[Перекрестная публикация на форуме k8s Discuss - извиняюсь, если это считается дурным тоном.]
Привет!
Со свежим кластером 1.13.3, созданным через Kubernetes The Hard Wayплюс дополнительная конфигурация для начальной загрузки TLS, я изо всех сил пытаюсь получить автоматическое одобрение сертификатов kubelet server .Клиентские сертификаты загружаются нормально, и связь 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.Но запросы на подпись сертификатов: 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"]
И затем я связываю роль с системой:группа узлов:
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
И, чтобы быть уверенным, система: узлы - это одна из групп, связанных с CSR сервера:
$ kubectl get csr csr-m7rjs -o template --template {{.spec.groups}}
[system:nodes system:authenticated]
Я пробовал несколько часов на черныйУровни копирования и вставки из-за переполнения стека (большинство советов действительно применимо к более старым версиям 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 является истинным по умолчанию с 1.12, я полагаю, что аргумент --feature-gates является избыточным, но я его оставил.)
Большое спасибо за любыепомощь, которую вы можете предложить.