Kubernetes（简称K8s，“8”代表“Kubernetes”中“K”和“s”之间的8个字母）是目前全球最主流的容器编排平台，由Google基于其内部多年运行容器集群的经验（Borg系统）开源，后捐赠给Cloud Native Computing Foundation（CNCF）并成为其旗舰项目。它的核心价值是“自动化容器的部署、扩展、管理与运维”，相当于为容器化应用搭建了一套“分布式操作系统”，让开发者和运维人员能更高效地管理大规模容器集群。

一、K8s的核心定位与解决的问题

在理解K8s之前，需先明确其“为何存在”——它是为解决容器化应用在大规模部署时的痛点而生。当应用从“单体架构”拆分为“微服务架构”，并通过Docker等工具打包为容器后，会面临一系列新问题：

• 如何同时管理成百上千个容器，确保它们正常运行？
• 如何在容器故障时自动重启，避免服务中断？
• 如何根据流量波动（如秒杀、高峰期）自动增加/减少容器数量？
• 如何实现容器间的网络通信、数据存储共享？
• 如何滚动更新容器版本，避免更新过程中服务 downtime？

K8s的出现正是为了统一解决这些问题，它通过标准化的流程和接口，将“零散的容器”组织成“可管理、高可用、可扩展”的集群，让应用部署从“手动操作”升级为“自动化编排”。

二、K8s的核心架构：Master与Node的“主从模式”

K8s集群采用主从架构（Master-Slave） ，分为“控制平面（Control Plane，即Master节点）”和“工作节点（Worker Node）”两部分，各司其职且相互协作。

1. 控制平面（Control Plane）：集群的“大脑”

控制平面负责决策集群的整体状态（如“哪个容器该运行在哪里”“是否需要扩容”），通常部署在独立的服务器上（生产环境中需多节点高可用部署，避免单点故障），包含以下核心组件：

组件名称	核心功能	通俗理解
kube-apiserver	集群的“统一入口”，所有操作（如创建容器、扩容）都通过API请求实现；同时负责权限验证、请求转发	集群的“前台接待员”，所有指令必须经过它
etcd	分布式键值数据库，存储集群的所有配置信息（如Pod定义、服务规则），是集群的“数据中心”	集群的“账本”，所有关键信息都记在这里
kube-scheduler	负责“调度容器”：当用户创建容器时，它会根据节点资源（CPU、内存）、亲和性规则等，选择最合适的Worker Node运行容器	集群的“调度员”，决定“谁该坐哪辆车”
kube-controller-manager	运行各类“控制器”，确保集群状态与用户期望一致（如“容器故障后自动重启”“副本数不足时自动扩容”）	集群的“运维管家”，时刻监控并修复异常
cloud-controller-manager	（可选）对接云厂商（如AWS、阿里云、华为云）的API，实现“云资源联动”（如自动创建负载均衡、存储卷）	集群与云厂商的“桥梁”

2. 工作节点（Worker Node）：集群的“手脚”

工作节点是实际运行容器的服务器，接收控制平面的指令并执行，包含以下核心组件：

组件名称	核心功能	通俗理解
kubelet	与控制平面的kube-apiserver通信，执行具体指令（如启动/停止容器、挂载存储卷）；同时监控容器状态，向控制平面汇报	工作节点的“执行者”，听指挥、做实事
kube-proxy	维护节点的网络规则，实现“容器间通信”和“外部访问容器”（如Service的负载均衡）；本质是一个网络代理	工作节点的“网络管理员”，负责流量转发
容器运行时（Container Runtime）	实际运行容器的软件，如Docker、containerd、CRI-O等；K8s通过CRI（Container Runtime Interface）接口与它交互，解耦了“编排逻辑”和“容器运行逻辑”	工作节点的“容器引擎”，负责把容器跑起来

三、K8s的核心资源对象：理解“编排的最小单位”

K8s通过“资源对象”来定义集群的“期望状态”（如“我要运行3个nginx容器”“这些容器需要1G内存”），控制平面会持续监控这些对象，确保实际状态与期望一致。以下是最常用的核心资源：

1. Pod：K8s的“最小部署单位”

• 定义：Pod是K8s中最小的、可部署的计算单元，一个Pod包含一个或多个紧密关联的容器（如“应用容器+日志收集容器”）。
• 特点：
  • 所有容器共享Pod的网络命名空间（即同一Pod内的容器可通过localhost通信）和存储卷（可共享文件）。
  • Pod是“短暂的”：一旦Pod被删除或节点故障，它不会自动恢复，需通过“控制器”管理。
• 示例场景：一个Web应用容器+一个Sidecar容器（负责收集该Web应用的日志），两者必须在同一节点运行且共享日志文件，此时适合打包为一个Pod。

2. Controller（控制器）：管理Pod的“自动化工具”

控制器的核心作用是“确保Pod的数量和状态符合期望”，避免手动管理Pod的繁琐。常用控制器包括：

• Deployment：最常用的控制器，用于管理“无状态应用”（如Web服务、API服务），支持滚动更新（逐步替换旧Pod，避免服务中断）、回滚（更新失败时恢复到上一版本）、扩容缩容（手动或自动调整Pod数量）。
  • 示例：通过Deployment定义“运行3个nginx Pod，每个Pod使用nginx:1.21镜像”，K8s会自动创建3个Pod，并在Pod故障时重启。
• StatefulSet：用于管理“有状态应用”（如数据库、Redis集群），特点是“每个Pod有固定的名称、网络标识和存储”（如数据库Pod重启后仍使用原来的存储卷，避免数据丢失）。
• DaemonSet：确保“所有（或指定）Worker Node上都运行一个相同的Pod”，常用于部署“节点级工具”（如日志收集组件Fluentd、监控组件Prometheus Node Exporter）。
• Job/CronJob：用于运行“一次性任务”（Job，如数据备份）或“定时任务”（CronJob，如每天凌晨2点执行数据库备份），任务完成后Pod自动停止。

3. Service：Pod的“网络入口”

• 问题背景：Pod是短暂的（IP会变化），如果直接通过Pod的IP访问应用，Pod重启后IP改变会导致访问失败。
• Service的作用：为一组“功能相同的Pod”（如Deployment管理的3个nginx Pod）提供一个固定的访问地址（ClusterIP） ，并实现负载均衡（请求自动分发到不同Pod）。
• 常用类型：
  • ClusterIP：仅集群内部可访问（默认类型），适合内部服务间通信。
  • NodePort：在每个Worker Node上开放一个固定端口，外部通过“NodeIP:NodePort”访问，适合测试环境。
  • LoadBalancer：对接云厂商的负载均衡服务（如阿里云SLB、AWS ELB），外部通过负载均衡器的IP访问，适合生产环境。
  • ExternalName：将Service映射到外部域名（如“service-a”映射到“www.example.com”），适合访问集群外服务。

4. Ingress：管理“外部访问规则”

• 问题背景：如果用Service的LoadBalancer类型暴露多个应用，每个应用需要一个独立的负载均衡器，成本高且管理繁琐。
• Ingress的作用：作为集群的“入口网关”，通过一条公网IP和一套规则，将外部请求根据“域名”或“路径”转发到不同的Service（如“www.abc.com”转发到前端Service，“api.abc.com”转发到后端Service）。
• 注意：Ingress本身只是“规则定义”，需要“Ingress Controller”（如Nginx Ingress Controller、Traefik）来实际执行这些规则（本质是一个运行在集群中的反向代理）。

5. Volume：Pod的“持久化存储”

• 问题背景：容器内的存储是“临时的”（容器删除后数据丢失），而应用（如数据库）需要持久化存储数据。
• Volume的作用：为Pod提供“外部存储空间”，可挂载到Pod内的一个或多个容器中，支持多种存储类型：
  • 本地存储：emptyDir（Pod内临时存储，Pod删除后消失）、hostPath（挂载节点的本地目录，适合测试）。
  • 网络存储：PersistentVolumeClaim（PVC）（通过“声明”申请集群中的“持久化存储卷（PV）”，如阿里云云盘、AWS EBS，适合生产环境）。

四、K8s的核心能力：为什么它成为行业标准？

K8s的流行并非偶然，而是源于其强大且全面的核心能力，覆盖了容器生命周期的全流程：

1. 高可用性（High Availability）

• Pod自愈：控制器（如Deployment）会监控Pod状态，若Pod故障（如容器崩溃、节点宕机），会自动在其他节点重建Pod。
• 控制平面高可用：通过多Master节点部署（如3个Master节点），etcd采用集群模式（至少3个节点），避免单点故障。
• 服务可用性：Service的负载均衡和Ingress的请求转发，确保即使部分Pod故障，服务仍能正常响应。

2. 弹性伸缩（Scalability）

• 手动伸缩：通过kubectl scale命令或K8s Dashboard，手动调整Deployment/StatefulSet的Pod副本数（如从3个扩到5个）。
• 自动伸缩（HPA）：Horizontal Pod Autoscaler根据“CPU使用率”“内存使用率”或“自定义指标（如请求QPS）”，自动调整Pod数量（如CPU使用率超过70%时扩容，低于30%时缩容）。
• 集群伸缩（Cluster Autoscaler）：对接云厂商时，若集群内所有节点资源不足，会自动创建新的Worker Node；若节点长期空闲，会自动删除节点，实现“资源按需分配”。

3. 滚动更新与回滚（Rolling Update & Rollback）

• 滚动更新：Deployment默认采用滚动更新策略，每次删除一个旧Pod、创建一个新Pod，逐步替换所有Pod（可配置“最大不可用数”和“最大新增数”），确保更新过程中服务不中断。
• 版本回滚：若更新后出现问题（如应用BUG），可通过kubectl rollout undo命令快速回滚到上一版本的Pod，降低故障影响。

4. 服务发现与负载均衡

• 服务发现：通过Service的固定ClusterIP，集群内的应用无需关注Pod的IP变化，直接通过Service名称访问（依赖K8s内置的DNS服务CoreDNS）。
• 负载均衡：Service会将请求均匀分发到后端的多个Pod，Ingress则实现了更细粒度的HTTP/HTTPS层负载均衡（如按路径、域名转发）。

5. 持久化存储与配置管理

• 持久化存储：通过PV/PVC机制，应用可“声明式”申请存储资源，无需关心存储的具体实现（如本地盘、云盘），实现“存储与计算解耦”。
• 配置管理：
  • ConfigMap：存储“非敏感配置信息”（如应用的配置文件、环境变量），可挂载到Pod中，修改ConfigMap后无需重建Pod即可生效。
  • Secret：存储“敏感信息”（如数据库密码、API密钥），数据会被Base64编码（注意：默认并非加密，生产环境需结合加密插件如Vault）。

五、K8s的应用场景：哪些场景适合用K8s？

K8s并非“万能工具”，其优势在大规模、分布式、微服务架构的场景中最能体现，主要应用场景包括：

1. 微服务部署与管理：微服务架构下，应用被拆分为多个独立服务，每个服务可通过K8s的Deployment/Service独立部署、扩容、更新，降低服务间的耦合。
2. 持续集成/持续部署（CI/CD）：K8s可与Jenkins、GitLab CI、Argo CD等工具集成，实现“代码提交→自动构建镜像→自动部署到K8s集群”的全流程自动化，缩短迭代周期。
3. 大规模数据处理：如Spark、Flink等大数据框架的任务，可通过K8s的Job/CronJob管理，实现任务的自动调度、资源隔离和弹性伸缩。
4. 云原生应用开发：K8s是云原生应用的“标准运行环境”，支持“容器化、可观测性、弹性伸缩”等云原生特性，帮助应用更好地适配公有云、私有云、混合云环境。
5. 高可用业务系统：对可用性要求高的业务（如电商、金融交易），可通过K8s的高可用架构、自愈能力、滚动更新，确保服务99.9%以上的可用性。

六、K8s的生态系统：丰富的工具链支撑

K8s的强大不仅在于其本身，更在于其围绕CNCF构建的庞大生态系统，覆盖了“部署、监控、日志、安全、CI/CD”等全流程工具：

领域	代表性工具
容器运行时	Docker、containerd、CRI-O
网络	Calico、Flannel（容器网络插件）、Nginx Ingress、Traefik（Ingress Controller）
存储	Rook（分布式存储）、GlusterFS、Ceph（开源存储）、云厂商存储（阿里云云盘、AWS EBS）
部署与管理	kubectl（命令行工具）、K8s Dashboard（Web界面）、Helm（包管理工具）、Argo CD（GitOps部署）
监控与可观测	Prometheus（指标监控）、Grafana（可视化）、ELK Stack（日志收集：Elasticsearch+Logstash+Kibana）、Jaeger（链路追踪）
安全	Istio（服务网格，负责流量加密、身份认证）、Vault（密钥管理）、Falco（运行时安全监控）

版权所有

许可证：署名 4.0 国际 (CC-BY-4.0)