如何在 Kubernetes 中设置 Deployment 副本的不同环境变量答案

【问题标题】：how to set different environment variables of Deployment replicas in kubernetes如何在 Kubernetes 中设置 Deployment 副本的不同环境变量
【发布时间】：2019-09-13 11:36:10
【问题描述】：

现在通过将 Deployment 的副本设置为 4，我有 4 个 k8s pod。

apiVersion: v1
kind: Deployment
metadata:
  ...
spec:
  ...
  replicas: 4
...

POD 将获取数据库中的项目并使用它，数据库中的项目有一个列class_name。

现在我想要一个 pod 只得到一个 class_name 的项目。例如pod1 仅获取class_name 等于class_name_1 的项目，pod2 仅获取class_name 等于class_name_2 的项目...

所以我想将不同的class_name 作为环境变量传递给不同的部署 POD。可以在Deployment的yaml文件中定义吗？

或者还有其他方法可以实现我的目标吗？（比如在 k8s 中部署以外的其他方法）

【问题讨论】：

标签： deployment kubernetes environment-variables kubernetes-deployment

【解决方案1】：

对于分布式作业处理部署不是很好，因为它们没有任何类型的排序或一致的 pod 主机名。最好使用 StatefulSet，因为它们的命名是一致的，比如 pod-0、pod-1、pod-2。您可以依赖该主机名索引。

例如，如果你的class_name_idx - 是类名列表中类名的索引，num_replicas - 是 StatefulSet 中的副本数，pod_idx - 是 Pod 在 StatefulSet 中的索引，那么 pod 应该仅在以下情况下运行作业：class_name_idx % num_replicas == pod_idx。

遗憾的是，无法使用Downward API 在 pod 内动态获取 StatefulSet 副本的数量，因此您可以对其进行硬编码或使用 Kubernetes API 从集群中获取。

【讨论】：

【解决方案2】：

无论是部署还是其他任何东西都无助于实现您的目标。您的目标是某种逻辑，它应该通过应用程序中的代码来实现。

由于部署是同一应用程序的一些实例，唯一可能对您有用的是：使用多个部署，每个部署都有自己的任务。第一个可以得到class_name_1 项目，而其他class_name_2、class_name_3 等。但这不是一个好主意

【讨论】：

【解决方案3】：

我不推荐这种方法，但最接近你想要做的事情是使用 stateful-set 并使用 pod 名称作为索引。

当您部署有状态集时，pod 将以其有状态集名称命名，在以下示例中：

apiVersion: v1
kind: Service
metadata:
  name: kuard
  labels:
    app: kuard
spec:
  type: NodePort
  ports:
  - port: 8080
    name: web
  selector:
    app: kuard
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kuard
spec:
  serviceName: "kuard"
  replicas: 3
  selector:
    matchLabels:
      app: kuard
  template:
    metadata:
      labels:
        app: kuard
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:1 
        ports:
        - containerPort: 8080
          name: web

statefulset 创建的 pod 将被命名为：

kuard-0
kuard-1
kuard-2

这样，您可以根据类命名有状态集，即：class-name，创建的 pod 将是 class-name-0，您可以将 _ 替换为 -。或者只是去掉名称以获得最后的索引。

要获取名称，只需读取环境变量HOSTNAME

此命名是一致的，因此您可以确保名称后始终有 0、1、2、3。如果2 发生故障，它将被重新创建。

就像我说的，我不推荐这种方法，因为您将基础架构与代码绑定在一起，并且也无法扩展（如果需要），因为每个服务都是唯一的，并且添加新实例会获得新的 id。

更好的方法是为每个类使用一个部署，并将适当的值作为环境变量传递。

【讨论】：