🥇 Tecrûbeya me ya xebata bi daneyan re di koma Kubernetes ya etcd de rasterast (bê K8s API)

Zêdetir, xerîdar ji me daxwaz dikin ku em gihîştina koma Kubernetes peyda bikin da ku karibin bigihîjin karûbarên di nav komê de: da ku ew rasterast bi databasek an karûbarek ve girêdayî bin, da ku serîlêdanek herêmî bi serîlêdanên di nav komê ve girêbidin…

Mînakî, pêdivî ye ku meriv ji makîneya xweya herêmî bi karûbarek ve girêdayî be memcached.staging.svc.cluster.local. Em vê kapasîteyê bi karanîna VPN-ê di nav koma ku xerîdar pê ve girêdide peyda dikin. Ji bo kirina vê yekê, em jêrtorên pods, karûbaran û DNS-ya komê ji xerîdar re radigihînin. Ji ber vê yekê, gava ku xerîdar hewl dide ku bi karûbarê ve girêdayî be memcached.staging.svc.cluster.local, daxwaz diçe koma DNS-ê û di bersivê de navnîşana vê karûbarê ji tora karûbarê komê an navnîşana pod distîne.

Em komikên K8s bi karanîna kubeadm veava dikin, ku li wir jêrtora karûbarê xwerû ye 192.168.0.0/16, û tora podan e 10.244.0.0/16. Bi gelemperî her tişt baş dixebite, lê çend xal hene:

Subnet 192.168.*.* pir caran di torên nivîsgeha xerîdar de, û hêj bêtir di torên malê yên pêşdebiran de têne bikar anîn. Dûv re em nakokî distînin: rêwerên malê li ser vê jêrtorê dixebitin û VPN van jêrtoran ji komê ber bi xerîdar ve dihêle.
Gelek komên me hene (hilberîn, qonax û / an jî çend komên dev). Dûv re, ji hêla xwerû, hemî wan dê ji bo pod û karûbaran xwedan heman subnets bin, ku ev yek ji bo xebata hevdemî bi karûbaran re di çend koman de zehmetiyên mezin diafirîne.

Me demek berê pratîka karanîna jêrtorên cihêreng ji bo karûbar û podan di nav yek projeyê de pejirand - bi gelemperî, da ku hemî kom xwedan torên cûda bin. Lêbelê, di operasyonê de hejmareke mezin a koman hene ku ez naxwazim ji sifirê vegerînim, ji ber ku ew gelek karûbar, serîlêdanên dewletî, hwd.

Û dûv re me ji xwe pirsî: meriv çawa di koma heyî de subnet biguhezîne?

Lêgerîna biryaran

Pratîka herî gelemperî ji nû ve çêkirinê ye hemî xizmetên bi cureyê ClusterIP. Wek vebijêrk, dikare şîret bike û ev:

Pêvajoya jêrîn pirsgirêkek heye: piştî ku her tişt hate mîheng kirin, pod di /etc/resolv.conf de IP-ya kevn wekî serverek navek DNS-ê derdikevin.
Ji ber ku min hîn jî çareserî nedît, min neçar ma ku bi vesazkirina kubeadm tevahî komê reset bikim û dîsa dest pê bikim.

Lê ev ji bo her kesî ne guncaw e... Li vir ji bo doza me danasîna berfirehtir hene:

Flannel tê bikaranîn;
Hem di ewran de hem jî li ser hardware kom hene;
Ez dixwazim xwe ji nûvekirina hemî karûbarên di komê de dûr bixim;
Pêdivî ye ku bi gelemperî her tişt bi hejmareke kêmtirîn pirsgirêkan re bikin;
Guhertoya Kubernetes 1.16.6 e (lêbelê, gavên din dê ji bo guhertoyên din wekhev bin);
Karê sereke ev e ku meriv pê ewle bike ku di komikek ku kubeadm-ê bi jêr-netek karûbarê ve hatî bikar anîn de hatî bicîh kirin 192.168.0.0/16, li şûna wê 172.24.0.0/16.

Û wusa bû ku em demek dirêj eleqedar bûn ku em bibînin ka di Kubernetes de çi û çawa di etcd de tê hilanîn, çi dikare bi wê re were kirin… Ji ber vê yekê em fikirîn:Çima ne tenê daneyên di etcd de nûve bikin, navnîşanên IP-yê yên kevn (subnet) bi yên nû veguherînin? »

Dema ku li amûrên amade yên ji bo xebata bi daneyan di etcd de geriyam, me tiştek ku pirsgirêk bi tevahî çareser bike nedît. (Bi awayê, heke hûn di derheqê karûbaran de ji bo xebata bi daneyan rasterast di etcd de dizanin, em ê ji girêdanan re spas bikin.) Lêbelê, xalek destpêkek baş e etcdhelper ji OpenShift (spas ji bo nivîskarên wê!).

Ev karûbar dikare bi karanîna sertîfîkayan bi etcd ve girêbide û bi karanîna fermanan daneyan ji wir bixwîne ls, get, dump.

etcdhelper zêde bikin

Ramana paşîn mentiqî ye: "Çi dihêle ku hûn vê amûreyê zêde bikin bi zêdekirina şiyana nivîsandina daneyan li etcd?"

Ew bû guhertoyek guhezbar ya etcdhelper bi du fonksiyonên nû changeServiceCIDR и changePodCIDR. li ser wê hûn dikarin kodê bibînin vir.

Taybetmendiyên nû çi dikin? Algorithm changeServiceCIDR:

deserializer ava bikin;
birêkûpêkek birêkûpêk berhev bikin ku li şûna CIDR-ê biguhezînin;
em hemî karûbarên bi celebê ClusterIP-ê di komê de derbas dikin:
- nirxê ji etcd-ê di tiştek Go deşîfre bike;
- bi karanîna birêkûpêkek birêkûpêk em du baytên pêşîn ên navnîşanê diguhezînin;
- karûbarê navnîşanek IP-ê ji jêrtora nû veqetînin;
- serializatorek biafirînin, tiştê Go veguherînin protobuf, daneyên nû li etcd binivîsin.

function changePodCIDR esasî dişibin hev changeServiceCIDR - tenê li şûna ku em taybetmendiya karûbarê biguherînin, em wê ji bo nodê dikin û diguhezînin .spec.PodCIDR li jêrtoreke nû.

Praktice

Guhertina karûbarê CIDR

Plana bicihanîna peywirê pir hêsan e, lê dema ku hemî podên di komê de ji nû ve têne nûve kirin, navberê vedihewîne. Piştî danasîna gavên sereke, em ê di heman demê de ramanan jî parve bikin ka, di teoriyê de, ev demdirêj çawa dikare were kêm kirin.

Gavên amadekariyê:

sazkirina nermalava pêwîst û berhevkirina etcdhelper-a patched;
hilanînê etcd û /etc/kubernetes.

Plana çalakiyê ya kurt ji bo guheztina karûbarêCIDR:

guhertina apiserver û nîşaneyên kontrolker-rêveber;
dubare weşandina sertîfîkayan;
guhertina karûbarên ClusterIP di etcd de;
ji nû ve destpêkirina hemî pelên di komê de.

Li jêr rêzek bêkêmasî ya çalakiyan bi hûrgulî ye.

1. Ji bo avêtina daneyê etcd-client saz bikin:

apt install etcd-client

2. Avakirina etcdhelper:

Golang saz bikin:

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

Em ji bo xwe xilas dikin etcdhelper.go, girêdanan dakêşin, berhev bikin:

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. Piştgiriyek etcd çêbikin:

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. Di pêşandanên balafira kontrolê ya Kubernetes de subneta karûbarê biguhezînin. Di pelan de /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml parametreyê biguherîne --service-cluster-ip-range ji bo jêrtoreke nû: 172.24.0.0/16 li gorî 192.168.0.0/16.

5. Ji ber ku em subneta karûbarê ku kubeadm ji bo apiserver sertîfîkayan derdixe diguherînin (di nav de), pêdivî ye ku ew ji nû ve werin weşandin:

Ka em bibînin ka sertîfîkaya heyî ji bo kîjan domain û navnîşanên IP-yê hatî derxistin:

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

Ka em ji bo kubeadm mîhengek hindiktirîn amade bikin:

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

Ka em crt û mifteya kevn jêbikin, ji ber ku bêyî vê sertîfîkaya nû nayê derxistin:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```
Ka em sertîfîkayên ji bo servera API-ê ji nû ve biweşînin:
```
kubeadm init phase certs apiserver --config=kubeadm-config.yaml
```

Ka em kontrol bikin ka sertîfîka ji bo subneta nû hatîye derxistin:

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

Piştî ku sertîfîkaya servera API-yê ji nû ve biweşîne, konteynera wê ji nû ve bidin destpêkirin:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
Werin em veavakirina ji bo nûjen bikin admin.conf:
```
kubeadm alpha certs renew admin.conf
```
Ka em daneyan di etcd de biguherînin:
```
./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 
```
Hişyariya kerema xwe! Di vê gavê de, çareseriya domainê di komê de xebata xwe disekine, ji ber ku di podên heyî de di hundurê de ye /etc/resolv.conf navnîşana CoreDNS ya kevn (kube-dns) tê tomar kirin, û kube-proxy qaîdeyên iptables ji jêrtora kevn diguhezîne ya nû. Zêdetir di gotarê de li ser vebijarkên mimkun ên ji bo kêmkirina demdirêjiyê hatî nivîsandin.
Ka em ConfigMap-ên di nav qada navan de rast bikin kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- li vir biguherînin clusterDNS ji navnîşana IP-ya nû ya karûbarê kube-dns: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
- em ê çareser bikin data.ClusterConfiguration.networking.serviceSubnet li jêrtoreke nû.
Ji ber ku navnîşana kube-dns guherî ye, pêdivî ye ku konfigurasyona kubelet li ser hemî girêkan nûve bike:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```

Tiştê ku dimîne ev e ku hûn hemî podên di komê de ji nû ve bidin destpêkirin:

kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'

Demjimêra domandinê kêm bikin

Ramanên li ser ka meriv çawa dema domandinê kêm dike:

Piştî guheztina nîşana balafira kontrolê, karûbarek nû ya kube-dns, mînakî, bi navê xwe biafirînin kube-dns-tmp û navnîşana nû 172.24.0.10.
Ji bo çêkirina if di etcdhelper de, ku dê karûbarê kube-dns neguhezîne.
Di hemî kubeletan de navnîşan biguherînin ClusterDNS ji yekî nû re, dema ku karûbarê kevin dê bi ya nû re hevdem bixebite.
Li bendê bin heya ku pelên bi serîlêdan bi serê xwe ji ber sedemên xwezayî an di demek lihevkirî de bizivirin.
Xizmetê jêbirin kube-dns-tmp û guhertin serviceSubnetCIDR ji bo xizmeta kube-dns.

Ev plan dê bihêle ku hûn ji bo dirêjahiya rakirina karûbarê ~ deqeyekê domdariya domandinê kêm bikin kube-dns-tmp û guhertina subnet ji bo xizmetê kube-dns.

Guhertina podNetwork

Di heman demê de, me biryar da ku em binihêrin ka meriv çawa podNetwork-ê bi karanîna etcdhelper-a encam digire biguhezîne. Rêza çalakiyan wiha ye:

rastkirina mîhengan tê de kube-system;
rastkirina manîfestoya kube-kontroller-rêveber;
podCIDR rasterast di etcd de biguherînin;
hemî girêkên komê ji nû ve bidin destpêkirin.

Niha bêtir li ser van çalakiyan:

1. ConfigMaps di navan de biguherînin kube-system:

kubectl -n kube-system edit cm kubeadm-config

- rastkirin data.ClusterConfiguration.networking.podSubnet li jêrtoreke nû 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- rastkirin data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Manîfestoya kontrolker-rêveber biguherînin:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

- rastkirin --cluster-cidr=10.55.0.0/16.

3. Li nirxên heyî binêrin .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses ji bo hemî girêkên komê:

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. Bi guherandina rasterast li etcd-ê podCIDR biguhezînin:

./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. Ka em kontrol bikin ku podCIDR bi rastî guherî ye:

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. Werin em hemî girêkên komê yek bi yek ji nû ve bidin destpêkirin.

7. Ger tu bi kêmanî yek node bihêle kevin podCIDR, wê hingê kube-kontroller-rêveber dê nikaribe dest pê bike, û podên di komê de dê neyên plansaz kirin.

Bi rastî, guhartina podCIDR dikare hê hêsantir jî were kirin (mînak, wiha). Lê me dixwest em fêr bibin ka meriv çawa rasterast bi etcd re bixebite, ji ber ku dema ku tiştên Kubernetes di etcd de biguherînin hene - tenê guhertoya gengaz. (Mînakî, hûn nekarin tenê qada Karûbar bêyî demjimêr biguhezînin spec.clusterIP.)

Encam

Gotar li ser îmkana xebata bi daneyan li etcd rasterast nîqaş dike, ango. derbaskirina Kubernetes API. Carinan ev nêzîkatî dihêle hûn "tiştên dijwar" bikin. Me operasyonên ku di nivîsê de hatine dayîn li ser komên K8s ên rastîn ceribandin. Lêbelê, rewşa wan a amadebûna ji bo karanîna berfireh e PoC (delîlên konseptê). Ji ber vê yekê, heke hûn dixwazin guhertoyek guhezbar a kargêriya etcdhelper li ser komên xwe bikar bînin, wiya bi xetereya xwe bikin.

PS

Li ser bloga me jî bixwînin:

Source: www.habr.com

Tecrûbeya me ya bi daneyan re di komika etcd Kubernetes de rasterast (bê K8s API)