સીધો 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 આ સબનેટને ક્લસ્ટરમાંથી ક્લાયન્ટ તરફ ધકેલે છે.
• અમારી પાસે ઘણા ક્લસ્ટરો છે (ઉત્પાદન, સ્ટેજ અને/અથવા કેટલાક ડેવ ક્લસ્ટર). પછી, મૂળભૂત રીતે, તે બધામાં પોડ્સ અને સેવાઓ માટે સમાન સબનેટ હશે, જે અનેક ક્લસ્ટરોમાં સેવાઓ સાથે એકસાથે કામ કરવા માટે મોટી મુશ્કેલીઓ ઊભી કરે છે.

અમે લાંબા સમય પહેલા એક પ્રોજેક્ટમાં સેવાઓ અને પોડ્સ માટે અલગ-અલગ સબનેટનો ઉપયોગ કરવાની પ્રથા અપનાવી છે - સામાન્ય રીતે, જેથી તમામ ક્લસ્ટરમાં અલગ-અલગ નેટવર્ક હોય. જો કે, ત્યાં મોટી સંખ્યામાં ક્લસ્ટરો કાર્યરત છે જેને હું શરૂઆતથી રોલ ઓવર કરવા માંગતો નથી, કારણ કે તેઓ ઘણી સેવાઓ, સ્ટેટફુલ એપ્લિકેશન્સ વગેરે ચલાવે છે.

અને પછી અમે અમારી જાતને પૂછ્યું: હાલના ક્લસ્ટરમાં સબનેટ કેવી રીતે બદલવું?

નિર્ણયોની શોધ

સૌથી સામાન્ય પ્રથા ફરીથી બનાવવાની છે બધા ક્લસ્ટરઆઈપી પ્રકાર સાથે સેવાઓ. વિકલ્પ તરીકે, સલાહ આપી શકે છે અને આ:

નીચેની પ્રક્રિયામાં સમસ્યા છે: બધું ગોઠવ્યા પછી, /etc/resolv.conf માં DNS નેમસર્વર તરીકે પોડ્સ જૂના IP સાથે આવે છે.
મને હજુ પણ ઉકેલ ન મળ્યો હોવાથી, મારે kubeadm રીસેટ સાથે આખા ક્લસ્ટરને રીસેટ કરવું પડ્યું અને તેને ફરીથી શરૂ કરવું પડ્યું.

પરંતુ આ દરેક માટે યોગ્ય નથી... અમારા કેસ માટે અહીં વધુ વિગતવાર પરિચય છે:

• ફલેનલનો ઉપયોગ થાય છે;
• વાદળોમાં અને હાર્ડવેર બંનેમાં ક્લસ્ટરો છે;
• હું ક્લસ્ટરમાં તમામ સેવાઓને ફરીથી જમાવવાનું ટાળવા માંગુ છું;
• સામાન્ય રીતે ન્યૂનતમ સંખ્યામાં સમસ્યાઓ સાથે બધું કરવાની જરૂર છે;
• Kubernetes સંસ્કરણ 1.16.6 છે (જો કે, આગળનાં પગલાં અન્ય સંસ્કરણો માટે સમાન હશે);
• મુખ્ય કાર્ય એ સુનિશ્ચિત કરવાનું છે કે સેવા સબનેટ સાથે kubeadm નો ઉપયોગ કરીને જમાવટ કરેલ ક્લસ્ટરમાં 192.168.0.0/16, તેની સાથે બદલો 172.24.0.0/16.

અને એવું બન્યું કે અમને લાંબા સમયથી એ જોવામાં રસ હતો કે કુબરનેટ્સ વગેરે વગેરેમાં શું અને કેવી રીતે સંગ્રહિત છે, તેની સાથે શું કરી શકાય છે... તેથી અમે વિચાર્યું: “જૂના IP એડ્રેસ (સબનેટ) ને નવા સાથે બદલીને, ફક્ત etcd માં ડેટા કેમ અપડેટ ન કરો?

etcd માં ડેટા સાથે કામ કરવા માટે તૈયાર સાધનોની શોધ કર્યા પછી, અમને એવું કંઈ મળ્યું નથી કે જે સમસ્યાને સંપૂર્ણપણે હલ કરે. (માર્ગ દ્વારા, જો તમે etcd માં સીધા ડેટા સાથે કામ કરવા માટેની કોઈપણ ઉપયોગિતાઓ વિશે જાણો છો, તો અમે લિંક્સની પ્રશંસા કરીશું.) જો કે, એક સારો પ્રારંભિક બિંદુ છે વગેરે સહાયક ઓપનશિફ્ટમાંથી (તેના લેખકોને આભાર!).

આ ઉપયોગિતા પ્રમાણપત્રોનો ઉપયોગ કરીને etcd સાથે જોડાઈ શકે છે અને આદેશોનો ઉપયોગ કરીને ત્યાંથી ડેટા વાંચી શકે છે ls, get, dump.

વગેરે સહાયક ઉમેરો

આગળનો વિચાર તાર્કિક છે: " etcd માં ડેટા લખવાની ક્ષમતા ઉમેરીને તમને આ ઉપયોગિતા ઉમેરવાથી શું રોકે છે?"

તે બે નવા કાર્યો સાથે etcdhelper નું સંશોધિત સંસ્કરણ બન્યું changeServiceCIDR и changePodCIDR. તેના પર તમે કોડ જોઈ શકો છો અહીં.

નવી સુવિધાઓ શું કરે છે? અલ્ગોરિધમ changeServiceCIDR:

• એક deserializer બનાવો;
• CIDR ને બદલવા માટે નિયમિત અભિવ્યક્તિનું સંકલન કરો;
• અમે ક્લસ્ટરમાં ClusterIP પ્રકાર સાથેની બધી સેવાઓમાંથી પસાર થઈએ છીએ:
  • ગો ઑબ્જેક્ટમાં etcd માંથી મૂલ્ય ડીકોડ કરો;
  • નિયમિત અભિવ્યક્તિનો ઉપયોગ કરીને અમે સરનામાંના પ્રથમ બે બાઇટ્સ બદલીએ છીએ;
  • સેવાને નવા સબનેટમાંથી IP સરનામું સોંપો;
  • સીરીયલાઇઝર બનાવો, ગો ઓબ્જેક્ટને પ્રોટોબફમાં કન્વર્ટ કરો, વગેરેમાં નવો ડેટા લખો.

કાર્ય changePodCIDR અનિવાર્યપણે સમાન changeServiceCIDR - ફક્ત સેવા સ્પષ્ટીકરણને સંપાદિત કરવાને બદલે, અમે તે નોડ અને ફેરફાર માટે કરીએ છીએ .spec.PodCIDR નવા સબનેટ પર.

પ્રેક્ટિસ

સેવા CIDR બદલો

કાર્યને અમલમાં મૂકવા માટેની યોજના ખૂબ જ સરળ છે, પરંતુ તેમાં ડાઉનટાઇમનો સમાવેશ થાય છે જ્યારે ક્લસ્ટરમાં તમામ પોડ્સ ફરીથી બનાવવામાં આવે છે. મુખ્ય પગલાઓનું વર્ણન કર્યા પછી, અમે સિદ્ધાંતમાં, આ ડાઉનટાઇમને કેવી રીતે ઘટાડી શકાય તે અંગેના વિચારો પણ શેર કરીશું.

તૈયારીના પગલાં:

• જરૂરી સોફ્ટવેર ઇન્સ્ટોલ કરવું અને પેચ કરેલ વગેરે હેલ્પરને એસેમ્બલ કરવું;
• બેકઅપ વગેરે અને /etc/kubernetes.

સર્વિસસીઆઈડીઆર બદલવા માટે સંક્ષિપ્ત એક્શન પ્લાન:

• apiserver અને કંટ્રોલર-મેનેજર મેનિફેસ્ટ બદલવું;
• પ્રમાણપત્રો ફરીથી જારી;
• વગેરેમાં ક્લસ્ટરઆઈપી સેવાઓ બદલવી;
• ક્લસ્ટરમાં તમામ શીંગો પુનઃપ્રારંભ કરો.

નીચેની વિગતવાર ક્રિયાઓનો સંપૂર્ણ ક્રમ છે.

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. કારણ કે અમે સેવા સબનેટ બદલી રહ્યા છીએ જેમાં 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. માટે રૂપરેખા પુનઃજનરેટ કરીએ admin.conf:

   kubeadm alpha certs renew admin.conf

8. ચાલો ડેટાને વગેરેમાં સંપાદિત કરીએ:

   ./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. બધા કુબેલેટમાં સરનામું બદલો ClusterDNS નવી સેવા માટે, જ્યારે જૂની સેવા નવી સાથે એકસાથે કામ કરવાનું ચાલુ રાખશે.
4. પ્રાકૃતિક કારણોસર અથવા સંમત સમયે એપ્લિકેશન સાથેના શીંગો જાતે જ ફેરવાઈ જાય ત્યાં સુધી રાહ જુઓ.
5. સેવા કાઢી નાખો kube-dns-tmp અને બદલો serviceSubnetCIDR kube-dns સેવા માટે.

આ યોજના તમને સેવા દૂર કરવાના સમયગાળા માટે ડાઉનટાઇમને ~એક મિનિટ સુધી ઘટાડવાની મંજૂરી આપશે kube-dns-tmp અને સેવા માટે સબનેટ બદલવું kube-dns.

ફેરફાર પોડનેટવર્ક

તે જ સમયે, અમે પરિણામી etcdhelper નો ઉપયોગ કરીને પોડનેટવર્કને કેવી રીતે સંશોધિત કરવું તે જોવાનું નક્કી કર્યું. ક્રિયાઓનો ક્રમ નીચે મુજબ છે:

• માં રૂપરેખાઓ ફિક્સિંગ kube-system;
• kube-controller-manager મેનિફેસ્ટને ઠીક કરવું;
• podCIDR સીધા etcd માં બદલો;
• બધા ક્લસ્ટર નોડ્સ રીબુટ કરો.

હવે આ ક્રિયાઓ વિશે વધુ:

1. નેમસ્પેસમાં ConfigMaps ને સંશોધિત કરો 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. ચાલો તપાસીએ કે પોડસીઆઈડીઆર ખરેખર બદલાઈ ગયું છે:

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. જો તમે ઓછામાં ઓછું એક નોડ છોડો છો જૂના પોડસીઆઈડીઆર, તો kube-controller-manager શરૂ કરી શકશે નહીં, અને ક્લસ્ટરમાં પોડ્સ શેડ્યૂલ કરવામાં આવશે નહીં.

વાસ્તવમાં, પોડસીઆઈડીઆર બદલવું વધુ સરળ પણ કરી શકાય છે (ઉદાહરણ તરીકે, તેથી). પરંતુ અમે સીધા etcd સાથે કેવી રીતે કામ કરવું તે શીખવા માગતા હતા, કારણ કે કુબરનેટ્સ ઑબ્જેક્ટ્સ વગેરેમાં સંપાદિત કરતી વખતે એવા કિસ્સાઓ છે - માત્ર શક્ય પ્રકાર. (ઉદાહરણ તરીકે, તમે ડાઉનટાઇમ વિના ફક્ત સેવા ક્ષેત્ર બદલી શકતા નથી spec.clusterIP.)

પરિણામ

લેખ વગેરેમાં ડેટા સાથે સીધી રીતે કામ કરવાની શક્યતાની ચર્ચા કરે છે, એટલે કે. Kubernetes API ને બાયપાસ કરીને. કેટલીકવાર આ અભિગમ તમને "મુશ્કેલ વસ્તુઓ" કરવાની મંજૂરી આપે છે. અમે વાસ્તવિક K8s ક્લસ્ટરો પર ટેક્સ્ટમાં આપેલ ઑપરેશન્સનું પરીક્ષણ કર્યું. જો કે, વ્યાપક ઉપયોગ માટે તેમની તત્પરતાની સ્થિતિ છે PoC (વિભાવનાનો પુરાવો). તેથી, જો તમે તમારા ક્લસ્ટરો પર etcdhelper ઉપયોગિતાના સંશોધિત સંસ્કરણનો ઉપયોગ કરવા માંગતા હો, તો તે તમારા પોતાના જોખમે કરો.

PS

અમારા બ્લોગ પર પણ વાંચો:

• «etcd 3.4.3: સંગ્રહની વિશ્વસનીયતા અને સુરક્ષાનો અભ્યાસ»;
• «કુબરનેટ્સમાં નેટવર્કિંગ માટે કેલિકો: પરિચય અને થોડો અનુભવ»;
• «કુબરનેટ્સના સંચાલનમાં 6 મનોરંજક સિસ્ટમ બગ્સ [અને તેમના ઉકેલ]»;
• «કુબરનેટ્સના મુશ્કેલીનિવારણ માટે વિઝ્યુઅલ માર્ગદર્શિકા».

સોર્સ: www.habr.com