ProHoster > بلاګ > اداره > زموږ تجربه په مستقیم ډول د etcd Kubernetes کلستر کې ډیټا سره (پرته د K8s API)

زموږ تجربه په مستقیم ډول د etcd Kubernetes کلستر کې ډیټا سره (پرته د K8s API)

په زیاتیدونکي توګه، پیرودونکي له موږ څخه غوښتنه کوي چې د کلستر دننه خدماتو ته د لاسرسي لپاره د Kubernetes کلستر ته لاسرسی چمتو کړئ: د دې وړتیا ولرئ چې مستقیم د ځینې ډیټابیس یا خدماتو سره وصل شئ، د کلستر دننه غوښتنلیکونو سره محلي غوښتنلیک سره وصل کړئ ...

زموږ تجربه په مستقیم ډول د etcd Kubernetes کلستر کې ډیټا سره (پرته د K8s API)

د مثال په توګه، ستاسو د محلي ماشین څخه خدمت ته اړتیا شتون لري memcached.staging.svc.cluster.local. موږ دا وړتیا په کلستر کې د VPN په کارولو سره چمتو کوو چې پیرودونکي ورسره وصل وي. د دې کولو لپاره، موږ د پوډونو، خدماتو فرعي نیټ اعلانوو او پیرودونکي ته د کلستر DNS فشار ورکوو. پدې توګه ، کله چې پیرودونکي هڅه کوي خدمت سره وصل شي memcached.staging.svc.cluster.local، غوښتنه کلستر DNS ته ځي او په ځواب کې د کلسټر خدماتو شبکې یا پوډ پته څخه د دې خدمت پته ترلاسه کوي.

موږ د K8s کلسترونه د kubeadm په کارولو سره تنظیم کوو، چیرې چې د ډیفالټ خدمت سبنټ دی 192.168.0.0/16، او د پوډ شبکه ده 10.244.0.0/16. معمولا هرڅه ښه کار کوي، مګر یو څو ټکي شتون لري:

  • Subnet 192.168.*.* ډیری وختونه د پیرودونکي دفتر شبکې کې کارول کیږي، او حتی ډیری وختونه د پراختیا کونکي کور شبکې کې. او بیا موږ شخړې ترلاسه کوو: د کور روټرونه پدې فرعي نیټ کار کوي او VPN دا فرعي نیټونه له کلستر څخه پیرودونکي ته اړوي.
  • موږ څو کلسترونه لرو (تولید، مرحله او/یا څو dev کلسترونه). بیا، د ډیفالټ په واسطه، دا ټول به د پوډونو او خدماتو لپاره ورته فرعي نیټونه ولري، کوم چې په څو کلسترونو کې د خدماتو سره یوځای کار کولو لپاره لوی مشکلات رامینځته کوي.

موږ ډیر دمخه په ورته پروژه کې د خدماتو او پوډونو لپاره د مختلف فرعي نیټونو کارولو تمرین غوره کړی - په عموم کې ، نو ټول کلسترونه مختلف شبکې لري. په هرصورت، په عملیاتو کې ډیری کلسترونه شتون لري چې زه نه غواړم له سکریچ څخه راوګرځم، ځکه چې دوی ډیری خدمتونه، دولتي غوښتنلیکونه، او نور چلوي.

او بیا موږ له ځانه وپوښتل: څنګه په موجوده کلستر کې فرعي نیټ بدل کړو؟

د پریکړو لټون

تر ټولو عام عمل د بیارغونې لپاره دی ټول خدمتونه د ClusterIP ډول سره. د یو اختیار په توګه، مشوره ورکولی شي او دا:

لاندې پروسه ستونزه لري: د هر څه تنظیم کولو وروسته، پوډونه د زاړه IP سره د DNS نوم سرور په توګه په /etc/resolv.conf کې راځي.
له هغه ځایه چې ما لاهم حل ندی موندلی، ما باید ټول کلستر د kubeadm ریسیټ سره تنظیم کړي او بیا یې پیل کړي.

مګر دا د هرچا لپاره مناسب نه دی ... دلته زموږ د قضیې لپاره نور تفصیلي پیژندنې دي:

  • فلالین کارول کیږي؛
  • په بادل او هارډویر کې کلسترونه شتون لري؛
  • زه غواړم په کلستر کې د ټولو خدماتو له بیا ځای پرځای کولو څخه مخنیوی وکړم؛
  • په عمومي توګه د لږ تر لږه ستونزو سره هر څه ته اړتیا ده؛
  • د Kubernetes نسخه 1.16.6 ده (په هرصورت، نور ګامونه به د نورو نسخو لپاره ورته وي)؛
  • اصلي دنده دا ده چې ډاډ ترلاسه شي چې په کلستر کې د خدمت فرعي نیټ سره د kubeadm په کارولو سره ځای په ځای شوي 192.168.0.0/16سره بدل کړئ 172.24.0.0/16.

او دا یوازې داسې پیښ شوي چې موږ له ډیرې مودې راهیسې علاقه درلوده چې وګورو چې څه او څنګه په کبرنیټس کې په etcd کې زیرمه کیږي ، د دې سره څه کیدی شي ... نو موږ فکر وکړ: "ولې یوازې په etcd کې ډاټا تازه نه کړئ، زاړه IP پتې (سبنټ) د نوي سره ځای په ځای کړئ؟ »

په etcd کې د ډیټا سره کار کولو لپاره د چمتو شوي وسیلو لټون کولو سره ، موږ داسې څه ونه موندل چې ستونزه په بشپړ ډول حل کړي. (په لاره کې، که تاسو په etcd کې د ډیټا سره مستقیم کار کولو لپاره د کومې اسانتیاو په اړه پوهیږئ، موږ به د لینکونو ستاینه وکړو.) په هرصورت، یو ښه پیل ټکی دی etc مرسته کوونکی د OpenShift څخه (له لیکوالانو څخه مننه!).

دا افادیت کولی شي د سندونو په کارولو سره etcd سره وصل شي او د کمانډونو په کارولو سره له هغه ځایه ډیټا ولولي ls, get, dump.

etcdhelper اضافه کړئ

بل فکر منطقي دی: "څه شی تاسو د etcd ته د ډیټا لیکلو وړتیا اضافه کولو سره د دې افادیت اضافه کولو څخه منع کوي؟"

دا د دوه نویو دندو سره د etcdhelper بدل شوی نسخه شوه changeServiceCIDR и changePodCIDR. په هغې باندې تاسو کولی شئ کوډ وګورئ دلته.

نوې ځانګړتیاوې څه کوي؟ الګوریتم changeServiceCIDR:

  • deserializer جوړ کړئ؛
  • د CIDR ځای په ځای کولو لپاره منظم بیان تالیف کړئ؛
  • موږ په کلستر کې د ClusterIP ډول سره ټولو خدماتو ته ځو:
    • ارزښت له etcd څخه په Go څیز کې ډیکوډ کړئ؛
    • د منظم بیان په کارولو سره موږ د پتې لومړی دوه بایټونه بدلوو؛
    • خدمت ته د نوي فرعي نیټ څخه IP پته ورکړئ؛
    • سیریلائزر جوړ کړئ، د Go اعتراض په پروټوبف کې بدل کړئ، etcd ته نوي معلومات ولیکئ.

دنده changePodCIDR په اصل کې ورته changeServiceCIDR - یوازې د خدماتو توضیحاتو ترمیم کولو پرځای ، موږ دا د نوډ او بدلون لپاره کوو .spec.PodCIDR نوي فرعي شبکې ته.

تمرین

د خدمت CIDR بدل کړئ

د کار د پلي کولو پلان خورا ساده دی، مګر دا په کلستر کې د ټولو پوډونو د بیا جوړولو په وخت کې ځنډول شامل دي. د اصلي ګامونو له بیانولو وروسته، موږ به په دې اړه هم فکرونه شریک کړو چې څنګه، په تیوري کې، دا وخت کم کیدی شي.

د چمتووالي ګامونه:

  • د اړین سافټویر نصب کول او د پیچ ​​شوي etcdhelper راټولول؛
  • بیک اپ etcd او /etc/kubernetes.

د خدماتو CIDR بدلولو لپاره لنډ عمل پلان:

  • د apiserver او کنټرولر مدیر بدلول؛
  • د سندونو بیا خپرول؛
  • په etcd کې د ClusterIP خدماتو بدلول؛
  • په کلستر کې ټول پوډونه بیا پیل کړئ.

لاندې په تفصیل سره د عملونو بشپړ ترتیب دی.

1. د ډیټا ډمپ لپاره etcd-client نصب کړئ:

apt install etcd-client

2. جوړول etchdhelper:

  • ګولنګ نصب کړئ: 
    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. یو بیک اپ etcd جوړ کړئ:

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 لپاره سندونه صادروي ​​(پشمول)، دوی باید بیا صادر شي:

  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. راځئ چې زوړ کرټ او کیلي حذف کړو، ځکه چې له دې پرته به نوی سند صادر نه شي: 
    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 پته بدله شوې، نو اړینه ده چې په ټولو نوډونو کې د کوبیلټ ترتیب تازه کړئ: 
    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. د کنټرول الوتکې بدلولو وروسته ، یو نوی کیوب-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.

د ترمیم پوډ شبکه

په ورته وخت کې، موږ پریکړه وکړه چې وګورو چې څنګه د پوډ نیټ ورک تعدیل د پایلې ایډیډیلپر په کارولو سره. د کړنو ترتیب په لاندې ډول دی:

  • د تشکیلاتو اصلاح کول kube-system;
  • د کیوب کنټرولر مدیر منشور اصلاح کول؛
  • په مستقیم ډول په etcd کې podCIDR بدل کړئ؛
  • ټول کلستر نوډونه ریبوټ کړئ.

اوس د دې کړنو په اړه نور:

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 کې د بدلونونو په کولو سره د پوډ سی آی آر بدل کړئ:

./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. که تاسو لږترلږه یو نوډ پریږدئ زوړ podCIDR، نو د کیوب کنټرولر مدیر به د پیل کولو توان ونلري ، او په کلستر کې پوډونه به مهالویش نشي.

په حقیقت کې، د پوډ سی آی آر بدلول حتی ساده کیدی شي (د مثال په توګه، نو). مګر موږ غوښتل زده کړو چې څنګه په مستقیم ډول د etcd سره کار وکړو، ځکه چې داسې قضیې شتون لري کله چې په etcd کې د Kubernetes توکي ایډیټ کړئ - یوازینی ممکنه بڼه. (د مثال په توګه، تاسو نشئ کولی یوازې د وخت وخت پرته د خدماتو ساحه بدل کړئ spec.clusterIP.)

نتیجه

مقاله په مستقیم ډول په etcd کې د معلوماتو سره د کار کولو امکان په اړه بحث کوي ، د بیلګې په توګه. د Kubernetes API څخه تیریدل. ځینې ​​​​وختونه دا طریقه تاسو ته اجازه درکوي چې "مشکل شیان" ترسره کړئ. موږ په ریښتیني K8s کلسترونو کې په متن کې ورکړل شوي عملیات ازمویل. په هرصورت، د پراخه استعمال لپاره د دوی د چمتووالي حالت دی PoC (د مفهوم ثبوت). له همدې امله، که تاسو غواړئ په خپلو کلسترونو کې د etcdhelper افادیت بدله شوې نسخه وکاروئ، دا په خپل خطر کې وکړئ.

PS

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

Add a comment