K8s Deployment 滚动更新、金丝雀发布、自定义钩子、生命周期解析

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

一、Deployment的高级特性

1、滚动更新

2、金丝雀发布

3、自定义钩子

4、生命周期管理

二、Deployment常见问题与解决方案

1、Deployment更新失败处理

2、Pod调度失败与资源限制

三、总结

一、Deployment的高级特性

1、滚动更新

Kubernetes（K8s）的滚动更新是一种更新策略，用于无缝地更新应用程序的部署，而不会中断现有用户的服务。滚动更新通过逐步替换现有的Pod实例来实现，确保新版本的Pod在部署过程中逐步上线，同时监控应用程序的健康状态，并在需要时回滚到旧版本。

滚动更新的工作原理主要基于Deployment资源内的spec.strategy.type设定。当设置为RollingUpdate时，Kubernetes会根据spec.strategy.rollingUpdate.maxUnavailable和spec.strategy.rollingUpdate.maxSurge的定义来执行更新。

maxUnavailable设定了在更新过程中能有多少Pod处于不可用状态。这个值可以是一个绝对值（例如，最多可以有1个Pod不可用），也可以是一个百分比（例如，最多可以有25%的Pod不可用）。
maxSurge则决定了在更新过程中，可以额外创建的Pod数量上限。这个值同样可以是一个绝对值或百分比。它允许在更新过程中，超出预期的Replica数量，以便更快地替换旧的Pod实例。

滚动更新步骤如下：

创建一个Deployment来管理Pod的创建和更新。在这个Deployment中，可以指定要使用的镜像和其他配置参数。
使用kubectl命令执行滚动更新。例如，可以通过kubectl set image deployment/my-app my-app=my-app:2.0.0命令将my-app的镜像更新为my-app:2.0.0，并触发滚动更新过程。
Kubernetes会开始逐步替换旧的Pod实例。它会先按照maxSurge创建新的Pod实例，然后按照maxUnavailable逐渐杀死旧的Pod实例。在这个过程中，服务的可用性得到保证，因为始终有足够的Pod实例在运行以处理请求。
可以使用kubectl命令来监控滚动更新的进度，确保更新过程顺利进行。
如果滚动更新出现问题，可以回滚到之前的版本，以确保服务的稳定性。

2、金丝雀发布

金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。

金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。

金丝雀发布（Canary Release）是一种部署策略，用于逐步将新版本的应用程序引入生产环境，以降低部署风险并确保应用程序的稳定性。金丝雀发布通过逐步将新版本的应用程序引入生产流量，然后监控其性能和稳定性，以便在出现问题时快速回滚。以下是金丝雀发布的一般步骤：

准备新版本：首先，您需要准备新版本的应用程序，并在Kubernetes中创建一个新的Deployment资源来部署该版本。新版本的应用程序可能包含新功能、性能优化或bug修复等改进。
创建金丝雀Deployment：在Kubernetes中创建一个新的Deployment资源，用于金丝雀发布。这个Deployment资源通常包含新版本的应用程序，并且可以根据需要配置特定的副本数量和Pod策略。
设置流量分配规则：在金丝雀Deployment资源中，您可以配置流量分配规则，将一部分生产流量引导到新版本的应用程序。您可以使用Kubernetes的服务资源或Ingress资源来配置流量路由规则，将一部分流量发送到金丝雀Deployment，而将其他流量发送到旧版本的Deployment。
逐步增加流量：一旦设置了流量分配规则，Kubernetes会逐步将生产流量引导到金丝雀Deployment中的新版本。您可以根据需要逐步增加流量的比例，例如从5%开始，然后逐步增加到10%、20%等。
监控性能和稳定性：在引入生产流量的过程中，您需要监控新版本的应用程序的性能和稳定性。您可以使用监控工具、日志记录和警报系统等来监控应用程序的指标，并在出现问题时及时采取措施。
快速回滚：如果发现新版本的应用程序存在严重问题，您可以通过调整流量分配规则，将流量立即回滚到旧版本的Deployment。Kubernetes的滚动更新和回滚功能可以确保金丝雀发布过程的安全性和可靠性。

3、自定义钩子

在Kubernetes中，Deployment资源提供了一种称为“钩子”的机制，允许在部署过程的不同阶段执行自定义操作。这些钩子可用于执行各种任务，例如在容器启动之前或之后运行脚本、初始化数据库、执行数据迁移等。Deployment资源支持以下几种钩子：

PostStart钩子：在容器启动后立即执行。这通常用于执行容器启动后的初始化任务，例如等待其他服务启动、注册服务到服务发现系统等。
PreStop钩子：在容器关闭之前执行。这通常用于执行容器关闭前的清理任务，例如保存数据、关闭连接、发送信号给其他进程等。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example-container
        image: nginx:latest
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo 'Container started'"]
          preStop:
            exec:
              command: ["/bin/sh", "-c", "echo 'Container stopping'"]

在上面的示例中，我们为名为example-container的容器配置了PostStart和PreStop钩子。PostStart钩子在容器启动后执行命令 echo 'Container started'，而PreStop钩子在容器关闭之前执行命令echo 'Container stopping'。

4、生命周期管理

在Kubernetes中，Deployment资源的生命周期管理涉及创建、更新和销毁部署的过程。

创建Deployment：首先，需要定义一个Deployment资源，并指定所需的副本数、Pod模板、更新策略等信息。创建Deployment后，Kubernetes将自动启动Pod副本并监视它们的状态。
更新Deployment：如果需要更新应用程序的版本或配置，可以通过更新Deployment资源来实现。可以修改Deployment资源的Pod模板或标签选择器，然后应用这些更改。Kubernetes将根据更新策略逐步将新的Pod副本部署到集群中，并确保新旧版本的Pod副本同时存在一段时间，以确保平滑的过渡。
监控Deployment：在Deployment部署过程中，可以通过Kubernetes Dashboard、kubectl命令行工具或自定义监控系统来监控Deployment的状态。可以查看Deployment的副本数、可用性、健康状态等指标，以确保部署的顺利进行。
回滚Deployment：如果更新部署后发现问题，可以通过回滚Deployment来恢复到之前的稳定状态。Kubernetes支持回滚操作，可以指定要回滚到的特定版本或回滚到上一个成功的版本。
销毁Deployment：当不再需要某个Deployment资源时，可以将其从集群中删除。删除Deployment资源将同时删除与之关联的所有Pod副本和其他相关资源。

二、Deployment常见问题与解决方案

1、Deployment更新失败处理

1. 检查更新配置：

首先，确认更新的Deployment配置文件是否正确。检查是否有语法错误、字段缺失或配置不当的地方。
特别注意镜像名称、标签、端口、环境变量等关键配置是否准确无误。

2. 查看事件和日志：

使用kubectl describe deployment <deployment-name>命令查看Deployment的详细信息，包括事件和状态。
检查Pod的状态和事件，使用kubectl get pods和kubectl describe pod <pod-name>命令获取更多信息。
查看Pod的日志，使用kubectl logs <pod-name>命令，这有助于发现应用层面的错误或异常。

3. 检查资源配额和限制：

Kubernetes允许管理员为每个namespace设置资源配额，包括CPU、内存等资源。如果Pod使用的资源超出了配额限制，更新可能会失败。
使用kubectl describe quota命令查看配额的使用情况，确保更新后的Pod不会超出限制。

4. 检查网络问题：

网络问题可能导致Pod无法拉取镜像或与其他服务通信。
检查集群的网络配置，确保Pod可以访问所需的镜像仓库和服务。

5. 检查存储和持久卷：

如果Deployment使用了持久卷（PersistentVolumes），确保相关的存储配置正确，并且持久卷可用。
检查持久卷的状态和事件，使用kubectl get pv和kubectl describe pv <pv-name>命令。

6. 检查就绪探测和存活探测：

如果Deployment配置了就绪探测（Readiness Probe）或存活探测（Liveness Probe），确保探测逻辑正确。
不当的探测配置可能导致Pod无法正确启动或过早被杀死。

7. 回滚更新：

如果更新失败且无法立即解决，可以考虑回滚到之前的版本。
使用kubectl rollout undo deployment <deployment-name>命令可以回滚到上一个版本。

2、Pod调度失败与资源限制

当Pod调度失败时，可以考虑以下几个方面进行排查和解决：

检查节点资源：首先，检查集群中的节点资源情况，包括CPU、内存等资源的使用情况。使用kubectl describe node命令可以查看节点的资源使用情况和容量。
查看Pod资源请求和限制：检查Pod的资源请求和限制是否与节点的资源容量相匹配。可以通过kubectl describe pod命令查看Pod的资源请求和限制配置。
调整资源配置：如果Pod的资源请求过高或者资源限制过低，可能会导致调度失败。可以根据实际情况调整Pod的资源配置，确保资源请求和限制合理。
添加节点：如果集群中的节点资源已经饱和，考虑添加新的节点来扩容集群。使用更强大的节点或者增加节点数量可以提高集群的容量和性能。
排查其他问题：除了资源限制外，还可能有其他原因导致Pod调度失败，例如节点标签不匹配、网络配置问题等。可以查看Pod的事件记录和日志，进一步排查问题并解决。