将 kubernetes 中的流量重新路由到工作 pod

Question

不确定是否有这样的问题，如果我找不到这样的问题，请原谅我。

我有一个基于 3 个节点的集群，我的应用程序由一个前端和一个后端组成，每个运行 2 个副本：

• front1 - 在node1上运行
• front2 - 在node2上运行
• be1 - node1 1
• be2 - node2 2
• 两个FE pod 都在frontend-service后面提供
• 两个BE pod 都是be-service后面的服务

当我关闭node-2时，应用程序停止并且在我的 UI 中我可以看到应用程序错误。

我检查了日志，发现我的应用程序试图访问后端 pod 的服务类型，但由于be2没有运行，它没有响应，调度程序尚未终止现有的。

只有当节点被终止并从集群中删除时，pod 才会重新调度到第 3 个节点并且应用程序重新上线。

我知道服务网格可以通过删除对流量没有响应的 Pod 来提供帮助，但是，我还不想实现它，并试图了解将流量路由到健康 Pod 的最佳解决方案是什么一种快速简便的方法，5 分钟的停机时间是很多时间。

这是我be部署规范：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: backend
  name: backend
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: backend
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: backend
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-Application
                operator: In
                values:
                - "true"
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - backend
            topologyKey: kubernetes.io/hostname
      containers:
      - env:
        - name: SSL_ENABLED
          value: "false"
        image: quay.io/something:latest
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /liveness
            port: 16006
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 10
        name: backend
        ports:
        - containerPort: 16006
          protocol: TCP
        - containerPort: 8457
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readiness
            port: 16006
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 5
        resources:
          limits:
            cpu: 1500m
            memory: 8500Mi
          requests:
            cpu: 6m
            memory: 120Mi
      dnsPolicy: ClusterFirst

这是我的后端服务：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: identity
  name: backend
  namespace: default
spec:
  clusterIP: 10.233.34.115
  ports:
  - name: tcp
    port: 16006
    protocol: TCP
    targetPort: 16006
  - name: internal-http-rpc
    port: 8457
    protocol: TCP
    targetPort: 8457
  selector:
    app: backend
  sessionAffinity: None
  type: ClusterIP

Answer 1

这是一个社区维基答案。 随意扩展它。

正如@TomerLeibovich 已经提到的，这里的主要问题是由于探针配置：

探针有许多字段，您可以使用它们来更精确地控制活动性和就绪性检查的行为：

• initialDelaySeconds ：容器启动后，在启动活动或就绪探测之前的秒数。 默认为 0 秒。 最小值为 0。

• periodSeconds ：执行探测的频率（以秒为单位）。 默认为 10 秒。 最小值为 1。

• timeoutSeconds ：探测超时的秒数。 默认为 1 秒。 最小值为 1。

• successThreshold ：探测失败后被视为成功的最小连续成功。 默认为 1。对于 liveness 和 startup Probes，必须为 1。 最小值为 1。

• failureThreshold ：当探测失败时，Kubernetes 将在放弃之前尝试 failureThreshold 次。 在 liveness probe 的情况下放弃意味着重新启动容器。 在就绪探测的情况下，Pod 将被标记为未就绪。 默认为 3。最小值为 1。

加上正确的Pod 驱逐配置：

当可用计算资源不足时， kubelet需要保持节点稳定性。 这在处理不可压缩的计算资源时尤其重要，例如 memory 或磁盘空间。 如果这些资源耗尽，节点就会变得不稳定。

将阈值更改为 1 而不是 3 并减少 pod-eviction 解决了这个问题，因为 Pod 现在被更快地驱逐了。

编辑：

在这种情况下，另一种可能的解决方案是 label 其他节点与应用后端，以确保每个后端/pod 部署在不同的节点上。 在您当前的情况下，部署在节点上的一个 pod 已从端点中删除，应用程序变得无响应。

此外，从不健康节点触发 pod 驱逐的解决方法是将容忍度添加到

deployment.spec. template.spec: tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 60 

而不是使用默认值： tolerationSeconds: 300 。

您可以在本文档中找到更多信息。