ປະສົບການຂອງພວກເຮົາທີ່ເຮັດວຽກກັບຂໍ້ມູນໃນ etcd Kubernetes cluster ໂດຍກົງ (ໂດຍບໍ່ມີ K8s API)

ເພີ່ມຂຶ້ນ, ລູກຄ້າກໍາລັງຂໍໃຫ້ພວກເຮົາສະຫນອງການເຂົ້າເຖິງກຸ່ມ Kubernetes ເພື່ອສາມາດເຂົ້າເຖິງການບໍລິການພາຍໃນກຸ່ມ: ເພື່ອສາມາດເຊື່ອມຕໍ່ໂດຍກົງກັບບາງຖານຂໍ້ມູນຫຼືການບໍລິການ, ການເຊື່ອມຕໍ່ແອັບພລິເຄຊັນທ້ອງຖິ່ນກັບແອັບພລິເຄຊັນພາຍໃນກຸ່ມ ...

ຕົວຢ່າງ, ມີຄວາມຕ້ອງການທີ່ຈະເຊື່ອມຕໍ່ຈາກເຄື່ອງທ້ອງຖິ່ນຂອງທ່ານໄປຫາບໍລິການ memcached.staging.svc.cluster.local. ພວກເຮົາສະຫນອງຄວາມສາມາດນີ້ໂດຍໃຊ້ VPN ພາຍໃນກຸ່ມທີ່ລູກຄ້າເຊື່ອມຕໍ່. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາປະກາດ subnets ຂອງ pods, ບໍລິການແລະ push cluster DNS ກັບລູກຄ້າ. ດັ່ງນັ້ນ, ເມື່ອລູກຄ້າພະຍາຍາມເຊື່ອມຕໍ່ກັບການບໍລິການ memcached.staging.svc.cluster.local, ການຮ້ອງຂໍໄປຫາ DNS cluster ແລະໃນການຕອບສະຫນອງໄດ້ຮັບທີ່ຢູ່ຂອງບໍລິການນີ້ຈາກເຄືອຂ່າຍບໍລິການ cluster ຫຼືທີ່ຢູ່ pod.

ພວກເຮົາກຳນົດຄ່າກຸ່ມ K8s ໂດຍໃຊ້ kubeadm, ບ່ອນທີ່ເຄືອຂ່າຍຍ່ອຍບໍລິການເລີ່ມຕົ້ນຢູ່ 192.168.0.0/16, ແລະເຄືອຂ່າຍຂອງຝັກແມ່ນ 10.244.0.0/16. ປົກກະຕິແລ້ວທຸກສິ່ງທຸກຢ່າງເຮັດວຽກໄດ້ດີ, ແຕ່ມີສອງສາມຈຸດ:

• ເຄືອຂ່າຍຍ່ອຍ 192.168.*.* ມັກຈະໃຊ້ໃນເຄືອຂ່າຍຫ້ອງການລູກຄ້າ, ແລະຫຼາຍກວ່ານັ້ນມັກຈະຢູ່ໃນເຄືອຂ່າຍບ້ານຂອງຜູ້ພັດທະນາ. ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ຮັບຄວາມຂັດແຍ້ງ: ເຣົາເຕີໃນເຮືອນເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍຍ່ອຍນີ້ແລະ VPN ຍູ້ເຄືອຂ່າຍຍ່ອຍເຫຼົ່ານີ້ຈາກກຸ່ມໄປຫາລູກຄ້າ.
• ພວກເຮົາມີຫຼາຍກຸ່ມ (ການຜະລິດ, ຂັ້ນຕອນ ແລະ/ຫຼືກຸ່ມນັກພັດທະນາຫຼາຍກຸ່ມ). ຫຼັງຈາກນັ້ນ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ພວກມັນທັງຫມົດຈະມີ subnets ດຽວກັນສໍາລັບ pods ແລະການບໍລິການ, ເຊິ່ງສ້າງຄວາມຫຍຸ້ງຍາກຫຼາຍສໍາລັບການເຮັດວຽກພ້ອມໆກັນກັບການບໍລິການໃນຫຼາຍໆກຸ່ມ.

ພວກເຮົາໄດ້ຮັບຮອງເອົາການປະຕິບັດຂອງການນໍາໃຊ້ subnets ທີ່ແຕກຕ່າງກັນສໍາລັບການບໍລິການແລະ pods ພາຍໃນໂຄງການດຽວກັນ - ໂດຍທົ່ວໄປ, ເພື່ອໃຫ້ກຸ່ມທັງຫມົດມີເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ. ຢ່າງໃດກໍຕາມ, ມີຈໍານວນຫລາຍຂອງກຸ່ມປະຕິບັດງານທີ່ຂ້ອຍບໍ່ຢາກຈະມ້ວນຈາກຈຸດເລີ່ມຕົ້ນ, ຍ້ອນວ່າພວກເຂົາດໍາເນີນການບໍລິການຫຼາຍ, ຄໍາຮ້ອງສະຫມັກຂອງລັດ, ແລະອື່ນໆ.

ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ຖາມຕົວເອງວ່າ: ວິທີການປ່ຽນ subnet ໃນ cluster ທີ່ມີຢູ່ແລ້ວ?

ຄົ້ນຫາການຕັດສິນໃຈ

ການປະຕິບັດທົ່ວໄປທີ່ສຸດແມ່ນການສ້າງໃຫມ່ ທັງ​ຫມົດ ການບໍລິການທີ່ມີປະເພດ ClusterIP. ເປັນທາງເລືອກ, ສາມາດໃຫ້ຄໍາແນະນໍາ ແລະນີ້:

ຂະບວນການຕໍ່ໄປນີ້ມີບັນຫາ: ຫຼັງຈາກທຸກສິ່ງທຸກຢ່າງຖືກຕັ້ງຄ່າ, ຝັກຈະມາກັບ IP ເກົ່າເປັນ DNS nameserver ໃນ /etc/resolv.conf.
ເນື່ອງຈາກຂ້ອຍຍັງບໍ່ພົບທາງອອກ, ຂ້ອຍຕ້ອງຕັ້ງກຸ່ມທັງໝົດດ້ວຍ kubeadm reset ແລະ init ມັນອີກຄັ້ງ.

ແຕ່ນີ້ບໍ່ເຫມາະສົມສໍາລັບທຸກຄົນ ... ນີ້ແມ່ນການແນະນໍາລາຍລະອຽດເພີ່ມເຕີມສໍາລັບກໍລະນີຂອງພວກເຮົາ:

• Flannel ຖືກນໍາໃຊ້;
• ມີກຸ່ມທັງຢູ່ໃນຄລາວ ແລະໃນຮາດແວ;
• ຂ້ອຍຢາກຫຼີກເວັ້ນການນຳໃຊ້ບໍລິການທັງໝົດໃນກຸ່ມຄືນໃໝ່;
• ໂດຍທົ່ວໄປແລ້ວມີຄວາມຈໍາເປັນທີ່ຈະເຮັດທຸກສິ່ງທຸກຢ່າງທີ່ມີຈໍານວນຕໍາ່ສຸດທີ່ຂອງບັນຫາ;
• ລຸ້ນ Kubernetes ແມ່ນ 1.16.6 (ຢ່າງໃດກໍຕາມ, ຂັ້ນຕອນຕໍ່ໄປຈະຄ້າຍຄືກັນກັບລຸ້ນອື່ນໆ);
• ວຽກງານຕົ້ນຕໍແມ່ນເພື່ອຮັບປະກັນວ່າຢູ່ໃນກຸ່ມທີ່ນໍາໃຊ້ kubeadm ກັບເຄືອຂ່າຍຍ່ອຍບໍລິການ 192.168.0.0/16, ແທນທີ່ດ້ວຍ 172.24.0.0/16.

ແລະມັນເກີດຂຶ້ນຫຼາຍທີ່ພວກເຮົາສົນໃຈຢາກເຫັນສິ່ງທີ່ຢູ່ໃນ Kubernetes ຖືກເກັບໄວ້ໃນ etcd, ສິ່ງທີ່ສາມາດເຮັດໄດ້ກັບມັນ ... ດັ່ງນັ້ນພວກເຮົາຄິດວ່າ: "ເປັນຫຍັງບໍ່ພຽງແຕ່ປັບປຸງຂໍ້ມູນໃນ etcd, ແທນທີ່ທີ່ຢູ່ IP ເກົ່າ (subnet) ດ້ວຍອັນໃຫມ່? »

ມີການຄົ້ນຫາເຄື່ອງມືທີ່ກຽມພ້ອມສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນໃນ etcd, ພວກເຮົາບໍ່ພົບສິ່ງທີ່ແກ້ໄຂບັນຫາຢ່າງສົມບູນ. (ໂດຍວິທີທາງການ, ຖ້າທ່ານຮູ້ກ່ຽວກັບຜົນປະໂຫຍດໃດໆສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນໂດຍກົງໃນ etcd, ພວກເຮົາຈະຊື່ນຊົມກັບການເຊື່ອມຕໍ່.) ຢ່າງໃດກໍຕາມ, ຈຸດເລີ່ມຕົ້ນທີ່ດີແມ່ນ ແລະ ອື່ນໆ ຈາກ OpenShift (ຂໍ​ຂອບ​ໃຈ​ຜູ້​ຂຽນ​ຂອງ​ຕົນ​!).

ຜົນປະໂຫຍດນີ້ສາມາດເຊື່ອມຕໍ່ກັບ etcd ໂດຍໃຊ້ໃບຢັ້ງຢືນແລະອ່ານຂໍ້ມູນຈາກນັ້ນໂດຍໃຊ້ຄໍາສັ່ງ ls, get, dump.

ເພີ່ມ etcdhelper

ຄວາມຄິດຕໍ່ໄປແມ່ນມີເຫດຜົນ: "ແມ່ນຫຍັງທີ່ຂັດຂວາງເຈົ້າຈາກການເພີ່ມປະໂຫຍດນີ້ໂດຍການເພີ່ມຄວາມສາມາດໃນການຂຽນຂໍ້ມູນໃສ່ etcd?"

ມັນໄດ້ກາຍເປັນສະບັບດັດແກ້ຂອງ etcdhelper ດ້ວຍສອງຫນ້າທີ່ໃຫມ່ changeServiceCIDR и changePodCIDR. ສຸດຂອງນາງ ທ່ານສາມາດເບິ່ງລະຫັດ ທີ່ນີ້.

ຄຸນສົມບັດໃໝ່ເຮັດຫຍັງແດ່? ສູດການຄິດໄລ່ changeServiceCIDR:

• ສ້າງ deserializer ເປັນ;
• ລວບລວມການສະແດງອອກປົກກະຕິເພື່ອທົດແທນ CIDR;
• ພວກເຮົາຜ່ານການບໍລິການທັງຫມົດທີ່ມີປະເພດ ClusterIP ໃນກຸ່ມ:
  • ຖອດລະຫັດຄ່າຈາກ etcd ເຂົ້າໄປໃນວັດຖຸ Go;
  • ການນໍາໃຊ້ການສະແດງອອກປົກກະຕິພວກເຮົາແທນສອງ bytes ທໍາອິດຂອງທີ່ຢູ່;
  • ມອບໝາຍໃຫ້ການບໍລິການທີ່ຢູ່ IP ຈາກເຄືອຂ່າຍຍ່ອຍໃໝ່;
  • ສ້າງ serializer, ປ່ຽນວັດຖຸ Go ເປັນ protobuf, ຂຽນຂໍ້ມູນໃຫມ່ເປັນ etcd.

ການທໍາງານຂອງ changePodCIDR ຄ້າຍຄືກັນ changeServiceCIDR - ພຽງແຕ່ແທນທີ່ຈະແກ້ໄຂຂໍ້ກໍານົດການບໍລິການ, ພວກເຮົາເຮັດມັນສໍາລັບ node ແລະການປ່ຽນແປງ .spec.PodCIDR ກັບເຄືອຂ່າຍຍ່ອຍໃຫມ່.

ການປະຕິບັດ

ປ່ຽນບໍລິການ CIDR

ແຜນການຈັດຕັ້ງປະຕິບັດວຽກງານແມ່ນງ່າຍດາຍຫຼາຍ, ແຕ່ມັນກ່ຽວຂ້ອງກັບການຢຸດເວລາໃນເວລາຂອງການສ້າງຝັກທັງຫມົດໃນກຸ່ມ. ຫຼັງຈາກການອະທິບາຍຂັ້ນຕອນຕົ້ນຕໍ, ພວກເຮົາຍັງຈະແບ່ງປັນຄວາມຄິດກ່ຽວກັບວິທີການ, ໃນທາງທິດສະດີ, ການຢຸດເຮັດວຽກນີ້ສາມາດຫຼຸດຜ່ອນລົງໄດ້.

ຂັ້ນ​ຕອນ​ການ​ກະ​ກຽມ​:

• ການຕິດຕັ້ງຊອບແວທີ່ຈໍາເປັນແລະການປະກອບ etcdhelper patched;
• backup etcd ແລະ /etc/kubernetes.

ແຜນປະຕິບັດງານສັ້ນໆສໍາລັບການປ່ຽນແປງການບໍລິການCIDR:

• ການປ່ຽນແປງ apiserver ແລະ controller-manager manifests;
• ການອອກໃບຢັ້ງຢືນ;
• ການປ່ຽນແປງການບໍລິການ ClusterIP ໃນ etcd;
• ຣີສະຕາດຂອງຝັກທັງໝົດໃນກຸ່ມ.

ຕໍ່​ໄປ​ນີ້​ແມ່ນ​ເປັນ​ລໍາ​ດັບ​ທີ່​ສົມ​ບູນ​ຂອງ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ລະ​ອຽດ​.

1. ຕິດຕັ້ງ etcd-client ສໍາລັບການ dump ຂໍ້ມູນ:

apt install etcd-client

2. ສ້າງ ແລະ ອື່ນໆ:

• ການ​ຕິດ​ຕັ້ງ golang​:

  GOPATH=/root/golang
  mkdir -p $GOPATH/local
  curl -sSL https://dl.google.com/go/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH/local
  echo "export GOPATH="$GOPATH"" >> ~/.bashrc
  echo 'export GOROOT="$GOPATH/local/go"' >> ~/.bashrc
  echo 'export PATH="$PATH:$GOPATH/local/go/bin"' >> ~/.bashrc

• ພວກເຮົາປະຫຍັດສໍາລັບຕົວເຮົາເອງ etcdhelper.go, ດາວໂຫຼດການເພິ່ງພາອາໄສ, ເກັບກໍາ:

  wget https://raw.githubusercontent.com/flant/examples/master/2020/04-etcdhelper/etcdhelper.go
  go get go.etcd.io/etcd/clientv3 k8s.io/kubectl/pkg/scheme k8s.io/apimachinery/pkg/runtime
  go build -o etcdhelper etcdhelper.go

3. ເຮັດ backup etcd:

backup_dir=/root/backup
mkdir ${backup_dir}
cp -rL /etc/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --endpoints https://192.168.199.100:2379 snapshot save ${backup_dir}/etcd.snapshot

4. ປ່ຽນເຄືອຂ່າຍຍ່ອຍບໍລິການໃນເຄື່ອງຄວບຄຸມ Kubernetes manifests. ໃນໄຟລ໌ /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml ປ່ຽນພາລາມິເຕີ --service-cluster-ip-range ໄປຫາເຄືອຂ່າຍຍ່ອຍໃໝ່: 172.24.0.0/16 ແທນທີ່ຈະ 192.168.0.0/16.

5. ເນື່ອງຈາກພວກເຮົາກໍາລັງປ່ຽນເຄືອຂ່າຍຍ່ອຍບໍລິການທີ່ kubeadm ອອກໃບຢັ້ງຢືນສໍາລັບ apiserver (ລວມທັງ), ເຂົາເຈົ້າຈໍາເປັນຕ້ອງໄດ້ອອກໃຫມ່:

1. ໃຫ້ເບິ່ງວ່າໂດເມນ ແລະທີ່ຢູ່ IP ໃດທີ່ໃບຮັບຮອງປະຈຸບັນໄດ້ຖືກອອກໃຫ້:

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

2. ໃຫ້ກະກຽມ config ຫນ້ອຍທີ່ສຸດສໍາລັບ kubeadm:

   cat kubeadm-config.yaml
   apiVersion: kubeadm.k8s.io/v1beta1
   kind: ClusterConfiguration
   networking:
     podSubnet: "10.244.0.0/16"
     serviceSubnet: "172.24.0.0/16"
   apiServer:
     certSANs:
     - "192.168.199.100" # IP-адрес мастер узла

3. ໃຫ້ລຶບ crt ແລະລະຫັດເກົ່າ, ເພາະວ່າຖ້າບໍ່ມີໃບຮັບຮອງໃຫມ່ຈະບໍ່ຖືກອອກ:

   rm /etc/kubernetes/pki/apiserver.{key,crt}

4. ມາອອກໃບຮັບຮອງໃໝ່ສຳລັບເຊີບເວີ API:

   kubeadm init phase certs apiserver --config=kubeadm-config.yaml

5. ໃຫ້ກວດເບິ່ງວ່າໃບຮັບຮອງໄດ້ຖືກອອກໃຫ້ສໍາລັບ subnet ໃຫມ່:

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

6. ຫຼັງ​ຈາກ​ການ​ອອກ​ໃບ​ຢັ້ງ​ຢືນ​ເຄື່ອງ​ແມ່​ຂ່າຍ API ຄືນ​ໃຫມ່​, restart container ຂອງ​ຕົນ​:

   docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

7. ໃຫ້ພວກເຮົາສ້າງ config ສໍາລັບ admin.conf:

   kubeadm alpha certs renew admin.conf

8. ມາແກ້ໄຂຂໍ້ມູນໃນ etcd:

   ./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-service-cidr 172.24.0.0/16 

   ລະ​ມັດ​ລະ​ວັງ ໃນເວລານີ້, ການແກ້ໄຂໂດເມນຢຸດເຮັດວຽກຢູ່ໃນກຸ່ມ, ນັບຕັ້ງແຕ່ຢູ່ໃນຝັກທີ່ມີຢູ່ /etc/resolv.conf ທີ່ຢູ່ CoreDNS ເກົ່າ (kube-dns) ຖືກລົງທະບຽນ, ແລະ kube-proxy ປ່ຽນກົດລະບຽບ iptables ຈາກ subnet ເກົ່າໄປຫາອັນໃຫມ່. ເພີ່ມເຕີມໃນບົດຄວາມມັນຖືກຂຽນກ່ຽວກັບທາງເລືອກທີ່ເປັນໄປໄດ້ເພື່ອຫຼຸດຜ່ອນເວລາຢຸດເຮັດວຽກ.

9. ໃຫ້ແກ້ໄຂ ConfigMap ໃນ namespace kube-system:

   kubectl -n kube-system edit cm kubelet-config-1.16

   - ແທນ​ທີ່​ນີ້​ clusterDNS ໄປຫາທີ່ຢູ່ IP ໃຫມ່ຂອງບໍລິການ kube-dns: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - ພວກ​ເຮົາ​ຈະ​ແກ້​ໄຂ​ມັນ​ data.ClusterConfiguration.networking.serviceSubnet ກັບເຄືອຂ່າຍຍ່ອຍໃຫມ່.

10. ເນື່ອງຈາກທີ່ຢູ່ kube-dns ມີການປ່ຽນແປງ, ມັນຈໍາເປັນຕ້ອງໄດ້ປັບປຸງການຕັ້ງຄ່າ kubelet ໃນທຸກ nodes:

    kubeadm upgrade node phase kubelet-config && systemctl restart kubelet

11. ທັງໝົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອຣີສະຕາດພອດທັງໝົດໃນກຸ່ມ:

    kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'

ຫຼຸດເວລາຢຸດເຮັດວຽກ

ຄວາມ​ຄິດ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ຫຼຸດ​ຜ່ອນ​ການ​ຢຸດ​ເຊົາ​ການ​:

1. ຫຼັງຈາກການປ່ຽນແປງຍົນຄວບຄຸມ manifests, ສ້າງການບໍລິການ kube-dns ໃຫມ່, ສໍາລັບການຍົກຕົວຢ່າງ, ມີຊື່ kube-dns-tmp ແລະທີ່ຢູ່ໃໝ່ 172.24.0.10.
2. ເຮັດໃຫ້ if ໃນ etcdhelper, ເຊິ່ງຈະບໍ່ດັດແປງການບໍລິການ kube-dns.
3. ທົດແທນທີ່ຢູ່ໃນ kubelets ທັງຫມົດ ClusterDNS ກັບອັນໃຫມ່, ໃນຂະນະທີ່ການບໍລິການເກົ່າຈະສືບຕໍ່ເຮັດວຽກພ້ອມໆກັນກັບອັນໃຫມ່.
4. ລໍຖ້າຈົນກ່ວາຝັກທີ່ມີຄໍາຮ້ອງສະຫມັກມ້ວນຜ່ານດ້ວຍຕົນເອງສໍາລັບເຫດຜົນທໍາມະຊາດຫຼືໃນເວລາທີ່ຕົກລົງ.
5. ລຶບການບໍລິການ kube-dns-tmp ແລະການປ່ຽນແປງ serviceSubnetCIDR ສໍາລັບການບໍລິການ kube-dns.

ແຜນການນີ້ຈະຊ່ວຍໃຫ້ທ່ານຫຼຸດຜ່ອນເວລາຢຸດເຮັດວຽກໃຫ້ໜ້ອຍສຸດເປັນ ~ ນາທີ - ສໍາລັບໄລຍະເວລາຂອງການກໍາຈັດການບໍລິການ kube-dns-tmp ແລະການປ່ຽນແປງ subnet ສໍາລັບການບໍລິການ kube-dns.

ການ​ດັດ​ແກ້ podNetwork​

ໃນເວລາດຽວກັນ, ພວກເຮົາໄດ້ຕັດສິນໃຈເບິ່ງວິທີການດັດແປງ podNetwork ໂດຍໃຊ້ etcdhelper ຜົນໄດ້ຮັບ. ລໍາດັບຂອງການປະຕິບັດແມ່ນດັ່ງຕໍ່ໄປນີ້:

• ການແກ້ໄຂ configs ໃນ kube-system;
• ແກ້ໄຂ manifest kube-controller-manager;
• ປ່ຽນ podCIDR ໂດຍກົງໃນ etcd;
• reboot nodes cluster ທັງໝົດ.

ໃນປັດຈຸບັນເພີ່ມເຕີມກ່ຽວກັບການປະຕິບັດເຫຼົ່ານີ້:

1. ແກ້ໄຂ ConfigMap ໃນ namespace kube-system:

kubectl -n kube-system edit cm kubeadm-config

- ການ​ແກ້​ໄຂ​ data.ClusterConfiguration.networking.podSubnet ກັບເຄືອຂ່າຍຍ່ອຍໃຫມ່ 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- ການ​ແກ້​ໄຂ​ data.config.conf.clusterCIDR: 10.55.0.0/16.

2. ແກ້ໄຂ manifest ຂອງຜູ້ຄວບຄຸມ-ຜູ້ຈັດການ:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

- ການ​ແກ້​ໄຂ​ --cluster-cidr=10.55.0.0/16.

3. ເບິ່ງຄ່າປັດຈຸບັນ .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses ສໍາລັບທຸກ nodes cluster:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. ແທນທີ່ podCIDR ໂດຍການປ່ຽນແປງໂດຍກົງກັບ etcd:

./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-pod-cidr 10.55.0.0/16

5. ໃຫ້ກວດເບິ່ງວ່າ podCIDR ມີການປ່ຽນແປງແທ້ໆ:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. ໃຫ້ reboot nodes cluster ທັງໝົດເທື່ອລະອັນ.

7. ຖ້າທ່ານອອກຈາກຢ່າງຫນ້ອຍຫນຶ່ງ node podCIDR ເກົ່າ, ຫຼັງຈາກນັ້ນ kube-controller-manager ຈະບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້, ແລະ pods ໃນ cluster ຈະບໍ່ຖືກກໍານົດ.

ໃນຄວາມເປັນຈິງ, ການປ່ຽນແປງ podCIDR ສາມາດເຮັດໄດ້ງ່າຍກວ່າ (ຕົວຢ່າງ, ສະນັ້ນ). ແຕ່ພວກເຮົາຕ້ອງການຮຽນຮູ້ວິທີການເຮັດວຽກກັບ etcd ໂດຍກົງ, ເພາະວ່າມີກໍລະນີທີ່ແກ້ໄຂວັດຖຸ Kubernetes ໃນ etcd - ດຽວ ຕົວແປທີ່ເປັນໄປໄດ້. (ຕົວຢ່າງ, ທ່ານບໍ່ສາມາດພຽງແຕ່ປ່ຽນພາກສະຫນາມການບໍລິການໂດຍບໍ່ມີການຢຸດເວລາ spec.clusterIP.)

ຜົນໄດ້ຮັບ

ບົດຄວາມສົນທະນາກ່ຽວກັບຄວາມເປັນໄປໄດ້ຂອງການເຮັດວຽກກັບຂໍ້ມູນໃນ etcd ໂດຍກົງ, i.e. ຂ້າມ Kubernetes API. ບາງຄັ້ງວິທີການນີ້ຊ່ວຍໃຫ້ທ່ານເຮັດ "ສິ່ງທີ່ຫຍຸ້ງຍາກ". ພວກເຮົາໄດ້ທົດສອບການປະຕິບັດທີ່ໃຫ້ຢູ່ໃນຂໍ້ຄວາມຢູ່ໃນກຸ່ມ K8s ທີ່ແທ້ຈິງ. ຢ່າງໃດກໍ່ຕາມ, ສະຖານະພາບຄວາມພ້ອມຂອງພວກເຂົາສໍາລັບການນໍາໃຊ້ຢ່າງກວ້າງຂວາງແມ່ນ PoC (ຫຼັກຖານສະແດງແນວຄວາມຄິດ). ດັ່ງນັ້ນ, ຖ້າທ່ານຕ້ອງການໃຊ້ສະບັບດັດແກ້ຂອງ utility etcdhelper ໃນກຸ່ມຂອງທ່ານ, ໃຫ້ເຮັດແນວນັ້ນດ້ວຍຄວາມສ່ຽງຂອງທ່ານເອງ.

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «etcd 3.4.3: ການສຶກສາຄວາມຫນ້າເຊື່ອຖືແລະຄວາມປອດໄພຂອງການເກັບຮັກສາ"
• «Calico ສໍາລັບເຄືອຂ່າຍໃນ Kubernetes: ການແນະນໍາແລະປະສົບການເລັກນ້ອຍ"
• «6 ແມງໄມ້ລະບົບທີ່ຫນ້າສົນໃຈເມື່ອໃຊ້ Kubernetes [ແລະການແກ້ໄຂຂອງມັນ]"
• «ຄູ່ມືສາຍຕາເພື່ອແກ້ໄຂບັນຫາ Kubernetes".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com