我第一次认真接触 Kubernetes 是 2018 年当时被一堆新名词砸得晕头转向Pod、Deployment、Service、etcd、kubelet…… 最要命的是我虽然能照着教程把集群搭起来但遇到问题完全不知道从哪里下手。后来我才意识到k8s 入门最大的门槛不是命令也不是 YAML而是缺少一张全局地图。这篇文章就是一份纯入门向的 k8s 概述尽量用大白话把 Kubernetes 是什么、解决什么问题、核心概念有哪些、和 Docker 什么关系、怎么快速搭环境、日常怎么用以及它周边值得关注的东西一次性讲清楚。适合刚接触容器编排的开发者、运维也适合准备把应用容器化上 K8s 的团队。读完之后你不需要立刻成为专家但你会知道后续该往哪个方向深入。1. Kubernetes 到底解决了什么问题1.1 从 Docker 到编排单台机器的瓶颈Docker 解决的是“应用打包和分发”问题。它把代码、依赖、运行环境打成一个镜像拿到哪台机器上都能跑这确实是一个非常了不起的进步。但问题也随之而来当容器数量从几个增加到几十个、上百个的时候光靠 Docker 本身已经管不过来了。举个例子你用手动 docker run 启动了一个 web 服务进程崩了谁来重启流量上来了怎么把副本从 3 个变成 20 个新版本发布怎么做到不停机滚动替换容器的 IP 是动态的服务之间怎么互相找到对方这么多容器的 CPU、内存怎么分配和限制这几类问题统称为“编排”问题而 Kubernetes 就是专门解决这些问题的。你可以把 Docker 想象成集装箱把 Kubernetes 想象成港口调度系统。单个集装箱再标准如果没有调度系统那也只是一个一个孤立的大铁箱成不了吞吐量惊人的港口。Kubernetes 存在的意义就是把分布在成百上千台机器上的容器像港口调度集装箱一样统一管理起来让你以一种“面对一台超级大电脑”的方式去使用整个集群。1.2 声明式 API 与自愈能力理解 K8s 的一把钥匙Kubernetes 最核心的哲学是“声明式”你不需要告诉系统“怎么做”只需要告诉它“最终要达到什么状态”。系统会持续把当前状态往期望状态收敛直到两者一致。比如你在 YAML 里写了 replicas: 3代表你期望始终有 3 个 Pod 在运行。如果其中一个 Pod 挂了kubelet 会把这个变化上报给控制平面控制平面会在其他可用节点上重新调度一个新 Pod让副本数重新回到 3。这种“当前状态 vs 期望状态”的对账逻辑是理解几乎所有 K8s 问题的前提。K8s 的架构可以分成控制平面和工作节点两层。控制平面负责决策和状态管理部署在 Master 节点上核心组件包括 API Server、etcd、Scheduler、Controller Manager工作节点负责真正运行容器每个节点上有 kubelet、kube-proxy 和容器运行时。用一句人话来概括API Server 是“前台的接待员”所有操作都走它etcd 是“数据库/记事本”保存集群的完整状态Scheduler 是“调度员”决定 Pod 放在哪台机器上Controller Manager 是“监工”盯着各种控制器把状态掰回正道kubelet 是“各台机器上的执行者”负责把容器真正拉起来并报告状态。2. 核心概念速览把 K8s 当成一套操作系统刚开始学 K8s最好把每个概念都理解成“API 资源对象”。你可以通过 YAML 或命令创建对象K8s 会根据这些对象持续工作完成你要的结果。下面这些概念是按重要程度排的先把它们搞清楚日常 80% 的操作都不会慌。2.1 Pod最小的调度单元Pod 是 Kubernetes 里最小的部署和调度单元。注意它不是容器而是一个“容器组”。同一个 Pod 里的容器共享网络命名空间和存储卷它们之间可以用 localhost 直接通信也能挂载同一份数据卷。一个 Pod 通常只跑一个主容器另外一个边车容器专门负责日志采集、流量代理之类的辅助工作。为什么需要 Pod 而不是直接用容器因为有些场景下主应用和辅助功能的关系非常紧密比如日志采集器必须和应用容器待在同一台机器上才能读它的日志文件。把它们放在同一个 Pod 里就是一个天然的部署单元。有一点必须记住一个 Pod 只有一个 IP而且这个 IP 是动态的。Pod 被重建之后IP 一定会变。所以千万不要在应用配置里写死 Pod IP跨服务访问要走 Service。2.2 Deployment声明副本状态的核心控制器Deployment 是管无状态应用最常用的控制器负责维护 Pod 的副本数支持滚动更新和回滚。你只需要定义镜像版本和副本数Deployment 会逐个替换旧 Pod在更新过程中保持服务整体可用而不是一起重启。配合 HPAHorizontalPodAutoscalerDeployment 还能根据 CPU 等指标自动伸缩副本数量这是 K8s 处理高并发的核心机制之一。你预期“3 个副本”流量涨到阈值后它自动扩到 10 个流量降下来再缩回去整个过程不需要人工介入。2.3 Service 与 Ingress流量如何进来Service 为一组 Pod 提供一个稳定的虚拟 IPClusterIP和 DNS 名称并负责负载均衡。它通过 Label Selector 找到后端 Pod把请求转发给它们。因为 Pod IP 动态变化Service 相当于一个固定入口只要 Pod 的标签匹配Service 就能找到它们。Ingress 是七层网关负责把外部 HTTP/HTTPS 流量路由到集群内部的 Service。Ingress 本身只是一套转发规则真正执行规则的是 Ingress Controller比如 Nginx Ingress。你可以把它理解成“域名/路径转发路由器”外部请求来了先打到 Ingress Controller它再根据域名和路径把流量转到对应的 Service。2.4 ConfigMap 与 Secret配置和敏感信息的解耦ConfigMap 专门用来存普通配置Secret 专门用来存密码、Token、密钥等敏感信息。它们可以以环境变量的方式注入容器也可以以文件形式挂载到容器内部。好处是镜像和配置分离同一份镜像在开发、测试、生产环境里配不同的 ConfigMap 就能复用。Secret 不是纯明文存储它只是做了 base64 编码严格意义上不能替代加密方案。生产环境下要用成熟的密钥管理方案比如对接外部的 KMS 服务但入门阶段先理解“普通配置放 ConfigMap敏感信息放 Secret”这个分层就够了。2.5 Namespace、Label 与 Selector集群里的组织方式Namespace 用来隔离资源比如把 dev、test、prod 三个环境分开或者把不同团队的资源分开避免互相干扰。Label 是键值对标签Selector 是查询标签的选择器。Service 通过 Selector 找到自己的后端 PodDeployment 通过 Selector 管理它创建出来的 Pod。这套设计非常轻量却很强大。它不像传统运维那样靠目录层级或命名规范来组织资源而是靠“打标签 按条件筛选”。给资源打上 teampay、envprod 这类标签后续在监控、排查、自动化运维里会方便很多。除了上面这些你还会碰到 StatefulSet有状态应用、DaemonSet每个节点恰好运行一个 Pod比如日志采集器、Job/CronJob一次性任务和定时任务。入门阶段可以先把它们名字记住知道什么时候用就好不需要立刻深入。3. Docker 和 Kubernetes 到底是什么关系3.1 分工不同打包 vs 调度这是初学者最容易绕晕的地方。简单来说Docker 负责把应用打成镜像、运行容器Kubernetes 负责管理这些容器在哪里跑、跑多少、挂了怎么办。两者不是竞争关系而是上下游配合关系。更准确地说现代 Kubernetes 集群通过 CRIContainer Runtime Interface与容器运行时交互。自从 Kubernetes 1.24 版本之后kubelet 不再直接管理 Docker 创建的容器而是通过 containerd 或 CRI-O 对接。Docker 本身依然可以用来构建镜像、在本地开发环境运行容器但在集群节点上Docker daemon 的角色正在被 containerd 取代。这个变化有一个很现实的影响在 K8s 节点上用 docker ps 经常看不到 K8s 创建的容器很多新手在这里卡住。解决办法是使用 crictl 或 kubectl 查看容器状态而不是依赖 docker 命令。3.2 Docker Compose 与 K8s 的边界Docker Compose 适合单机上的多容器编排用起来非常简单非常适合本地开发K8s 是分布式场景下的集群级编排适合成百上千台机器、海量容器的场景。如果你只有一两个应用用 Compose 就够了但如果你的业务有几十个微服务还要做弹性伸缩和高可用那 Compose 会很快撞到天花板。在学习路径上我一般建议先熟悉 Docker 的核心操作比如镜像构建、容器网络、数据卷然后再用 minikube 或 kind 过渡到 K8s。另外要明确一点K8s 使用的也是 OCI 镜像标准Dockerfile 构建出来的镜像可以直接用在 K8s 中所以 Docker 依然是云原生生态的重要基础并不会被完全替代。4. 从零搭一套环境本地与生产级4.1 本地开发环境怎么选本地学习有几个常见选择。minikube 是官方维护的轻量级方案适合单机学习一条命令就能起一个单节点集群kindKubernetes in Docker用容器来模拟节点在 CI/CD 环境里非常流行k3s 则适合边缘计算和资源受限场景也可以用来在本地快速起集群。我的个人建议是先别装太复杂的用 minikube 把核心概念跑一遍然后找一个周末用 kubeadm 手动搭一套“一主两从”的集群。这个过程能帮你把前面讲的控制平面、节点、etcd、CNI 网络这些概念全部串起来比看十遍文档都管用。4.2 kubeadm 搭建最小集群的流程下面是最简化版的搭建思路不同版本细节会略有差异但大方向一致准备三台 Linux 主机建议 2 核 4G 以上关闭 swap配置好主机名和 hosts 映射。安装容器运行时containerd以及 kubeadm、kubelet、kubectl 三个组件。在 Master 节点执行 kubeadm init初始化控制平面生成 kubeconfig。安装 CNI 网络插件比如 Calico 或 Flannel让节点之间可以互通容器网络。用 kubeadm join 命令把两个 Worker 节点加入集群。验证kubectl get nodes 应该看到 3 台机器都是 Ready再执行 kubectl get pods -n kube-system 确认核心组件正常运行。这里给一个最简单的初始化示例需要在初始化前规划好 Pod 网段kubeadm init \ --apiserver-advertise-address192.168.1.10 \ --pod-network-cidr10.244.0.0/16 \ --kubernetes-versionv1.28.2执行成功后把生成的 kubeconfig 复制到 root 用户目录下然后按输出提示去安装 CNI 插件。很多人卡在 Node NotReady绝大多数情况都是网络插件没装或者插件版本和 K8s 版本不兼容。4.3 生产环境高可用三台 Master 怎么保证生产环境千万不要只搭单节点集群控制平面一定要做高可用。所谓三台 Master其实就是让控制平面的每个组件都有多个副本不出现单点故障至少 3 个 Master 节点每个节点都运行 API Server、Scheduler、Controller Manager 和 etcd。前端用负载均衡器比如 Nginx 或 HAProxy把流量分发到多个 API Server对外只暴露一个虚拟 IP。etcd 使用奇数节点常见是 3、5、7基于 Raft 协议保证数据一致性容忍少数节点故障。使用 KubeKey、kubeadm 这类工具可以自动化这个流程。KubeKey 是很多实践团队会用的安装工具支持一键部署高可用集群也能管理证书续期。用这类工具的好处是它会帮你处理好 etcd 集群、负载均衡前置、证书签发这些繁琐步骤。证书过期是生产环境最常见的坑。K8s 组件证书默认只有 1 年有效期用 kubeadm 搭建的集群如果不做自动续期到期后 API Server 会拒绝连接那时整个集群会处于非常尴尬的“半瘫痪”状态。kubeadm 可以配置证书自动续期KubeKey 也提供了对应的证书续期能力。日常运维一定要监控证书过期时间最好在失效前至少一个月处理。5. 日常使用常用命令与排障经验5.1 kubectl 常用命令清单kubectl 是操作 K8s 集群的核心命令行工具日常主要就是围绕它来做增删改查。我把最常用的一组命令整理成了表格方便你对照使用。操作场景命令示例说明查看集群节点kubectl get nodes看节点状态正常应为 Ready查看资源列表kubectl get pods/deploy/svc -n 命名空间get 是所有查询的基础查看详情和事件kubectl describe pod pod名 -n 命名空间排查问题第一步查看日志kubectl logs -f pod名 -n 命名空间-f 表示持续跟踪日志进入容器kubectl exec -it pod名 -n 命名空间 -- /bin/sh进入容器内部排查声明式更新kubectl apply -f deployment.yaml创建/更新资源都推荐用 apply删除资源kubectl delete -f deployment.yaml删除一个或多个对象手动伸缩kubectl scale deployment 名字 --replicas5临时扩容/缩容查看滚动状态kubectl rollout status deployment/名字看发布是否完成回滚kubectl rollout undo deployment/名字回滚到上一个版本查看资源占用kubectl top node / pod需要预先部署 metrics-server5.2 排查思路先状态再事件后日志K8s 排障有一个很通用的思路先看状态再看事件接着看日志最后检查网络。千万不要一上来就进容器翻配置文件。如果 Pod 一直停留在 Pending 状态通常是资源不足、节点资源耗尽或者调度器无法满足标签约束。用 kubectl describe pod 看 Events。如果看到 ImagePullBackOff说明镜像拉取失败。检查镜像名、tag 是否存在私有仓库是否配置了认证。如果看到 CrashLoopBackOff说明容器启动后马上崩溃又不断被重启。用 kubectl logs 看容器输出了什么错误。如果节点变成 NotReady先看节点上的 kubelet 服务状态再看网络插件是否正常运行。如果 Service 访问不通重点检查 Endpoints 有没有地址。用 kubectl get endpoints service名如果列表为空说明 Service 的 Label Selector 没有匹配到任何 Pod。这套路径看着简单但非常管用。K8s 的日志和事件信息量很大学会筛选关键错误比死记硬背命令更重要。5.3 几个实操原则越早知道越省事生产环境里我强烈建议坚持几条操作原则。第一创建或更新资源一律用 kubectl apply -f不要用 create这样才能体现声明式管理的优势第二不要直接修改运行中的 Pod不要进去打补丁式改配置有改动就先改 YAML 再重新 apply第三给所有资源打上标签比如 env、app、team后续排查和自动化会方便得多。还有一个容易被忽略的点kubectl delete 是按资源名找对象的如果对象处于别的命名空间不加上 -n 参数就会提示找不到。删除之前建议先用 kubectl get 确认一下目标到底在哪个命名空间避免误删。另外etcd 是整个集群状态的核心所有关于 Pod、Service、配置的数据都存在里面。所以一定要定期备份 etcd这是生产环境安全感的底线。6. 从入门到落地监控、高并发、GPU 与 Service Mesh6.1 监控Prometheus 与 K8s 的天然配合集群搭起来之后第一步通常是部署监控。Prometheus 在云原生生态里几乎是默认选择它通过定期抓取指标接口来监控系统而 K8s 本身有完善的服务发现和标签机制两者配合非常自然。社区常见的方案是 kube-prometheus-stack部署之后能一次性拿到组件监控、kubelet 监控、Grafana 面板和 Alertmanager 告警规则。另外还需要部署 metrics-server它是 kubectl top 命令的基础也是 HPA 获取指标的数据来源之一。没有 metrics-server 的话HPA 和 top 命令都无法工作。6.2 高并发场景与自动扩缩容K8s 处理高并发主要靠三层机制负载均衡层负责把流量分发到多个副本Service 本身就带负载均衡能力自动伸缩层通过 HPA 根据 CPU、内存或自定义指标动态调整副本数量资源配额层通过 requests/limits 控制每个 Pod 占用的资源范围。如果你拿压测工具去做高并发测试比如 JMeter测之前必须看 Pod 的 requests 和 limits 设置是否合理。limits 设得太小流量一上来 Pod 就可能被 OOMKilledrequests 设得太大集群会白白占着资源不干活。压测不是只看集群能扛多少并发更要看它在资源限制下能不能稳定地弹性伸缩。6.3 GPU 资源调度如果要在 K8s 里跑 AI 训练或推理任务需要让集群“认识”GPU。常见的做法是部署 NVIDIA device plugin它会把每个节点的 GPU 作为扩展资源nvidia.com/gpu上报给集群。之后你就可以在 Pod 的 resources 里申请 GPU 资源了。resources: limits: nvidia.com/gpu: 1这样调度器就知道这个 Pod 需要使用 GPU并且只会把它调度到真正有 GPU 且剩余显存的节点上。GPU 资源的使用和 CPU、内存不太一样它只能按“张”来分配而且节点上如果混部普通业务和高 GPU 业务要特别注意显存和算力隔离的问题。6.4 Service Mesh 与 Dubbo MeshService Mesh 解决的是微服务治理问题比如流量管理、熔断、灰度发布、链路追踪。Istio、Linkerd 是比较流行的 Service Mesh 框架它们会在 Pod 旁边注入一个代理容器接管所有进出流量让应用不用改代码就能获得这些治理能力。Dubbo Mesh 则是把 Dubbo 这类微服务框架和 K8s 基础设施结合起来让老一代微服务架构也能享受到 Service Mesh 的能力。这个方向对很多人来说是进阶内容入门阶段了解即可但如果你的团队有大量微服务可以提前关注一下。6.5 集群运维与证书续期最后再强调一次证书问题。K8s 集群的组件证书默认有效期是一年很多团队把集群搭完就忘了这事一年后 API Server 突然不可用才发现是证书过期。用 kubeadm 部署的集群可以执行 kubeadm certs renew all 来续期用 KubeKey 部署的集群也有对应的证书管理能力。最好的方式是把证书过期时间加到监控告警里到期前 90 天就提醒你处理。关于怎么入门 K8s我最掏心窝的建议是别只背命令也别只看不练。我第一次用 kubeadm 搭集群光 etcd 集群的地址配置就折腾了一个晚上正是那次踩坑让我搞清楚了控制平面各个组件是怎么协作的。你先照着官方文档搭一套单节点然后用 Deployment 发布一个 Nginx再把它暴露成 Service配上 ConfigMap 改一次配置最后模拟一次 Pod 崩溃看看它怎么自愈。等这些基本动作都亲手做过一遍K8s 这张地图就已经在你脑子里了。后面的进阶方向虽然还有一大片但至少你已经有底气继续往下走了。