🥇Ang among kasinatian sa pagtrabaho sa data sa etcd Kubernetes cluster direkta (walay K8s API)

Nagkadaghan, ang mga kliyente naghangyo kanamo sa paghatag og access sa Kubernetes cluster aron maka-access sa mga serbisyo sulod sa cluster: aron direktang makakonektar sa pipila ka database o serbisyo, aron makonektar ang usa ka lokal nga aplikasyon sa mga aplikasyon sulod sa cluster...

Pananglitan, adunay panginahanglan sa pagkonektar gikan sa imong lokal nga makina ngadto sa usa ka serbisyo memcached.staging.svc.cluster.local. Gihatag namo kini nga kapabilidad gamit ang VPN sulod sa cluster diin ang kliyente nagkonektar. Aron mahimo kini, gipahibalo namon ang mga subnet sa mga pod, serbisyo ug pagduso sa cluster DNS sa kliyente. Busa, kung ang usa ka kliyente mosulay sa pagkonektar sa serbisyo memcached.staging.svc.cluster.local, ang hangyo moadto sa cluster DNS ug isip tubag makadawat sa adres niini nga serbisyo gikan sa cluster service network o sa pod address.

Among gi-configure ang K8s clusters gamit ang kubeadm, diin ang default service subnet 192.168.0.0/16, ug ang network sa mga pod mao ang 10.244.0.0/16. Kasagaran ang tanan molihok nga maayo, apan adunay pipila ka mga punto:

Subnet 192.168.*.* kasagarang gigamit sa mga network sa opisina sa kliyente, ug mas kanunay sa mga network sa balay sa developer. Ug unya matapos namon ang mga panagbangi: ang mga router sa balay nagtrabaho sa kini nga subnet ug ang VPN nagduso niini nga mga subnet gikan sa cluster ngadto sa kliyente.
Adunay kami daghang mga pungpong (produksyon, entablado ug/o daghang mga pungpong sa dev). Unya, pinaagi sa default, silang tanan adunay parehas nga mga subnet alang sa mga pod ug serbisyo, nga nagmugna daghang mga kalisud alang sa dungan nga pagtrabaho sa mga serbisyo sa daghang mga cluster.

Dugay na namong gisagop ang praktis sa paggamit sa lain-laing mga subnet para sa mga serbisyo ug pod sulod sa samang proyekto - sa kinatibuk-an, aron ang tanang cluster adunay lain-laing mga network. Bisan pa, adunay daghang daghang mga kumpol nga naglihok nga dili nako gusto nga ibalhin gikan sa wala, tungod kay nagpadagan sila daghang mga serbisyo, stateful nga aplikasyon, ug uban pa.

Ug dayon gipangutana namo ang among kaugalingon: unsaon pag-usab ang subnet sa usa ka kasamtangan nga cluster?

Pagpangita sa mga desisyon

Ang labing kasagaran nga praktis mao ang pag-recreate sa tanan nga mga mga serbisyo nga adunay tipo nga ClusterIP. Ingon usa ka kapilian, makatambag ug kini:

Ang mosunud nga proseso adunay problema: pagkahuman sa tanan nga na-configure, ang mga pod moabut sa daan nga IP ingon usa ka DNS nameserver sa /etc/resolv.conf.
Tungod kay wala pa nako makit-an ang solusyon, kinahanglan nako nga i-reset ang tibuuk nga cluster gamit ang pag-reset sa kubeadm ug i-init kini pag-usab.

Apan dili kini angay alang sa tanan... Ania ang mas detalyado nga mga pasiuna alang sa among kaso:

Ang flannel gigamit;
Adunay mga pungpong sa mga panganod ug sa hardware;
Gusto nakong likayan ang pag-deploy pag-usab sa tanang serbisyo sa cluster;
Adunay usa ka panginahanglan sa kinatibuk-ang pagbuhat sa tanan nga adunay usa ka minimum nga gidaghanon sa mga problema;
Ang bersyon sa Kubernetes mao ang 1.16.6 (bisan pa, ang dugang nga mga lakang mahimong parehas alang sa ubang mga bersyon);
Ang nag-unang tahas mao ang pagsiguro nga sa usa ka cluster nga gipakatap gamit ang kubeadm nga adunay subnet nga serbisyo 192.168.0.0/16, ilisan kini ug 172.24.0.0/16.

Ug nahitabo nga dugay na kami nga interesado nga makita kung unsa ug kung giunsa sa Kubernetes gitipigan sa etcd, kung unsa ang mahimo niini ... Mao nga naghunahuna kami: "Ngano nga dili na lang i-update ang datos sa etcd, ilisan ang daan nga mga IP address (subnet) sa mga bag-o? »

Ang pagpangita alang sa andam nga mga himan alang sa pagtrabaho sa mga datos sa etcd, wala kami nakit-an nga bisan unsa nga hingpit nga nakasulbad sa problema. (By the way, kung nahibal-an nimo ang bahin sa bisan unsang mga utilities alang sa pagtrabaho sa data direkta sa etcd, among gipasalamatan ang mga link.) Bisan pa, usa ka maayo nga punto sa pagsugod etcdhelper gikan sa OpenShift (salamat sa mga tagsulat niini!).

Kini nga utility makakonektar sa etcd gamit ang mga sertipiko ug magbasa sa datos gikan didto gamit ang mga sugo ls, get, dump.

Idugang ang etcdhelper

Ang sunod nga hunahuna makatarunganon: "Unsa ang nakapugong kanimo sa pagdugang niini nga gamit pinaagi sa pagdugang sa abilidad sa pagsulat sa datos sa etcd?"

Kini nahimo nga usa ka giusab nga bersyon sa etcdhelper nga adunay duha ka bag-ong mga gimbuhaton changeServiceCIDR и changePodCIDR. sa iyaha makita nimo ang code dinhi.

Unsa ang gibuhat sa bag-ong mga bahin? Algorithm changeServiceCIDR:

paghimo og deserializer;
pag-compile og regular nga ekspresyon aron ilisan ang CIDR;
giagian namon ang tanan nga mga serbisyo nga adunay klase nga ClusterIP sa cluster:
- decode sa bili gikan sa etcd ngadto sa usa ka Go butang;
- gamit ang regular nga ekspresyon atong ilisan ang unang duha ka byte sa adres;
- paghatag sa serbisyo og IP address gikan sa bag-ong subnet;
- paghimo og serializer, i-convert ang Go object ngadto sa protobuf, pagsulat og bag-ong data sa etcd.

function changePodCIDR esensya susama changeServiceCIDR - lamang imbis sa pag-edit sa espesipikasyon sa serbisyo, gibuhat namo kini alang sa node ug pagbag-o .spec.PodCIDR sa bag-ong subnet.

Pagpraktis

Usba ang serbisyo CIDR

Ang plano alang sa pagpatuman sa buluhaton yano ra kaayo, apan kini naglakip sa downtime sa panahon sa paghimo pag-usab sa tanan nga mga pod sa cluster. Human sa paghulagway sa mga nag-unang mga lakang, kita usab mopakigbahin sa mga hunahuna kon sa unsang paagi, sa teoriya, kini nga downtime mahimong maminusan.

Mga lakang sa pagpangandam:

pag-instalar sa gikinahanglan nga software ug pag-assemble sa gitambalan nga etcdhelper;
backup etcd ug /etc/kubernetes.

Mubo nga plano sa aksyon alang sa pagbag-o sa serbisyoCIDR:

pagbag-o sa apiserver ug controller-manager manifests;
pag-isyu pag-usab sa mga sertipiko;
pagbag-o sa mga serbisyo sa ClusterIP sa etcd;
I-restart ang tanan nga mga pod sa cluster.

Ang mosunod usa ka kompleto nga han-ay sa mga aksyon sa detalye.

1. I-install ang etcd-client para sa data dump:

apt install etcd-client

2. Pagtukod ug etcdhelper:

I-install ang 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

Nagtipig kami alang sa among kaugalingon etcdhelper.go, pag-download sa mga dependency, pagkolekta:

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. Paghimo og backup etcd:

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. Usba ang service subnet sa Kubernetes control plane manifests. Sa mga file /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml usba ang parameter --service-cluster-ip-range sa bag-ong subnet: 172.24.0.0/16 imbis nga 192.168.0.0/16.

5. Tungod kay gibag-o namon ang subnet sa serbisyo diin ang kubeadm nag-isyu sa mga sertipiko para sa apiserver (lakip na), kini kinahanglan nga i-isyu pag-usab:

Atong tan-awon kung unsang mga domain ug mga IP address ang gihatag karon nga sertipiko:

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

Mag-andam kita og gamay nga config para sa 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-адрес мастер узла

Atong tangtangon ang daan nga crt ug yawe, tungod kay kung wala kini ang bag-ong sertipiko dili ma-isyu:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```

Atong i-isyu pag-usab ang mga sertipiko para sa API server:

kubeadm init phase certs apiserver --config=kubeadm-config.yaml

Atong susihon nga ang sertipiko gihatag alang sa bag-ong subnet:

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

Human sa pag-isyu pag-usab sa API server certificate, i-restart ang sudlanan niini:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
Atong i-regenerate ang config para admin.conf:
```
kubeadm alpha certs renew admin.conf
```
Atong usbon ang datos sa 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 
```
Pasidaan Niining higayona, ang resolusyon sa domain mihunong sa pagtrabaho sa cluster, tungod kay sa kasamtangan nga mga pod /etc/resolv.conf ang daan nga CoreDNS address (kube-dns) narehistro, ug ang kube-proxy nag-usab sa mga lagda sa iptables gikan sa daan nga subnet ngadto sa bag-o. Dugang pa sa artikulo gisulat kini bahin sa posible nga mga kapilian aron maminusan ang oras sa pag-undang.
Ayuhon nato ang ConfigMap sa namespace kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- ilisan dinhi clusterDNS sa bag-ong IP address sa serbisyo sa kube-dns: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
- ayohon namo kini data.ClusterConfiguration.networking.serviceSubnet sa bag-ong subnet.
Tungod kay ang kube-dns nga adres nausab, gikinahanglan nga i-update ang kubelet config sa tanang node:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```

Ang nahabilin mao ang pag-restart sa tanan nga mga pod sa cluster:

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

Pagmenos sa downtime

Mga hunahuna kon unsaon pagpamenos sa downtime:

Human mabag-o ang gipakita nga control plane, paghimo usa ka bag-ong serbisyo sa kube-dns, pananglitan, nga adunay ngalan kube-dns-tmp ug bag-ong adres 172.24.0.10.
Paghimo if sa etcdhelper, nga dili usbon ang serbisyo sa kube-dns.
Ilisan ang adres sa tanang kubelets ClusterDNS sa usa ka bag-o, samtang ang daan nga serbisyo magpadayon sa pagtrabaho nga dungan sa bag-o.
Paghulat hangtud nga ang mga pod nga adunay mga aplikasyon magligid sa ilang kaugalingon alang sa natural nga mga hinungdan o sa gikasabutan nga oras.
Pagtangtang sa serbisyo kube-dns-tmp ug pagbag-o serviceSubnetCIDR para sa serbisyo sa kube-dns.

Kini nga plano magtugot kanimo sa pagpamenos sa downtime ngadto sa ~usa ka minuto - alang sa gidugayon sa pagtangtang sa serbisyo kube-dns-tmp ug pag-ilis sa subnet para sa serbisyo kube-dns.

Pagbag-o podNetwork

Sa parehas nga oras, nakahukom kami nga tan-awon kung giunsa ang pagbag-o sa podNetwork gamit ang sangputanan nga etcdhelper. Ang han-ay sa mga aksyon mao ang mosunod:

pag-ayo sa mga config sa kube-system;
pag-ayo sa kube-controller-manager manifest;
usba ang podCIDR direkta sa etcd;
I-reboot ang tanan nga mga cluster node.

Karon dugang mahitungod niini nga mga aksyon:

1. Usba ang ConfigMap sa namespace kube-system:

kubectl -n kube-system edit cm kubeadm-config

- pagtul-id data.ClusterConfiguration.networking.podSubnet sa bag-ong subnet 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- pagtul-id data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Usba ang controller-manager manifest:

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

- pagtul-id --cluster-cidr=10.55.0.0/16.

3. Tan-awa ang kasamtangang mga bili .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses para sa tanang cluster node:

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. Ilisan podCIDR pinaagi sa paghimo sa mga kausaban direkta ngadto sa 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-pod-cidr 10.55.0.0/16

5. Atong susihon nga ang podCIDR tinuod nga nausab:

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. Atong i-reboot ang tanang cluster node sa tinagsa.

7. Kon ikaw mobiya sa labing menos usa ka node daan nga podCIDR, unya ang kube-controller-manager dili makasugod, ug ang mga pod sa cluster dili ma-iskedyul.

Sa tinuud, ang pagbag-o sa podCIDR mahimo nga labi ka yano (pananglitan, mao nga). Apan gusto namon nga makat-on kung giunsa ang pagtrabaho sa etcd direkta, tungod kay adunay mga kaso kung ang pag-edit sa mga butang sa Kubernetes sa etcd - ang bugtong posible nga variant. (Pananglitan, dili nimo mabag-o ang natad sa Serbisyo nga wala’y downtime spec.clusterIP.)

Ang resulta

Ang artikulo naghisgot sa posibilidad sa pagtrabaho uban sa data sa etcd direkta, i.e. pag-bypass sa Kubernetes API. Usahay kini nga pamaagi nagtugot kanimo sa pagbuhat sa "makalilisang nga mga butang". Among gisulayan ang mga operasyon nga gihatag sa teksto sa tinuod nga K8s clusters. Bisan pa, ang ilang kahimtang sa pagkaandam alang sa kaylap nga paggamit mao PoC (pamatuod sa konsepto). Busa, kung gusto nimo mogamit usa ka giusab nga bersyon sa etcdhelper utility sa imong mga cluster, buhata kini sa imong kaugalingon nga peligro.

PS

Basaha usab sa among blog:

Source: www.habr.com

Ang among kasinatian nga nagtrabaho sa datos sa etcd Kubernetes cluster direkta (walay K8s API)