我正在做一个项目，该项目目前正在将旧版应用程序迁移到符合云的要求。我们为此使用Kubernetes，Openshift和Docker。该应用程序具有一种特殊类型的“后端容器”（简称为BEP），其职责是处理传入的事务。在此容器中，我们有几个相互依赖的容器，但是只有一个容器实际执行“实际处理”（称为BEC）。这个旧版应用程序每秒处理数千个事务，因此需要继续在云中进行。
为达到此规模，我们正在考虑在容器中复制BEC，而不是复制BEP（因此也复制了它随附的所有其他不必要的容器）。我们可能需要此BEC的X个副本，而我们根本不需要扩展其相互依赖的容器。因此，缩放BEP的X个副本将毫无用处。
但是，该解决方案带来了问题。一旦一个BEC停机，kubernetes（即使还有100个其他BEC已启动并准备处理）将被kubernetes标记为“未准备好”，从而移除了pod端点，从而减少了到整个豆荚。
我想这是为吊舱定义某种“最低运行要求”的经典示例。
因此，我有两个问题：
如果对这两个问题的回答均为“否”：您是否有解决此问题的想法/方法，而没有建议对该遗留应用程序进行主要的体系结构重构？我们不能从BEC中拆分出相互依赖的容器，不幸的是它们需要在同一容器中运行。
在此先感谢您的帮助/建议！
/亚历克斯
答案 0 :(得分：1)
是否有一种方法可以将Pod标记为仍在运行，即使所有容器都不处于“就绪”状态？即通过在“准备就绪”状态下的＃个容器上定义一个较低的阈值来实现此最低运行要求，以使吊舱能够正常工作？
不，这是不可能的。
- 是否有一种方法可以标记Pod提供的服务，即使Pod未处于就绪状态也可以继续发送流量？我已经看到一个名为publishNotReadyAddresses（https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#servicespec-v1-core#publishNotReadyAddresses）的属性，但是我不确定这是否符合我们的要求？
您可以使用annotations：
metadata:
name: name
labels:
app: app
annotations:
service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"