etcd Kubernetes ക്ലസ്റ്ററിലെ ഡാറ്റയുമായി നേരിട്ടുള്ള ഞങ്ങളുടെ അനുഭവം (K8s API ഇല്ലാതെ)

ക്ലസ്റ്ററിനുള്ളിലെ സേവനങ്ങൾ ആക്‌സസ് ചെയ്യാൻ കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്ക് ആക്‌സസ് നൽകാൻ ക്ലയൻ്റുകൾ ഞങ്ങളോട് ആവശ്യപ്പെടുന്നത് വർദ്ധിച്ചുവരികയാണ്: ചില ഡാറ്റാബേസിലേക്കോ സേവനത്തിലേക്കോ നേരിട്ട് കണക്റ്റുചെയ്യാൻ, ക്ലസ്റ്ററിനുള്ളിലെ ആപ്ലിക്കേഷനുകളുമായി ഒരു പ്രാദേശിക ആപ്ലിക്കേഷനെ ബന്ധിപ്പിക്കുന്നതിന്...

ഉദാഹരണത്തിന്, നിങ്ങളുടെ പ്രാദേശിക മെഷീനിൽ നിന്ന് ഒരു സേവനത്തിലേക്ക് കണക്റ്റുചെയ്യേണ്ടതുണ്ട് memcached.staging.svc.cluster.local. ക്ലയൻ്റ് കണക്റ്റുചെയ്യുന്ന ക്ലസ്റ്ററിനുള്ളിൽ ഒരു VPN ഉപയോഗിച്ച് ഞങ്ങൾ ഈ കഴിവ് നൽകുന്നു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ പോഡുകളുടെയും സേവനങ്ങളുടെയും സബ്‌നെറ്റുകളും ക്ലയൻ്റിലേക്ക് പുഷ് ക്ലസ്റ്റർ ഡിഎൻഎസും പ്രഖ്യാപിക്കുന്നു. അങ്ങനെ, ഒരു ക്ലയൻ്റ് സേവനത്തിലേക്ക് കണക്റ്റുചെയ്യാൻ ശ്രമിക്കുമ്പോൾ memcached.staging.svc.cluster.local, അഭ്യർത്ഥന ക്ലസ്റ്റർ ഡിഎൻഎസിലേക്ക് പോകുകയും പ്രതികരണമായി ക്ലസ്റ്റർ സേവന നെറ്റ്‌വർക്കിൽ നിന്നോ പോഡ് വിലാസത്തിൽ നിന്നോ ഈ സേവനത്തിൻ്റെ വിലാസം സ്വീകരിക്കുന്നു.

ഡിഫോൾട്ട് സർവീസ് സബ്നെറ്റ് ഉള്ള kubeadm ഉപയോഗിച്ച് ഞങ്ങൾ K8s ക്ലസ്റ്ററുകൾ കോൺഫിഗർ ചെയ്യുന്നു 192.168.0.0/16, ഒപ്പം പോഡുകളുടെ ശൃംഖലയാണ് 10.244.0.0/16. സാധാരണയായി എല്ലാം നന്നായി പ്രവർത്തിക്കുന്നു, പക്ഷേ കുറച്ച് പോയിൻ്റുകൾ ഉണ്ട്:

• സബ്നെറ്റ് 192.168.*.* പലപ്പോഴും ക്ലയൻ്റ് ഓഫീസ് നെറ്റ്‌വർക്കുകളിലും ഡെവലപ്പർ ഹോം നെറ്റ്‌വർക്കുകളിലും പലപ്പോഴും ഉപയോഗിക്കുന്നു. തുടർന്ന് ഞങ്ങൾക്ക് വൈരുദ്ധ്യങ്ങൾ ലഭിക്കുന്നു: ഹോം റൂട്ടറുകൾ ഈ സബ്‌നെറ്റിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ VPN ഈ സബ്‌നെറ്റുകളെ ക്ലസ്റ്ററിൽ നിന്ന് ക്ലയൻ്റിലേക്ക് തള്ളുന്നു.
• ഞങ്ങൾക്ക് നിരവധി ക്ലസ്റ്ററുകൾ ഉണ്ട് (പ്രൊഡക്ഷൻ, സ്റ്റേജ് കൂടാതെ/അല്ലെങ്കിൽ നിരവധി ഡെവലപ്പ് ക്ലസ്റ്ററുകൾ). തുടർന്ന്, സ്ഥിരസ്ഥിതിയായി, അവയ്‌ക്കെല്ലാം പോഡുകൾക്കും സേവനങ്ങൾക്കും ഒരേ സബ്‌നെറ്റുകൾ ഉണ്ടായിരിക്കും, ഇത് നിരവധി ക്ലസ്റ്ററുകളിലെ സേവനങ്ങളുമായി ഒരേസമയം പ്രവർത്തിക്കുന്നതിന് വലിയ ബുദ്ധിമുട്ടുകൾ സൃഷ്ടിക്കുന്നു.

ഒരേ പ്രോജക്റ്റിനുള്ളിൽ സേവനങ്ങൾക്കും പോഡുകൾക്കുമായി വ്യത്യസ്‌ത സബ്‌നെറ്റുകൾ ഉപയോഗിക്കുന്ന രീതി ഞങ്ങൾ വളരെ മുമ്പുതന്നെ സ്വീകരിച്ചിട്ടുണ്ട് - പൊതുവെ, എല്ലാ ക്ലസ്റ്ററുകൾക്കും വ്യത്യസ്ത നെറ്റ്‌വർക്കുകൾ ഉണ്ടായിരിക്കും. എന്നിരുന്നാലും, നിരവധി സേവനങ്ങൾ, സ്‌റ്റേറ്റ്‌ഫുൾ ആപ്ലിക്കേഷനുകൾ മുതലായവ പ്രവർത്തിപ്പിക്കുന്നതിനാൽ, ആദ്യം മുതൽ ഉരുട്ടാൻ ഞാൻ ആഗ്രഹിക്കാത്ത ധാരാളം ക്ലസ്റ്ററുകൾ പ്രവർത്തനത്തിലുണ്ട്.

എന്നിട്ട് ഞങ്ങൾ സ്വയം ചോദിച്ചു: നിലവിലുള്ള ഒരു ക്ലസ്റ്ററിൽ സബ്നെറ്റ് എങ്ങനെ മാറ്റാം?

തീരുമാനങ്ങൾ തിരയുന്നു

പുനർനിർമ്മിക്കുക എന്നതാണ് ഏറ്റവും സാധാരണമായ രീതി എല്ലാം തരം ClusterIP ഉള്ള സേവനങ്ങൾ. ഒരു ഓപ്ഷനായി, ഉപദേശിക്കാം ഇതും:

ഇനിപ്പറയുന്ന പ്രക്രിയയ്ക്ക് ഒരു പ്രശ്‌നമുണ്ട്: എല്ലാം ക്രമീകരിച്ചതിന് ശേഷം, /etc/resolv.conf-ൽ ഒരു DNS നെയിംസെർവറായി പോഡുകൾ പഴയ ഐപിയുമായി വരുന്നു.
എനിക്ക് ഇപ്പോഴും പരിഹാരം കണ്ടെത്താനാകാത്തതിനാൽ, എനിക്ക് മുഴുവൻ ക്ലസ്റ്ററും kubeadm റീസെറ്റ് ഉപയോഗിച്ച് റീസെറ്റ് ചെയ്യുകയും അത് വീണ്ടും ഇൻനിറ്റ് ചെയ്യുകയും ചെയ്യേണ്ടിവന്നു.

എന്നാൽ ഇത് എല്ലാവർക്കും അനുയോജ്യമല്ല... ഞങ്ങളുടെ കേസിൻ്റെ കൂടുതൽ വിശദമായ ആമുഖങ്ങൾ ഇതാ:

• ഫ്ലാനൽ ഉപയോഗിക്കുന്നു;
• മേഘങ്ങളിലും ഹാർഡ്‌വെയറിലും ക്ലസ്റ്ററുകൾ ഉണ്ട്;
• ക്ലസ്റ്ററിലെ എല്ലാ സേവനങ്ങളും വീണ്ടും വിന്യസിക്കുന്നത് ഒഴിവാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു;
• എല്ലാ കാര്യങ്ങളും ചുരുങ്ങിയത് പ്രശ്‌നങ്ങളോടെ ചെയ്യേണ്ടതുണ്ട്;
• കുബർനെറ്റസ് പതിപ്പ് 1.16.6 ആണ് (എന്നിരുന്നാലും, മറ്റ് പതിപ്പുകൾക്കും തുടർ നടപടികൾ സമാനമായിരിക്കും);
• ഒരു ക്ലസ്റ്ററിൽ ഒരു സേവന സബ്‌നെറ്റിനൊപ്പം kubeadm ഉപയോഗിച്ച് വിന്യസിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക എന്നതാണ് പ്രധാന ചുമതല 192.168.0.0/16, ഇത് മാറ്റിസ്ഥാപിക്കുക 172.24.0.0/16.

കുബെർനെറ്റസിൽ എന്താണ്, എങ്ങനെ തുടങ്ങിയവ etcd-ൽ സംഭരിച്ചിരിക്കുന്നു, അത് കൊണ്ട് എന്തുചെയ്യാൻ കഴിയും എന്നറിയാൻ ഞങ്ങൾക്ക് വളരെക്കാലമായി താൽപ്പര്യമുണ്ടായിരുന്നു ... അതിനാൽ ഞങ്ങൾ ചിന്തിച്ചു: "പഴയ ഐപി വിലാസങ്ങൾ (സബ്‌നെറ്റ്) മാറ്റി പുതിയവ ഉപയോഗിച്ച് എന്തിനാണ് etcd-യിലെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്‌തത്??

etcd-യിലെ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതിന് റെഡിമെയ്ഡ് ടൂളുകൾക്കായി തിരഞ്ഞതിനാൽ, പ്രശ്നം പൂർണ്ണമായും പരിഹരിക്കുന്ന ഒന്നും ഞങ്ങൾ കണ്ടെത്തിയില്ല. (വഴി, etcd-യിൽ നേരിട്ട് ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതിനുള്ള ഏതെങ്കിലും യൂട്ടിലിറ്റികളെക്കുറിച്ച് നിങ്ങൾക്ക് അറിയാമെങ്കിൽ, ഞങ്ങൾ ലിങ്കുകളെ അഭിനന്ദിക്കുന്നു.) എന്നിരുന്നാലും, ഒരു നല്ല തുടക്കമാണ് etcdhelper OpenShift-ൽ നിന്ന് (അതിൻ്റെ രചയിതാക്കൾക്ക് നന്ദി!).

ഈ യൂട്ടിലിറ്റിക്ക് സർട്ടിഫിക്കറ്റുകൾ ഉപയോഗിച്ച് etcd-ലേക്ക് കണക്റ്റുചെയ്യാനും കമാൻഡുകൾ ഉപയോഗിച്ച് അവിടെ നിന്ന് ഡാറ്റ വായിക്കാനും കഴിയും ls, get, dump.

etcdhelper ചേർക്കുക

അടുത്ത ചിന്ത യുക്തിസഹമാണ്: " etcd-യിലേക്ക് ഡാറ്റ എഴുതാനുള്ള കഴിവ് ചേർത്ത് ഈ യൂട്ടിലിറ്റി ചേർക്കുന്നതിൽ നിന്ന് നിങ്ങളെ തടയുന്നതെന്താണ്?"

രണ്ട് പുതിയ ഫംഗ്‌ഷനുകളുള്ള etcdhelper-ൻ്റെ പരിഷ്‌ക്കരിച്ച പതിപ്പായി ഇത് മാറി changeServiceCIDR и changePodCIDR. അവളുടെ മേൽ നിങ്ങൾക്ക് കോഡ് കാണാൻ കഴിയും ഇവിടെ.

പുതിയ സവിശേഷതകൾ എന്താണ് ചെയ്യുന്നത്? അൽഗോരിതം changeServiceCIDR:

• ഒരു deserializer സൃഷ്ടിക്കുക;
• CIDR മാറ്റിസ്ഥാപിക്കുന്നതിന് ഒരു സാധാരണ എക്സ്പ്രഷൻ സമാഹരിക്കുക;
• ക്ലസ്റ്ററിലെ ClusterIP തരം ഉപയോഗിച്ച് ഞങ്ങൾ എല്ലാ സേവനങ്ങളിലൂടെയും കടന്നുപോകുന്നു:
  • etcd-ൽ നിന്നുള്ള മൂല്യം ഒരു Go ഒബ്ജക്റ്റിലേക്ക് ഡീകോഡ് ചെയ്യുക;
  • ഒരു സാധാരണ പദപ്രയോഗം ഉപയോഗിച്ച് ഞങ്ങൾ വിലാസത്തിൻ്റെ ആദ്യ രണ്ട് ബൈറ്റുകൾ മാറ്റിസ്ഥാപിക്കുന്നു;
  • പുതിയ സബ്നെറ്റിൽ നിന്ന് സേവനത്തിന് ഒരു IP വിലാസം നൽകുക;
  • ഒരു സീരിയലൈസർ സൃഷ്‌ടിക്കുക, Go ഒബ്‌ജക്‌റ്റിനെ പ്രോട്ടോബഫാക്കി മാറ്റുക, etcd-ലേക്ക് പുതിയ ഡാറ്റ എഴുതുക.

ഫംഗ്ഷൻ changePodCIDR അടിസ്ഥാനപരമായി സമാനമാണ് changeServiceCIDR - സേവന സ്പെസിഫിക്കേഷൻ എഡിറ്റ് ചെയ്യുന്നതിനുപകരം, നോഡിനും മാറ്റത്തിനുമായി ഞങ്ങൾ അത് ചെയ്യുന്നു .spec.PodCIDR ഒരു പുതിയ സബ്നെറ്റിലേക്ക്.

പ്രാക്ടീസ് ചെയ്യുക

സേവനം CIDR മാറ്റുക

ടാസ്‌ക് നടപ്പിലാക്കുന്നതിനുള്ള പദ്ധതി വളരെ ലളിതമാണ്, എന്നാൽ ക്ലസ്റ്ററിലെ എല്ലാ പോഡുകളുടെയും പുനർനിർമ്മാണ സമയത്ത് പ്രവർത്തനരഹിതമായ സമയം ഇതിൽ ഉൾപ്പെടുന്നു. പ്രധാന ഘട്ടങ്ങൾ വിവരിച്ച ശേഷം, സൈദ്ധാന്തികമായി, ഈ പ്രവർത്തനരഹിതമായ സമയം എങ്ങനെ കുറയ്ക്കാം എന്നതിനെക്കുറിച്ചുള്ള ചിന്തകളും ഞങ്ങൾ പങ്കിടും.

തയ്യാറെടുപ്പ് ഘട്ടങ്ങൾ:

• ആവശ്യമായ സോഫ്‌റ്റ്‌വെയർ ഇൻസ്റ്റാൾ ചെയ്യുകയും പാച്ച് ചെയ്ത etcdhelper കൂട്ടിച്ചേർക്കുകയും ചെയ്യുക;
• ബാക്കപ്പ് തുടങ്ങിയവ /etc/kubernetes.

സർവീസ്‌സിഐഡിആർ മാറ്റുന്നതിനുള്ള ഹ്രസ്വ പ്രവർത്തന പദ്ധതി:

• apiserver, കൺട്രോളർ-മാനേജർ മാനിഫെസ്റ്റുകൾ മാറ്റുന്നു;
• സർട്ടിഫിക്കറ്റുകളുടെ പുനർവിതരണം;
• etcd-ൽ ClusterIP സേവനങ്ങൾ മാറ്റുന്നു;
• ക്ലസ്റ്ററിലെ എല്ലാ പോഡുകളും പുനരാരംഭിക്കുക.

വിശദമായ പ്രവർത്തനങ്ങളുടെ ഒരു സമ്പൂർണ്ണ ശ്രേണിയാണ് ഇനിപ്പറയുന്നത്.

1. ഡാറ്റ ഡമ്പിനായി etcd-ക്ലയൻ്റ് ഇൻസ്റ്റാൾ ചെയ്യുക:

apt install etcd-client

2. ബിൽഡ് etcdhelper:

• ഗോലാംഗ് ഇൻസ്റ്റാൾ ചെയ്യുക:

  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_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. കുബർനെറ്റസ് കൺട്രോൾ പ്ലെയിൻ മാനിഫെസ്റ്റിലെ സേവന സബ്നെറ്റ് മാറ്റുക. ഫയലുകളിൽ /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. apiserver-ന് (ഉൾപ്പെടെ) kubeadm സർട്ടിഫിക്കറ്റുകൾ നൽകുന്ന സേവന സബ്‌നെറ്റ് ഞങ്ങൾ മാറ്റുന്നതിനാൽ, അവ വീണ്ടും ഇഷ്യൂ ചെയ്യേണ്ടതുണ്ട്:

1. ഏതൊക്കെ ഡൊമെയ്‌നുകൾക്കും ഐപി വിലാസങ്ങൾക്കുമാണ് നിലവിലെ സർട്ടിഫിക്കറ്റ് നൽകിയിരിക്കുന്നതെന്ന് നോക്കാം:

   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. എന്നതിനായുള്ള കോൺഫിഗറേഷൻ നമുക്ക് പുനഃസൃഷ്ടിക്കാം 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 നിയമങ്ങളെ പഴയ സബ്‌നെറ്റിൽ നിന്ന് പുതിയതിലേക്ക് മാറ്റുന്നു. പ്രവർത്തനരഹിതമായ സമയം കുറയ്ക്കുന്നതിനുള്ള സാധ്യമായ ഓപ്ഷനുകളെക്കുറിച്ച് ലേഖനത്തിൽ കൂടുതൽ എഴുതിയിട്ടുണ്ട്.

9. നമുക്ക് നെയിംസ്പേസിൽ കോൺഫിഗ്മാപ്പ് ശരിയാക്കാം kube-system:

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

   - ഇവിടെ മാറ്റിസ്ഥാപിക്കുക clusterDNS kube-dns സേവനത്തിൻ്റെ പുതിയ IP വിലാസത്തിലേക്ക്: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - ഞങ്ങൾ അത് ശരിയാക്കും data.ClusterConfiguration.networking.serviceSubnet ഒരു പുതിയ സബ്നെറ്റിലേക്ക്.

10. kube-dns വിലാസം മാറിയതിനാൽ, എല്ലാ നോഡുകളിലും kubelet config അപ്ഡേറ്റ് ചെയ്യേണ്ടത് ആവശ്യമാണ്:

    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. നിയന്ത്രണ തലം മാനിഫെസ്റ്റുകൾ മാറ്റിയ ശേഷം, ഒരു പുതിയ kube-dns സേവനം സൃഷ്ടിക്കുക, ഉദാഹരണത്തിന്, പേര് kube-dns-tmp പുതിയ വിലാസവും 172.24.0.10.
2. ഉണ്ടാക്കുക if etcdhelper-ൽ, അത് kube-dns സേവനത്തിൽ മാറ്റം വരുത്തില്ല.
3. എല്ലാ കുബെലെറ്റുകളിലും വിലാസം മാറ്റിസ്ഥാപിക്കുക ClusterDNS പുതിയതിലേക്ക്, പഴയ സേവനം പുതിയതിനൊപ്പം ഒരേസമയം പ്രവർത്തിക്കുന്നത് തുടരും.
4. പ്രയോഗങ്ങളുള്ള പോഡുകൾ സ്വാഭാവിക കാരണങ്ങളാലോ അല്ലെങ്കിൽ സമ്മതിച്ച സമയത്തോ തനിയെ ഉരുളുന്നത് വരെ കാത്തിരിക്കുക.
5. സേവനം ഇല്ലാതാക്കുക kube-dns-tmp മാറ്റുകയും serviceSubnetCIDR kube-dns സേവനത്തിനായി.

ഈ പ്ലാൻ നിങ്ങളെ പ്രവർത്തനരഹിതമായ സമയം ~ഒരു മിനിറ്റായി കുറയ്ക്കാൻ അനുവദിക്കും - സേവനം നീക്കം ചെയ്യുന്ന സമയത്തേക്ക് kube-dns-tmp സേവനത്തിനായി സബ്നെറ്റ് മാറ്റുകയും ചെയ്യുന്നു kube-dns.

പരിഷ്‌ക്കരണം പോഡ് നെറ്റ്‌വർക്ക്

അതേ സമയം, തത്ഫലമായുണ്ടാകുന്ന etcdhelper ഉപയോഗിച്ച് എങ്ങനെ podNetwork പരിഷ്ക്കരിക്കാം എന്ന് നോക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. പ്രവർത്തനങ്ങളുടെ ക്രമം ഇപ്രകാരമാണ്:

• കോൺഫിഗറേഷനുകൾ ശരിയാക്കുന്നു kube-system;
• ക്യൂബ്-കൺട്രോളർ-മാനേജർ മാനിഫെസ്റ്റ് ശരിയാക്കുന്നു;
• podCIDR നേരിട്ട് etcd-യിൽ മാറ്റുക;
• എല്ലാ ക്ലസ്റ്റർ നോഡുകളും റീബൂട്ട് ചെയ്യുക.

ഇപ്പോൾ ഈ പ്രവർത്തനങ്ങളെക്കുറിച്ച് കൂടുതൽ:

1. നെയിംസ്പേസിൽ കോൺഫിഗ്മാപ്പ് പരിഷ്ക്കരിക്കുക 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. കൺട്രോളർ-മാനേജർ മാനിഫെസ്‌റ്റ് പരിഷ്‌ക്കരിക്കുക:

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. etcd-ലേക്ക് നേരിട്ട് മാറ്റങ്ങൾ വരുത്തിക്കൊണ്ട് podCIDR മാറ്റിസ്ഥാപിക്കുക:

./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-ന് ആരംഭിക്കാൻ കഴിയില്ല, കൂടാതെ ക്ലസ്റ്ററിലെ പോഡുകൾ ഷെഡ്യൂൾ ചെയ്യപ്പെടുകയുമില്ല.

വാസ്തവത്തിൽ, podCIDR മാറ്റുന്നത് ഇതിലും ലളിതമായി ചെയ്യാൻ കഴിയും (ഉദാഹരണത്തിന്, അതുപോലെ). എന്നാൽ, etcd-യിൽ Kubernetes ഒബ്‌ജക്‌റ്റുകൾ എഡിറ്റുചെയ്യുമ്പോൾ ചില കേസുകളുണ്ട് എന്നതിനാൽ, etcd-യിൽ നേരിട്ട് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് പഠിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഒരേയൊരു സാധ്യമായ വേരിയൻ്റ്. (ഉദാഹരണത്തിന്, പ്രവർത്തനരഹിതമാകാതെ നിങ്ങൾക്ക് സേവന ഫീൽഡ് മാറ്റാൻ കഴിയില്ല spec.clusterIP.)

ഫലം

etcd-യിലെ ഡാറ്റയുമായി നേരിട്ട് പ്രവർത്തിക്കാനുള്ള സാധ്യത ലേഖനം ചർച്ചചെയ്യുന്നു, അതായത്. Kubernetes API ബൈപാസ് ചെയ്യുന്നു. ചിലപ്പോൾ ഈ സമീപനം നിങ്ങളെ "തന്ത്രപരമായ കാര്യങ്ങൾ" ചെയ്യാൻ അനുവദിക്കുന്നു. യഥാർത്ഥ K8s ക്ലസ്റ്ററുകളിൽ വാചകത്തിൽ നൽകിയിരിക്കുന്ന പ്രവർത്തനങ്ങൾ ഞങ്ങൾ പരീക്ഷിച്ചു. എന്നിരുന്നാലും, വ്യാപകമായ ഉപയോഗത്തിനുള്ള അവരുടെ സന്നദ്ധതയാണ് PoC (സങ്കൽപ്പത്തിൻ്റെ തെളിവ്). അതിനാൽ, നിങ്ങളുടെ ക്ലസ്റ്ററുകളിൽ etcdhelper യൂട്ടിലിറ്റിയുടെ പരിഷ്കരിച്ച പതിപ്പ് ഉപയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ സ്വന്തം ഉത്തരവാദിത്തത്തിൽ അത് ചെയ്യുക.

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «etcd 3.4.3: സംഭരണ ​​വിശ്വാസ്യതയും സുരക്ഷാ പഠനവും";
• «കുബർനെറ്റസിലെ നെറ്റ്‌വർക്കിംഗിനുള്ള കാലിക്കോ: ആമുഖവും ഒരു ചെറിയ അനുഭവവും";
• «കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തിലെ 6 രസകരമായ സിസ്റ്റം ബഗുകളും [അവയുടെ പരിഹാരവും]";
• «കുബെർനെറ്റസ് ട്രബിൾഷൂട്ടിംഗിനുള്ള ഒരു വിഷ്വൽ ഗൈഡ്".

അവലംബം: www.habr.com