#Deployments

#Understanding Deployments

参考官方 Kubernetes 文档：Deployments

Deployment 是 Kubernetes 中一种高级工作负载资源，用于声明式地管理和更新应用的 Pod 副本。它提供了一种强大且灵活的方式来定义应用的运行方式，包括维护多少副本以及如何安全地执行滚动更新。

Deployment 是 Kubernetes API 中管理 Pods 和 ReplicaSets 的对象。当你创建一个 Deployment 时，Kubernetes 会自动创建一个 ReplicaSet，负责维护指定数量的 Pod 副本。

使用 Deployments 可以实现：

• 声明式管理：定义应用的期望状态，Kubernetes 自动确保集群的实际状态与期望状态一致。
• 版本控制与回滚：跟踪 Deployment 的每个修订版本，出现问题时可以轻松回滚到之前的稳定版本。
• 零停机更新：使用滚动更新策略逐步更新应用，无服务中断。
• 自我修复：当 Pod 崩溃、终止或从节点移除时，Deployment 会自动替换 Pod 实例，确保指定数量的 Pod 始终可用。

工作原理：

1. 通过 Deployment 定义应用的期望状态（例如，使用哪个镜像，运行多少副本）。
2. Deployment 创建 ReplicaSet，确保指定数量的 Pod 正在运行。
3. ReplicaSet 创建并管理实际的 Pod 实例。
4. 当更新 Deployment（例如更改镜像版本）时，Deployment 会创建新的 ReplicaSet，并根据预定义的滚动更新策略逐步替换旧 Pod，直到所有新 Pod 运行，然后删除旧的 ReplicaSet。

#Creating Deployments

#使用 CLI 创建 Deployment

#前提条件

• 确保已配置并连接到集群的 kubectl。

#YAML 文件示例

# example-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Deployment 名称
  labels:
    app: nginx # 用于识别和选择的标签
spec:
  replicas: 3 # 期望的 Pod 副本数
  selector:
    matchLabels:
      app: nginx # 选择器，匹配该 Deployment 管理的 Pods
  template:
    metadata:
      labels:
        app: nginx # Pod 的标签，必须匹配 selector.matchLabels
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2 # 容器镜像
          ports:
            - containerPort: 80 # 容器暴露端口
          resources: # 资源限制和请求
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

#通过 YAML 创建 Deployment

# 第一步：通过 yaml 创建 Deployment
kubectl apply -f example-deployment.yaml

# 第二步：检查 Deployment 状态
kubectl get deployment nginx-deployment # 查看 Deployment
kubectl get pod -l app=nginx # 查看该 Deployment 创建的 Pods

#使用 Web 控制台创建 Deployment

#前提条件

获取镜像地址。镜像来源可以是平台管理员通过工具链集成的镜像仓库，也可以是第三方平台的镜像仓库。

• 对于前者，管理员通常会将镜像仓库分配给你的项目，你可以使用其中的镜像。如果找不到所需的镜像仓库，请联系管理员分配。

• 如果是第三方平台的镜像仓库，确保当前集群可以直接拉取该镜像。

• 如果镜像仓库需要认证，需配置相应的镜像拉取密钥。详情见 为 ServiceAccount 添加 ImagePullSecrets。

#操作步骤 - 配置基本信息

1. 在 Container Platform，左侧导航栏进入 Workloads > Deployments。

2. 点击 Create Deployment。

3. 选择或输入镜像，点击 Confirm。

4. 在 Basic Info 区域，配置 Deployment 工作负载的声明式参数：

   参数	说明
   Replicas	定义 Deployment 中期望的 Pod 副本数（默认：1）。根据工作负载需求调整。
   More > Update Strategy	配置 rollingUpdate 策略，实现零停机部署： Max surge (maxSurge)： 更新时允许超过期望副本数的最大 Pod 数量。 支持绝对值（如 2）或百分比（如 20%）。 百分比计算方式：ceil(当前副本数 × 百分比)。 示例：10 副本时，4.1 → 5。 Max unavailable (maxUnavailable)： 更新时允许不可用的最大 Pod 数量。 百分比值不可超过 100%。 百分比计算方式：floor(当前副本数 × 百分比)。 示例：10 副本时，4.9 → 4。 注意事项： 1. 默认值：若未显式设置，maxSurge=1，maxUnavailable=1。 2. 非运行状态的 Pod（如 Pending、CrashLoopBackOff）视为不可用。 3. 同时约束： maxSurge 和 maxUnavailable 不能同时为 0 或 0%。 若两者百分比均计算为 0，Kubernetes 会强制设置 maxUnavailable=1 以保证更新进度。 示例： 对于 10 副本的 Deployment： maxSurge=2 → 更新期间总 Pod 数为 10 + 2 = 12。 maxUnavailable=3 → 最小可用 Pod 数为 10 - 3 = 7。 确保在控制滚动更新的同时保证可用性。

#操作步骤 - 配置 Pod

注意：在混合架构集群中部署单架构镜像时，需确保正确配置 Node Affinity 规则 以实现 Pod 调度。

1. 在 Pod 区域，配置容器运行时参数及生命周期管理：

   参数	说明
   Volumes	挂载持久卷到容器。支持的卷类型包括 PVC、ConfigMap、Secret、emptyDir、hostPath 等。具体实现见 卷挂载指南。
   Pull Secret	仅在从第三方镜像仓库（通过手动输入镜像 URL）拉取镜像时必需。 注意：用于认证拉取受保护镜像的 Secret。
   Close Grace Period	Pod 接收到终止信号后允许的优雅关闭时间（默认：30s）。 - 在此期间，Pod 会完成正在处理的请求并释放资源。 - 设置为 0 会强制立即删除（SIGKILL），可能导致请求中断。

2. Node Affinity 规则

参数	说明
More > Node Selector	限制 Pod 只能调度到带有特定标签的节点（例如 kubernetes.io/os: linux）。
More > Affinity	定义基于现有条件的细粒度调度规则。 Affinity 类型： Pod Affinity：将新 Pod 调度到运行特定 Pod 的节点（相同拓扑域）。 Pod Anti-affinity：避免新 Pod 与特定 Pod 共存。 执行模式： requiredDuringSchedulingIgnoredDuringExecution：仅当规则满足时才调度 Pod。 preferredDuringSchedulingIgnoredDuringExecution：优先满足规则的节点，但允许例外。 配置字段： topologyKey：定义拓扑域的节点标签（默认：kubernetes.io/hostname）。 labelSelector：通过标签查询过滤目标 Pod。

3. 网络配置

   • Kube-OVN

     参数	说明
     Bandwidth Limits	对 Pod 网络流量实施 QoS： 出站速率限制：最大出站流量速率（如 10Mbps）。 入站速率限制：最大入站流量速率。
     Subnet	从预定义子网池分配 IP。若未指定，使用命名空间默认子网。
     Static IP Address	绑定持久 IP 地址给 Pod： 多个 Deployment 的 Pod 可声明相同 IP，但同一时间仅允许一个 Pod 使用。 关键：静态 IP 数量必须 ≥ Pod 副本数。

   • Calico

     参数	说明
     Static IP Address	分配固定 IP，严格唯一： 每个 IP 只能绑定给集群中的一个 Pod。 关键：静态 IP 数量必须 ≥ Pod 副本数。

#操作步骤 - 配置容器

1. 在 Container 区域，参考以下说明配置相关信息。

   参数	说明
   Resource Requests & Limits	Requests：容器运行所需的最小 CPU/内存。 Limits：容器运行时允许的最大 CPU/内存。单位定义见 资源单位。 命名空间超售比： 无超售比： 若存在命名空间资源配额，容器请求/限制继承命名空间默认值（可修改）。 无命名空间配额时，无默认值，自定义请求。 有超售比： 请求自动计算为 Limits / 超售比（不可修改）。 约束条件： 请求 ≤ 限制 ≤ 命名空间配额最大值。 超售比变更需重建 Pod 生效。 超售比启用时禁止手动配置请求。 无命名空间配额时无容器资源限制。
   Extended Resources	配置集群可用的扩展资源（如 vGPU、pGPU）。
   Volume Mounts	持久存储配置。详见 存储卷挂载说明。 操作： 已有 Pod 卷：点击 Add 无 Pod 卷：点击 Add & Mount 参数： mountPath：容器文件系统路径（如 /data） subPath：卷内相对文件/目录路径。 对于 ConfigMap/Secret：选择特定键 readOnly：只读挂载（默认读写） 参考 Kubernetes 卷。
   Ports	暴露容器端口。 示例：暴露 TCP 端口 6379，名称为 redis。 字段： protocol：TCP/UDP Port：暴露端口（如 6379） name：符合 DNS 规范的标识符（如 redis）
   Startup Commands & Arguments	覆盖默认 ENTRYPOINT/CMD： 示例 1：执行 top -b - Command：["top", "-b"] - 或 Command：["top"]，Args：["-b"] 示例 2：输出 $MESSAGE： /bin/sh -c "while true; do echo $(MESSAGE); sleep 10; done" 详见 定义命令。
   More > Environment Variables	静态值：直接键值对 动态值：引用 ConfigMap/Secret 键，Pod 字段（fieldRef），资源指标（resourceFieldRef） 注意：环境变量会覆盖镜像或配置文件中的设置。
   More > Referenced ConfigMaps	将整个 ConfigMap/Secret 注入为环境变量。支持的 Secret 类型：Opaque、kubernetes.io/basic-auth。
   More > Health Checks	Liveness Probe：检测容器健康（失败时重启） Readiness Probe：检测服务可用性（失败时从 Endpoints 移除） 详见 健康检查参数。
   More > Log Files	配置日志路径： - 默认收集 stdout - 文件模式，如 /var/log/*.log 要求： 存储驱动 overlay2：默认支持 devicemapper：需手动挂载 EmptyDir 到日志目录 Windows 节点：确保父目录已挂载（如 c:/a 对应 c:/a/b/c/*.log）
   More > Exclude Log Files	排除特定日志收集（如 /var/log/aaa.log）。
   More > Execute before Stopping	容器终止前执行命令。 示例：echo "stop" 注意：命令执行时间须短于 Pod 的 terminationGracePeriodSeconds。

2. 点击右上角的 Add Container 或 Add Init Container。

   参考 Init Containers。 Init Container：

   1. 在应用容器之前启动（顺序执行）。
   2. 完成后释放资源。
   3. 允许删除条件：
      • Pod 有多个应用容器且至少有一个 Init Container。
      • 单应用容器的 Pod 不允许删除 Init Container。

3. 点击 Create。

#参考信息

#存储卷挂载说明

#健康检查

• 健康检查 YAML 文件示例
• Web 控制台健康检查配置参数

#Managing Deployments

#使用 CLI 管理 Deployment

#查看 Deployment

• 检查 Deployment 是否已创建。

  kubectl get deployments

• 获取 Deployment 详情。

  kubectl describe deployments

#更新 Deployment

按照以下步骤更新 Deployment：

1. 将 nginx Pods 更新为使用 nginx:1 .16.1 镜像。

   kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

   或使用以下命令：

   kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

   也可以编辑 Deployment，将 .spec.template.spec.containers[0].image 从 nginx:1.14.2 改为 nginx:1.16.1：

   kubectl edit deployment/nginx-deployment

2. 查看滚动更新状态：

   kubectl rollout status deployment/nginx-deployment

   运行 kubectl get rs 查看 Deployment 通过创建新 ReplicaSet 并扩容到 3 副本，同时缩容旧 ReplicaSet 到 0 副本来更新 Pods。

   kubectl get rs

   运行 kubectl get pods 应只显示新 Pods：

   kubectl get pods

#扩缩 Deployment

使用以下命令扩缩 Deployment：

kubectl scale deployment/nginx-deployment --replicas=10

#回滚 Deployment

• 假设更新 Deployment 时输入镜像名错误，将 nginx:1.16.1 写成了 nginx:1.161：

  kubectl set image deployment/nginx-deployment nginx=nginx:1.161

• 滚动更新会卡住。可通过检查滚动状态验证：

  kubectl rollout status deployment/nginx-deployment

#删除 Deployment

删除 Deployment 会同时删除其管理的 ReplicaSet 及所有关联的 Pods。

kubectl delete deployment <deployment-name>

#使用 Web 控制台管理 Deployment

#查看 Deployment

可查看 Deployment 以获取应用信息。

1. 在 Container Platform，导航至 Workloads > Deployments。
2. 找到要查看的 Deployment。
3. 点击 Deployment 名称查看 详情、拓扑、日志、事件、监控等。

#更新 Deployment

1. 在 Container Platform，导航至 Workloads > Deployments。
2. 找到要更新的 Deployment。
3. 在 Actions 下拉菜单中选择 Update，进入编辑 Deployment 页面。

#删除 Deployment

1. 在 Container Platform，导航至 Workloads > Deployments。
2. 找到要删除的 Deployment。
3. 在 Actions 下拉菜单中点击操作列的 Delete 按钮并确认。

#使用 CLI 进行故障排查

当 Deployment 遇到问题时，以下是常用的排查方法。

#检查 Deployment 状态

kubectl get deployment nginx-deployment
kubectl describe deployment nginx-deployment # 查看详细事件和状态

#检查 ReplicaSet 状态

kubectl get rs -l app=nginx
kubectl describe rs <replicaset-name>

#检查 Pod 状态

kubectl get pods -l app=nginx
kubectl describe pod <pod-name>

#查看日志

kubectl logs <pod-name> -c <container-name> # 查看指定容器日志
kubectl logs <pod-name> --previous         # 查看上一个终止容器的日志

#进入 Pod 进行调试

kubectl exec -it <pod-name> -- /bin/bash # 进入容器 Shell

#检查健康检查配置

确保 livenessProbe 和 readinessProbe 配置正确，且应用的健康检查接口响应正常。探针失败排查

#检查资源限制

确保容器资源请求和限制合理，避免因资源不足导致容器被杀死。