英文:
Build a Kubernetes Operator For rolling updates
问题
我已经创建了一个 Kubernetes 应用程序(假设部署名称为 D1,使用 Docker 镜像 I1),将在客户集群上运行。
需求 1:
现在,我希望在更新 Docker 镜像 I1 时能够自动进行更新,而无需客户端进行任何努力
(某种方式,客户集群应自动拉取最新的 Docker 镜像)。
需求 2:
每当我更新特定的 configMap 时,客户集群应自动开始使用新的 configMap。
我应该如何实现这一点?
- 使用 Kubernetes CronJobs?
- Kubernetes Operators?
- 还是其他方法?
我听说 k8s Operator 可能会有用。
英文:
I have created a Kubernetes application (Say deployment D1, using docker image I1), that will run on client clusters.
Requirement 1 :
Now, I want to roll updates whenever I update my docker image I1, without any efforts from client side
(Somehow, client cluster should automatically pull the latest docker image)
Requirement 2:
Whenever, I update a particular configMap, the client cluster should automatically start using the new configMap
How should I achieve this ?
- Using Kubernetes Cronjobs ?
- Kubernetes Operators ?
- Or something else ?
I heard that k8s Operator can be useful
答案1
得分: 1
从需求2开始:
> 每当我更新特定的configMap时,客户端集群应自动开始使用新的configMap
如果configMap被挂载到部署中,它将自动更新,但是如果作为环境注入,只有重新启动才是唯一的选择,除非您使用了sidecar解决方案或重新启动进程。
我应该如何实现这个?
- ImagePullPolicy 不是一个好的选择,但在这种情况下,需要手动干预来重新启动部署,并从客户端拉取最新的镜像,这不是一个受控的方式。
使用Kubernetes Cronjobs?
-
Cronjobs你将在哪一侧运行?如果在客户端运行,也可以这样做。
否则,您可以保留具有公开API的部署,该API将在任何镜像被推送到您的Docker注册表时运行作业以使用最新的标签更新部署。
Kubernetes Operators?
- 操作员是一个很好的本地K8s选项,您可以使用Go、Python或您喜欢的语言编写,可以使用/不使用操作员框架或客户端库。
还是其他什么?
如果您只是想更新部署,可以选择在部署中运行API或计划作业以受控的方式进行,操作员也没有问题,如果您可以创建、管理和部署一个操作员,那将是一种更本地和好的方法。
如果将来您需要从单一的真实来源管理多个客户端的所有集群(部署、服务、防火墙、网络),您可以探索Anthos。
英文:
Starting with the Requirement 2:
> Whenever, I update a particular configMap, the client cluster should
> automatically start using the new configMap
If configmap is mounted to the deployment it will get auto-updated however if getting injected as the Environment restart is only option unless you are using the sidecar solution or restarting the process.
For ref : Update configmap without restarting POD
How should I achieve this ?
- ImagePullpolicy is not a good option i am seeing however, in that case, manual intervention is required to restart deployment and it
pulls the latest image from the client side and it won't be in a
controlled manner.
Using Kubernetes Cronjobs ?
-
Cronjobs you will run which side ? If client-side it's fine to do
that way also.Else you can keep deployment with Exposed API which will run Job to
update the deployment with the latest tag when any image gets pushed
to your docker registry.
Kubernetes Operators ?
- An operator is a good native K8s option you can write in Go,
Python or your preferred language with/without Operator framework or Client Libraries.
Or something else?
If you just looking for updating the deployment, Go with running the API in the deployment or Job you can schedule in a controlled manner, no issue with the operator too would be a more native and a good approach if you can create, manage & deploy one.
If in the future you have a requirement to manage all clusters (deployment, service, firewall, network) of multiple clients from a single source of truth place you can explore the Anthos.
答案2
得分: 0
你可以构建一个 Kubernetes operator 来监视你特定的 configmap,并触发集群重启。至于滚动更新,你可以根据需求配置 deployment。只有当 Deployment 的 Pod 模板(即 .spec.template
)发生变化时,才会触发 Deployment 的滚动更新,例如,如果模板的标签或容器镜像被更新。在你的 Kubernetes deployment 的 .spec
部分添加滚动更新的规范:
type: RollingUpdate
rollingUpdate:
maxSurge: 3 // 在升级期间,超出期望状态的最大 pod 数量
maxUnavailable: 1 // 在更新期间不可用的最大 pod 数量
timeoutSeconds: 100 // 等待滚动事件超时的时间(以秒为单位)
intervalSeconds: 5 // 更新后的时间间隔(以秒为单位)
updatePeriodSeconds: 5 // 在单个 pod 迁移或更新之间等待的时间
英文:
You can build a Kubernetes operator to watch your particular configmap and trigger cluster restart. As for the rolling updates, you can configure the deployment according to your requirement. A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, .spec.template
) is changed, for example, if the labels or container images of the template are updated. Add the specifications for rolling update on your Kubernetes deployment .spec
section:
type: RollingUpdate
rollingUpdate:
maxSurge: 3 //the maximum number of pods to be created beyond the desired state during the upgrade
maxUnavailable: 1 //the maximum number of unavailable pods during an update
timeoutSeconds: 100 //the time (in seconds) that waits for the rolling event to timeout
intervalSeconds: 5 //the time gap in seconds after an update
updatePeriodSeconds: 5 //time to wait between individual pods migrations or updates
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论