🥇 براہ راست 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 ان سب نیٹس کو کلسٹر سے کلائنٹ تک پہنچاتا ہے۔
ہمارے پاس متعدد کلسٹرز ہیں (پروڈکشن کلسٹرز، اسٹیج کلسٹرز اور/یا ایک سے زیادہ دیو کلسٹرز)۔ پھر، ڈیفالٹ کے طور پر، ان سب کے پاس پوڈز اور سروسز کے لیے ایک جیسے ذیلی نیٹ ہوں گے، جو کئی کلسٹرز میں خدمات کے ساتھ بیک وقت کام کرنے کے لیے بڑی مشکلات پیدا کرتا ہے۔

ہم نے طویل عرصے سے ایک ہی پروجیکٹ کے اندر خدمات اور پوڈز کے لیے مختلف ذیلی نیٹ استعمال کرنے کا رواج اپنایا ہے - عام طور پر، تاکہ تمام کلسٹرز مختلف نیٹ ورکس کے ساتھ ہوں۔ تاہم، ایسے کلسٹرز کی ایک بڑی تعداد کام کر رہی ہے جنہیں ہم شروع سے رول اوور نہیں کرنا چاہیں گے، کیونکہ ان میں بہت سی سروسز، اسٹیٹفول ایپلی کیشنز وغیرہ چل رہی ہیں۔

اور پھر ہم نے خود سے پوچھا: موجودہ کلسٹر میں سب نیٹ کو کیسے تبدیل کیا جائے؟

فیصلوں کی تلاش

سب سے عام مشق دوبارہ بنانا ہے۔ تمام ClusterIP قسم کے ساتھ خدمات۔ ایک اختیار کے طور پر، مشورہ دے سکتے ہیں۔ اور یہ:

مندرجہ ذیل عمل میں ایک مسئلہ ہے: ہر چیز کو ترتیب دینے کے بعد، پوڈز /etc/resolv.conf میں DNS نیم سرور کے طور پر پرانے IP کے ساتھ آتے ہیں۔
چونکہ مجھے ابھی تک حل نہیں ملا، مجھے kubeadm reset کے ساتھ پورے کلسٹر کو دوبارہ ترتیب دینا پڑا اور اسے دوبارہ شروع کرنا پڑا۔

لیکن یہ سب کے لیے موزوں نہیں ہے... ہمارے کیس کے لیے مزید تفصیلی تعارفی باتیں یہ ہیں:

فلالین کی طرف سے استعمال کیا جاتا ہے؛
بادلوں اور ہارڈ ویئر دونوں میں کلسٹرز ہیں؛
میں کلسٹر میں تمام خدمات کو دوبارہ تعینات کرنے سے بچنا چاہوں گا؛
عام طور پر کم از کم مسائل کے ساتھ ہر کام کرنے کی ضرورت ہے۔
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 کو تبدیل کرنے کے لیے ایک ریگولر ایکسپریشن مرتب کریں۔
ہم کلسٹر میں کلسٹر آئی پی قسم کے ساتھ تمام خدمات سے گزرتے ہیں:
- ای سی ڈی سے گو آبجیکٹ میں ویلیو کو ڈی کوڈ کریں۔
- ریگولر ایکسپریشن کا استعمال کرتے ہوئے، ہم ایڈریس کے پہلے دو بائٹس کو بدل دیتے ہیں۔
- سروس کو نئے سب نیٹ سے IP ایڈریس تفویض کریں۔
- سیریلائزر بنائیں، گو آبجیکٹ کو پروٹوبف میں تبدیل کریں، etcd میں نیا ڈیٹا لکھیں۔

فنکشن changePodCIDR بنیادی طور پر ایک ہی changeServiceCIDR - صرف سروس کی تفصیلات میں ترمیم کرنے کے بجائے، ہم اسے نوڈ اور تبدیلی کے لیے کرتے ہیں۔ .spec.PodCIDR نئے سب نیٹ پر۔

پریکٹس

سروس سی آئی ڈی آر کو تبدیل کریں۔

ٹاسک کے نفاذ کا منصوبہ بہت آسان ہے، لیکن اس کا مطلب کلسٹر میں تمام پوڈز کی دوبارہ تخلیق کے وقت ایک ڈاون ٹائم ہے۔ بنیادی اقدامات کو بیان کرنے کے بعد، ہم اس بارے میں بھی خیالات کا اشتراک کریں گے کہ نظریہ کے لحاظ سے اس ڈاؤن ٹائم کو کیسے کم کیا جا سکتا ہے۔

تیاری کے مراحل:

ضروری سافٹ ویئر انسٹال کرنا اور پیچ شدہ etcdhelper بنانا؛
etcd بیک اپ اور /etc/kubernetes.

سروس سی آئی ڈی آر کو تبدیل کرنے کے لیے مختصر ایکشن پلان:

apiserver اور کنٹرولر مینیجر کے منشور کو تبدیل کرنا؛
سرٹیفکیٹ کا دوبارہ اجراء؛
وغیرہ میں خدمات کے کلسٹر آئی پی کو تبدیل کرنا؛
کلسٹر میں تمام پوڈ کو دوبارہ شروع کریں.

مندرجہ ذیل تفصیل سے اعمال کا مکمل سلسلہ ہے۔

1. ڈیٹا ڈمپ کے لیے etcd-client انسٹال کریں:

apt install etcd-client

2. ہم etcdhelper جمع کرتے ہیں:

گولنگ انسٹال کریں:

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 کے لیے سرٹیفکیٹ جاری کرتا ہے (بشمول)، انہیں دوبارہ جاری کیا جانا چاہیے:

آئیے دیکھتے ہیں کہ کن ڈومینز اور آئی پی ایڈریسز کے لیے موجودہ سرٹیفکیٹ جاری کیا جاتا ہے:

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 اور key کو حذف کر دیں، کیونکہ اس کے بغیر نیا سرٹیفکیٹ جاری نہیں کیا جائے گا:
```
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 کے قواعد کو پرانے سب نیٹ سے نئے میں تبدیل کر دیا ہے۔ مزید مضمون میں یہ ڈاؤن ٹائم کو کم سے کم کرنے کے ممکنہ اختیارات کے بارے میں لکھا گیا ہے۔
آئیے نام کی جگہ میں ConfigMaps کو ٹھیک کرتے ہیں۔ 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 config کو اپ ڈیٹ کرنے کی ضرورت ہے:
```
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 مینی فیسٹ کو ٹھیک کریں؛
podCIDR کو براہ راست etcd میں تبدیل کریں۔
تمام کلسٹر نوڈس کو دوبارہ شروع کریں۔

اب ان اعمال کے بارے میں مزید:

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 میں ترمیم کرکے 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 شروع کرنے میں ناکام ہو جائے گا اور کلسٹر میں پوڈز کو شیڈول نہیں کیا جائے گا۔

درحقیقت، podCIDR کو تبدیل کرنا زیادہ آسانی سے کیا جا سکتا ہے (مثال کے طور پر، تو)۔ لیکن سب کے بعد، ہم یہ سیکھنا چاہتے تھے کہ etcd کے ساتھ براہ راست کیسے کام کیا جائے، کیونکہ ایسے معاملات ہوتے ہیں جب etcd میں Kubernetes اشیاء میں ترمیم کرتے ہیں۔ صرف ممکنہ قسم. (مثال کے طور پر، آپ بغیر وقت کے سروس فیلڈ کو تبدیل نہیں کر سکتے spec.clusterIP.)

کل

مضمون براہ راست etcd میں ڈیٹا کے ساتھ کام کرنے کے امکان پر بحث کرتا ہے، یعنی Kubernetes API کو نظرانداز کرتے ہوئے۔ بعض اوقات یہ نقطہ نظر آپ کو "مشکل چیزیں" کرنے کی اجازت دیتا ہے۔ ہم نے اصلی K8s کلسٹرز پر متن میں دی گئی کارروائیوں کا تجربہ کیا۔ تاہم، وسیع پیمانے پر استعمال کے لیے ان کی تیاری کی حیثیت ہے۔ پی او سی (تصور کا ثبوت). اس لیے، اگر آپ اپنے کلسٹرز پر etcdhelper کا تبدیل شدہ ورژن استعمال کرنا چاہتے ہیں، تو اپنے ذمہ داری پر کریں۔

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

براہ راست etcd Kubernetes کلسٹر میں ڈیٹا کے ساتھ ہمارا تجربہ (K8s API کے بغیر)