Повторное развертывание сертификатов после истечения срока их действия в кластере kubernetes

Срок действия сертификатов в моем kubernetes истек. Каковы шаги по повторному развертыванию сертификатов. После передислокации это влияет на здоровье модуля. Как мне это преодолеть?

[mdupaguntla@iacap067 K8S_HA_Setup_Post_RPM_Installation_With_RBAC]$ sudo kubectl logs elasticsearch-logging-0
+ export NODE_NAME=elasticsearch-logging-0
+ NODE_NAME=elasticsearch-logging-0
+ export NODE_MASTER=true
+ NODE_MASTER=true
+ export NODE_DATA=true
+ NODE_DATA=true
+ export HTTP_PORT=9200
+ HTTP_PORT=9200
+ export TRANSPORT_PORT=9300
+ TRANSPORT_PORT=9300
+ export MINIMUM_MASTER_NODES=2
+ MINIMUM_MASTER_NODES=2
+ chown -R elasticsearch:elasticsearch /data
+ ./bin/elasticsearch_logging_discovery
F0323 07:18:25.043962       8 elasticsearch_logging_discovery.go:78] kube-system namespace doesn't exist: Unauthorized
goroutine 1 [running]:
k8s.io/kubernetes/vendor/github.com/golang/glog.stacks(0xc4202b1200, 0xc42020a000, 0x77, 0x85)
        /go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:766 +0xcf
k8s.io/kubernetes/vendor/github.com/golang/glog.(*loggingT).output(0x1a38100, 0xc400000003, 0xc4200ba2c0, 0x1994cf4, 0x22, 0x4e, 0x0)
        /go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:717 +0x322
k8s.io/kubernetes/vendor/github.com/golang/glog.(*loggingT).printf(0x1a38100, 0x3, 0x121acfe, 0x1e, 0xc4206aff50, 0x2, 0x2)
        /go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:655 +0x14c
k8s.io/kubernetes/vendor/github.com/golang/glog.Fatalf(0x121acfe, 0x1e, 0xc4206aff50, 0x2, 0x2)
        /go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:1145 +0x67
main.main()
        /go/src/k8s.io/kubernetes/cluster/addons/fluentd-elasticsearch/es-image/elasticsearch_logging_dis

person vamsi krishna    schedule 03.04.2018    source источник


Ответы (1)


Срок действия сертификатов в моем kubernetes истек. Каковы шаги по повторному развертыванию сертификатов. После передислокации это влияет на здоровье модуля. Как мне это преодолеть?

...

F0323 07:18:25.043962 8 elasticsearch_logging_discovery.go:78] пространство имен kube-system не существует: несанкционированное

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

Если это так, то вам нужно будет сделать (по крайней мере) одну из следующих двух вещей:

Извлеките старые файлы закрытых ключей из резервной копии, сгенерируйте из них CSR, повторно выдайте сертификаты API и запишите это как ценный урок, чтобы не удалять закрытые ключи снова без тщательного размышления.

Or:

Удалите все serviceAccounts< /a>, названный в любом Pod serviceAccountName, для каждого пространства имен, с последующим удалением самих этих модулей, чтобы восстановить их volumeMount:s. Дополнительная информация находится в руководстве администратора.

Если все пойдет хорошо, ServiceAccountController воссоздаст эти секреты ServiceAccount, что позволит этим Pod возобновить работу, и вы снова в деле.

Конкретных шагов по управлению сертификатами X.509 для кластера слишком много, чтобы уместиться в одном поле для ответов, но это общий обзор того, что должно произойти.

person mdaniel    schedule 04.04.2018
comment
Пробовал с первого подхода. Получил решение для моей проблемы. Спасибо. Могу ли я узнать причину использования старого закрытого ключа для создания новых сертификатов? - person vamsi krishna; 04.04.2018
comment
Могу ли я узнать причину использования старого закрытого ключа для создания новых сертификатов, потому что закрытый ключ представляет собой настоящий контракт между apiserver и остальной частью кластера; сертификат, как вы видели, содержит более эфемерные детали, такие как CN, истечение срока действия и т. д. Этот процесс точно такой же, как и обычное продление SSL, и по той же причине. - person mdaniel; 05.04.2018
comment
Привет, Мэтью Л. Даниэль, не могли бы вы помочь мне решить эту проблему? stackoverflow.com/questions/51303819/rbac-error-in-kubernetes< /а> - person vamsi krishna; 12.07.2018