🥇 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.*.* प्राय: क्लाइन्ट अफिस नेटवर्कहरूमा प्रयोग गरिन्छ, र अझ धेरै पटक विकासकर्ता गृह नेटवर्कहरूमा। र त्यसपछि हामी द्वन्द्वको साथ समाप्त हुन्छौं: गृह राउटरहरू यस सबनेटमा काम गर्दछन् र VPN ले यी सबनेटहरूलाई क्लस्टरबाट ग्राहकमा धकेल्छ।
हामीसँग धेरै क्लस्टरहरू छन् (उत्पादन, चरण र/वा धेरै देव क्लस्टरहरू)। त्यसपछि, पूर्वनिर्धारित रूपमा, ती सबैसँग पोडहरू र सेवाहरूको लागि समान सबनेटहरू हुनेछन्, जसले धेरै क्लस्टरहरूमा सेवाहरूसँग एकसाथ काम गर्न ठूलो कठिनाइहरू सिर्जना गर्दछ।

हामीले धेरै पहिले नै एउटै परियोजना भित्र सेवाहरू र पोडहरूका लागि विभिन्न सबनेटहरू प्रयोग गर्ने अभ्यास अपनाएका छौं - सामान्यतया, ताकि सबै क्लस्टरहरूमा फरक नेटवर्कहरू छन्। यद्यपि, त्यहाँ धेरै संख्यामा क्लस्टरहरू सञ्चालनमा छन् जुन म स्क्र्याचबाट रोल ओभर गर्न चाहन्न, किनकि तिनीहरूले धेरै सेवाहरू, स्टेटफुल अनुप्रयोगहरू, आदि चलाउँछन्।

र त्यसपछि हामीले आफैलाई सोध्यौं: अवस्थित क्लस्टरमा सबनेट कसरी परिवर्तन गर्ने?

निर्णय खोज्दै

सबैभन्दा सामान्य अभ्यास पुन: सिर्जना गर्न हो सबै क्लस्टरआईपी प्रकारका साथ सेवाहरू। विकल्पको रूपमा, सल्लाह दिन सक्छ र यो:

निम्न प्रक्रियामा समस्या छ: सबै कुरा कन्फिगर गरेपछि, /etc/resolv.conf मा DNS नेमसर्भरको रूपमा पोडहरू पुरानो आईपीसँग आउँछन्।
मैले अझै समाधान फेला पारेको छैन, मैले kubeadm रिसेटको साथ सम्पूर्ण क्लस्टर रिसेट गर्नुपर्‍यो र यसलाई फेरि सुरु गर्नुपर्‍यो।

तर यो सबैका लागि उपयुक्त छैन... यहाँ हाम्रो मामलाको लागि थप विस्तृत परिचयहरू छन्:

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

र यो यस्तो भयो कि हामी लामो समयदेखि कुबर्नेट्समा के र कसरी etcd मा भण्डार गरिएको छ, यसको साथ के गर्न सकिन्छ भनेर हेर्नको लागि चासो राखेका थियौं ... त्यसैले हामीले सोच्यौं: "पुरानो आईपी ठेगानाहरू (सबनेट) लाई नयाँसँग प्रतिस्थापन गर्दै, etcd मा डाटा अपडेट किन नगर्नुहोस्? "

etcd मा डेटा संग काम गर्न को लागी तयार उपकरण को लागी खोजी गरिसकेपछि, हामीले समस्या को पूर्ण समाधान गर्ने केहि पनि फेला पारेनौं। (वैसे, यदि तपाइँ डेटा संग सीधा etcd मा काम गर्न को लागी कुनै उपयोगिताहरु को बारे मा थाहा छ, हामी लिङ्कहरु को सराहना गर्नेछौं।) यद्यपि, राम्रो सुरुवात बिन्दु हो आदि सहयोगी OpenShift बाट (यसका लेखकहरूलाई धन्यवाद!).

यो उपयोगिताले प्रमाणपत्रहरू प्रयोग गरेर etcd मा जडान गर्न सक्छ र त्यहाँबाट आदेशहरू प्रयोग गरेर डेटा पढ्न सक्छ ls, get, dump.

etcdhelper थप्नुहोस्

अर्को विचार तार्किक छ: "कसले तपाईंलाई etcd मा डाटा लेख्ने क्षमता थपेर यो उपयोगिता थप्नबाट रोकेको छ?"

यो दुई नयाँ प्रकार्यहरु संग etcdhelper को परिमार्जित संस्करण भयो changeServiceCIDR и changePodCIDR। उनको मा तपाईं कोड हेर्न सक्नुहुन्छ यहाँ.

नयाँ सुविधाहरूले के गर्छ? एल्गोरिदम changeServiceCIDR:

एक deserializer सिर्जना;
CIDR प्रतिस्थापन गर्न नियमित अभिव्यक्ति कम्पाइल गर्नुहोस्;
हामी क्लस्टरमा ClusterIP प्रकारका सबै सेवाहरू मार्फत जान्छौं:
- etcd बाट Go वस्तुमा मान डिकोड गर्नुहोस्;
- नियमित अभिव्यक्ति प्रयोग गरेर हामी ठेगानाको पहिलो दुई बाइटहरू प्रतिस्थापन गर्छौं;
- सेवालाई नयाँ सबनेटबाट IP ठेगाना प्रदान गर्नुहोस्;
- सिरियलाइजर सिर्जना गर्नुहोस्, गो वस्तुलाई प्रोटोबफमा रूपान्तरण गर्नुहोस्, आदिमा नयाँ डाटा लेख्नुहोस्।

समारोह changePodCIDR मूलतः समान changeServiceCIDR - केवल सेवा विशिष्टता सम्पादन गर्नुको सट्टा, हामी यो नोड र परिवर्तनको लागि गर्छौं .spec.PodCIDR नयाँ सबनेटमा।

अभ्यास गर्नुहोस्

सेवा CIDR परिवर्तन गर्नुहोस्

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

तयारी चरणहरू:

आवश्यक सफ्टवेयर स्थापना र प्याच गरिएको etcdhelper संयोजन;
ब्याकअप आदि र /etc/kubernetes.

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

apiserver परिवर्तन गर्दै र नियन्त्रक-प्रबन्धक प्रकट हुन्छ;
प्रमाणपत्र पुन: जारी;
आदिमा क्लस्टरआईपी सेवाहरू परिवर्तन गर्दै;
क्लस्टरमा सबै पोडहरू पुन: सुरु गर्नुहोस्।

निम्न विस्तृत रूपमा कार्यहरूको पूर्ण अनुक्रम हो।

1. डाटा डम्पको लागि etcd-client स्थापना गर्नुहोस्:

apt install etcd-client

२. निर्माण आदि सहयोगकर्ता:

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 नियन्त्रण विमान manifests मा सेवा सबनेट परिवर्तन गर्नुहोस्। फाइलहरूमा /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
```
आदिमा डाटा सम्पादन गरौं:
```
./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 सेवाको नयाँ आईपी ठेगानामा: 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 सेवा परिमार्जन गर्दैन।
सबै kubelets मा ठेगाना बदल्नुहोस् ClusterDNS नयाँमा, जबकि पुरानो सेवाले नयाँसँग एकैसाथ काम गर्न जारी राख्नेछ।
एप्लिकेसनहरू भएका पोडहरू प्राकृतिक कारणहरूका लागि वा एक सहमति भएको समयमा आफैंले रोल ओभर नभएसम्म पर्खनुहोस्।
सेवा मेटाउनुहोस् kube-dns-tmp र परिवर्तन serviceSubnetCIDR kube-dns सेवाको लागि।

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

परिमार्जन पोडनेटवर्क

एकै समयमा, हामीले परिणामित etcdhelper प्रयोग गरेर podNetwork कसरी परिमार्जन गर्ने भनेर हेर्ने निर्णय गर्यौं। कार्यहरूको क्रम निम्नानुसार छ:

मा कन्फिगहरू फिक्स गर्दै kube-system;
kube-controller-manager manifest फिक्स गर्दै;
podCIDR सिधै 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

५. पोडसीआईडीआर वास्तवमै परिवर्तन भएको छ भनी जाँच गरौं:

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"
  }
]

६. सबै क्लस्टर नोडहरू एक-एक गरेर रिबुट गरौं।

7. यदि तपाईंले कम्तिमा एउटा नोड छोड्नुभयो भने पुरानो podCIDR, त्यसपछि kube-controller-manager सुरु गर्न सक्षम हुनेछैन, र क्लस्टरमा पोडहरू निर्धारित हुने छैनन्।

वास्तवमा, podCIDR परिवर्तन गर्न अझ सरल गर्न सकिन्छ (उदाहरणका लागि, त्यसैले)। तर हामी etcd सँग सीधै कसरी काम गर्ने भनेर जान्न चाहन्थ्यौं, किनभने त्यहाँ कुबेरनेट वस्तुहरू etcd मा सम्पादन गर्दा केसहरू छन् - एकल सम्भावित भिन्नता। (उदाहरणका लागि, तपाइँ डाउनटाइम बिना सेवा क्षेत्र परिवर्तन गर्न सक्नुहुन्न spec.clusterIP.)

परिणाम

लेखले डेटासँग प्रत्यक्ष रूपमा etcd मा काम गर्ने सम्भावनाको बारेमा छलफल गर्दछ, अर्थात्। Kubernetes API लाई बाइपास गर्दै। कहिलेकाहीँ यो दृष्टिकोणले तपाईंलाई "ठुलो कुराहरू" गर्न अनुमति दिन्छ। हामीले वास्तविक K8s क्लस्टरहरूमा पाठमा दिइएको अपरेसनहरूको परीक्षण गर्यौं। यद्यपि, व्यापक प्रयोगको लागि तिनीहरूको तत्परताको स्थिति छ PoC (अवधारणाको प्रमाण)। त्यसकारण, यदि तपाइँ तपाइँको क्लस्टरहरूमा etcdhelper उपयोगिताको परिमार्जित संस्करण प्रयोग गर्न चाहनुहुन्छ भने, तपाइँको आफ्नै जोखिममा गर्नुहोस्।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

स्रोत: www.habr.com

etcd Kubernetes क्लस्टरमा डाटासँग काम गर्ने हाम्रो अनुभव सीधा (K8s API बिना)