క్లస్టర్‌లోని సేవలను యాక్సెస్ చేయడానికి Kubernetes క్లస్టర్‌కు యాక్సెస్‌ను అందించమని క్లయింట్లు ఎక్కువగా అడుగుతున్నారు: కొన్ని డేటాబేస్ లేదా సర్వీస్‌కి నేరుగా కనెక్ట్ అవ్వడానికి, క్లస్టర్‌లోని అప్లికేషన్‌లతో స్థానిక అప్లికేషన్‌ని కనెక్ట్ చేయడానికి...
ఉదాహరణకు, మీ స్థానిక యంత్రం నుండి సేవకు కనెక్ట్ చేయవలసిన అవసరం ఉంది 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 రకంతో సేవలు. ఒక ఎంపికగా, మరియు ఇది:
కింది ప్రక్రియలో సమస్య ఉంది: ప్రతిదీ కాన్ఫిగర్ చేసిన తర్వాత, పాడ్‌లు పాత IPతో /etc/resolv.confలో DNS నేమ్‌సర్వర్‌గా వస్తాయి.
నేను ఇప్పటికీ పరిష్కారం కనుగొనలేదు కాబట్టి, నేను kubeadm రీసెట్‌తో మొత్తం క్లస్టర్‌ని రీసెట్ చేసి, దాన్ని మళ్లీ ప్రారంభించాల్సి వచ్చింది.
కానీ ఇది అందరికీ తగినది కాదు... మా కేసు కోసం ఇక్కడ మరింత వివరణాత్మక పరిచయాలు ఉన్నాయి:
- ఫ్లాన్నెల్ ఉపయోగించబడుతుంది;
- క్లౌడ్స్‌లో మరియు హార్డ్‌వేర్‌లో క్లస్టర్‌లు ఉన్నాయి;
- నేను క్లస్టర్‌లోని అన్ని సేవలను మళ్లీ అమలు చేయడాన్ని నివారించాలనుకుంటున్నాను;
- కనీస సంఖ్యలో సమస్యలతో సాధారణంగా ప్రతిదీ చేయవలసిన అవసరం ఉంది;
- కుబెర్నెటెస్ వెర్షన్ 1.16.6 (అయితే, తదుపరి దశలు ఇతర వెర్షన్‌లకు సమానంగా ఉంటాయి);
- ఒక క్లస్టర్‌లో సర్వీస్ సబ్‌నెట్‌తో kubeadmని ఉపయోగించినట్లు నిర్ధారించడం ప్రధాన పని
192.168.0.0/16, దానితో భర్తీ చేయండి172.24.0.0/16.
కుబెర్నెటెస్‌లో etcdలో ఏమి మరియు ఎలా నిల్వ చేయబడిందో, దానితో ఏమి చేయవచ్చో చూడాలని మేము చాలా కాలంగా ఆసక్తిని కలిగి ఉన్నాము... కాబట్టి మేము ఇలా అనుకున్నాము: "పాత IP చిరునామాలను (సబ్‌నెట్) కొత్త వాటితో భర్తీ చేసి, etcdలో డేటాను ఎందుకు అప్‌డేట్ చేయకూడదు? »
etcdలో డేటాతో పని చేయడానికి సిద్ధంగా ఉన్న సాధనాల కోసం శోధించిన తర్వాత, సమస్యను పూర్తిగా పరిష్కరించే ఏదీ కనుగొనబడలేదు. (మార్గం ద్వారా, నేరుగా etcdలో డేటాతో పని చేయడానికి ఏవైనా యుటిలిటీల గురించి మీకు తెలిస్తే, మేము లింక్‌లను అభినందిస్తాము.) అయితే, మంచి ప్రారంభ స్థానం (దాని రచయితలకు ధన్యవాదాలు!).
ఈ యుటిలిటీ సర్టిఫికేట్లను ఉపయోగించి etcdకి కనెక్ట్ చేయగలదు మరియు ఆదేశాలను ఉపయోగించి అక్కడి నుండి డేటాను చదవగలదు ls, get, dump.
etcdhelper జోడించండి
తదుపరి ఆలోచన తార్కికంగా ఉంది: "etcdకి డేటాను వ్రాయగల సామర్థ్యాన్ని జోడించడం ద్వారా ఈ యుటిలిటీని జోడించకుండా మిమ్మల్ని ఆపేది ఏమిటి?"
ఇది రెండు కొత్త ఫంక్షన్లతో etcdhelper యొక్క సవరించిన సంస్కరణగా మారింది changeServiceCIDR и changePodCIDR. ఆమె మీద మీరు కోడ్‌ని చూడవచ్చు .
కొత్త ఫీచర్లు ఏమి చేస్తాయి? అల్గోరిథం changeServiceCIDR:
- ఒక deserializer సృష్టించండి;
- CIDR స్థానంలో సాధారణ వ్యక్తీకరణను కంపైల్ చేయండి;
- మేము క్లస్టర్‌లోని క్లస్టర్‌ఐపి రకంతో అన్ని సేవల ద్వారా వెళ్తాము:
- etcd నుండి విలువను గో వస్తువుగా డీకోడ్ చేయండి;
- సాధారణ వ్యక్తీకరణను ఉపయోగించి మేము చిరునామా యొక్క మొదటి రెండు బైట్‌లను భర్తీ చేస్తాము;
- కొత్త సబ్‌నెట్ నుండి సేవకు IP చిరునామాను కేటాయించండి;
- సీరియలైజర్‌ని సృష్టించండి, గో ఆబ్జెక్ట్‌ను ప్రోటోబఫ్‌గా మార్చండి, కొత్త డేటాను etcdకి వ్రాయండి.
ఫంక్షన్ changePodCIDR తప్పనిసరిగా పోలి ఉంటుంది changeServiceCIDR - సర్వీస్ స్పెసిఫికేషన్‌ని సవరించడానికి బదులుగా, మేము నోడ్ మరియు మార్పు కోసం దీన్ని చేస్తాము .spec.PodCIDR కొత్త సబ్‌నెట్‌కి.
ఆచరణలో
సేవ CIDRని మార్చండి
పనిని అమలు చేయడానికి ప్రణాళిక చాలా సులభం, అయితే ఇది క్లస్టర్‌లోని అన్ని పాడ్‌లను తిరిగి సృష్టించే సమయంలో పనికిరాని సమయాన్ని కలిగి ఉంటుంది. ప్రధాన దశలను వివరించిన తర్వాత, సిద్ధాంతపరంగా, ఈ పనికిరాని సమయాన్ని ఎలా తగ్గించవచ్చనే దానిపై కూడా మేము ఆలోచనలను పంచుకుంటాము.
సన్నాహక దశలు:
- అవసరమైన సాఫ్ట్‌వేర్‌ను ఇన్‌స్టాల్ చేయడం మరియు ప్యాచ్ చేసిన etcdhelperని అసెంబ్లింగ్ చేయడం;
- బ్యాకప్ etcd మరియు
/etc/kubernetes.
సర్వీస్‌సిఐడిఆర్‌ని మార్చడానికి సంక్షిప్త కార్యాచరణ ప్రణాళిక:
- apiserver మరియు కంట్రోలర్-మేనేజర్ మానిఫెస్ట్‌లను మార్చడం;
- సర్టిఫికేట్లను తిరిగి జారీ చేయడం;
- etcdలో ClusterIP సేవలను మార్చడం;
- క్లస్టర్‌లోని అన్ని పాడ్‌లను పునఃప్రారంభించండి.
కిందివి వివరంగా చర్యల పూర్తి క్రమం.
1. డేటా డంప్ కోసం etcd-క్లయింట్‌ని ఇన్‌స్టాల్ చేయండి:
apt install etcd-client2. బిల్డ్ 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 సర్టిఫికేట్లను జారీ చేసే సర్వీస్ సబ్‌నెట్‌ను మేము మారుస్తున్నందున, వాటిని మళ్లీ జారీ చేయాలి:
- ప్రస్తుత ప్రమాణపత్రం ఏ డొమైన్‌లు మరియు 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 - 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-адрес мастер узла - పాత crt మరియు కీని తొలగిస్తాము, ఎందుకంటే ఇది లేకుండా కొత్త సర్టిఫికేట్ జారీ చేయబడదు:
rm /etc/kubernetes/pki/apiserver.{key,crt} - API సర్వర్ కోసం సర్టిఫికెట్‌లను మళ్లీ జారీ చేద్దాం:
kubeadm init phase certs apiserver --config=kubeadm-config.yaml - కొత్త సబ్‌నెట్ కోసం సర్టిఫికేట్ జారీ చేయబడిందని తనిఖీ చేద్దాం:
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 - API సర్వర్ ప్రమాణపత్రాన్ని మళ్లీ జారీ చేసిన తర్వాత, దాని కంటైనర్‌ను పునఃప్రారంభించండి:
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart - కోసం కాన్ఫిగరేషన్‌ను రీజెనరేట్ చేద్దాం
admin.conf:kubeadm alpha certs renew admin.conf - 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 నియమాలను మారుస్తుంది. ఇంకా వ్యాసంలో పనికిరాని సమయాన్ని తగ్గించడానికి సాధ్యమయ్యే ఎంపికల గురించి వ్రాయబడింది. - నేమ్‌స్పేస్‌లో కాన్ఫిగ్‌మ్యాప్‌లను సరిచేద్దాం
kube-system:kubectl -n kube-system edit cm kubelet-config-1.16- ఇక్కడ భర్తీ చేయండి
clusterDNSkube-dns సేవ యొక్క కొత్త IP చిరునామాకు:kubectl -n kube-system get svc kube-dns.kubectl -n kube-system edit cm kubeadm-config- మేము దాన్ని పరిష్కరిస్తాము
data.ClusterConfiguration.networking.serviceSubnetకొత్త సబ్‌నెట్‌కి. - kube-dns చిరునామా మారినందున, అన్ని నోడ్‌లలో kubelet కాన్ఫిగరేషన్‌ను నవీకరించడం అవసరం:
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet - క్లస్టర్‌లోని అన్ని పాడ్‌లను పునఃప్రారంభించడం మాత్రమే మిగిలి ఉంది:
kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'
పనికిరాని సమయాన్ని తగ్గించండి
పనికిరాని సమయాన్ని ఎలా తగ్గించాలనే దానిపై ఆలోచనలు:
- నియంత్రణ ప్లేన్ మానిఫెస్ట్‌లను మార్చిన తర్వాత, కొత్త kube-dns సేవను సృష్టించండి, ఉదాహరణకు, పేరుతో
kube-dns-tmpమరియు కొత్త చిరునామా172.24.0.10. - తయారు
ifetcdhelperలో, ఇది kube-dns సేవను సవరించదు. - అన్ని kubeletsలో చిరునామాను భర్తీ చేయండి
ClusterDNSకొత్తదానికి, పాత సేవ కొత్త దానితో ఏకకాలంలో పని చేస్తూనే ఉంటుంది. - అప్లికేషన్‌లతో కూడిన పాడ్‌లు సహజ కారణాల వల్ల లేదా అంగీకరించిన సమయంలో వాటంతట అవే రోల్ అయ్యే వరకు వేచి ఉండండి.
- సేవను తొలగించండి
kube-dns-tmpమరియు మార్పుserviceSubnetCIDRkube-dns సేవ కోసం.
సేవ తీసివేసే వ్యవధి కోసం - ఈ ప్లాన్ డౌన్‌టైమ్‌ని ~నిమిషానికి తగ్గించడానికి మిమ్మల్ని అనుమతిస్తుంది kube-dns-tmp మరియు సేవ కోసం సబ్‌నెట్‌ను మార్చడం kube-dns.
సవరణ పాడ్ నెట్‌వర్క్
అదే సమయంలో, ఫలితంగా వచ్చిన etcdhelperని ఉపయోగించి పాడ్‌నెట్‌వర్క్‌ని ఎలా సవరించాలో చూడాలని మేము నిర్ణయించుకున్నాము. చర్యల క్రమం క్రింది విధంగా ఉంది:
- కాన్ఫిగరేషన్‌లను పరిష్కరించడం
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/165. పోడ్‌సిఐడిఆర్ నిజంగా మారిందో లేదో చూద్దాం:
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 ప్రారంభించబడదు మరియు క్లస్టర్‌లోని పాడ్‌లు షెడ్యూల్ చేయబడవు.
నిజానికి, పాడ్‌సిఐడిఆర్‌ని మార్చడం మరింత సరళంగా చేయవచ్చు (ఉదాహరణకు, ) కానీ మేము etcdతో నేరుగా ఎలా పని చేయాలో నేర్చుకోవాలనుకుంటున్నాము, ఎందుకంటే etcdలో Kubernetes ఆబ్జెక్ట్‌లను సవరించేటప్పుడు సందర్భాలు ఉన్నాయి - మాత్రమే సాధ్యం వేరియంట్. (ఉదాహరణకు, మీరు డౌన్‌టైమ్ లేకుండా సేవా ఫీల్డ్‌ను మార్చలేరు spec.clusterIP.)
ఫలితం
వ్యాసం నేరుగా etcdలో డేటాతో పని చేసే అవకాశాన్ని చర్చిస్తుంది, అనగా. కుబెర్నెట్స్ APIని దాటవేయడం. కొన్నిసార్లు ఈ విధానం మిమ్మల్ని "గమ్మత్తైన పనులు" చేయడానికి అనుమతిస్తుంది. మేము నిజమైన K8s క్లస్టర్‌లపై టెక్స్ట్‌లో ఇచ్చిన ఆపరేషన్‌లను పరీక్షించాము. అయినప్పటికీ, విస్తృత ఉపయోగం కోసం వారి సంసిద్ధత యొక్క స్థితి PoC (కాన్సెప్ట్ రుజువు). కాబట్టి, మీరు మీ క్లస్టర్‌లలో etcdhelper యుటిలిటీ యొక్క సవరించిన సంస్కరణను ఉపయోగించాలనుకుంటే, మీ స్వంత పూచీతో అలా చేయండి.
PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com