Membuat sebuah klaster dengan control-plane tunggal menggunakan kubeadm

Perkakas kubeadm membantu kamu membuat sebuah klaster Kubernetes minimum yang layak dan sesuai dengan best practice. Bahkan, kamu dapat menggunakan kubeadm untuk membuat sebuah klaster yang lolos uji Kubernetes Conformance.
kubeadm juga mendukung fungsi siklus hidup (lifecycle) klaster lainnya, seperti bootstrap token dan pembaruan klaster (cluster upgrade).

kubeadm merupakan perkakas yang bagus jika kamu membutuhkan:

  • Sebuah cara yang sederhana untuk kamu mencoba Kubernetes, mungkin untuk pertama kalinya.
  • Sebuah cara bagi pengguna lama (existing users) untuk mengotomatiskan penyetelan sebuah klaster dan menguji aplikasi mereka.
  • Sebuah komponen dasar pada ekosistem lain dan/atau perkakas penginstal lain dengan cakupan yang lebih luas.

Kamu dapat menginstal dan menggunakan kubeadm pada berbagai macam mesin: laptop milikmu, sekelompok server di cloud, sebuah Raspberry Pi, dan lain-lain. Baik itu men-deploy pada cloud ataupun on-premise, kamu dapat mengintegrasikan kubeadm pada sistem provisioning seperti Ansible atau Terraform.

Sebelum kamu memulai

Untuk mengikuti panduan ini, kamu membutuhkan:

  • Satu mesin atau lebih, yang menjalankan sistem operasi Linux yang kompatibel dengan deb atau rpm; sebagai contoh: Ubuntu atau CentOS.
  • 2 GiB atau lebih RAM per mesin--kurang dari nilai tersebut akan menyisakan sedikit ruang untuk aplikasi-aplikasimu.
  • Sedikitnya 2 CPU pada mesin yang akan kamu gunakan sebagai Node control-plane.
  • Koneksi internet pada seluruh mesin pada klaster. Kamu dapat menggunakan internet publik ataupun pribadi.

Kamu juga harus menggunakan versi kubeadm yang dapat men-deploy versi Kubernetes yang ingin kamu gunakan pada klaster barumu.

Kebijakan dukungan versi Kubernetes dan version skew juga berlaku pada kubeadm dan Kubernetes secara umum. Periksa kebijakan tersebut untuk mempelajari tentang versi Kubernetes dan kubeadm mana saja yang didukung. Laman ini ditulis untuk Kubernetes v1.24.

Fitur kubeadm secara umum berstatus General Availability (GA). Beberapa sub-fitur sedang berada dalam pengembangan. Implementasi pembuatan klaster dapat berubah sedikit seiring dengan berevolusinya kubeadm, namun secara umum implementasinya sudah cukup stabil.

Tujuan

  • Menginstal Kubernetes klaster dengan control-plane tunggal atau klaster dengan ketersediaan tinggi
  • Menginstal jaringan Pod pada klaster sehingga Pod dapat berinteraksi satu sama lain

Instruksi

Menginstal kubeadm pada hos

Lihat "Menginstal kubeadm".

Menginisialisasi Node control-plane

Node control-plane adalah mesin dimana komponen-komponen control plane berjalan, termasuk etcd (basis data klaster) dan API Server (yang akan berkomunikasi dengan perkakas command line kubectl.

  1. (Direkomendasikan) Jika kamu berencana untuk memperbarui klaster kubeadm dengan control-plane tunggal menjadi ketersediaan tinggi kamu harus menentukan --control-plane-endpoint agar mengarah ke endpoint yang digunakan bersama untuk semua Node control-plane. Endpoint tersebut dapat berupa nama DNS atau sebuah alamat IP dari load-balancer.
  2. Pilih add-on jaringan Pod, dan pastikan apakah diperlukan argumen untuk diberikan pada kubeadm init. Tergantung penyedia pihak ketiga yang kamu pilih, kamu mungkin harus mengatur --pod-network-cidr dengan nilai yang spesifik pada penyedia tertentu. Lihat Menginstal add-on jaringan Pod.
  3. (Opsional) Sejak versi 1.14, kubeadm mencoba untuk mendeteksi runtime kontainer pada Linux dengan menggunakan daftar domain socket path yang umum diketahui. Untuk menggunakan runtime kontainer yang berbeda atau jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen --cri-socket pada kubeadm init. Lihat Menginstal runtime.
  4. (Opsional) Kecuali ditentukan sebelumnya, kubeadm akan menggunakan antarmuka jaringan yang diasosiasikan dengan default gateway untuk mengatur alamat advertise untuk API Server pada Node control-plane ini. Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen --apiserver-advertise-address=<ip-address> pada kubeadm init. Untuk men-deploy klaster Kubernetes IPv6 menggunakan pengalamatan IPv6, kamu harus menentukan alamat IPv6, sebagai contoh --apiserver-advertise-address=fd00::101
  5. (Opsional) Jalankan kubeadm config images pull sebelum kubeadm init untuk memastikan konektivitas ke container image registry gcr.io.

Untuk menginisialisasi Node control-plane jalankan:

kubeadm init <args>

Pertimbangan mengenai apiserver-advertise-address dan ControlPlaneEndpoint

Meski --apiserver-advertise-address dapat digunakan untuk mengatur alamat advertise untuk server API pada Node control-plane ini, --control-plane-endpoint dapat digunakan untuk mengatur endpoint yang digunakan bersama untuk seluruh Node control-plane.

--control-plane-endpoint tidak hanya mengizinkan alamat IP tetapi juga nama DNS yang dapat dipetakan ke alamat IP. Silakan hubungi administrator jaringan kamu untuk mengevaluasi solusi-solusi yang mempertimbangkan pemetaan tersebut.

Berikut contoh pemetaannya:

192.168.0.102 cluster-endpoint

Di mana 192.168.0.102 merupakan alamat IP dari Node ini dan cluster-endpoint merupakan nama DNS custom yang dipetakan pada IP ini. Hal ini memungkinkan kamu untuk memberikan --control-plane-endpoint=cluster-endpoint pada kubeadm init dan memberikan nama DNS yang sama pada kubeadm join. Kemudian kamu dapat memodifikasi cluster-endpoint untuk mengarah pada alamat load-balancer dalam skenario ketersediaan tinggi (highly availabile).

Mengubah klaster control plane tunggal yang dibuat tanpa --control-plane-endpoint menjadi klaster dengan ketersediaan tinggi tidak didukung oleh kubeadm.

Informasi lebih lanjut

Untuk informasi lebih lanjut mengenai argumen-argumen kubeadm init, lihat panduan referensi kubeadm.

Untuk daftar pengaturan konfigurasi yang lengkap, lihat dokumentasi berkas konfigurasi.

Untuk menyetel komponen-komponen control plane, termasuk pemasangan IPv6 opsional pada liveness probe untuk komponen-komponen control plane dan server etcd, berikan argumen ekstra pada tiap komponen seperti yang didokumentasikan pada argumen-argumen custom.

Untuk menjalankan kubeadm init lagi, sebelumnya kamu harus membongkar klaster.

Jika kamu menggabungkan sebuah Node dengan arsitektur yang berbeda ke klastermu, pastikan DaemonSets yang di_deploy_ memiliki image kontainer yang mendukung arsitektur tersebut.

Pertama-tama kubeadm init akan menjalankan sekumpulan precheck untuk memastikan mesin siap untuk menjalankan Kubernetes. Kumpulan precheck ini menunjukkan peringatan-peringatan dan akan berhenti jika terjadi kesalahan. Kemudian kubeadm init akan mengunduh dan menginstal komponen-komponen control plane klaster. Hal ini membutuhkan waktu beberapa menit. Keluaran yang dihasilkan terlihat seperti berikut ini:

[init] Using Kubernetes version: vX.Y.Z
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubeadm-cp kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 31.501735 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-cp" as an annotation
[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: <token>
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a Pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  /docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Untuk membuat kubectl bekerja bagi pengguna non-root, jalankan perintah-perintah berikut, yang juga merupakan bagian dari keluaran kubeadm init:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Secara alternatif, jika kamu adalah pengguna root, kamu dapat menjalankan:

export KUBECONFIG=/etc/kubernetes/admin.conf

Buatlah catatan dari perintah kubeadm join yang dihasilkan kubeadm init. Kamu membutuhkan perintah ini untuk menggabungkan Node-Node ke klaster.

Token digunakan untuk otentikasi bersama (mutual authentication) antara Node control-plane dan Node-Node yang akan bergabung. Token yang didapat di sini bersifat rahasia. Simpan dengan aman, karena siapapun yang memiliki token tersebut dapat menambahkan Node-Node yang dapat mengotentikasikan diri ke klaster. Kamu dapat menampilkan daftar token, membuat, dan menghapus token dengan perintah kubeadm token. Lihat panduan referensi kubeadm.

Menginstal add-on jaringan Pod

Beberapa proyek eksternal menyediakan jaringan Pod Kubernetes menggunakan CNI, beberapa di antaranya juga mendukung Network Policy.

Lihat daftar add-on jejaring dan network policy yang tersedia.

Kamu dapat menginstal add-on jaringan Pod dengan perintah berikut pada Node control-plane atau Node yang memiliki kredensial kubeconfig:

kubectl apply -f <add-on.yaml>

Kamu hanya dapat menginstal satu jaringan Pod per klaster. Di bawah ini kamu dapat menemukan instruksi instalasi untuk beberapa plugin jaringan Pod yang populer:

Calico merupakan penyedia jejaring dan network policy. Calico mendukung sekumpulan opsi jejaring yang fleksibel sehingga kamu dapat memilih opsi yang paling efisien untuk situasimu, termasuk jaringan non-overlay dan overlay, dengan atau tanpa BGP. Calico menggunakan mesin yang sama untuk melaksanakan network policy pada hos, Pod, dan (jika menggunakan Istio & Envoy) aplikasi yang berada pada lapisan service mesh. Calico bekerja pada beberapa arsitektur, meliputi amd64, arm64, dan ppc64le.

Secara bawaan, Calico menggunakan 192.168.0.0/16 sebagai CIDR jaringan Pod, namun hal ini dapat diatur pada berkas calico.yaml. Agar Calico dapat bekerja dengan benar, kamu perlu memberikan CIDR yang sama pada perintah kubeadm init menggunakan opsi --pod-network-cidr=192.168.0.0/16 atau melalui konfigurasi kubeadm.

kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml

Agar Cilium dapat bekerja dengan benar, kamu harus memberikan --pod-network-cidr=10.217.0.0/16 pada kubeadm init.

Untuk men-deploy Cilium kamu hanya perlu menjalankan:

kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml

Ketika seluruh Pod Cilium sudah bertanda READY, kamu dapat mulai menggunakan klaster.

kubectl get pods -n kube-system --selector=k8s-app=cilium

Keluarannya akan tampil seperti berikut:

NAME           READY   STATUS    RESTARTS   AGE
cilium-drxkl   1/1     Running   0          18m

Cilium dapat digunakan sebagai kube-proxy, lihat Kubernetes tanpa kube-proxy.

Untuk informasi lebih lanjut mengenai penggunaan Cilium dengan Kubernetes, lihat panduan Instalasi Kubernetes untuk Cilium.

Contiv-VPP menggunakan CNF vSwitch berbasis FD.io VPP yang dapat diprogram, menawarkan layanan dan jejaring cloud-native yang memiliki banyak fungsi dan berkinerja tinggi.

Contiv-VPP mengimplementasikan Service dan Network Policy Kubernetes pada user space (on VPP).

Silakan merujuk pada panduan pemasangan berikut: Pemasangan Manual Contiv-VPP

Kube-router mengandalkan kube-controller-manager untuk mengalokasikan CIDR Pod untuk Node-Node. Maka dari itu, gunakan kubeadm init dengan opsi --pod-network-cidr.

Kube-router menyediakan jejaring Pod, network policy, dan IP Virtual Server(IPVS)/Linux Virtual Server(LVS) berbasis service proxy yang memiliki kinerja tinggi.

Informasi mengenai penggunaan kubeadm untuk mendirikan klaster Kubernetes dengan Kube-router, dapat dilihat di panduan pemasangan resminya.

Untuk informasi lebih lanjut mengenai pemasangan klaster Kubernetes menggunakan Weave Net, silakan lihat Mengintegrasikan Kubernetes melalui Addon.

Weave Net bekerja pada platform amd64, arm, arm64 dan ppc64le tanpa membutuhkan tindakan ekstra. Weave Net menyalakan mode hairpin secara bawaan. Hal ini mengizinkan Pod untuk mengakses dirinya sendiri melalui alamat IP Service jika mereka tidak tahu PodIP miliknya.

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Setelah jaringan Pod dipasangkan, kamu dapat mengonfirmasi hal tersebut dengan memastikan Pod CoreDNS berada pada kondisi Running pada keluaran kubectl get pods --all-namespaces. Dan setelah Pod CoreDNS sudah menyala dan berjalan, kamu dapat melanjutkan (pemasangan klaster) dengan menggabungkan Node-Node yang lain.

Jika jaringan belum bekerja atau CoreDNS tidak berada pada kondisi Running, periksalah/lihatlah panduan penyelesaian masalah untuk kubeadm.

Isolasi Node control plane

Secara bawaan, klaster tidak akan menjadwalkan Pod pada Node control-plane untuk alasan keamanan. Jika kamu ingin Pod dapat dijadwalkan pada Node control-plane, sebagai contoh untuk klaster Kubernetes bermesin-tunggal untuk pengembangan, jalankan:

kubectl taint nodes --all node-role.kubernetes.io/master-

Dengan keluaran seperti berikut:

node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found

Hal ini akan menghapus taint node-role.kubernetes.io/master pada Node manapun yang memilikinya, termasuk Node control-plane, sehingga scheduler akan dapat menjadwalkan Pod di manapun.

Menggabungkan Node-Node

Node adalah tempat beban kerja (Container, Pod, dan lain-lain) berjalan. Untuk menambahkan Node baru pada klaster lakukan hal berikut pada setiap mesin:

  • SSH ke mesin
  • Gunakan pengguna root (mis. sudo su -)
  • Jalankan perintah hasil keluaran kubeadm init. Sebagai contoh:
kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Jika kamu tidak memiliki token, kamu bisa mendapatkannya dengan menjalankan perintah berikut pada Node control-plane:

kubeadm token list

Keluarannya akan tampil seperti berikut:

TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
                                                                    'kubeadm init'.        kubeadm:
                                                                                           default-node-token

Secara bawaan, token akan kadaluarsa dalam 24 jam. Jika kamu menggabungkan Node ke klaster setelah token kadaluarsa, kamu dapat membuat token baru dengan menjalankan perintah berikut pada Node control-plane:

kubeadm token create

Keluarannya akan tampil seperti berikut:

5didvk.d09sbcov8ph2amjw

Jika kamu tidak memiliki nilai --discovery-token-ca-cert-hash, kamu bisa mendapatkannya dengan menjalankan perintah berantai berikut pada Node control-plane:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'

Keluaran yang diberikan kurang lebih akan ditampilkan sebagai berikut:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

Keluaran yang diberikan kurang lebih akan ditampilkan sebagai berikut:

[preflight] Running pre-flight checks

... (log output of join workflow) ...

Node join complete:
* Certificate signing request sent to control-plane and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on control-plane to see this machine join.

Beberapa saat kemudian, kamu akan melihat Node tersebut pada keluaran dari kubectl get nodes ketika dijalankan pada Node control-plane.

(Opsional) Mengendalikan klaster dari mesin selain Node control-plane

Untuk membuat kubectl bekerja pada mesin lain (mis. laptop) agar dapat berbicara dengan klaster, kamu harus menyalin berkas kubeconfig administrator dari Node control-plane ke mesin seperti berikut:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

(Opsional) Memproksi API Server ke localhost

Jika kamu ingin terhubung dengan API Server dari luar klaster kamu dapat menggunakan kubectl proxy:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

Kini kamu dapat mengakses API Server secara lokal melalui http://localhost:8001/api/v1

Pembongkaran

Jika kamu menggunakan server sekali pakai untuk membuat klaster, sebagai ujicoba, kamu dapat mematikannya tanpa perlu melakukan pembongkaran. Kamu dapat menggunakan kubectl config delete-cluster untuk menghapus referensi lokal ke klaster.

Namun, jika kamu ingin mengatur ulang klaster secara lebih rapih, pertama-tama kamu harus menguras (drain) Node dan memastikan Node sudah kosong, kemudian mengembalikan pengaturan pada Node kembali seperti semula.

Menghapus Node

Berinteraksi dengan Node control-plane menggunakan kredensial yang sesuai, jalankan:

kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
kubectl delete node <node name>

Lalu, pada Node yang dihapus, atur ulang semua kondisi kubeadm yang telah dipasang:

kubeadm reset

Proses pengaturan ulang tidak mengatur ulang atau membersihkan kebijakan iptables atau tabel IPVS. Jika kamu ingin mengatur ulang iptables, kamu harus melakukannya secara manual:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

Jika kamu ingin mengatur ulang tabel IPVS, kamu harus menjalankan perintah berikut:

ipvsadm -C

Jika kamu ingin mengulang dari awal, cukup jalankan kubeadm init atau kubeadm join dengan argumen yang sesuai.

Membersihkan control plane

Kamu dapat menggunakan kubeadm reset pada hos control plane untuk memicu pembersihan best-effort.

Lihat dokumentasi referensi kubeadm reset untuk informasi lebih lanjut mengenai sub-perintah ini dan opsinya.

Selanjutnya

  • Pastikan klaster berjalan dengan benar menggunakan Sonobuoy
  • Lihat Memperbaharui klaster kubeadm untuk detail mengenai pembaruan klaster menggunakan kubeadm.
  • Pelajari penggunaan kubeadm lebih lanjut pada dokumentasi referensi kubeadm
  • Pelajari lebih lanjut mengenai konsep-konsep Kubernetes dan kubectl.
  • Lihat halaman Cluster Networking untuk daftar add-on jaringan Pod yang lebih banyak.
  • Lihat daftar add-on untuk mengeksplor add-on lainnya, termasuk perkakas untuk logging, monitoring, network policy, visualisasi & pengendalian klaster Kubernetes.
  • Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari aplikasi-aplikasi yang berjalan pada Pod. Lihat Arsitektur Logging untuk gambaran umum tentang hal-hal yang terlibat.

Umpan balik

Kebijakan version skew

kubeadm versi v1.24 dapat men-deploy klaster dengan control plane versi v1.24 atau v1.23. kubeadm v1.24 juga dapat memperbarui klaster yang dibuat dengan kubeadm v1.23.

Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v1.24 mungkin atau tidak mungkin dapat men-deploy klaster v1.25.

Sumber daya ini menyediakan informasi lebih lanjut mengenai version skew yang didukung antara kubelet dan control plane, serta komponen Kubernetes lainnya:

Keterbatasan

Ketahanan klaster

Klaster yang dibuat pada panduan ini hanya memiliki Node control-plane tunggal, dengan basis data etcd tunggal yang berjalan di atasnya. Hal ini berarti jika terjadi kegagalan pada Node control-plane, klaster dapat kehilangan data dan mungkin harus dibuat kembali dari awal.

Solusi:

  • Lakukan back up etcd secara reguler. Direktori data etcd yang dikonfigurasi oleh kubeadm berada di /var/lib/etcd pada Node control-plane.

  • Gunakan banyak Node control-plane. Kamu dapat membaca Opsi untuk topologi dengan ketersediaan tinggi untuk memilih topologi klaster yang menyediakan ketersediaan lebih tinggi.

Kompatibilitas platform

Package dbm/rpm dan binary kubeadm dibuat untuk amd64, arm (32-bit), arm64, ppc64le, dan s390x mengikuti proposal multi-platform.

Image kontainer multiplatform untuk control plane dan addon juga telah didukung sejak v1.12.

Hanya beberapa penyedia jaringan yang menawarkan solusi untuk seluruh platform. Silakan merujuk pada daftar penyedia jaringan di atas atau dokumentasi dari masing-masing penyedia untuk mencari tahu apakah penyedia tersebut mendukung platform pilihanmu.

Penyelesaian masalah

Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada dokumen penyelesaian masalah.

Last modified September 08, 2021 at 10:35 AM PST: Change reference to kubeadm-stacked-color.png (826fb8dc90)