Jika sebagai tanggapan terhadap
kubectl get pod perintah
kubectl get pod Anda dapatkan:
Unable to connect to the server: x509: certificate has expired or is not yet valid
kemudian, kemungkinan besar, satu tahun telah berlalu, sertifikat kubernetes Anda kedaluwarsa, komponen kluster berhenti menggunakannya, interaksi di antara mereka berhenti dan kluster Anda berubah menjadi labu.
Apa yang harus dilakukan dan cara mengembalikan cluster?
Pertama, kita perlu memahami di mana sertifikat yang perlu diperbarui berada.
Bergantung pada cara cluster diinstal, lokasi dan nama file sertifikat dapat bervariasi. Jadi, misalnya, saat membuat cluster, Kubeadm menguraikan file sertifikat sesuai dengan
praktik terbaik . Dengan demikian, semua sertifikat terletak di
/etc/kuberenetes/pki , masing-masing dalam file dengan ekstensi
.crt , kunci pribadi, dalam file
.key . Plus di
/etc/kubernetes/ adalah file
/etc/kubernetes/ dengan konfigurasi akses untuk administrator akun pengguna, pengontrol manajer, sheduler dan kubelet dari node master. Sertifikat dalam file .conf terletak di bidang data pengguna.client-sertifikat-data dalam bentuk yang disandikan base64.
Anda dapat melihat tanggal kedaluwarsa kepada siapa dikeluarkan dan oleh siapa sertifikat ditandatangani menggunakan skrip shcert kecil ini
Masih ada sertifikat yang menggunakan kubelet pada simpul kerja untuk otentikasi di API. Jika Anda menggunakan kubeadm join untuk menambahkan node ke cluster, maka kemungkinan besar node terhubung menggunakan prosedur
bootstrap TLS , di mana kubelet dapat memperbarui sertifikat secara otomatis jika diberi opsi
--rotate-certificates . Di kubernet versi terbaru, opsi ini sudah diaktifkan secara default.
Memeriksa bahwa node terhubung menggunakan prosedur bootstrap TLS cukup sederhana - dalam kasus ini, file
/etc/kubernetes/kubelet.conf biasanya ditentukan dalam file sertifikat klien di file
/var/lib/kubelet/pki/kubelet-client-current.pem yang merupakan symlink ke sertifikat saat ini.
Anda juga dapat melihat tanggal kedaluwarsa sertifikat ini menggunakan skrip
shcertKami kembali ke masalah memperbarui sertifikat.Jika Anda menginstal cluster menggunakan kubeadm, maka saya punya kabar baik untuk Anda. Dimulai dengan versi 1.15, kubeadm dapat memperbarui hampir semua sertifikat bidang kendali dengan satu perintah
kubeadm alpha certs renew all
Perintah ini akan memperbarui semua sertifikat di direktori / etc / kubernetes, meskipun sudah kadaluarsa dan semuanya telah rusak.
Hanya sertifikat kubelet tidak akan diperbarui - ini adalah yang terletak di file
/etc/kubernetes/kubelet.conf !
Pembaruan: kubeadm, dimulai dengan versi 1.17, termasuk pada semua node (bahkan pada wizard pertama di mana kubeadm init dilakukan) pembaruan otomatis sertifikat culet. Memeriksa sangat sederhana - di /etc/kubernetes/kubelet.conf path ke file /var/lib/kubelet/pki/kubelet-client-current.pem akan ditunjukkan di bidang sertifikat klien
Untuk memperbarui sertifikat ini, gunakan perintah buat akun pengguna
kubeadm alpha kubeconfig user --client-name system:node:kube.slurm.io --org system:nodes > /etc/kubernetes/kubelet.conf
Jika sistem memiliki akun pengguna, perintah ini memperbarui sertifikat untuk akun ini. Jangan lupa untuk menentukan nama host yang benar dalam opsi
--client-name , Anda dapat
--client-name nama host di bidang Subjek dari sertifikat yang ada:
shcert /etc/kubernetes/kubelet.conf
Dan tentu saja, setelah memperbarui sertifikat, Anda perlu me-restart semua komponen dari pesawat kontrol, me-reboot seluruh node atau menghentikan wadah dengan etcd, api, controller-manager dan scheduler dengan
docker stop , dan kemudian memulai kembali sistem
systemctl restart kubelet .
Jika kluster Anda memiliki versi lama: 1.13 atau kurang, itu tidak akan berfungsi untuk memutakhirkan kubeadm menjadi 1.15, karena ia menarik sepanjang ketergantungan kubelet dan kubernetes-cni, yang dapat menyebabkan masalah, karena kinerja komponen kluster berbeda dalam versi oleh lebih dari satu panggung, tidak dijamin. Cara termudah untuk keluar dari situasi ini adalah dengan menginstal kubeadm pada komputer lain, mengambil file biner
/usr/bin/kubeadm , menyalinnya ke node master dari cluster yang telah meninggal dan menggunakannya hanya untuk memperbarui sertifikat. Dan setelah cluster direvitalisasi, perbarui langkah demi langkah menggunakan metode biasa, instal kubeadm satu versi lebih baru setiap kali.
Dan akhirnya, dari versi 1.15 kubeadm belajar cara memperbarui semua-semua sertifikat ketika memperbarui sebuah cluster dengan perintah
kubeadm upgrade . Jadi, jika Anda secara teratur memperbarui cluster Anda setidaknya sekali setahun, sertifikat Anda akan selalu valid.
Tetapi jika cluster tidak diinstal menggunakan kubeadm, maka Anda harus mengambil openssl dan memperbarui semua sertifikat secara individual.
Masalahnya adalah bahwa sertifikat berisi bidang yang diperluas, dan alat instalasi cluster yang berbeda dapat menambahkan kumpulan bidangnya sendiri. Selain itu, nama-nama bidang ini dalam konfigurasi openssl dan dalam output isi sertifikat berkorelasi, tetapi lemah. Perlu untuk google dan pilih.
Saya akan memberikan contoh konfigurasi untuk openssl, di bagian terpisah di mana atribut diperluas dijelaskan, khusus untuk setiap jenis sertifikat. Kami akan merujuk ke bagian yang sesuai saat membuat dan menandatangani csr. Konfigurasi ini digunakan untuk merevitalisasi klaster yang didirikan setahun yang lalu oleh pemilik peternakan.
openssl.cnf [req] distinguished_name = req_distinguished_name req_extensions = v3_req [v3_req] keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [client] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [apiproxyclient] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth [etcd] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [api] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = ec2-us-east-1-1a-c1-master-2 DNS.2 = ec2-us-east-1-1a-c1-master-3 DNS.3 = ec2-us-east-1-1a-c1-master-1 DNS.4 = localhost DNS.5 = kubernetes DNS.6 = kubernetes.default DNS.7 = kubernetes.default.svc DNS.8 = kubernetes.default.svc.cluster.local IP.1 = 10.0.0.109 IP.2 = 10.0.0.159 IP.3 = 10.0.0.236 IP.4 = 127.0.0.1 IP.5 = 10.43.0.1
Atribut aktual dan nama tambahan dalam sertifikat dapat dilihat menggunakan perintah
openssl x509 -in cert.crt -text
Saat memperbarui sertifikat untuk API server, saya punya masalah: sertifikat yang diperbarui tidak berfungsi. Solusinya adalah mengeluarkan sertifikat yang berlaku selama 1 tahun di masa lalu.
Dalam openssl, Anda tidak dapat mengeluarkan sertifikat yang valid di masa lalu dengan perintah sederhana, kode tersebut secara tegas menyatakan bahwa sertifikat hanya valid dari saat ini. Tetapi Anda dapat kembali ke masa lalu menggunakan perpustakaan libfaketime
yum install libfaketime LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req ...
Kami menerbitkan sertifikat tambahan sesuai dengan algoritma berikut:
Kami membuat CSR menggunakan sertifikat yang ada, tentukan bagian yang diinginkan dengan daftar atribut lanjutan di file konfigurasi:
openssl x509 -x509toreq -in "node.cert" -out "node.csr" -signkey "node.key" -extfile "openssl.cnf" -extensions client
Kami menandatanganinya dengan sertifikat akar yang sesuai, menggeser waktu 1 tahun yang lalu dan menentukan bagian yang diinginkan dengan daftar atribut lanjutan di file konfigurasi
LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req -days 36500 -in "node.csr" -CA "kube-ca.pem" -CAkey "kube-ca-key.pem" -CAcreateserial -out "node.new.cert" -extfile "openssl.cnf" -extensions client
Kami memeriksa atribut dan memulai kembali komponen bidang kontrol.
Sergey Bondarev,
Guru Slurm
slurm.io