Kubernetes：容器编排

为什么需要 Kubernetes：从手工管容器到声明式编排

当容器数量只有几十个时，docker run 加几段脚本勉强能管；一旦超过这个规模，就会出现一连串问题：进程崩溃无人拉起、流量增长只能手动扩容、发布需要停机窗口、节点间端口冲突、跨机器服务发现困难。胶水脚本把状态散落在各处，脚本本身反而成了新的故障源，排障时无法回答“现在系统实际是什么状态”。

Kubernetes 的解法是把“期望状态”固化为 API 对象（Pod、Deployment、Service 等）。控制面（Control Plane）由 API Server、etcd、Controller Manager、Scheduler 组成闭环：etcd 是分布式键值存储，保存集群全部对象状态；Controller Manager 中的各控制器反复比对“期望状态”与“实际状态”并自动收敛；Scheduler 为新 Pod 挑选合适节点；每个节点上的 kubelet（节点代理）保证容器按照清单运行。自愈、扩缩容、滚动更新都变成“改声明，系统自己收敛”，这正是它与脚本管理方式最根本的差异。

与 Docker Swarm、Nomad 等同类工具相比，Kubernetes 的气质是优先保证工程化的扩展性与生态统一：API 即契约，CRD（自定义资源）+ Operator（用控制器管理特定应用的模式）让任意领域都能以 Kubernetes 的方式自动化管理。代价是概念多、学习曲线陡，因此它的价值也随集群规模增长而放大。

安装与环境配置：4 步就绪

最少需要三样东西：kubectl（命令行客户端）、一个本地集群运行时、以及 Docker（kind 依赖它创建节点）。

步骤一：安装 kubectl。 macOS 用 Homebrew，Linux 用官方二进制脚本，安装后验证版本。

步骤二：安装 kind（Kubernetes in Docker）。 kind 用容器模拟节点，几分钟就能起一个多节点集群，适合学习和 CI；若需要更接近真实节点的体验可改用 minikube。

步骤三：创建集群。 kind create cluster 默认创建单节点集群，也可通过配置文件指定 control-plane 与 worker 节点数量。

步骤四：验证。 kubectl cluster-info 检查 API Server 连通性，kubectl get nodes 确认节点 Ready。

生产或需要模拟生产的环境建议用 kubeadm（官方安装器）或直接使用云托管集群，前者负责初始化 control plane 与加入 worker 节点，后者免去 etcd 与控制面运维。

# 1. 安装 kubectl（macOS；Linux 用 curl 下载官方 stable 二进制）brew install kubectlcurl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" # 2. 安装 kindbrew install kind # 3. 创建本地集群（kind 会先创建 Docker 网络与节点容器）kind create cluster --name k8s-demo # 4. 验证kubectl cluster-infokubectl get nodes -o wide

快速上手：15 分钟跑通部署、发布与扩容

最小可用流程的思路：用 Deployment（管理无状态应用副本与滚动更新的工作负载对象）声明“我要 3 个 Nginx 副本”，用 Service（为一组 Pod 提供稳定访问入口的对象）暴露访问，再用 kubectl 走一遍扩容和升级，理解“声明一旦改变，系统自动收敛”。

步骤一：创建 Deployment。 执行 kubectl create deployment nginx --image=nginx:1.26 --replicas=3，Kubernetes 会自动创建对应的 ReplicaSet（负责维护副本数的控制器对象）与 3 个 Pod。

步骤二：确认 Pod 状态。 kubectl get pods -o wide 查看 Pod 所在节点与 IP；状态为 Running 且 READY 列为 1/1 即就绪。

步骤三：暴露 Service。 执行 kubectl expose deployment nginx --port=80 --type=NodePort，为 Pod 组创建稳定入口。

步骤四：本地访问。 另开终端执行 kubectl port-forward svc/nginx 8080:80，浏览器访问 http://localhost:8080 应看到 Nginx 欢迎页。

步骤五：滚动发布与扩容。 kubectl set image 修改镜像版本，kubectl rollout status 观察滚动过程——旧 Pod 逐个下线、新 Pod 逐个就绪，全程不中断服务；kubectl scale 调整副本数。

所有命令操作的都是 API 对象，因此更推荐把声明写成 YAML 文件提交，便于版本化管理与代码评审。

将上述 YAML 保存为 deployment.yaml 后执行 kubectl apply -f deployment.yaml，即可用声明式方式创建同一份工作负载。进阶技巧：用 kubectl explain deployment.spec 查看字段说明，用 kubectl get deployment nginx-web -o yaml 查看系统实际存下来的对象状态。

# 命令式快速演示kubectl create deployment nginx --image=nginx:1.26 --replicas=3kubectl get pods -o widekubectl expose deployment nginx --port=80 --type=NodePortkubectl port-forward svc/nginx 8080:80   # 另开终端访问 http://localhost:8080kubectl set image deployment/nginx nginx=nginx:1.27kubectl rollout status deployment/nginxkubectl scale deployment nginx --replicas=5kubectl delete deployment nginxkind delete cluster --name k8s-demo

apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx-webspec:  replicas: 3  selector:    matchLabels:      app: nginx-web  template:    metadata:      labels:        app: nginx-web    spec:      containers:        - name: nginx          image: nginx:1.26          ports:            - containerPort: 80

核心能力详解：5 大支柱

支柱一：声明式 API 与控制循环。 所有变更都通过 API Server 写入 etcd——分布式键值存储，相当于整个集群的“期望状态数据库”；Controller Manager 内的控制器（控制器是不断对比期望与现实的循环程序）持续工作，Deployment 控制器负责副本数，Node 控制器负责节点状态。这套机制让“自愈”变成基础设施行为而不是运维动作。

支柱二：调度与资源管理。 Scheduler 为新 Pod 挑选节点，先过滤（如资源是否够、是否满足亲和性），再打分择优。用户在容器里声明 requests（资源预留，调度依据）与 limits（资源上限，运行时限制），配合 LimitRange（命名空间级资源范围约束）与 ResourceQuota（命名空间级资源配额）防止单个应用挤占集群。GPU 需先部署 NVIDIA device plugin，节点才会暴露 nvidia.com/gpu 资源供调度。

支柱三：自愈与滚动发布。 kubelet 通过三类探针判断容器状态：livenessProbe 决定是否重启，readinessProbe 决定是否把流量打进来，startupProbe 用于慢启动应用。滚动更新由 strategy.rollingUpdate 控制，maxUnavailable 限制最大不可用数、maxSurge 限制最大超卖数，配合 minReadySeconds 保证新版本先稳定再继续推进。

支柱四：服务发现与流量治理。 Service 提供四种暴露方式：ClusterIP（集群内虚拟 IP）、NodePort（节点端口）、LoadBalancer（云负载均衡）、ExternalName（DNS 别名）；集群内 DNS 让 Service 名即域名。Pod 间网络由 CNI（容器网络接口）插件提供，常见选择 Calico（网络策略成熟）、Cilium（基于 eBPF，性能好）、Flannel（简单）；七层流量治理用 Ingress 控制器（如 ingress-nginx）按域名/路径转发。注意网络策略 NetworkPolicy 默认不生效，需要显式声明“允许谁访问谁”。

支柱五：弹性伸缩。 水平扩缩容 HPA 从 metrics-server（提供节点与 Pod CPU/内存指标的组件）读取数据，按“当前值/目标值向上取整”计算副本数；垂直扩缩容 VPA 建议或直接调整 Pod 资源规格，原地修改 CPU/内存的能力（InPlacePodVerticalScaling）自 v1.30 起为 Beta，调整时无需重建 Pod；节点层面的伸缩由 Cluster Autoscaler 等外部组件完成。CronJob 则负责定时任务，如定期清理或批处理。

生产部署与监控：从上线到运维

部署方式一：云托管集群（EKS/GKE/AKS）。 控制面（API Server、etcd、Controller Manager）由云厂商托管，自动完成版本升级与安全补丁，节点组按需扩缩。适合大多数生产业务：省去 etcd 备份、证书轮换、控制面高可用等最重的运维负担，同时保留完整的 Kubernetes API 兼容性。注意节点池仍需配置合理机型（如 GPU 实例）与自动伸缩策略。

部署方式二：自建高可用集群（kubeadm）。 生产建议 3 个 control-plane 节点 + 至少 2 个 worker 节点，用 kubeadm init 初始化后用 kubeadm join 加入；etcd 与 apiserver 之间启用 TLS，etcd 定期用 etcdctl snapshot save 备份；证书由 kubeadm cert renew 轮换。CNI 选型决定网络策略与性能，无特殊需求首选 Calico；升级必须逐 minor 版本推进，先对照官方 Deprecated API 迁移指南检查清单文件。

可观测性： 指标用 Prometheus 生态（kube-state-metrics 暴露对象状态、node-exporter 采集节点指标、Alertmanager 告警）；日志用 EFK（Elasticsearch/Fluentd/Kibana）或 Loki 按命名空间与标签聚合；链路追踪用 OpenTelemetry 采集、Jaeger/Tempo 存储。日常排障先跑 kubectl top node/pod 看资源水位，再用 kubectl get events --sort-by=.lastTimestamp 与 kubectl describe 定位事件，最后进入容器用 kubectl logs -f 确认应用层问题。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>版本与 API 兼容：Kubernetes 每个 minor 版本都会清理已弃用 API，升级前不检查 deprecated API 列表，存量 YAML 会在升级后 apply 失败，建议用 kubectl convert 或官方迁移文档先行转换。</li><li>不设 requests/limits：未声明资源上限的 Pod 可能打爆节点引发 CPU 节流与 OOMKilled，生产命名空间必须用 LimitRange 与 ResourceQuota 兜底。</li><li>漏配 readiness 探针：滚动更新时 Service 可能把流量打进未就绪的新 Pod，造成请求 502；探针与 minReadySeconds 应作为发布流程的强制项。</li><li>自建集群用 LoadBalancer 类型却不部署实现组件：没有云负载均衡或 MetalLB 这类方案时 Service 的 external-ip 会一直 Pending，排查时先确认集群是否具备 LoadBalancer 提供能力。</li></ul>

版本迭代

Kubernetes 自 2015 年 v1.0 以来保持一年 3 个 minor 版本的节奏（约 4 月、8 月、12 月），每个版本通常包含数十项特性增强与 API 调整。版本演进主线是从“跑起来”走向“工程化”：v1.29 完成云厂商代码剥离，v1.30 将原地调整 Pod 资源的 beta 能力落地，v1.31 起安全相关特性（如 AppArmor）转正，v1.32 完成工具链升级，v1.33 持续推进稳定化。官方维护最近 3 个 minor 版本，约为 14 个月支持窗口。

AI 应用场景

常见误区

面试题

参考来源

• webpageCKA 官方认证官方认证考试与学习路径