k8s操作（三）

目录

一，3种发布方式

[1.1蓝绿发布（Blue-Green Deployment）](#1.1蓝绿发布（Blue-Green Deployment）)

[1.1.1. 定义](#1.1.1. 定义)

[1.1.2. 核心原理](#1.1.2. 核心原理)

[1.1.3. 核心特点](#1.1.3. 核心特点)

[1.1.4. 适用场景](#1.1.4. 适用场景)

[1.2，滚动发布（Rolling Update）](#1.2，滚动发布（Rolling Update）)

[1.2.1. 定义](#1.2.1. 定义)

[1.2.2. 核心原理](#1.2.2. 核心原理)

[1.2.3. 核心特点](#1.2.3. 核心特点)

[1.2.4. 适用场景](#1.2.4. 适用场景)

[1.3，金丝雀发布（Canary Deployment）](#1.3，金丝雀发布（Canary Deployment）)

[1.3.1. 定义](#1.3.1. 定义)

[1.3.2. 核心原理](#1.3.2. 核心原理)

[1.3.3. 核心特点](#1.3.3. 核心特点)

[1.3.4. 适用场景](#1.3.4. 适用场景)

[二，Kubernetes 操作管理](#二，Kubernetes 操作管理)

2.1，管理操作分类

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

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

2.2陈述式资源管理方法

容器内部调试

[删除 web-nginx 的 Deployment（自动级联删 Pod、ReplicaSet）](#删除 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****操作管理

kubectl 命令补全功能
yum -y install bash-completion
echo "source <(kubectl completion bash)" >> /etc/profile
source /etc/profile

2.1，管理操作分类

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

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

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

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

2.2陈述式资源管理方法

kubectl get all

• n 指定命名空间
• o 指定输出格式
  -- all - namespaces ：显示所有命名空间
  -- show - labels ：显示所有标签
• l app=nginx ：筛选指定标签的资源

命名空间操作
kubectl create ns app 创建命名空间
kubectl delete namespace app 删除命名空间

避免干扰到其他环境
创建 Deployment （副本控制器）
它是 Pod 的控制器 ，核心作用是管理 Pod 的全生命周期：

• 帮你创建指定数量的 Pod；

• 自动维护 Pod 的 "健康状态"：如果某个 Pod 挂了，Deployment 会自动重建新的 Pod；

• 支持版本升级、回滚：比如你之前接触的 "滚动发布"，就是通过 Deployment 实现的；

• 你之前删除 Deployment 时，它管理的 Pod、ReplicaSet（Pod 的副本集）会被自动清理。

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

：在kube-public命名空间下，创建管理 nginx 的 Deployment，自动启动对应 Pod（无状态服务的基础部署）。

kubectl get pods -n kube-public

：确认 Pod 是否处于Running状态，判断服务是否启动成功。

# 查看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，创建阶段

kubectl create deployment nginx -- image=nginx:1.14 --port=80 --replicas=3

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

3.1.2，发布阶段

将资源暴露为 Service
先理解多个端口的各个意思

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）。
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service
--type=NodePort

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 中服务部署、访问、管理的基础操作，从资源创建到清理的全流程逻辑，