បទពិសោធន៍របស់យើងជាមួយនឹងទិន្នន័យនៅក្នុង etcd Kubernetes cluster ដោយផ្ទាល់ (ដោយគ្មាន K8s API)

កាន់តែខ្លាំងឡើង អតិថិជនកំពុងស្នើសុំឱ្យយើងផ្តល់នូវការចូលប្រើចង្កោម Kubernetes ដើម្បីអាចចូលប្រើសេវាកម្មនៅក្នុងចង្កោម៖ ដើម្បីអាចភ្ជាប់ដោយផ្ទាល់ទៅមូលដ្ឋានទិន្នន័យ ឬសេវាកម្មមួយចំនួន ដើម្បីភ្ជាប់កម្មវិធីក្នុងស្រុកជាមួយកម្មវិធីនៅក្នុងចង្កោម...

ជាឧទាហរណ៍ មានតំរូវការក្នុងការតភ្ជាប់ពីម៉ាស៊ីនក្នុងស្រុករបស់អ្នកទៅកាន់សេវាកម្មមួយ។ memcached.staging.svc.cluster.local. យើងផ្តល់សមត្ថភាពនេះដោយប្រើ VPN នៅក្នុងចង្កោមដែលអតិថិជនភ្ជាប់។ ដើម្បី​ធ្វើ​ដូច្នេះ យើង​ប្រកាស​បណ្ដាញ​រង​នៃ​ផត, សេវា និង​រុញ DNS ចង្កោម​ទៅ​ម៉ាស៊ីន​ភ្ញៀវ។ ដូច្នេះនៅពេលដែលអតិថិជនព្យាយាមភ្ជាប់ទៅសេវាកម្ម memcached.staging.svc.cluster.localសំណើទៅកាន់ cluster DNS ហើយជាការឆ្លើយតប ទទួលបានអាសយដ្ឋាននៃសេវាកម្មនេះពីបណ្តាញសេវា cluster ឬអាសយដ្ឋាន pod ។

យើងកំណត់រចនាសម្ព័ន្ធក្រុម K8s ដោយប្រើ kubeadm ដែលបណ្តាញរងសេវាកម្មលំនាំដើមគឺ 192.168.0.0/16និងបណ្តាញនៃ pods គឺ 10.244.0.0/16. ជាធម្មតាអ្វីៗដំណើរការល្អ ប៉ុន្តែមានចំណុចមួយចំនួន៖

• បណ្តាញរង 192.168.*.* ជាញឹកញាប់ត្រូវបានគេប្រើនៅក្នុងបណ្តាញការិយាល័យអតិថិជន ហើយថែមទាំងជាញឹកញាប់នៅក្នុងបណ្តាញផ្ទះអ្នកអភិវឌ្ឍន៍។ ហើយបន្ទាប់មកយើងទទួលបានជម្លោះ៖ រ៉ោតទ័រនៅផ្ទះដំណើរការលើបណ្តាញរងនេះ ហើយ VPN រុញបណ្តាញរងទាំងនេះពីចង្កោមទៅម៉ាស៊ីនភ្ញៀវ។
• យើងមានចង្កោមជាច្រើន (ផលិតកម្ម ដំណាក់កាល និង/ឬចង្កោមអ្នកអភិវឌ្ឍន៍ជាច្រើន)។ បន្ទាប់មក តាមលំនាំដើម ពួកវាទាំងអស់នឹងមានបណ្តាញរងដូចគ្នាសម្រាប់ផត និងសេវាកម្ម ដែលបង្កើតការលំបាកយ៉ាងខ្លាំងសម្រាប់ការងារដំណាលគ្នាជាមួយសេវាកម្មនៅក្នុងចង្កោមជាច្រើន។

យើងបានអនុវត្តជាយូរមកហើយនូវការអនុវត្តនៃការប្រើប្រាស់បណ្តាញរងផ្សេងៗគ្នាសម្រាប់សេវាកម្ម និងផតនៅក្នុងគម្រោងដូចគ្នា - ជាទូទៅ ដូច្នេះចង្កោមទាំងអស់មានបណ្តាញផ្សេងៗគ្នា។ ទោះយ៉ាងណាក៏ដោយ មានចង្កោមមួយចំនួនធំដែលកំពុងដំណើរការ ដែលខ្ញុំមិនចង់រំកិលពីដំបូងឡើយ ចាប់តាំងពីពួកគេដំណើរការសេវាកម្មជាច្រើន កម្មវិធីដែលមានស្ថានភាពជាដើម។

ហើយបន្ទាប់មកយើងសួរខ្លួនយើងថា: របៀបផ្លាស់ប្តូរបណ្តាញរងនៅក្នុងចង្កោមដែលមានស្រាប់?

ការស្វែងរកការសម្រេចចិត្ត

ការអនុវត្តទូទៅបំផុតគឺការបង្កើតឡើងវិញ ទាំងអស់ សេវាកម្មដែលមានប្រភេទ ClusterIP ។ ជាជម្រើសមួយ អាចណែនាំ ហើយ​នេះ:

ដំណើរការខាងក្រោមមានបញ្ហា៖ បន្ទាប់ពីអ្វីៗបានកំណត់រចនាសម្ព័ន្ធ ផតឃែរមកជាមួយ IP ចាស់ជា DNS nameserver នៅក្នុង /etc/resolv.conf ។
ដោយសារខ្ញុំនៅតែរកមិនឃើញដំណោះស្រាយ ខ្ញុំត្រូវកំណត់ចង្កោមទាំងមូលឡើងវិញដោយប្រើ kubeadm reset ហើយបញ្ចូលវាម្តងទៀត។

ប៉ុន្តែ​នេះ​មិន​ស័ក្តិសម​សម្រាប់​អ្នក​រាល់​គ្នា​ទេ... នេះ​ជា​ការ​ណែនាំ​លម្អិត​បន្ថែម​ទៀត​សម្រាប់​ករណី​របស់​យើង៖

• Flannel ត្រូវបានប្រើ;
• មានចង្កោមទាំងនៅក្នុងពពក និងនៅលើផ្នែករឹង។
• ខ្ញុំចង់ជៀសវាងការដាក់ឱ្យប្រើប្រាស់ឡើងវិញនូវសេវាកម្មទាំងអស់នៅក្នុងចង្កោម។
• មានតម្រូវការជាទូទៅដើម្បីធ្វើអ្វីគ្រប់យ៉ាងជាមួយនឹងចំនួនអប្បបរមានៃបញ្ហា;
• កំណែ Kubernetes គឺ 1.16.6 (ទោះជាយ៉ាងណាក៏ដោយ ជំហានបន្ថែមទៀតនឹងស្រដៀងគ្នាសម្រាប់កំណែផ្សេងទៀត);
• ភារកិច្ចចម្បងគឺដើម្បីធានាថានៅក្នុងចង្កោមដែលបានដាក់ពង្រាយដោយប្រើ kubeadm ជាមួយបណ្តាញរងសេវាកម្ម 192.168.0.0/16ជំនួសវាដោយ 172.24.0.0/16.

ហើយ​វា​ទើបតែ​កើត​ឡើង​ជា​យូរ​មក​ហើយ​ដែល​យើង​ចាប់​អារម្មណ៍​ជា​យូរ​មក​ហើយ​ក្នុង​ការ​មើល​អ្វី​និង​របៀប​ដែល​នៅ​ក្នុង Kubernetes ត្រូវ​បាន​រក្សា​ទុក​នៅ​ក្នុង etcd អ្វី​ដែល​អាច​ធ្វើ​បាន​ជាមួយ​វា... ដូច្នេះ​យើង​គិត​ថា​៖ «ហេតុអ្វីមិនគ្រាន់តែធ្វើបច្ចុប្បន្នភាពទិន្នន័យនៅក្នុង etcd ដោយជំនួសអាសយដ្ឋាន IP ចាស់ (បណ្តាញរង) ជាមួយថ្មី។?

ដោយបានស្វែងរកឧបករណ៍ដែលត្រៀមរួចជាស្រេចសម្រាប់ធ្វើការជាមួយទិន្នន័យនៅក្នុង etcd យើងមិនបានរកឃើញអ្វីដែលអាចដោះស្រាយបញ្ហាបានទាំងស្រុងនោះទេ។ (ដោយវិធីនេះ ប្រសិនបើអ្នកដឹងអំពីឧបករណ៍ប្រើប្រាស់ណាមួយសម្រាប់ធ្វើការជាមួយទិន្នន័យដោយផ្ទាល់នៅក្នុង etcd យើងនឹងពេញចិត្តចំពោះតំណភ្ជាប់នេះ។ ) ទោះយ៉ាងណាក៏ដោយ ចំណុចចាប់ផ្តើមដ៏ល្អមួយគឺ etcdhelper ពី OpenShift (សូមអរគុណដល់អ្នកនិពន្ធ!).

ឧបករណ៍ប្រើប្រាស់នេះអាចភ្ជាប់ទៅ etcd ដោយប្រើវិញ្ញាបនបត្រ និងអានទិន្នន័យពីទីនោះដោយប្រើពាក្យបញ្ជា ls, get, dump.

បន្ថែម etdhelper

គំនិតបន្ទាប់គឺឡូជីខល៖ "តើអ្វីទៅដែលរារាំងអ្នកពីការបន្ថែមឧបករណ៍ប្រើប្រាស់នេះដោយបន្ថែមសមត្ថភាពក្នុងការសរសេរទិន្នន័យទៅ etd?"

វាបានក្លាយជាកំណែដែលបានកែប្រែរបស់ etcdhelper ជាមួយនឹងមុខងារថ្មីពីរ changeServiceCIDR и changePodCIDR. លើនាង អ្នកអាចឃើញលេខកូដ នៅទីនេះ.

តើមុខងារថ្មីធ្វើអ្វី? ក្បួនដោះស្រាយ changeServiceCIDR:

• បង្កើត deserializer មួយ;
• ចងក្រងកន្សោមធម្មតាដើម្បីជំនួស CIDR;
• យើងឆ្លងកាត់សេវាកម្មទាំងអស់ជាមួយនឹងប្រភេទ ClusterIP នៅក្នុងចង្កោម៖
  • ឌិកូដតម្លៃពី etcd ចូលទៅក្នុងវត្ថុ Go;
  • ដោយប្រើកន្សោមធម្មតា យើងជំនួសពីរបៃដំបូងនៃអាសយដ្ឋាន។
  • ផ្តល់សេវាកម្មអាសយដ្ឋាន IP ពីបណ្តាញរងថ្មី;
  • បង្កើត serializer បម្លែងវត្ថុ Go ទៅជា protobuf សរសេរទិន្នន័យថ្មីទៅជា ល។

មុខងារ changePodCIDR សំខាន់ស្រដៀងគ្នា changeServiceCIDR - ជំនួសឱ្យការកែសម្រួលការបញ្ជាក់សេវាកម្ម យើងធ្វើវាសម្រាប់ថ្នាំង និងការផ្លាស់ប្តូរ .spec.PodCIDR ទៅបណ្តាញរងថ្មី។

អនុវត្ត

ផ្លាស់ប្តូរសេវាកម្ម CIDR

ផែនការសម្រាប់ការអនុវត្តភារកិច្ចគឺសាមញ្ញណាស់ ប៉ុន្តែវាពាក់ព័ន្ធនឹងពេលវេលារងចាំនៅពេលនៃការបង្កើតឡើងវិញនូវផតទាំងអស់នៅក្នុងចង្កោម។ បន្ទាប់ពីការពិពណ៌នាអំពីជំហានសំខាន់ៗ យើងក៏នឹងចែករំលែកគំនិតអំពីរបៀបដែលតាមទ្រឹស្តី ពេលវេលារងចាំនេះអាចបង្រួមអប្បបរមា។

ជំហានត្រៀមរៀបចំ៖

• ដំឡើងកម្មវិធីចាំបាច់ និងដំឡើង patched etcdhelper;
• ការបម្រុងទុក ល។ និង /etc/kubernetes.

ផែនការសកម្មភាពសង្ខេបសម្រាប់ការផ្លាស់ប្តូរសេវាកម្មCIDR៖

• ការផ្លាស់ប្តូរ apiserver និង controller-manager manifests;
• ការចេញវិញ្ញាបនបត្រ;
• ការផ្លាស់ប្តូរសេវាកម្ម ClusterIP នៅក្នុង etcd;
• ចាប់ផ្តើមឡើងវិញនៃផតទាំងអស់នៅក្នុងចង្កោម។

ខាងក្រោម​នេះ​ជា​លំដាប់​សកម្មភាព​យ៉ាង​លម្អិត។

1. ដំឡើង etcd-client សម្រាប់ការបោះចោលទិន្នន័យ៖

apt install etcd-client

2. Build etdhelper:

• ដំឡើង 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 ជាដើម។

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. តោះរៀបចំការកំណត់អប្បបរមាសម្រាប់ 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. សូមពិនិត្យមើលថាវិញ្ញាបនបត្រត្រូវបានចេញសម្រាប់បណ្តាញរងថ្មី៖

   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 ឡើងវិញ សូមចាប់ផ្តើមកុងតឺន័ររបស់វាឡើងវិញ៖

   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's នៅក្នុង 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 នៅលើថ្នាំងទាំងអស់៖

    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 និងផ្លាស់ប្តូរបណ្តាញរងសម្រាប់សេវាកម្ម kube-dns.

ការកែប្រែ podNetwork

ក្នុងពេលជាមួយគ្នានេះ យើងបានសម្រេចចិត្តមើលពីរបៀបកែប្រែ podNetwork ដោយប្រើ etcdhelper លទ្ធផល។ លំដាប់នៃសកម្មភាពមានដូចខាងក្រោម៖

• ជួសជុលការកំណត់នៅក្នុង kube-system;
• ជួសជុលការបង្ហាញ Kube-controller-manager;
• ផ្លាស់ប្តូរ podCIDR ដោយផ្ទាល់នៅក្នុង etcd;
• ចាប់ផ្ដើមថ្នាំងចង្កោមទាំងអស់ឡើងវិញ។

ឥឡូវនេះបន្ថែមអំពីសកម្មភាពទាំងនេះ៖

1. កែប្រែ ConfigMap's ក្នុង 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 របស់ controller-manager៖

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

- ការកែតម្រូវ --cluster-cidr=10.55.0.0/16.

3. មើលតម្លៃបច្ចុប្បន្ន .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses សម្រាប់ថ្នាំងចង្កោមទាំងអស់៖

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. តោះចាប់ផ្តើមថ្នាំងចង្កោមទាំងអស់ឡើងវិញម្តងមួយៗ។

7. ប្រសិនបើអ្នកចាកចេញពីថ្នាំងយ៉ាងហោចណាស់មួយ។ podCIDR ចាស់បន្ទាប់មក kube-controller-manager នឹងមិនអាចចាប់ផ្តើមបានទេ ហើយ pods នៅក្នុង cluster នឹងមិនត្រូវបានកំណត់ពេលទេ។

តាមពិតការផ្លាស់ប្តូរ podCIDR អាចធ្វើបានកាន់តែសាមញ្ញ (ឧទាហរណ៍ ដូច្នេះ) ប៉ុន្តែយើងចង់រៀនពីរបៀបធ្វើការជាមួយ etcd ដោយផ្ទាល់ ពីព្រោះមានករណីជាច្រើននៅពេលកែសម្រួលវត្ថុ Kubernetes នៅក្នុង etcd - តែមួយគត់ វ៉ារ្យ៉ង់ដែលអាចធ្វើបាន។ (ឧទាហរណ៍ អ្នក​មិន​អាច​គ្រាន់​តែ​ផ្លាស់​ប្តូ​រ​វាល​សេវា​ដោយ​គ្មាន​ពេល​វេលា​ spec.clusterIP.)

លទ្ធផល

អត្ថបទពិភាក្សាអំពីលទ្ធភាពនៃការធ្វើការជាមួយទិន្នន័យនៅក្នុង etcd ដោយផ្ទាល់ i.e. ឆ្លងកាត់ Kubernetes API ។ ជួនកាលវិធីសាស្រ្តនេះអនុញ្ញាតឱ្យអ្នកធ្វើ "រឿងពិបាក" ។ យើងបានសាកល្បងប្រតិបត្តិការដែលបានផ្តល់ឱ្យនៅក្នុងអត្ថបទនៅលើចង្កោម K8s ពិតប្រាកដ។ ទោះជាយ៉ាងណាក៏ដោយស្ថានភាពនៃការត្រៀមខ្លួនរបស់ពួកគេសម្រាប់ការប្រើប្រាស់យ៉ាងទូលំទូលាយគឺ PoC (ភស្តុតាងនៃគំនិត). ដូច្នេះ ប្រសិនបើអ្នកចង់ប្រើកំណែដែលបានកែប្រែនៃឧបករណ៍ប្រើប្រាស់ etcdhelper នៅលើចង្កោមរបស់អ្នក ធ្វើដូច្នេះដោយហានិភ័យផ្ទាល់ខ្លួនរបស់អ្នក។

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «etcd 3.4.3៖ ការសិក្សាអំពីភាពជឿជាក់នៃការផ្ទុក និងសុវត្ថិភាព»
• «Calico សម្រាប់បណ្តាញនៅក្នុង Kubernetes៖ ការណែនាំ និងបទពិសោធន៍តិចតួច»
• «កំហុសប្រព័ន្ធកម្សាន្តចំនួន 6 នៅក្នុងប្រតិបត្តិការរបស់ Kubernetes [និងដំណោះស្រាយរបស់ពួកគេ]»
• «មគ្គុទ្ទេសក៍ដែលមើលឃើញសម្រាប់ការដោះស្រាយបញ្ហា Kubernetes"។

ប្រភព: www.habr.com