【问题标题】:nodeSelector does not reliably place pods on the correct EKS worker nodesnodeSelector 无法可靠地将 pod 放置在正确的 EKS 工作节点上
【发布时间】:2020-03-11 20:31:18
【问题描述】:

我在 EKS 中运行 Kubernetes 集群,但由于某种原因,部署中的 nodeSelector 属性并不总是被遵循。

三个部署: 1 - 卡桑德拉:

kind: StatefulSet
metadata:
  name: cassandra
  labels:
    app: cassandra
spec:
  serviceName: cassandra
  replicas: 3
...
    spec:
      terminationGracePeriodSeconds: 1800
      containers:
      - name: cassandra
        image: gcr.io/google-samples/cassandra:v13
...
      nodeSelector:
        layer: "backend"

2 - 卡夫卡

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    service: kafka
...
    spec:
      containers:
        image: strimzi/kafka:0.11.3-kafka-2.1.0
...
      nodeSelector:
        layer: "backend"
...

3 - 动物园管理员

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    service: zookeeper
...
    spec:
      containers:
        image: strimzi/kafka:0.11.3-kafka-2.1.0
...
      nodeSelector:
        layer: "backend"
...

注意 - 所有三个在容器规范中都有 nodeSelector “layer=backend”。但是,当我查看看到的 pod 时,我只有 2 个“后端”pod:

% kubectl get all -o wide
NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE                                         NOMINATED NODE   READINESS GATES
pod/cassandra-0                  1/1     Running   0          9m32s   10.1.150.39    ip-...-27.us-west-2.compute.internal    <none>           <none>
pod/cassandra-1                  1/1     Running   0          7m56s   10.1.100.7     ip-...-252.us-west-2.compute.internal   <none>           <none>
pod/cassandra-2                  1/1     Running   0          6m46s   10.1.150.254   ip-...-27.us-west-2.compute.internal    <none>           <none>
pod/kafka-56dcd8665d-hfvz4       1/1     Running   0          9m32s   10.1.100.247   ip-...-252.us-west-2.compute.internal   <none>           <none>
pod/zookeeper-7f74f96f56-xwjjt   1/1     Running   0          9m32s   10.1.100.128   ip-...-154.us-west-2.compute.internal   <none>           <none>

它们被放置在三个不同的节点上 - 27、252 和 154。查看每个节点上的“层”标签:

> kubectl describe node ip-...-27.us-west-2.compute.internal | grep layer
                    layer=backend
> kubectl describe node ip-...-252.us-west-2.compute.internal | grep layer
                    layer=backend
> kubectl describe node ip-...-154.us-west-2.compute.internal | grep layer
                    layer=perf

154 节点的标签是“perf”,而不是“backend”。所以根据我对 nodeSelector 的理解,zookeeper pod 不应该放在那里。我已经删除了所有内容(包括节点本身)并尝试了几次 - 有时是 kafka 被放在那里,有时是 zookeeper,但确实有些东西被放在了不应该放在的地方。

据我所知,我确实想要的节点有足够的容量,即使它们没有,我也希望出现无法调度 pod 的错误,而不是忽略 nodeSelector。

我错过了什么? nodeSelector 不是 100% 可靠吗?还有其他方法可以强制 pod 仅放置在具有特定标签的节点上吗?

【问题讨论】:

  • 鉴于您省略了很多细节,我们无法为您提供帮助。 kubernetes——甚至是它愚蠢的 EKS 表亲——极不可能自发停止兑现 nodeSelector:,更有可能是您的实验存在缺陷
  • nodeSelector 是从一开始就配置好的吗?还是中间加的?
  • 如果它是在 Pod 已经创建后添加的,只需重启 Pod,如果还没有,它将进入正确的节点。
  • 除了其他人所说的之外,更传统的方法是污点。创建一个您喜欢的实例类型的节点组,并将其设置为使用 backend 之类的键进行污染,然后对 pod 应用匹配的容忍度。

标签: kubernetes amazon-eks


【解决方案1】:

作为用户错误关闭。

一个单独的进程恢复了我的 git 更改,而我在 IDE 中查看的部署已过时。

【讨论】:

    猜你喜欢
    • 2020-01-15
    • 2019-07-28
    • 2019-06-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多