versi kubeadm : 1.10.2
Lingkungan :
Beberapa bulan yang lalu saya membuat cluster kubernetes 1.9.3 HA menggunakan kubeadm 1.9.3
, mengikuti dokumentasi 'resmi' https://kubernetes.io/docs/setup/independent/high-availability/ , menyiapkan etcd
HA cluster menghostingnya di node master menggunakan pod statis
Saya ingin mengupgrade cluster saya ke k8s 1.10.2
menggunakan kubeadm
; setelah memperbarui kubeadm
, ketika menjalankan kubeadm upgrade plan
, saya mendapat kesalahan berikut:
[root@shared-cob-01 tmp]# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/plan] computing upgrade possibilities
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.9.3
[upgrade/versions] kubeadm version: v1.10.2
[upgrade/versions] Latest stable version: v1.10.2
[upgrade/versions] FATAL: context deadline exceeded
Saya menyelidiki masalah dan menemukan 2 akar penyebab:
kubeadm
tidak mengidentifikasi etcd
cluster sebagai TLS diaktifkanPanduan menginstruksikan untuk menggunakan perintah berikut di pod statis etcd
- etcd --name <name> \
- --data-dir /var/lib/etcd \
- --listen-client-urls http://localhost:2379 \
- --advertise-client-urls http://localhost:2379 \
- --listen-peer-urls http://localhost:2380 \
- --initial-advertise-peer-urls http://localhost:2380 \
- --cert-file=/certs/server.pem \
- --key-file=/certs/server-key.pem \
- --client-cert-auth \
- --trusted-ca-file=/certs/ca.pem \
- --peer-cert-file=/certs/peer.pem \
- --peer-key-file=/certs/peer-key.pem \
- --peer-client-cert-auth \
- --peer-trusted-ca-file=/certs/ca.pem \
- --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
- --initial-cluster-token my-etcd-token \
- --initial-cluster-state new
kubeadm >= 1.10
cek (di sini: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) jika etcd
telah mengaktifkan TLS dengan memeriksa keberadaan flag berikut dalam perintah pod statis.
"--cert-file=",
"--key-file=",
"--trusted-ca-file=",
"--client-cert-auth=",
"--peer-cert-file=",
"--peer-key-file=",
"--peer-trusted-ca-file=",
"--peer-client-cert-auth=",
tetapi karena tanda --client-cert-auth
dan --peer-client-cert-auth
digunakan dalam instruksi tanpa parameter apa pun (menjadi boolean) kubeadm
tidak mengenali cluster etcd
untuk memiliki TLS diaktifkan.
PERBAIKAN PRIBADI:
Saya memperbarui perintah pod etcd
statis saya untuk menggunakan - --client-cert-auth=true
dan - --peer-client-cert-auth=true
PERBAIKAN UMUM:
Perbarui instruksi untuk menggunakan --client-cert-auth=true
dan --peer-client-cert-auth=true
dan rileks pemeriksaan kubeadm menggunakan "--peer-cert-file"
dan "--peer-key-file"
(tanpa persamaan)
kubeadm
tidak menggunakan sertifikat yang benarsetelah memperbaiki poin 1, masalah tetap ada karena kubeadm
tidak menggunakan sertifikat yang benar.
Dengan mengikuti panduan HA kubeadm, sebenarnya, sertifikat yang dibuat adalah ca.pem
ca-key.pem
peer.pem
peer-key.pem
client.pem
client-key.pem
tapi yang terbaru kubeadm
mengharapkan ca.crt
ca.key``peer.crt
peer.key``healthcheck-client.crt
healthcheck-client.key
sebagai gantinya.
Yhe kubeadm-config
MasterKonfigurasi kunci etcd.caFile
, etcd.certFile
dan etcd.keyFile
diabaikan.
PERBAIKAN PRIBADI:
Mengganti nama sertifikat .pem
menjadi .crt
dan setara .key
dan memperbarui konfigurasi pod statis etcd
untuk menggunakannya.
PERBAIKAN UMUM:
Gunakan nilai kubeadm-config
data.caFile
, data.certFile
dan data.keyFile
, simpulkan sertifikat yang benar dari definisi pod statis etcd (jalur pod + volume hostPath) dan / atau buat sertifikat klien sementara baru untuk digunakan selama peningkatan.
Rencana peningkatan seharusnya dijalankan dengan benar
buat cluster k8s ha menggunakan kubeadm 1.9.3
mengikuti https://kubernetes.io/docs/setup/independent/high-availability/ dan coba perbarui ke k8s >= 1.10
menggunakan kubeadm
masalah ini tampaknya telah diperbaiki dalam kubeadm 1.10.3
, meskipun tidak secara otomatis memperbarui pod statis etcd
karena mengenalinya sebagai 'eksternal'
Saya menggunakan kubeadm 1.10.3
dan memiliki masalah yang sama. Cluster saya adalah 1.10.2 dengan dlld aman eksternal
@brokenmass Apakah nilai untuk perbaikan pribadi Anda untuk penyebab kedua yang Anda perhatikan terlihat seperti ini:
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/etcd/healthcheck-client.crt
keyFile: /etc/kubernetes/pki/etcd/healthcheck-client.key
@detiber dapatkah Anda membantu?
@Bayu_joo
dalam kasus saya, nilainya terlihat seperti:
caFile: /etc/kubernetes/pki/etcd/ca.pem
certFile: /etc/kubernetes/pki/etcd/client.pem
keyFile: /etc/kubernetes/pki/etcd/client-key.pem
dan 1.10.3 bekerja dengan benar
@brokenmass Jadi dengan kubeadm 1.10.3 semuanya bekerja tanpa perlu perbaikan pribadi Anda. Dalam hal ini saya sedikit bingung. Saya memiliki kubeadm 1.10.3 tetapi pesan kesalahan yang sama yang Anda sebutkan dalam laporan bug ini. Saya akan memeriksa ulang konfigurasi saya, mungkin saya membuat beberapa kesalahan di tempat lain
tambahkan di sini (atau bergabunglah dengan kubernetes slack dan kirimi saya pesan langsung) kubeadm-config Anda, etcd static pods yml dan hasil lengkap kubeadm upgrade plan
Maafkan saya, saya baru saja melihat ini. @chuckha melakukan pekerjaan asli untuk dokumen HA etcd static-pod, saya akan bekerja dengannya selama beberapa hari ke depan untuk melihat apakah kami dapat membantu meluruskan peningkatan HA.
@etiber terima kasih. rencana peningkatan akhirnya berhasil. tetapi saya menghadapi beberapa masalah kondisi balapan saat mencoba memutakhirkan kluster. kadang berhasil kadang saya memiliki kesalahan yang sama dengan kubernetes / kubeadm / issues / 850 . kubeadm mengalami kondisi balapan saat mencoba memulai ulang pod pada satu node.
Saya mengalami beberapa kendala saat melakukan tes env setup untuk hari ini dan saya kehabisan waktu sebelum akhir pekan saya dimulai. Saya akan melanjutkannya awal minggu depan.
/ assign @chuckha @detiber
@chuckha @detiber @stealthybox ada pembaruan tentang ini?
Jadi 1.9-> 1.10 peningkatan HA bukanlah jalur yang didukung atau diperiksa.
Kami sedang dalam proses memperbarui pemeliharaan dokumen kami untuk 1,11-> 1,12 yang kami rencanakan untuk dipertahankan ke depannya.