来自 Kubernetes 中副本集的单个工作 Pod

编程问答 2022-06-02

问题描述

我们有一项定期查询数据库记录的服务。对于 HA，我们希望拥有副本。但是有了副本，所有的然后查询数据库记录。

以下 Deployment 清单用于部署。但在此配置中，一个 pod 正在接收流量。但它们都查询数据库并执行操作。

apiVersion: apps/v1
kind: Deployment
Metadata:
  name: db-queries 
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: db-queries 
  template:
    Metadata:
      labels:
        app: db-queries
        version: v1 
    spec:
      serviceAccountName: leader-election-test
      containers:
      - name: db-queries
        image: our-registry:5000/db-queries
        imagePullPolicy: Always
        ports:
        - containerPort: 8090
        volumeMounts:
          - readOnly: true
            mountPath: /path/to/config
            name: config-files
      - name: mako
        image: gcr.io/google_containers/leader-elector:0.4
        imagePullPolicy: Always
        args:
        -  --election=sample

此处 mako 容器显示只有一个 Pod 作为领导者持有锁。我们只需要一个 pod 来查询数据库记录，其他两个保持理想状态。

解决方法

可用性

Kubernetes 可以实现不同级别的可用性，这完全取决于您的要求。

您的用例似乎是在数据库中只有一个副本应该处于活动状态。

单个副本

即使您在 Kubernetes 部署或 StatefulSet 中使用单个副本，也会使用您声明的 LivenessProbe 和 ReadinessProbe 定期对其进行探测。

如果您的应用在 LivenessProbe 上没有响应，则会立即创建一个新的 Pod。

多个副本使用Leader选举

由于一次只有一个副本应该与您的数据库建立活动连接，因此leader选举解决方案是可行的。

当前没有锁的被动副本应该定期尝试获取锁 - 以便在旧的主动 pod 死亡的情况下它们会变得活跃。如何做到这一点取决于实现和配置。

如果您希望只有多副本解决方案中的活动 Pod 应该查询数据库，应用程序必须首先检查它是否有锁（例如，是否是活动实例）。

结论

单副本部署和使用leader选举的多副本部署之间没有太大区别。故障转移所需的时间可能略有不同。

对于单副本解决方案，您可能会考虑使用 StatefulSet 而不是 Deployment，因为当节点无法访问时会出现不同的行为。

kubernetesreplicaset