问题描述
我有一个ReplicationController，在一个Pod中包含两个容器，第一个是寿命长的Pod，第二个在RC启动POD时执行一些维护任务.但是，由于第二个容器寿命很短，因此它在完成启动任务时会自行停止.当Kuberbetes注意到这一点时，它将杀死POD并开始一个新的POD.
I have a ReplicationController containing two containers in a pod, the first is a long-living pod, the second does a few maintenance tasks when the RC starts up a POD. However as the second container is short lived, it stops itself when it finishes its start tasks.When Kuberbetes notices this, it kills off the POD and starts a new one...
在Kuberbetes中处理此问题的正确方法是什么?
What is the correct way to handle this in Kuberbetes?
推荐答案
正如您已经注意到的，通过设计，吊舱中的所有容器都注定会共同生活和死亡.在不知道您的助手需要准确执行哪种维护任务的情况下，很难说出最佳选择.一般来说，我可以想到三种方法:
As you already noticed, by design all containers in a pod are destined to live and die together. It's a bit hard to tell what your best alternative would be without knowing what kind of maintenance task your sidekick needs to perform exactly. Generally speaking, I can think of three approaches:
-
保持维护容器运行.这可能是一个相当丑陋的解决方案，因为它浪费了资源.只有维护任务可以从定期运行中受益才真正有意义.
Keep your maintenance container running. This is probably a fairly ugly solution as it wastes resources. It really only makes sense if the maintenance task can benefit from running periodically.
将维护任务移至主容器，将多容器吊舱有效地转换为单容器吊舱.我假设您可以异步运行任务(因为您已经能够在单独的容器中运行它)；如果由于某些原因您不能考虑修改就绪和活跃度探针，这样您的容器就有足够的时间来完成所有启动过程，然后才有资格终止.
Move the maintenance task over to your primary container, effectively converting your multi-container pod into a single-container one. I assume that you can run the task asynchronously (as you would already be able to run it in a separate container); if, for some reasons, you cannot, consider modifying readiness and liveness probes accordingly so that your container is given enough time to finish any boot-up procedures before becoming eligible for termination.
请考虑调整设计，以便维护任务可以作为单独的pod运行(甚至可以作为工作).然后，您需要管理任何依赖关系，并通过正确地组合Kubernetes原语来连接自己.
Consider adjusting your design so that the maintenance task may run as a separate pod (or maybe even as a job). You'd then need to manage any dependencies and wiring yourself by putting together Kubernetes primitives properly.
这篇关于吊舱(在Replication Controller中)中的短暂kubernetes容器(/sidekick)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！