容器正忙于请求，则请求应路由到另一个容器

Question

我对k8s和docker很陌生。但我有关于K8的任务。现在我坚持使用一个用例。即：

如果容器正忙于处理请求。然后传入的请求应该重定向到另一个容器。

部署.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: twopoddeploy
namespace: twopodns
spec:
selector:
matchLabels:
app: twopod
replicas: 1
template:
metadata:
labels:
app: twopod
spec:
containers:
- name: secondcontainer
image: "docker.io/tamilpugal/angmanualbuild:latest"
env:
- name: "PORT"
value: "24244"
- name: firstcontainer
image: "docker.io/tamilpugal/angmanualbuild:latest"
env:
- name: "PORT"
value: "24243"

服务.yaml

apiVersion: v1
kind: Service
metadata:
name: twopodservice
spec:
type: NodePort
selector:
app: twopod
ports:
- nodePort: 31024
protocol: TCP
port: 82
targetPort: 24243

在deployment.yaml中，我创建了一个包含两个具有相同图像的容器的pod。因为firstcontainer不可访问/繁忙，所以secondcontainer应该处理传入的请求这是我们的想法和用例。所以(仅用于检查我们的用例(我使用docker container rm -f id_of_firstcontainer删除了firstcontainer。现在站点无法访问，直到docker重新创建firstcontainer。但我需要k8s将请求重定向到secondcontainer，而不是等待firstcontainer。

然后，我在谷歌上搜索了这个解决方案，找到了Ingress和Liveness - Readiness。但是Ingress确实根据路径而不是容器状态来路由请求。CCD_ 14还重新创建容器。CCD_ 15也有一些问题，有些正在使用CCD_ 16服务器。但运气不好。这就是我提出新问题的原因。

所以我的问题是如何配置这两个容器以减少停机时间？

什么是关键字从谷歌获得解决方案来尝试自己？

谢谢，

Pugal。

Answer 1

服务可以在多个pod之间实现负载平衡。您应该删除部署规范中容器的第二个副本，但也要将其更改为replicas: 2。现在，您的部署将启动两个相同的pod，但服务将匹配这两个pod，请求将同时发送到这两个pods。

apiVersion: apps/v1
kind: Deployment
metadata:
name: onepoddeploy
namespace: twopodns
spec:
selector: { ... }
replicas: 2 # not 1
template:
metadata: { ... }
spec:
containers:
- name: firstcontainer
image: "docker.io/tamilpugal/angmanualbuild:latest"
env:
- name: "PORT"
value: "24243"
# no secondcontainer

这意味着，如果两个pod不足以处理您的负载，您可以kubectl scale deployment -n twopodns onepoddeploy --replicas=3来增加副本数量。如果你能从CPU利用率或其他指标中判断出你何时达到"；"不够"；，您可以配置水平pod自动缩放器来为您调整副本计数。

(每个pod通常只需要一个容器。没有办法像你在这里建议的那样在容器之间共享流量，而且能够独立地扩展组件是很有帮助的。如果你看到的是像数据库这样的有状态组件和像HTTP服务这样的无状态组件，那就更正确了d网络代理，在某种程度上是pod主要操作的次要代理，可以与主容器一起扩展或终止。(

在一个服务后面运行多个pod副本有两个重要的注意事项。服务负载均衡器并不是特别聪明，所以如果你的一个副本最终从事密集型工作，而另一个或多或少处于空闲状态，它们仍然会各自获得大约一半的请求。此外，如果你的pod被配置为HTTP健康检查(推荐(，如果pod被备份到无法处理请求的地步，它也将无法回答其健康检查，Kubernetes将杀死它。

您可以通过努力回答所有HTTP请求来帮助Kubernetes；迅速地"；(瞄准1000毫秒以下总是可能是一个不错的目标(。这可以意味着返回"0"；还没有准备好"；对触发大量计算的请求的响应。这也可能意味着重新安排主请求处理程序，这样HTTP请求线程就不会在等待某个任务完成时出现问题。