புரோஹோஸ்டர் > Блог > நிர்வாகம் > etcd குபெர்னெட்ஸ் கிளஸ்டரில் நேரடியாக (K8s API இல்லாமல்) தரவுகளுடன் பணிபுரிந்த அனுபவம்

etcd குபெர்னெட்ஸ் கிளஸ்டரில் நேரடியாக (K8s API இல்லாமல்) தரவுகளுடன் பணிபுரிந்த அனுபவம்

க்ளஸ்டருக்குள் சேவைகளை அணுகுவதற்கு Kubernetes கிளஸ்டருக்கான அணுகலை வழங்குமாறு வாடிக்கையாளர்கள் பெருகிய முறையில் எங்களிடம் கேட்கின்றனர்: சில தரவுத்தளம் அல்லது சேவையுடன் நேரடியாக இணைக்க முடியும், கிளஸ்டரில் உள்ள பயன்பாடுகளுடன் உள்ளூர் பயன்பாட்டை இணைக்க...

etcd குபெர்னெட்ஸ் கிளஸ்டரில் நேரடியாக (K8s API இல்லாமல்) தரவுகளுடன் பணிபுரிந்த அனுபவம்

எடுத்துக்காட்டாக, உங்கள் உள்ளூர் இயந்திரத்திலிருந்து ஒரு சேவையுடன் இணைக்க வேண்டிய அவசியம் உள்ளது memcached.staging.svc.cluster.local. கிளையன்ட் இணைக்கும் கிளஸ்டருக்குள் VPN ஐப் பயன்படுத்தி இந்தத் திறனை நாங்கள் வழங்குகிறோம். இதைச் செய்ய, காய்கள், சேவைகள் மற்றும் புஷ் கிளஸ்டர் DNS இன் சப்நெட்களை கிளையண்டிற்கு அறிவிக்கிறோம். இவ்வாறு, ஒரு வாடிக்கையாளர் சேவையுடன் இணைக்க முயற்சிக்கும் போது memcached.staging.svc.cluster.local, கோரிக்கையானது க்ளஸ்டர் DNS க்கு செல்கிறது மற்றும் பதில் இந்த சேவையின் முகவரியை க்ளஸ்டர் சர்வீஸ் நெட்வொர்க் அல்லது பாட் முகவரியில் இருந்து பெறுகிறது.

kubeadm ஐப் பயன்படுத்தி K8s கிளஸ்டர்களை உள்ளமைக்கிறோம், அங்கு இயல்புநிலை சேவை சப்நெட் உள்ளது 192.168.0.0/16, மற்றும் காய்களின் நெட்வொர்க் ஆகும் 10.244.0.0/16. பொதுவாக எல்லாம் நன்றாக வேலை செய்கிறது, ஆனால் இரண்டு புள்ளிகள் உள்ளன:

  • சப்நெட் 192.168.*.* பெரும்பாலும் கிளையன்ட் அலுவலக நெட்வொர்க்குகளில் பயன்படுத்தப்படுகிறது, மேலும் பெரும்பாலும் டெவலப்பர் வீட்டு நெட்வொர்க்குகளில். பின்னர் நாங்கள் முரண்பாடுகளைப் பெறுகிறோம்: வீட்டு திசைவிகள் இந்த சப்நெட்டில் வேலை செய்கின்றன, மேலும் VPN இந்த சப்நெட்களை கிளஸ்டரிலிருந்து கிளையண்டிற்குத் தள்ளுகிறது.
  • எங்களிடம் பல கிளஸ்டர்கள் உள்ளன (உற்பத்தி, நிலை மற்றும்/அல்லது பல டெவ் கிளஸ்டர்கள்). பின்னர், முன்னிருப்பாக, அவை அனைத்தும் காய்கள் மற்றும் சேவைகளுக்கான ஒரே சப்நெட்களைக் கொண்டிருக்கும், இது பல கிளஸ்டர்களில் சேவைகளுடன் ஒரே நேரத்தில் வேலை செய்வதற்கு பெரும் சிரமங்களை உருவாக்குகிறது.

ஒரே திட்டத்தில் சேவைகள் மற்றும் பாட்களுக்கு வெவ்வேறு சப்நெட்களைப் பயன்படுத்தும் நடைமுறையை நாங்கள் நீண்ட காலத்திற்கு முன்பே ஏற்றுக்கொண்டோம் - பொதுவாக, அனைத்து கிளஸ்டர்களும் வெவ்வேறு நெட்வொர்க்குகளைக் கொண்டிருக்கும். இருப்பினும், அதிக எண்ணிக்கையிலான கிளஸ்டர்கள் செயல்பாட்டில் உள்ளன, அவை பல சேவைகள், நிலையான பயன்பாடுகள் போன்றவற்றை இயக்குவதால், நான் புதிதாக உருட்ட விரும்பவில்லை.

பின்னர் நாங்கள் நம்மை நாமே கேட்டுக்கொண்டோம்: ஏற்கனவே உள்ள கிளஸ்டரில் சப்நெட்டை எவ்வாறு மாற்றுவது?

தீர்வுகளைத் தேடுங்கள்

மிகவும் பொதுவான நடைமுறை மீண்டும் உருவாக்குவது அனைத்து ClusterIP வகை கொண்ட சேவைகள். ஒரு விருப்பமாக, ஆலோசனை செய்யலாம் இந்த:

பின்வரும் செயல்முறையில் சிக்கல் உள்ளது: அனைத்தும் கட்டமைக்கப்பட்ட பிறகு, /etc/resolv.conf இல் DNS பெயர்செர்வராக காய்கள் பழைய IP உடன் வரும்.
நான் இன்னும் தீர்வைக் கண்டுபிடிக்கவில்லை என்பதால், முழு கிளஸ்டரையும் kubeadm ரீசெட் மூலம் மீட்டமைத்து மீண்டும் தொடங்க வேண்டியிருந்தது.

ஆனால் இது அனைவருக்கும் பொருந்தாது... எங்கள் வழக்குக்கான விரிவான அறிமுகங்கள் இங்கே:

  • Flannel பயன்படுத்தப்படுகிறது;
  • மேகங்களிலும் வன்பொருளிலும் கொத்துகள் உள்ளன;
  • கிளஸ்டரில் அனைத்து சேவைகளையும் மீண்டும் பயன்படுத்துவதை தவிர்க்க விரும்புகிறேன்;
  • குறைந்தபட்ச எண்ணிக்கையிலான சிக்கல்களுடன் பொதுவாக எல்லாவற்றையும் செய்ய வேண்டிய அவசியம் உள்ளது;
  • குபெர்னெட்டஸ் பதிப்பு 1.16.6 (இருப்பினும், மற்ற பதிப்புகளுக்கு அடுத்த படிகள் ஒரே மாதிரியாக இருக்கும்);
  • சேவை சப்நெட்டுடன் kubeadm ஐப் பயன்படுத்தி ஒரு கிளஸ்டரில் பயன்படுத்தப்படுவதை உறுதி செய்வதே முக்கிய பணியாகும் 192.168.0.0/16, அதை மாற்றவும் 172.24.0.0/16.

குபெர்னெட்டஸில் என்ன, எப்படி முதலியன சேமிக்கப்படுகிறது, அதை என்ன செய்யலாம் என்பதைப் பார்ப்பதில் நாங்கள் நீண்ட காலமாக ஆர்வமாக இருந்தோம் ... எனவே நாங்கள் நினைத்தோம்: "பழைய ஐபி முகவரிகளை (சப்நெட்) புதியதாக மாற்றி, etcd இல் உள்ள தரவை மட்டும் ஏன் புதுப்பிக்கக்கூடாது? '

முதலியன தரவுகளுடன் பணிபுரிய ஆயத்த கருவிகளைத் தேடியதால், சிக்கலை முழுமையாகத் தீர்க்கும் எதையும் நாங்கள் கண்டுபிடிக்கவில்லை. (இதன் மூலம், நேரடியாக etcd இல் தரவுகளுடன் பணிபுரிவதற்கான ஏதேனும் பயன்பாடுகள் பற்றி உங்களுக்குத் தெரிந்தால், இணைப்புகளைப் பாராட்டுவோம்.) இருப்பினும், ஒரு நல்ல தொடக்க புள்ளி முதலியன உதவி செய்பவர் OpenShift இலிருந்து (அதன் ஆசிரியர்களுக்கு நன்றி!).

இந்த பயன்பாடு சான்றிதழ்களைப் பயன்படுத்தி etcd உடன் இணைக்கலாம் மற்றும் கட்டளைகளைப் பயன்படுத்தி அங்கிருந்து தரவைப் படிக்கலாம் ls, get, dump.

etcdhelper ஐச் சேர்க்கவும்

அடுத்த எண்ணம் தர்க்கரீதியானது: "etcd இல் தரவை எழுதும் திறனைச் சேர்ப்பதன் மூலம் இந்த பயன்பாட்டைச் சேர்ப்பதில் இருந்து உங்களைத் தடுப்பது எது?"

இது இரண்டு புதிய செயல்பாடுகளுடன் etcdhelper இன் மாற்றியமைக்கப்பட்ட பதிப்பாக மாறியது changeServiceCIDR и changePodCIDR. அவள் மீது நீங்கள் குறியீட்டைக் காணலாம் இங்கே.

புதிய அம்சங்கள் என்ன செய்கின்றன? அல்காரிதம் changeServiceCIDR:

  • ஒரு டீரியலைசரை உருவாக்கவும்;
  • CIDR ஐ மாற்றுவதற்கு வழக்கமான வெளிப்பாட்டை தொகுக்கவும்;
  • கிளஸ்டரில் உள்ள ClusterIP வகையுடன் அனைத்து சேவைகளையும் நாங்கள் மேற்கொள்கிறோம்:
    • etcd இலிருந்து மதிப்பை ஒரு Go பொருளாக டிகோட் செய்யவும்;
    • வழக்கமான வெளிப்பாட்டைப் பயன்படுத்தி, முகவரியின் முதல் இரண்டு பைட்டுகளை மாற்றுவோம்;
    • புதிய சப்நெட்டிலிருந்து சேவைக்கு ஐபி முகவரியை ஒதுக்கவும்;
    • ஒரு சீரியலைசரை உருவாக்கவும், Go பொருளை புரோட்டோபஃப் ஆக மாற்றவும், புதிய தரவை etcdக்கு எழுதவும்.

செயல்பாடு changePodCIDR அடிப்படையில் ஒத்த changeServiceCIDR - சேவை விவரக்குறிப்பைத் திருத்துவதற்குப் பதிலாக, நாங்கள் அதை முனை மற்றும் மாற்றத்திற்காக செய்கிறோம் .spec.PodCIDR புதிய சப்நெட்டிற்கு.

பயிற்சி

CIDR சேவையை மாற்றவும்

பணியைச் செயல்படுத்துவதற்கான திட்டம் மிகவும் எளிமையானது, ஆனால் கிளஸ்டரில் உள்ள அனைத்து காய்களையும் மீண்டும் உருவாக்கும் நேரத்தில் வேலையில்லா நேரத்தை உள்ளடக்கியது. முக்கிய படிகளை விவரித்த பிறகு, கோட்பாட்டில், இந்த வேலையில்லா நேரத்தை எவ்வாறு குறைக்கலாம் என்பது பற்றிய எண்ணங்களையும் பகிர்ந்து கொள்வோம்.

ஆயத்தப் படிகள்:

  • தேவையான மென்பொருளை நிறுவுதல் மற்றும் பேட்ச் செய்யப்பட்ட etcdhelper ஐ அசெம்பிள் செய்தல்;
  • காப்பு போன்றவை மற்றும் /etc/kubernetes.

சிஐடிஆர் சேவையை மாற்றுவதற்கான சுருக்கமான செயல் திட்டம்:

  • apiserver மற்றும் கன்ட்ரோலர்-மேனேஜர் மேனிஃபெஸ்ட்டை மாற்றுதல்;
  • சான்றிதழ்களை மீண்டும் வழங்குதல்;
  • முதலியன ClusterIP சேவைகளை மாற்றுதல்;
  • கிளஸ்டரில் உள்ள அனைத்து காய்களையும் மீண்டும் துவக்கவும்.

பின்வருபவை விரிவான செயல்களின் முழுமையான வரிசை.

1. டேட்டா டம்ப்பிற்கு etcd-client ஐ நிறுவவும்:

apt install etcd-client

2. பில்ட் எட்டெல்பர்:

  • கோலாங்கை நிறுவவும்: 
    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. பெயர்வெளியில் ConfigMap ஐ சரி செய்வோம் 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 கட்டமைப்பைப் புதுப்பிக்க வேண்டியது அவசியம்: 
    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. அனைத்து kubelets இல் முகவரியை மாற்றவும் ClusterDNS புதிய சேவைக்கு, பழைய சேவை புதிய சேவையுடன் ஒரே நேரத்தில் தொடர்ந்து செயல்படும்.
  4. பயன்பாடுகளுடன் கூடிய காய்கள் இயற்கையான காரணங்களுக்காக அல்லது ஒப்புக்கொள்ளப்பட்ட நேரத்தில் தானாக உருளும் வரை காத்திருக்கவும்.
  5. சேவையை நீக்கு kube-dns-tmp மற்றும் மாற்றம் serviceSubnetCIDR kube-dns சேவைக்காக.

சேவையை அகற்றும் காலத்திற்கு - ஒரு நிமிடத்திற்கு வேலையில்லா நேரத்தைக் குறைக்க இந்தத் திட்டம் உங்களை அனுமதிக்கும் kube-dns-tmp மற்றும் சேவைக்கான சப்நெட்டை மாற்றுகிறது kube-dns.

மாற்றியமைத்தல் பாட்நெட்வொர்க்

அதே நேரத்தில், இதன் விளைவாக வரும் etcdhelper ஐப் பயன்படுத்தி podNetwork ஐ எவ்வாறு மாற்றுவது என்பதைப் பார்க்க முடிவு செய்தோம். செயல்களின் வரிசை பின்வருமாறு:

  • உள்ளமைவுகளை சரிசெய்தல் kube-system;
  • குபே-கண்ட்ரோலர்-மேனேஜர் மேனிஃபெஸ்ட்டை சரிசெய்தல்;
  • podCIDR ஐ நேரடியாக etcd இல் மாற்றவும்;
  • அனைத்து கிளஸ்டர் முனைகளையும் மீண்டும் துவக்கவும்.

இப்போது இந்த நடவடிக்கைகள் பற்றி மேலும்:

1. பெயர்வெளியில் ConfigMap ஐ மாற்றவும் 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 உடன் நேரடியாக வேலை செய்வது எப்படி என்பதை அறிய விரும்பினோம், ஏனெனில் etcd இல் Kubernetes ஆப்ஜெக்ட்களை எடிட் செய்யும் சந்தர்ப்பங்கள் உள்ளன - ஒரே சாத்தியமான மாறுபாடு. (உதாரணமாக, வேலையில்லா நேரம் இல்லாமல் சேவை புலத்தை மட்டும் மாற்ற முடியாது spec.clusterIP.)

இதன் விளைவாக

கட்டுரை நேரடியாக etcd இல் தரவுகளுடன் பணிபுரியும் சாத்தியத்தை விவாதிக்கிறது, அதாவது. Kubernetes API ஐத் தவிர்க்கிறது. சில நேரங்களில் இந்த அணுகுமுறை உங்களை "தந்திரமான விஷயங்களை" செய்ய அனுமதிக்கிறது. உண்மையான K8s கிளஸ்டர்களில் உரையில் கொடுக்கப்பட்டுள்ள செயல்பாடுகளை நாங்கள் சோதித்தோம். இருப்பினும், பரவலான பயன்பாட்டிற்கான அவர்களின் தயார்நிலை நிலை PoC (கருத்துக்கான ஆதாரம்). எனவே, உங்கள் கிளஸ்டர்களில் etcdhelper பயன்பாட்டின் மாற்றியமைக்கப்பட்ட பதிப்பைப் பயன்படுத்த விரும்பினால், உங்கள் சொந்த ஆபத்தில் அதைப் பயன்படுத்தவும்.

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

ஆதாரம்: www.habr.com

கருத்தைச் சேர்