ჩვენი გამოცდილება მონაცემებით etcd Kubernetes კლასტერში პირდაპირ (K8s API-ის გარეშე)

უფრო და უფრო ხშირად კლიენტები გვთხოვენ, მივცეთ წვდომა Kubernetes-ის კლასტერზე, რათა შეძლონ სერვისებზე წვდომა კლასტერში: რათა მათ პირდაპირ დაუკავშირდნენ რომელიმე მონაცემთა ბაზას ან სერვისს, დააკავშირონ ლოკალური აპლიკაცია აპლიკაციებთან კლასტერში...

მაგალითად, საჭიროა თქვენი ადგილობრივი აპარატიდან სერვისთან დაკავშირება memcached.staging.svc.cluster.local. ჩვენ გთავაზობთ ამ შესაძლებლობას VPN-ის გამოყენებით იმ კლასტერში, რომელსაც კლიენტი უკავშირდება. ამისათვის ჩვენ ვაცხადებთ ქვექსელებს, სერვისებს და კლასტერულ DNS-ს კლიენტს. ამრიგად, როდესაც კლიენტი ცდილობს სერვისთან დაკავშირებას memcached.staging.svc.cluster.local, მოთხოვნა მიდის კლასტერულ DNS-ში და საპასუხოდ იღებს ამ სერვისის მისამართს კლასტერული სერვისის ქსელიდან ან pod მისამართიდან.

ჩვენ ვაკონფიგურირებთ K8s კლასტერებს kubeadm-ის გამოყენებით, სადაც არის ნაგულისხმევი სერვისის ქვექსელი 192.168.0.0/16, ხოლო პოდების ქსელი არის 10.244.0.0/16. როგორც წესი, ყველაფერი კარგად მუშაობს, მაგრამ არსებობს რამდენიმე პუნქტი:

• ქვექსელი 192.168.*.* ხშირად გამოიყენება კლიენტის საოფისე ქსელებში და კიდევ უფრო ხშირად დეველოპერის სახლის ქსელებში. და შემდეგ ვიღებთ კონფლიქტებს: სახლის მარშრუტიზატორები მუშაობენ ამ ქვექსელზე და VPN უბიძგებს ამ ქვექსელებს კლასტერიდან კლიენტამდე.
• ჩვენ გვაქვს რამდენიმე კლასტერი (წარმოება, სცენა და/ან რამდენიმე დეველოპერის კლასტერი). შემდეგ, ნაგულისხმევად, ყველა მათგანს ექნება იგივე ქვექსელები პოდებისა და სერვისებისთვის, რაც დიდ სირთულეებს ქმნის რამდენიმე კლასტერში სერვისებთან ერთდროული მუშაობისთვის.

ჩვენ დიდი ხანია მივიღეთ პრაქტიკა სხვადასხვა ქვექსელების სერვისებისთვის და პოდებისთვის ერთი და იმავე პროექტის ფარგლებში - ზოგადად, ისე, რომ ყველა კლასტერს ჰქონდეს განსხვავებული ქსელი. თუმცა, ფუნქციონირებს კლასტერების დიდი რაოდენობა, რომელთა გადატანა არ მსურს ნულიდან, რადგან ისინი აწარმოებენ ბევრ სერვისს, სახელმწიფო აპლიკაციებს და ა.შ.

და შემდეგ საკუთარ თავს ვკითხეთ: როგორ შევცვალოთ ქვექსელი არსებულ კლასტერში?

გადაწყვეტილებების ძიება

ყველაზე გავრცელებული პრაქტიკაა ხელახლა შექმნა ყველა სერვისები ტიპის ClusterIP. როგორც ვარიანტი, შეუძლია რჩევა და ეს:

შემდეგ პროცესს აქვს პრობლემა: ყველაფრის კონფიგურაციის შემდეგ, პოდებს ჩნდება ძველი IP, როგორც DNS სახელების სერვერი /etc/resolv.conf-ში.
რადგან გამოსავალი ჯერ კიდევ ვერ ვიპოვე, მომიწია მთელი კლასტერის გადატვირთვა kubeadm reset-ით და ხელახლა ჩართვა.

მაგრამ ეს არ არის ყველასთვის შესაფერისი... აქ არის უფრო დეტალური შესავალი ჩვენი საქმისთვის:

• გამოიყენება ფლანელი;
• არის კლასტერები როგორც ღრუბლებში, ასევე აპარატურაზე;
• მსურს თავიდან ავიცილოთ კლასტერში ყველა სერვისის ხელახალი განთავსება;
• საჭიროა ზოგადად ყველაფერი გავაკეთოთ პრობლემების მინიმალური რაოდენობით;
• Kubernetes ვერსია არის 1.16.6 (თუმცა, შემდგომი ნაბიჯები მსგავსი იქნება სხვა ვერსიებისთვის);
• მთავარი ამოცანაა უზრუნველყოს, რომ კლასტერში განლაგებულია kubeadm-ის გამოყენებით სერვისის ქვექსელთან 192.168.0.0/16, შეცვალეთ იგი 172.24.0.0/16.

და ისე მოხდა, რომ დიდი ხანია გვაინტერესებდა, გვენახა, რა და როგორ ინახება Kubernetes-ში etcd-ში, რა შეიძლება გაკეთდეს მასთან... ასე ვფიქრობდით: “რატომ არ განაახლეთ მონაცემები etcd-ში, ძველი IP მისამართების (ქვექსელის) ჩანაცვლება ახლით? "

etcd-ში მონაცემებთან მუშაობისთვის მზა ხელსაწყოების მოძიებისას, ვერ ვიპოვნეთ ისეთი რამ, რაც პრობლემას მთლიანად გადაჭრის. (სხვათა შორის, თუ თქვენ იცით რაიმე კომუნალური პროგრამის შესახებ მონაცემებით უშუალოდ etcd-ში მუშაობისთვის, ჩვენ მადლობელი ვიქნებით ბმულებზე.) თუმცა, კარგი საწყისი წერტილია სხვა დამხმარე OpenShift-დან (მადლობა მის ავტორებს!).

ამ პროგრამას შეუძლია etcd-თან დაკავშირება სერთიფიკატების გამოყენებით და წაიკითხოს მონაცემები იქიდან ბრძანებების გამოყენებით ls, get, dump.

დაამატეთ etcdhelper

შემდეგი აზრი ლოგიკურია: "რა გიშლით ხელს ამ პროგრამის დამატებას და სხვა მონაცემების ჩაწერის შესაძლებლობის დამატებით?"

იგი გახდა etcdhelper-ის შეცვლილი ვერსია ორი ახალი ფუნქციით changeServiceCIDR и changePodCIDR. მასზე თქვენ შეგიძლიათ ნახოთ კოდი აქ.

რას აკეთებს ახალი ფუნქციები? ალგორითმი changeServiceCIDR:

• შექმენით დესერილიზატორი;
• რეგულარული გამოხატვის შედგენა CIDR-ის ჩასანაცვლებლად;
• ჩვენ გავდივართ ყველა სერვისს ClusterIP ტიპის კლასტერში:
  • მნიშვნელობის გაშიფვრა etcd-დან Go ობიექტში;
  • რეგულარული გამოხატვის გამოყენებით ვცვლით მისამართის პირველ ორ ბაიტს;
  • მიანიჭეთ სერვისს IP მისამართი ახალი ქვექსელიდან;
  • ჩვენ ვქმნით სერიალიზატორს, გადავიყვანთ Go ობიექტს პროტობუფად, ვწერთ ახალ მონაცემებს etcd-ში.

ფუნქცია changePodCIDR არსებითად მსგავსი changeServiceCIDR - მხოლოდ სერვისის სპეციფიკაციის რედაქტირების ნაცვლად, ჩვენ ამას ვაკეთებთ კვანძისთვის და ვცვლით .spec.PodCIDR ახალ ქვექსელში.

პრაქტიკა

სერვისის შეცვლა CIDR

ამოცანის განხორციელების გეგმა ძალიან მარტივია, მაგრამ ის გულისხმობს შეფერხების პერიოდს კლასტერში ყველა ჯიშის ხელახლა შექმნის დროს. ძირითადი ნაბიჯების აღწერის შემდეგ, ჩვენ ასევე გაგიზიარებთ აზრებს იმის შესახებ, თუ როგორ შეიძლება, თეორიულად, ამ შეფერხების მინიმუმამდე შემცირება.

მოსამზადებელი ნაბიჯები:

• საჭირო პროგრამული უზრუნველყოფის ინსტალაცია და დაყენებული etcdhelper-ის აწყობა;
• სარეზერვო და ა.შ /etc/kubernetes.

მოკლე სამოქმედო გეგმა სერვისის შეცვლისთვისCIDR:

• აპისერვერის და კონტროლერ-მენეჯერის მანიფესტების შეცვლა;
• სერტიფიკატების ხელახალი გაცემა;
• ClusterIP სერვისების შეცვლა etcd-ში;
• კლასტერში ყველა ჯიშის გადატვირთვა.

ქვემოთ მოცემულია მოქმედებების სრული თანმიმდევრობა დეტალურად.

1. დააინსტალირეთ etcd-კლიენტი მონაცემთა ამონაწერისთვის:

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. ვინაიდან ჩვენ ვცვლით სერვისის ქვექსელს, რომელზეც 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. მოდით დაარედაქტიროთ მონაცემები 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. შეცვალეთ მისამართი ყველა კუბელეტში ClusterDNS ახალზე, ხოლო ძველი სერვისი გააგრძელებს მუშაობას ახალთან ერთად.
4. დაელოდეთ სანამ აპლიკაციებით ღვეზელები დაბრუნდება ან თავისთავად ბუნებრივი მიზეზების გამო ან შეთანხმებულ დროს.
5. სერვისის წაშლა kube-dns-tmp და შეცვლა serviceSubnetCIDR kube-dns სერვისისთვის.

ეს გეგმა საშუალებას მოგცემთ შეამციროთ შეფერხების დრო ~ წუთამდე - სერვისის მოხსნის ხანგრძლივობისთვის kube-dns-tmp და სერვისის ქვექსელის შეცვლა kube-dns.

მოდიფიკაციის podNetwork

ამავდროულად, ჩვენ გადავწყვიტეთ შევხედოთ, თუ როგორ უნდა შეცვალოთ podNetwork მიღებული etcdhelper-ის გამოყენებით. მოქმედებების თანმიმდევრობა ასეთია:

• კონფიგურაციის დაფიქსირება kube-system;
• kube-controller-manager manifest-ის დაფიქსირება;
• შეცვალეთ podCIDR პირდაპირ etcd-ში;
• გადატვირთეთ ყველა კლასტერული კვანძი.

ახლა უფრო მეტი ამ მოქმედებების შესახებ:

1. შეცვალეთ ConfigMap's სახელთა სივრცეში 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. შეცვალეთ podCIDR ცვლილებების შეტანით პირდაპირ 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. მოდით შევამოწმოთ, რომ 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 ვერ დაიწყებს და pods კლასტერში არ დაიგეგმება.

სინამდვილეში, podCIDR-ის შეცვლა შეიძლება კიდევ უფრო მარტივი იყოს (მაგალითად, ასე). მაგრამ ჩვენ გვინდოდა გვესწავლა, თუ როგორ უნდა ვიმუშაოთ etcd-თან პირდაპირ, რადგან არის შემთხვევები, როდესაც Kubernetes ობიექტების რედაქტირება etcd-ში - ერთი შესაძლო ვარიანტი. (მაგალითად, თქვენ არ შეგიძლიათ უბრალოდ შეცვალოთ სერვისის ველი შეფერხების გარეშე spec.clusterIP.)

სულ

სტატიაში განხილულია მონაცემებით მუშაობის შესაძლებლობა etcd-ში უშუალოდ, ე.ი. Kubernetes API-ს გვერდის ავლით. ზოგჯერ ეს მიდგომა საშუალებას გაძლევთ გააკეთოთ "რთული საქმეები". ჩვენ გამოვცადეთ ტექსტში მოცემული ოპერაციები რეალურ K8-ის კლასტერებზე. თუმცა, მათი მზადყოფნის სტატუსი ფართო გამოყენებისთვის არის PoC (კონცეფციის მტკიცებულება). ამიტომ, თუ გსურთ გამოიყენოთ etcdhelper პროგრამის შეცვლილი ვერსია თქვენს კლასტერებზე, გააკეთეთ ეს თქვენი რისკის ქვეშ.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «და ა.შ. 3.4.3: შენახვის საიმედოობისა და უსაფრთხოების შესწავლა";
• «Calico კუბერნეტში ქსელისთვის: შესავალი და მცირე გამოცდილება";
• «6 გასართობი სისტემის შეცდომა Kubernetes-ის მუშაობაში [და მათი გადაწყვეტა]";
• «ვიზუალური გზამკვლევი კუბერნეტის პრობლემების გადასაჭრელად".

წყარო: www.habr.com