#部署

#理解 Deployments

请参考 Kubernetes 官方文档：Deployments

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

Deployment 是 Kubernetes API 中用于管理 Pod 和 ReplicaSets 的对象。创建 Deployment 时，Kubernetes 会自动创建一个 ReplicaSet，然后由该 ReplicaSet 负责维持指定数量的 Pod 副本。

使用 Deployments，你可以：

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

其工作原理如下：

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

#创建 Deployments

#使用 CLI 创建 Deployment

#前提条件

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

#YAML 文件示例

# example-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Name of the Deployment
  labels:
    app: nginx # Labels for identification and selection
spec:
  replicas: 3 # Desired number of Pod replicas
  selector:
    matchLabels:
      app: nginx # Selector to match Pods managed by this Deployment
  template:
    metadata:
      labels:
        app: nginx # Pod's labels, must match selector.matchLabels
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2 # Container image
          ports:
            - containerPort: 80 # Container exposed port
          resources: # Resource limits and requests
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

#通过 YAML 创建 Deployment

# Step 1: Create Deployment via yaml
kubectl apply -f example-deployment.yaml

# Step 2: Check the Deployment status
kubectl get deployment nginx-deployment # View Deployment
kubectl get pod -l app=nginx # View Pods created by this Deployment

#使用 web console 创建 Deployment

#前提条件

获取 image 地址。image 的来源可以是平台管理员通过 toolchain 集成的 image repository，也可以是第三方平台的 image repository。

• 对于前者，管理员通常会将 image repository 分配给你的项目，你可以使用其中的 image。如果未找到所需的 image repository，请联系管理员进行分配。

• 如果是第三方平台的 image repository，请确保当前集群能够直接从中拉取 image。

• 如果 image registry 需要认证，则需要配置相应的 image pull secret。更多信息，请参见 将 ImagePullSecrets 添加到 ServiceAccount。

• 通过 OCI Connector 选择 image 时，还需要为 Connector proxy 选择一个 image pull Secret，或者确认该工作负载的 ServiceAccount 已经引用了该 Secret。这两种引用方式是二选一的。请参见 在 OCI Connector 中使用 ImagePullSecret。

#使用新的 web console 创建 Deployment

新的 web console 可以从不同视图暴露 Deployment 创建入口。请根据你是从项目范围还是从具体集群范围操作，选择合适的入口。

• Applications 视图：从当前项目开始。打开 Applications > Applications，选择目标 Cluster 和 Namespace，然后选择会创建 Deployment 的工作负载模型或创建流程。
• Clusters 视图：从具体集群开始。先打开目标集群，进入目标 namespace，然后导航到 Workloads > Deployments，点击 Create Deployment。

继续之前，请确认以下差异：

• 在 Applications 视图中，集群选择是项目范围应用工作流的一部分。
• 在 Clusters 视图中，由于你是从具体集群中进入，因此集群已经固定。
• 在 Applications 视图中，请确认 namespace 是否属于预期的项目范围。
• 在 Clusters 视图中，请确认该集群中的 namespace 侧资源是否已准备好供 Deployment 使用。

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

1. 在 Container Platform 左侧边栏中，导航到 Workloads > Deployments。

2. 点击 Create Deployment。

3. Select 或 Input 一个 image，然后点击 Confirm。

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

   Parameters	Description
   Replicas	定义 Deployment 中期望的 Pod 副本数量（默认值：1）。请根据工作负载需求进行调整。
   More > Update Strategy	配置用于零停机部署的 rollingUpdate 策略： Max surge（maxSurge）： 更新期间，允许超过期望副本数的最大 Pod 数量。 可接受绝对值（例如 2）或百分比（例如 20%）。 百分比计算方式：ceil(current_replicas × percentage)。 示例：当有 10 个副本时，计算结果 4.1 会取为 5。 Max unavailable（maxUnavailable）： 更新期间，允许临时不可用的最大 Pod 数量。 百分比值不能超过 100%。 百分比计算方式：floor(current_replicas × percentage)。 示例：当有 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

说明：在混合架构集群中部署单架构 image 时，请确保已正确配置 节点亲和性规则，以便进行 Pod 调度。

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

   Parameters	Description
   Volumes	将持久卷挂载到容器。支持的卷类型包括 PVC、ConfigMap、Secret、emptyDir、hostPath 等。实现细节请参见 Volume Mounting Guide。
   Pull Secret	对于私有 registry image，请使用包含该 registry 凭据的 Secret。对于 OCI Connector image，请选择 Connector proxy 的 image pull Secret，或者使用已经引用该 Secret 的 ServiceAccount。来自平台集成的 image 将继续使用其关联凭据。请参见 在 OCI Connector 中使用 ImagePullSecret。
   Close Grace Period	Pod 在接收到终止信号后允许完成优雅关闭的时长（默认值：30s）。 - 在此期间，Pod 会完成正在处理中的请求并释放资源。 - 设置为 0 会强制立即删除（SIGKILL），这可能会导致请求中断。

2. 节点亲和性规则

Parameters	Description
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

     Parameters	Description
     Bandwidth Limits	为 Pod 网络流量强制执行 QoS： Egress rate limit：最大出站流量速率（例如 10Mbps）。 Ingress rate limit：最大入站流量速率。
     Subnet	从预定义的子网池中分配 IP。如果未指定，则使用 namespace 的默认子网。
     Static IP Address	为 Pod 绑定持久 IP 地址： 多个 Deployment 中的 Pod 可以声明同一个 IP，但同一时刻只能有一个 Pod 使用它。 关键：静态 IP 数量必须 ≥ Pod 副本数。

   • Calico

     Parameters	Description
     Static IP Address	分配固定 IP，并强制唯一性： 每个 IP 在集群中只能绑定一个 Pod。 关键：静态 IP 数量必须 ≥ Pod 副本数。

#操作步骤 - 配置容器

1. 在 Container 区域中，按照以下说明配置相关信息。

   Parameters	Description
   Resource Requests & Limits	Requests：容器运行所需的最小 CPU/内存。 Limits：容器运行期间允许使用的最大 CPU/内存。有关单位定义，请参见 Resource Units。 Namespace overcommit ratio： Without overcommit ratio： 如果存在 namespace 资源配额：容器 requests/limits 继承 namespace 默认值（可修改）。 无 namespace 配额：没有默认值；使用自定义 Request。 With overcommit ratio： Requests 会自动计算为 Limits / Overcommit ratio（不可修改）。 约束： Request ≤ Limit ≤ Namespace 配额上限。 更改 overcommit ratio 后需要重建 Pod 才会生效。 启用 overcommit ratio 后将禁用手动配置 request。 没有 namespace 配额 → 没有容器资源约束。
   Extended Resources	配置集群中可用的扩展资源（例如 vGPU、pGPU）。
   Volume Mounts	持久化存储配置。请参见 Storage Volume Mounting Instructions。 操作： 已有 pod 卷：点击 Add 没有 pod 卷：点击 Add & Mount 参数： mountPath：容器文件系统路径（例如 /data） subPath：卷内的相对文件/目录路径。 对于 ConfigMap/Secret：选择特定键 readOnly：以只读方式挂载（默认值：读写） 请参见 Kubernetes Volumes。
   Ports	暴露容器端口。 示例：暴露名为 redis 的 TCP 端口 6379。 字段： 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" 请参见 Defining Commands。
   More > Environment Variables	静态值：直接键值对 动态值：引用 ConfigMap/Secret 键、pod 字段（fieldRef）、资源指标（resourceFieldRef） 说明：环境变量会覆盖 image/配置文件中的设置。
   More > Referenced ConfigMaps	将整个 ConfigMap/Secret 注入为环境变量。支持的 Secret 类型：Opaque、kubernetes.io/basic-auth。
   More > Health Checks	Liveness Probe：检测容器健康状态（失败时重启） Readiness Probe：检测服务可用性（失败时从 endpoints 中移除） 请参见 Health Check Parameters。
   More > Log Files	配置日志路径： - 默认：收集 stdout - 文件模式：例如 /var/log/*.log 要求： 存储驱动 overlay2：默认支持 devicemapper：需要手动将 EmptyDir 挂载到日志目录 Windows 节点：确保已挂载父目录（例如 c:/a/b/c/*.log 对应 c:/a）
   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 中有 >1 个应用容器且至少有 1 个 init container。
      • 单应用容器 Pod 不允许删除。

3. 点击 Create。

#参考信息

#存储卷挂载说明

#健康检查

• 健康检查 YAML 文件示例
• web console 中的健康检查配置参数

#何时在 Applications 视图中使用 Deployment

当工作负载主要是无状态的，并且应通过副本 Pod 替换来更新，而不是依赖稳定标识或每个副本的持久状态时，请使用 Deployment。

通常在以下情况下，Deployment 更适合：

• 副本标识在替换后不需要保持稳定
• 工作负载应通过可互换的 Pod 进行横向扩展
• 应用交付更倾向于使用滚动更新行为

如果工作负载依赖稳定的序号标识或每个副本的持久存储，请改为查看 StatefulSets。

#提交前的 Deployment 检查点

在 Applications 视图中创建或更新 Deployment 之前，请仔细检查以下内容：

• 所选项目、集群和 namespace 是否为预期的运行范围
• 副本数量是否与预期的可用性目标一致
• 所选 image 和拉取凭据在目标集群中是否有效
• 引用的 ConfigMap、Secret、PVC 或 ServiceAccount 是否已存在于同一 namespace 中
• 资源 requests、limits 和探针是否与应用真实的启动和健康行为一致
• 发布策略是否适合该工作负载和流量模式

#管理 Deployments

#使用 CLI 管理 Deployment

#查看 Deployment

• 检查 Deployment 是否已创建。

  kubectl get deployments

• 获取 Deployment 的详细信息。

  kubectl describe deployments

#更新 Deployment

按照以下步骤更新 Deployment：

1. 将 nginx Pod 更新为使用 nginx:1 .16.1 image。

   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. 查看 rollout 状态，运行：

   kubectl rollout status deployment/nginx-deployment

   运行 kubectl get rs 可以看到 Deployment 通过创建新的 ReplicaSet 并将其扩容到 3 个副本，同时将旧的 ReplicaSet 缩减到 0 个副本，从而完成了 Pod 更新。

   kubectl get rs

   运行 get pods 现在应该只会显示新的 Pod：

   kubectl get pods

当更改 image 或 OCI Connector 时，也请检查 Pod 模板的 Pull Secret、serviceAccountName 和 token 有效期。更新后，请验证新的 ReplicaSet 和 Pod：检查 Connector 注解，确认实际 Pod image 已重写为 Connector proxy，等待 Pod 变为 Running，并查看 Events。

#扩缩容 Deployment

你可以使用以下命令对 Deployment 进行扩缩容：

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

#回滚 Deployment

• 假设你在更新 Deployment 时出现了拼写错误，把 image 名称写成了 nginx:1.161，而不是 nginx:1.16.1：

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

• rollout 会卡住。你可以通过检查 rollout 状态来验证这一点：

  kubectl rollout status deployment/nginx-deployment

#删除 Deployment

删除 Deployment 时，也会删除其托管的 ReplicaSet 和所有关联的 Pod。

kubectl delete deployment <deployment-name>

#使用 web console 管理 Deployment

#查看 Deployment

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

1. 在 Container Platform 中，导航到 Workloads > Deployments。
2. 找到要查看的 Deployment。
3. 点击 Deployment 名称，查看 Details、Topology、Logs、Events、Monitoring 等信息。

#更新 Deployment

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

更新操作会让 Deployment 保持在当前的 cluster 和 namespace 中。如果工作负载必须运行在不同的 cluster 或 namespace 中，请在目标范围内创建或应用一个单独的 Deployment，而不要把更新当作迁移操作。

在提交更新之前，请确认对 image、探针、环境变量、端口、卷挂载或资源设置的更改不会破坏正在运行的工作负载。

对 Pod 模板的更改可能会触发新的 rollout。成功的更新请求本身并不意味着 rollout 已经健康。只有当新的 Pod 修订版本正确调度、变为就绪，并且替换了之前的修订版本而没有导致工作负载不可用时，实际效果才会体现出来。

在 web console 中更改 image 或 OCI Connector 时，也请检查 Pull Secret、工作负载 ServiceAccount 和 token 有效期。确认最终生成的 Pod 使用了 Connector proxy image 并完成 rollout；仅更新成功并不能验证 image 拉取是否正常。

#删除 Deployment

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

删除后，请验证 Deployment 已不再出现在列表中，并确认需要保留的独立 Service、ConfigMap、Secret 或 PVC 仍然存在。

#使用 CLI 排障

当 Deployment 出现问题时，可以采用以下常见排障方法。

对于 OCI Connector image 拉取失败，请按以下顺序检查：

1. 检查 Pod 模板中的 connectors.<baseDomain>/connectors 注解。
2. 检查 spec.imagePullSecrets 以及工作负载 ServiceAccount 的 imagePullSecrets。
3. 检查实际 Pod image 是否已重写为 Connector proxy。
4. 检查 Pod 状态和 Events。

如果 Events 中显示原始 HTTP registry 出现 HTTPS 错误，则工作负载可能没有进入 Connector proxy 路径。请在更改 registry 运行时设置之前，检查 Connector proxy Secret、ServiceAccount 和 token。请参见 在 OCI Connector 中使用 ImagePullSecret。

#检查 Deployment 状态

kubectl get deployment nginx-deployment
kubectl describe deployment nginx-deployment # View detailed events and status

#检查 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> # View logs for a specific container
kubectl logs <pod-name> --previous         # View logs for the previously terminated container

#进入 Pod 进行调试

kubectl exec -it <pod-name> -- /bin/bash # Enter the container shell

#检查健康配置

确保 livenessProbe 和 readinessProbe 已正确配置，并且应用的健康检查端点能够正常响应。探针失败排障

#检查资源限制

确保容器的 resource requests 和 limits 设置合理，并且容器没有因为资源不足而被杀死。