在 Kubernetes 集群中运行并发布应用程序

一、背景与应用场景

一、核心层级关系：Deployment → ReplicaSet → Pod

Deployment 不直接创建 Pod ，而是通过控制 ReplicaSet 的生命周期 ，间接管理 Pod 副本。这种 "中间层" 设计是 Deployment 实现滚动更新、版本回滚的关键。

Pod：最底层的工作单元，运行容器化应用。

ReplicaSet ：确保集群中始终运行指定数量的 Pod 副本（通过标签选择器匹配 Pod）。

Deployment ：管理 ReplicaSet 的 "上层控制器"，负责 ReplicaSet 的创建、更新、回滚，并通过 ReplicaSet 间接控制 Pod。

二、核心功能解析

1. 副本管理与 "自愈" 机制

Deployment 的核心目标是：让集群中始终运行 spec.replicas 定义的期望 Pod 数量。

创建阶段 ：用户创建 Deployment 时，需指定 replicas（如 replicas: 3）。Deployment 会生成一个 ReplicaSet，由该 ReplicaSet 自动创建 3 个 Pod。

自愈阶段 ：若某个 Pod 因 "节点故障""容器崩溃" 等原因终止，ReplicaSet 会检测到 "实际 Pod 数量 < 期望数量"，立即创建新 Pod 补充，确保最终 Pod 数量始终匹配 replicas。

2. 滚动更新（Rolling Update）：无中断升级

当需要更新应用版本（如 Nginx 镜像从 1.18 升级到 1.20），Deployment 会通过 **"逐步替换 Pod"的方式实现无中断更新 **，避免服务完全不可用。

过程：

用户更新 Deployment（如 kubectl set image deployment/nginx-deployment nginx=nginx:1.20）。

Deployment 会新建一个 ReplicaSet（记为 "新 ReplicaSet"），并为其指定新的镜像版本。

新 ReplicaSet 逐步增加新 Pod 数量 ，同时旧 ReplicaSet 逐步减少旧 Pod 数量 ，直到所有 Pod 都属于 "新 ReplicaSet"。（示例：若 replicas=3，可能先启动 1 个新 Pod → 终止 1 个旧 Pod → 再启动 1 个新 Pod → 终止 1 个旧 Pod → 最后启动 1 个新 Pod → 终止最后 1 个旧 Pod）。

精细控制 ：可通过 maxSurge（升级时允许超出的最大 Pod 数，如 maxSurge: 25% 表示最多比 replicas 多 25% 的 Pod）和 maxUnavailable（升级时允许不可用 的最大 Pod 数，如 maxUnavailable: 25% 表示最多有 25% 的 Pod 临时不可用），调整滚动更新的 "激进程度"。

3. 版本回滚（Rollback）：快速恢复故障版本

若滚动更新后，新 Pod 出现 Bug（如镜像兼容问题），Deployment 支持回滚到历史稳定版本 ------ 因为每次更新都会保留旧 ReplicaSet （默认保留最近几个版本，可通过 revisionHistoryLimit 配置保留数量）。

操作：执行 kubectl rollout undo deployment/<deployment-name>，Deployment 会重新激活旧 ReplicaSet，并逐步减少 "新 ReplicaSet" 的 Pod 数量，最终回到旧版本的 Pod 副本状态。

三、声明式控制："期望状态" 驱动

Kubernetes 采用声明式 API ，Deployment 的 spec 部分定义了 "期望的集群状态"（如要运行 3 个 nginx:1.20 的 Pod）。

Kubernetes 的 "控制器" 会持续监控集群的实际状态，并自动调整（如创建 / 删除 Pod、切换 ReplicaSet），使 "实际状态" 向 "期望状态" 靠拢。

例如：若手动删除了一个由 Deployment 管理的 Pod，ReplicaSet 会立即检测到 "Pod 数量不足"，并创建新 Pod 补充，最终让 Pod 数量回到 replicas 定义的期望数值。

总结：Deployment 的核心价值

通过 "Deployment → ReplicaSet → Pod" 的层级设计，Deployment 实现了三大核心能力：

无中断滚动更新：保障应用升级时服务不中断；

故障自愈：Pod 异常终止时自动重建，提升可用性；

版本回滚：快速回退到历史版本，降低变更风险。

这使得 Deployment 成为 Kubernetes 中管理 "长期运行、需高可用性和版本管控的应用" 的核心资源对象。

背景与应用场景（为什么用 K8s 部署 Nginx？适合哪些场景？）

要理解为何用 Kubernetes（K8s）部署 Nginx ，以及其适用场景，需从「K8s 核心能力」与「Nginx 角色（反向代理、网关、负载均衡）」的结合点分析：

一、为什么用 Kubernetes 部署 Nginx？

K8s 为 Nginx 这类服务提供了自动化管理、高可用、弹性伸缩、服务治理等能力，解决了传统部署的诸多痛点：

1. 自动化部署与配置一致性

传统痛点：手动在多台服务器安装 Nginx、配置 nginx.conf（反向代理规则、静态资源路径等），易出现 **"配置漂移"（不同服务器配置不一致）。 K8s 优势：通过 Deployment + ConfigMap 声明 Nginx 的 "期望状态"（镜像版本、副本数、配置文件），一次定义即可在集群中自动、一致地部署多份 Nginx 实例 **，避免人工操作误差。

2. 高可用与 "自愈" 能力

传统痛点：Nginx 进程崩溃或服务器故障时，需人工检测、重启服务，期间服务可能中断。K8s 优势：Deployment 会持续监控 Nginx Pod 的运行状态，若 Pod 因 "容器退出""节点故障" 等原因终止，K8s 会自动在健康节点重建 Pod，保障服务持续可用。

3. 弹性伸缩（应对流量波动）

传统痛点：流量高峰时，需人工登录服务器增加 Nginx 实例、调整负载均衡，操作滞后且繁琐；低峰时又会浪费资源。K8s 优势：通过 HPA（Horizontal Pod Autoscaler） ，可基于 "CPU 使用率""QPS" 等指标，自动增加 / 减少 Nginx Pod 数量，灵活应对突发流量（如电商大促、直播峰值）或低峰期资源节省。

4. 服务发现与集群内动态路由

K8s 集群内通常运行大量微服务（如后端 Java 服务、数据库服务），Nginx 需动态发现这些服务的地址。K8s 优势：通过 Service + 集群 DNS 机制，Nginx 可直接通过 "服务名"（如 backend-service.default.svc.cluster.local）解析集群内服务的 IP，无需硬编码后端地址，完美适配微服务的动态扩缩容。

5. 滚动更新与版本回滚

传统痛点：升级 Nginx 版本（或修改配置）时，需 "停旧服务 → 部署新服务"，导致短暂服务中断；若新版本有 Bug，回滚流程繁琐。K8s 优势：支持 滚动更新 （逐步替换旧 Nginx Pod 为新版本，全程不中断服务）；若新版本故障，可通过 kubectl rollout undo 一键回滚到历史稳定版本。

二、适合的场景

结合 K8s 的能力，Nginx 在以下场景中特别适合通过 K8s 部署：

1. 大规模微服务集群的 "统一入口层"

当集群内有数十、上百个微服务时，Nginx 可作为反向代理网关：

对外暴露统一域名（如 api.example.com），通过 location 配置将请求路由到不同微服务；

集中处理 TLS 加密（HTTPS）、请求限流、日志收集、跨域处理等 "边缘能力"，减少每个微服务的重复开发。

2. 高并发 + 弹性伸缩的场景

如电商网站、直播平台、在线教育系统：

流量低峰时，K8s 自动缩减 Nginx Pod 数量，节省集群资源；

流量高峰（如秒杀活动、直播开播）时，HPA 自动扩容 Nginx 实例，承载更大并发请求。

3. 多环境（开发 / 测试 / 生产）一致性要求高的场景

企业内有 "开发、测试、预发、生产" 等多个环境时，通过 K8s 的 YAML 配置 + GitOps 流程，可确保 "开发环境的 Nginx 配置，一键同步到生产环境"，避免环境差异导致的故障。

4. 高可用优先的关键业务

若 Nginx 是业务的 "流量入口"（如核心 API 网关），K8s 的 "多节点部署 + 自愈能力" 可保障：即使部分节点故障，Nginx Pod 会在其他健康节点自动重建，服务不中断。

5. 与 K8s 生态深度集成的场景

作为 Ingress Controller ：用 Nginx 实现 K8s 的 Ingress（如 nginx-ingress-controller），统一管理集群内外的 HTTP/HTTPS 路由；

与服务网格（Service Mesh）协同 ：Nginx 作为 "边缘代理"，与网格内的 Sidecar（如 Envoy）配合，实现灰度发布、熔断、限流等高级流量治理能力。

总结

只要场景需要自动化运维、高可用、弹性伸缩、服务治理 中的任意一项，用 K8s 部署 Nginx 都能带来明显优势；尤其是微服务集群、高并发系统、多环境协同的场景，收益更为突出。

已成功创建 Kubernetes 集群（如通过 kind 或云厂商集群），且 kubectl 工具可正常连接集群。

二、步骤 1：创建 Nginx Deployment（使用国内镜像）

Deployment 用于管理 "多副本 Nginx Pod"，确保应用高可用。

1.编写 Deployment 配置文件

bash 复制代码

[root@host2 ~]# vi nginx-deploy.yaml
[root@host2 ~]# cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: registry.cn-hangzhou.aliyuncs.com/library/nginx:1.14.2
        ports:
        - name: nginx-port
          containerPort: 80

2.应用 Deployment 配置

执行命令创建 Deployment：

bash 复制代码

[root@host2 ~]# kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx-deploy created

3.验证 Deployment 和 Pod

bash 复制代码

[root@host2 ~]# kubectl get pod nginx-5f8f49fff4-sxzf9 -o jsonpath='{.spec.containers[0].image}{"\n"}'
nginx:alpine
[root@host2 ~]# vi nginx-deploy.yaml
[root@host2 ~]# vi nginx-deploy.yaml
[root@host2 ~]# cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - name: nginx-port
          containerPort: 80
[root@host2 ~]# kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx-deploy configured
[root@host2 ~]# kubectl delete pods -l app=nginx-pod
pod "nginx-deploy-59d796c49f-8r27s" deleted from default namespace
pod "nginx-deploy-59d796c49f-9qvmc" deleted from default namespace
[root@host2 ~]# kubectl get pods -w
NAME                            READY   STATUS    RESTARTS       AGE
nginx-5f8f49fff4-sxzf9          1/1     Running   15 (26m ago)   123m
nginx-deploy-59d796c49f-6cpws   1/1     Running   1 (7s ago)     8s
nginx-deploy-59d796c49f-hxw6h   1/1     Running   1 (7s ago)     8s
^Z
[1]+  已停止               kubectl get pods -w
[root@host2 ~]# kubectl get deployment nginx-deploy
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   2/2     2            2           24m

三、步骤 2：创建 Nginx Service（NodePort 类型，对外暴露）

Service 用于将 Nginx Pod 暴露给外部访问（通过 "节点 IP + 端口" 访问）。

1.编写 Service 配置文件

bash 复制代码

[root@host2 ~]# vi nginx-service.yaml
[root@host2 ~]# cat nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: nginx-pod
  ports:
  - port: 8080
    targetPort: 80
    nodePort: 30008

2.应用 Service 配置

bash 复制代码

[root@host2 ~]# kubectl apply -f nginx-service.yaml
service/nginx-svc created

3.验证 Service

bash 复制代码

[root@host2 ~]# kubectl get service nginx-svc
NAME        TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
nginx-svc   NodePort   10.96.96.20   <none>        8080:30008/TCP   19s

四、步骤 3：测试访问（集群内 + 集群外）

1.集群内访问（通过 Service ClusterIP）

bash 复制代码

/ # curl localhost:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ # exit

2.集群外访问（通过 "节点 IP + NodePort"）

bash 复制代码

[root@host2 ~]# curl 192.168.197.10:30008
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

五、步骤 4：清理资源（可选）

测试完成后，删除 Deployment 和 Service：

bash 复制代码

[root@host2 ~]# kubectl delete -f nginx-service.yaml
service "nginx-svc" deleted from default namespace
[root@host2 ~]# kubectl delete -f nginx-deploy.yaml
deployment.apps "nginx-deploy" deleted from default namespace

关键说明

国内镜像加速 ：使用 registry.cn-hangzhou.aliyuncs.com/library/nginx 替代外网 docker.io/nginx，避免海外拉取镜像的网络问题，提升速度。
NodePort 范围 ：nodePort 需在 30000-32767 之间，且确保节点端口未被其他服务占用。
标签匹配 ：Service 的 selector 必须与 Deployment 中 Pod 的 labels 完全一致，否则 Service 无法找到对应的 Pod。

可参考：基于 kind 部署 Kubernetes 集群-CSDN博客

**"Deployment 工作原理解析"**

一、核心层级关系：Deployment → ReplicaSet → Pod

Deployment 不直接创建 Pod ，而是通过控制 ReplicaSet 的生命周期 ，间接管理 Pod 副本。这种 "中间层" 设计是 Deployment 实现滚动更新、版本回滚的关键。

Pod：最底层的工作单元，运行容器化应用。

ReplicaSet ：确保集群中始终运行指定数量的 Pod 副本（通过标签选择器匹配 Pod）。

Deployment ：管理 ReplicaSet 的 "上层控制器"，负责 ReplicaSet 的创建、更新、回滚，并通过 ReplicaSet 间接控制 Pod。

二、核心功能解析

1. 副本管理与 "自愈" 机制

Deployment 的核心目标是：让集群中始终运行 spec.replicas 定义的期望 Pod 数量。

创建阶段 ：用户创建 Deployment 时，需指定 replicas（如 replicas: 3）。Deployment 会生成一个 ReplicaSet，由该 ReplicaSet 自动创建 3 个 Pod。

自愈阶段 ：若某个 Pod 因 "节点故障""容器崩溃" 等原因终止，ReplicaSet 会检测到 "实际 Pod 数量 < 期望数量"，立即创建新 Pod 补充，确保最终 Pod 数量始终匹配 replicas。

2. 滚动更新（Rolling Update）：无中断升级

当需要更新应用版本（如 Nginx 镜像从 1.18 升级到 1.20），Deployment 会通过 **"逐步替换 Pod"的方式实现无中断更新 **，避免服务完全不可用。

过程：

用户更新 Deployment（如 kubectl set image deployment/nginx-deployment nginx=nginx:1.20）。

Deployment 会新建一个 ReplicaSet（记为 "新 ReplicaSet"），并为其指定新的镜像版本。

新 ReplicaSet 逐步增加新 Pod 数量 ，同时旧 ReplicaSet 逐步减少旧 Pod 数量 ，直到所有 Pod 都属于 "新 ReplicaSet"。（示例：若 replicas=3，可能先启动 1 个新 Pod → 终止 1 个旧 Pod → 再启动 1 个新 Pod → 终止 1 个旧 Pod → 最后启动 1 个新 Pod → 终止最后 1 个旧 Pod）。

精细控制 ：可通过 maxSurge（升级时允许超出的最大 Pod 数，如 maxSurge: 25% 表示最多比 replicas 多 25% 的 Pod）和 maxUnavailable（升级时允许不可用 的最大 Pod 数，如 maxUnavailable: 25% 表示最多有 25% 的 Pod 临时不可用），调整滚动更新的 "激进程度"。

3. 版本回滚（Rollback）：快速恢复故障版本

若滚动更新后，新 Pod 出现 Bug（如镜像兼容问题），Deployment 支持回滚到历史稳定版本 ------ 因为每次更新都会保留旧 ReplicaSet （默认保留最近几个版本，可通过 revisionHistoryLimit 配置保留数量）。

操作：执行 kubectl rollout undo deployment/<deployment-name>，Deployment 会重新激活旧 ReplicaSet，并逐步减少 "新 ReplicaSet" 的 Pod 数量，最终回到旧版本的 Pod 副本状态。

三、声明式控制："期望状态" 驱动

Kubernetes 采用声明式 API ，Deployment 的 spec 部分定义了 "期望的集群状态"（如要运行 3 个 nginx:1.20 的 Pod）。

Kubernetes 的 "控制器" 会持续监控集群的实际状态，并自动调整（如创建 / 删除 Pod、切换 ReplicaSet），使 "实际状态" 向 "期望状态" 靠拢。

例如：若手动删除了一个由 Deployment 管理的 Pod，ReplicaSet 会立即检测到 "Pod 数量不足"，并创建新 Pod 补充，最终让 Pod 数量回到 replicas 定义的期望数值。

总结：Deployment 的核心价值

通过 "Deployment → ReplicaSet → Pod" 的层级设计，Deployment 实现了三大核心能力：

无中断滚动更新：保障应用升级时服务不中断；

故障自愈：Pod 异常终止时自动重建，提升可用性；

版本回滚：快速回退到历史版本，降低变更风险。

这使得 Deployment 成为 Kubernetes 中管理 "长期运行、需高可用性和版本管控的应用" 的核心资源对象。