以下内容均来自个人笔记并重新梳理,如有错误欢迎指正!
如果对您有帮助,烦请点赞、关注、转发!如果您有其他想要了解的,欢迎私信联系我~
初始化容器
探测并等待某些服务(如数据库服务)的启动和可用性 执行一些预处理任务,如预加载数据 为业务容器生成环境变量或配置文件
initContainer 共享业务容器的网络命名空间 initContainer 可以访问业务容器挂载的卷 每个 initContainer 必须成功完成,业务容器才能继续启动
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
...
重启策略
Always:默认策略,无论容器以什么状态退出,Kubernetes 都会尝试重启容器 OnFailure:只有当容器以非零状态退出时,Kubernetes 才会重启容器。这可以防止在容器正常退出时不必要的重启 Never:无论容器以什么状态退出,Kubernetes 都不会重启容器。这通常用于批处理作业,其中失败的作业不需要重新启动
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%
减少更新对用户的影响,实现无缝更新和服务的持续可用 允许逐步验证新版本的稳定性 提供回滚机制(Rollout Undo),以便在更新失败时恢复到旧版本