构建一个用于滚动更新的 Kubernetes Operator

huangapple go评论78阅读模式
英文:

Build a Kubernetes Operator For rolling updates

问题

我已经创建了一个 Kubernetes 应用程序(假设部署名称为 D1,使用 Docker 镜像 I1),将在客户集群上运行。

需求 1:

现在,我希望在更新 Docker 镜像 I1 时能够自动进行更新,而无需客户端进行任何努力
(某种方式,客户集群应自动拉取最新的 Docker 镜像)。

需求 2:

每当我更新特定的 configMap 时,客户集群应自动开始使用新的 configMap。

我应该如何实现这一点?

  1. 使用 Kubernetes CronJobs?
  2. Kubernetes Operators?
  3. 还是其他方法?

我听说 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 ?

  1. Using Kubernetes Cronjobs ?
  2. Kubernetes Operators ?
  3. Or something else ?

I heard that k8s Operator can be useful

答案1

得分: 1

需求2开始:

> 每当我更新特定的configMap时,客户端集群应自动开始使用新的configMap

如果configMap被挂载到部署中,它将自动更新,但是如果作为环境注入,只有重新启动才是唯一的选择,除非您使用了sidecar解决方案或重新启动进程。

参考:无需重新启动POD更新configMap

我应该如何实现这个?

  • ImagePullPolicy 不是一个好的选择,但在这种情况下,需要手动干预来重新启动部署,并从客户端拉取最新的镜像,这不是一个受控的方式。

使用Kubernetes Cronjobs?

  • Cronjobs你将在哪一侧运行?如果在客户端运行,也可以这样做。

    否则,您可以保留具有公开API的部署,该API将在任何镜像被推送到您的Docker注册表时运行作业以使用最新的标签更新部署。

Kubernetes Operators?

  • 操作员是一个很好的本地K8s选项,您可以使用GoPython或您喜欢的语言编写,可以使用/不使用操作员框架或客户端库。

还是其他什么?

如果您只是想更新部署,可以选择在部署中运行API或计划作业以受控的方式进行,操作员也没有问题,如果您可以创建、管理和部署一个操作员,那将是一种更本地和好的方法。

如果将来您需要从单一的真实来源管理多个客户端的所有集群(部署、服务、防火墙、网络),您可以探索Anthos

使用Git仓库同步的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.

Config management from Git repo sync with 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

huangapple
  • 本文由 发表于 2022年12月6日 13:46:36
  • 转载请务必保留本文链接:https://go.coder-hub.com/74697801.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定