什么是Kubernetes？当今最流行的容器编排平台

当系统中的容器数量从几个增长到数百、数千个时，手动管理变得无法实现。Kubernetes正是为解决这个问题而生——在整个服务器集群中自动调度、扩缩容和恢复容器，无需人工逐步干预。本文将解释什么是Kubernetes、其架构如何运作，以及何时真正需要使用它。

什么是Kubernetes？

Kubernetes（即K8s——因为K和s之间有8个字母而得名）是一个用于容器编排（container orchestration）的开源平台，即在多台服务器组成的集群上自动部署、扩缩容和管理容器的生命周期。它由Google基于内部的Borg系统开发，于2014年开源，并移交给云原生计算基金会（CNCF）管理。

可以将Kubernetes想象成容器乐团的指挥。每件乐器（容器）都了解自己的部分，但需要指挥来分配谁在何时演奏、替换生病的乐手，并确保整个乐团节奏协调。Kubernetes正是这样做的：将容器分配到哪个节点、在容器崩溃时重启它、在负载增加时增加副本数量。

Kubernetes解决的问题

当你只有一个小型应用时，Docker完全够用。但对于包含数十个服务的微服务架构，每个服务在多台服务器上运行多个副本，你会立即遇到以下问题：

• 手动调度：哪个服务运行在哪台机器上？哪台机器还有资源？手动操作极其耗时。
• 缺乏自我修复：凌晨3点容器崩溃了——谁来重启？Kubernetes会自动完成这件事。
• 扩容复杂：流量突然增加，需要立即从2个副本扩展到10个——无法逐台SSH登录机器操作。
• 滚动更新风险：在不停机的情况下部署新版本需要复杂的策略。
• 服务发现：容器A需要调用容器B——每次重启后IP都在变化，如何知道地址？

Kubernetes通过一套声明式API（declarative API）解决了所有这些问题：你描述期望的状态，K8s负责将系统调整到该状态并持续维持它。

Kubernetes架构

一个Kubernetes集群由两个主要层次组成：控制平面（Control Plane）和工作节点（Worker Node）。

控制平面

控制平面是集群的大脑，包含：

• API Server：与集群所有交互的唯一入口。所有kubectl命令、webhook或CI/CD流水线都通过这里调用。
• etcd：存储整个集群状态的分布式键值数据库。这是最重要的组件——失去etcd就失去了集群。
• Scheduler：根据可用资源、亲和性规则和优先级决定新Pod将运行在哪个工作节点上。
• Controller Manager：持续比较当前状态与期望状态并执行必要操作的控制循环集合（重启崩溃的Pod、扩容时创建新Pod等）。

工作节点

工作节点是实际运行容器的服务器，包含：

• kubelet：运行在每个节点上的代理，接收来自API Server的指令并确保容器按规范运行。
• kube-proxy：处理网络，根据Service规则将流量路由到正确的Pod。
• 容器运行时：实际运行容器的组件（containerd、CRI-O——不一定是Docker）。

核心概念

Pod

Pod是Kubernetes中最小的部署单元。每个Pod包含一个或多个共享同一IP地址、网络命名空间和存储卷的容器。实际上，90%的Pod只有一个容器。Kubernetes不直接管理容器——它始终通过Pod进行操作。

Deployment

Deployment是声明Pod需要运行的副本数量以及如何更新它们的对象。当你部署新版本时，Deployment执行滚动更新——逐步用新Pod替换旧Pod，确保零停机。如果新版本出现故障，kubectl rollout undo可立即回滚。

Service

Service为一组Pod提供稳定的IP地址和DNS名称，即使Pod重启或更换IP，Service地址也不会改变。主要有三种类型：ClusterIP（集群内部）、NodePort（在节点上开放端口）、LoadBalancer（集成云的负载均衡器）。

Ingress

Ingress是从外部到集群的HTTP/HTTPS路由层，支持虚拟主机和基于路径的路由。例如：api.example.com/users → 服务A，api.example.com/orders → 服务B，全部通过单一入口点。

Namespace

Namespace是集群内部的逻辑分区机制，用于分隔环境（开发、预发布、生产）或在同一物理集群中分隔团队。

自动化：扩缩容、更新、自我修复

自动扩缩容

Kubernetes提供三个级别的自动扩缩容：

• HPA（Horizontal Pod Autoscaler）：根据CPU、内存或自定义指标增减Pod数量。
• VPA（Vertical Pod Autoscaler）：自动调整Pod的CPU/内存请求量。
• Cluster Autoscaler：当集群需要更多或更少资源时自动添加/删除物理节点（与GKE、EKS、AKS集成）。

滚动更新与回滚

1# 更新Deployment的镜像
2kubectl set image deployment/my-app app=my-app:v2.1.0
3
4# 监控滚动更新进度
5kubectl rollout status deployment/my-app
6
7# 出现错误时回滚到上一版本
8kubectl rollout undo deployment/my-app

自我修复

Controller Manager持续检查：如果一个Pod崩溃，它会立即在有可用资源的节点上创建替代Pod。如果整个节点宕机，该节点上的所有Pod都会被重新调度到其他节点——自动完成，无需人工干预。

工具：kubectl和Helm

kubectl

kubectl是与集群交互的主要CLI工具。以下是声明简单Deployment的YAML manifest示例：

 1apiVersion: apps/v1
 2kind: Deployment
 3metadata:
 4  name: my-app
 5  namespace: production
 6spec:
 7  replicas: 3
 8  selector:
 9    matchLabels:
10      app: my-app
11  template:
12    metadata:
13      labels:
14        app: my-app
15    spec:
16      containers:
17        - name: app
18          image: my-app:v2.1.0
19          ports:
20            - containerPort: 8080
21          resources:
22            requests:
23              cpu: "100m"
24              memory: "128Mi"
25            limits:
26              cpu: "500m"
27              memory: "256Mi"
28          readinessProbe:
29            httpGet:
30              path: /healthz
31              port: 8080
32            initialDelaySeconds: 5
33            periodSeconds: 10

应用manifest：

1kubectl apply -f deployment.yaml
2kubectl get pods -n production
3kubectl describe pod <pod-name> -n production

Helm——Kubernetes的包管理器

Helm是Kubernetes的包管理工具（称为chart），类似于Node.js的npm。与其编写数十个独立的YAML文件，不如使用Helm将其打包成可参数化、可复用的chart。一个Helm chart包含带有变量的YAML模板，变量通过values.yaml文件填充，使得同一个chart只需替换values.yaml就能部署到开发、预发布和生产环境。

 1# 通过Helm安装nginx-ingress
 2helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 3helm install ingress-nginx ingress-nginx/ingress-nginx \
 4  --namespace ingress-nginx \
 5  --create-namespace
 6
 7# 为生产环境覆盖默认值
 8helm upgrade --install my-app ./chart \
 9  -f values.production.yaml \
10  --namespace production

Helm还保存发布历史，允许使用helm rollback my-app 1回滚到上一版本——类似于kubectl rollout undo，但适用于包含多个资源的整个技术栈。将Helm与CI/CD流水线结合使用，是在生产环境中自动化部署到Kubernetes的最常见方式。

ConfigMap与Secret

这两个对象将配置与容器镜像分离。ConfigMap存储非敏感配置（数据库主机、功能标志）；Secret以base64编码形式存储敏感数据（密码、API密钥）。两者都通过环境变量或卷挂载注入到Pod中，使同一镜像无需重新构建即可在多个不同环境中运行。

对比：托管K8s与自托管

何时需要Kubernetes——以及何时是过度设计

适合使用Kubernetes的情况：

• 系统有5个以上需要独立部署的微服务。
• 需要根据实际负载进行自动扩缩容（例如：夜间流量突然增加）。
• 要求零停机部署和快速回滚。
• DevOps团队已具备集群运维经验。
• 基础设施部署在支持托管K8s的云服务器上。

Kubernetes是过度设计的情况：

• 处于早期阶段、只有1-3个服务的初创项目。
• 团队规模小，没有专职的K8s运维人员。
• 流量低且稳定，不需要自动扩缩容。
• 预算有限——集群的开销（至少3个节点）比单台VPS更昂贵。

对于小型项目，Docker Compose或简单的CI/CD流水线部署到VPS就已足够。Kubernetes是强大的工具，但伴随着高度复杂性——只有在真正需要时才值得投入。

结论： Kubernetes解决了大规模容器编排问题，目前没有任何工具能做得更好。深入理解控制平面架构、Pod/Deployment/Service等核心概念，并了解何时应该使用它，将帮助你做出正确的决策——而不是仅仅因为它流行就将K8s应用于每个项目。

常见问题