Как включить автоматическое утверждение CSR для сертификатов сервера kubelet?

[Перекрестно размещено на форуме обсуждения k8s - извиняюсь, если это считается дурным тоном.]

Привет!

Со свежим кластером 1.13.3, установленным через Kubernetes The Hard Way, а также с дополнительной конфигурацией для начальной загрузки TLS, я изо всех сил пытаюсь получить автоматическое одобрение сертификатов сервера kubelet. Клиентские сертификаты отлично загружаются, и связь kubelet -> apiserver работает без сбоев, но связь apiserver -> kubelet является проблемой.

Серверные сертификаты запрашиваются, но они застряли в ожидании ручного вмешательства, и я не смог предугадать заклинание RBAC, необходимое для автоматического утверждения серверных CSR так же, как и клиентских CSR.

Вот CSR (после восстановления кластера):

NAME                                                   AGE   REQUESTOR                      CONDITION
csr-m7rjs                                              4s    system:node:k8s-lab3-worker1   Pending
node-csr-aTpBsagYzYaZYJM6iGMN5AvqzVXATDj1BrmZs_dZCJA   5s    system:bootstrap:ec5591        Approved,Issued

На этом этапе очевидно, что связь apiserver -> kubelet (через kubectl exec или logs) не работает. Если я утверждаю сертификат вручную, все работает как положено.

Тот факт, что отправляются клиентские и серверные CSR, заставляет меня думать, что kubelet настроен правильно (плюс тот факт, что ручное одобрение заставляет его работать).

Главное, что вызывает у меня паучье чутье, - это тот факт, что при первом запуске apiserver я вижу:

Feb  6 00:14:13 k8s-lab3-controller1[3495]: I0206 00:14:13.697030    3495 storage_rbac.go:187] created clusterrole.rbac.authorization.k8s.io/system:certificates.k8s.io:certificatesigningrequests:nodeclient
Feb  6 00:14:13 k8s-lab3-controller1[3495]: I0206 00:14:13.706561    3495 storage_rbac.go:187] created clusterrole.rbac.authorization.k8s.io/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient

Роли кластера для подписи сертификата клиента автоматически создаются apiserver. Но certificateigningrequests: selfnodeserver не создается автоматически. Означает ли это, что автоматическое одобрение серверных сертификатов на самом деле не реализовано или не поддерживается?

Ну, я создал это вручную:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeserver
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
rules:
- apiGroups: ["certificates.k8s.io"]
  resources: ["certificatesigningrequests/selfnodeserver"]
  verbs: ["create"]

А потом привязываю роль к группе system: nodes:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: auto-approve-server-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeserver
  apiGroup: rbac.authorization.k8s.io

И, чтобы быть уверенным, system: nodes - это одна из групп, связанных с сервером CSR:

$ kubectl get csr csr-m7rjs -o template --template {{.spec.groups}}
[system:nodes system:authenticated]

Я пробовал несколько часов уровней черного пояса копирования и вставки из Stack Overflow (причем большинство советов действительно применимы к более старым версиям Kubernetes), но безрезультатно. Я надеюсь, что мозговой трест поймет, что я делаю неправильно.

Если это актуально, вот как я запускаю apiserver (и снова это v1.13.3, так что я):

/usr/local/bin/kube-apiserver \
  --advertise-address=172.24.22.168 \
  --allow-privileged=true \
  --anonymous-auth=false \
  --apiserver-count=3 \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=10 \
  --audit-log-maxsize=100 \
  --audit-log-path=/var/log/audit.log \
  --authorization-mode=Node,RBAC \
  --bind-address=0.0.0.0 \
  --client-ca-file=/etc/kubernetes/pki/ca.crt \
  --enable-admission-plugins=Initializers,NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,AlwaysPullImages,DenyEscalatingExec,SecurityContextDeny,EventRateLimit \
  --admission-control-config-file=/etc/kubernetes/admissionconfig.yaml \
  --enable-bootstrap-token-auth=true \
  --enable-swagger-ui=true \
  --etcd-cafile=/etc/kubernetes/pki/ca.crt \
  --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
  --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key \
  --etcd-servers=https://172.24.22.168:2379 \
  --event-ttl=1h \
  --encryption-provider-config=/etc/kubernetes/encryption-config.yaml \
  --feature-gates=RotateKubeletServerCertificate=true \
  --insecure-port=0 \
  --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt \
  --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key \
  --kubelet-https=true \
  --profiling=false \
  --repair-malformed-updates=false \
  --runtime-config=api/all \
  --service-account-lookup=true \
  --service-account-key-file=/etc/kubernetes/pki/sa.crt  \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
  --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256 \
  --tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
  --v=2

(Учитывая, что RotateKubeletServerCertificate по умолчанию имеет значение true, начиная с 1.12, я полагаю, что аргумент --feature-gates является избыточным, но я оставил его.)

Большое спасибо за любую помощь, которую вы могли бы предложить.