如何滚动重启pod而不改变kubernetes(k8s)中的部署yaml?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何滚动重启pod而不改变kubernetes(k8s)中的部署yaml?相关的知识,希望对你有一定的参考价值。
参考技术A 在 1.15 版本之前通过修改 annotations 的变量值可实现滚动重启 Pod ,当然这个方法其实更改了 yaml 文件,不过是更改的自定义变量字段通过时间戳的方式来设置值,一般不会对 Pod 主要内容有影响在 1.15 版本之后使用以下命令:
Kubernetes - 滚动更新杀死旧 pod 而不启动新 pod
【中文标题】Kubernetes - 滚动更新杀死旧 pod 而不启动新 pod【英文标题】:Kubernetes - Rolling update killing off old pod without bringing up new one 【发布时间】:2018-03-04 07:00:18 【问题描述】:我目前正在使用 Deployments 来管理我的 K8S 集群中的 pod。
我的一些部署需要 2 个 Pod/副本,有些需要 3 个 Pod/副本,而其中一些只需要 1 个 Pod/副本。我遇到的问题是一个 pod/副本。
我的 YAML 文件是:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: user-management-backend-deployment
spec:
replicas: 1
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 2
selector:
matchLabels:
name: user-management-backend
template:
metadata:
labels:
name: user-management-backend
spec:
containers:
- name: user-management-backend
image: proj_csdp/user-management_backend:3.1.8
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
livenessProbe:
httpGet:
port: 8080
path: /user_management/health
initialDelaySeconds: 300
timeoutSeconds: 30
readinessProbe:
httpGet:
port: 8080
path: /user_management/health
initialDelaySeconds: 10
timeoutSeconds: 5
volumeMounts:
- name: nfs
mountPath: "/vault"
volumes:
- name: nfs
nfs:
server: kube-nfs
path: "/kubenfs/vault"
readOnly: true
我的旧版本运行良好。
# kubectl get po | grep user-management-backend-deployment
user-management-backend-deployment-3264073543-mrrvl 1/1 Running 0 4d
现在我要更新图像:
# kubectl set image deployment user-management-backend-deployment user-management-backend=proj_csdp/user-management_backend:3.2.0
现在根据 RollingUpdate 设计,K8S 应该在保持旧 pod 正常工作的同时启动新 pod,并且只有在新 pod 准备好接受流量时,旧 pod 才会被删除。但是我看到的是旧的 pod 立即被删除并创建了新的 pod,然后开始占用流量需要时间,这意味着我必须丢弃流量。
# kubectl get po | grep user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9 0/1 ContainerCreating 0 1s
# kubectl get po | grep user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9 1/1 Running 0 33s
我使用过maxSurge: 2
和maxUnavailable: 1
,但这似乎不起作用。
任何想法为什么这不起作用?
【问题讨论】:
【参考方案1】:好像是maxUnavailable: 1
;我能够轻松地重现您设置该值的体验,并通过将其设置为 maxUnavailable: 0
这是我对调度程序如何得出您所遇到的行为的“伪证明”:
因为replicas: 1
,k8s 的期望状态恰好是Ready
中的一个 Pod。在滚动更新操作期间,这是您请求的策略,它将创建一个新 Pod,使总数达到 2。但是您授予 k8s 允许 一个 Pod 处于不可用状态,并且您指示它将期望的 Pod 数量保持在 1。因此,它满足了所有这些约束:1 Pod,期望的数量,处于不可用状态,由 RU 策略允许。
通过将maxUnavailable
设置为零,您可以正确地指示 k8s 永远不要让任何 Pod 不可用,即使这意味着 Pod 会在短时间内飙升至超过 replica
计数
【讨论】:
假设我们有maxUnavailable: 0
的这种部署策略,k8s 会耗尽节点吗?在此之前它会在现有节点上创建新的 pod 吗?【参考方案2】:
将 Strategy Type 设置为 RollingUpdate
会在删除旧 pod 之前创建一个新 pod,即使只有一个副本也是如此。策略类型Recreate
在创建新 pod 之前杀死旧 pod
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
【讨论】:
OP 正在使用策略类型 RollingUpdate 因为他想要这种行为 - 不确定这个答案有什么帮助......【参考方案3】:正如已经回答的那样,您可以将 maxUnavailable 设置为 0 以获得所需的结果。一些额外的说明:
当使用挂载单个特定卷的有状态服务时,您不应期望这会工作,该卷将由新 pod 使用。该卷将附加到即将更换的 pod,因此无法附加到新的 pod。
文档指出,如果您已将 .spec.strategy.rollingUpdate.maxSurge 设置为 0,则无法将其设置为 0。
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable
【讨论】:
那么你是说如果我们在 pod 上有一个永久卷,我们就不应该这样做吗?以上是关于如何滚动重启pod而不改变kubernetes(k8s)中的部署yaml?的主要内容,如果未能解决你的问题,请参考以下文章