🥇 etcd Kubernetes क्लस्टरमध्ये थेट डेटासह काम करण्याचा आमचा अनुभव (K8s API शिवाय)

वाढत्या प्रमाणात, क्लायंट आम्हाला क्लस्टरमधील सेवांमध्ये प्रवेश करण्यास सक्षम होण्यासाठी Kubernetes क्लस्टरमध्ये प्रवेश प्रदान करण्यास सांगत आहेत: काही डेटाबेस किंवा सेवेशी थेट कनेक्ट करण्यात सक्षम होण्यासाठी, क्लस्टरमधील अनुप्रयोगांसह स्थानिक अनुप्रयोग कनेक्ट करण्यासाठी...

उदाहरणार्थ, तुमच्या स्थानिक मशीनवरून सेवेशी कनेक्ट करणे आवश्यक आहे memcached.staging.svc.cluster.local. क्लायंट ज्या क्लस्टरला जोडतो त्या क्लस्टरमध्ये VPN वापरून आम्ही ही क्षमता प्रदान करतो. हे करण्यासाठी, आम्ही पॉड्स, सेवांचे सबनेट घोषित करतो आणि क्लस्टर 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 रीसेटसह संपूर्ण क्लस्टर रीसेट करावे लागले आणि ते पुन्हा सुरू करावे लागले.

परंतु हे प्रत्येकासाठी योग्य नाही... आमच्या केससाठी येथे अधिक तपशीलवार परिचय आहेत:

फ्लॅनेल वापरले जाते;
ढगांमध्ये आणि हार्डवेअरवर दोन्ही क्लस्टर्स आहेत;
मी क्लस्टरमधील सर्व सेवा पुन्हा तैनात करणे टाळू इच्छितो;
सामान्यत: कमीतकमी समस्यांसह सर्वकाही करण्याची आवश्यकता आहे;
Kubernetes आवृत्ती 1.16.6 आहे (तथापि, पुढील चरण इतर आवृत्त्यांसाठी समान असतील);
सेवा सबनेटसह kubeadm वापरून तैनात केलेल्या क्लस्टरमध्ये याची खात्री करणे हे मुख्य कार्य आहे 192.168.0.0/16, सह बदला 172.24.0.0/16.

आणि हे असेच घडले की कुबर्नेट्समध्ये etcd मध्ये काय आणि कसे संग्रहित केले जाते, त्याद्वारे काय केले जाऊ शकते हे पाहण्यात आम्हाला खूप पूर्वीपासून रस होता... म्हणून आम्ही विचार केला: “जुने IP पत्ते (सबनेट) बदलून फक्त etcd मध्ये डेटा का अपडेट करू नये?

etcd मधील डेटासह कार्य करण्यासाठी तयार साधनांचा शोध घेतल्यानंतर, आम्हाला समस्येचे पूर्णपणे निराकरण करणारे काहीही सापडले नाही. (तसे, जर तुम्हाला थेट etcd मध्ये डेटासह काम करण्यासाठी कोणत्याही उपयुक्ततेबद्दल माहिती असेल, तर आम्ही लिंक्सची प्रशंसा करू.) तथापि, एक चांगला प्रारंभ बिंदू आहे etcdhelper OpenShift वरून (त्याच्या लेखकांना धन्यवाद!).

ही युटिलिटी प्रमाणपत्रे वापरून etcd शी कनेक्ट करू शकते आणि कमांड वापरून तेथून डेटा वाचू शकते ls, get, dump.

etcdhelper जोडा

पुढील विचार तार्किक आहे: "इडीडीमध्ये डेटा लिहिण्याची क्षमता जोडून ही उपयुक्तता जोडण्यापासून तुम्हाला काय थांबवत आहे?"

हे दोन नवीन फंक्शन्ससह etcdhelper ची सुधारित आवृत्ती बनली changeServiceCIDR и changePodCIDR. तिच्या वर तुम्ही कोड पाहू शकता येथे.

नवीन वैशिष्ट्ये काय करतात? अल्गोरिदम changeServiceCIDR:

एक deserializer तयार करा;
CIDR पुनर्स्थित करण्यासाठी नियमित अभिव्यक्ती संकलित करा;
आम्ही क्लस्टरमधील ClusterIP प्रकारासह सर्व सेवांमधून जातो:
- गो ऑब्जेक्टमध्ये etcd वरून मूल्य डीकोड करा;
- रेग्युलर एक्सप्रेशन वापरून आम्ही पत्त्याचे पहिले दोन बाइट्स बदलतो;
- नवीन सबनेटवरून सेवेला IP पत्ता नियुक्त करा;
- सीरियलायझर तयार करा, गो ऑब्जेक्टला प्रोटोबफमध्ये रूपांतरित करा, etcd वर नवीन डेटा लिहा.

कार्य changePodCIDR मूलत: समान changeServiceCIDR - केवळ सेवा तपशील संपादित करण्याऐवजी, आम्ही ते नोड आणि बदलासाठी करतो .spec.PodCIDR नवीन सबनेटवर.

सराव

सेवा CIDR बदला

कार्य अंमलात आणण्याची योजना अगदी सोपी आहे, परंतु क्लस्टरमधील सर्व शेंगा पुन्हा तयार करण्याच्या वेळी डाउनटाइमचा समावेश आहे. मुख्य पायऱ्यांचे वर्णन केल्यानंतर, आम्ही सिद्धांतानुसार, हा डाउनटाइम कसा कमी करता येईल यावर विचार देखील सामायिक करू.

तयारीचे टप्पे:

आवश्यक सॉफ्टवेअर स्थापित करणे आणि पॅच केलेले etcdhelper एकत्र करणे;
बॅकअप etcd आणि /etc/kubernetes.

सर्व्हिससीआयडीआर बदलण्यासाठी संक्षिप्त कृती योजना:

apiserver बदलणे आणि नियंत्रक-व्यवस्थापक प्रकट होते;
प्रमाणपत्रे पुन्हा जारी करणे;
इत्यादी मध्ये क्लस्टरआयपी सेवा बदलणे;
क्लस्टरमधील सर्व शेंगा पुन्हा सुरू करा.

खालील क्रियांचा तपशीलवार संपूर्ण क्रम आहे.

1. डेटा डंपसाठी etcd-क्लायंट स्थापित करा:

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 apiserver साठी प्रमाणपत्र जारी करते (यासह), ते पुन्हा जारी करणे आवश्यक आहे:

सध्याचे प्रमाणपत्र कोणत्या डोमेन आणि 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

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}
```
चला API सर्व्हरसाठी प्रमाणपत्रे पुन्हा जारी करू:
```
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

API सर्व्हर प्रमाणपत्र पुन्हा जारी केल्यानंतर, त्याचा कंटेनर रीस्टार्ट करा:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
साठी कॉन्फिगरेशन पुन्हा तयार करूया admin.conf:
```
kubeadm alpha certs renew admin.conf
```
चला 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 चे नियम जुन्या सबनेटवरून नवीनमध्ये बदलते. पुढे लेखात डाउनटाइम कमी करण्याच्या संभाव्य पर्यायांबद्दल लिहिले आहे.
नेमस्पेसमध्ये कॉन्फिगमॅपचे निराकरण करूया 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 नवीन सबनेटवर.
kube-dns पत्ता बदलला असल्याने, सर्व नोड्सवर kubelet कॉन्फिगरेशन अपडेट करणे आवश्यक आहे:
```
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 सेवा तयार करा, उदाहरणार्थ, नावासह kube-dns-tmp आणि नवीन पत्ता 172.24.0.10.
बनवा if etcdhelper मध्ये, जे kube-dns सेवेत बदल करणार नाही.
सर्व कुबेलेट्समध्ये पत्ता बदला ClusterDNS नवीनसाठी, तर जुनी सेवा नवीनसह एकाच वेळी कार्य करणे सुरू ठेवेल.
ऍप्लिकेशन्ससह शेंगा एकतर नैसर्गिक कारणास्तव स्वतःहून किंवा मान्य वेळेत रोल होईपर्यंत प्रतीक्षा करा.
सेवा हटवा kube-dns-tmp आणि बदल serviceSubnetCIDR kube-dns सेवेसाठी.

ही योजना तुम्हाला सेवा काढून टाकण्याच्या कालावधीसाठी डाउनटाइम ~एक मिनिटापर्यंत कमी करण्यास अनुमती देईल kube-dns-tmp आणि सेवेसाठी सबनेट बदलणे kube-dns.

बदल पॉडनेटवर्क

त्याच वेळी, आम्ही परिणामी etcdhelper वापरून podNetwork कसे सुधारायचे ते पाहण्याचे ठरविले. क्रियांचा क्रम खालीलप्रमाणे आहे:

मध्ये कॉन्फिग्स निश्चित करणे kube-system;
kube-controller-manager मॅनिफेस्ट निश्चित करणे;
पॉडसीआयडीआर थेट etcd मध्ये बदला;
सर्व क्लस्टर नोड्स रीबूट करा.

आता या क्रियांबद्दल अधिक:

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 मध्ये संपादित करताना काही प्रकरणे आहेत - फक्त संभाव्य प्रकार. (उदाहरणार्थ, तुम्ही डाउनटाइमशिवाय सेवा फील्ड बदलू शकत नाही spec.clusterIP.)

परिणाम

लेख थेट etcd मध्ये डेटासह कार्य करण्याच्या शक्यतेची चर्चा करतो, म्हणजे. Kubernetes API ला बायपास करून. कधीकधी हा दृष्टीकोन आपल्याला "कठीण गोष्टी" करण्यास अनुमती देतो. आम्ही वास्तविक K8s क्लस्टर्सवरील मजकूरात दिलेल्या ऑपरेशन्सची चाचणी केली. तथापि, व्यापक वापरासाठी त्यांच्या तयारीची स्थिती आहे PoC (संकल्पनेचा पुरावा). म्हणून, जर तुम्हाला तुमच्या क्लस्टर्सवर etcdhelper युटिलिटीची सुधारित आवृत्ती वापरायची असेल, तर ते तुमच्या स्वत:च्या जोखमीवर करा.

PS

आमच्या ब्लॉगवर देखील वाचा:

स्त्रोत: www.habr.com

etcd Kubernetes क्लस्टरमधील डेटाचा आमचा अनुभव थेट (K8s API शिवाय)