Persiapan

• 1: Lingkungan Pembelajaran
• 2: Lingkungan Produksi
• 2.1: Runtime Container
• 2.2: Menginstal Kubernetes dengan perkakas penyebaran
• 2.2.1: Menyiapkan klaster dengan kubeadm
• 2.2.1.1: Menginstal kubeadm
• 2.2.1.2: Membuat sebuah klaster dengan control-plane tunggal menggunakan kubeadm
• 2.2.1.3: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm
• 3: Praktek-praktek Terbaik
• 3.1: Menjalankan klaster dalam beberapa zona

1 - Lingkungan Pembelajaran

kind

kind memberikan kamu kemampuan untuk menjalankan Kubernetes pada komputer lokal kamu. Perangkat ini membutuhkan Docker yang sudah diinstal dan terkonfigurasi.

Halaman Memulai Cepat kind memperlihatkan kepada kamu tentang apa yang perlu kamu lakukan agar kind dapat berjalan dan bekerja.

Melihat Memulai Cepat Kind

minikube

Seperti halnya dengan kind, minikube merupakan perangkat yang memungkinkan kamu untuk menjalankan Kubernetes secara lokal. minikube menjalankan sebuah klaster Kubernetes dengan satu node saja dalam komputer pribadi (termasuk Windows, macOS dan Linux) sehingga kamu dapat mencoba Kubernetes atau untuk pekerjaan pengembangan sehari-hari.

Kamu bisa mengikuti petunjuk resmi Memulai! minikube jika kamu ingin fokus agar perangkat ini terinstal.

Lihat Panduan Memulai! Minikube

Setelah kamu memiliki minikube yang bekerja, kamu bisa menggunakannya untuk menjalankan aplikasi contoh.

2 - Lingkungan Produksi

2.1 - Runtime Container

Untuk menjalankan Container di Pod, Kubernetes menggunakan runtime Container (Container runtimes). Berikut ini adalah petunjuk instalasi untuk berbagai macam runtime.

Penerapan

Kamu harus menjalankan semua perintah dalam panduan ini sebagai root. Sebagai contoh, awali perintah dengan sudo, atau masuk sebagai root dan kemudian baru menjalankan perintah sebagai pengguna root.

Driver cgroup

Ketika systemd dipilih sebagai sistem init untuk sebuah distribusi Linux, proses init menghasilkan dan menggunakan grup kontrol root (cgroup) dan proses ini akan bertindak sebagai manajer cgroup. Systemd memiliki integrasi yang ketat dengan cgroup dan akan mengalokasikan cgroups untuk setiap proses. Kamu dapat mengonfigurasi runtime Container dan kubelet untuk menggunakan cgroupfs. Menggunakan cgroupfs bersama dengan systemd berarti akan ada dua manajer cgroup yang berbeda.

Cgroup digunakan untuk membatasi sumber daya yang dialokasikan untuk proses. Sebuah manajer cgroup tunggal akan menyederhanakan pandangan tentang sumber daya apa yang sedang dialokasikan dan secara bawaan (default) akan memiliki pandangan yang lebih konsisten tentang sumber daya yang tersedia dan yang sedang digunakan. Ketika kita punya memiliki dua manajer maka kita pun akan memiliki dua pandangan berbeda tentang sumber daya tersebut. Kita telah melihat kasus di lapangan di mana Node yang dikonfigurasi menggunakan cgroupfs untuk kubelet dan Docker, dan systemd untuk semua sisa proses yang berjalan pada Node maka Node tersebut akan menjadi tidak stabil di bawah tekanan sumber daya.

Mengubah aturan sedemikian rupa sehingga runtime Container dan kubelet kamu menggunakan systemd sebagai driver cgroup akan menstabilkan sistem. Silahkan perhatikan opsi native.cgroupdriver=systemd dalam pengaturan Docker di bawah ini.

Docker

Pada setiap mesin kamu, mari menginstall Docker. Versi yang direkomendasikan adalah 19.03.11, tetapi versi 1.13.1, 17.03, 17.06, 17.09, 18.06 dan 18.09 juga diketahui bekerja dengan baik. Jagalah versi Docker pada versi terbaru yang sudah terverifikasi pada catatan rilis Kubernetes.

Gunakan perintah berikut untuk menginstal Docker pada sistem kamu:

• Ubuntu 16.04+
• CentOS/RHEL 7.4+

# (Menginstal Docker CE)
## Mengatur repositori:
### Menginstal packet untuk mengijinkan apt untuk menggunakan repositori melalui HTTPS
apt-get update && apt-get install -y \
  apt-transport-https ca-certificates curl software-properties-common gnupg2

# Menambahkan key GPG resmi dari Docker:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

# Menambahkan repositori apt dari Docker:
add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"

# Menginstal Docker CE
apt-get update && apt-get install -y \
  containerd.io=1.2.13-2 \
  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)

# Mengatur daemon Docker
cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

mkdir -p /etc/systemd/system/docker.service.d

# Menjalankan ulang Docker
systemctl daemon-reload
systemctl restart docker

# (Menginstal Docker CE)
## Mengatur repositori
### Menginstal paket yang diperlukan
yum install -y yum-utils device-mapper-persistent-data lvm2

## Menambahkan repositori apt dari Docker
yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

# Menginstal Docker CE
yum update -y && yum install -y \
  containerd.io-1.2.13 \
  docker-ce-19.03.11 \
  docker-ce-cli-19.03.11

## Membuat berkas /etc/docker
mkdir /etc/docker

# Mengatur daemon Docker
cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}
EOF

mkdir -p /etc/systemd/system/docker.service.d

# Menjalankan ulang Docker
systemctl daemon-reload
systemctl restart docker

Jika kamu menginginkan layanan Docker berjalan dari saat memulai pertama (boot), jalankan perintah ini:

sudo systemctl enable docker

Silahkan merujuk pada Panduan resmi instalasi Docker untuk informasi lebih lanjut.

CRI-O

Bagian ini mencakup langkah-langkah yang diperlukan untuk menginstal CRI-O sebagai runtime CRI.

Gunakan perintah-perinath berikut untuk menginstal CRI-O pada sistem kamu:

Prasyarat

modprobe overlay
modprobe br_netfilter

# Mengatur parameter sysctl yang diperlukan, dimana ini akan bernilai tetap setiap kali penjalanan ulang.
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sysctl --system

• Debian
• Ubuntu 18.04, 19.04 and 19.10
• CentOS/RHEL 7.4+
• openSUSE Tumbleweed

# Debian Unstable/Sid
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -

# Debian Testing
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -

# Debian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -

# Raspbian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -

sudo apt-get install cri-o-1.17

# Mengatur repositori paket
. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
sudo apt-get update

# Menginstal CRI-O
sudo apt-get install cri-o-1.17

# Menginstal prasyarat
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:1.26.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:1.26/CentOS_7/devel:kubic:libcontainers:stable:cri-o:1.26.repo

# Menginstal CRI-O
yum install -y cri-o

sudo zypper install cri-o

Memulai CRI-O

systemctl daemon-reload
systemctl start crio

Silahkan merujuk pada Panduan instalasi CRI-O untuk informasi lanjut.

Containerd

Bagian ini berisi langkah-langkah yang diperlukan untuk menggunakan containerd sebagai runtime CRI.

Gunakan perintah-perintah berikut untuk menginstal containerd pada sistem kamu:

Prasyarat

cat > /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

# Mengatur parameter sysctl yang diperlukan, dimana ini akan bernilai tetap setiap kali penjalanan ulang.
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sysctl --system

Menginstal containerd

• Ubuntu 16.04
• CentOS/RHEL 7.4+

# (Meninstal containerd)
## Mengatur repositori paket
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common

## Menambahkan key GPG resmi dari Docker:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

## Mengatur repositori paket Docker
add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"

## Menginstal containerd
apt-get update && apt-get install -y containerd.io

# Mengonfigure containerd
mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Menjalankan ulang containerd
systemctl restart containerd

# (Menginstal containerd)
## Mengatur repositori
### Menginstal paket prasyarat
yum install -y yum-utils device-mapper-persistent-data lvm2

## Menambahkan repositori Docker
yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

## Menginstal containerd
yum update -y && yum install -y containerd.io

## Mengonfigurasi containerd
mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Menjalankan ulang containerd
systemctl restart containerd

systemd

Untuk menggunakan driver cgroup systemd, atur plugins.cri.systemd_cgroup = true pada /etc/containerd/config.toml. Ketika menggunakan kubeadm, konfigurasikan secara manual driver cgroup untuk kubelet

Runtime CRI yang lainnya: Frakti

Silahkan lihat Panduan cepat memulai Frakti untuk informasi lebih lanjut.

2.2 - Menginstal Kubernetes dengan perkakas penyebaran

2.2.1 - Menyiapkan klaster dengan kubeadm

2.2.1.1 - Menginstal kubeadm

Laman ini menunjukkan cara untuk menginstal kubeadm. Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman Menggunakan kubeadm untuk Membuat Sebuah Klaster.

Sebelum kamu memulai

• Satu mesin atau lebih yang menjalankan:
  • Ubuntu 16.04+
  • Debian 9+
  • CentOS 7
  • Red Hat Enterprise Linux (RHEL) 7
  • Fedora 25+
  • HypriotOS v1.0.1+
  • Container Linux (teruji pada versi 1800.6.0)
• 2 GB RAM atau lebih per mesin (kurang dari nilai tersebut akan menyisakan sedikit ruang untuk aplikasi-aplikasimu)
• 2 CPU atau lebih
• Koneksi internet pada seluruh mesin pada klaster (kamu dapat menggunakan internet publik ataupun pribadi)
• Hostname yang unik, alamat MAC, dan product_uuid untuk setiap Node. Lihat di sini untuk detail lebih lanjut.
• Porta tertentu pada mesin. Lihat di sini untuk detail lebih lanjut.
• Swap dinonaktifkan. Kamu HARUS menonaktifkan swap agar kubelet dapat berfungsi dengan baik.

Memastikan alamat MAC dan product_uuid yang unik untuk setiap Node

• Kamu bisa mendapatkan alamat MAC dari antarmuka jaringan menggunakan perintah ip link atau ifconfig -a
• product_uuid didapatkan dengan perintah sudo cat /sys/class/dmi/id/product_uuid

Sangat memungkinkan bagi perangkat keras untuk memiliki alamat yang unik, namun beberapa mesin virtual bisa memiliki nilai yang identik. Kubernetes menggunakan nilai-nilai tersebut untuk mengidentifikasi Node-Node secara unik pada klaster. Jika nilai-nilai tersebut tidak unik pada tiap Node, proses instalasi bisa saja gagal.

Memeriksa adaptor jaringan

Jika kamu memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes tidak dapat dijangkau melalui rute bawaan (default route), kami merekomendasikan kamu untuk menambahkan rute IP sehingga alamat-alamat klaster Kubernetes melewati adaptor yang tepat.

Membuat iptables melihat bridged traffic

Agar iptables pada Node Linux dapat melihat bridged traffic dengan benar, kamu harus memastikan net.bridge.bridge-nf-call-iptables bernilai 1 pada pengaturan sysctl, misalnya.

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

Pastikan modul br_netfilter sudah dimuat sebelum melakukan langkah ini. Hal ini dilakukan dengan menjalankan lsmod | grep br_netfilter. Untuk memuatnya secara eksplisit gunakan sudo modprobe br_netfilter.

Untuk detail lebih lanjut, silakan lihat laman Persyaratan Plugin Jaringan.

Memeriksa porta yang dibutuhkan

Node control-plane

Node pekerja (worker)

† Jangkauan porta bawaan untuk Service NodePort.

Angka porta yang ditandai dengan * dapat diganti (overrideable), sehingga kamu harus memastikan porta khusus lainnya yang kamu sediakan juga terbuka.

Meskipun porta etcd turut dituliskan pada Node control-plane, kamu juga bisa menghos klaster etcd-mu sendiri secara eksternal atau pada porta custom.

Plugin jaringan Pod yang kamu gunakan (lihat di bawah) juga mungkin membutuhkan porta tertentu untuk terbuka. Karena hal ini dapat berbeda pada setiap plugin jaringan Pod, silakan lihat dokumentasi plugin mengenai porta yang dibutuhkan.

Menginstal runtime

Untuk menjalankan Container pada Pod, Kubernetes menggunakan _runtime_ Container.

• Linux nodes
• sistem operasi lainnya

Menginstal kubeadm, kubelet, dan kubectl

Kamu akan menginstal package berikut pada semua mesinmu:

• kubeadm: alat untuk mem-bootstrap klaster.

• kubelet: komponen yang berjalan pada seluruh mesin pada klaster dan memiliki tugas seperti menjalankan Pod dan Container.

• kubectl: alat untuk berinteraksi dengan klastermu.

Alat kubeadm tidak akan menginstal atau mengelola kubelet ataupun kubectl untukmu, jadi kamu harus memastikan keduanya memiliki versi yang cocok dengan control plane Kubernetes yang akan kamu instal dengan kubeadm. Jika tidak, ada risiko version skew yang dapat terjadi dan dapat berujung pada perangai yang bermasalah dan tidak terduga. Namun, satu version skew minor antara kubelet dan control plane masih diperbolehkan, tetapi versi kubelet tidak boleh melebihi versi API Server. Sebagai contoh, kubelet yang berjalan pada versi 1.7.0 akan kompatibel dengan API Server versi 1.8.0, tetapi tidak sebaliknya.

Untuk informasi mengenai instalasi kubectl, lihat Menginstal dan mengatur kubectl.

Untuk informasi lebih lanjut mengenai version skew, lihat:

• Kebijakan version-skew dan versi Kubernetes
• Kebijakan version skew yang spesifik untuk kubeadm

• Ubuntu, Debian atau HypriotOS
• CentOS, RHEL atau Fedora
• Container Linux

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

# Mengatur SELinux menjadi permissive mode (menonaktifkannya secara efektif)
setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

systemctl enable --now kubelet

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

CRICTL_VERSION="v1.22.0"
ARCH="amd64"
mkdir -p /opt/bin
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"

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

RELEASE_VERSION="v0.2.7"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemctl enable --now kubelet

Sekarang kubelet akan melakukan restart setiap beberapa detik, sambil menunggu dalam kondisi crashloop sampai kubeadm memberikan instruksi yang harus dilakukan.

Mengonfigurasi driver cgroup yang digunakan oleh kubelet pada Node control-plane

Ketika menggunakan Docker, kubeadm akan mendeteksi secara otomatis driver cgroup untuk kubelet dan mengaturnya pada berkas /var/lib/kubelet/config.yaml pada saat runtime.

Jika kamu menggunakan CRI yang berbeda, kamu harus memodifikasi berkasnya dengan nilai cgroupDriver yang kamu gunakan, seperti berikut:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: <value>

Harap diperhatikan, kamu hanya perlu melakukannya jika driver cgroup dari CRI pilihanmu bukanlah cgroupfs, karena nilai tersebut merupakan nilai bawaan yang digunakan oleh kubelet.

Kamu harus melakukan restart pada kubelet:

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Deteksi driver cgroup secara otomatis untuk runtime Container lainnya seperti CRI-O dan containerd masih dalam proses pengembangan.

Penyelesaian masalah

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

Selanjutnya

• Menggunakan kubeadm untuk Membuat Sebuah Klaster

2.2.1.2 - 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.26.

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
• Cilium
• Contiv-VPP
• Kube-router
• Weave Net

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

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

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

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

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

• Untuk masalah kekutu (bug), kunjungi kubeadm GitHub issue tracker
• Untuk dukungan, kunjungi kanal Slack #kubeadm
• Kanal Slack umum pengembangan SIG Cluster Lifecycle: #sig-cluster-lifecycle
• SIG Cluster Lifecycle SIG information
• Milis SIG Cluster Lifecycle: kubernetes-sig-cluster-lifecycle

Kebijakan version skew

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

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

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

• Kebijakan versi and version-skew Kubernetes
• Panduan instalasi spesifik untuk kubeadm

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.

2.2.1.3 - Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm

Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm:

• Dengan Node control plane yang bertumpuk (stacked). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node control plane diletakkan pada tempat yang sama (co-located).
• Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node control plane dan anggota etcd berada pada tempat yang berbeda.

Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan environment-mu. Topik perbandingan berikut menguraikan kelebihan dan kekurangan dari masing-masing pendekatan.

Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik pada pelacak isu kubeadm.

Lihat juga dokumentasi pembaruan.

Sebelum kamu memulai

Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut:

• Tiga mesin yang memenuhi kebutuhan minimum kubeadm untuk Node control plane
• Tiga mesin yang memenuhi kebutuhan minimum kubeadm untuk Node worker
• Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi)
• Hak akses sudo pada seluruh mesin
• Akses SSH dari satu perangkat ke seluruh Node pada sistem
• Perkakas kubeadm dan kubelet diinstal pada seluruh mesin. Perkakas kubectl bersifat opsional.

Untuk klaster etcd eksternal saja, kamu juga membutuhkan:

• Tiga mesin tambahan untuk anggota-anggota etcd

Langkah pertama untuk kedua metode

Membuat load balancer untuk kube-apiserver

1. Buat sebuah load balancer kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS.

   • Pada environment cloud kamu harus meletakkan Node control plane di belakang load balancer yang meneruskan TCP. Load balancer ini mendistribusikan trafik ke seluruh Node control plane pada daftar tujuan. Health check untuk apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver (nilai semula :6443).

   • Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada environment cloud.

   • Load balancer harus dapat berkomunikasi dengan seluruh Node control plane pada porta yang digunakan apiserver. Load balancer tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya.

   • Pastikan alamat load balancer sesuai dengan alamat ControlPlaneEndpoint pada kubeadm.

   • Baca panduan Opsi untuk Software Load Balancing untuk detail lebih lanjut.

2. Tambahkan Node control plane pertama pada load balancer dan lakukan pengujian koneksi:

   nc -v LOAD_BALANCER_IP PORT
   

   • Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum berjalan. Namun jika mendapat timeout, berarti load balancer tidak dapat berkomunikasi dengan Node control plane. Jika terjadi timeout, lakukan pengaturan ulang pada load balancer agar dapat berkomunikasi dengan Node control plane.

3. Tambahkan Node control plane lainnya pada grup tujuan load balancer.

Node control plane dan etcd bertumpuk (stacked)

Langkah-langkah untuk Node control plane pertama

1. Inisialisasi control plane:

   sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
   

   • Kamu bisa menggunakan opsi --kubernetes-version untuk mengatur versi Kubernetes yang akan digunakan. Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama.

   • Opsi --control-plane-endpoint harus diatur menuju alamat atau DNS dan porta dari load balancer.

   • Opsi --upload-certs digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh Node control plane pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke seluruh Node control plane sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian Distribusi sertifikat manual di bawah.

   Catatan: Opsi --config dan --certificate-key pada kubeadm init tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan konfigurasi kubeadm kamu harus menambahkan field certificateKey pada lokasi pengaturan yang sesuai (berada di bawah InitConfiguration dan JoinConfiguration: controlPlane).
   Catatan: Beberapa plugin jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak. Lihat dokumentasi jaringan CNI. Untuk menambahkan CIDR Pod, tambahkan opsi --pod-network-cidr, atau jika kamu menggunakan berkas konfigurasi kubeadm pasang field podSubnet di bawah objek networking dari ClusterConfiguration.

   • Keluaran yang dihasilkan terlihat seperti berikut ini:

     ...
     You can now join any number of control-plane node by running the following command on each as a root:
         kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
     
     Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
     As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
     
     Then you can join any number of worker nodes by running the following on each as root:
         kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
     

   • Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node control plane dan worker ke klaster.

   • Ketika opsi --upload-certs digunakan dengan kubeadm init, sertifikat dari control plane utama akan dienkripsi dan diunggah ke Secret kubeadm-certs.

   • Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node control plane yang sudah tergabung pada klaster:

     sudo kubeadm init phase upload-certs --upload-certs
     

   • Kamu juga dapat menentukan --certificate-key custom pada saat init yang nanti dapat digunakan pada saat join. Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut:

     kubeadm alpha certs certificate-key
     

   Catatan: Secret kubeadm-certs dan kunci dekripsi akan kadaluarsa setelah dua jam.
   Perhatian: Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya!

2. Pasang plugin CNI pilihanmu: Ikuti petunjuk berikut untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan.

   Pada contoh berikut kami menggunakan Weave Net:

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

3. Tulis perintah berikut dan saksikan Pod komponen-komponen control plane mulai dinyalakan:

   kubectl get pod -n kube-system -w
   

Langkah-langkah selanjutnya untuk Node control plane

Untuk setiap Node control plane kamu harus:

1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran kubeadm init pada Node pertama. Perintah tersebut terlihat seperti ini:

   sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
   

   • Opsi --control-plane menunjukkan kubeadm join untuk membuat control plane baru.
   • Opsi --certificate-key ... akan membuat sertifikat control plane diunduh dari Secret kubeadm-certs pada klaster dan didekripsi menggunakan kunci yang diberikan.

Node etcd eksternal

Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd pada berkas konfigurasi kubeadm.

Memasang klaster etcd

1. Ikuti petunjuk berikut untuk membangun klaster etcd.

2. Lakukan pengaturan SSH seperti yang dijelaskan di sini.

3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node control plane pertama:

   export CONTROL_PLANE="ubuntu@10.0.0.7"
   scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
   

   • Ganti nilai CONTROL_PLANE dengan user@host dari mesin control plane pertama.

Mengatur Node control plane pertama

1. Buat sebuah berkas bernama kubeadm-config.yaml dengan konten sebagai berikut:

   apiVersion: kubeadm.k8s.io/v1beta2
   kind: ClusterConfiguration
   kubernetesVersion: stable
   controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
   etcd:
       external:
           endpoints:
           - https://ETCD_0_IP:2379
           - https://ETCD_1_IP:2379
           - https://ETCD_2_IP:2379
           caFile: /etc/kubernetes/pki/etcd/ca.crt
           certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
           keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
   

• Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu:

- `LOAD_BALANCER_DNS`
- `LOAD_BALANCER_PORT`
- `ETCD_0_IP`
- `ETCD_1_IP`
- `ETCD_2_IP`

Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk:

1. Jalankan sudo kubeadm init --config kubeadm-config.yaml --upload-certs pada Node ini.

2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti.

3. Pasang plugin CNI pilihanmu. Contoh berikut ini untuk Weave Net:

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

Langkah selanjutnya untuk Node control plane lainnya

Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk:

• Pastikan Node control plane pertama sudah diinisialisasi dengan sempurna.
• Gabungkan setiap Node control plane dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk menggabungkan Node control plane satu persatu.
• Jangan lupakan bahwa kunci dekripsi dari --certificate-key akan kadaluarsa setelah dua jam, pada pengaturan semula.

Tugas-tugas umum setelah menyiapkan control plane

Menginstal worker

Node worker bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya dari keluaran perintah kubeadm init:

sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

Distribusi sertifikat manual

Jika kamu memilih untuk tidak menggunakan kubeadm init dengan opsi --upload-certs berarti kamu harus menyalin sertifikat dari Node control plane utama secara manual ke Node control plane yang akan bergabung.

Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan ssh dan scp:

SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin.

1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada sistem:

   eval $(ssh-agent)
   

2. Tambahkan identitas SSH milikmu ke dalam sesi:

   ssh-add ~/.ssh/path_to_private_key
   

3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik.

   • Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi -A:

     ssh -A 10.0.0.7
     

   • Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan environment yang ada sehingga penerusan SSH dapat bekerja dengan baik:

     sudo -E -s
     

4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node control plane pertama setelah menjalankan kubeadm init. Skrip ini akan menyalin sertifikat dari Node control plane pertama ke Node control plane lainnya:

   Pada contoh berikut, ganti CONTROL_PLANE_IPS dengan alamat IP dari Node control plane lainnya.

   USER=ubuntu # dapat disesuaikan
   CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
   for host in ${CONTROL_PLANE_IPS}; do
       scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
       # Kutip baris berikut jika kamu menggunakan etcd eksternal
       scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
   done
   

   Perhatian: Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya dengan SANs yang dibutuhkan untuk Node control plane yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja, pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan.

5. Lalu, pada setiap Node control plane yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan kubeadm join. Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori home ke /etc/kubernetes/pki:

   USER=ubuntu # dapat disesuaikan
   mkdir -p /etc/kubernetes/pki/etcd
   mv /home/${USER}/ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/ca.key /etc/kubernetes/pki/
   mv /home/${USER}/sa.pub /etc/kubernetes/pki/
   mv /home/${USER}/sa.key /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
   mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
   # Kutip baris berikut jika kamu menggunakan etcd eksternal
   mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
   

3 - Praktek-praktek Terbaik

3.1 - Menjalankan klaster dalam beberapa zona

Laman ini menjelaskan tentang bagaimana menjalankan sebuah klaster dalam beberapa zona.

Pendahuluan

Kubernetes 1.2 menambahkan dukungan untuk menjalankan sebuah klaster dalam beberapa zona kegagalan (multiple failure zones) (GCE secara sederhana menyebutnya sebagai "zones", AWS menyebutnya sebagai "availability zones", dan di sini kita akan menyebutnya sebagai "zona"). Fitur ini adalah versi sederhana dari fitur federasi klaster yang lebih luas (yang sebelumnya ditujukan pada sebuah nama panggilan yang ramah (affectionate nickname) "Ubernetes"). Federasi klaster yang penuh memungkinkan untuk menggabungkan klaster Kubernetes terpisah, yang berjalan pada wilayah atau penyedia cloud yang berbeda (baik dalam datacenter atau on-premise). Namun banyak pengguna yang ingin menjalankan klaster Kubernetes dengan tingkat ketersediaan yang lebih, dalam beberapa zona dari satu penyedia cloud mereka, dan dukungan inilah yang akhirnya memperbolehkan fitur multi-zona dalam versi Kubernetes 1.2 (sebelumnya fitur ini dikenal dengan nama panggilan "Ubernetes Lite").

Dukungan multi-zona sengaja dibuat terbatas: dimana satu klaster Kubernetes hanya dapat berjalan dalam beberapa zona, tetapi hanya pada wilayah yang sama (dan penyedia cloud yang sama pula). Hanya GCE dan AWS yang saat ini mendukung fitur ini secara otomatis (meskipun cukup mudah untuk menambahkan dukungan serupa untuk penyedia cloud yang lain atau bahkan untuk perangkat baremetal, hanya dengan mengatur label yang sesuai untuk ditambahkan ke Node dan volume).

Fungsionalitas

Ketika Node mulai dijalankan, kubelet secara otomatis menambahkan label informasi pada Node tersebut.

Kubernetes akan menyebarkan Pod secara otomatis dalam sebuah controller replikasi atau Service lintas Node dalam sebuah klaster zona tunggal (untuk mengurangi dampak kegagalan). Dengan klaster multi-zona, perilaku penyebaran ini akan dilanjutkan hingga melintasi zona (untuk mengurangi dampak kegagalan dalam satu zona.) (Ini dicapai melalui opsi SelectorSpreadPriority). Hal tersebut adalah untuk upaya penempatan terbaik, apabila zona pada klaster kamu bersifat heterogen (mis. jumlah Node yang berbeda, tipe Node yang berbeda, atau persyaratan sumber daya Pod yag berbeda), yang akan mencegah dengan sempurna penyebaran Pod kamu untuk melintasi zona yang berbeda. Jika diinginkan, kamu bisa menggunakan zona yang homogen (jumlah dan jenis Node yang sama) untuk mengurangi probabilitas penyebaran yang tidak merata.

Pada saat volume persisten dibuat, controller penerima PersistentVolumeLabel akan secara otomatis menambahkan label zona pada volume tersebut. Penjadwal (melalui predikat VolumeZonePredicate) kemudian akan memastikan bahwa Pod yang mengklaim suatu volume hanya akan ditempatkan pada zona yang sama dengan volume tersebut, karena volume tidak dapat di-attach melintasi zona yang berbeda.

Batasan

Ada beberapa batasan penting dari dukungan multi-zona:

• Kami berasumsi bahwa zona yang berbeda terletak secara berdekatan satu sama lain dalam jaringan, jadi kami tidak melakukan routing yang sadar akan zona. Secara khusus, lalu lintas (traffic) yang berjalan melalui Service mungkin melintasi beberapa zona (bahkan ketika beberapa Pod yang mendukung Service itu berada pada zona yang sama dengan klien), dan hal ini dapat menimbulkan latensi dan biaya tambahan.

• Volume zone-afinity hanya akan bekerja dengan PersistentVolume, dan tidak akan berfungsi apabila kamu secara langsung menentukan volume EBS dalam spesifikasi Pod (misalnya).

• Klaster tidak dapat melebarkan jangkauan cloud atau region (fungsi ini akan membutuhkan dukungan penuh federasi).

• Meskipun Node kamu berada dalam beberapa zona, saat ini kube-up hanya membuat satu Node master secara bawaan (default). Karena Service memerlukan ketersediaan (availability) yang tinggi dan dapat mentolerir akan hilangnya sebuah zona, maka control plane diletakkan pada setiap zona. Pengguna yang menginginkan control plane yang memiliki ketersediaan tinggi harus mengikuti instruksi ketersediaan tinggi.

Batasan Volume

Batasan berikut ditunjukkan dengan menggunakan pengikatan volume yang sadar topologi.

• Penyebaran zona volume StatefulSet yang menggunakan penyediaan secara dinamis, saat ini tidak sesuai dengan kebijakan afinitas atau anti-afinitas Pod.

• Jika nama StatefulSet berisi tanda hubung ("-"), maka penyebaran zona volume mungkin saja tidak menyediakan distribusi penyimpanan (storage) yang seragam di seluruh zona yang berbeda.

• Ketika menentukan beberapa PVC dalam spesifikasi Deployment atau Pod, StorageClass perlu dikonfigurasi untuk zona tunggal tertentu, atau PV perlu disediakan secara statis pada zona tertentu. Solusi lainnya adalah menggunakan sebuah StatefulSet, yang akan memastikan bahwa semua volume untuk sebuah replika disediakan dalam zona yang sama.

Panduan

Kita sekarang akan berjalan melalui pengaturan dan menggunakan multi-zona klaster pada GCE & AWS. Untuk melakukannya, kamu perlu mengaktifkan klaster penuh (dengan menentukan MULTIZONE=true), dan kemudian kamu menambahkan Node di zona tambahan dengan menjalankan kube-up lagi (dengan menetapkan opsi KUBE_USE_EXISTING_MASTER=true).

Mengaktifkan klaster kamu

Buatlah klaster seperti biasa, tetapi teruskan opsi MULTIZONE untuk memberi tahu klaster untuk mengelola beberapa zona; dan membuat Node di zona us-central1-a.

GCE:

curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash

AWS:

curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash

Langkah ini akan mengaktifkan klaster seperti biasa, namun masih berjalan dalam satu zona (tetapi opsi MULTIZONE=true telah mengaktifkan kapabilitas multi-zona).

Node yang telah diberi label

Lihatlah Node; dimana kamu bisa melihat Node tersebut diberi label sesuai dengan informasi zona. Node tersebut sejauh ini berada di zona us-central1-a (GCE) atau zona us-west-2a (AWS). Label dari Node itu adalah failure-domain.beta.kubernetes.io/region untuk informasi wilayah, dan failure-domain.beta.kubernetes.io/zone untuk informasi zona:

kubectl get nodes --show-labels

Tampilan akan seperti dibawah ini:

NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q

Menambah lebih banyak Node di zona kedua

Mari kita tambahkan sekumpulan Node ke dalam klaster yang ada, dengan menggunakan kembali master yang ada, namun dijalankan pada zona yang berbeda (zona us-central1-b atau zona us-west-2b). Kemudian kita jalankan kube-up lagi, tetapi dengan menentukan opsi KUBE_USE_EXISTING_MASTER=true sehingga kube-up tidak akan membuat master baru, tetapi akan menggunakan kembali master yang dibuat sebelumnya.

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh

Pada AWS, kita juga perlu menentukan CIDR jaringan sebagai tambahan subnet, bersama dengan alamat IP internal dari master:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

Lihat lagi Node; dimana 3 Node lainnya harus sudah dijalankan dan ditandai berada di us-central1-b:

kubectl get nodes --show-labels

Hasil tampilan akan terlihat seperti dibawah ini:

NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i

Afinitas Volume

Buatlah sebuah volume dengan menggunakan pembuatan volume yang dinamis (hanya PersistentVolume yang didukung untuk afinitas zona):

kubectl apply -f - <<EOF
{
  "apiVersion": "v1",
  "kind": "PersistentVolumeClaim",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.alpha.kubernetes.io/storage-class": "foo"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "5Gi"
      }
    }
  }
}
EOF

Sekarang marilah kita memvalidasi bahwa Kubernetes secara otomatis memberikan label zona & wilayah di mana PV itu dibuat.

kubectl get pv --show-labels

Hasil tampilan akan terlihat seperti dibawah ini:

NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a

Kemudian sekarang kita akan membuat Pod yang menggunakan klaim akan volume persisten. Karena volume pada GCE PDs / AWS EBS tidak dapat di-attach melewati zona yang berbeda, hal ini berarti bahwa Pod ini hanya dapat dibuat pada zona yang sama dengan volume tersebut:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: claim1
EOF

Perhatikan bahwa Pod secara otomatis dibuat pada zona yang sama dengan volume, karena pada umumnya lampiran lintas zona tidak diizinkan oleh penyedia cloud:

kubectl describe pod mypod | grep Node

Node:        kubernetes-minion-9vlv/10.240.0.5

Kemudian cek label Node:

kubectl get node kubernetes-minion-9vlv --show-labels

NAME                     STATUS    AGE    VERSION          LABELS
kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv

Pod yang tersebar melintasi zona yang berbeda

Pod dalam controller atau Service replikasi tersebar secara otomatis melintasi zona yang berbeda. Pertama-tama, mari kita luncurkan lebih banyak Node di zona ketiga:

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh

AWS:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

Pastikan bahwa kamu mempunyai Node dalam 3 zona berbeda:

kubectl get nodes --show-labels

Buatlah contoh dengan program guestbook-go, yang mencakup RC dengan ukuran 3, dan menjalankan sebuah aplikasi web sederhana:

find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}

Beberapa Pod seharusnya tersebar di ketiga zona semuanya:

kubectl describe pod -l app=guestbook | grep Node

Node:        kubernetes-minion-9vlv/10.240.0.5
Node:        kubernetes-minion-281d/10.240.0.8
Node:        kubernetes-minion-olsh/10.240.0.11

kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels

NAME                     STATUS    ROLES    AGE    VERSION          LABELS
kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh

Load-balancer menjangkau semua zona dalam satu klaster; program contoh guestbook-go sudah termasuk contoh Service dengan beban seimbang (load-balanced service):

kubectl describe service guestbook | grep LoadBalancer.Ingress

Hasil tampilan akan terlihat seperti di bawah ini:

LoadBalancer Ingress:   130.211.126.21

Atur alamat IP di atas:

export IP=130.211.126.21

Telusurilah dengan curl melalui alamat IP tersebut:

curl -s http://${IP}:3000/env | grep HOSTNAME

Hasil tampilan akan terlihat seperti di bawah ini:

  "HOSTNAME": "guestbook-44sep",

Kemudian, telusurilah beberapa kali:

(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq

Hasil tampilan akan terlihat seperti dibawah ini:

  "HOSTNAME": "guestbook-44sep",
  "HOSTNAME": "guestbook-hum5n",
  "HOSTNAME": "guestbook-ppm40",

Load balancer telah menargetkan ke semua Pod dengan benar, meskipun semuanya berada di beberapa zona yang berbeda.

Menghentikan Klaster

Shutting down the cluster

Apabila kamu sudah selesai, maka bersihkanlah:

GCE:

KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh

AWS:

KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh