🥇Naše zkušenosti s přímou prací s daty v etcd clusteru Kubernetes (bez K8s API)

Stále častěji nás klienti žádají o poskytnutí přístupu ke clusteru Kubernetes, aby měli přístup ke službám v rámci clusteru: abychom se mohli přímo připojit k nějaké databázi nebo službě, abychom propojili lokální aplikaci s aplikacemi v rámci clusteru...

Například je potřeba se z místního počítače připojit ke službě memcached.staging.svc.cluster.local. Tuto možnost poskytujeme pomocí VPN v rámci clusteru, ke kterému se klient připojuje. K tomu klientovi oznamujeme podsítě podů, služeb a push clusteru DNS. Tedy, když se klient pokusí připojit ke službě memcached.staging.svc.cluster.local, požadavek přejde do clusteru DNS a jako odpověď obdrží adresu této služby ze sítě clusterových služeb nebo adresy pod.

Klastry K8s konfigurujeme pomocí kubeadm, kde je výchozí podsíť služeb 192.168.0.0/16, a síť podů je 10.244.0.0/16. Obvykle vše funguje dobře, ale existuje několik bodů:

Podsíť 192.168.*.* často používané v sítích klientských kanceláří a ještě častěji v domácích sítích vývojářů. A pak se dostáváme ke konfliktům: domácí routery fungují na této podsíti a VPN tyto podsítě tlačí z clusteru ke klientovi.
Máme několik clusterů (produkční, etapový a/nebo několik vývojových clusterů). Ve výchozím nastavení pak všechny budou mít stejné podsítě pro pody a služby, což vytváří velké potíže pro současnou práci se službami v několika clusterech.

Již dávno jsme přijali praxi používání různých podsítí pro služby a moduly v rámci stejného projektu – obecně tak, že všechny clustery mají různé sítě. V provozu je však velké množství clusterů, které bych nerad převaloval od nuly, protože na nich běží mnoho služeb, stavových aplikací atd.

A pak jsme si položili otázku: jak změnit podsíť ve stávajícím clusteru?

Hledejte řešení

Nejběžnější praxí je rekreace vše služby typu ClusterIP. Jako možnost může poradit a tohle:

Následující proces má problém: poté, co vše nakonfigurujete, pody přijdou se starou IP jako DNS nameserver v /etc/resolv.conf.
Protože jsem stále nenašel řešení, musel jsem resetovat celý cluster pomocí resetu kubeadm a znovu jej spustit.

To ale není vhodné pro každého... Zde jsou podrobnější úvody pro náš případ:

Používá se flanel;
Existují clustery jak v cloudech, tak na hardwaru;
Rád bych se vyhnul opětovnému nasazení všech služeb v clusteru;
Všeobecně je potřeba dělat vše s minimálním počtem problémů;
Verze Kubernetes je 1.16.6 (další kroky však budou pro ostatní verze podobné);
Hlavním úkolem je zajistit, aby v clusteru nasazeném pomocí kubeadm byla podsíť služeb 192.168.0.0/16, nahraďte jej 172.24.0.0/16.

A tak se stalo, že nás dlouho zajímalo, co a jak je v Kubernetes uloženo v etcd, co se s tím dá dělat... Tak jsme si řekli: “Proč prostě neaktualizovat data v etcd a nahradit staré IP adresy (podsítě) novými? "

Po hledání hotových nástrojů pro práci s daty v etcd jsme nenašli nic, co by problém úplně vyřešilo. (Mimochodem, pokud víte o nějakých utilitách pro práci s daty přímo v etcd, budeme rádi za odkazy.) Nicméně, dobrý výchozí bod je etcdhelper z OpenShift (díky jejím autorům!).

Tento nástroj se může připojit k etcd pomocí certifikátů a číst data odtud pomocí příkazů ls, get, dump.

Přidejte etcdhelper

Další myšlenka je logická: "Co vám brání přidat tento nástroj přidáním možnosti zapisovat data do etcd?"

Stala se upravenou verzí etcdhelper se dvěma novými funkcemi changeServiceCIDR и changePodCIDR. na ní můžete vidět kód zde.

Co dělají nové funkce? Algoritmus changeServiceCIDR:

vytvořit deserializátor;
zkompilovat regulární výraz, který nahradí CIDR;
procházíme všechny služby s typem ClusterIP v clusteru:
- dekódovat hodnotu z etcd do objektu Go;
- pomocí regulárního výrazu nahradíme první dva bajty adresy;
- přiřadit službě IP adresu z nové podsítě;
- vytvořit serializátor, převést objekt Go na protobuf, zapsat nová data do etcd.

Funkce changePodCIDR v podstatě podobný changeServiceCIDR - pouze místo úpravy specifikace služby to uděláme pro uzel a změnu .spec.PodCIDR do nové podsítě.

Praxe

Změna služby CIDR

Plán implementace úlohy je velmi jednoduchý, ale zahrnuje prostoje v době opětovného vytvoření všech modulů v clusteru. Po popisu hlavních kroků se také podělíme o myšlenky, jak lze teoreticky tyto prostoje minimalizovat.

Přípravné kroky:

instalace potřebného softwaru a sestavení opraveného etcdhelper;
zálohování atdd a /etc/kubernetes.

Stručný akční plán pro změnu serviceCIDR:

změna manifestů apiserver a controller-manager;
opětovné vydání certifikátů;
změna služeb ClusterIP v etcd;
restartování všech modulů v clusteru.

Následuje podrobný úplný sled akcí.

1. Nainstalujte etcd-client pro výpis dat:

apt install etcd-client

2. Sestavení etcdhelper:

Nainstalujte 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

Šetříme pro sebe etcdhelper.go, stáhnout závislosti, shromáždit:

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. Vytvořte zálohu atd.

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. Změňte podsíť služeb v manifestech řídicí roviny Kubernetes. V souborech /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml změnit parametr --service-cluster-ip-range do nové podsítě: 172.24.0.0/16 místo 192.168.0.0/16.

5. Protože měníme podsíť služeb, do které kubeadm vydává certifikáty pro apiserver (včetně), je třeba je znovu vydat:

Podívejme se, pro které domény a IP adresy byl vydán aktuální certifikát:

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

Připravíme si minimální konfiguraci pro 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-адрес мастер узла

Smažte starý crt a klíč, protože bez toho nebude nový certifikát vydán:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```

Pojďme znovu vystavit certifikáty pro server API:

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

Zkontrolujeme, zda byl certifikát vydán pro novou podsíť:

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

Po opětovném vydání certifikátu serveru API restartujte jeho kontejner:

docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

Pojďme znovu vygenerovat konfiguraci pro admin.conf:
```
kubeadm alpha certs renew admin.conf
```
Upravme data v 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 
```
Varování! V tuto chvíli přestává v clusteru fungovat rozlišení domény, protože ve stávajících podech /etc/resolv.conf stará adresa CoreDNS (kube-dns) je zaregistrována a kube-proxy změní pravidla iptables ze staré podsítě na novou. Dále se v článku píše o možných možnostech minimalizace prostojů.
Opravme ConfigMap ve jmenném prostoru kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- vyměňte zde clusterDNS na novou IP adresu služby kube-dns: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
- opravíme to data.ClusterConfiguration.networking.serviceSubnet do nové podsítě.
Protože se adresa kube-dns změnila, je nutné aktualizovat konfiguraci kubelet na všech uzlech:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```

Zbývá pouze restartovat všechny moduly v clusteru:

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

Minimalizujte prostoje

Nápady, jak minimalizovat prostoje:

Po změně manifestů řídicí roviny vytvořte novou službu kube-dns, například s názvem kube-dns-tmp a novou adresu 172.24.0.10.
Udělat if v etcdhelper, který nezmění službu kube-dns.
Nahraďte adresu ve všech kubeletech ClusterDNS na novou, přičemž stará služba bude nadále fungovat současně s novou.
Počkejte, až se tobolky s aplikacemi převalí buď samy od sebe z přirozených důvodů, nebo v dohodnutou dobu.
Smazat službu kube-dns-tmp a změnit serviceSubnetCIDR pro službu kube-dns.

Tento plán vám umožní minimalizovat prostoje na ~ minutu - po dobu odstranění služby kube-dns-tmp a změna podsítě pro službu kube-dns.

Modifikace podNetwork

Zároveň jsme se rozhodli podívat se na to, jak upravit podNetwork pomocí výsledného etcdhelper. Posloupnost akcí je následující:

oprava konfigurací v kube-system;
oprava manifestu kube-controller-manager;
změnit podCIDR přímo v etcd;
restartujte všechny uzly clusteru.

Nyní více o těchto akcích:

1. Upravte ConfigMap ve jmenném prostoru kube-system:

kubectl -n kube-system edit cm kubeadm-config

- opravování data.ClusterConfiguration.networking.podSubnet do nové podsítě 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- opravování data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Upravte manifest správce-správce:

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

- opravování --cluster-cidr=10.55.0.0/16.

3. Podívejte se na aktuální hodnoty .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses pro všechny uzly clusteru:

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. Nahraďte podCIDR provedením změn přímo v 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. Zkontrolujte, zda se podCIDR skutečně změnil:

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. Restartujme všechny uzly clusteru jeden po druhém.

7. Pokud ponecháte alespoň jeden uzel starý podCIDR, pak se kube-controller-manager nebude moci spustit a pody v clusteru nebudou naplánovány.

Ve skutečnosti lze změnu podCIDR provést ještě jednodušeji (např. tak). Chtěli jsme se ale naučit pracovat s etcd přímo, protože existují případy, kdy editujete Kubernetes objekty v etcd - jediný možná varianta. (Například nemůžete jen změnit pole Služba bez výpadku spec.clusterIP.)

Celkový

Článek pojednává o možnosti práce s daty v etcd přímo, tzn. obcházení Kubernetes API. Někdy vám tento přístup umožňuje dělat „ošidné věci“. Operace uvedené v textu jsme testovali na skutečných clusterech K8s. Jejich stav připravenosti k širokému použití je však takový PoC (proof of concept). Pokud tedy chcete na svých clusterech používat upravenou verzi utility etcdhelper, činíte tak na vlastní nebezpečí.