库伯奈特复制品中的单工作荚

Question

我们有一个定期查询数据库记录的服务。对于HA，我们想要复制。但是对于副本，所有这些都会查询数据库记录。

下面的Deployment清单用于部署。但在这种配置中，一个吊舱正在接收通信量。但是它们都查询数据库并执行操作。

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容器显示，只有一个吊舱作为保持锁的领头工作。我们只想要一个荚来查询数据库记录，而另外两个则是理想的。

Answer 1

可用性

在Kubernetes中可以实现不同级别的可用性，这取决于您的需求。

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

单副本

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

如果你的应用程序在LivenessProbe上没有响应，一个新的豆荚将被立即创建。

使用领袖选举的多个副本

由于一次只有一个副本应该与您的数据库有活动连接，所以领导人选举解决方案是可行的。

目前没有锁的被动复制体，应该定期尝试获得锁，这样它们就会变得活跃起来，以防旧的活动舱死掉。如何做到这一点取决于实现和配置。

如果您希望只有乘法副本解决方案中的active Pod能够查询数据库，则应用程序必须首先检查它是否有锁(例如，是活动实例)。

结论

单个副本部署与使用领导人选举的多副本部署没有太大区别。故障转移所需的时间可能有很小的差异。

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