【K8s】专题六（4）：Kubernetes 稳定性之初始化容器、重启策略、滚动更新策略

行者Sun1989

已于 2024-08-29 13:59:17 修改

阅读量1.5k

点赞数 50

CC 4.0 BY-SA版权

分类专栏： Kubernetes 文章标签： kubernetes 云原生容器

于 2024-07-08 12:38:30 首次发布

本文链接：https://blog.youkuaiyun.com/2401_82795112/article/details/140213691

Kubernetes 专栏收录该内容

52 篇文章

订阅专栏

本文内容均来自个人笔记并重新梳理，如有错误欢迎指正！

如果对您有帮助，烦请点赞、关注、转发、订阅专栏！

专栏订阅入口

Linux 专栏 | Docker 专栏 | Kubernetes 专栏

往期精彩文章

【Docker】（全网首发）Kylin V10 下 MySQL 容器内存占用异常的解决方法

【Docker】（全网首发）Kylin V10 下 MySQL 容器内存占用异常的解决方法（续）

【Docker】MySQL 源码构建 Docker 镜像（基于 ARM 64 架构）

一、初始化容器

1、基本介绍

初始化容器即 initContainer。

在 Kubernetes 中，initContainer 用于在 Pod 中的业务容器启动之前，执行某些特定的初始化任务来提升 Pod 运行状态的稳定，如：

探测并等待某些服务（如数据库服务）的启动和可用性
执行一些预处理任务，如预加载数据
为业务容器生成环境变量或配置文件

2、主要特点

initContainer 共享业务容器的网络命名空间
initContainer 可以访问业务容器挂载的卷
每个 initContainer 必须成功完成，业务容器才能继续启动

3、资源清单（示例）

apiVersion: apps/v1
kind: Deployment
metadata:
  nanme: demo-deployment
spec:
...
    spec:
      initContainers:
      - name: demo-init
        image: busybox
        command:
        - "/bin/sh"
        - "-c"
        - "until nc -w 2 -z mysql 3306;do echo mysql is not ready.;sleep 2;done"
      containers:
      - name: demo-container
...

上述资源清单中定义了一个 initContainer，该 initContainer 使用 busybox 镜像（自带 ping、nslookup、nc 等工具），在业务容器启动之前执行命令探测 MySQL 服务是否就绪。当 initContainer 探测成功并退出后，业务容器 demo-container 开始启动，可以避免 demo-container 因无法连接 MySQL 服务而报错重启、Pod 一直处于 CrashLoopBackOff 状态。

二、重启策略

1、基本介绍

重启策略（Restart Policy）定义了当 Pod 中的容器失败时，Kubernetes 如何响应。

重启策略有 3 种选项：

Always：默认策略，无论容器以什么状态退出，Kubernetes 都会尝试重启容器
OnFailure：只有当容器以非零状态退出时，Kubernetes 才会重启容器。这可以防止在容器正常退出时不必要的重启
Never：无论容器以什么状态退出，Kubernetes 都不会重启容器。这通常用于批处理作业，其中失败的作业不需要重新启动

2、资源清单（示例）

apiVersion: apps/v1
kind: Deployment
metadata:
  nanme: demo-deployment
spec:
...
    spec:
      containers:
      - name: demo-container
...
      restartPolicy: Always
...

三、滚动更新策略

1、基本介绍

Deployment 对象的镜像、env 环境变量等发生变更后，Deployment 控制器会对 Pod 进行更新，有 2 种更新策略可选：

Recreate：重新创建，先杀死运行中的 Pod 再创建新的 Pod
RollingUpdate：滚动更新，通过 ReplicaSet 控制器对旧 Pod 进行有序替换

滚动更新策略（Rolling Update Strategy）可以通过逐步替换旧版本的 Pod 的方式，来实现应用程序的平滑过渡，确保应用程序的可用性和提供服务的稳定性。

2、资源清单（示例）

apiVersion: apps/v1
kind: Deployment
metadata:
  nanme: demo-deployment
spec:
...
  minReadySeconds: 5                  # 等待设置的时间后开始更新
  revisionHistoryLimit: 10            # 最多保存多少个历史版本
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
...
    spec:
      containers:
      - name: demo-container
...


🔔 maxSurge：在更新过程中可以超出期望数量的最大 Pod 数量，可以是绝对值或百分比，默认为 25%
🔔 maxUnavailable：在更新过程中可以处于不可用状态的最大 Pod 数量，可以是绝对值或百分比，默认为 25%