目录

一，3种发布方式

1.1蓝绿发布（Blue-Green Deployment）

1.1.1. 定义

1.1.2. 核心原理

1.1.3. 核心特点

1.1.4. 适用场景

1.2，滚动发布（Rolling Update）

1.2.1. 定义

1.2.2. 核心原理

1.2.3. 核心特点

1.2.4. 适用场景

1.3，金丝雀发布（Canary Deployment）

1.3.1. 定义

1.3.2. 核心原理

1.3.3. 核心特点

1.3.4. 适用场景

二，Kubernetes 操作管理

2.1，管理操作分类

2.1.1声明：对类别的精准定义—— 一句话说清 “这个类是什么”，高度概括核心属性。

2.1.2陈述：对类别的完整解释—— 在声明基础上，补充 “这个类的特征、作用、适用场景”，让定义更丰满。

2.2陈述式资源管理方法

容器内部调试

删除 web-nginx 的 Deployment（自动级联删 Pod、ReplicaSet）

三，项目生命周期管理

3.1，项目的生命周期包括：

3.1.1，创建阶段

3.1.2，发布阶段

前言

这部分内容围绕 Kubernetes 中 Deployment、Pod、Service 的核心操作展开，从资源部署、端口暴露到状态查看、资源清理，拆解了日常运维中常用的命令逻辑与资源关系，帮读者快速理清 K8s 基础运维的核心链路。

一，3种发布方式

1.1蓝绿发布（Blue-Green Deployment）

1.1.1. 定义

蓝绿发布是一种全量切换的部署策略，通过部署两套完全相同的生产环境（蓝环境与绿环境），实现版本的无缝切换。其中，一套环境承载当前的生产流量（称为活跃环境），另一套环境部署新版本并进行验证（称为备用环境），验证通过后，通过切换流量路由的方式，将全量流量从活跃环境切换到备用环境。

1.1.2. 核心原理

• 构建两套完全隔离且配置一致的生产环境：蓝环境（Blue）和绿环境（Green）。两套环境的硬件配置、软件版本、网络策略、存储配置等完全一致；
• 升级前，蓝环境为活跃环境，承载全量的生产流量；绿环境为备用环境，部署新版本的服务，但不接入任何生产流量，仅用于内部验证；
• 新版本在绿环境中通过功能、性能、稳定性的全面验证后，执行流量切换操作，将全量生产流量从蓝环境切换到绿环境；
• 切换完成后，绿环境成为新的活跃环境，蓝环境则作为备用环境保留一段时间（用于回滚）。若新版本运行稳定，可逐步下线蓝环境；若新版本出现问题，可立即执行反向切换，将流量切回蓝环境。

1.1.3. 核心特点

• 绝对的零停机：流量切换是瞬间完成的，整个过程中，服务的可用状态不会发生任何变化，不会出现任何请求的超时或失败；
• 回滚速度极快：若新版本出现问题，仅需执行一次流量切换操作，即可将全量流量切回旧版本环境，回滚过程在秒级内即可完成；
• 资源占用高：需要部署两套完全相同的生产环境，资源占用为正常运行时的两倍，对资源储备的要求较高；
• 无灰度特性：流量切换是全量的，不存在小比例流量验证的过程，新版本要么不接入流量，要么接入全量流量；
• 环境一致性要求高：蓝绿两套环境必须保持完全一致的配置，否则可能会导致切换后出现服务异常的问题。

1.1.4. 适用场景

• 核心业务的版本升级，对服务的可用性和回滚速度有极高要求的场景；
• 新版本的功能复杂，需要在完整的生产环境中进行验证的场景；
• 对请求的连续性要求极高，不允许出现任何请求失败的场景（如金融交易、支付系统）；
• 资源储备充足，能够提供两套完全相同的生产环境的场景。

1.2，滚动发布（Rolling Update）

1.2.1. 定义

滚动发布是一种渐进式的版本替换策略，通过逐步删除旧版本实例、创建新版本实例的方式，实现全量版本升级。整个过程中，服务的总可用实例数始终保持在一个相对稳定的范围内，无需额外的资源储备。

1.2.2. 核心原理

• 以单个部署单元（如 K8s 的 Deployment、Docker Compose 的 Service）为核心，统一管理新旧版本的实例；
• 升级过程中，系统会按照预设的批次大小（如每次替换 20% 的实例），逐批完成旧版本到新版本的替换；
• 每一批次的新版本实例启动并通过健康检查后，才会将其接入流量池，同时下线对应的旧版本实例；
• 整个过程中，新旧版本实例会短暂共存，但流量会被动态路由到可用的实例上，保证业务的持续可用。

1.2.3. 核心特点

• 资源占用低：无需额外的资源储备，仅使用业务正常运行所需的资源即可完成升级；
• 实现简单：大部分容器编排工具（K8s、Docker Compose）均原生支持，无需复杂的额外配置；
• 灰度特性弱：灰度控制的粒度为实例数量比例，无法实现基于流量比例、用户分组的精准灰度；
• 回滚复杂度中等：若新版本出现问题，需要反向执行滚动过程，逐批将新版本实例替换为旧版本实例，回滚速度取决于实例数量和批次大小；
• 无绝对的零停机：虽然整体服务可用，但在批次替换的过程中，单个实例的下线和上线可能会导致少量请求的超时或失败。

1.2.4. 适用场景

• 无状态服务的常规版本升级；
• 对灰度控制精度要求不高的场景；
• 资源紧张，无法提供额外资源储备的环境；
• 新版本的风险较低，无需进行小比例流量验证的场景。

1.3，金丝雀发布（Canary Deployment）

1.3.1. 定义

金丝雀发布是一种低风险的灰度部署策略，其名称来源于历史上矿工通过携带金丝雀下井，检测矿井中是否存在有毒气体的做法。该策略通过将小比例的生产流量（如 5%、10%）路由到新版本实例上，进行功能、性能、稳定性的验证。验证通过后，逐步提升新版本的流量比例，最终实现全量升级。若新版本出现问题，可快速切断金丝雀流量，主业务不受任何影响。

1.3.2. 核心原理

• 部署两套独立的部署单元：主部署单元（承载大部分生产流量，运行旧版本）和金丝雀部署单元（承载小比例流量，运行新版本）；
• 两套部署单元使用相同的基础服务标识（如相同的服务名、相同的端口），但通过不同的标签或标识进行区分；
• 通过流量控制层（如 Ingress、服务网格、负载均衡器），将预设比例的生产流量路由到金丝雀部署单元，其余流量仍路由到主部署单元；
• 对金丝雀部署单元的新版本进行持续的监控和验证，重点关注请求成功率、响应时间、错误日志、资源使用率等关键指标；
• 若新版本验证通过，逐步提升金丝雀部署单元的流量比例（如从 10% 提升到 30%、50%、100%），同时逐步缩减主部署单元的实例数量；
• 若新版本验证失败，立即切断金丝雀部署单元的流量，并下线金丝雀部署单元，主部署单元仍正常运行，业务不受任何影响。

1.3.3. 核心特点

• 风险极低：仅使用小比例的流量验证新版本，即使新版本出现严重问题，影响范围也仅限于小部分用户，不会对整体业务造成大的影响；
• 灰度控制精度高：支持基于流量比例、用户分组、地域、请求头等多种维度的精准灰度控制，可根据业务需求灵活配置；
• 回滚简单快速：若新版本出现问题，仅需切断金丝雀流量或下线金丝雀部署单元即可完成回滚，主业务不受任何影响；
• 实现复杂度中等：需要额外的流量控制层来实现精准的流量路由，部分场景下需要依赖服务网格（如 Istio、Linkerd）等工具；
• 资源占用中等：需要额外的资源来部署金丝雀部署单元，但资源占用远低于蓝绿发布（仅需小比例的实例数量）。

1.3.4. 适用场景

• 新版本的风险较高，需要进行小比例流量验证的场景（如核心功能的重大更新、新功能的首次上线）；
• 对用户体验敏感，需要逐步验证新版本的用户体验的场景；
• 需要精准控制灰度范围，实现基于用户分组、地域的定向灰度的场景；
• 新版本的性能不确定，需要通过小比例流量验证其性能瓶颈的场景。

二，Kubernetes 操作管理

2.1，管理操作分类

2.1.1声明：对类别的精准定义—— 一句话说清 “这个类是什么”，高度概括核心属性。

1. 实例生命周期管理操作：管控服务运行实体（Pod / 容器）的创建、删除、更新的操作。
2. 流量路由规则管理操作：控制流量在不同版本实例间分发路径、比例的操作。

2.1.2陈述：对类别的完整解释—— 在声明基础上，补充 “这个类的特征、作用、适用场景”，让定义更丰满。

1. 实例生命周期管理操作：聚焦服务运行实体，通过创建、删除等操作管控实例全生命周期，不直接调整流量走向，是所有发布方式的基础操作。
2. 流量路由规则管理操作：聚焦流量分发逻辑，通过调整路由规则控制流量分配，不改变实例本身状态，是蓝绿、金丝雀发布的核心操作。

2.2陈述式资源管理方法

kubectl get all

避免干扰到其他环境

kubectl create deployment nginx-wl --image=nginx -n kube-public

kubectl get pods -n kube-public

# 查看Deployment详情（确认副本数、Pod模板等）
kubectl describe deployment nginx-wl -n kube-public
# 查看指定Pod详情（排查Pod异常时用）
kubectl describe pod <pod名称> -n kube-public

容器内部调试

kubectl exec -it <pod名称> bash -n kube-public

目的：登录到 nginx 容器内部，执行命令（如nginx -v查版本、cat /etc/nginx/nginx.conf看配置），排查容器内的服务问题。

常规删除 Pod：

kubectl delete pod <pod名称> -n kube-public

：删除指定 Pod（Deployment 会自动重建新 Pod，用于测试 Pod 的自愈能力）。

删除 web-nginx 的 Deployment（自动级联删 Pod、ReplicaSet）

Deployment 是 Pod 和 ReplicaSet 的控制器，删除 Deployment 会自动清理它管理的 Pod 和 ReplicaSet：

kubectl delete deployment web-nginx

三，项目生命周期管理

3.1，项目的生命周期包括：

3.1.1，创建阶段

--replicas=3：指定 Deployment 管理 3 个 Pod 副本

3.1.2，发布阶段

NodePort 模式（生产环境不用）

1. 外部请求发起：外部通过 “节点 IP + NodePort（30001）” 发起 HTTP 请求；
2. Service 接收并转发：Service（暴露 port:80）接收请求，通过targetPort将流量转发到 node1 中 nginx 容器的 80 端口；
3. 容器处理请求：node1 内的 nginx 容器（监听 80 端口）处理请求，完成响应。

整个流程是：外部 → NodePort（30001）→ Service（port:80）→ targetPort → 容器（nginx:80）。

3.1.3、为什么 NodePort 不是企业生产的 “常用项”？

NodePort 的核心问题是 “暴露服务器” 带来的风险和管理痛点，这和企业对稳定性、安全性的要求冲突：

1. 安全风险高：NodePort 会在集群所有节点的网卡上开放一个固定端口（如 30080），只要能访问节点的公网 / 内网 IP，就能直接访问服务；若节点 IP 泄露、端口被扫描，很容易遭到攻击，且节点故障会直接导致服务不可用。

3.1.4、企业生产环境真正 “最常用” 的对外暴露方式

企业会优先选择 “间接暴露” 而非直接暴露节点，核心是通过统一入口管控流量、降低风险，主流有两种：

1. Ingress + Ingress Controller

这是云原生企业最核心的方案，本质是 “统一网关层” 暴露服务：

• 逻辑：先部署 Ingress Controller（如 Nginx Ingress、Traefik，相当于集群的 “统一反向代理”），再通过 Ingress 资源定义路由规则（比如把www.xxx.com/api转发到后端的 nginx 服务）；Ingress Controller 仅通过 1 个端口对外暴露（可配合 LoadBalancer），所有服务的流量都走这个网关。
• 优势：① 仅暴露网关入口，后端服务无需直接对外，避免服务器 / 节点暴露；② 支持七层路由（HTTP/HTTPS）、统一管理 HTTPS 证书、限流 / 鉴权 / 灰度发布等企业级能力；③ 端口、域名集中管理，不会混乱。

3.1.5 发布操作

kubectl expose deployment nginx：基于名为nginx的 Deployment 创建 Service，Service 会自动关联这个 Deployment 管理的所有 Pod；

--port=80：设置 Service 在 K8s 集群内部暴露的端口为 80，集群里的其他服务可以用 “nginx-service:80” 访问 nginx；

--target-port=80：指定 Service 把流量转发到 Pod 的 80 端口（和 Pod 里 nginx 容器的监听端口保持一致）；

--name=nginx-service：给这个 Service 命名为nginx-service；

--type=NodePort：把 Service 类型设为 NodePort——K8s 会在集群所有节点上开放一个宿主机端口（默认 30000-32767 之间的随机数），外部可以用 “节点 IP + 这个宿主机端口” 直接访问 nginx。

最终，集群内通过 “nginx-service:80” 访问，集群外通过 “节点 IP+NodePort 端口” 访问，流量会经 Service 转发到 Pod 的 nginx 容器。

kubectl get pods,svc -o wide

kubectl delete svc <服务名>：删除指定的 Service。

结语

以上内容覆盖了 K8s 中服务部署、访问、管理的基础操作，从资源创建到清理的全流程逻辑，