Lihat juga https://github.com/cookeem/kubeadm-ha - ini sepertinya mencakup apa yang ingin saya capai di sini.

@mbert kami mulai menerapkan fitur HA dan memotong kayu pada tumpukan dependensi yang mendasarinya sekarang di v1.9, tetapi ini adalah siklus pendek untuk tugas besar, jadi pekerjaan akan dilanjutkan di v1.10 seperti yang Anda tunjukkan.

Untuk v1.9, kami akan mendokumentasikan apa yang Anda jelaskan di sini di dokumen resmi; bagaimana mencapai HA dengan deps eksternal seperti menyiapkan LB

Luar biasa. Saya sedang menggali semua ini sekarang. Saat ini saya terjebak di bootstrap master 2 dan 3, khususnya cara mengkonfigurasi kubelet dan apiserver (berapa banyak yang dapat saya gunakan kembali dari master 1?) Dan etcd (Saya berpikir untuk menggunakan bootstrap dll pada mesin terpisah untuk penemuan). Panduan dari dokumen agak singkat dalam hal ini.

@mbert Saya telah mengikuti komentar Anda di sini dan saya hanya ingin memberi tahu Anda bahwa saya mengikuti panduan di dokumen dan dapat mempertahankan cluster HA k8s yang berfungsi menggunakan kubeadm (v1.8.x).

Jika Anda mengikuti pengaturan ini dan Anda perlu bootstrap master 2 dan 3, Anda dapat menggunakan kembali hampir semuanya dari master pertama. Anda kemudian perlu memperbaiki file konfigurasi berikut pada master 2 dan 3 untuk mencerminkan host saat ini: /etc/kubernetes/manifests/kube-apiserver.yaml, /etc/kubernetes/kubelet.conf, / etc / kubernetes / admin. conf, dan /etc/kubernetes/controller-manager.conf

Mengenai etcd, jika Anda mengikuti dokumen panduan ini, Anda harus mendirikan kluster 3-node etcd eksternal yang membentang di seluruh node master 3 k8s.

Ada juga satu item 'gotcha' yang BELUM tercakup dalam dokumen panduan.
Anda dapat melihat masalah ini untuk detailnya: https://github.com/cookeem/kubeadm-ha/issues/6

Saya juga mengajukan beberapa pertanyaan terkait kubeadm HA dari posting ini: https://github.com/cookeem/kubeadm-ha/issues/7

Saya sangat berharap itu dapat memberi saya beberapa pemikiran tentang ini.

Terima kasih sebelumnya atas waktu Anda.

Ini bagus - pasti membutuhkan ini karena saya yakin 99% pengguna kubeadm memiliki paranoia yang mengganggu di belakang kepala mereka tentang ha dari master mereka.

@ kcao3 terima kasih. Saya akan memeriksa semua ini pada hari Senin mendatang. Jadi saya mengerti bahwa tidak masalah menggunakan sertifikat yang sama pada ketiga master?

Jika ya, saya berasumsi bahwa selanjutnya saya akan mencoba menampilkan kubelet dan apiserver pada master 2 dan 3 menggunakan konfigurasi dari master 1 (tentu saja dengan IP dan nama host yang dimodifikasi) dan kemudian bootstrap cluster etcd dengan meletakkan a memodifikasi etcd.yaml menjadi / etc / kubernetes / manifests.

Hari ini saya mengalami masalah karena menjalankan etcd pada master 1 sudah memiliki informasi cluster di direktori datanya yang harus saya hapus terlebih dahulu, tetapi saya masih mengalami masalah. Kurasa tidur malam yang nyenyak akan membantu.

Setelah saya menjalankan ini, saya akan mendokumentasikan keseluruhan proses dan menerbitkannya.

@ srflaxu40 ya, dan khususnya jika Anda memiliki aplikasi yang secara tidak langsung memerlukan apiserver pada saat runtime (aplikasi warisan dan penemuan layanan dalam kasus saya) Anda tidak dapat kehilangan satu-satunya master kapan saja.

Ubah single-instance _etcd_ menjadi cluster

Saya bisa mengganti instance _etcd_ tunggal oleh cluster di cluster K8s baru. Langkah-langkahnya kira-kira sebagai berikut:

1. Siapkan server _etcd_ terpisah. Instance _etcd_ ini hanya diperlukan untuk melakukan bootstrap pada cluster. Buat URL penemuan untuk 3 node di dalamnya (lihat https://coreos.com/etcd/docs/latest/op-guide/clustering.html#etcd-discovery).
2. Salin _ / etc / kubernetes_ dari master 1 ke master 2 dan 3. Gantikan nama host dan IP di _ / etc / kubernetes /*.*_ dan _ / etc / kubernetes / manifests /*.*_
3. Buat penggantian ke _ / etc / kubernetes / manifests / etcd.yaml_ untuk ketiga master: setel semua URL pengumuman ke IP utama host masing-masing, semua dengarkan URL ke 0.0.0.0, tambahkan URL penemuan dari langkah 1. Saya menggunakan melekat Jinja2 file template etcd.yaml.j2.txt bersama-sama dengan _ansible._
4. Salin penggantian _etcd.yaml_ ke _ / etc / kubernetes / manifests_ pada ketiga node master.
5. Sekarang segalanya menjadi kritis waktu. Tunggu hingga proses _etcd_ lokal berhenti, lalu pindahkan _ / var / lib / etcd / member / wal_ ke tempat lain sebelum proses baru muncul (jika tidak maka akan mengabaikan URL penemuan).
6. Saat _etcd_ baru muncul, sekarang akan menunggu dua instance yang tersisa untuk bergabung. Karenanya, luncurkan _kubelet_ dengan cepat di dua node master lainnya.
7. Ikuti log penampung _etcd_ pada master pertama untuk melihat apakah ada yang benar-benar tidak beres. Jika semuanya baik-baik saja, maka setelah beberapa menit cluster akan beroperasi kembali.

Langkah 5 agak canggung, dan saya telah menemukan bahwa jika saya melewatkan waktu yang tepat di sini atau membutuhkan terlalu banyak waktu untuk membuat dua master lainnya bergabung (langkah 6) klaster saya masuk ke dalam keadaan yang membuatnya sulit
memulihkan. Ketika ini terjadi, solusi paling sederhana yang saya temukan adalah mematikan _kubelet_ pada master 2 dan 3, menjalankan _kubeadm reset_ pada semua master dan minion, menghapus direktori _ / var / lib / etcd_ pada semua master dan menyiapkan cluster baru menggunakan _kubeadm init_.

Sementara ini berhasil, saya akan tertarik pada kemungkinan peningkatan: Apakah ada alternatif, pendekatan yang lebih elegan dan kuat untuk ini (asalkan saya masih ingin mengikuti pendekatan menjalankan _etcd_ di kontainer pada master)?

Komentar ini bertujuan untuk mengumpulkan umpan balik dan petunjuk pada tahap awal. Saya akan memposting pembaruan pada langkah selanjutnya dengan cara yang sama sebelum akhirnya mendokumentasikan ini sebagai panduan yang dapat diikuti.

@ mbert Mengapa Anda tidak menggunakan cluster ETCD independen daripada membuat di k8s?

@KeTTT Terima kasih atas tanggapan Anda. Saya sedang memikirkan ini di sini:

1. Tidak menggunakan data apa pun.
2. Tetap sedekat mungkin dengan penyiapan kubeadm.
3. Apakah itu diawasi oleh K8 dan terintegrasi dalam pemantauan apa pun yang saya siapkan untuk sistem saya.
4. Jaga agar jumlah layanan yang berjalan di OS tetap rendah.
5. Itu tidak akan membuat segalanya lebih mudah karena saya masih harus berurusan dengan (4) di atas.

Jika keuntungan cluster etcd independen melebihi daftar di atas, saya akan senang untuk diyakinkan sebaliknya.

@mbert Pastikan Anda menyinkronkan dengan @jamiehannaford dalam upaya ini, dia juga mengerjakan ini / berkomitmen untuk menjadikan dokumen ini sesuatu di v1.9

@mbert apakah Anda bersedia untuk bergabung dengan pertemuan SIG kita hari ini 9PT atau PR implementasi kubeadm besok 9PT? Saya ingin membicarakan hal ini dengan Anda melalui telepon: +1:

@luxas sebenarnya adalah @jamiehannaford yang meminta saya untuk membuka masalah ini. Setelah semuanya berjalan dan didokumentasikan, saya berharap mendapat banyak umpan balik darinya.
9PT, itu dalam satu jam, kan? Itu akan baik-baik saja. Beri tahu saya cara terhubung dengan Anda.

Berikut panduan di sana-sini saya berhasil melakukannya di sini adalah langkah terakhir saya

/ cc @craigtracey

@bert

Dibuat - tidak dikonversi - 3 cluster master-node menggunakan kubeadm dengan 3 cluster node etcd di- deploy di kubernetes

Inilah yang perlu saya lakukan:

1. Buat 3 cluster node master menggunakan kubeadm di server barebone
2. Deploy cluster etcd pada 3 node master menggunakan kubeadm
3. Gunakan cidr / 27 jaringan pod non-default

Masalah:

1. Menggunakan cidr pod-network non-default tidak mungkin disiapkan menggunakan _kubeadm init_
2. Tidak ada dokumentasi tentang pembuatan cluster multi-master pada barebone. Dokumen lain tidak sedetail mungkin

Cara saya melakukannya menggunakan langkah-langkah fase kubeadm alpha, daftar singkatnya sebagai berikut:

di semua node master:

1. Mulai buruh pelabuhan - bukan kubelet

di masternode1:

1. Buat sertifikat CA
2. Buat sertifikat apiserver dengan _-- apiserver-advertise-address_, _-- service-cidr_, _-- parameter apiserver-cert-extra-sans_ yang digunakan. Di sini, hanya _ --apiserver-cert-extra-sans _ yang wajib
3. Buat sertifikat lainnya yang diperlukan
4. Buat kubeconfig dan konfigurasi controlplane
5. Edit file yaml yang baru dibuat di direktori / etc / kubernetes / manifest untuk menambahkan opsi tambahan yang Anda butuhkan.
   Bagi saya, di sinilah saya menetapkan CIDR jaringan pod non-default / 27 di kube-control-manager.yaml. Selain itu, hapus NodeRestriction dari --admission-control
6. Salin file yaml yang telah disiapkan sebelumnya untuk cluster etd di direktori / etc / kubernetes / manifest
7. Salin / etc / kubernetes direktori ke node master lainnya dan edit semua file yang diperlukan untuk mengkonfigurasinya untuk masternode2 dan masternode3.
8. Setelah semua file dikonfigurasi ulang, jalankan kubelet ON ALL 3 MASTER NODES.
9. Setelah semua node naik, taint semua master-node
10. Bootstrap semua token
11. Buat token untuk bergabung dengan node pekerja
12. Edit masterConfig.yaml yang dibuat sebelumnya dan perbarui parameter token
13. Unggah masterConfig ke kubernetes
14. Pasang addons
15. Hasilkan --discovery-token-ca-cert-hash dan tambahkan node pekerja

Ini adalah daftar singkat dari apa yang saya lakukan dan dapat diotomatiskan dan direproduksi dalam 5 menit. Juga, bagi saya, bonus terbesar adalah saya dapat menetapkan CIDR jaringan pod non-standar karena saya memiliki batasan tidak dapat menyisihkan rentang alamat IP kelas B.

Jika Anda tertarik dengan versi yang lebih mendetail, beri tahu saya dan saya akan mencoba membuat beberapa dokumen tentang cara melakukannya.

@dimitrijezivkovic terima kasih atas komentar Anda. Saya pikir akan masuk akal untuk mengumpulkan semua informasi yang relevan sehingga satu dokumentasi keluar.

Saya berencana untuk menyiapkan dokumen google docs dan mulai mendokumentasikan apa yang saya lakukan (yang sangat sederhana). Saya kemudian akan mengundang orang lain untuk bergabung dan menulis ekstensi, koreksi, komentar?

Saya sekarang telah "mendokumentasikan" penyiapan yang sangat sederhana dalam bentuk proyek kecil yang memungkinkan: https://github.com/mbert/kubeadm2ha

Ini tentu saja masih dalam proses, tetapi sudah memungkinkan untuk mengatur cluster multi-master tanpa bel dan peluit. Saya telah berusaha membuatnya sesederhana mungkin sehingga dengan membaca seseorang dapat mengetahui dengan mudah apa yang perlu dilakukan dalam urutan yang mana.

Besok saya akan mulai menulis ini sebagai resep memasak sederhana di dokumen google docs dan mengundang orang lain untuk berkolaborasi.

Hanya untuk menyebutnya secara eksplisit, ada banyak masalah ortogonal yang digabungkan bersama dalam percakapan / saran di atas. Mungkin berguna untuk memecahnya secara terpisah, dan mungkin memprioritaskan beberapa di atas yang lain:

• ketahanan data etcd (multi etcd. Membutuhkan 2+ node etcd)
• ketersediaan data etcd (multi etcd + redundancy. Membutuhkan 3+ node etcd)
• ketersediaan apiserver (multi apiserver. Membutuhkan loadbalancer / VIP atau (setidaknya) DNS dengan beberapa rekam A)
• ketersediaan cm / penjadwal (multi cm / penjadwal. Memerlukan 2+ node master, dan replika = 2 + pada tugas ini)
• reboot-all-the-masters pemulihan (tantangan untuk dihosting sendiri - memerlukan beberapa bentuk pod persisten untuk bidang kontrol)
• kubeadm upgrade dukungan untuk multi-apiserver / cm-scheduler (bervariasi tergantung pada self-host vs non-self-hosted)

Imo minimal yang kita butuhkan adalah daya tahan dlld (atau mungkin ketersediaan), dan sisanya bisa menunggu. Itu menghilangkan faktor "ketakutan", sementara masih membutuhkan beberapa intervensi manual untuk pulih dari kegagalan utama utama (yaitu: semacam penyiapan aktif / pasif).

Saya pikir detail sisanya sangat bergantung pada hosting mandiri vs "warisan", jadi saya rasa ini akan sangat menyederhanakan jika kita baru saja memutuskan sekarang untuk menganggap hosting mandiri (atau tidak?) - atau kami jelas-jelas membuat solusi / dokumen ke dalam dua wadah itu sehingga kami tidak membingungkan pembaca dengan memotong dan mengubah.

Selain: Salah satu tantangan di sini adalah bahwa hampir semua yang harus dilakukan dengan perubahan instal + peningkatan jika Anda mengasumsikan pengaturan + HA yang dihosting sendiri (sebagian besar _simplify_ everything karena Anda dapat menggunakan upgrade bergulir, dan mesin k8s built-in). Saya merasa bahwa dengan terus-menerus menunda penyiapan ini, kami benar-benar telah membuatnya _harder_ bagi diri kami sendiri untuk mencapai tujuan akhirnya, dan saya khawatir bahwa kami hanya akan terus mendorong penyiapan "sebenarnya" lebih jauh sementara kami berupaya menyempurnakan single- yang tidak relevan peningkatan master :( Saya lebih suka kita membahas pengaturan HA _first_, dan kemudian bekerja _backwards_ untuk mencoba menghasilkan perkiraan host tunggal jika diperlukan (mungkin dengan mengemas pekerjaan duplikat sementara ke host tunggal), daripada mencoba menyelesaikan host tunggal dan _then_ berpikir bahwa pengalaman akan membantu kami dengan multi-host.

@mbert Saya telah mencapai proposal HA dengan membuat sertifikat secara manual untuk setiap node, dan tanpa menghapus NodeRestriction , saya menggunakan haproxy+keepalived sebagai loadbalancer sekarang, mungkin lvs+keepalived akan lebih baik, Saya akan mendokumentasikan detailnya di akhir pekan ini, berharap dapat berbagi dengan Anda.

FYI semuanya, @mbert telah mulai mengerjakan panduan WIP yang bagus untuk kubeadm HA secara manual yang akan kami tambahkan ke dokumen kubeadm v1.9 pada akhirnya: https://docs.google.com/document/d/1rEMFuHo3rBJfFapKBInjCqm2d7xGkXzh0FpFO0cRuqg/edit

Silakan lihat di dokumen semuanya, dan berikan komentar Anda. Kami akan segera mengubahnya menjadi penurunan harga dan mengirimkannya sebagai PR ke kubernetes / situs web.

Terima kasih @mbert dan semua orang lain yang aktif di utas, ini akan menjadi kolaborasi yang hebat!

@mbert / @luxas : dokumen itu tidak mengizinkan komentar (setidaknya bagi saya: menangis :)

Selesai, saya punya setting yang salah di dokumen.

@mbert Saya punya pertanyaan untuk Anda. Mengikuti pendekatan Anda, dengan asumsi saya memiliki cluster HA k8s yang berfungsi. Apakah Anda tahu cara menambahkan master k8 baru ke cluster saya yang sudah ada? Masalah yang saya hadapi sekarang adalah sertifikat yang dibuat berdasarkan jumlah TETAP host master k8 pada saat cluster di-bootstrap. Ini sekarang mencegah master baru untuk bergabung dengan cluster. Dari log kubelet master baru, Anda akan melihat sesuatu seperti ini: "... x509: sertifikat berlaku untuk 192.168.1.x, 192.168.1.y, 192.168.1.z bukan 192.168.1.n. " (di mana .x, .y, .z adalah alamat IP master saat ini, dan .n adalah alamat master baru). Apakah Anda tahu cara mengatasi masalah ini? Apakah node master harus menggunakan sertifikat yang sama dalam kasus ini?

@ kcao3 Saya tidak begitu paham dengan aspek khusus ini. Mungkin @jamiehannaford bisa memberi tahu lebih banyak tentang ini?

@ kcao3 Setiap panduan HA dalam ulasan , jadi periksalah jika Anda punya waktu.

Saya baru saja memasukkan komitmen baru ke https://github.com/mbert/kubeadm2ha

• jaringan flanel sekarang didukung (dan default)
• ada instalasi dasar untuk dasbor (jaringan NodePort, tidak aman, yaitu tidak ada SSL) sebagai pedoman terpisah
• pembersihan kode

@mbert Saya baru saja membaca panduan HA dari @jamiehannaford : https://github.com/jamiehannaford/kubernetes.github.io/blob/3663090ea9b9a29a00c79dd2916e11737ccf1802/docs/setup/independent/high-availability.md. Apakah mungkin pada setiap node master, kita dapat memiliki kubeadm untuk menghasilkan dan menandatangani sertifikat terpisah menggunakan CA.crt dan CA.key yang sama?

Jadi satu-satunya hal yang perlu disalin dari master utama ke master sekunder adalah CA.crt dan CA.key. Dengan pendekatan ini, pada setiap master (termasuk primer dan sekunder), kita akan menjalankan 'kubeadm init' menggunakan file konfigurasi kubeadm yang dihasilkan berdasarkan template seperti berikut:

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
kubernetesVersion: v{{ KUBERNETES_VERSION }}
networking:
  podSubnet: {{ POD_NETWORK_CIDR }}
api:
  advertiseAddress: {{ MASTER_VIP }}
apiServerCertSANs:
- {{ MASTER_VIP }}
etcd:
  endpoints:
{% for host in groups['masters'] %}
  - http://{{ hostvars[host]['ansible_default_ipv4']['address'] }}:2379
{% endfor %}

Jika pendekatan ini berhasil, ini akan memungkinkan admin k8s untuk menambahkan master baru ke cluster multi-master yang ada di masa mendatang.

Ada pemikiran?

@ kcao3 Itulah yang saya coba lakukan. Saya menemukan bahwa saya juga perlu membuat kunci sertifikat CA + proxy yang berbeda.
Tetapi sekarang ketika saya menjalankan kubeadm init di master saya, semua komponen muncul dengan benar tetapi kube-proxy masih gagal karena masalah otentikasi, meskipun front-proxy-client.crt sekarang ditandatangani oleh CA yang sama di semua node.

@discordianfish Saya juga mengalami masalah auth tetapi saat menerapkan Flanel. Bertanya-tanya apakah itu terkait dengan apa yang Anda lihat.

Sementara itu, saya menemukan bahwa 'proxy CA' (frontend-proxy- *) tidak terkait dengan kube-proxy. Masih mencoba mencari tahu apa yang sedang terjadi, sepertinya tidak ada peran system:node-proxier tetapi saya tidak tahu apa yang seharusnya membuatnya.

Karena hal-hal proxy frontend adalah ikan haring merah, saya mulai dari awal yang bersih sekarang. Tetapi akan lebih bagus jika seseorang dapat mengonfirmasi bahwa itu harus berfungsi untuk membuat kredensial CA dan hanya menjalankan init di semua master? Diberikan titik akhir advertiseAddress, SAN dan etcd yang tepat?
Karena saya paling khawatir bahwa kubeadm entah bagaimana masih menghasilkan rahasia lokal yang tidak diketahui oleh master lain.

Ketika master saya muncul, kube-proxy berfungsi terlebih dahulu tetapi kube-proxy pada master terakhir gagal. Saat saya membuat ulang pod, semuanya gagal. Jadi ketika menjalankan kubeadm init lagi, etcd yang sama beberapa kali dari host yang berbeda, entah bagaimana itu merusak otentikasi.

Akun layanan terlihat benar dan memiliki rahasia:

$ kubectl -n kube-system get ds kube-proxy -o yaml|grep serviceAccount
      serviceAccount: kube-proxy
      serviceAccountName: kube-proxy

$ kubectl -n kube-system get sa kube-proxy -o yaml|grep -A1 secrets
secrets:
- name: kube-proxy-token-5ll9k

$ kubectl -n kube-system get secret kube-proxy-token-5ll9k
NAME                     TYPE                                  DATA      AGE
kube-proxy-token-5ll9k   kubernetes.io/service-account-token   3         16m

Akun layanan ini juga terikat dengan peran:

$ kubectl get clusterrolebindings kubeadm:node-proxier -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: 2017-12-07T12:52:54Z
  name: kubeadm:node-proxier
  resourceVersion: "181"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kubeadm%3Anode-proxier
  uid: 8a9638df-db4d-11e7-8d7e-0e580b140468
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-proxier
subjects:
- kind: ServiceAccount
  name: kube-proxy
  namespace: kube-system

Dan peran tersebut ada dan terlihat bagus:

$ kubectl get clusterrole system:node-proxier -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2017-12-07T12:52:51Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:node-proxier
  resourceVersion: "63"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Anode-proxier
  uid: 88dfc662-db4d-11e7-8d7e-0e580b140468
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - services
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update

Jadi tidak yakin apa yang akan terjadi. Dari bagaimana saya memahami semuanya, ini seharusnya bekerja seperti ini tetapi apiserver terus mencatat: E1207 13:18:20.697707 1 authentication.go:64] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, crypto/rsa: verification error]]

Oke, jadi sepertinya token hanya diterima oleh satu contoh apiserver saya, mungkin pada master tempat kubeadm init terakhir dijalankan. Saya pikir token akun layanan disimpan di etcd?

Misteri terpecahkan, terima kasih untuk gintas dan foxie di # kubernetes-users: Kita juga perlu membuat kunci sa terlebih dahulu dan mendistribusikannya bersama dengan CA.

Saya mengikuti panduan HA @jamiehannaford cukup dekat dan akhirnya mencapai cluster HA yang berfungsi (diatur dalam pengaturan Vagrant dengan penyeimbang beban HAProxy yang menghadap ke tiga node master), tetapi saya menemui beberapa rintangan di sepanjang jalan dan berpikir saya akan bagikan di sini karena mungkin relevan terlepas dari pendekatannya:

• Versi etcd harus kompatibel dengan versi Kubernetes yang Anda jalankan. Dari apa yang saya dapat mengumpulkan panduan target k8s 1.9 dan karena itu menggunakan etcd v3.1.10 . Untuk instalasi k8s 1.8 (yang saya targetkan), Anda harus menggunakan v3.0.17 (menggunakan v3.1.17 menyebabkan kubeadm tersedak, gagal mengekstrak versi etcd ).

• Saya harus menjalankan etcd menggunakan systemd, karena menjalankannya sebagai pod statis di bawah /etc/kubernetes/manifests akan menyebabkan pemeriksaan preflight kubeadm gagal (ia mengharapkan direktori itu kosong).

• Sebelum menjalankan kubeadm init di master1 dan master2, Anda harus menunggu master0 menghasilkan sertifikat dan, selain /etc/kubernetes/pki/ca.{crt,key} , salin file /etc/kubernetes/pki/sa.key dan /etc/kubernetes/pki/sa.pub ke master1 dan master2 (seperti yang diisyaratkan oleh @discordianfish). Jika tidak, master1 dan master2 akan menghasilkan sertifikat penandatanganan token akun layanan mereka sendiri, yang dalam kasus saya menyebabkan kube-proxy pada host tersebut gagal mengautentikasi terhadap apiserver.

  Ada juga file front-proxy-ca.{crt,key} dan front-proxy-client.{crt,key} yang tidak saya salin. Saya tidak yakin apakah mereka seharusnya telah disalin dari master0 juga, tetapi hal - hal

• Panduan instalasi kubeadm "biasa" mendorong Anda untuk mengkonfigurasi Docker untuk menggunakan driver cgroup systemd. Bagi saya, itu juga mengharuskan saya untuk mengirimkan --cgroup-driver=systemd ke kubelet melalui KUBELET_EXTRA_ARGS .

@petergardfjall Ha lucu melihat bagaimana Anda mengalami masalah yang persis sama. Jadi ya mulai kemarin cluster multi-HA saya juga berfungsi. Saya menemukan https://github.com/kubernetes/kubeadm/issues/590 , apakah Anda menemukan solusi yang bagus untuk itu?
Tidak harus menggunakan versi etcd khusus. Saya pikir saya hanya menggunakan default di coreos 'stable etcd-wrapper.
Mengenai hal front-proxy .. Terus terang saya tidak tahu apa itu.

@ Discordianfish : Saya tidak mengalami # 590. Saya menggunakan file konfigurasi kubeadm dengan

api:
  advertiseAddress: <apiserver-loadbalancer-ip>

dan tampaknya telah diambil oleh peta config kube-proxy .

> kubectl get cm -n kube-system kube-proxy -o yaml
apiVersion: v1
data:
  kubeconfig.conf: |
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://<apiserver-loadbalancer-ip>:6443
      name: default

Ah baiklah. Benar, ini berfungsi dengan ip penyeimbang beban tetapi Anda tidak mendapatkan IP yang stabil saat berjalan di AWS dan menggunakan ELB, jadi perlu menggunakan nama.

@discordianfish Saya mengerti, itu mungkin benar-benar menjadi masalah karena saya berencana menjalankannya di AWS nanti. Bagaimana Anda menyiasatinya?

@jamiehannaford dalam panduan HA Anda membuat referensi untuk menggunakan loadbalancer cloud-native. Apakah Anda bereksperimen dengan itu? Apakah Anda berhasil mengatasi # 590?

Tidak, belum menemukan solusi. Saat ini hanya ada catatan di dokumen saya untuk mengedit peta konfigurasi ini secara manual.

Dan saya baru saja menembak saya dengan ini: kubeadm init pada master baru akan menimpa configmap dan https://github.com/kubernetes/kubernetes/issues/57109 membuatnya semakin sulit untuk mewujudkannya.

Jadi dari apa yang dapat saya katakan tidak ada cara untuk menggunakan kubeadm saat ini dalam pengaturan multi-master, tanpa kembali ke mengeksekusi alpha phases secara manual.

Panduan HA @jamiehannaford secara umum melewatkan hal ini. Sebuah cluster yang dibuat seperti ini akan memiliki IP dari master tunggal yang di-hardcode dan yang rusak ini akan hilang.

Halo

Saya baru saja bereksperimen sedikit dengan ini dan saya pikir saya memiliki pengaturan yang berfungsi sekarang.
Jadi inilah yang saya lakukan:

Percobaan dilakukan pada DigtialOcean dengan tetesan 4x 20 $ (3 master + 1 pekerja)

Pertama saya membuat 3 droplet (CoreOS stable):

master1: 188.166.76.108
master2: 188.166.29.53
master3: 188.166.76.133

Saya kemudian hujan skrip berikut di setiap node untuk mengonfigurasi bagian yang diperlukan untuk menggunakan kubeadm dengan CoreOS:

#!/bin/bash
set -o nounset -o errexit

RELEASE="$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)"
CNI_VERSION="v0.6.0"

mkdir -p /opt/bin
cd /opt/bin
curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
chmod +x {kubeadm,kubelet,kubectl}

mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz

BRANCH="release-$(cut -f1-2 -d .<<< "${RELEASE##v}")"
cd "/etc/systemd/system/"
curl -L "https://raw.githubusercontent.com/kubernetes/kubernetes/${BRANCH}/build/debs/kubelet.service" | sed 's:/usr/bin:/opt/bin:g' > kubelet.service
mkdir -p "/etc/systemd/system/kubelet.service.d"
cd "/etc/systemd/system/kubelet.service.d"
curl -L "https://raw.githubusercontent.com/kubernetes/kubernetes/${BRANCH}/build/debs/10-kubeadm.conf" | sed 's:/usr/bin:/opt/bin:g' > 10-kubeadm.conf

Buat master awal:

core@master-01 ~ $ sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-cert-extra-sans="127.0.0.1,188.166.76.108,188.166.29.53,188.166.76.133"
[...]
  kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
[...]
core@master-01 ~ $ sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml
core@master-01 ~ $ sudo systemctl enable kubelet docker

Selanjutnya kita perlu membuat cluster etcd, jadi ubah manifest etcd sehingga etcd mendengarkan peer di semua antarmuka ( PERINGATAN : Ini tidak aman, dalam produksi Anda setidaknya harus menggunakan TLS untuk otentikasi / komunikasi peer)

core@master-01 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# add --listen-peer-urls=http://0.0.0.0:2380 as a command arg
core@master-01 ~ $ sudo systemctl restart kubelet # for some reason, kubelet does not pick up the change

Ubah peer-url anggota etcd default ke ipv4 ip publik:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member list
8e9e05c52164694d, started, default, http://localhost:2380, http://127.0.0.1:2379

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member update 8e9e05c52164694d --peer-urls="http://188.166.76.108:2380"

Sekarang salin semua file kubernetes (manifests / pki) ke node master lainnya:

$ eval $(ssh-agent)
$ ssh-add <path to ssh key>
$ ssh -A [email protected] # master-02
core@master-02 ~ $ sudo -E rsync -aP --rsync-path="sudo rsync" [email protected]:/etc/kubernetes/ /etc/kubernetes
$ ssh -A [email protected] # master-03
core@master-03 ~ $ sudo -E rsync -aP --rsync-path="sudo rsync" [email protected]:/etc/kubernetes/ /etc/kubernetes

Tambahkan master-02 ke cluster etcd:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member add member-02 --peer-urls="http://188.166.29.53:2380"
Member  b52af82cbbc8f30 added to cluster cdf818194e3a8c32

ETCD_NAME="member-02"
ETCD_INITIAL_CLUSTER="member-02=http://188.166.29.53:2380,default=http://188.166.76.108:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

$ ssh [email protected] # master-02
core@master-02 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# Add the following as args:
--name=member-02
--initial-cluster=member-02=http://188.166.29.53:2380,default=http://188.166.76.108:2380
--initial-cluster-state=existing
core@master-02 ~ $ sudo systemctl restart kubelet

Tambahkan master-03 ke cluster etcd:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member add master-03 --peer-urls="http://188.166.76.133:2380"
Member 874cba873a1f1e81 added to cluster cdf818194e3a8c32

ETCD_NAME="master-03"
ETCD_INITIAL_CLUSTER="member-02=http://188.166.29.53:2380,master-03=http://188.166.76.133:2380,default=http://188.166.76.108:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

$ ssh [email protected] # master-03
core@master-03 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# Add the following as args:
--name=master-03
--initial-cluster=member-02=http://188.166.29.53:2380,master-03=http://188.166.76.133:2380,default=http://188.166.76.108:2380
--initial-cluster-state=existing
core@master-03 ~ $ sudo systemctl start kubelet

Jadi sekarang kita harus memiliki cluster etcd 3-node.

Sekarang mari master-02 dan master-03 bergabung dengan cluster k8s:

$ ssh [email protected] # master-02
core@master-02 ~ $ sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf
core@master-02 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
$ ssh [email protected] # master-03
core@master-03 ~ $ sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf
core@master-03 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a

Tandai mereka sebagai master:

core@master-01 ~ $ sudo kubeadm alpha phase mark-master --node-name master-02
core@master-01 ~ $ sudo kubeadm alpha phase mark-master --node-name master-03

Ubah kubelet, kube-scheduler dan kube-controller-manager untuk menggunakan apiserver lokal dan bukan apiserver master-01:

core@master-01 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}
core@master-02 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}
core@master-03 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}

Ubah file yaml kube-apiserver untuk mengiklankan ip yang benar dan ip pemeriksaan kesehatan:

core@master-02 ~ $ sudo sed 's/188.166.76.108/188.166.29.53/g' -i /etc/kubernetes/manifests/kube-apiserver.yaml
core@master-03 ~ $ sudo sed 's/188.166.76.108/188.166.76.133/g' -i /etc/kubernetes/manifests/kube-apiserver.yaml

Aktifkan kubelet, buruh pelabuhan dan reboot:

core@master-01 ~ $ sudo systemctl enable kubelet docker; sudo reboot
core@master-02 ~ $ sudo systemctl enable kubelet docker; sudo reboot
core@master-03 ~ $ sudo systemctl enable kubelet docker; sudo reboot

Ubah kube-proxy untuk menggunakan apiserver di localhost:

core@master-01 ~ $ sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf -n kube-system edit configmap kube-proxy
# Change server: https://<ip>:6443 to https://127.0.0.1:6443

Sekarang mari kita coba menambahkan node pekerja (jalankan skrip di atas):
pekerja-01: 178.62.216.244

$ ssh [email protected]
core@worker-01 ~ $ sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 6443 -j DNAT --to 188.166.76.108
core@worker-01 ~ $ sudo iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to-source $(curl -s ipinfo.io | jq -r .ip)
core@worker-01 ~ $ sudo sysctl net.ipv4.conf.eth0.route_localnet=1
core@worker-01 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 127.0.0.1:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
core@worker-01 ~ $ sudo systemctl enable kubelet docker

Sekarang kita hanya perlu menambahkan loadbalancer lokal ke node pekerja, dan semuanya selesai.
Simpan yang berikut ini sebagai /etc/nginx/nginx.conf pada simpul pekerja-01:

error_log stderr notice;

worker_processes auto;
events {
    use epoll;
    worker_connections 1024;
}

stream {
    upstream kube_apiserver {
        least_conn;
        server 188.166.76.108:6443 max_fails=3 fail_timeout=30s;
        server 188.166.29.53:6443 max_fails=3 fail_timeout=30s;
        server 188.166.76.133:6443 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 127.0.0.1:6443 reuseport;
        proxy_pass kube_apiserver;
        proxy_timeout 10m;
        proxy_connect_timeout 1s;

    }
}

Buat /etc/kubernetes/manifests

core@worker-01 ~ $ sudo mkdir /etc/kubernetes/manifests

Menambahkan static nginx-proxy bermanifestasi sebagai /etc/kubernetes/manifests/nginx-proxy.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-proxy
  namespace: kube-system
  labels:
    k8s-app: kube-nginx
spec:
  hostNetwork: true
  containers:
  - name: nginx-proxy
    image: nginx:1.13-alpine
    imagePullPolicy: Always
    resources:
      limits:
        cpu: 200m
        memory: 128M
      requests:
        cpu: 50m
        memory: 32M
    volumeMounts:
    - mountPath: /etc/nginx
      name: etc-nginx
      readOnly: true
  volumes:
  - name: etc-nginx
    hostPath:
      path: /etc/nginx

Nyalakan ulang node dan aturan iptables sementara harus hilang, dan semuanya akan berfungsi seperti yang diharapkan.

Posting yang panjang, tetapi itu menunjukkan bahwa itu bisa dilakukan :)

Edit: Lupa mengubah server API untuk node pekerja: sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{bootstrap-kubelet.conf,kubelet.conf}
Edit2: Harus juga mengubah kubectl --kubeconfig=admin.conf -n kube-public get configmap cluster-info

@klausenbusk Bagus: tada :! Jika Anda ingin membawa / meningkatkan https://github.com/kubernetes/website/pull/6458 , jangan ragu untuk mengirim PR dengan detail lebih lanjut tentang apa yang Anda lakukan untuk membantu @jamiehannaford yang sedang liburan saat ini.

@klausenbusk , di master-02 dan master-03, saya tidak mengerti bagaimana Anda bisa bergabung? Karena direktori / etc / kubernetes tidak kosong. Bisakah Anda menjelaskan jika ada langkah yang terlewat?
Terima kasih.

@klausenbusk , di master-02 dan master-03, saya tidak mengerti bagaimana Anda bisa bergabung? Karena direktori / etc / kubernetes tidak kosong. Bisakah Anda menjelaskan jika ada langkah yang terlewat?

Saya memang menghapus sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf seperti yang didokumentasikan, menghapus seluruh direktori tidak diperlukan.

Kepada @discordianfish dan lainnya yang ingin menjalankan penyiapan HA di AWS.

Saya berhasil mendapatkan pengaturan HA untuk bekerja dengan Amazon's ELB (meskipun tidak memiliki satu alamat IP statis).

Untuk membuatnya berfungsi, langkah-langkah berikut (selain panduan HA @jamiehannaford ) perlu dilakukan:

• Karena ELB tidak memiliki alamat IP statis, kami tidak dapat menggunakannya sebagai alamat iklan apiserver. Sebagai gantinya, kami membiarkan setiap master mengiklankan alamat IP pribadinya sendiri.

  Sisi negatif dari pendekatan ini tampaknya adalah bahwa apiserver akan "memperebutkan" catatan titik akhir, menulis ulang sesekali (seperti yang dapat dilihat melalui kubectl get endpoints ) yang, pada gilirannya, memiliki konsekuensi untuk kube- proxy, yang akan menulis ulang iptables-nya setiap kali ada perubahan yang terdeteksi.

  Hal ini tampaknya tidak mengganggu kebenaran Kubernetes, tetapi saya rasa hal ini dapat menyebabkan penurunan performa dalam cluster yang besar. Ada pemikiran?

  Masalahnya dibahas lebih rinci di sini .

• Semua kubelet pekerja dan kube-proxies perlu mengakses server API melalui penyeimbang beban FQDN. Karena kubeadm tidak memungkinkan kita untuk menentukan server yang berbeda untuk kube-proxy dan kubelet pekerja (mereka hanya akan menggunakan alamat IP dari apiserver yang mereka hubungkan dengan kubeadm join )
  kita perlu mengurus ini sendiri.

  • Konfigurasi kube-proxy disimpan sebagai configmap, yang akan ditimpa setiap kali kubeadm init dijalankan (sekali untuk setiap node master). Oleh karena itu, untuk setiap kubeadm init kita perlu menambal configmap sebagai berikut:

    kubectl dapatkan configmap -n kube-system kube-proxy -o yaml> kube-proxy.cm
    sudo sed -i's # server :. * # server: https: //: 6443 # g 'kube-proxy.cm
    kubectl apply -f kube-proxy.cm --force

    restart semua pod kube-proxy untuk memastikan bahwa mereka memuat configmap baru

    kubectl hapus pod -n kube-system -l k8s-app = kube-proxy

  • Pada setiap pekerja kita perlu menambal konfigurasi kubelet setelah bergabung, sehingga kubelet terhubung melalui load-balancer.

    sudo kubeadm bergabung --config = kubeadm-config.yaml

    /etc/kubernetes/kubelet.conf mungkin tidak langsung ada

    wait_for 60 [-f /etc/kubernetes/kubelet.conf]
    sudo sed -i's # server :. * # server: https: //: 6443 # g '/etc/kubernetes/kubelet.conf
    sudo systemctl restart kubelet

Dengan pendekatan ini saya tampaknya memiliki cluster kerja di mana satu master pada satu waktu dapat turun tanpa gangguan layanan (apiserver).

Hal ini tampaknya tidak mengganggu kebenaran Kubernetes, tetapi saya rasa hal ini dapat menyebabkan penurunan performa dalam cluster yang besar. Ada pemikiran?

Anda dapat beralih ke rekonsiliator sewa baru di 1.9, ini akan memperbaiki "perselisihan" atas masalah titik akhir.

Saran yang sangat baik @klausenbusk. Ini bekerja seperti pesona.

@jodohgratis

mereka hanya akan menggunakan alamat IP apiserver yang mereka inginkan untuk terhubung ke kubeadm join

Apa yang terjadi jika Anda melakukan kubeadm join dengan IP LB?

Dalam hal kubelet, menurut saya itu adalah pengeditan manual yang diperlukan. Perlu ditambahkan ke panduan HA.

@jamiehannaford Masalah saat menggunakan ELB Amazon adalah tidak memberikan satu alamat IP yang stabil, jadi tidak ada IP LB yang dapat saya gunakan (lihat https://stackoverflow.com/a/35317682/7131191 ).

Jadi untuk saat ini pekerja bergabung melalui FQDN ELB, yang akan meneruskannya ke salah satu apiserver, yang, karena ini mengiklankan alamat IP-nya sendiri, membuat pekerja mengonfigurasi kubeletnya untuk menggunakan alamat IP itu (dan bukan ELB FQDN). Oleh karena itu, untuk memastikan bahwa kubelet melewati load-balancer apiserver, kubelet.conf perlu ditambal setelahnya dengan ELB FQDN dan kubelet di-restart.

Saya baru saja membuka tusukan di HA kubeadm. Dilengkapi dengan beberapa peringatan dan solusi buruk (terutama peretasan kube-proxy jelek). Tetapi berhasil: https://github.com/itskoko/kubecfn

Saya telah melakukan beberapa pekerjaan pada panduan penyiapan HA di google docs :

• mengambil alih beberapa perubahan yang diusulkan dalam komentar
• dukungan untuk plugin jaringan 'calico'
• mengambil alih penyiapan SSL _etcd_ dari dokumen panduan resmi yang ditulis oleh @jamiehannaford

Perubahan tersebut telah diterapkan dalam otomatisasi berbasis saya yang memungkinkan dari proses yang dijelaskan , ditambah lagi:

• pengaturan otomatis operator etcd untuk aplikasi yang berjalan di cluster (bukan cluster itu sendiri)
• mengambil gambar yang diperlukan untuk operasi Kubernetes dan menyalinnya ke host cluster
• Pengaturan dasbor (tidak aman, tanpa SSL) dengan port 30990 pada NodePort (jika tidak ada LB yang dikonfigurasi)

Saya telah menerbitkan skrip penginstal HA kubernetes berbasis kubeadm yang telah saya kerjakan belakangan ini. Mudah-mudahan ini akan menempatkan komentar saya sebelumnya ke dalam konteks dan berfungsi sebagai satu contoh konkret tentang bagaimana mengotomatiskan langkah-langkah panduan HA @jamiehannaford , yang mengikuti cukup dekat.

Ini adalah skrip python yang dijalankan dalam dua fase: render yang membuat "aset cluster" dalam bentuk kunci SSH, sertifikat, dan skrip boot, dan fase install yang menjalankan skrip boot tersebut melalui SSH.

Skrip telah dicoba di klaster Vagrant lokal dan terhadap AWS. Dua "skrip penyedia infrastruktur" disertakan dalam repo (gelandangan dan AWS melalui Terraform) untuk menyediakan penyeimbang beban cluster dan VM yang diperlukan.

Silakan mencobanya. https://github.com/elastisys/hakube-installer

Saya belum menemukan cara untuk meningkatkan cluster HA yang diinstal menggunakan kubeadm dan langkah-langkah manual yang dijelaskan dalam panduan penyiapan HA saya

Apa yang telah saya coba sejauh ini adalah sebagai berikut:

1. Matikan keepalived pada master sekunder, jalankan peningkatan kubeadm pada master utama, terapkan perubahan yang sama pada / etc / kubernetes / manifests pada master sekunder seperti pada master primer dan mulai keepalived pada master sekunder.
2. Sama seperti (1), tetapi selain keepalived, juga matikan (dan kemudian mulai) kubelet dan buruh pelabuhan di master sekunder.
3. Sama seperti (2), tetapi sebelum menerapkan peningkatan pada master utama, cordon (dan kemudian uncordon) semua master sekunder.

Ini tidak berhasil, dan hasilnya hampir sama di semua kasus. Apa yang saya dapatkan di log master sekunder terlihat seperti ini:

Unable to register node "master-2.mylan.local" with API server: nodes "master-2.mylan.local" is forbidden: node "master-1.mylan.local" cannot modify node "master-2.mylan.local"

Failed to update status for pod "kube-apiserver-master-2.mylan.local_kube-system(6d84ab47-0008-11e8-a558-0050568a9775)": pods "kube-apiserver-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-controller-manager-master-2.mylan.local_kube-system(665da2db-0008-11e8-a558-0050568a9775)": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-scheduler-master-2.mylan.local_kube-system(65c6a0b3-0008-11e8-a558-0050568a9775)": pods "kube-scheduler-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-flannel-ds-ch8gq_kube-system(47cccaea-0008-11e8-b5b5-0050568a9e45)": pods "kube-flannel-ds-ch8gq" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-proxy-htzg7_kube-system(47cc9d00-0008-11e8-b5b5-0050568a9e45)": pods "kube-proxy-htzg7" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Deleting mirror pod "kube-controller-manager-master-2.mylan.local_kube-system(665da2db-0008-11e8-a558-0050568a9775)" because it is outdated

Failed deleting a mirror pod "kube-controller-manager-master-2.mylan.local_kube-system": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only delete pods with spec.nodeName set to itself

Failed creating a mirror pod for "kube-controller-manager-master-2.mylan.local_kube-system(78432ebfe5d8dfbb93f8173decf3447e)": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only create pods with spec.nodeName set to itself

[... and so forth, repeats itself ...]

Adakah yang punya petunjuk bagaimana melanjutkan untuk meningkatkan master sekunder dengan bersih?

@mbert Sepertinya masalah RBAC. Apakah Anda memastikan nama node cocok dengan hostname-override ?

Juga, apakah Anda mengatur ulang etcd untuk setiap langkah? Itu mungkin menjelaskan mengapa Anda melihat hasil yang sama.

@jamiehannaford Saya tidak menggunakan penimpaan nama host, baik di kubelet maupun di konfigurasi init kubeadm. Dan, ya, saya menyetel ulang etcd, yaitu membongkar cluster, menginstal yang baru dari awal, lalu mencoba memutakhirkannya.

Saya akan memberikan pengaturan hostname-override untuk kubelet sebuah tembakan dan melihat apakah ini mengarah ke hasil lain.

Sepertinya pengaturan hostname-override saat mengatur cluster membantu, yaitu membuat master sekunder dapat diupgrade. Setelah ini menjadi prosedur standar, saya akan mendokumentasikannya di panduan penyiapan HA di google docs .

Hai @mbert dan lainnya - Dari sekitar setahun terakhir, saya memiliki beberapa cluster k8s (kubeadm dan lainnya) yang dijalankan dari Tukang Sepatu / Boneka di CoreOS dan CentOS. Namun, tidak satupun dari ini adalah HA.

Tugas saya selanjutnya adalah mengintegrasikan K8s HA dan saya ingin menggunakan kubeadm. Saya tidak yakin apakah akan pergi dengan @mbert 's HA pengaturan panduan atau @jamiehannaford' s HA panduan .

Juga - pagi ini saya membaca @timothysc 's Proposal untuk konfigurasi kontrol pesawat sangat tersedia untuk 'kubeadm' penyebaran. dan saya suka pendekatan "awal etcd seed" yang dia garisbawahi. Namun, saya tidak melihat pendekatan yang sama baik di karya @mbert atau @jamiehannaford . @mbert tampaknya menggunakan satu etcd yang dihosting k8s sementara dokumen @jamiehannaford mendokumentasikan pendekatan klasik dari external etcd (yang persis seperti yang telah saya gunakan untuk upaya POC non-HA saya yang lain).

Apa yang Anda rekomendasikan? Etcd eksternal, tunggal yang dihosting sendiri, atau mencari dan menggunakan "seed" etcd (dengan pivot ke k8s-hosted)? Jika yang terakhir - panduan atau dokumentasi apa yang Anda sarankan?

TIA!

@andybrucenet Eksternal etcd direkomendasikan untuk pengaturan HA (setidaknya pada saat ini). CoreOS baru-baru ini menghentikan dukungan untuk segala jenis hosting mandiri. Ini seharusnya hanya benar-benar digunakan untuk dev, staging, atau cluster kasual.

@andybrucenet Kurang tepat - Saya menggunakan cluster etcd eksternal seperti yang diusulkan @jamiehannaford dalam panduannya. Sebenarnya pendekatan yang dijelaskan dalam dokumen kita masing-masing seharusnya cukup mirip. Ini didasarkan pada pengaturan cluster etcd yang Anda rasa Anda butuhkan dan kemudian meminta kubeadm menggunakannya saat melakukan bootstrap pada cluster Kubernetes.

Saat ini saya kurang lebih akan menyelesaikan panduan saya dan implementasi berbasis yang mungkin dengan mendokumentasikan dan mengimplementasikan prosedur upgrade yang berfungsi - itu (dan beberapa perbaikan bug) harus dilakukan minggu depan.

Tidak yakin apakah akan ada kebutuhan untuk mentransfer lebih lanjut panduan saya ke milik Anda, @jamiehannaford bagaimana menurut Anda?

Sebenarnya penimpaan nama host tidak diperlukan. Saat menjalankan kubeadm upgrade apply , beberapa pengaturan default menimpa adaptasi saya, misalnya NodeRestriction diaktifkan kembali (juga penskalaan _Kube DNS_ saya direset, tetapi ini tentu saja bukan penghenti acara di sini). Menambal aturan admission NodeRestriction dari _ / etc / kubernetes / manifests / kube-apiserver.yaml_ berhasil.

Sekarang saya telah menulis bab tentang peningkatan cluster HA ke panduan penyiapan HA saya.

Saya juga telah menambahkan kode untuk mengotomatiskan proses ini ke proyek saya yang mungkin di github . Lihat file

@mbert untuk proses peningkatan yang telah Anda uraikan, apa alasan sebenarnya untuk menyalin konfigurasi dan manifestasi secara manual dari /etc/kubernetes pada master utama ke master sekunder daripada hanya menjalankan kubeadm upgrade apply <version> pada master sekunder juga?

@mattkelly Sepertinya agak berbahaya bagi saya.
Karena master cluster HA menggunakan pengaturan aktif / pasif, tetapi kubeadm hanya mengetahui satu master yang menurut saya menjalankannya lagi pada master yang berbeda berisiko.
Saya mungkin salah.

Membalas ke diri saya sendiri: Setelah melihat panduan Jamie di kubernetes.io , menjalankan kubeadm di master mungkin berfungsi, bahkan saat menyiapkan cluster. Saya akan mencobanya minggu depan dan mungkin akan membuat beberapa perubahan pada dokumen saya.

FWIW, menjalankan kubeadm pada master sekunder tampaknya telah bekerja dengan baik untuk saya (termasuk peningkatan) - tetapi saya perlu lebih memahami risiko yang sebenarnya pada setiap tahap. Saya sudah mengikuti @jamiehannaford 's panduan yang otomatis oleh @petergardfjall' s hakube-installer (tidak ada dukungan peningkatan belum sekalipun, jadi saya diuji secara manual).

Sunting: Yang juga penting untuk diperhatikan adalah bahwa saya hanya menguji pada v1.9 +. Peningkatan dari v1.9.0 ke v1.9.2.

Saya sekarang telah mengikuti panduan di kubernetes.io yang dibuat oleh @jamiehannaford , yaitu menjalankan kubeadm init pada semua mesin master (setelah menyalin /etc/kubernetes/pki/ca.* ke master sekunder). Ini berfungsi dengan baik untuk menyiapkan cluster. Untuk dapat meningkatkan ke v1.9.2 saya menyiapkan v1.8.3 di sini.

Sekarang saya mengalami masalah saat mencoba memutakhirkan cluster: Menjalankan kubeadm upgrade apply v1.9.2 pada master pertama gagal:

[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests872757515/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests872757515/kube-scheduler.yaml"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests647361774/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

Langkah ini gagal direproduksi (saya selalu mulai dari awal, yaitu menghapus semua file konfigurasi ditambah data etcd dari semua node sebelum memulai pengaturan baru).

Saya mencoba beberapa variasi, tetapi tidak berhasil:

• Apakah kubelet menggunakan instance Server API lokal atau yang ditunjuk oleh IP virtual
• minta kube-proxy menggunakan instance Server API lokal atau yang ditunjuk oleh IP virtual

Saya telah melampirkan beberapa log. Namun saya tidak dapat benar-benar menemukan pola umum yang akan menjelaskan masalah ini kepada saya. Mungkin itu adalah sesuatu yang saya tidak tahu?

upgrade-gagal-proxy-on-vip.log
upgrade-gagal-proxy-dan-kubelet-on-vip.log
upgrade-gagal-proxy-dan-kubelet-on-local-ip.log

Setelah mencoba beberapa hal lainnya, intinya adalah sebagai berikut:

• Memperbarui master yang terakhir kali diset (yaitu yang kubeadm init dijalankan terakhir saat menyiapkan kluster) akan berhasil.
• Saya juga bisa mendapatkan node lain yang berfungsi, jika saya mengedit configmap/kubeadm-config dan mengubah nilai MasterConfiguration.nodeName di sana ke nama host master masing-masing atau cukup hapus baris itu.

Orang lain seperti @mattkelly dapat melakukan peningkatan tanpa mengedit configmap/kubeadm-config , oleh karena itu cara saya mengatur semuanya pasti berbeda.

Adakah yang tahu apa yang harus saya ubah, sehingga pemutakhiran bekerja tanpa trik (agak kotor) ini?

Saya telah mencoba meningkatkan dari 1.8.3 dan 1.9.0 ke 1.9.2, dengan hasil yang sama.

@mbert Sekarang saya mereproduksi masalah Anda dari kluster v1.9.0 baru yang dibuat menggunakan hakube-installer . Mencoba meningkatkan ke v1.9.3. Saya tidak bisa memikirkan apa pun yang telah berubah dengan alur kerja saya. Saya akan mencoba mencari tahu hari ini.

Saya memverifikasi bahwa menghapus baris nodeName dari configmap/kubeadm-config untuk setiap perbaikan masalah berikutnya.

Terima kasih, itu sangat membantu. Saya sekarang telah menambahkan patching configmap/kubeadm-config ke instruksi saya.

@ mbert oops, saya menemukan perbedaannya :). Untuk peningkatan sebelumnya saya telah menyediakan konfigurasi yang dihasilkan selama penyiapan melalui --config (memori otot saya kira). Inilah mengapa saya tidak pernah membutuhkan solusi tersebut. Saya percaya bahwa solusi Anda lebih tepat jika cluster telah berubah sejak waktu init. Akan sangat bagus untuk mengetahui cara menghindari peretasan itu, tetapi itu tidak terlalu buruk untuk sementara waktu - terutama dibandingkan dengan semua solusi lainnya.

Halo,
Akankah kubeadm 1.10 menghapus salah satu langkah awal / solusi yang saat ini diperlukan untuk HA di 1.9?
Misalnya pembuatan manual bootstrap etcd, pembuatan kunci etcd, dll?

Menutup item ini karena 1.10 dokumen sudah keluar dan kita akan melanjutkan ke cerita HA lebih lanjut di 1.11

/ cc @fabriziopandini