<p>kubeadm reset berhasil tetapi node ip ini masih dalam configmap kubeadm-config</p>

cc @abriindonesia

Idealnya akan ada cara untuk "menyegarkan" ClusterStatus. Kami menjalankan cluster dengan pengujian chaos, sangat mungkin bagi node bidang kontrol untuk dihentikan tanpa peringatan dan tanpa peluang untuk menjalankan kubeadm reset . Idealnya, akan ada cara yang bersih untuk memperbarui ClusterStatus secara eksplisit untuk menghapus node bidang kontrol yang kita tahu tidak lagi ada di cluster. Ini adalah sesuatu yang harus dilakukan sebelum menjalankan kubeadm join --control-plane ... atau mungkin sudah ada di dalamnya?

Beberapa komentar di sini:

kubeadm-config ConfigMap hapus node ip ini.

@pytimer Saya tahu bahwa memiliki alamat api node yang tersisa dalam status cluster tidak ideal, tetapi saya tertarik untuk memahami apakah "kurangnya pembersihan" ini menimbulkan masalah atau tidak. Sudahkah Anda mencoba bergabung dengan bidang kendali yang sama lagi? Sudahkah Anda mencoba untuk bergabung dengan bidang kendali lain? Saya tidak mengharapkan masalah, tetapi mendapatkan konfirmasi tentang hal ini akan sangat dihargai.

Saya masih punya pertanyaan, mengapa kubeadm reset tidak menghapus node ini langsung dari cluster? Sebagai gantinya, jalankan kubectl delete nodesecara manual.

@luxas mungkin sedikit konteks historis yang dapat membantu di sini.
Dugaan saya adalah bahwa node tidak memiliki hak untuk menghapus dirinya sendiri (tetapi ini berlaku untuk node pekerja, bukan untuk node pesawat kontrol ...)

Idealnya, akan ada cara untuk "menyegarkan" ClusterStatus / akan ada cara yang bersih untuk memperbarui ClusterStatus secara eksplisit

@danbeulieu itu poin yang bagus. memiliki perintah eksplisit untuk menyinkronkan status cluster dan atau menerapkan sinkronisasi otomatis saat kubeadm dijalankan adalah ide yang bagus.
Namun, menjadi kubeadm tanpa jenis loop kontrol yang terus berjalan, saya pikir akan selalu ada kemungkinan untuk membuat ClusterStatus tidak sinkron.
Ini seharusnya tidak menjadi masalah, atau lebih tepatnya memiliki ip node untuk node yang tidak ada lagi (kurangnya pembersihan) seharusnya tidak menjadi masalah.
Sebaliknya jika sebuah node ada dan ip node terkait hilang dari ClusterStatus (inisialisasi yang salah) ini dapat menimbulkan masalah misalnya untuk pembaruan.

Bisakah Anda melaporkan jika asumsi di atas dikonfirmasi oleh pengujian kekacauan Anda? umpan balik apa pun akan sangat dihargai.

@fabriziopandini Saya bergabung dengan node bidang kontrol yang sama, gagal.

Langkah saya bergabung:

IP node bidang kontrol kedua adalah 192.168.46.212 .

• Hapus anggota node etcd 192.168.46.212 dari cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f pada node bidang kontrol ini.
• jalankan kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 lagi.

kubeadm bergabung dengan log:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Saya melihat kode kubeadm, dan saya pikir masalah ini mungkin disebabkan oleh 192.168.46.212 tersisa di kubeadm-config ConfigMap.

Kubeadm mendapatkan titik akhir api dari kubeadm-config ConfigMap saat bergabung dengan node bidang kontrol, dan titik akhir etcd sama dengan titik akhir api. Tapi 912.168.46.212 node control-plane telah dihapus dan belum digabungkan, jadi periksa kesehatan cluster etcd salah.

Ketika saya menghapus titik akhir 192.168.46.212 api dari kubeadm-config ConfigMap, dan bergabung dengan simpul bidang kontrol ini lagi, itu bergabung dengan sukses.

@pytimer terima kasih!
Ini harus diselidiki. Sudah ada logika yang mencoba menyinkronkan daftar yang seharusnya dari titik akhir etcd dengan titik akhir daftar etcd yang sebenarnya, tetapi ada sesuatu yang tampaknya tidak berfungsi dengan baik

Ya, ini sepertinya bug. Kami memiliki ASG 3 node control plane. Jika kita menghentikan sebuah instance, yang baru akan dibuat sesuai dengan aturan ASG. Selama waktu ini node yang dihentikan terdaftar sebagai tidak sehat dalam daftar anggota etcd. Ketika instance baru muncul, sebelum menjalankan kubeadm join... , itu menghapus anggota yang tidak sehat dari etcd. Pada saat kami menjalankan kubeadm join... cluster etcd sehat dengan 2 node sesuai dengan etcd. Namun kubeadm menggunakan ClusterStatus sebagai sumber kebenarannya, yang masih mencantumkan contoh lama.

Solusi bagi kami tepat setelah melakukan manajemen keanggotaan etcd adalah memperbarui ConfigMap kubeadm-config dengan kebenaran cluster, dan kemudian menjalankan kubeadm join... .

Idealnya kubeadm join... akan menggunakan etcd sebagai sumber kebenaran dan mengupdate ConfigMap kubeadm-config yang sesuai.

@fabianofranz Saya mungkin menemukan penyebab masalah ini.

Saat menyinkronkan titik akhir etcd dengan daftar titik akhir etcd yang sebenarnya, sinkronisasi berhasil. Tapi tetapkan titik akhir etcd nyata ke klien etcd Endpoints , variabel klien ini bukan penunjuk, jadi ketika kode lain menggunakan klien, titik akhir klien ini masih titik akhir lama, bukan titik akhir yang sebenarnya setelah sinkronisasi.

Saya memperbaiki masalah ini di repositori garpu saya, Anda dapat memeriksa PR ini https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. Dan saya menguji join the same control-plane node kasus pengguna, itu bergabung dengan sukses.

@pytimer Tampak hebat! Terlihat bagus!
Bisakah Anda mengirimkan PR? IMO ini akan memenuhi syarat untuk memetik ceri.

@ neol2123 @fothysc ^^^

@fabianofranz PR pertama salah, saya lupa konfirmasi CLA.

PR https://github.com/kubernetes/kubernetes/pull/71945 ini dapat Anda periksa. Jika ada yang salah, harap Anda tunjukkan.

@fabriziopandini Saya bergabung dengan node bidang kontrol yang sama, gagal.

Langkah saya bergabung:

IP node bidang kontrol kedua adalah 192.168.46.212 .

• Hapus anggota node etcd 192.168.46.212 dari cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f pada node bidang kontrol ini.
• jalankan kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 lagi.

kubeadm bergabung dengan log:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Saya melihat kode kubeadm, dan saya pikir masalah ini mungkin disebabkan oleh 192.168.46.212 tersisa di kubeadm-config ConfigMap.

Kubeadm mendapatkan titik akhir api dari kubeadm-config ConfigMap saat bergabung dengan node bidang kontrol, dan titik akhir etcd sama dengan titik akhir api. Tapi 912.168.46.212 node control-plane telah dihapus dan belum digabungkan, jadi periksa kesehatan cluster etcd salah.

Ketika saya menghapus titik akhir 192.168.46.212 api dari kubeadm-config ConfigMap, dan bergabung dengan simpul bidang kontrol ini lagi, itu bergabung dengan sukses.

Mendapat kesalahan yang sama di kubeadm versi 1.13.2, saya mencoba menghapus node secara manual dan memperbarui kubeadm-config, tidak berhasil, node etcd lainnya masih mencoba menghubungkan node yang dihapus

Ketika saya menghapus titik akhir 192.168.46.212 api dari kubeadm-config ConfigMap, dan bergabung dengan simpul bidang kontrol ini lagi, itu bergabung dengan sukses.

@pytimer Bisakah Anda menjelaskan cara menghapus api-server lama secara manual?

Saya menjalankan 1.13.3; menghapus server lama secara manual melalui:

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

Saya masih tidak dapat bergabung dengan cluster karena kesalahan:

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

Saya kemudian mematikan pod api dan pod etcd (masing-masing 2 buah).

Mereka dibuat ulang, tetapi saya masih memiliki kesalahan yang sama ketika mencoba menghubungkan node tambahan.

Memiliki masalah yang sama di 1.13.3 (penyiapan cluster HA: 3 node master + 3 pekerja). Berhasil mengganti node master hanya setelah langkah berikutnya:

Hapus node dari cluster

kubectl delete node master03

Unduh etcdctl (misalnya, di master01)

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

Hapus node master dari etcd

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

Hapus dari kubeadm-config

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong Sekarang kubeadm reset tidak dapat menghapus anggota etcd, jadi Anda menemukan cluster etcd masih menghubungkan node etcd yang dihapus. Anda harus menghapus anggota etcd secara manual menggunakan etcdctl sekarang.

Saya mengirim PR untuk menerapkan menghapus node etcd saat reset, Anda bisa lihat. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Anda dapat mengikuti langkah-langkah @Halytskyi . PR: https://github.com/kubernetes/kubernetes/pull/71945 memperbaiki titik akhir sinkronisasi etcd ketika bergabung dengan node bidang kontrol, tidak dapat menghapus anggota etcd.

Hapus anggota etcd dari cluster etcd saat reset, Anda dapat melihat kubernetes / kubernetes # 74112.

Ini sepertinya masih bug di 1.13.4.

Kami masih perlu memperbarui peta konfigurasi kubeadm secara manual ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

Bukankah itu kasus yang memperbaikinya
kubernetes / kubernetes # 71945 akan menggunakan keanggotaan cluster etcd sebagai sumber kebenaran untuk anggota cluster? Jika tidak, apa tepatnya yang diperbaiki PR itu?

Menariknya, ini bekerja secara sporadis karena dalam rentang golang di atas peta, seperti ClusterStatus , tidak bersifat deterministik . Jadi, jika titik akhir pertama yang ditemukannya berasal dari titik akhir lama yang sudah tidak ada lagi, semuanya akan gagal. Jika menemukan titik akhir yang sehat, ClusterStatus akan diperbarui dari etcd Sync ...

Saya percaya akar penyebab ini adalah bug di etcd clientv3 di mana bug tersebut menyebabkan klien tidak mencoba lagi titik akhir lainnya jika yang pertama gagal https://github.com/etcd-io/etcd/issues/9949.

Silakan gunakan masalah berikut untuk melacak peningkatan reset

• https://github.com/kubernetes/kubeadm/issues/1312 Hapus node bidang kontrol dari ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Hapus anggota etcd dari cluster etcd (

@fabriziopandini Setidaknya ada satu masalah lain di sini yang tidak terkait dengan kubeadm reset .

Jika node gagal tanpa kesempatan untuk melakukan reset kubeadm (penghentian instans, kegagalan perangkat keras, dll.)
Cluster dibiarkan dalam keadaan di mana ClusterStatus.apiEndpoints masih mencantumkan node yang tidak lagi ada di cluster. Ini membutuhkan solusi untuk membaca, mengedit, dan memperbarui peta konfigurasi sebelum melakukan kubeadm join . Kubeadm mungkin memiliki 2 opsi:

1) Implementasikan klien etcd coba lagi sendiri jika dial gagal
2) Tunggu bug go-grpc diperbaiki dan kemudian perbaikannya dilakukan ke klien etcd

Masalah ini mungkin masalah yang bagus untuk digunakan untuk melacak salah satu opsi tersebut.

Jika node gagal tanpa kesempatan untuk melakukan reset kubeadm (penghentian instans, kegagalan perangkat keras, dll.)
Cluster dibiarkan dalam keadaan di mana ClusterStatus.apiEndpoints masih mencantumkan node yang tidak lagi ada di cluster. Ini membutuhkan solusi untuk membaca, mengedit, dan memperbarui peta konfigurasi sebelum melakukan kubeadm join .

itu benar, tanpa memanggil reset Anda harus memperbarui ClusterStatus secara manual.
kami tidak memiliki perintah yang melakukan itu. jika Anda merasa ini adalah fitur yang harus didukung oleh kubeadm, harap ajukan tiket terpisah.

Baru saja mengalaminya hari ini di 1.14.1

Instance yang menjalankan salah satu node master saya gagal sehingga tidak dapat dihapus dengan baik. Ketika node baru mencoba untuk masuk, gagal untuk bergabung karena kesalahan yang dijelaskan dalam tiket ini.

Saya harus menghapus anggota etcd secara manual melalui etcdctl, kemudian saya dapat bergabung di node baru. Saya juga secara manual menghapus node dari kubeadm-config ConfigMap, tetapi saya tidak yakin apakah itu diperlukan.

@Halytskyi Terima kasih, bagian etcdctl membantu saya .....

Mengalami hari ini di 1.15.5

Dalam kasus saya, saya bergabung dengan cluster tetapi dengan versi 1.16. kemudian hapus node ini kubectl delete node , turunkan ke 15.5.5 dan coba bergabung kembali (ip yang sama, nama host yang sama, versi berbeda) dan mendapatkan kesalahan tidak sehat etcd.

Dipecahkan oleh (berdasarkan jawaban @Halytskyi tetapi dengan etcdctl yang diperbarui):

• Hapus node dari configmap kubeadm-config

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• kubeadm reset -f di simpul bermasalah && iptables -t -f -X dan seterusnya.

• hapus anggota etcd (ini kuncinya):

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

`` cangkang
root @ k8s-nebula-m-115-2 : ~ / etcdctl / etcd-v3.4.3-linux-amd64 # ./etcdctl --endpoints https://127.0.0.1 : 2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key daftar anggota
289ed62da3c6e9e5, dimulai, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, salah
917e16b9e790c427, dimulai, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, salah
ad6b76d968b18085, dimulai, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, false

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

Dan kemudian bergabung kembali bekerja.

ini dapat terjadi jika kubeadm reset terputus dan tidak dapat menghapus node dari CM kubeadm.
dalam kasus seperti itu, Anda perlu menghapusnya secara manual dari CM kubeadm.

Jadi jika saya menghapus node dengan kubectl delete node foobar itu tidak
hapus dari anggota etcd? Tetapi jika saya melakukan kubeadm reset di node yang saya inginkan
menghapus, lalu apakah itu? 🙄

Pada Rabu, 30 Okt 2019, 13:27 Lubomir I. Ivanov, [email protected]
menulis:

ini bisa terjadi jika reset kubeadm terputus dan tidak dapat menghapus file
simpul dari CM kubeadm.
dalam kasus seperti itu, Anda perlu menghapusnya secara manual dari CM kubeadm.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43ZLO705P2HS4DFVREXG43VMVB54
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

"kubeadm reset" harus menghapusnya dari CM kubeadm, tetapi memanggil "kubectl delete node" juga diperlukan untuk menghapus objek Node API.

Dalam kasus saya, menghapus node dari de configmap tidak menghapusnya dari file
etcd cluster saya perlu secara manual etcdctl delete member .

Pada Kamis, 31 Okt 2019 pukul 16:28, Lubomir I. Ivanov [email protected]
menulis:

"kubeadm reset" harus menghapusnya dari CM kubeadm, tetapi memanggil "kubectl
delete node "juga diperlukan untuk menghapus objek Node API.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYGI4Y#issuecomment-548430963 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

kubeadm reset juga harus menghapus anggota etcd dari kluster etcd.
coba jalankan dengan eg --v = 5 dan lihat apa fungsinya.

Namun perlu diingat bahwa reset kubeadm adalah perintah upaya terbaik jadi jika gagal karena alasan tertentu itu mungkin hanya mencetak peringatan.

jadi kubectl delete node tidak menghapusnya dari etcd. Sebaliknya, berjalan di simpul kubeadm reset melakukannya.
Kedengarannya rusak bagi saya, saya pikir kubectl delete node harus menghapusnya dari bentuk etcd juga. Atau apakah saya melewatkan kasus penggunaan yang jelas?
mungkin bertanya apakah itu juga harus dihapus dari sana?
Pokoknya terima kasih atas klarifikasi @ neolit123 , saya hapus dulu dari control plane lalu lakukan reset, tebak sudah terlambat untuk menghapus dirinya sendiri dari etcd.

jadi ada tanggung jawab yang berbeda.
kubectl delete node, menghapus objek Node API - Anda harus melakukan ini ketika Anda benar-benar yakin bahwa Anda tidak lagi menginginkan node tersebut,
sebelum itu Anda harus memanggil reset kubeadm pada node tersebut. apa yang saya lakukan adalah membersihkan status pada disk dan juga menghapus anggota etcd (jika ini adalah node bidang kontrol dan jika Anda menggunakan opsi default di mana instance etcd berjalan per node bidang kontrol)

kubeadm reset me-reset node, tetapi tidak menghapus objek Node karena beberapa alasan:

• reset hanya menyetel ulang node dan Anda dapat bergabung kembali. nama Node tetap dicadangkan.
• node itu sendiri tidak memiliki cukup hak untuk menghapus objek Node itu. ini adalah tanggung jawab pemilik "admin.conf" (misalnya administrator).

kubeadm reset adalah perintah upaya terbaik

Mengenai ini: ketika kubeadm reset gagal diselesaikan karena alasan apa pun (termasuk kegagalan keras dari server yang mendasarinya sehingga reset kubeadm tidak pernah dijalankan sejak awal) apakah ada opsi untuk merekonsiliasi status secara manual di samping mengedit secara manual objek configmap kubeadm-config dan menghapus node?

jika node gagal keras dan Anda tidak dapat memanggil reset kubeadm di atasnya, itu memerlukan langkah manual. Anda harus:
1) hapus IP bidang kontrol dari CM ClusterStatus kubeadm-config
2) hapus anggota etcd menggunakan etcdctl
3) hapus objek Node menggunakan kubectl (jika Anda tidak ingin Node ada lagi)

1 dan 2 hanya berlaku untuk node bidang kontrol.

Apakah ada cara untuk mengotomatiskan kegagalan ini jika reset kubeadm tidak dapat dijalankan?

Masalah yang sama di 1.9. Terima kasih atas solusinya.