Menyebarkan kubernetes HA dengan contenterd

Selamat siang, para pembaca Habr! Pada 24 Mei 2018, sebuah artikel berjudul Kubernetes Containerd Integration Goes GA diterbitkan di blog resmi Kubernetes, yang menyatakan bahwa integrasierdengan Kubernetes siap diproduksi. Juga, orang-orang dari perusahaan Flant memposting terjemahan artikel ke dalam bahasa Rusia di blog mereka, menambahkan sedikit klarifikasi dari diri mereka sendiri. Setelah membaca dokumentasi proyek di github , saya memutuskan untuk mencoba memuat di "kulit saya sendiri."
Perusahaan kami memiliki beberapa proyek dalam tahap "masih sangat jauh dari produksi." Jadi mereka akan menjadi eksperimen kami; untuk mereka, kami memutuskan untuk mencoba menggunakan kluster failover Kubernet menggunakan contenterd dan melihat apakah ada kehidupan tanpa buruh pelabuhan.
Jika Anda tertarik untuk melihat bagaimana kami melakukannya dan apa yang terjadi, selamat datang di kucing.
Deskripsi skematis dan penerapan

Ketika menggunakan cluster, seperti biasa, (saya menulis tentang ini di artikel sebelumnya
keepalived - implementasi VRRP (Virtual Router Redundancy Protocol) untuk LinuxKeepalived menciptakan IP virtual (VIRTIP) yang "menunjuk" (membuat subinterface) ke IP salah satu dari tiga master. Daemon keepalived memantau kesehatan mesin dan, jika terjadi kegagalan, mengecualikan server yang gagal dari daftar server aktif dengan mengalihkan VIRTIP ke IP server lain, sesuai dengan "bobot" yang ditentukan ketika mengkonfigurasi keepalived di setiap server.
Daemon keepalived berkomunikasi melalui VRRP, saling mengirim pesan ke alamat 224.0.0.18.
Jika tetangga belum mengirim pesannya, maka setelah periode dia dianggap mati. Segera setelah server macet mulai mengirim pesannya ke jaringan, semuanya kembali ke tempatnya
Kami mengkonfigurasi pekerjaan dengan server API pada node kubernetes sebagai berikut.
Setelah menginstal cluster, konfigurasikan kube-proxy, ubah port dari 6443 menjadi 16443 (detail di bawah). Pada masing-masing master, nginx digunakan, yang berfungsi sebagai loadbalancer, mendengarkan pada port 16443 dan melakukan upstream dari ketiga master pada port 6443 (detail di bawah).
Skema ini telah mencapai peningkatan toleransi kesalahan menggunakan keepalived, serta menggunakan nginx, penyeimbangan antara server API pada penyihir telah tercapai.
Dalam artikel sebelumnya, saya menjelaskan penggunaan nginx dan etcd di buruh pelabuhan. Tetapi dalam kasus ini, kita tidak memiliki buruh pelabuhan, jadi nginx dan etcd akan bekerja secara lokal pada masternodes.
Secara teoritis, adalah mungkin untuk menggunakan nginx dan lain-lain menggunakan contenterd, tetapi jika ada masalah pendekatan ini akan mempersulit diagnosis, jadi kami memutuskan untuk tidak bereksperimen dan menjalankannya secara lokal.
Deskripsi server untuk ditempatkan:
Nama | IP | Layanan |
---|
VIRTIP | 172.26.133.160 | ------ |
kubus-master01 | 172.26.133.161 | kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived |
kubus-master02 | 172.26.133.162 | kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived |
kubus-master03 | 172.26.133.163 | kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived |
kubus-simpul01 | 172.26.133.164 | kubeadm, kubelet, kubectl, mengandungerd |
kubus-simpul02 | 172.26.133.165 | kubeadm, kubelet, kubectl, mengandungerd |
kubus-simpul03 | 172.26.133.166 | kubeadm, kubelet, kubectl, mengandungerd |
Instal kubeadm, kubelet, kubectl dan paket terkait
Semua perintah dijalankan dari root
sudo -i
apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl unzip tar apt-transport-https btrfs-tools libseccomp2 socat util-linux mc vim keepalived
Instal conteinerd

cd / wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-1.1.0-rc.0.linux-amd64.tar.gz tar -xvf cri-containerd-1.1.0-rc.0.linux-amd64.tar.gz
Mengkonfigurasi konfigurasi yang berisi
mkdir -p /etc/containerd nano /etc/containerd/config.toml
Tambahkan ke file:
[plugins.cri] enable_tls_streaming = true
Kami mulai conteinerd kami memeriksa bahwa semuanya OK
systemctl enable containerd systemctl start containerd systemctl status containerd β containerd.service - containerd container runtime Loaded: loaded (/etc/systemd/system/containerd.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2018-06-25 12:32:01 MSK; 7s ago Docs: https://containerd.io Process: 10725 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS) Main PID: 10730 (containerd) Tasks: 15 (limit: 4915) Memory: 14.9M CPU: 375ms CGroup: /system.slice/containerd.service ββ10730 /usr/local/bin/containerd Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Get image filesystem path "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=error msg="Failed to load cni during init, please check CRI plugin status before setting up network for pods" error="cni con Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="loading plugin "io.containerd.grpc.v1.introspection"..." type=io.containerd.grpc.v1 Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start subscribing containerd event" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start recovering state" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg=serving... address="/run/containerd/containerd.sock" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="containerd successfully booted in 0.308755s" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start event monitor" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start snapshots syncer" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start streaming server"
Instal dan jalankan etcd
Catatan penting, saya menginstal kubernetes versi 1.10. Hanya beberapa hari kemudian, ketika menulis artikel, versi 1.11 dirilis. Jika Anda menginstal versi 1.11, maka atur variabel ETCD_VERSION = "v3.2.17", jika 1.10 maka ETCD_VERSION = "v3.1.12".
export ETCD_VERSION="v3.1.12" curl -sSL https://github.com/coreos/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz | tar -xzv --strip-components=1 -C /usr/local/bin/
Salin konfigurasi dari gitahab.
git clone https://github.com/rjeka/k8s-containerd.git cd k8s-containerd
Konfigurasikan variabel dalam file konfigurasi.
vim create-config.sh
Deskripsi variabel file create-config.sh
pengaturan pada mesin lokal setiap node (masing-masing node memiliki sendiri)
K8SHA_IPLOCAL - alamat IP dari node di mana skrip dikonfigurasi
K8SHA_ETCDNAME - nama mesin lokal di gugus ETCD
K8SHA_KA_STATE - peran dalam kenang - kenangan . Satu simpul MASTER, semua CADANGAN lainnya.
K8SHA_KA_PRIO - prioritas tetap, master memiliki 102 untuk 101, 100 yang tersisa. Ketika master dengan nomor 102 jatuh, node dengan nomor 101 mengambil tempat dan seterusnya.
K8SHA_KA_INTF - antarmuka jaringan keepalived. Nama antarmuka yang disimpan akan mendengarkan.
Pengaturan umum untuk semua masternode adalah sama:
K8SHA_IPVIRTUAL = 172.26.133.160 - IP virtual cluster.
K8SHA_IP1 ... K8SHA_IP3 - alamat IP master
K8SHA_HOSTNAME1 ... K8SHA_HOSTNAME3 - nama host untuk masternodes. Poin penting, dengan nama-nama ini kubeadm akan menghasilkan sertifikat.
K8SHA_KA_AUTH - kata sandi untuk tetap disimpan . Anda dapat menentukan apa saja
K8SHA_TOKEN - klaster tanda. Dapat dihasilkan dengan perintah generate token kubeadm
K8SHA_CIDR - alamat subnet untuk perapian. Saya menggunakan flanel jadi CIDR 0.244.0.0/16. Pastikan untuk menyaring - dalam konfigurasi harus K8SHA_CIDR = 10.244.0.0 \ / 16
Jalankan skrip yang akan mengkonfigurasi nginx, keepalived, etcd dan kubeadmin
./create-config.sh
Kami mulai, dll.
dll saya angkat tanpa tls. Jika Anda memerlukan tls, maka dalam
dokumentasi kubernet resmi ditulis secara rinci cara membuat sertifikat untuk etcd.
systemctl daemon-reload && systemctl start etcd && systemctl enable etcd
Pemeriksaan Status
etcdctl cluster-health member ad059013ec46f37 is healthy: got healthy result from http://192.168.5.49:2379 member 4d63136c9a3226a1 is healthy: got healthy result from http://192.168.4.169:2379 member d61978cb3555071e is healthy: got healthy result from http://192.168.4.170:2379 cluster is healthy etcdctl member list ad059013ec46f37: name=hb-master03 peerURLs=http://192.168.5.48:2380 clientURLs=http://192.168.5.49:2379,http://192.168.5.49:4001 isLeader=false 4d63136c9a3226a1: name=hb-master01 peerURLs=http://192.168.4.169:2380 clientURLs=http://192.168.4.169:2379,http://192.168.4.169:4001 isLeader=true d61978cb3555071e: name=hb-master02 peerURLs=http://192.168.4.170:2380 clientURLs=http://192.168.4.170:2379,http://192.168.4.170:4001 isLeader=false
Jika semuanya baik-baik saja, lanjutkan ke langkah berikutnya.
Konfigurasikan kubeadmin
Jika Anda menggunakan kubeadm versi 1.11, Anda dapat melewati langkah ini
Agar kybernet mulai bekerja bukan dengan buruh pelabuhan, tetapi dengan contenterd, konfigurasikan konfigurasi kubeadmin
vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Setelah [Layanan] tambahkan baris ke blok
Environment="KUBELET_EXTRA_ARGS=--runtime-cgroups=/system.slice/containerd.service --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
Keseluruhan konfigurasi akan terlihat seperti ini: [Service] Environment="KUBELET_EXTRA_ARGS=--runtime-cgroups=/system.slice/containerd.service --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock" Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true" Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin" Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local" Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt" Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0" Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki" ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS
Jika Anda menginstal versi 1.11 dan ingin bereksperimen dengan CoreDNS alih-alih kube-dns dan menguji konfigurasi dinamis, batalkan komentar pada blok berikut di file konfigurasi kubeadm-init.yaml:
feature-gates: DynamicKubeletConfig: true CoreDNS: true
Mulai kembali kubelet
systemctl daemon-reload && systemctl restart kubelet
Inisialisasi panduan pertama
Sebelum memulai kubeadm, Anda harus memulai ulang keepalived dan memeriksa statusnya
systemctl restart keepalived.service systemctl status keepalived.service β keepalived.service - Keepalive Daemon (LVS and VRRP) Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-06-27 10:40:03 MSK; 1min 44s ago Process: 4589 ExecStart=/usr/sbin/keepalived $DAEMON_ARGS (code=exited, status=0/SUCCESS) Main PID: 4590 (keepalived) Tasks: 7 (limit: 4915) Memory: 15.3M CPU: 968ms CGroup: /system.slice/keepalived.service ββ4590 /usr/sbin/keepalived ββ4591 /usr/sbin/keepalived ββ4593 /usr/sbin/keepalived ββ5222 /usr/sbin/keepalived ββ5223 sh -c /etc/keepalived/check_apiserver.sh ββ5224 /bin/bash /etc/keepalived/check_apiserver.sh ββ5231 sleep 5
periksa apakah ping VIRTIP
ping -c 4 172.26.133.160 PING 172.26.133.160 (172.26.133.160) 56(84) bytes of data. 64 bytes from 172.26.133.160: icmp_seq=1 ttl=64 time=0.030 ms 64 bytes from 172.26.133.160: icmp_seq=2 ttl=64 time=0.050 ms 64 bytes from 172.26.133.160: icmp_seq=3 ttl=64 time=0.050 ms 64 bytes from 172.26.133.160: icmp_seq=4 ttl=64 time=0.056 ms --- 172.26.133.160 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3069ms rtt min/avg/max/mdev = 0.030/0.046/0.056/0.012 ms
Setelah itu, jalankan kubeadmin. Pastikan untuk menyertakan baris --skip-preflight-checking. Kubeadmin secara default mencari buruh pelabuhan dan tanpa melewati pemeriksaan akan gagal dengan kesalahan.
kubeadm init --config=kubeadm-init.yaml --skip-preflight-checks
Setelah kubeadm bekerja, simpan baris yang dihasilkan. Ini akan diperlukan untuk memasukkan node yang bekerja ke dalam cluster.
kubeadm join 172.26.133.160:6443 --token XXXXXXXXXXXXXXXXXXXXXXXXX --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Selanjutnya, tunjukkan di mana file admin.conf disimpan
Jika kita bekerja sebagai root, maka:
vim ~/.bashrc export KUBECONFIG=/etc/kubernetes/admin.conf source ~/.bashrc
Untuk pengguna sederhana, ikuti instruksi di layar.
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
Tambahkan 2 penyihir lagi ke cluster. Untuk melakukan ini, salin sertifikat dari kube-master01 ke kube-master02 dan kube-master03 ke direktori / etc / kubernetes /. Untuk melakukan ini, saya mengkonfigurasi akses ssh untuk root, dan setelah menyalin file, saya mengembalikan pengaturan.
scp -r /etc/kubernetes/pki 172.26.133.162:/etc/kubernetes/ scp -r /etc/kubernetes/pki 172.26.133.163:/etc/kubernetes/
Setelah menyalin ke kube-master02 dan kube-master03, jalankan.
kubeadm init --config=kubeadm-init.yaml --skip-preflight-checks
Instal flanel CIDR
pada eksekusi kube-master01
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml
Versi flanel saat ini dapat ditemukan di dokumentasi kubernetes .
Kami menunggu sampai semua wadah dibuat.
watch -n1 kubectl get pods --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE kube-system kube-apiserver-kube-master01 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-apiserver-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-apiserver-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-controller-manager-kube-master01 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-controller-manager-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-controller-manager-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-dns-86f4d74b45-8c24s 3/3 Running 0 17m 10.244.2.2 kube-master03 kube-system kube-flannel-ds-4h4w7 1/1 Running 0 2m 172.26.133.163 kube-master03 kube-system kube-flannel-ds-kf5mj 1/1 Running 0 2m 172.26.133.162 kube-master02 kube-system kube-flannel-ds-q6k4z 1/1 Running 0 2m 172.26.133.161 kube-master01 kube-system kube-proxy-9cjtp 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-proxy-9sqk2 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-proxy-jg2pt 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-scheduler-kube-master01 1/1 Running 0 18m 172.26.133.161 kube-master01 kube-system kube-scheduler-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-scheduler-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03
Kami membuat replikasi kube-dns ke ketiga master
Pada kube-master01 jalankan
kubectl scale --replicas=3 -n kube-system deployment/kube-dns
Instal dan konfigurasikan nginx
Pada setiap master node, instal nginx sebagai penyeimbang untuk API Kubernetes
Saya memiliki semua mesin cluster di debian. Dari paket nginx, modul stream tidak mendukung, jadi tambahkan repositori nginx dan instal dari repositori nginx`a. Jika Anda memiliki OS yang berbeda, lihat dokumentasi nginx .
wget https://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key echo -e "\n#nginx\n\ deb http://nginx.org/packages/debian/ stretch nginx\n\ deb-src http://nginx.org/packages/debian/ stretch nginx" >> /etc/apt/sources.list apt-get update && apt-get install nginx -y
Buat nginx config (jika belum dibuat)
./create-config.sh
nginx.confpengguna nginx;
pekerja_proses otomatis;
peringatan error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
acara {
koneksi pekerja_1024;
}
http {
termasuk /etc/nginx/mime.types;
default_type application / octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf;
}
aliran {
apiserver hulu {
server 172.26.133.161:6443 weight = 5 max_fails = 3 fail_timeout = 30s;
server 172.26.133.162:6443 weight = 5 max_fails = 3 fail_timeout = 30s;
server 172.26.133.163:6443 weight = 5 max_fails = 3 fail_timeout = 30s;
} server { listen 16443; proxy_connect_timeout 1s; proxy_timeout 3s; proxy_pass apiserver; }
}
Kami memeriksa bahwa semuanya OK dan menerapkan konfigurasi
nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful systemctl restart nginx systemctl status nginx β nginx.service - nginx - high performance web server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-06-28 08:48:09 MSK; 22s ago Docs: http://nginx.org/en/docs/ Process: 22132 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID: 22133 (nginx) Tasks: 2 (limit: 4915) Memory: 1.6M CPU: 7ms CGroup: /system.slice/nginx.service ββ22133 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf ββ22134 nginx: worker process
Uji penyeimbang
curl -k https://172.26.133.161:16443 | wc -l % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 233 100 233 0 0 12348 0 --:--:-- --:--:-- --:--:-- 12944
Konfigurasikan kube-proxy untuk bekerja dengan penyeimbang
Setelah penyeimbang dikonfigurasi, edit port di pengaturan kubernetes.
kubectl edit -n kube-system configmap/kube-proxy
Ubah pengaturan server menjadi https://172.26.133.160:16443
Selanjutnya, Anda perlu mengonfigurasi kube-proxy untuk bekerja dengan port baru
kubectl get pods --all-namespaces -o wide | grep proxy kube-system kube-proxy-9cjtp 1/1 Running 1 22h 172.26.133.163 kube-master03 kube-system kube-proxy-9sqk2 1/1 Running 1 22h 172.26.133.161 kube-master01 kube-system kube-proxy-jg2pt 1/1 Running 4 22h 172.26.133.162 kube-
Kami menghapus semua pod, setelah dihapus, pod tersebut dibuat ulang secara otomatis dengan pengaturan baru
kubectl delete pod -n kube-system kube-proxy-XXX ```bash . ```bash kubectl get pods --all-namespaces -o wide | grep proxy kube-system kube-proxy-hqrsw 1/1 Running 0 33s 172.26.133.161 kube-master01 kube-system kube-proxy-kzvw5 1/1 Running 0 47s 172.26.133.163 kube-master03 kube-system kube-proxy-zzkz5 1/1 Running 0 7s 172.26.133.162 kube-master02
Menambahkan node kerja ke cluster
Pada setiap catatan root, jalankan perintah yang dihasilkan oleh kubeadm
kubeadm join 172.26.133.160:6443 --token XXXXXXXXXXXXXXXXXXXXXXXXX --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --cri-socket /run/containerd/containerd.sock --skip-preflight-checks
Jika garis "hilang", maka Anda harus membuat yang baru
kubeadm token generate kubeadm token create <generated-token> --print-join-command --ttl=0
Pada node yang berfungsi di file /etc/kubernetes/bootstrap-kubelet.conf dan /etc/kubernetes/kubelet.conf
nilai variabel server untuk virtip kami
vim /etc/kubernetes/bootstrap-kubelet.conf server: https://172.26.133.60:16443 vim /etc/kubernetes/kubelet.conf server: https://172.26.133.60:16443
Dan mulai ulang contenterd dan kubernetes
systemctl restart containerd kubelet
Instalasi dasbor
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
Buat pengguna dengan hak istimewa admin:
kubectl apply -f kube-dashboard/dashboard-adminUser.yaml
Kami mendapatkan token untuk masuk:
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')
Mengonfigurasi akses dasbor melalui NodePort di VIRTIP
kubectl -n kube-system edit service kubernetes-dashboard
Kami mengganti nilai tipe: ClusterIP dengan tipe: NodePort dan di bagian port: tambahkan nilai nodePort: 30000 (atau port di kisaran 30000 hingga 32000 tempat Anda ingin panel dapat diakses):

Panel sekarang tersedia di https: // VIRTIP: 30000
Heapster
Selanjutnya, instal Heapster, alat untuk mendapatkan metrik komponen kluster.
Instalasi:
git clone https://github.com/kubernetes/heapster.git cd heapster kubectl create -f deploy/kube-config/influxdb/ kubectl create -f deploy/kube-config/rbac/heapster-rbac.yaml
Kesimpulan
Saya tidak melihat adanya masalah khusus ketika bekerja dengan contenterd. Suatu ketika ada kesalahan yang tidak bisa dipahami dengan perapian setelah penyebaran dihapus. Kubernetes percaya bahwa di bawah telah dihapus, tetapi di bawah menjadi "zombie" aneh. Masih ada di node, tetapi dalam status diperpanjang.
Saya percaya bahwa Containerd lebih berorientasi sebagai runtime wadah untuk kubernetes. Kemungkinan besar, di masa depan, sebagai lingkungan untuk meluncurkan layanan microser di Kubernetes, adalah mungkin dan perlu untuk menggunakan lingkungan yang berbeda yang akan diorientasikan untuk berbagai tugas, proyek, dll.
Proyek ini berkembang sangat cepat. Alibaba Cloud telah mulai secara aktif menggunakan conatinerd dan menekankan bahwa itu adalah lingkungan yang ideal untuk menjalankan kontainer.
Menurut pengembang, integrasi contenterd di platform cloud Google Kubernetes sekarang setara dengan integrasi Docker.
Contoh yang bagus dari utilitas konsol crictl . Saya juga akan memberikan beberapa contoh dari cluster yang dibuat:
kubectl describe nodes | grep "Container Runtime Version:"

CLI Docker tidak memiliki konsep dasar Kubernetes, misalnya, pod dan namespace, sementara crictl mendukung konsep-konsep ini
crictl pods

Dan jika perlu, kita bisa melihat wadah dalam format yang biasa, seperti buruh pelabuhan
crictl ps

Kita bisa melihat gambar yang ada di node
crictl images

Ternyata, hidup tanpa buruh pelabuhan adalah :)
Masih terlalu dini untuk berbicara tentang bug dan gangguan, cluster telah bekerja bersama kami selama sekitar satu minggu. Dalam waktu dekat tes akan ditransfer ke sana, dan jika berhasil, kemungkinan besar berdiri dev salah satu proyek. Ada ide tentang ini untuk menulis serangkaian artikel yang mencakup proses DevOps, seperti: membuat cluster, mengatur pengontrol masuknya dan memindahkannya ke node yang terpisah dari cluster, mengotomasi perakitan gambar, memeriksa gambar untuk kerentanan, penyebaran, dll. Sementara itu, kita akan melihat stabilitas pekerjaan, mencari bug dan mengembangkan produk baru.
Juga, manual ini cocok untuk menggunakan gugus failover dengan buruh pelabuhan, Anda hanya perlu menginstal buruh pelabuhan sesuai dengan instruksi dari dokumentasi Kubernet resmi dan lewati langkah-langkah untuk menginstal contenterd dan mengkonfigurasi konfigurasi kubeadm.
Atau Anda dapat menempatkan contenterd dan buruh pelabuhan secara bersamaan di host yang sama, dan, seperti yang dipastikan pengembang, mereka akan bekerja sama dengan sempurna. Containerd adalah lingkungan peluncuran container konbernetes, dan buruh pelabuhan seperti buruh pelabuhan)))

Repositori memiliki containerd
pedoman ansible untuk menginstal sebuah cluster dengan satu master. Tapi itu lebih menarik bagi saya untuk "meningkatkan" sistem dengan tangan saya untuk memahami secara lebih rinci konfigurasi setiap komponen dan memahami cara kerjanya dalam praktik.
Mungkin suatu hari nanti tangan saya akan mencapai, dan saya akan menulis buku pedoman saya untuk menyebarkan sebuah cluster dengan HA, karena selama enam bulan terakhir saya telah menggunakan mereka selama lebih dari selusin dan mungkin akan menjadi waktu untuk mengotomatiskan proses.
Juga, saat menulis artikel ini, versi kubernetes 1.11 dirilis. Anda dapat membaca tentang perubahan utama di blog Flant atau di blog kubernet resmi . Kami memperbarui gugus uji ke versi 1.11 dan mengganti kube-dns dengan CoreDNS. Selain itu, kami menyertakan fungsi DynamicKubeletConfig untuk menguji kemampuan pembaruan dinamis konfigurasi.
Bahan yang digunakan:
Terima kasih sudah membaca sampai akhir.
Karena informasi tentang kubernetes, terutama pada cluster yang beroperasi dalam kondisi nyata, sangat langka di RuNet, indikasi ketidakakuratan diterima, seperti komentar pada skema penyebaran cluster umum. Saya akan mencoba untuk memperhitungkannya dan membuat koreksi yang tepat. Dan saya selalu siap untuk menjawab pertanyaan di komentar, di githab dan di jejaring sosial apa pun yang ditunjukkan di profil saya.
Hormat kami, Eugene.