标签: nodeselector

在 pod 定义中，我们将 nodeSelector 添加为 spec 的子项。但我不确定如何将其添加到部署 yaml 文件中

我们是否应该将其添加到模板的规范中？

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: first-deployment
  labels: 
    app: first
spec:
  replicas: 1
  template:
    metadata:
      name: first-deployment-pod
      label: 
        app: first
    spec:
      containers:
      - name: test
        image: test/test
    nodeSelector:
      testkey: testvalue

 

或者我们是否需要将其添加到部署规范中 -

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: first-deployment
  labels: 
    app: first
spec:
  replicas: 1
  nodeSelector:
    testkey: testvalue
  template:
    metadata:
      name: first-deployment-pod
      label: 
        app: first
    spec:
      containers:
      - name: test
        image: test/test
    
 

我有一个具有 2 个节点的集群，其中一个节点被标记为“SS”作为节点选择器。

我有三个服务，一个服务应该部署在节点选择器节点中（这正常发生），另外两个服务应该部署在另一个节点中

剩下的服务应该如何部署在一个节点（未标记的）上？

我不想对其他两个服务也使用节点选择器。

我们正在使用 Gitlab Runner 和 Kubernetes 执行器，我们正在思考我认为目前不可能的事情。我们希望将 Gitlab Runner 守护进程的 pod 分配给实例类型为 X 的特定节点组的工作线程，并将作业的 pod 分配给不同节点组 Y 工作节点，因为这些节点通常比 Gitlab Runner 的 pod 需要更多的计算资源。

这样做是为了节省成本，因为 Gitlab 运行程序主守护进程将始终运行在节点上，然后我们希望它在便宜的实例上运行，然后需要更多计算能力的作业可以在不同的实例上运行具有不同的类型，将由 Cluster Autoscaler 启动，并在不存在作业时销毁。

我对此功能进行了调查，将 pod 分配到特定节点的可用方法是使用节点选择器或节点亲和性，但这两个配置部分中包含的规则适用于 Gitlab Runner 的所有 pod，主 Pod 和工作 Pod。该提案旨在使应用两种单独的配置成为可能，一种用于 Gitlab Runner 的 Pod，另一种用于作业的 Pod。

当前的现有配置由节点选择器和节点/pod 亲和力组成，但正如我提到的，这些配置全局适用于所有 pod，而不是我们在本例中想要的指定的 pod。

Gitlab Runner Kubernetes 执行器配置：https://docs.gitlab.com/runner/executors/kubernetes.html