问题一:有个OpenKruise的问题想请教一下。如果在workload的PodTemplate中配置了restartPolicy=Never,但是又想要使用原地升级的功能,有没有什么好办法可以绕开?
问题二:主要是k8s没有更细粒度的restartPolicy控制了,大概需求就是有一个container业务方不想重启。但是其他的container又想原地升级
在 OpenKruise 中,如果你在 Workload 中已经配置了程序,并且想要使用原地升级(In-place Upgrade)的功能,可以考虑以下几个方法来绕开这个问题:
创建新的 Workload:可以通过创建一个新的 Workload 来进行原地升级。在新的 Workload 中更新所需的配置和程序,并逐步切换流量到新的 Workload 上。一旦确认新的 Workload 正常运行并满足预期,可以停止旧的 Workload。
使用 Kubectl 编辑:如果你的 Workload 使用的是 Deployment、StatefulSet 或 DaemonSet 等 Kubernetes 对象管理器,你可以使用 kubectl edit
命令直接编辑对应的对象,修改其中的配置和程序。请确保在编辑前备份相关资源,并谨慎操作,以避免不可逆的更改。
使用标签选择器:如果你的 Workload 是通过标签选择器来管理多个 Pod 的,可以通过更新标签选择器的方式,将新的 Pod 与旧的 Pod 区分开来。然后可以逐步删除旧的 Pod,并增加新的 Pod,从而实现原地升级的效果。
需要注意的是,在进行任何变更之前,请确保备份当前 Workload 的配置和数据,以便在出现问题时进行恢复。此外,还建议在进行重要更新之前先进行测试,并确保你了解原地升级过程中可能出现的风险和潜在问题。
OpenKruise 中的原地升级功能是通过在 Workload 中指定 RollingUpdate 策略来实现的。如果您想使用原地升级功能,但是又不想修改 Workload 中的配置,可以考虑使用 OpenKruise 提供的 InPlaceUpdate 策略,该策略可以在不修改 Workload 的情况下实现原地升级。
具体来说,您可以按照以下步骤进行操作:
在需要进行原地升级的 Deployment 或 StatefulSet 上,添加 OpenKruise 提供的 InPlaceUpdate Annotation,示例如下:
Copy
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
kruise.alibaba.com/in-place-update: "true"
name: sample-deployment
namespace: default
spec:
在 Workload 所在的命名空间上,创建一个 InPlaceUpdate 计划,用于指定升级的版本和策略。示例如下:
angelscript
Copy
apiVersion: kruise.io/v1alpha1
kind: InPlaceUpdatePlan
metadata:
name: sample-inplaceupdate-plan
namespace: default
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: sample-deployment
updatePolicy:
# ...
其中,"targetRef" 字段用于指定需要升级的 Workload,"updatePolicy" 字段用于指定升级的版本和策略。根据实际情况修改这些参数。
执行 InPlaceUpdate 计划,开始进行原地升级。示例如下:
Copy
kubectl apply -f inplaceupdate.yaml
需要注意的是,使用 InPlaceUpdate 策略进行原地升级时,需要确保应用程序的状态和数据不会丢失或被破坏。建议您在进行升级前,先进行备份和测试,确保应用程序的可用性和稳定性。
针对问题一的回答:workload 的这个就不能 配置 restartPolicy=Never 吧。 必须要 always
一般是作业才会配置成Never的 restartPolicy,你们有作业需要原地升级的场景吗?
restartPolicy=Never 那真的就是在梭哈了,好奇是服务端需要做这种策略吗?或者说好奇是不是那种 24x7 的服务进程要这么搞
针对问题二的回答:charts 或者别的 iac 模板要是有管控的话,或许给他开个白名单
有状态服务的一些场景是会将restartPolicy设置为never,ContainerRecreateRequest有没有方案跳过restart policy?
我也不太理解,容器挂了,不希望 kubelet 自动拉起吗?
可以理解为服务云原生化的程度还不够,部分逻辑由平台来控制,实例挂了,平台在别的机器新建一个;并将原来挂的那个实例提出集群
要不你们在 docker 里面搞一个 父进程,业务的 进程是子进程,这样子进程挂了,父进程也不会退出啥的—此回答来自钉群“OAM/KubeVela 社区交流群”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。