Kubernetes HA cluster dengan contenterd. Atau adakah kehidupan tanpa buruh pelabuhan?

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 Linux
Keepalived 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:


NamaIPLayanan
VIRTIP172.26.133.160------
kubus-master01172.26.133.161kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived
kubus-master02172.26.133.162kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived
kubus-master03172.26.133.163kubeadm, kubelet, kubectl, etcd, mengandungerd, nginx, keepalived
kubus-simpul01172.26.133.164kubeadm, kubelet, kubectl, mengandungerd
kubus-simpul02172.26.133.165kubeadm, kubelet, kubectl, mengandungerd
kubus-simpul03172.26.133.166kubeadm, 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
 #!/bin/bash # local machine ip address export K8SHA_IPLOCAL=172.26.133.161 # local machine etcd name, options: etcd1, etcd2, etcd3 export K8SHA_ETCDNAME=kube-master01 # local machine keepalived state config, options: MASTER, BACKUP. One keepalived cluster only one MASTER, other's are BACKUP export K8SHA_KA_STATE=MASTER # local machine keepalived priority config, options: 102, 101,100 MASTER must 102 export K8SHA_KA_PRIO=102 # local machine keepalived network interface name config, for example: eth0 export K8SHA_KA_INTF=ens18 ####################################### # all masters settings below must be same ####################################### # master keepalived virtual ip address export K8SHA_IPVIRTUAL=172.26.133.160 # master01 ip address export K8SHA_IP1=172.26.133.161 # master02 ip address export K8SHA_IP2=172.26.133.162 # master03 ip address export K8SHA_IP3=172.26.133.163 # master01 hostname export K8SHA_HOSTNAME1=kube-master01 # master02 hostname export K8SHA_HOSTNAME2=kube-master02 # master03 hostname export K8SHA_HOSTNAME3=kube-master03 # keepalived auth_pass config, all masters must be same export K8SHA_KA_AUTH=56cf8dd754c90194d1600c483e10abfr #etcd tocken: export ETCD_TOKEN=9489bf67bdfe1b3ae077d6fd9e7efefd # kubernetes cluster token, you can use 'kubeadm token generate' to get a new one export K8SHA_TOKEN=535tdi.utzk5hf75b04ht8l # kubernetes CIDR pod subnet, if CIDR pod subnet is "10.244.0.0/16" please set to "10.244.0.0\\/16" export K8SHA_CIDR=10.244.0.0\\/16 

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.conf

pengguna 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.

Source: https://habr.com/ru/post/id415601/


All Articles