🥇आदि Kubernetes क्लस्टर में डेटा के साथ सीधे काम करने का हमारा अनुभव (K8s API के बिना)

तेजी से, ग्राहक हमसे क्लस्टर के भीतर सेवाओं तक पहुंचने में सक्षम होने के लिए कुबेरनेट्स क्लस्टर तक पहुंच प्रदान करने के लिए कह रहे हैं: कुछ डेटाबेस या सेवा से सीधे जुड़ने में सक्षम होने के लिए, क्लस्टर के भीतर अनुप्रयोगों के साथ एक स्थानीय एप्लिकेशन को कनेक्ट करने में सक्षम होने के लिए ...

उदाहरण के लिए, आपकी स्थानीय मशीन से किसी सेवा से जुड़ने की आवश्यकता है memcached.staging.svc.cluster.local. हम क्लस्टर के भीतर एक वीपीएन का उपयोग करके यह क्षमता प्रदान करते हैं जिससे क्लाइंट कनेक्ट होता है। ऐसा करने के लिए, हम क्लाइंट को पॉड्स, सेवाओं और पुश क्लस्टर DNS के सबनेट की घोषणा करते हैं। इस प्रकार, जब कोई ग्राहक सेवा से जुड़ने का प्रयास करता है memcached.staging.svc.cluster.local, अनुरोध क्लस्टर DNS पर जाता है और प्रतिक्रिया में क्लस्टर सेवा नेटवर्क या पॉड पते से इस सेवा का पता प्राप्त करता है।

हम kubeadm का उपयोग करके K8s क्लस्टर को कॉन्फ़िगर करते हैं, जहां डिफ़ॉल्ट सेवा सबनेट है 192.168.0.0/16, और पॉड्स का नेटवर्क है 10.244.0.0/16. आमतौर पर सब कुछ ठीक से काम करता है, लेकिन कुछ बिंदु हैं:

सबनेट 192.168.*.* अक्सर क्लाइंट ऑफिस नेटवर्क में उपयोग किया जाता है, और यहां तक कि डेवलपर होम नेटवर्क में भी अधिक बार उपयोग किया जाता है। और फिर हमें टकराव मिलता है: होम राउटर इस सबनेट पर काम करते हैं और वीपीएन इन सबनेट को क्लस्टर से क्लाइंट तक धकेलता है।
हमारे पास कई क्लस्टर (उत्पादन, चरण और/या कई देव क्लस्टर) हैं। फिर, डिफ़ॉल्ट रूप से, उन सभी में पॉड्स और सेवाओं के लिए समान सबनेट होंगे, जो कई समूहों में सेवाओं के साथ एक साथ काम करने में बड़ी कठिनाइयाँ पैदा करता है।

हमने बहुत पहले ही एक ही प्रोजेक्ट के भीतर सेवाओं और पॉड्स के लिए अलग-अलग सबनेट का उपयोग करने की प्रथा को अपनाया है - सामान्य तौर पर, ताकि सभी क्लस्टरों में अलग-अलग नेटवर्क हों। हालाँकि, ऑपरेशन में बड़ी संख्या में क्लस्टर हैं जिन्हें मैं स्क्रैच से रोल करना नहीं चाहूंगा, क्योंकि वे कई सेवाएं, स्टेटफुल एप्लिकेशन इत्यादि चलाते हैं।

और फिर हमने खुद से पूछा: मौजूदा क्लस्टर में सबनेट कैसे बदलें?

समाधान खोजे

सबसे आम अभ्यास पुनः बनाना है सब क्लस्टरआईपी प्रकार वाली सेवाएँ। एक विकल्प के रूप में, सलाह दे सकते हैं और ऐसा:

निम्नलिखित प्रक्रिया में एक समस्या है: सब कुछ कॉन्फ़िगर होने के बाद, पॉड्स पुराने आईपी के साथ /etc/resolv.conf में DNS नेमसर्वर के रूप में आते हैं।
चूँकि मुझे अभी भी समाधान नहीं मिला, मुझे पूरे क्लस्टर को kubeadm रीसेट के साथ रीसेट करना पड़ा और इसे फिर से शुरू करना पड़ा।

लेकिन यह हर किसी के लिए उपयुक्त नहीं है... यहां हमारे मामले के लिए अधिक विस्तृत परिचय दिए गए हैं:

फलालैन का प्रयोग किया जाता है;
बादलों और हार्डवेयर दोनों में क्लस्टर होते हैं;
मैं क्लस्टर में सभी सेवाओं को पुनः तैनात करने से बचना चाहूँगा;
आम तौर पर हर काम को न्यूनतम समस्याओं के साथ करने की आवश्यकता होती है;
कुबेरनेट्स संस्करण 1.16.6 है (हालांकि, आगे के चरण अन्य संस्करणों के लिए समान होंगे);
मुख्य कार्य यह सुनिश्चित करना है कि एक सेवा सबनेट के साथ kubeadm का उपयोग करके क्लस्टर में तैनात किया जाए 192.168.0.0/16, इसके साथ बदलें 172.24.0.0/16.

और ऐसा हुआ कि हम लंबे समय से यह देखने में रुचि रखते थे कि कुबेरनेट्स आदि में क्या और कैसे संग्रहीत किया जाता है, इसके साथ क्या किया जा सकता है... इसलिए हमने सोचा: "पुराने आईपी पते (सबनेट) को नए के साथ बदलकर, आदि में डेटा को अपडेट क्यों न किया जाए? "

आदि में डेटा के साथ काम करने के लिए तैयार टूल की खोज करने पर, हमें ऐसा कुछ भी नहीं मिला जिससे समस्या पूरी तरह से हल हो गई हो। (वैसे, यदि आप आदि में सीधे डेटा के साथ काम करने के लिए किसी उपयोगिता के बारे में जानते हैं, तो हम लिंक की सराहना करेंगे।) हालाँकि, एक अच्छा प्रारंभिक बिंदु है आदि सहायक ओपनशिफ्ट से (इसके लेखकों को धन्यवाद!).

यह उपयोगिता प्रमाणपत्रों का उपयोग करके आदि से जुड़ सकती है और कमांड का उपयोग करके वहां से डेटा पढ़ सकती है ls, get, dump.

आदि हेल्पर जोड़ें

अगला विचार तर्कसंगत है: "आदि में डेटा लिखने की क्षमता जोड़कर आपको इस उपयोगिता को जोड़ने से क्या रोक रहा है?"

यह दो नए कार्यों के साथ इत्यादिहेल्पर का एक संशोधित संस्करण बन गया changeServiceCIDR и changePodCIDR. उस पर आप कोड देख सकते हैं यहां.

नई सुविधाएँ क्या करती हैं? कलन विधि changeServiceCIDR:

एक डिसेरिएलाइज़र बनाएं;
सीआईडीआर को प्रतिस्थापित करने के लिए एक नियमित अभिव्यक्ति संकलित करें;
हम क्लस्टर में क्लस्टरआईपी प्रकार के साथ सभी सेवाओं से गुजरते हैं:
- आदि से मान को गो ऑब्जेक्ट में डिकोड करें;
- रेगुलर एक्सप्रेशन का उपयोग करके हम पते के पहले दो बाइट्स बदलते हैं;
- सेवा को नए सबनेट से एक आईपी पता निर्दिष्ट करें;
- एक सीरिएलाइज़र बनाएं, गो ऑब्जेक्ट को प्रोटोबफ़ में बदलें, आदि में नया डेटा लिखें।

समारोह changePodCIDR मूलतः समान changeServiceCIDR - केवल सेवा विनिर्देश को संपादित करने के बजाय, हम इसे नोड और परिवर्तन के लिए करते हैं .spec.PodCIDR एक नये सबनेट पर.

अभ्यास

सेवा सीआईडीआर बदलें

कार्य को लागू करने की योजना बहुत सरल है, लेकिन इसमें क्लस्टर में सभी पॉड्स के पुन: निर्माण के समय डाउनटाइम शामिल है। मुख्य चरणों का वर्णन करने के बाद, हम इस पर भी विचार साझा करेंगे कि सिद्धांत रूप में, इस डाउनटाइम को कैसे कम किया जा सकता है।

प्रारंभिक चरण:

आवश्यक सॉफ़्टवेयर स्थापित करना और पैच किए गए आदिहेल्पर को असेंबल करना;
बैकअप आदि और /etc/kubernetes.

सेवासीआईडीआर बदलने के लिए संक्षिप्त कार्य योजना:

एपिसर्वर और नियंत्रक-प्रबंधक मैनिफ़ेस्ट को बदलना;
प्रमाणपत्रों को पुनः जारी करना;
इत्यादि में क्लस्टरआईपी सेवाएँ बदलना;
क्लस्टर में सभी पॉड्स को पुनः प्रारंभ करें।

निम्नलिखित क्रियाओं का पूरा क्रम विस्तार से दिया गया है।

1. डेटा डंप के लिए आदि-क्लाइंट स्थापित करें:

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 एपीसर्वर (सहित) के लिए प्रमाणपत्र जारी करता है, उन्हें फिर से जारी करने की आवश्यकता है:

आइए देखें कि वर्तमान प्रमाणपत्र किन डोमेन और आईपी पते के लिए जारी किया गया है:

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

आइए 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-адрес мастер узла

आइए पुराने crt और कुंजी को हटा दें, क्योंकि इसके बिना नया प्रमाणपत्र जारी नहीं किया जाएगा:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```
आइए एपीआई सर्वर के लिए प्रमाणपत्र पुनः जारी करें:
```
kubeadm init phase certs apiserver --config=kubeadm-config.yaml
```

आइए जाँचें कि प्रमाणपत्र नए सबनेट के लिए जारी किया गया था:

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

एपीआई सर्वर प्रमाणपत्र पुनः जारी करने के बाद, उसके कंटेनर को पुनरारंभ करें:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
आइए इसके लिए कॉन्फ़िगरेशन को पुन: जनरेट करें admin.conf:
```
kubeadm alpha certs renew admin.conf
```
आइए आदि में डेटा संपादित करें:
```
./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 पता (क्यूब-डीएनएस) पंजीकृत है, और क्यूब-प्रॉक्सी iptables नियमों को पुराने सबनेट से नए में बदल देता है। लेख में आगे डाउनटाइम को कम करने के संभावित विकल्पों के बारे में लिखा गया है।
आइए नेमस्पेस में कॉन्फ़िगमैप को ठीक करें kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- यहां बदलें clusterDNS क्यूब-डीएनएस सेवा के नए आईपी पते पर: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
- हम इसे ठीक कर देंगे data.ClusterConfiguration.networking.serviceSubnet एक नये सबनेट पर.
चूंकि क्यूब-डीएनएस पता बदल गया है, इसलिए सभी नोड्स पर क्यूबलेट कॉन्फ़िगरेशन को अपडेट करना आवश्यक है:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```
जो कुछ बचा है वह क्लस्टर में सभी पॉड्स को पुनः आरंभ करना है:
```
kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'
```

डाउनटाइम कम से कम करें

डाउनटाइम को कम करने के तरीके पर विचार:

नियंत्रण विमान मैनिफ़ेस्ट को बदलने के बाद, एक नई क्यूब-डीएनएस सेवा बनाएं, उदाहरण के लिए, नाम के साथ kube-dns-tmp और नया पता 172.24.0.10.
बनाना if इत्यादिहेल्पर में, जो क्यूब-डीएनएस सेवा को संशोधित नहीं करेगा।
सभी क्यूबलेट्स में पता बदलें ClusterDNS एक नए के लिए, जबकि पुरानी सेवा नई के साथ-साथ काम करती रहेगी।
तब तक प्रतीक्षा करें जब तक कि एप्लिकेशन वाले पॉड प्राकृतिक कारणों से या किसी सहमत समय पर अपने आप रोल न हो जाएं।
सेवा हटाएँ kube-dns-tmp और बदलो serviceSubnetCIDR क्यूब-डीएनएस सेवा के लिए।

यह योजना आपको सेवा हटाने की अवधि के लिए डाउनटाइम को ~एक मिनट तक कम करने की अनुमति देगी kube-dns-tmp और सेवा के लिए सबनेट बदल रहा है kube-dns.

संशोधन पॉडनेटवर्क

उसी समय, हमने यह देखने का निर्णय लिया कि परिणामी आदिहेल्पर का उपयोग करके पॉडनेटवर्क को कैसे संशोधित किया जाए। क्रियाओं का क्रम इस प्रकार है:

कॉन्फ़िगरेशन को ठीक करना kube-system;
क्यूब-नियंत्रक-प्रबंधक मेनिफ़ेस्ट को ठीक करना;
पॉडसीआईडीआर को सीधे आदि में बदलें;
सभी क्लस्टर नोड्स को रीबूट करें।

अब इन कार्रवाइयों के बारे में और अधिक जानकारी:

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. सीधे आदि में परिवर्तन करके पॉडसीआईडीआर को बदलें:

./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. यदि आप कम से कम एक नोड छोड़ते हैं पुराना पॉडसीआईडीआर, तो क्यूब-नियंत्रक-प्रबंधक प्रारंभ नहीं हो पाएगा, और क्लस्टर में पॉड्स शेड्यूल नहीं किए जाएंगे।

वास्तव में, पॉडसीआईडीआर को बदलना और भी सरल तरीके से किया जा सकता है (उदाहरण के लिए, इसलिए). लेकिन हम सीखना चाहते थे कि सीधे आदि के साथ कैसे काम किया जाए, क्योंकि ऐसे मामले हैं जब कुबेरनेट्स वस्तुओं को आदि में संपादित किया जाता है - केवल संभव संस्करण. (उदाहरण के लिए, आप बिना डाउनटाइम के सेवा फ़ील्ड को नहीं बदल सकते spec.clusterIP.)

संपूर्ण

लेख सीधे आदि में डेटा के साथ काम करने की संभावना पर चर्चा करता है, यानी। कुबेरनेट्स एपीआई को दरकिनार करना। कभी-कभी यह दृष्टिकोण आपको "मुश्किल चीजें" करने की अनुमति देता है। हमने वास्तविक K8s क्लस्टरों पर पाठ में दिए गए संचालन का परीक्षण किया। हालाँकि, व्यापक उपयोग के लिए उनकी तत्परता की स्थिति है पीओसी (अवधारणा का प्रमाण). इसलिए, यदि आप अपने क्लस्टर पर आदिहेल्पर उपयोगिता के संशोधित संस्करण का उपयोग करना चाहते हैं, तो ऐसा अपने जोखिम पर करें।

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

स्रोत: www.habr.com

सीधे इत्यादि Kubernetes क्लस्टर में डेटा के साथ काम करने का हमारा अनुभव (K8s API के बिना)