Question

我最近正在测试我的kubernetes服务。而且我发现它非常不可靠。情况如下：
1.在端口80接收HTTP请求的测试服务“ A”在三个节点上部署了五个Pod。
2.已设置nginx入口，以将流量路由到服务“ A”之外。
3.入口设置如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-A
  annotations:    
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "1s"
    nginx.ingress.kubernetes.io/proxy-next-upstream: "error timeout invalid_header http_502 http_503 http_504"
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
spec:
  rules:
  - host: <test-url>
    http:
      paths:
      - path: /
        backend:
          serviceName: A
          servicePort: 80

http_load在客户端主机上启动，并以每秒1000的速度不断向入口nginx发送请求。所有请求都被路由到k8s中的服务“ A”，并且一切顺利。

当我手动重新启动其中一个节点时，出现了问题：
在接下来的3分钟内，大约20％的请求超时，这在产品环境中是不可接受的。

我不知道为什么k8s反应这么慢，有没有办法解决这个问题？

Answer 1

您可以通过在Pod的规范中配置liveness and readiness probes来加快故障转移过程：

Container probes

...

livenessProbe ：指示容器是否正在运行。如果活动性探针失败，则kubelet将杀死Container，并且Container将接受其重新启动策略。如果“容器”不提供活动性探针，则默认状态为“成功”。

readinessProbe ：指示容器是否准备好处理请求。如果就绪探针失败，则端点控制器将从与Pod匹配的所有服务的端点中删除Pod的IP地址。初始延迟之前的默认就绪状态为“失败”。如果“容器”未提供“准备就绪”探针，则默认状态为“成功”。

活力探针示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

Answer 2

感谢@VAS的回答！
活力探针是解决此问题的一种方法。
但是我终于发现，我想要的是被动健康检查，这是k8s所不能支持的。
我通过将istio引入集群来解决了这个问题。

当节点在k8s中崩溃时，20％的请求超时。如何解决呢？

2 个答案:

Container probes