在 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"的方式实现无中断更新 **,避免服务完全不可用。

  • 过程

    1. 用户更新 Deployment(如 kubectl set image deployment/nginx-deployment nginx=nginx:1.20)。
    2. Deployment 会新建一个 ReplicaSet(记为 "新 ReplicaSet"),并为其指定新的镜像版本。
    3. 新 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"的方式实现无中断更新 **,避免服务完全不可用。

  • 过程

    1. 用户更新 Deployment(如 kubectl set image deployment/nginx-deployment nginx=nginx:1.20)。
    2. Deployment 会新建一个 ReplicaSet(记为 "新 ReplicaSet"),并为其指定新的镜像版本。
    3. 新 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 中管理 "长期运行、需高可用性和版本管控的应用" 的核心资源对象

相关推荐
失散133 小时前
分布式专题——24 Kafka功能扩展
java·分布式·云原生·架构·kafka
2501_920047033 小时前
k8s-pod的镜像升级与回滚
云原生·容器·kubernetes
关关长语3 小时前
Ubuntu 中获取指定软件依赖安装包
linux·运维·ubuntu
dragon_cdut3 小时前
ubuntu22.04 无法清空回收站文件
linux·运维
七七七七073 小时前
【Linux 系统】进程优先级
linux·运维·服务器
码路工人3 小时前
第10章:K8s 数据持久化
docker·云原生·容器
chainbees3 小时前
Git账号配置 SSH 密钥
运维·git·ssh
richxu202510014 小时前
Java开发环境搭建之 9.使用Docker Compose 安装部署RabbitMQ
java·docker·java-rabbitmq
小闫BI设源码4 小时前
istio集群服务治理
云原生·负载均衡·istio·service服务·ingress路由·网络插件·端口暴露