Модули "Ожидание" в Google Kubernetes Engine из-за нового поля "Приоритет" - PullRequest
1 голос
/ 13 мая 2019

У меня есть кластер Kubernetes в GKE, которым управляет Helm, и недавно развертывание начало давать сбой, потому что модули не выходили из состояния Pending. Осматривая ожидающие решения я вижу:

Events:
  Type     Reason            Age                From                                                Message
  ----     ------            ----               ----                                                -------
  Normal   Scheduled         50m                default-scheduler                                   Successfully assigned default/my-pod-6cbfb94cb-4pzl9 to gke-staging-pool-43f2e11c-nzjz
  Warning  FailedValidation  50m (x6 over 50m)  kubelet, gke-staging-pool-43f2e11c-nzjz  Error validating pod my-pod-6cbfb94cb-4pzl9_default(8e4dab93-75a7-11e9-80e1-42010a960181) from api, ignoring: spec.priority: Forbidden: Pod priority is disabled by feature-gate

И, в частности, это предупреждение представляется актуальным: Error validating pod my-pod-6cbfb94cb-4pzl9_default(8e4dab93-75a7-11e9-80e1-42010a960181) from api, ignoring: spec.priority: Forbidden: Pod priority is disabled by feature-gate

Сравнение новых модулей Pending с текущими модулями, единственное отличие, которое я вижу (кроме меток времени и т. Д.):

$ kubectl get pod my-pod-6cbfb94cb-4pzl9 -o yaml > /tmp/pending-pod.yaml
$ kubectl get pod my-pod-7958cc964-64wsd -o yaml > /tmp/running-pod.yaml
$ diff /tmp/running-pod.yaml /tmp/pending-pod.yaml
…
@@ -58,7 +58,8 @@
       name: default-token-wnhwl
       readOnly: true
   dnsPolicy: ClusterFirst
-  nodeName: gke-staging-pool-43f2e11c-r4f9
+  nodeName: gke-staging-pool-43f2e11c-nzjz
+  priority: 0 // <-- notice that the `priority: 0` field is added
   restartPolicy: Always
   schedulerName: default-scheduler
…

Похоже, это начало происходить где-то между 1 мая 2019 года и 6 мая 2019 года.

Кластер, который я использовал здесь в качестве примера, является промежуточным кластером, но я заметил такое же поведение на двух одинаково настроенных производственных кластерах, что позволяет мне полагать, что произошли изменения на стороне Google Kube.

Модули развертываются с помощью Helm через cloudbuild.yaml, и в этой настройке ничего не изменилось (ни версия Helm, ни файл cloudbuild) в период с 1 по 6 мая, когда кажется, что регрессия была введена.

Версия шлема:

Client: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}

1 Ответ

2 голосов
/ 14 мая 2019

Если вы видите документы для Приоритет Pod и Preemption , эта функция равна alpha в <= 1.10 (по умолчанию отключена, активируется шлюзом функций, который GKE не делает в плоскости управления, afaik) затем он стал beta в >= 1.11 (включен по умолчанию).

Может быть либо комбинацией, либо:

  1. У вас есть управляющая плоскость GKE >= 1.11, а узел, с которого ваш Pod пытается запустить (который запланирован планировщиком куба), запускает кублет <= 1.10. Кто-то мог обновить плоскость управления, не обновляя узлы (или группу экземпляров)

  2. Кто-то обновил плоскость управления до 1.11 или более поздней, и контроллер доступа с приоритетом включен по умолчанию, и он запрещает запуск (или перезапуск) модулей с установленным полем spec.priority. Если вы видите API docs (поле приоритета), это говорит о том, что когда включен контроллер доступа с приоритетом, вы не можете установить это поле, и это поле может быть установлено только с помощью PriorityClass / PriorityClassName .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...