সরাসরি etcd Kubernetes ক্লাস্টারে ডেটা নিয়ে আমাদের অভিজ্ঞতা (K8s API ছাড়া)

ক্রমবর্ধমানভাবে, ক্লায়েন্টরা ক্লাস্টারের মধ্যে পরিষেবাগুলি অ্যাক্সেস করতে সক্ষম হওয়ার জন্য Kubernetes ক্লাস্টারে অ্যাক্সেস প্রদান করতে বলছে: কিছু ডাটাবেস বা পরিষেবার সাথে সরাসরি সংযোগ করতে সক্ষম হতে, ক্লাস্টারের মধ্যে থাকা অ্যাপ্লিকেশনগুলির সাথে একটি স্থানীয় অ্যাপ্লিকেশন সংযোগ করতে...

উদাহরণস্বরূপ, আপনার স্থানীয় মেশিন থেকে একটি পরিষেবাতে সংযোগ করার প্রয়োজন আছে 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.*.* প্রায়শই ক্লায়েন্ট অফিস নেটওয়ার্কে ব্যবহৃত হয়, এমনকি আরও প্রায়ই ডেভেলপার হোম নেটওয়ার্কে। এবং তারপরে আমরা দ্বন্দ্ব পাই: হোম রাউটারগুলি এই সাবনেটে কাজ করে এবং ভিপিএন এই সাবনেটগুলিকে ক্লাস্টার থেকে ক্লায়েন্টের কাছে ঠেলে দেয়।
• আমাদের বেশ কয়েকটি ক্লাস্টার রয়েছে (উৎপাদন, পর্যায় এবং/অথবা বেশ কয়েকটি ডেভ ক্লাস্টার)। তারপর, ডিফল্টরূপে, তাদের সকলের পড এবং পরিষেবাগুলির জন্য একই সাবনেট থাকবে, যা বিভিন্ন ক্লাস্টারে পরিষেবাগুলির সাথে একযোগে কাজ করার জন্য দুর্দান্ত অসুবিধা সৃষ্টি করে।

আমরা অনেক আগেই একই প্রকল্পের মধ্যে পরিষেবা এবং পডের জন্য বিভিন্ন সাবনেট ব্যবহার করার অভ্যাস গ্রহণ করেছি - সাধারণভাবে, যাতে সমস্ত ক্লাস্টারের বিভিন্ন নেটওয়ার্ক থাকে। যাইহোক, প্রচুর সংখ্যক ক্লাস্টার রয়েছে যেগুলি আমি স্ক্র্যাচ থেকে রোল ওভার করতে চাই না, যেহেতু তারা অনেক পরিষেবা, রাষ্ট্রীয় অ্যাপ্লিকেশন ইত্যাদি চালায়।

এবং তারপরে আমরা নিজেদেরকে জিজ্ঞাসা করেছি: কীভাবে একটি বিদ্যমান ক্লাস্টারে সাবনেট পরিবর্তন করবেন?

সিদ্ধান্ত অনুসন্ধান

সবচেয়ে সাধারণ অভ্যাস হল পুনরায় তৈরি করা সব ClusterIP টাইপ সহ পরিষেবা। একটি বিকল্প হিসাবে, পরামর্শ দিতে পারেন এবং এই:

নিম্নলিখিত প্রক্রিয়াটিতে একটি সমস্যা রয়েছে: সবকিছু কনফিগার করার পরে, পডগুলি /etc/resolv.conf-এ একটি DNS নেমসার্ভার হিসাবে পুরানো আইপি নিয়ে আসে।
যেহেতু আমি এখনও সমাধানটি খুঁজে পাইনি, তাই আমাকে kubeadm রিসেটের সাথে পুরো ক্লাস্টারটি পুনরায় সেট করতে হয়েছিল এবং এটি আবার শুরু করতে হয়েছিল।

কিন্তু এটি সবার জন্য উপযুক্ত নয়... এখানে আমাদের ক্ষেত্রে আরো বিস্তারিত ভূমিকা রয়েছে:

• ফ্ল্যানেল ব্যবহার করা হয়;
• মেঘ এবং হার্ডওয়্যারে উভয় ক্লাস্টার আছে;
• আমি ক্লাস্টারে সমস্ত পরিষেবা পুনরায় স্থাপন করা এড়াতে চাই;
• সাধারণত ন্যূনতম সংখ্যক সমস্যা সহ সবকিছু করার প্রয়োজন রয়েছে;
• Kubernetes সংস্করণ হল 1.16.6 (তবে, পরবর্তী পদক্ষেপগুলি অন্যান্য সংস্করণগুলির জন্য একই রকম হবে);
• একটি পরিষেবা সাবনেটের সাথে kubeadm ব্যবহার করে একটি ক্লাস্টারে স্থাপন করা হয়েছে তা নিশ্চিত করাই প্রধান কাজ 192.168.0.0/16, এটি দিয়ে প্রতিস্থাপন করুন 172.24.0.0/16.

এবং এটি ঠিক তাই ঘটেছে যে আমরা অনেক আগে থেকেই দেখতে আগ্রহী ছিলাম কুবারনেটেসে কী এবং কীভাবে etcd তে সংরক্ষণ করা হয়, এটি দিয়ে কী করা যায়... তাই আমরা ভেবেছিলাম: "কেন শুধু etcd-এ ডেটা আপডেট করবেন না, পুরানো IP ঠিকানাগুলি (সাবনেট) নতুন দিয়ে প্রতিস্থাপন করুন? "

etcd-এ ডেটা নিয়ে কাজ করার জন্য প্রস্তুত-তৈরি সরঞ্জামগুলি অনুসন্ধান করার পরে, আমরা এমন কিছু খুঁজে পাইনি যা সম্পূর্ণরূপে সমস্যার সমাধান করেছে। (যাইহোক, আপনি যদি etcd-এ সরাসরি ডেটা নিয়ে কাজ করার জন্য কোনো ইউটিলিটি সম্পর্কে জানেন, আমরা লিঙ্কগুলির প্রশংসা করব।) যাইহোক, একটি ভাল সূচনা পয়েন্ট etcdhelper OpenShift থেকে (এর লেখকদের ধন্যবাদ!).

এই ইউটিলিটি সার্টিফিকেট ব্যবহার করে etcd এর সাথে সংযোগ করতে পারে এবং কমান্ড ব্যবহার করে সেখান থেকে ডেটা পড়তে পারে ls, get, dump.

etcdhelper যোগ করুন

পরবর্তী চিন্তাটি যৌক্তিক: "ইত্যাদিতে ডেটা লেখার ক্ষমতা যোগ করে এই ইউটিলিটি যোগ করা থেকে আপনাকে কী বাধা দিচ্ছে?"

এটি দুটি নতুন ফাংশন সহ etcdhelper-এর একটি পরিবর্তিত সংস্করণে পরিণত হয়েছে changeServiceCIDR и changePodCIDR. তার উপর আপনি কোড দেখতে পারেন এখানে.

নতুন বৈশিষ্ট্যগুলি কী করে? অ্যালগরিদম changeServiceCIDR:

• একটি deserializer তৈরি করুন;
• CIDR প্রতিস্থাপনের জন্য একটি রেগুলার এক্সপ্রেশন কম্পাইল করুন;
• আমরা ক্লাস্টারে ClusterIP প্রকারের সাথে সমস্ত পরিষেবার মধ্য দিয়ে যাই:
  • একটি Go অবজেক্টে etcd থেকে মান ডিকোড করুন;
  • একটি নিয়মিত অভিব্যক্তি ব্যবহার করে আমরা ঠিকানার প্রথম দুটি বাইট প্রতিস্থাপন করি;
  • নতুন সাবনেট থেকে পরিষেবাটিকে একটি আইপি ঠিকানা বরাদ্দ করুন;
  • একটি সিরিয়ালাইজার তৈরি করুন, Go অবজেক্টটিকে প্রোটোবাফে রূপান্তর করুন, etcd-এ নতুন ডেটা লিখুন।

ক্রিয়া changePodCIDR মূলত অনুরূপ changeServiceCIDR - শুধুমাত্র পরিষেবার স্পেসিফিকেশন সম্পাদনা করার পরিবর্তে, আমরা নোড এবং পরিবর্তনের জন্য এটি করি .spec.PodCIDR একটি নতুন সাবনেটে।

অনুশীলন

পরিষেবা CIDR পরিবর্তন করুন

টাস্ক বাস্তবায়নের পরিকল্পনাটি খুবই সহজ, তবে ক্লাস্টারের সমস্ত পড পুনরায় তৈরি করার সময় এটি ডাউনটাইম জড়িত। মূল পদক্ষেপগুলি বর্ণনা করার পরে, আমরা কীভাবে তাত্ত্বিকভাবে, এই ডাউনটাইমটি কমিয়ে আনা যায় সে সম্পর্কেও চিন্তাভাবনা ভাগ করব।

প্রস্তুতিমূলক পদক্ষেপ:

• প্রয়োজনীয় সফ্টওয়্যার ইনস্টল করা এবং প্যাচ করা etcdhelper একত্রিত করা;
• ব্যাকআপ etcd এবং /etc/kubernetes.

সার্ভিসসিআইডিআর পরিবর্তনের জন্য সংক্ষিপ্ত কর্ম পরিকল্পনা:

• এপিসার্ভার এবং কন্ট্রোলার-ম্যানেজার পরিবর্তন করা;
• সার্টিফিকেট পুনরায় প্রদান;
• ইত্যাদিতে 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. Kubernetes কন্ট্রোল প্লেন ম্যানিফেস্টে পরিষেবা সাবনেট পরিবর্তন করুন। ফাইলে /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. চলুন দেখি কোন ডোমেন এবং আইপি ঠিকানার জন্য বর্তমান সার্টিফিকেট জারি করা হয়েছে:

   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. এপিআই সার্ভারের জন্য শংসাপত্র পুনরায় জারি করা যাক:

   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 পরিষেবার নতুন আইপি ঠিকানায়: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - আমরা এটা ঠিক করব data.ClusterConfiguration.networking.serviceSubnet একটি নতুন সাবনেটে।

10. যেহেতু kube-dns ঠিকানা পরিবর্তিত হয়েছে, সমস্ত নোডে কুবেলেট কনফিগারেশন আপডেট করা প্রয়োজন:

    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;
• kube-controller-manager ম্যানিফেস্ট ঠিক করা;
• সরাসরি etcd এ podCIDR পরিবর্তন করুন;
• সমস্ত ক্লাস্টার নোড পুনরায় বুট করুন।

এখন এই কর্ম সম্পর্কে আরো:

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. আসুন পরীক্ষা করে দেখি যে পডসিআইডিআর সত্যিই পরিবর্তিত হয়েছে:

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 এর সাথে কিভাবে কাজ করতে হয় তা শিখতে চেয়েছিলাম, কারণ etcd-এ Kubernetes অবজেক্ট এডিট করার সময় এমন কিছু ঘটনা আছে - শুধুমাত্র সম্ভাব্য বৈকল্পিক। (উদাহরণস্বরূপ, আপনি ডাউনটাইম ছাড়াই পরিষেবা ক্ষেত্র পরিবর্তন করতে পারবেন না spec.clusterIP.)

ফলাফল

নিবন্ধটি সরাসরি etcd-এ ডেটা নিয়ে কাজ করার সম্ভাবনা নিয়ে আলোচনা করে, যেমন Kubernetes API বাইপাস করে। কখনও কখনও এই পদ্ধতিটি আপনাকে "কঠিন জিনিস" করতে দেয়। আমরা বাস্তব K8s ক্লাস্টারগুলিতে পাঠ্যে প্রদত্ত ক্রিয়াকলাপগুলি পরীক্ষা করেছি। তবে তাদের ব্যাপক ব্যবহারের জন্য প্রস্তুতির অবস্থা PoC (ধারণার প্রমাণ). অতএব, আপনি যদি আপনার ক্লাস্টারে etcdhelper ইউটিলিটির একটি পরিবর্তিত সংস্করণ ব্যবহার করতে চান, তাহলে তা আপনার নিজের ঝুঁকিতে করুন।

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «etcd 3.4.3: স্টোরেজ নির্ভরযোগ্যতা এবং নিরাপত্তা অধ্যয়ন";
• «কুবারনেটসে নেটওয়ার্কিংয়ের জন্য ক্যালিকো: ভূমিকা এবং সামান্য অভিজ্ঞতা";
• «কুবারনেটসের অপারেশনে 6টি বিনোদনমূলক সিস্টেম বাগ [এবং তাদের সমাধান]";
• «কুবারনেটস সমস্যা সমাধানের জন্য একটি ভিজ্যুয়াল গাইড».

উত্স: www.habr.com