Kubernetes 是什么？K8s 核心原理、常用命令与部署教程
一、Kubernetes 是什么？
Kubernetes，简称 K8s，是一个开源的容器编排平台，用于自动化部署、扩缩容、管理和维护容器化应用。
当一个应用只需要运行一个容器时，使用 Docker 就可以完成基本的部署工作。但当应用发展到几十个、几百个甚至更多容器时，就会出现容器调度、服务发现、负载均衡、故障恢复、资源分配和版本更新等复杂问题。
Kubernetes 正是为了解决这些问题而设计的。
例如，一个在线商城可能包含以下服务：
- 前端 Web 服务：负责展示商品和用户界面。
- 后端 API 服务：处理用户请求和业务逻辑。
- MySQL 数据库：保存用户、订单和商品数据。
- Redis 缓存：提高数据访问效率。
- 消息队列：处理异步任务和消息传递。
如果这些服务全部运行在容器中，就需要考虑容器应该部署在哪台服务器上、服务器故障后如何恢复、流量增加时如何扩容，以及如何在更新应用时尽量避免服务中断。
Kubernetes 可以根据预先声明的配置，自动调度工作负载、维护目标副本数量，并通过服务发现和相关控制机制帮助应用保持在期望状态。
简单来说，Docker 主要解决容器如何构建和运行的问题，而 Kubernetes 主要解决大量容器化应用如何在集群中部署和管理的问题。
Kubernetes 官方文档： https://kubernetes.io/zh-cn/docs/home/
Kubernetes 主要解决什么问题？
问题 | Kubernetes 提供的能力 |
|---|---|
应用部署复杂 | 通过声明式配置管理应用部署 |
容器分布在多台服务器 | 根据资源需求和调度规则安排工作负载 |
容器发生故障 | 通过控制器协调工作负载，尝试恢复期望状态 |
访问地址难以管理 | 通过 Service 提供稳定的服务访问入口 |
访问流量不断变化 | 可以结合副本扩缩容和负载均衡机制应对流量变化 |
应用更新容易影响服务 | 支持滚动更新和版本回滚等操作 |
资源使用不合理 | 可以设置资源请求、限制及调度约束 |
多个团队共享集群 | 可以通过 Namespace、RBAC 等机制组织和管理资源 |
需要注意，Kubernetes 提供的是容器化应用的编排与管理能力，并不能自动解决所有业务问题。应用本身的健壮性、数据库高可用、数据备份、网络架构和监控告警仍然需要合理设计。
二、Kubernetes 与 K8s 有什么区别？
Kubernetes 和 K8s 指的是同一个项目，没有功能上的区别。
Kubernetes 这个名称来源于希腊语，含义与舵手或领航者有关。
K8s 是一种常见的缩写方式：K 和 s 之间省略了 8 个字母，因此得到 K8s。
在技术文档和开发交流中，经常会看到以下表达：
- Kubernetes 集群：由控制平面和工作节点等组成的集群。
- K8s 部署：将应用部署到 Kubernetes 环境中。
- K8s 运维：负责集群、应用、资源和故障管理的工作。
- K8s YAML：用于描述 Kubernetes 资源的 YAML 配置文件。
这些表达通常都指向 Kubernetes 相关技术。
三、Kubernetes 的核心架构
Kubernetes 集群通常由两大部分组成：控制平面（Control Plane）和工作节点（Worker Node）。
控制平面负责维护集群的整体状态、处理 API 请求和调度工作负载；工作节点负责运行具体的应用容器。
<escape> Kubernetes 集群 │ ┌────────────┴────────────┐ │ │ 控制平面 Control Plane 工作节点 Worker Nodes │ │ ┌──────┼──────┐ ┌───────┴────────┐ │ │ │ │ │ API Scheduler Controller Node 1 Node 2 Server Manager │ │ │ Pod Pod etcd 数据库 应用容器 应用容器 </escape>
上图展示的是简化的逻辑结构。实际集群中，控制平面组件可以部署在多台机器上，工作节点的数量也可以根据业务需求调整。
1. 控制平面（Control Plane）
控制平面负责管理 Kubernetes 集群，是整个系统的管理中枢。
主要组件包括：
kube-apiserver
API Server 是 Kubernetes 的主要 API 入口。
用户通过 kubectl 提交命令，控制器和其他组件也通过 Kubernetes API 交互。API Server 负责接收请求、执行认证和授权，并在适用时进行准入控制及资源校验。
例如，当用户提交一个 Deployment 配置时，API Server 会处理这个资源对象的创建请求。
etcd
etcd 是一个分布式键值存储系统，用于保存 Kubernetes 集群的重要状态数据。
例如，集群中的资源对象、配置和状态信息等，都需要通过 Kubernetes 的存储机制进行管理。
etcd 对集群正常运行非常重要，因此生产环境需要重视其备份、恢复和高可用设计。
kube-scheduler
Scheduler 是调度器，负责为尚未分配节点的 Pod 选择合适的工作节点。
调度时可以考虑：
- 节点可用资源。
- Pod 的 CPU 和内存资源请求。
- 节点选择器和亲和性规则。
- 污点与容忍度。
- 拓扑分布等调度约束。
Scheduler 负责选择节点，但通常不会亲自启动容器。实际运行工作由目标节点上的相关组件完成。
kube-controller-manager
Controller Manager 运行多个控制器，持续观察集群的实际状态，并尝试使其接近用户声明的期望状态。
例如，如果一个 Deployment 希望运行三个 Pod，但当前只有两个符合要求的 Pod，相关控制器会尝试创建新的 Pod。
这种持续协调的机制是 Kubernetes 自动化管理能力的重要基础。
2. 工作节点（Worker Node）
工作节点是实际运行应用工作负载的机器，可以是物理服务器，也可以是虚拟机。
kubelet
kubelet 是运行在节点上的主要代理组件，负责根据 Kubernetes 的工作负载配置，与容器运行时协作，确保分配给该节点的 Pod 按预期运行，并向控制平面报告相关状态。
容器运行时（Container Runtime）
容器运行时负责实际运行容器。
Kubernetes 通过容器运行时接口 CRI 与受支持的运行时进行交互。常见的运行时包括 containerd 和 CRI-O。
需要注意，Kubernetes 并不要求所有容器都必须由 Docker Engine 直接运行。Docker 构建的 OCI 兼容镜像通常可以在支持相应镜像格式的容器运行时中使用。
kube-proxy
kube-proxy 在许多 Kubernetes 集群中负责实现 Service 的部分网络转发功能，例如维护相关网络规则。
不过，某些集群网络实现可以使用其他机制替代 kube-proxy，因此它不是所有集群部署中都必须存在的独立组件。
网络与存储插件
实际集群还通常需要网络和存储相关组件：
- CNI 网络插件：为 Pod 网络连接提供相应能力。
- CSI 存储插件：为 Kubernetes 对接各种持久化存储系统。
- 监控和日志组件：用于采集指标、日志并排查故障。
这些插件并非全部属于 Kubernetes 核心组件，但对生产环境通常十分重要。
四、Kubernetes 的核心概念
理解 Kubernetes 时，不要一开始就死记所有组件。建议先掌握 Pod、Deployment、Service、Namespace 和 ConfigMap 等核心概念。
1. Pod：最小的部署单元
Pod 是 Kubernetes 中最小的可部署计算单元。
一个 Pod 可以包含一个或多个紧密协作的容器，这些容器共享 Pod 的网络命名空间，并可以通过配置共享存储。
在常见的 Web 应用中，一个 Pod 通常运行一个主要应用容器。例如，一个后端 API Pod 可以运行一个 Java 应用容器。
Pod 的主要特点：
- 可以包含一个或多个容器。
- Pod 内的容器共享网络环境，可以通过
localhost通信。 - 可以通过卷共享数据。
- Pod 具有自己的 IP 地址，但该地址通常不应被当作永久固定的应用入口。
- Pod 可能因为故障、调度或更新而被替换。
重要概念：Pod 通常不是长期固定不变的实例。 如果应用需要稳定地维持多个副本，应使用 Deployment、StatefulSet 等工作负载控制器进行管理，而不是手动创建一个 Pod 后就不再维护。
2. Deployment：管理无状态应用
Deployment 是 Kubernetes 中常用的工作负载资源，用于管理无状态应用的副本，并支持滚动更新和版本回滚。
例如，一个 Web 服务希望始终运行三个副本，可以在 Deployment 中声明副本数量为 3。
当某个 Pod 不再满足期望状态时，相关控制器会尝试创建替代实例。
Deployment 适用于：
- Web 前端。
- REST API 服务。
- 无状态业务后端。
- 不需要固定身份标识的应用实例。
Deployment 通常通过 ReplicaSet 管理 Pod 副本。
3. ReplicaSet：维持 Pod 副本数量
ReplicaSet 的主要职责是确保符合选择条件的 Pod 副本数量达到预期值。
例如，ReplicaSet 希望维持三个 Pod，当实际符合条件的 Pod 只有两个时，就会尝试补足一个。
在日常应用部署中，通常由 Deployment 管理 ReplicaSet，因此开发者一般不需要直接手动创建 ReplicaSet。
4. StatefulSet：管理有状态应用
StatefulSet 用于管理需要稳定身份标识、部署顺序或持久化存储关联的应用。
与普通 Deployment 不同，StatefulSet 管理的 Pod 通常具有稳定的序号和身份，并且可以关联持久化存储。
常见应用场景包括：
- 某些数据库集群。
- 分布式存储系统。
- 需要稳定网络标识的分布式应用。
- 具有特定启动和终止顺序要求的服务。
不过，使用 StatefulSet 并不意味着数据库自动具备高可用能力。数据库复制、故障切换、备份恢复和一致性管理仍然需要应用自身或配套系统支持。
5. Service：提供稳定的服务访问入口
Pod 的生命周期可能发生变化，IP 地址也可能变化。如果其他应用直接依赖某个 Pod 的 IP，就容易出现访问不稳定的问题。
Service 为一组符合选择条件的 Pod 提供相对稳定的访问入口，并根据具体类型和网络实现进行流量转发。
常见 Service 类型包括：
类型 | 主要用途 |
|---|---|
ClusterIP | 提供集群内部访问入口，通常是默认类型 |
NodePort | 通过节点端口暴露服务 |
LoadBalancer | 在支持的环境中通过外部负载均衡器暴露服务 |
ExternalName | 将服务名称映射到外部 DNS 名称 |
例如，前端应用不需要记录每个后端 Pod 的 IP，而是可以通过后端 Service 的 DNS 名称访问后端 API。
6. Namespace：资源逻辑隔离
Namespace（命名空间）用于在同一个 Kubernetes 集群中对资源进行逻辑分组。
例如，一个团队可以把开发、测试和生产环境相关的资源分别放入不同的 Namespace 中。
常见用途包括：
- 区分不同项目。
- 按团队管理资源。
- 组织开发和测试工作负载。
- 配合 RBAC 和资源配额进行权限及资源管理。
需要注意，Namespace 本身并不等于完整的安全隔离。网络访问控制、权限配置和资源限制还需要结合其他机制。
7. ConfigMap：管理非敏感配置
ConfigMap 用于保存非敏感的应用配置，例如：
- 应用运行模式。
- 日志级别。
- 服务地址。
- 功能开关。
- 配置文件内容。
将配置与应用镜像分离，可以让同一个镜像在不同环境中使用不同配置。
ConfigMap 不适合保存密码、访问令牌等敏感信息。
8. Secret：管理敏感配置
Secret 用于保存密码、令牌、证书等敏感数据。
不过，Secret 并不意味着数据天然安全。其默认存储和访问行为需要结合集群配置进行评估，尤其应关注：
- etcd 静态数据加密。
- RBAC 权限控制。
- 工作负载访问范围。
- 外部密钥管理系统。
- 日志和配置文件中的敏感信息泄漏。
生产环境不应把敏感凭据直接硬编码在公开的 YAML 文件或代码仓库中。
9. Ingress：管理 HTTP 和 HTTPS 外部访问
Ingress 是一种用于管理集群外部 HTTP 和 HTTPS 流量进入集群的 Kubernetes API 资源。
它可以通过域名、路径等规则，将请求转发到相应的 Service。
例如：
www.example.com转发到前端服务。api.example.com转发到后端服务。/admin路径转发到管理后台。
Ingress 资源本身通常需要配套的 Ingress Controller 才能真正处理流量。
此外，Kubernetes 还提供 Gateway API 等较新的流量管理 API。具体选择应根据集群环境、控制器支持和业务需求决定。
五、Kubernetes 的工作原理
Kubernetes 的核心思想是：用户声明期望状态，系统持续协调实际状态。
例如，用户希望一个应用运行三个副本，只需要在配置中声明 replicas: 3。Kubernetes 的控制器就会持续观察相关资源，并尝试使实际运行状态达到目标。
这个过程可以概括为：
- 用户通过 YAML 文件或命令提交资源配置。
- API Server 验证并处理资源请求。
- 资源状态被记录到集群存储中。
- Scheduler 为尚未调度的 Pod 选择合适节点。
- 节点上的 kubelet 根据配置协调容器运行。
- 控制器持续观察实际状态，并处理副本数量等变化。
例如，如果一个 Deployment 的三个 Pod 中有一个因为节点故障而无法继续运行，相关控制器可能会创建新的 Pod，并由调度器选择可用节点。
但这并不意味着应用一定完全无中断。故障检测、调度、镜像拉取和应用启动都需要时间，应用本身也需要正确处理重试、连接中断和状态恢复。
六、Kubernetes 与 Docker 有什么区别？
Docker 和 Kubernetes 不是互相替代的关系，而是可以在容器化应用体系中承担不同职责的技术。
对比维度 | Docker | Kubernetes |
|---|---|---|
核心定位 | 容器化工具及平台 | 容器编排与集群管理平台 |
主要任务 | 构建镜像、运行和管理容器 | 调度、维护和管理集群中的工作负载 |
应用规模 | 适合单机容器管理，也可用于开发测试 | 适合多节点集群和大规模应用管理 |
运行单位 | 容器 | 主要以 Pod 等工作负载资源进行管理 |
故障恢复 | 依赖具体运行方式和管理机制 | 通过控制器协调期望状态 |
服务发现 | 可使用容器网络等机制 | 提供 Service 和集群 DNS 等能力 |
配置方式 | Dockerfile、CLI、Compose 等 | YAML 资源清单、API、kubectl 等 |
举一个简单例子：
你可以先通过 Docker 构建一个后端应用镜像，再将镜像推送到镜像仓库，最后通过 Kubernetes Deployment 将它部署到集群中。
在这个流程中，Docker 主要参与镜像构建与容器相关工作，而 Kubernetes 负责后续的工作负载编排。
七、Kubernetes 常用命令
Kubernetes 最常用的命令行工具是 kubectl。它用于与 Kubernetes API Server 交互，查询资源、部署应用和排查问题。
执行这些命令前，需要安装 kubectl，并配置正确的集群访问凭据。
1. 查看集群信息
kubectl cluster-info
查看集群相关服务信息。
kubectl get nodes
查看集群节点及其状态。
kubectl get namespaces
查看集群中的命名空间。
2. 查看工作负载
kubectl get pods
查看当前 Namespace 下的 Pod。
kubectl get pods -A
查看所有 Namespace 下的 Pod。
kubectl get deployments
查看 Deployment 资源。
kubectl get services
查看 Service 资源。
3. 查看应用详细信息
kubectl describe pod <pod-name>
查看指定 Pod 的详细信息、事件和状态。
kubectl logs <pod-name>
查看 Pod 中容器的日志。对于包含多个容器的 Pod，可以通过 -c 指定容器。
kubectl exec -it <pod-name> -- sh
尝试进入指定 Pod 的容器执行命令。容器需要包含相应的 Shell 工具；精简镜像可能没有 sh。
4. 部署和更新应用
kubectl apply -f deployment.yaml
根据配置文件创建或更新相应资源。
kubectl rollout status deployment/my-app
查看 Deployment 的滚动更新状态。
kubectl rollout history deployment/my-app
查看 Deployment 的更新历史。
kubectl rollout undo deployment/my-app
尝试回滚到上一个可用的 Deployment 修订版本。
回滚是否成功取决于资源历史、镜像可用性及相关配置，实际操作前应确认目标环境和影响范围。
八、Kubernetes 实战：部署一个 Nginx 应用
下面通过一个完整示例，演示如何使用 Kubernetes 部署 Nginx，并通过 Service 在集群内部访问它。
本示例假设你已经拥有一个可用的 Kubernetes 集群，并已配置好 kubectl。
第一步：创建 Deployment
新建文件 nginx-deployment.yaml：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-demo
spec:
replicas: 2
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "64Mi"
limits:
cpu: "500m"
memory: "128Mi"
配置说明：
kind: Deployment：声明这是一个 Deployment 资源。replicas: 2：期望运行两个 Pod 副本。selector.matchLabels：指定 Deployment 管理哪些 Pod。template：定义要创建的 Pod 模板。image：指定应用镜像。resources.requests：声明调度时考虑的 CPU 和内存资源请求。resources.limits：设置容器资源使用限制。
这里的资源数值仅用于演示，不代表所有 Nginx 工作负载的推荐配置。
第二步：应用配置
kubectl apply -f nginx-deployment.yaml
Kubernetes 会根据配置创建或更新 Deployment，并协调 Pod 副本数量。
第三步：查看 Pod 状态
kubectl get pods
正常情况下，可以看到两个与 nginx-demo 相关的 Pod。
如果 Pod 没有进入 Running 状态，可以进一步查看：
kubectl describe deployment nginx-demo
kubectl get events --sort-by=.metadata.creationTimestamp
这些信息可以帮助排查镜像拉取失败、资源不足、调度失败等问题。
第四步：创建 Service
仅创建 Deployment 并不意味着应用已经可以从集群外部直接访问。
新建文件 nginx-service.yaml：
apiVersion: v1
kind: Service
metadata:
name: nginx-demo
spec:
type: ClusterIP
selector:
app: nginx-demo
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
这个 Service 会选择带有 app: nginx-demo 标签的 Pod，并为它们提供集群内部访问入口。
第五步：创建 Service
kubectl apply -f nginx-service.yaml
查看 Service：
kubectl get services
可以看到 nginx-demo 服务及其 ClusterIP 等信息。
第六步：在本地访问应用
对于这个 ClusterIP 类型的 Service，可以使用端口转发进行本地测试：
kubectl port-forward service/nginx-demo 8080:80
保持命令运行，然后在浏览器访问：
http://localhost:8080
正常情况下可以看到 Nginx 欢迎页面。
这种端口转发方式适合测试和调试，不应直接当作生产环境的公网访问方案。
第七步：扩展应用副本
如果希望将副本数量增加到三个，可以执行：
kubectl scale deployment nginx-demo --replicas=3
随后检查：
kubectl get pods
如果集群资源充足且没有其他约束，Kubernetes 会尝试将副本数量调整到三个。
第八步：清理测试资源
kubectl delete -f nginx-service.yaml
kubectl delete -f nginx-deployment.yaml
这会删除本示例创建的 Service 和 Deployment 资源。请不要将这些命令直接用于生产资源。
九、Kubernetes 的自动扩缩容机制
Kubernetes 可以根据需求调整应用副本数量，但需要区分不同的扩缩容机制。
1. 手动扩缩容
通过 kubectl scale 等方式修改副本数量。
适合临时测试或明确知道目标副本数量的场景。
2. HPA：水平 Pod 自动扩缩容
Horizontal Pod Autoscaler，简称 HPA，可以根据 CPU、内存或自定义指标等信息，自动调整工作负载的副本数量。
例如，当业务请求增加时，HPA 可以根据设定的指标和范围增加 Pod 副本；负载下降时，也可以适当减少副本。
HPA 正常工作通常需要指标数据来源，例如 Metrics Server 提供的资源指标，或者相应的自定义指标适配器。
HPA 也不是即时扩容机制。镜像拉取、应用启动和资源调度都需要时间，因此需要根据实际业务压力设置合理的阈值、最小副本数和最大副本数。
3. VPA：垂直 Pod 自动扩缩容
Vertical Pod Autoscaler，简称 VPA，主要用于根据资源使用情况调整 Pod 的 CPU 和内存请求，部分配置还涉及资源限制。
它与 HPA 的关注点不同：HPA 主要调整副本数量，VPA 主要调整单个 Pod 的资源配置。
具体行为取决于 VPA 的安装、策略及更新模式。
4. Cluster Autoscaler：集群节点扩缩容
Cluster Autoscaler 可以在受支持的基础设施环境中，根据待调度 Pod 和节点利用情况调整集群节点数量。
例如，当现有节点无法满足 Pod 的调度需求时，它可能请求增加节点；当部分节点长期不再需要时，也可能尝试缩减节点。
这需要底层基础设施支持，不能简单理解为 Kubernetes 在任何服务器上都能自动创建或删除机器。
十、Kubernetes 的应用场景
1. 微服务架构
微服务应用通常包含多个独立服务。Kubernetes 可以帮助管理服务副本、内部通信、配置和应用更新。
2. 高流量 Web 应用
对于流量波动较大的 Web 服务，可以结合副本扩缩容、负载均衡和集群节点扩容机制，提升资源利用效率。
3. CI/CD 持续交付
开发团队可以通过自动化流水线构建镜像、执行测试，再将应用部署到 Kubernetes 集群。
4. 云原生应用平台
Kubernetes 可以作为云原生平台的基础设施，结合监控、日志、服务网格、策略管理等工具，构建统一的应用运行环境。
5. AI 推理与 GPU 工作负载
Kubernetes 也可用于管理 AI 推理服务及部分 GPU 计算任务。
不过，这类任务还需要配置适当的 GPU 设备插件、资源调度方式、驱动与运行时环境，并考虑模型文件分发、显存容量和任务启动时间等因素。
十一、Kubernetes 的常见问题
1. 学习 Kubernetes 之前必须学 Docker 吗？
不一定必须精通 Docker，但建议先理解容器、镜像、端口映射、容器网络和数据持久化等基础知识。
掌握这些概念后，再学习 Pod、Deployment、Service 和集群调度会更容易。
2. Kubernetes 一定需要多台服务器吗？
不一定。学习和测试时，可以使用单节点或轻量级本地集群。
但在生产环境中，如果需要应对节点故障、业务高可用或大规模工作负载，通常需要更完善的多节点架构。
单节点集群无法提供真正的节点级高可用能力。
3. Kubernetes 和 Docker Compose 应该如何选择？
如果项目规模较小，只需要在一台服务器上运行几个容器，Docker Compose 通常更简单。
如果需要跨多个节点调度工作负载、自动维护副本、统一管理服务发现和集群资源，则可以考虑 Kubernetes。
技术选型应根据实际复杂度决定，而不是因为 Kubernetes 功能更多就一定选择它。
4. Pod 和容器有什么区别？
容器是实际运行应用进程的环境，而 Pod 是 Kubernetes 中的部署单元，可以包含一个或多个容器。
一个 Pod 内的容器共享网络环境，并可以通过配置共享存储。Kubernetes 主要以 Pod 为单位进行调度和管理。
5. Deployment 和 StatefulSet 有什么区别？
Deployment 主要用于管理无状态应用副本；StatefulSet 适合需要稳定身份标识、存储关联或特定部署顺序的有状态应用。
两者并不是简单的高低级关系，应根据应用本身的状态管理需求进行选择。
6. Kubernetes 可以自动恢复所有故障吗？
不能。
Kubernetes 可以根据控制器定义的期望状态恢复部分工作负载，但无法自动修复所有应用逻辑错误、数据库数据损坏、外部依赖故障或错误的配置。
例如，容器进程不断崩溃时，Kubernetes 可能反复尝试重启它，但根本问题仍然需要开发者排查。
7. Kubernetes 是不是越复杂越好？
不是。
Kubernetes 能提供强大的编排能力，但也会引入集群维护、权限管理、网络、存储、监控和升级等额外成本。
对于简单的个人项目或小型网站，Docker Compose 或托管容器服务可能更适合。只有当应用规模、可用性需求或管理复杂度达到一定程度时，Kubernetes 的优势才更容易体现。
十二、学习 Kubernetes 的推荐路线
对于刚接触容器编排的开发者，可以按照以下顺序逐步学习：
- 容器基础： 理解 Docker 镜像、容器、网络、数据卷和 Dockerfile。
- 集群基础： 了解控制平面、工作节点、API Server 和调度器。
- 核心资源： 掌握 Pod、Deployment、ReplicaSet、Service 和 Namespace。
- 配置管理： 学习 ConfigMap、Secret、环境变量和资源请求限制。
- 网络与存储： 理解集群 DNS、Ingress、持久化卷及存储声明。
- 应用更新： 掌握滚动更新、版本回滚和故障排查。
- 自动扩缩容： 学习 HPA、资源指标以及节点扩缩容机制。
- 生产运维： 进一步学习 RBAC、安全策略、监控、日志、备份和集群升级。
建议在学习过程中，至少完成一个完整的练习项目：将一个简单 Web 应用打包成镜像，部署到 Kubernetes，创建 Service，再练习扩容、更新和故障排查。
十四、总结
Kubernetes 是用于管理容器化应用的开源编排平台，能够通过声明式配置和控制器机制，自动化完成应用部署、调度、扩缩容和故障恢复等任务。
理解 Kubernetes 的关键不在于记住所有命令，而在于掌握几个核心思想：
- Pod 是最小的可部署单元。
- Deployment 等控制器用于维护工作负载的期望状态。
- Service 为应用提供稳定的服务访问入口。
- 控制平面负责管理集群，工作节点负责运行工作负载。
- Kubernetes 通过持续协调实际状态与期望状态，实现自动化管理。
对于开发者来说，先掌握 Docker，再学习 Kubernetes 的核心资源和部署流程，是一条实用且循序渐进的学习路径。
