Kar*_*ddy 3 containers kubernetes
我知道在一个 Pod 中拥有多个容器的优点，但拥有多个容器的缺点是什么。我们有 20k pod 产品需求，而我们当前的基础设施支持一个命名空间最多 900 个 pod。这是满足这一请求的最佳方法。
我不是 DevOps 人员，但从开发人员的角度来看：
如果 POD 中有很多容器：
您应该注意： 生命周期问题 - 哪个容器先启动，哪个容器先结束，等等
如何评价pod作为逻辑单元的“可操作性”。如果 pod 中有一个容器，那么它就清楚了——如果容器运行——那就没问题。但如果你有很多，你定义什么样的探针（就绪性、活跃性）？如果一个容器死掉了，整个 Pod 还能运行吗？
可能在 kubernetes 集群中找到小 pod 副本的位置比大 pod 更容易（有很多容器，因此可能消耗更多资源）
您牺牲了潜在的可扩展性灵活性。假设容器 A 和 B 位于同一个 Pod 中。如果只想横向扩展容器 A 该怎么办？
与上面相同的项目适用于发布管理灵活性（推出、金丝雀发布、回退到先前版本 - 所有这些）
您必须考虑从 Pod 内的容器收集日志/指标的解决方案。根据实际的技术堆栈，这可能很简单也可能很乏味，但无论如何这是您必须解决的问题。可以说，当 Pod 中有多个容器时，解决方案可能会变得更加复杂。
操作性稍差一些kubectl。好吧，这虽然是小事，但仍然如此。您始终需要添加该-c标志。想查看 pod 的日志吗？添加-c <container-name>。想做kubectl exec -it-再次，-c <container-name>。
当然，有时运行 sidecar 容器是一种有效的情况（例如，对于服务混搭）。但总而言之，它是工作的工具。
有趣的是，我发现一篇文章谈到赋予侧车集装箱一种“特殊态度”。这可能有点相关，尽管从这个问题来看，我知道如果我没说错的话，你不会考虑“边车”