Kubernetes 完整介绍
Kubernetes（简称 K8s，因中间省略 8 个字母而得名）是一个开源的容器编排平台，用于自动化容器化应用的部署、扩缩容和管理。它最初由 Google 基于内部系统 Borg 的经验设计，2014 年开源，现由 CNCF（Cloud Native Computing Foundation）托管，是云原生生态的事实标准。
1. 为什么需要 Kubernetes
在容器化之前，应用部署面临环境不一致、资源利用率低、扩容困难等问题。Docker 解决了"打包和运行单个容器"的问题，但当容器数量达到数十、上百个，分布在多台机器上时，会出现新的挑战：
- 容器调度到哪台机器上？
- 容器挂了怎么自动重启？
- 如何在不停机的情况下发布新版本？
- 服务之间如何发现彼此？
- 如何根据负载自动扩缩容？
Kubernetes 就是为解决这些"容器编排"问题而生的系统。
2. 核心设计理念
Kubernetes 的核心是声明式 API + 控制器模式：
- 用户通过 YAML/JSON 描述"期望状态"（Desired State），例如"我要 3 个副本的 Nginx"。
- Kubernetes 的控制器（Controller）持续观察集群的"实际状态"（Current State），并不断调整使其趋近期望状态。
- 这种"调谐循环"（Reconciliation Loop）是 K8s 几乎所有组件的工作方式。
期望状态 (etcd 中存储) ──> Controller 观察差异 ──> 执行动作 ──> 实际状态趋近期望状态
▲ │
└────────────────────── 持续循环 ───────────────────────────┘3. 整体架构
一个 Kubernetes 集群由 控制平面（Control Plane） 和 工作节点（Worker Node） 组成。
┌─────────────────────────── Control Plane ───────────────────────────┐
│ │
│ kube-apiserver kube-scheduler kube-controller-manager │
│ │ │ │
│ └──────────────┬─────────────────────┘ │
│ │ │
│ etcd (集群状态存储) │
│ │
└──────────────────────────┬──────────────────────────────────────────┘
│ (API 通信)
┌───────────────────┼───────────────────┐
│ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ Worker Node1 │ │ Worker Node2 │ │ Worker Node3 │
│ kubelet │ │ kubelet │ │ kubelet │
│ kube-proxy │ │ kube-proxy │ │ kube-proxy │
│ 容器运行时 │ │ 容器运行时 │ │ 容器运行时 │
│ (containerd) │ │ (containerd) │ │ (containerd) │
│ Pod Pod Pod │ │ Pod Pod │ │ Pod Pod Pod │
└────────────────┘ └────────────────┘ └────────────────┘3.1 控制平面组件
| 组件 | 作用 |
|---|---|
kube-apiserver | 集群唯一入口，提供 REST API，所有组件都通过它读写集群状态 |
etcd | 分布式键值存储，保存集群的全部配置和状态数据 |
kube-scheduler | 为新创建的 Pod 选择合适的 Node（基于资源、亲和性、污点容忍等） |
kube-controller-manager | 运行各类控制器（Node、Deployment、Job 等），驱动集群趋向期望状态 |
cloud-controller-manager | 对接云厂商 API（负载均衡器、存储卷、路由等），云环境专用 |
3.2 工作节点组件
| 组件 | 作用 |
|---|---|
kubelet | 运行在每个 Node 上，负责与 apiserver 通信，管理本节点上 Pod 的生命周期 |
kube-proxy | 维护节点网络规则，实现 Service 的负载均衡和转发 |
| 容器运行时（Container Runtime） | 实际运行容器，如 containerd、CRI-O（Docker Engine 已不再直接支持，改用 cri-dockerd 适配） |
4. 核心资源对象
4.1 Pod —— 最小调度单元
Pod 是 K8s 中可以创建和管理的最小部署单元，包含一个或多个共享网络/存储的容器。Pod 本身不具备自愈能力，通常不会直接创建 Pod，而是通过更高层的控制器管理。
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 804.2 Deployment —— 无状态应用管理
Deployment 管理 Pod 的多副本、滚动更新和回滚，是最常用的工作负载资源。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0Deployment 内部通过 ReplicaSet 管理具体的 Pod 副本数量；升级新版本时会创建新的 ReplicaSet，逐步扩容新版本、缩容旧版本，实现滚动更新。
4.3 StatefulSet —— 有状态应用管理
用于需要稳定网络标识、稳定存储、有序部署/扩缩容的应用（如数据库、消息队列）。每个 Pod 拥有固定序号的名称（如 mysql-0、mysql-1）和独立的持久卷。
4.4 DaemonSet —— 每节点一份
确保集群中每个（或指定的）Node 上运行一个 Pod 副本，典型用途：日志采集（Fluentd）、监控代理（node-exporter）、网络插件（CNI）。
4.5 Job / CronJob —— 批处理任务
Job：运行一次性任务直到成功完成。CronJob：按 Cron 表达式周期性创建 Job，用于定时任务。
4.6 Service —— 服务发现与负载均衡
Pod 的 IP 是动态的，Service 提供一个稳定的虚拟 IP（ClusterIP）和 DNS 名称，将流量负载均衡到匹配的 Pod 集合。
| 类型 | 说明 |
|---|---|
ClusterIP（默认） | 仅集群内部可访问 |
NodePort | 在每个 Node 上开放固定端口，从集群外部可访问 |
LoadBalancer | 对接云厂商负载均衡器，分配公网 IP |
ExternalName | 将 Service 映射到外部 DNS 名称，不做代理 |
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
type: ClusterIP4.7 Ingress —— 七层路由
Ingress 在 Service 之上提供基于域名/路径的 HTTP(S) 路由和 TLS 终止，需要集群安装 Ingress Controller（如 nginx-ingress、Traefik）才能生效。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo-ingress
spec:
rules:
- host: demo.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 804.8 ConfigMap / Secret —— 配置与敏感信息
ConfigMap：以键值对形式存储非敏感配置，可挂载为环境变量或文件。Secret：结构与 ConfigMap 类似，但用于存储密码、Token、证书等敏感数据（默认仅 Base64 编码，非加密，生产环境需配合 KMS 或外部密钥管理）。
4.9 PersistentVolume / PersistentVolumeClaim —— 持久化存储
PV（PersistentVolume）：集群管理员或存储驱动提供的实际存储资源。PVC（PersistentVolumeClaim）：用户对存储的申请，K8s 自动绑定符合条件的 PV。StorageClass：定义动态供应存储的模板，实现 PVC 自动创建对应 PV。
4.10 Namespace —— 资源隔离
将集群资源划分为多个虚拟隔离的逻辑分区，常用于多团队、多环境（dev/staging/prod）的资源隔离和权限控制（配合 RBAC）。
5. 网络模型
Kubernetes 网络遵循几条基本原则：
- 所有 Pod 之间可以直接通信，无需 NAT。
- 所有 Node 与所有 Pod 之间可以直接通信，无需 NAT。
- Pod 看到自己的 IP 与其他人看到的一致。
这套模型由 CNI（Container Network Interface） 插件实现，常见方案有 Calico、Flannel、Cilium 等，分别在性能、网络策略支持、eBPF 加速等方面各有侧重。
6. 调度与资源管理
- 资源请求与限制（
requests/limits）：声明容器所需的 CPU/内存下限和上限，调度器依据requests决定节点是否有足够资源容纳 Pod。 - 亲和性/反亲和性（Affinity/Anti-Affinity）：控制 Pod 倾向或避免与特定 Pod/Node 共存。
- 污点与容忍（Taints/Tolerations）：Node 打上"污点"拒绝不能容忍该污点的 Pod 调度上来，常用于隔离专用节点（如 GPU 节点）。
- HPA（Horizontal Pod Autoscaler）：基于 CPU/内存或自定义指标自动调整 Deployment 副本数。
- VPA / Cluster Autoscaler：分别对单个 Pod 资源配额和集群节点数量做自动伸缩。
7. 声明式管理与 kubectl
日常操作以 kubectl 命令行工具为主，核心是对 YAML 清单的增删改查：
kubectl apply -f deployment.yaml # 创建/更新资源（声明式，推荐）
kubectl get pods -n default # 查看 Pod 列表
kubectl describe pod <pod-name> # 查看详细事件和状态
kubectl logs -f <pod-name> # 查看容器日志
kubectl exec -it <pod-name> -- bash # 进入容器
kubectl rollout status deployment/nginx-deployment # 查看滚动更新进度
kubectl rollout undo deployment/nginx-deployment # 回滚到上一版本
kubectl scale deployment/nginx-deployment --replicas=5 # 手动扩缩容8. 生态与延伸工具
| 领域 | 常用工具 |
|---|---|
| 包管理 | Helm（K8s 的"包管理器"，用 Chart 打包一组资源） |
| GitOps | ArgoCD、Flux（以 Git 仓库作为集群状态的唯一真源） |
| 服务网格 | Istio、Linkerd（流量治理、可观测性、mTLS） |
| 监控告警 | Prometheus + Grafana |
| 日志 | EFK/ELK（Elasticsearch + Fluentd/Logstash + Kibana）、Loki |
| CI/CD | Jenkins、GitLab CI、Tekton |
| 本地开发/测试集群 | kind、minikube、k3d |
9. 学习路径建议
- 用
minikube或kind在本地跑起一个单节点集群，动手实践 Pod / Deployment / Service。 - 理解声明式 API 和调谐循环的思想，而不只是背命令。
- 逐步深入网络（CNI）、存储（CSI）、调度、RBAC 等子系统。
- 学习 Helm 打包和 GitOps 部署流程，贴近生产实践。
- 结合可观测性体系（Prometheus/Grafana/日志）建立完整的运维闭环。
10. 小结
Kubernetes 的本质是一个通用的、声明式的分布式系统控制平面：用户描述期望状态，一组控制器持续观察并调谐集群，使其不断逼近这个状态。理解了这一核心思想，再去看 Pod、Deployment、Service 等具体资源，会发现它们都只是这套"控制器模式"在不同场景下的具体实现。