🥇Таҷрибаи кор бо додаҳо дар кластери etcd Kubernetes мустақим (бе K8s API)

Мизоҷон торафт бештар аз мо хоҳиш мекунанд, ки дастрасӣ ба кластери Kubernetes-ро таъмин кунем, то тавонем ба хидматҳо дар дохили кластер дастрасӣ дошта бошем: тавони пайваст шудан ба ягон пойгоҳи додаҳо ё хидмат, пайваст кардани замимаи маҳаллӣ бо замимаҳои дохили кластер...

Масалан, зарурати пайвастшавӣ аз мошини маҳаллии худ ба хидмат вуҷуд дорад memcached.staging.svc.cluster.local. Мо ин қобилиятро бо истифода аз VPN дар дохили кластер, ки муштарӣ ба он пайваст мешавад, таъмин мекунем. Барои ин, мо зершабакаҳои pods, хидматҳоро эълон мекунем ва кластери DNS-ро ба муштарӣ тела медиҳем. Ҳамин тариқ, вақте ки муштарӣ кӯшиш мекунад, ки ба хидмат пайваст шавад memcached.staging.svc.cluster.local, дархост ба кластери DNS меравад ва дар посух суроғаи ин хидматро аз шабакаи хидматрасонии кластер ё суроғаи подкаст мегирад.

Мо кластерҳои K8s-ро бо истифода аз kubeadm танзим мекунем, ки дар он зершабакаи хидматрасонии пешфарз ҷойгир аст 192.168.0.0/16, ва сети поддонхо мебошад 10.244.0.0/16. Одатан ҳама чиз хуб кор мекунад, аммо якчанд нукта вуҷуд дорад:

Шабака 192.168.*.* аксар вақт дар шабакаҳои офиси муштарӣ ва ҳатто бештар дар шабакаҳои хонагии таҳиягарон истифода мешавад. Ва он гоҳ мо ихтилофҳо ба даст меорем: роутерҳои хонагӣ дар ин зершабака кор мекунанд ва VPN ин зершабакаҳоро аз кластер ба муштарӣ тела медиҳад.
Мо якчанд кластер дорем (истеҳсол, марҳила ва/ё якчанд кластерҳои таҳиякунанда). Сипас, ба таври нобаёнӣ, ҳамаи онҳо зершабакаҳои якхела барои pods ва хидматҳо доранд, ки барои кори ҳамзамон бо хидматҳо дар якчанд кластерҳо мушкилоти зиёд ба вуҷуд меорад.

Мо кайҳо таҷрибаи истифодаи зершабакаҳои гуногунро барои хидматҳо ва подшоҳҳо дар як лоиҳа қабул кардаем - дар маҷмӯъ, то ҳама кластерҳо шабакаҳои гуногун дошта бошанд. Бо вуҷуди ин, шумораи зиёди кластерҳо дар амал ҳастанд, ки ман намехоҳам аз сифр иваз кунам, зеро онҳо бисёр хидматҳо, барномаҳои давлатӣ ва ғайраро иҷро мекунанд.

Ва он гоҳ мо аз худ пурсидем: чӣ гуна зершабақаро дар кластери мавҷуда тағир додан мумкин аст?

Ҷустуҷӯи қарорҳо

Таҷрибаи маъмултарин аз нав эҷод кардан аст ҳама хидматҳо бо навъи ClusterIP. Ҳамчун вариант, маслиҳат дода метавонад ва ин:

Раванди зерин мушкилот дорад: пас аз ҳама танзимшуда, подкҳо IP-и кӯҳнаро ҳамчун сервери номи DNS дар /etc/resolv.conf пайдо мекунанд.
Азбаски ман то ҳол ҳалли худро наёфтам, ман маҷбур шудам, ки тамоми кластерро бо reset kubeadm барқарор кунам ва онро дубора оғоз кунам.

Аммо ин барои ҳама мувофиқ нест... Дар ин ҷо муқаддимаҳои муфассали парвандаи мо ҳастанд:

Фланел истифода мешавад;
Ҳам дар абрҳо ва ҳам дар сахтафзор кластерҳо мавҷуданд;
Ман мехоҳам аз дубора ҷойгиркунии ҳама хидматҳо дар кластер худдорӣ кунам;
Зарур аст, ки ҳама чизро бо шумораи камтарини мушкилот иҷро кунед;
Версияи Kubernetes 1.16.6 аст (аммо, қадамҳои минбаъда барои версияҳои дигар монанд хоҳанд буд);
Вазифаи асосӣ ин аст, ки дар кластер ҷойгиршуда бо истифода аз kubeadm бо зершабакаи хидматрасонӣ 192.168.0.0/16, онро бо 172.24.0.0/16.

Ва ҳамин тавр шуд, ки мо кайҳо боз таваҷҷӯҳ доштем, ки дар Кубернетес чӣ гуна ва чӣ тавр дар etcd нигоҳ дошта мешавад, бо он чӣ кор кардан мумкин аст... Пас, мо фикр кардем: "Чаро на танҳо маълумотро дар etcd навсозӣ кунед, суроғаҳои IP-и кӯҳнаро (зершабака) бо суроғаҳои нав иваз кунедОё

Ҳангоми ҷустуҷӯи асбобҳои тайёр барои кор бо додаҳо дар etcd, мо чизе наёфтем, ки мушкилотро комилан ҳал кунад. (Дар омади гап, агар шумо дар бораи ҳама гуна утилитаҳо барои кор бо додаҳо дар etcd маълумот дошта бошед, мо истинодҳоро қадр мекунем.) Бо вуҷуди ин, нуқтаи ибтидоии хуб аст etcdhelper аз OpenShift (ташаккур ба муаллифони он!).

Ин утилит метавонад бо истифода аз сертификатҳо ба etcd пайваст шавад ва бо истифода аз фармонҳо маълумотро аз он ҷо хонад ls, get, dump.

Иловаи etcdhelper

Фикри навбатӣ мантиқист: "Чӣ шуморо аз илова кардани ин утилита бо илова кардани қобилияти навиштани маълумот ба etcd бозмедорад?"

Он як версияи тағирёфтаи etcdhelper бо ду функсияи нав шуд changeServiceCIDR и changePodCIDR. бар вай шумо метавонед кодро бинед дар ин ҷо.

Хусусиятҳои нав чӣ кор мекунанд? Алгоритм changeServiceCIDR:

десериализатор эҷод кунед;
тартиб додани ифодаи муқаррарӣ барои иваз кардани CIDR;
мо ҳама хидматҳоро бо навъи ClusterIP дар кластер мегузарем:
- рамзкушоӣ кардани арзиш аз etcd ба объекти Go;
- бо истифода аз ифодаи муқаррарӣ ду байти аввали суроғаро иваз мекунем;
- ба хидмат суроғаи IP аз зершабакаи нав таъин кунед;
- сериализатор эҷод кунед, объекти Go-ро ба протобуф табдил диҳед, ба ғайра маълумоти нав нависед.

функсия changePodCIDR аслан монанд changeServiceCIDR - танҳо ба ҷои таҳрири мушаххасоти хидмат, мо онро барои гиреҳ ва тағир медиҳем .spec.PodCIDR ба зершабакаи нав.

Таҷҳизот

Тағир додани хидмати CIDR

Нақшаи иҷрои вазифа хеле содда аст, аммо он бекористиро дар вақти аз нав сохтани ҳамаи подкҳо дар кластер дар бар мегирад. Пас аз тавсифи қадамҳои асосӣ, мо инчунин фикру мулоҳизаҳоро дар бораи он, ки чӣ тавр дар назария, ин вақти бекориро ба ҳадди ақал расонидан мумкин аст, мубодила хоҳем кард.

Қадамҳои омодагӣ:

насб кардани нармафзори зарурӣ ва васл кардани etcdhelper patched;
нусхабардорӣ ва ғайра /etc/kubernetes.

Нақшаи чорабиниҳои мухтасар оид ба тағир додани serviceCIDR:

тағир додани манифестҳои apiserver ва контроллер-менеҷер;
аз нав нашр кардани сертификатҳо;
тағир додани хидматҳои ClusterIP дар etcd;
аз нав оғоз кардани ҳамаи подкҳо дар кластер.

Дар зер пайдарпайии пурраи амалҳо ба таври муфассал оварда шудааст.

1. Барои партови маълумот etcd-client насб кунед:

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 сертификатҳо медиҳад (аз ҷумла), онҳо бояд дубора интишор карда шаванд:

Биёед бубинем, ки сертификати ҷорӣ барои кадом доменҳо ва суроғаҳои 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 -ро аз зершабакаи кӯҳна ба нав иваз мекунад. Минбаъд дар мақола дар бораи имконоти имконпазир барои кам кардани вақти бекорӣ навишта шудааст.
Биёед ConfigMap-ро дар фазои ном ислоҳ кунем kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- ин ҷо иваз кунед clusterDNS ба суроғаи нави IP хидмати 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-ро тағир намедиҳад.
Суроғаро дар ҳама кубелетҳо иваз кунед ClusterDNS ба нав, дар ҳоле ки хидмати кӯҳна ҳамзамон бо нав кор мекунад.
Мунтазир бошед, ки қуттиҳои барномаҳо худ аз худ бо сабабҳои табиӣ ё дар вақти мувофиқашуда меғелонанд.
Хидматро нест кунед kube-dns-tmp ва тағйир serviceSubnetCIDR барои хизмати кубе-днс.

Ин нақша ба шумо имкон медиҳад, ки вақти бекориро то ~як дақиқа кам кунед - дар давоми вақти бартарафсозии хидмат kube-dns-tmp ва иваз кардани зершабакаи хидмат kube-dns.

Тағироти podNetwork

Ҳамзамон, мо тасмим гирифтем, ки чӣ гуна тағир додани podNetwork-ро бо истифода аз etcdhelper дар натиҷа бубинем. Пайдарпаии амалҳо чунин аст:

ислоҳ кардани конфигуратсияҳо дар kube-system;
ислоҳ кардани манифести kube-controller-менеҷер;
тағир додани podCIDR мустақиман дар etcd;
ҳамаи гиреҳҳои кластерро бозоғоз намоед.

Акнун бештар дар бораи ин амалҳо:

1. Тағир додани ConfigMap дар фазои ном 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. Биёед тафтиш кунем, ки 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-meneger оғоз карда наметавонад ва pods дар кластер ба нақша гирифта намешаванд.

Дар асл, тағир додани podCIDR метавонад боз ҳам соддатар анҷом дода шавад (масалан, ҳамин тавр). Аммо мо мехостем, ки чӣ тавр бевосита бо etcd кор карданро омӯзем, зеро ҳолатҳои таҳрири объектҳои Kubernetes дар etcd вуҷуд доранд - ягона варианти имконпазир. (Масалан, шумо наметавонед танҳо майдони Хидматро бидуни бекоркунӣ иваз кунед spec.clusterIP.)

Натиҷа

Дар мақола имкони кор бо додаҳо дар etcd бевосита баррасӣ мешавад, яъне. гузаштан аз API Kubernetes. Баъзан ин равиш ба шумо имкон медиҳад, ки "корҳои душвор" кунед. Мо амалҳои дар матн овардашударо дар кластерҳои воқеии K8s санҷидем. Бо вуҷуди ин, ҳолати омодагии онҳо барои истифодаи васеъ аст PoC (далели консепсия). Аз ин рӯ, агар шумо хоҳед, ки версияи тағирёфтаи утилитаи etcdhelper-ро дар кластерҳои худ истифода баред, ин корро бо хатари худ иҷро кунед.

PS

Инчунин дар блоги мо хонед:

Манбаъ: will.com

Таҷрибаи мо бо маълумот дар кластери etcd Kubernetes мустақиман (бе API K8s)