kubernetes - 由于新增了 “Pending”字段，因此在Google Kubernetes Engine上添加了 “priority”

Question

我在Helm管理的GKE上有一个Kubernetes集群，最近部署开始失败，因为Pod不会离开Pending状态。检查挂起的 pods ，我看到了:

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 pods 与当前正在运行的 pods 进行比较，我看到的唯一区别(除了时间戳等)是:

$ 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
…

看来这是在2019年5月1日至2019年5月6日之间的某个时间开始发生的。

我在这里用作示例的集群是登台集群，但是我注意到两个配置相似的生产集群上的行为相同，这使我相信Google Kube方面有所变化。

Helm通过 cloudbuild.yaml部署了Pod，在似乎已引入回归的5月1日至5月6日之间，该设置(Helm的版本或cloudbuild文件)没有任何改变。

Helm 版本:

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

Answer 1

如果您看到Pod priority and Preemption的文档，则该功能是alpha中的<= 1.10(默认情况下已禁用，由功能闸(由GKE在控制平面上不执行的功能门，afaik启用)启用)，然后它变成了beta中的>= 1.11(默认情况下启用)。

可以是或组合:

您有一个GKE控制平面>= 1.11，并且您的Pod尝试启动的节点(由kube-scheduler调度)正在运行kubelet <= 1.10。有人可能已经升级了控制平面，而没有升级节点(或实例组)

有人将控制平面升级到1.11或更高版本，并且默认情况下启用了优先级允许 Controller ，这阻止了设置了spec.priority字段的Pods的启动(或重新启动)。如果看到API docs(优先级字段)，则表示启用优先级允许 Controller 后，您将无法设置该字段，而该字段只能由PriorityClass/PriorityClassName设置。