1. 为什么Kubernetes成了容器编排的事实标准1.1 从单机Docker到集群管理的痛点我最早接触容器的时候Docker刚刚火起来那时候大家觉得“一个应用打成一个镜像到处都能跑”已经是天大的进步。开发环境、测试环境、生产环境不再需要反复交代“我这边能跑”直接丢一个镜像过去就完事。但真正到了生产环境问题很快就浮出来了你有几十个容器要同时跑它们分布在几台机器上怎么做服务发现怎么做负载均衡一台机器挂了上面的容器谁来重新拉起流量变大了怎么扩容今天上线一个新版本怎么做到不中断服务这些问题单靠Docker本身解决不了。Docker Compose只能在单机层面编排Swarm虽然能跨节点但功能太弱。那时候的运维同学经常在凌晨做一套手工脚本检测到进程挂了就重启检测到流量高了就手动加机器。这套东西极其脆弱而且换一个人就玩不转。所以Kubernetes的出现本质上是为了解决“容器多了以后怎么管”这个问题它把调度、自愈、弹性伸缩、服务发现这些原本要自己折腾的能力做成了平台级的默认能力。1.2 Kubernetes的核心价值声明式而非命令式刚开始用Kubernetes的时候我脑子里还是传统的“命令式”思维总觉得系统应该告诉我“去干这件事”。但Kubernetes的玩法完全不同它希望你告诉它“我希望达到什么状态”然后它自己去搞定。举个例子传统的脚本思路是“启动nginx、发现挂了就重启、流量到了就加副本”而Kubernetes的玩法是你提交一个Deployment声明“我要3个nginx副本”之后系统持续保证这个状态——副本少了会拉起多了会回收节点挂了会在其他地方重建。这个思维转变非常重要行业内叫“声明式API”。说白了就是你负责提需求系统负责干活。刚开始你会觉得不习惯因为“希望状态”和“实际状态”之间总有偏差Kubernetes内部通过控制循环Control Loop不断比对这两个状态然后执行动作让它们收敛。理解了这一点再去看它的各种功能就会豁然开朗为什么有ReplicaSet因为在管理副本数。为什么有Service因为在提供稳定访问入口。为什么有控制器因为不同的应用生命周期需要差异化管理。2. 核心概念的一次性理清2.1 Pod最小的调度单位为什么不是容器很多人接触Kubernetes第一个困惑就是明明我用的是Docker容器为什么Kubernetes的最小单位变成了Pod其实理由很实在。有些应用表面上是一个进程实际上一拆开是多个关系极其紧密的进程比如一个主进程配一个日志收集的sidecar或者一个Web进程配一个本地缓存进程。它们需要共享网络栈、共享存储、最好还被调度到同一台机器上一起生一起死。如果最小单位是容器这些紧密关系就得靠外部机制硬凑非常别扭。Pod就是把一组“命运共同体”容器打包在一起的抽象层。里面的容器共享同一个IP地址、共享同一个网络命名空间可以通过localhost互相访问也能共享同一个Volume。我打个比方容器是乐高积木里的小块Pod是提前拼好的一个小组件Kubernetes调度器只搬运“组件”不拆散“小块”。这对网络理解也很关键——Pod里的容器端口是共享的不能冲突你不能在一个Pod里让两个容器同时监听80端口。2.2 控制器Deployment、StatefulSet、DaemonSet怎么选Pod在Kubernetes里是“可牺牲”的它会滚动更新、会被重新调度、IP地址会变。所以你在生产环境几乎不会直接去创建裸Pod而是通过控制器来声明Pod的期望状态。最常见的三个控制器选型逻辑其实很清晰Deployment面向无状态应用。Web服务、API服务、任务型服务这种随时可以替换实例用Deployment就对了。它支持滚动更新、回滚、副本扩缩容。StatefulSet面向有状态应用。数据库、消息队列、ZooKeeper这类需要稳定网络标识稳定的Pod名称、稳定的存储的服务用StatefulSet。它给每个实例一个固定的序号和独立的存储卷重启后身份不变。DaemonSet保证每个节点上恰好跑一个Pod。典型场景是日志采集Fluentd、监控探针Prometheus Node Exporter、网络插件Calico。我最初的项目就是从这三个控制器开始的核心原则就一句话你的应用有没有稳定的身份和存储没有用Deployment有用StatefulSet要每台机器都有用DaemonSet。别把无状态应用塞进StatefulSet里自找麻烦也别指望Deployment能给你数据库实例提供稳定的“名字”。2.3 Service与网络ClusterIP、NodePort、Ingress的关系Pod是会生老病死的IP也会变。Service就是那个“不变的入口”它通过标签选择器找到一组符合条件的Pod并把流量转发给它们。Service有三种常见类型我见过不少人搞混Service类型作用范围典型使用场景ClusterIP集群内部访问后端服务之间的互相调用只在集群内可达NodePort集群外部通过节点IP端口访问测试环境临时暴露服务或者配合Ingress使用LoadBalancer通过云厂商负载均衡器访问公有云上的生产环境直接暴露服务ClusterIP是默认类型等于给一组Pod提供了一个集群内部的虚拟IP和DNS名字。NodePort是在每个节点上开一个端口把流量转发到对应的Service上外部通过节点IP:端口就能访问。但生产环境很少直接用NodePort因为端口多了难管理、安全性也差。正规做法是上面再加一层Ingress——它本身是一个七层负载均衡器常见的是nginx-ingress或traefik根据域名和路径路由到不同的Service上。你只需要开一个外网入口所有服务都走这一个口进来。3. 实战从零把nginx部署到Kubernetes集群3.1 环境准备我用的什么方式搭建集群要实战就得先有一个集群。我在本地阶段用minikube体验但搞开发调试到一定深度之后我更推荐用KindKubernetes in Docker它把整个集群跑在Docker容器里创建速度快、资源消耗小、还能模拟多节点。生产环境我用的是一套三节点的二进制安装集群但那个过程太繁琐不适合新手起步。比较舒服的路径是本地用Kind或minikube先跑通业务逻辑再上云或者用kubeadm搭正式的集群。这里有一个新手很容易踩的坑装完集群第一件事先检查上下文别对着错误的集群发命令。kubectl config get-contexts看一下当前用的是哪个集群kubectl config current-context确认你要操作的正确环境。我在真实环境里就误操作过两次一次把测试环境的配置丢到了生产集群还好只是增加了副本数发现及时撤回了。在给关键集群操作之前养成这个习惯能省掉很多麻烦。3.2 编写YAML的完整过程部署nginx最核心的是两步Deployment定义“跑什么”Service定义“怎么访问”。我分享一份我常用的配置然后逐步解释关键字段。首先是Deployment的YAMLapiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - name: nginx image: nginx:1.27-alpine imagePullPolicy: IfNotPresent ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 3 periodSeconds: 5我解释几个容易被忽视的点replicas: 3期望的副本数。生产上不要设置1除非是临时验证。3个副本意味着当节点故障时Pod有机会在其他节点重建这是最基础的高可用保障。selector.matchLabels和template.labels必须一致。这个标签选择器决定了ReplicaSet要去管理哪些Pod我见过有人修改了模板标签但忘了改选择器结果ReplicaSet创建的Pod完全不匹配集群里出现了一堆“孤儿Pod”非常迷惑。resourcesrequests和limits一定要配。很多新手不配觉得不配跑得更爽。实际上Kubernetes调度器参考requests来决定把Pod放在哪个节点如果你不配调度器会把Pod打散到负载已经很重的地方而limit不配意味着这个Pod可以无限占用节点内存有可能把整个节点打挂。后面我会专门讲这个坑。readinessProbe就绪探针滚动更新时至关重要。新Pod只有通过了这个探针才会被纳入Service的负载均衡池保证流量不会打到还没准备好的实例上。然后是Service的YAMLapiVersion: v1 kind: Service metadata: name: nginx-demo-svc spec: type: ClusterIP selector: app: nginx-demo ports: - name: http port: 80 targetPort: 80这里port是Service对外服务的端口targetPort是Pod里nginx实际监听的端口selector告诉Service流量该发给哪些Pod。注意Service的selector要跟Deployment里的template.labels一致也就是app: nginx-demo。如果selector写错了Service的Endpoints列表会是空的流量自然转发不出去。执行命令很简单kubectl apply -f nginx-deployment.yaml kubectl apply -f nginx-svc.yaml kubectl get pods -o wide kubectl get svc nginx-demo-svc3.3 访问链路与调试命令上面的Service是ClusterIP类型只能在集群内部访问。想从外部访问有两个方案。方案一是把type改成NodePort改完后再看Service会发现多了一个映射端口比如80:31567/TCP这时候通过任意节点的IP加31567就能访问。但NodePort端口有范围限制默认30000-32767单纯说“外网访问”它不够优雅。方案二是上Ingress生产环境我一般这么做。Ingress需要一个Ingress Controller在集群里跑着最常用的是ingress-nginx。安装完之后创建一个Ingress资源来定义路由规则apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-demo-ingress spec: rules: - host: demo.example.com http: paths: - path: / pathType: Prefix backend: service: name: nginx-demo-svc port: number: 80这样外部的请求到了Ingress Controller根据host字段匹配demo.example.com再转发给对应的Service。如果你本地做实验没有域名可以临时在/etc/hosts里把域名指向集群入口IP。调试是日常高频场景我列几个常用的命令组合kubectl logs -f deployment/nginx-demo看日志kubectl describe pod看Pod事件和容器启动状态kubectl get endpoints确认Service背后有Podkubectl exec -it pod-name -- sh进容器里排查问题。遇到Service访问不通我按这个顺序查先看Pod是否Running且Ready再看Endpoints是否有值再看Service选择器是否匹配标签最后看节点和网络策略是否拦截。4. 原理视角从API Server到etcd源码阅读的切入路径4.1 一次kubectl apply背后发生了什么当你敲下kubectl apply -f nginx-deployment.yaml背后是一个完整的事件链。先看客户端kubectl读取你的kubeconfig配置文件找到API Server地址和认证信息把YAML转换成JSON格式的请求通过HTTPS发送给API Server的/apis/apps/v1/deployments接口。API Server是Kubernetes所有请求的总入口它先做认证你是谁、再授权你能不能干这个事、最后做准入控制比如检查命名空间是否存在、资源配额允不允许全部通过之后才会把数据写入etcd。etcd是一个分布式键值存储是Kubernetes唯一持久化数据的地方。你提交的Deployment对象就在这里存着。但存进去不代表运行起来了接下来才是控制器的重头戏。Deployment控制器一直Watch着etcd里的Deployment数据发现有了新对象它会创建对应的ReplicaSetReplicaSet控制器发现ReplicaSet的存在之后会比对“期望副本数”和“实际Pod数”然后调API Server创建缺失的Pod。Pod被创建的时候并没有被分配到任何节点它处于Pending状态。Kubernetes的调度器scheduler监听到了这个待调度的Pod根据节点的剩余资源、亲和性约束、污点和容忍度等条件选定一个合适的节点然后通过API Server把这个调度结果写回etcd。节点上的kubelet每个节点上的“耳目”通过持续的Watch机制发现Pod被分配到了自己节点就开始调用容器运行时containerd或CRI-O拉取镜像、启动容器。之后kubelet还会持续上报Pod状态更新到etcd里。所以整个链路串起来是kubectl → API Server → etcd → Deployment控制器 → ReplicaSet控制器 → scheduler → kubelet → 容器运行时。理解了这条链路你排查问题的时候就有方向了Pod卡在Pending多半是调度问题镜像一直拉取失败多半卡在kubelet那一步Pod报CrashLoopBackOff则是容器启动后立刻退出。每个现象对应的是链路中特定环节的异常。4.2 源码阅读的推荐路径和《深入理解kubernetes源码》这类书的读法很多人问我源码到底怎么读我觉得最快路径不是从main函数开始而是从“你平时最常打交道的对象”反着读。比如你先读kubectl apply这条命令的实现顺着它走到客户端如何组织请求、如何解析响应再读API Server的路由注册逻辑看Deployment这个资源是怎么被处理的然后看controller-manager里的Deployment控制器看它内部怎么实现“期望状态比对”。这三层走完你对Kubernetes的整个骨架就有感觉了。我大概翻过好几本Kubernetes源码相关的资料像《深入理解Kubernetes源码》这类书价值在于给你提供了模块级别的导航图。它会把client-go的Informer机制、WorkQueue、DeltaFIFO这些关键组件拆开讲。但我不建议从头到尾啃代码Kubernetes目前体量非常大代码量数千万行从头看不可能看完。我的读法是把源码当字典用——排查问题时带着具体问题去查比如“为什么某个事件没有触发我的控制器”就去看Informer的机制。源码阅读还有一个核心前置技能理解client-go这套客户端库。它是Kubernetes内部所有控制器和外部operator与API Server通信的基础库。你先搞懂informer的ListAndWatch机制——控制器启动的时候通过List全量拉取一次数据之后通过Watch持续监听变化变化的增量进入DeltaFIFO队列由自定义的WorkQueue分发到handler处理。Kubernetes的性能优势很大程度上来自这套“本地缓存增量监听”的机制控制器不会每次都要查询API Server。哪里读不懂就先看References文档再回到源码借助IDE跳转一点点啃。4.3 一个必须理解的机制控制循环与水平Pod自动伸缩理解了事件链之后我强烈建议你把“控制循环”这个机制吃透因为它贯穿了几乎所有核心组件。控制循环的逻辑就是三段期望状态、当前状态、差异处理。Deployment控制器时刻在算“我期望3个副本现在只有2个那我创建一个”。HPAHorizontalPodAutoscaler控制器也一模一样它从metrics-server拿业务的指标比如CPU使用率或QPS算出“当前需要的副本数是5期望副本数是3”然后调用API Server去更新Deployment的副本数。我在实际项目里就用HPA做过度量驱动的自动扩容配置大概是apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nginx-demo-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-demo minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60这个配置的含义是当所有Pod的平均CPU使用率超过60%HPA会逐步增加副本数最多到10个低于安全水位后会缩容最少保留2个。有一个我踩过的小坑HPA依赖metrics-server正常工作而metrics-server的数据采集有延迟所以HPA的响应不是瞬时的。压测的时候刚发起高流量扩容要等上一两分钟才生效这是正常现象别误以为HPA坏了。5. 这一年多踩过的坑和总结的经验5.1 资源请求与限制说不配就不配的代价前面提到了资源请求requests和限制limits这里专门展开说。我见过最典型的故障一个节点上跑了几个Java应用YAML里都没写limits某天流量稍微上来一点其中一个应用库吃内存直接把节点内存耗尽触发内核OOM结果节点上所有Pod一起陪葬。发生事情之后查监控发现节点内存曲线一路飙升到100%连kubelet自身都被拖垮了。正确的做法是每个容器都写明requests和limits。requests是调度依据告诉调度器“我这个容器启动至少需要多少资源”调度器据此保证节点总有足够资源不会多个容器超配到爆limits是运行时限制超了会被系统杀掉或限制CPU。给JVM类应用配内存一定要给JVM堆外留空间否则limits刚好等于堆大小一跑起来就OOMKilled。比如一个堆内存512M的应用我一般把limits的memory设到768Mi或1Gi甚至更高给元空间、线程栈留余地。还有CPU的requests和limits要注意单位100m等于0.1个CPU核心。如果一台节点是4核requests总和超过4000m时调度器就会拒绝新的Pod因为你明确说“我需要至少0.2核”但节点已经分完了。合理预留资源比例很关键我习惯保留20%~30%的节点余量防止雪崩。5.2 镜像拉取策略与版本管理的坑镜像版本管理是个大坑。很多项目镜像tag用的是latest看起来方便实际上等于放弃可重复性。“昨天部署的还能跑今天重新部署同一个YAML就跑不起来了”——因为latest镜像的内容变了。Kubernetes的imagePullPolicy如果没显式指定默认规则是tag为latest时总是拉取其他tag在节点本地没有时才拉取。所以即便你手动指定nginx:latest每次部署也可能拿到新内容行为不可控。用明确版本的tag是我的底线例如nginx:1.27-alpine、my-app:v1.2.3让每次部署都可追溯。更进一步推荐用镜像摘要digestmy-appsha256:xxxxx这个是最强的一致性保障镜像仓库里哪怕内容被覆盖只要digest不变拉到的内容一定不变。如果非要用latest做本地开发也请显式设置imagePullPolicy: IfNotPresent至少避免反复拉取。还有一个跟镜像相关的常见问题是镜像拉取失败。排查的时候先确认节点能不能访问镜像仓库再检查私有仓库的认证配置。配置了imagePullSecret的要用kubectl describe pod看看是不是Secret名字写错了、Secret内容里有没有正确编码账号密码。我在一个环境里遇到过明明在命名空间A配了SecretDeployment却部署在命名空间B结果镜像一直认证失败折腾了半小时才发现命名空间不对。5.3 我对Kubernetes学习路径的个人建议最后聊学习路径因为“Kubernetes知多少”这个问题最终回答还是拿实践说话绕不开一条循序渐进的路线。我自己的体会是别一上来就啃源码也别只盯着YAML背字段。先掌握三件事一把Pod、Service、Deployment相互关系吃透能在集群里部署一个有完整访问链路的应用二理解控制器的控制循环思想再去看任何自定义资源CRD/Operator都会更快三学会看日志、看事件、看监控定位问题的能力比记忆力管用得多。从入门到能独立排障我建议按这个顺序推进本地搭建Kind或多节点集群 → 学会用kubectl操作核心资源 → 手动部署一个包含Deployment、Service、Ingress、ConfigMap、Secrets的完整服务 → 给服务加上资源配额、HPA、探针 → 然后去理解API Server、etcd、调度器之间的关系 → 最后带着具体问题去读源码比如看调度器如何选节点、控制器如何计算期望状态。我通过Kubernetes的入门到日常运维最深的感觉是这个技术栈复杂但有迹可循。它的所有“高级”能力几乎都能从“声明式期望状态 控制循环”这个最基本的模型推导出来。你把这条主线抓住了剩下的都是细节填充。如果你现在刚起步别盯着那些平时用不到的抽象概念先把一个nginx应用跑通、给它加上各种生命周期保障再回头看原理你会发现一切都变得自然很多。
