Deployment和污点、容忍度

---

一、污点、容忍度

Kubernetes（k8s）中的“污点”（Taints）和“污点容忍”（Tolerations）是用于节点调度控制的一种机制。它们提供了一种方法来影响 Pod 被调度到节点上的策略，通过这种方式，你可以防止特定的 Pod 被调度到不合适的节点，或仅允许特定的 Pod 被调度到指定的节点。

污点（Taints）

污点是应用在节点上的属性，它告诉调度器不可以将 Pods 安排到这个节点上，除非该 Pod 可以容忍该污点。每个污点包含三个属性：

1. 键（Key） ：一个唯一标识污点的名称。

2. 值（Value） ：键的附加信息。

3. 效应（Effect） ：当污点存在而 Pod 无法容忍时，会产生的影响。主要有以下三种类型：

   • NoSchedule: 调度器不会将 Pod 调度到有此污点的节点上。
   • PreferNoSchedule: 调度器会尽量不将 Pod 调度到有此污点的节点上，但不是绝对的。
   • NoExecute: 除了不允许新的 Pod 调度到节点上，还会驱逐当前不容忍此污点的 Pod。

污点容忍（Tolerations）

Pod 可以有相应的容忍来匹配节点的污点，这允许 Pod 在有污点的节点上运行。容忍由键、值和效果组成，并必须匹配节点上的污点才能调度 Pod 到该节点。

应用场景

1. 隔离工作负载：通过使用污点和容忍，可以确保特定类型的工作负载不会混合在同一节点上。例如，隔离开发和生产环境下的负载。
2. 优先处理关键任务：可以通过设置污点来保护关键节点，使得只有特定的关键任务 Pod 可以被调度到这些节点上。
3. 管理资源和节点健康状况：用来限制访问资源紧张的节点或正在进行维护的节点。
4. 节点动态维护：在节点需要维护时，使用 NoExecute 污点来驱逐不需要的工作负载。

实际操作

配置污点
标记污点

kubectl taint node slave node-type=production:NoShchedule

注意需要选择污点类型。

删除污点

kubectl taint node slave node-type=production:NoShchedule-

查看污点

kubectl describe node slave1|grep -i Taints

当我在slave1上配置了污点之后，master主动将pod全部调度到slave2上。

配置容忍度

apiVersion: apps/v1  
kind: ReplicaSet  
metadata:  
  name: my-replicaset  
spec:  
  replicas: 10  
  selector:  
    matchLabels:  
      app: myapp  
  template:  
    metadata:  
      labels:  
        app: myapp  
    spec:  
      containers:  
      - name: mycontainer  
        image: harbor.hiuiu.com/nginx/nginx:1.21.5  
        ports:  
        - containerPort: 80
      tolerations:
      - key: "node-type"
        operator: "Equal"
        value: "production"
        effect: "NoSchedule"

由于node2节点并没有配置污点，所以master会随机调度到两个节点上。

二、Deployment

在 Kubernetes 中，Deployment 是一种用于部署和管理应用程序的控制器，它提供了一种声明式的方式来创建和管理 Pod 和集群的相关资源。Deployment 是应用管理中最常用的资源类型之一，因为它提供了许多强大的功能用来维护和更新应用程序的状态。

核心组件

1. 控制器模式（Controller Pattern） ：

   • Kubernetes 使用控制器模式来实现资源的自动化管理。Deployment 控制器是 Kubernetes 控制平面的一部分，负责监视 Deployment 对象的状态，并确定需要进行哪些操作以达到期望状态。

2. 副本集（ReplicaSet） ：

   • Deployment 的主要作用是管理 Pod 的副本集。ReplicaSet 确保指定数量的 Pod 副本在任何给定时间内都是运行的。Deployment 创建并管理这些 ReplicaSet。
   • 每次更新 Deployment 时，Deployment 控制器创建一个新的 ReplicaSet，并通过控制旧的和新的 ReplicaSet 的标签选择器来逐步增加新 Pod 的副本数量，减少旧 Pod 的副本数量。

特性和功能

1. 声明式更新：Deployment 允许用户声明所需的状态（如应用程序版本或副本数），Kubernetes 将自动调整集群以匹配这个状态。这种机制能够确保更新过程是一致的并且易于管理。
2. 滚动更新：将应用程序从一个版本更新到另一个版本是 Deployment 最常用的功能之一。Deployment 可以以控制的速度逐步替换旧版本的 Pod，以便在发生问题时可以轻松回滚。
3. 回滚更新：如果新版本的更新出现问题，可以轻松地滚回到之前的一个稳定版本。Kubernetes 会自动记录 Deployment 的历史版本，以便于回滚。
4. 扩展和缩减：使用 Deployment 可以轻松调整应用的副本数，这意味着可以轻松地应对流量的变化。
5. 自愈（自愈合） ：如果一个 Pod 出现故障，Deployment 会基于定义的状态即刻进行恢复操作，确保应用程序始终处于所需的状态。
6. 多副本控制：确保集群中始终有指定数量的 Pod 正在运行，此功能对于负载均衡和高可用性至关重要。

应用场景

1. 持续交付和集成：在 CI/CD 流水线中，Deployment 常用于自动发布新应用版本，利用其滚动更新和回滚功能简化管理和发布过程。
2. 负载扩展：对于流量波动较大的应用程序，可以通过调整 Deployment 的副本数量来快速扩容或缩容。
3. 高可用性：使用 Deployment 保证跨多个节点部署 Pod，增加应用的冗余性和可用性。
4. 测试和实验：可以快速部署新版本的应用以进行测试和实验，同时确保即便在实验中出现问题也可以快速回滚。
5. 应用稳定性管理：以自愈能力来增强应用的鲁棒性，在节点或 Pod 故障时自动恢复到正常状态。

Deployment 在 Kubernetes 集群管理中占据核心位置，它为开发和运维人员提供了一种简化且高效的方式来管理容器化应用的生命周期。它不仅能简化应用的部署流程，还能带来稳健性和灵活性。

实际操作

创建deployment

创建deployment一般是用yaml文件创建的。
查看配置

kubectl describe deployments.apps  +名字

查看状态

kubectl rollout status deployment/名字

查看当前命名空间下的deployment对象资源

kubectl get deployments.apps
kubectl get rs
kubectl get pod

配置文件

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: nginx-deployment  
  labels:  
    app: nginx-dep  
spec:  
  replicas: 10  
  selector:  
    matchLabels:  
      app: nginx  
  template:  
    metadata:  
      labels:  
        app: nginx  
    spec:  
      containers:  
      - name: nginx  
        image: harbor.hiuiu.com/nginx/nginx:1.21.5  
        ports:  
        - containerPort: 80

这里构建pod的流程是先构建ReplicaSet，然后由副本集构建下面的pod。观察各个资源对象的名字就可以知道。

判断deployment升级

在 Kubernetes 中，Deployment 判断是否需要升级及进行升级的过程是通过对比期望状态和当前状态来实现的。该过程涉及以下几个关键环节：

比较期望状态和现有状态

1. 期望状态：由用户通过 YAML/JSON 文件定义，描述应用的期望状态（包括镜像版本、配置、环境变量等）。
2. 当前状态：由 Kubernetes 控制平面实时维护，表示集群中相关资源的实际状态。

当这两者之间存在差异时（例如改变镜像版本、修改副本数量或调整环境变量等），Kubernetes 就会认为需要进行一次更新或升级操作。

如何确定需要升级

• 版本变更：如果 Deployment 配置的容器镜像版本有所变化（即 .spec.template.spec.containers[].image 发生变化）。
• 配置变更：任何 Pod 模板中的配置变更（如环境变量、端口定义、资源限制等）都会触发新的 ReplicaSet 的创建。
• 副本数变更：改变 .spec.replicas（Pod副本数）会直接导致 Deployment 动态调整正在运行的 Pod 数量。

检测和执行升级

1. 检测变更：Deployment 控制器会监控与 Deployment 关联的所有资源。当检测到变更时，控制器会开始执行升级过程。

2. 滚动更新：

   • Deployment 创建一个新的 ReplicaSet 来部署新的 Pod 模板版本。
   • 逐渐增加新的 ReplicaSet 中 Pod 的数量，同时减少旧 ReplicaSet 中 Pod 的数量，从而实现平滑过渡。

3. 回滚支持：在升级过程中，如果检测到任何问题（例如健康检查失败、Pod 启动失败等），可以自动或手动回滚到前一个稳定的版本。
   使用该命令kubectl rollout status deployment/nginx-deployment查看升级状态

滚动更新

方法：

1. vim 修改 YAML 文件

   • 使用命令行文本编辑器 vim 编辑一个 YAML 文件，通常是用来手动更新 Kubernetes 资源的配置。编辑器打开后，你可以手动更改 Deployment 的配置，例如更新镜像版本。

2. ​kubectl set image deployment.v1.apps/nginx-deployment nginx1=镜像名​

   • 这个命令使用 kubectl 直接在命令行中更新 Deployment 中指定容器的镜像版本。
   • deployment.v1.apps/nginx-deployment 指定了要更新的 Deployment 资源的类型和名称。

3. ​kubectl edit deployment/nginx-deployment​

   • 这个命令使用默认的命令行文本编辑器（通常是 vim）来直接编辑 Kubernetes 中现有的 Deployment 资源。
   • 它会拉取当前集群中 nginx-deployment 的 YAML 配置文件，你可以手动修改例如镜像版本、资源限制等部署配置。
   • 保存并退出编辑器后，Kubernetes 会应用这些更改。
     

使用场景

• ​kubectl set image​：
  用于快速更新 Deployment 中的镜像版本。这种方式快捷且减少可能的手动错误，但只是更新镜像，不能进行其他更复杂的配置更改。
• ​kubectl edit​：
  用于需要对 Deployment 进行更细粒度的修改时，不仅可以更新镜像，还有更多关于应用配置的控制，类似于直接修改配置文件。

实验效果
滚动更新前：

滚动更新：

滚动更新后：

滚动更新策略

在 Kubernetes 中，自定义更新策略可以决定在应用更新过程中 Pod 的替换方式。这些策略是通过 Deployment 中的 strategy 字段配置的，主要有两种类型：Recreate 和 RollingUpdate。

1. Recreate 策略
   在使用 Recreate 策略时，Kubernetes 会先终止旧版本的所有 Pod 然后再创建新版本的 Pod。这种策略适用于不需要保持服务可用性或在旧版本终止后新版本启动间允许短暂停机的情况。

   spec:  
     strategy:  
       type: Recreate  
   

2. RollingUpdate 策略
   RollingUpdate 策略通过逐步替换旧版本的 Pod 为新版本来更新服务，确保在整个更新过程中，服务始终保持可用状态。这是默认的更新策略，通常适用于需要保持高可用性的应用。

   • maxSurge: 控制在更新过程中可超出的最大副本数量。可以是绝对数量，或是占期望副本数的百分比。
   • maxUnavailable: 控制在更新过程中允许的最大不可用副本数量。同样可以是绝对数量或百分比。

   例如，配置为：

   spec:  
     strategy:  
       type: RollingUpdate  
       rollingUpdate:  
         maxSurge: 50%         # 超过的最大副本数允许是总副本数的 50%  
         maxUnavailable: 50%   # 更新过程中允许有 50% 的副本不可用  
   

用法解释

• Recreate:

  • 适合于没有客户端访问的应用，或者可以承受短暂中断的情况。
  • 更新过程中会出现停机，因为旧的全部停止后再启动新的。

• RollingUpdate:

  • 适合于需要提供持续服务的应用。
  • 最大努力保持服务的可用性，通过逐步替换 Pod 的方式进行。
  • maxSurge 和 maxUnavailable 可以灵活配置，以优化更新速度与服务可用性之间的平衡。

常见命令

1. 查看升级历史

   kubectl rollout history deployment/nginx-deployment  
   

   • 用于查看指定 Deployment 的版本历史记录，包括每个版本的修订号和一些摘要信息。

2. 回滚到指定版本

   kubectl rollout undo deployment/nginx-deployment --to-revision=1  
   

   • 用于将 Deployment 回滚到指定的历史版本。--to-revision=1 指定回滚到版本 1。

3. 动态缩放

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

   • 用于动态调整 Deployment 的 Pod 副本数，将其修改为 10 个。
   • 也可以通过修改配置文件来更改。

4. 锁定当前版本

   kubectl rollout pause deployment/nginx-deployment  
   

   • 用于暂停 Deployment 的滚动更新。暂停后可以安全地进行检查或其他批量操作，而不会触发新的滚动更新。

5. 解除锁定

   kubectl rollout resume deployment/nginx-deployment  
   

   • 用于恢复 Deployment 的更新过程。如果之前暂停了 Deployment 的更新，恢复后更新会继续进行。