etcd Kubernetes පොකුරේ දත්ත සමඟ අපගේ අත්දැකීම් සෘජුවම (K8s API නොමැතිව)

පොකුර තුළ සේවාවන් වෙත ප්‍රවේශ වීමට Kubernetes පොකුරට ප්‍රවේශය ලබා දෙන ලෙස සේවාදායකයින් වැඩි වැඩියෙන් අපෙන් ඉල්ලා සිටී: යම් දත්ත සමුදායකට හෝ සේවාවකට සෘජුවම සම්බන්ධ වීමට, පොකුර තුළ ඇති යෙදුම් සමඟ දේශීය යෙදුමක් සම්බන්ධ කිරීමට...

etcd Kubernetes පොකුරේ දත්ත සමඟ අපගේ අත්දැකීම් සෘජුවම (K8s API නොමැතිව)

උදාහරණයක් ලෙස, ඔබගේ දේශීය යන්ත්‍රයෙන් සේවාවකට සම්බන්ධ වීමට අවශ්‍ය වේ memcached.staging.svc.cluster.local. අපි සේවාදායකයා සම්බන්ධ කරන පොකුර තුළ VPN භාවිතයෙන් මෙම හැකියාව ලබා දෙන්නෙමු. මෙය සිදු කිරීම සඳහා, අපි පොඩ්ස්, සේවා සහ Push Cluster DNS හි අනුජාල සේවාලාභියාට නිවේදනය කරමු. මේ අනුව, සේවාදායකයා සේවාවට සම්බන්ධ වීමට උත්සාහ කරන විට memcached.staging.svc.cluster.local, ඉල්ලීම පොකුරු DNS වෙත යන අතර ප්‍රතිචාර වශයෙන් මෙම සේවාවේ ලිපිනය පොකුරු සේවා ජාලයෙන් හෝ පොඩ් ලිපිනයෙන් ලැබේ.

පෙරනිමි සේවා උපජාලය ඇති kubeadm භාවිතයෙන් අපි K8s පොකුරු වින්‍යාස කරමු. 192.168.0.0/16, සහ කරල් ජාලය වේ 10.244.0.0/16. සාමාන්යයෙන් සෑම දෙයක්ම හොඳින් ක්රියා කරයි, නමුත් කරුණු කිහිපයක් තිබේ:

  • උපජාලය 192.168.*.* බොහෝ විට සේවාලාභී කාර්යාල ජාල වල සහ බොහෝ විට සංවර්ධක නිවාස ජාල වල භාවිතා වේ. එවිට අපට ගැටුම් ඇති වේ: නිවසේ රවුටර මෙම උපජාලයේ ක්‍රියා කරන අතර VPN මෙම උපජාල පොකුරෙන් සේවාදායකයා වෙත තල්ලු කරයි.
  • අපට පොකුරු කිහිපයක් ඇත (නිෂ්පාදනය, අදියර සහ/හෝ dev පොකුරු කිහිපයක්). එවිට, පෙරනිමියෙන්, ඒවා සියල්ලම පොඩ් සහ සේවා සඳහා එකම අනුජාල ඇති අතර, එය පොකුරු කිහිපයක සේවා සමඟ එකවර වැඩ කිරීම සඳහා විශාල දුෂ්කරතා ඇති කරයි.

අපි බොහෝ කලකට පෙර එකම ව්‍යාපෘතිය තුළ සේවා සහ පොඩ් සඳහා විවිධ උපජාල භාවිතා කිරීමේ පුරුද්ද අනුගමනය කර ඇත්තෙමු - සාමාන්‍යයෙන්, සියලුම පොකුරුවලට විවිධ ජාල ඇත. කෙසේ වෙතත්, ඒවා බොහෝ සේවා, රාජ්‍ය යෙදුම් ආදිය ක්‍රියාත්මක කරන බැවින් මුල සිටම පෙරළීමට මා කැමති නැති පොකුරු විශාල ප්‍රමාණයක් ක්‍රියාත්මක වේ.

ඉන්පසුව අපි අපෙන්ම මෙසේ ඇසුවෙමු: පවතින පොකුරක් තුළ උපජාලය වෙනස් කරන්නේ කෙසේද?

තීරණ සෙවීම

වඩාත් පොදු භාවිතය වන්නේ නැවත නිර්මාණය කිරීමයි සියල්ල ClusterIP වර්ගය සහිත සේවාවන්. විකල්පයක් ලෙස, උපදෙස් දිය හැකිය සහ මෙය:

පහත ක්‍රියාවලියේ ගැටලුවක් ඇත: සියල්ල වින්‍යාස කළ පසු, /etc/resolv.conf හි DNS නාම සේවාදායකයක් ලෙස කරල් පැරණි IP සමඟ පැමිණේ.
මට තවමත් විසඳුම සොයාගත නොහැකි වූ නිසා, මට මුළු පොකුරම kubeadm reset සමඟ නැවත සකස් කර එය නැවත ආරම්භ කිරීමට සිදු විය.

නමුත් මෙය සෑම කෙනෙකුටම සුදුසු නොවේ ... අපගේ නඩුව සඳහා වඩාත් සවිස්තරාත්මක හැඳින්වීම් මෙන්න:

  • Flannel භාවිතා වේ;
  • වලාකුළු සහ දෘඪාංග යන දෙකෙහිම පොකුරු ඇත;
  • පොකුරේ සියලුම සේවාවන් නැවත යෙදවීම වැළැක්වීමට මම කැමතියි;
  • සාමාන්‍යයෙන් අවම ගැටලු සංඛ්‍යාවක් සමඟ සෑම දෙයක්ම කිරීමට අවශ්‍ය වේ;
  • Kubernetes අනුවාදය 1.16.6 (කෙසේ වෙතත්, අනෙකුත් අනුවාද සඳහා ඉදිරි පියවර සමාන වනු ඇත);
  • ප්‍රධාන කාර්යය වන්නේ සේවා උපජාලයක් සමඟ kubeadm භාවිතා කර ඇති පොකුරක් තුළ බව සහතික කිරීමයි 192.168.0.0/16, එය වෙනුවට 172.24.0.0/16.

Kubernetes හි ගබඩා කර ඇත්තේ කුමක්ද සහ කෙසේද, එය සමඟ කළ හැක්කේ කුමක්ද යන්න දැකීමට අපි බොහෝ කලක සිට උනන්දු වී සිටි නිසා එය සිදු විය ... එබැවින් අපි මෙසේ සිතුවෙමු: "පැරණි IP ලිපින (උපජාලය) නව ඒවා සමඟ ප්‍රතිස්ථාපනය කරමින් etcd හි දත්ත යාවත්කාලීන නොකරන්නේ මන්ද?? »

etcd හි දත්ත සමඟ වැඩ කිරීම සඳහා සූදානම් කළ මෙවලම් සෙවීමෙන් පසුව, ගැටළුව සම්පූර්ණයෙන්ම විසඳන කිසිවක් අපට හමු නොවීය. (මාර්ගය වන විට, දත්ත සමඟ සෘජුවම etcd හි වැඩ කිරීම සඳහා යම් උපයෝගිතා ගැන ඔබ දන්නේ නම්, අපි සබැඳි අගය කරන්නෙමු.) කෙසේ වෙතත්, හොඳ ආරම්භක ලක්ෂ්යයකි etcdhelper OpenShift වෙතින් (එහි කතුවරුන්ට ස්තුතියි!).

මෙම උපයෝගීතාවයට සහතික භාවිතයෙන් etcd වෙත සම්බන්ධ විය හැකි අතර විධාන භාවිතයෙන් එහි දත්ත කියවීමට හැකිය ls, get, dump.

etcdhelper එකතු කරන්න

මීළඟ සිතුවිල්ල තාර්කික ය: "etcd වෙත දත්ත ලිවීමේ හැකියාව එකතු කිරීමෙන් මෙම උපයෝගීතාව එකතු කිරීමෙන් ඔබව වළක්වන්නේ කුමක්ද?"

එය නව කාර්යයන් දෙකක් සහිත etcdhelper හි නවීකරණය කරන ලද අනුවාදයක් බවට පත් විය changeServiceCIDR и changePodCIDR. ඇය මත ඔබට කේතය දැකිය හැකිය මෙහි.

නව විශේෂාංග කරන්නේ කුමක්ද? ඇල්ගොරිතම changeServiceCIDR:

  • deserializer නිර්මාණය කරන්න;
  • CIDR වෙනුවට නිත්‍ය ප්‍රකාශනයක් සම්පාදනය කරන්න;
  • අපි පොකුරේ ClusterIP වර්ගය සමඟ සියලුම සේවාවන් හරහා යන්නෙමු:
    • etcd සිට Go වස්තුවකට අගය විකේතනය කරන්න;
    • නිත්‍ය ප්‍රකාශනයක් භාවිතා කරමින් අපි ලිපිනයේ පළමු බයිට් දෙක ප්‍රතිස්ථාපනය කරමු;
    • නව උපජාලයෙන් සේවාවට IP ලිපිනයක් පවරන්න;
    • Serializer එකක් සාදන්න, Go object එක protobuf බවට පරිවර්තනය කරන්න, etcd වලට නව දත්ත ලියන්න.

උත්සවය changePodCIDR අත්යවශ්යයෙන්ම සමානයි changeServiceCIDR - සේවා පිරිවිතර සංස්කරණය කිරීම වෙනුවට, අපි එය නෝඩය සහ වෙනස් කිරීම සඳහා කරන්නෙමු .spec.PodCIDR නව උපජාලයකට.

පුහුණු වන්න

CIDR සේවාව වෙනස් කරන්න

කාර්යය ක්රියාත්මක කිරීම සඳහා සැලැස්ම ඉතා සරල ය, නමුත් එය පොකුරේ සියලුම කරල් නැවත නිර්මාණය කරන අවස්ථාවේ දී අක්රිය වීම ඇතුළත් වේ. ප්‍රධාන පියවර විස්තර කිරීමෙන් පසු, න්‍යායාත්මකව, මෙම අක්‍රීය කාලය අවම කර ගත හැකි ආකාරය පිළිබඳ අදහස් ද අපි බෙදා ගන්නෙමු.

සූදානම් වීමේ පියවර:

  • අවශ්ය මෘදුකාංග ස්ථාපනය කිරීම සහ පැච් කරන ලද etcdhelper එකලස් කිරීම;
  • උපස්ථ ආදිය සහ /etc/kubernetes.

CIDR සේවාව වෙනස් කිරීම සඳහා කෙටි ක්‍රියාකාරී සැලැස්ම:

  • apiserver සහ controller-manager ප්‍රකාශනය වෙනස් කිරීම;
  • සහතික නැවත නිකුත් කිරීම;
  • ආදියෙහි ClusterIP සේවා වෙනස් කිරීම;
  • පොකුරේ ඇති සියලුම කරල් නැවත ආරම්භ කරන්න.

පහත දැක්වෙන්නේ විස්තරාත්මකව සම්පූර්ණ ක්‍රියා අනුපිළිවෙලකි.

1. දත්ත ඩම්ප් සඳහා etcd-Client ස්ථාපනය කරන්න:

apt install etcd-client

2. etcdhelper ගොඩනැගීම:

  • golang ස්ථාපනය කරන්න:
    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. අපි apiserver (ඇතුළු) සඳහා kubeadm සහතික නිකුත් කරන සේවා උපජාලය වෙනස් කරන බැවින්, ඒවා නැවත නිකුත් කළ යුතුය:

  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. අපි 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.

PodNetwork වෙනස් කිරීම

ඒ සමඟම, ප්‍රතිඵලයක් ලෙස ලැබෙන etcdhelper භාවිතයෙන් podNetwork වෙනස් කරන්නේ කෙසේදැයි බැලීමට අපි තීරණය කළෙමු. ක්රියා අනුපිළිවෙල පහත පරිදි වේ:

  • වින්‍යාස සවි කිරීම kube-system;
  • kube-controller-manager මැනිෆෙස්ටය සවි කිරීම;
  • 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 සමඟ කෙලින්ම වැඩ කරන්නේ කෙසේදැයි ඉගෙන ගැනීමට අවශ්‍ය විය, මන්ද Kubernetes objects etcd හි සංස්කරණය කිරීමේදී අවස්ථා ඇති බැවිනි - එකම හැකි ප්රභේදය. (උදාහරණයක් ලෙස, ඔබට අක්‍රීය කාලයකින් තොරව සේවා ක්ෂේත්‍රය වෙනස් කළ නොහැක spec.clusterIP.)

ප්රතිඵලය

ලිපිය සෘජුවම etcd හි දත්ත සමඟ වැඩ කිරීමේ හැකියාව ගැන සාකච්ඡා කරයි, i.e. Kubernetes API මඟ හැරීම. සමහර විට මෙම ප්රවේශය ඔබට "උපක්රම දේවල්" කිරීමට ඉඩ සලසයි. අපි සැබෑ K8s පොකුරු මත පෙළෙහි දක්වා ඇති මෙහෙයුම් පරීක්ෂා කළෙමු. කෙසේ වෙතත්, පුළුල් භාවිතය සඳහා ඔවුන්ගේ සූදානමේ තත්ත්වය PoC (සංකල්පයේ සාක්ෂි). එබැවින්, ඔබට ඔබේ පොකුරු මත etcdhelper උපයෝගීතාවයේ නවීකරණය කරන ලද අනුවාදයක් භාවිතා කිරීමට අවශ්‍ය නම්, එය ඔබගේම අවදානමෙන් කරන්න.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න