🥇Unsere Erfahrungen mit Daten im etcd Kubernetes-Cluster direkt (ohne K8s API)

Immer mehr Kunden wenden sich an uns mit der Bitte, Zugang zum Kubernetes-Cluster zu gewähren, um auf die Dienste innerhalb des Clusters zugreifen zu können: damit man sich direkt mit einer bestimmten Datenbank oder einem Dienst verbinden kann, um eine lokale Anwendung mit Anwendungen innerhalb des Clusters zu verbinden…

Beispielsweise besteht die Notwendigkeit, sich von seinem lokalen Rechner mit dem Dienst memcached.staging.svc.cluster.localzu verbinden. Wir bieten diese Möglichkeit über ein VPN innerhalb des Clusters an, mit dem sich der Kunde verbindet. Dazu kündigen wir die Subnetze der Pods, der Dienste an und pushen die Cluster-DNS an den Kunden. Wenn der Kunde also versucht, sich mit dem Dienst memcached.staging.svc.cluster.localzu verbinden, geht die Anfrage an das Cluster-DNS und erhält die Adresse dieses Dienstes aus dem Servicenetz des Clusters oder die Adresse des Pods zurück.

Die K8s-Cluster richten wir mit kubeadm ein, wobei das Standard-Servicenetz – 192.168.0.0/16und das Pod-Netz – 10.244.0.0/16ist. Normalerweise funktioniert alles gut, aber es gibt ein paar Punkte:

Das Subnetz 192.168.*.* wird häufig in den Büros von Kunden eingesetzt, aber noch häufiger in den Heimnetzwerken von Entwicklern. Daraus ergeben sich Konflikte: Heimrouter arbeiten in diesem Subnetz, und das VPN überträgt diese Subnetze aus dem Cluster an den Kunden.
Wir haben mehrere Cluster (Produktionscluster, Stage-Cluster und/oder mehrere Entwicklungscluster). Dadurch haben alle standardmäßig dieselben Subnetze für Pods und Dienste, was erhebliche Schwierigkeiten verursacht, wenn man gleichzeitig mit Diensten in mehreren Clustern arbeiten möchte.

Bereits seit geraumer Zeit haben wir die Praxis angenommen, verschiedene Subnetze für Dienste und Pods innerhalb eines Projekts zu verwenden – insgesamt, um sicherzustellen, dass alle Cluster unterschiedliche Netzwerke haben. Es gibt jedoch eine beträchtliche Anzahl von Clustern in Betrieb, die man nicht von Grund auf neu aufsetzen möchte, da viele Dienste, stateful-Anwendungen usw. darin laufen.

Und so haben wir uns die Frage gestellt: Wie können wir das Subnetz in einem bestehenden Cluster ändern?

Suche nach Lösungen

Die gängigste Praxis besteht darin, alle Dienste vom Typ ClusterIP neu zu erstellen. Alternativ können auch Folgendes empfohlen werden: und das:

Der folgende Prozess hat ein Problem: Nachdem alles konfiguriert ist, starten die Pods mit der alten IP als DNS-Namensserver in /etc/resolv.conf.
Da ich die Lösung noch nicht gefunden habe, musste ich das gesamte Cluster mit kubeadm zurücksetzen und neu initialisieren.

Aber das passt nicht für alle… Hier sind genauere Informationen für unseren Fall:

Flannel wird verwendet;
Es gibt Cluster sowohl in der Cloud als auch auf physischer Hardware;
Ich möchte vermeiden, alle Dienste im Cluster erneut bereitzustellen;
Es besteht die Notwendigkeit, alles mit minimalen Problemen zu erledigen;
Die Kubernetes-Version ist 1.16.6 (übrigens werden die nächsten Schritte auch für andere Versionen ähnlich sein);
Die Hauptaufgabe besteht darin, im Cluster, der mit kubeadm und einem Dienstnetzwerk bereitgestellt wurde, 192.168.0.0/16dieses auf 172.24.0.0/16.

Und zufällig war es so, dass wir schon lange interessiert waren, was und wie in Kubernetes in etcd gespeichert wird, und was man damit überhaupt machen kann… Und daher dachten wir: "Warum die Daten in etcd nicht einfach aktualisieren, indem wir die alten IP-Adressen (Subnetz) durch neue ersetzen??»

Nachdem wir nach vorhandenen Werkzeugen für die Arbeit mit Daten in etcd gesucht hatten, fanden wir nichts, das die gestellte Aufgabe vollständig löst. (Übrigens, wenn Sie von irgendwelchen Tools wissen, die direkt mit Daten in etcd arbeiten – wir wären dankbar für Links.) Eine gute Ausgangsbasis war jedoch etcdhelper von OpenShift (Danke an die Autoren!).

Dieses Tool kann sich mit etcd über Zertifikate verbinden und Daten dort mit Kommandos lesen. ls, get, dump.

Wir erweitern etcdhelper.

Der nächste Gedanke ist naheliegend: "Was hindert uns daran, dieses Tool zu erweitern und die Möglichkeit hinzuzufügen, Daten in etcd zu schreiben?"

Das wurde in einer modifizierten Version von etcdhelper mit zwei neuen Funktionen umgesetzt. changeServiceCIDR und changePodCIDR. Ihr Code kann eingesehen werden. hier.

Was machen die neuen Funktionen? Algorithmen changeServiceCIDR:

wir erstellen einen Deserialisierer;
wir kompilieren einen regulären Ausdruck zur Änderung von CIDR;
wir durchlaufen alle ClusterIP-Services im Cluster:
- wir dekodieren den Wert aus etcd in ein Go-Objekt;
- wir ersetzen mit dem regulären Ausdruck die ersten beiden Bytes der Adresse;
- wir weisen dem Service eine IP-Adresse aus dem neuen Subnetz zu;
- wir erstellen einen Serializer, wandeln das Go-Objekt in Protobuf um und schreiben die neuen Daten in etcd.

Die Funktion changePodCIDR ist im Grunde genommen ähnlich changeServiceCIDR — nur anstatt die Spezifikation der Services zu bearbeiten, tun wir dies für den Knoten und ändern .spec.PodCIDR in das neue Subnetz.

Praxis

Änderung von serviceCIDR.

Der Plan zur Umsetzung der gestellten Aufgabe ist sehr einfach, beinhaltet jedoch Downtime während der Neuerstellung aller Pods im Cluster. Nach der Beschreibung der wesentlichen Schritte werden wir auch Gedanken teilen, wie man in der Theorie diese Downtime minimieren kann.

Vorbereitende Maßnahmen:

Installation der erforderlichen Software und Kompilierung des gepatchten etcdhelper;
Backup von etcd und /etc/kubernetes.

Ein kurzer Aktionsplan zur Änderung des serviceCIDR:

Änderung der Manifeste von apiserver und controller-manager;
Neuausstellung von Zertifikaten;
Änderung der ClusterIP-Services in etcd;
Neustart aller Pods im Cluster.

Im Folgenden wird die vollständige Abfolge der Schritte im Detail dargestellt.

1. Installieren Sie den etcd-Client für das Dumpen von Daten:

apt install etcd-client

2. Kompilieren Sie etcdhelper:

Installieren Sie 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

Speichern Sie sich etcdhelper.go, laden Sie die Abhängigkeiten herunter und kompilieren Sie:

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. Machen Sie ein Backup von 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. Ändern Sie das Dienst-Subnetz in den Manifesten des Kubernetes-Controlplanes. In den Dateien /etc/kubernetes/manifests/kube-apiserver.yaml und /etc/kubernetes/manifests/kube-controller-manager.yaml ändern Sie den Parameter --service-cluster-ip-range in das neue Subnetz: 172.24.0.0/16 statt 192.168.0.0/16.

5. Da wir das Dienst-Subnetz ändern, für das kubeadm Zertifikate für den API-Server (unter anderem) ausstellt, müssen diese neu ausgestellt werden:

Sehen wir uns an, für welche Domains und IP-Adressen das aktuelle Zertifikat ausgestellt wurde:

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

Bereiten wir eine minimale Konfiguration für kubeadm vor:

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-Adresse des Master-Knotens

Löschen Sie die alten crt und key, da ohne dies das neue Zertifikat nicht ausgestellt werden kann:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```

Stellen Sie die Zertifikate für den API-Server neu aus:

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

Überprüfen wir, ob das Zertifikat für das neue Subnetz ausgestellt wurde:

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-Adresse:172.24.0.1, IP-Adresse:10.0.0.163, IP-Adresse:192.168.199.100

Nach der Neuausstellung des API-Server-Zertifikats starten wir den Container neu:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
Wir regenerieren die Konfiguration für admin.conf:
```
kubeadm alpha certs renew admin.conf
```
Wir bearbeiten die Daten in 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 
```
Achtung! In diesem Moment funktioniert die Namensauflösung im Cluster nicht mehr, da in den bereits vorhandenen Pods die alte Adresse von CoreDNS (kube-dns) hinterlegt ist und kube-proxy die iptables-Regeln von der alten Subnetz auf das neue geändert hat. Im weiteren Verlauf des Artikels wird erläutert, wie man die Ausfallzeiten minimieren kann. /etc/resolv.conf Die alte CoreDNS-Adresse (kube-dns) ist konfiguriert, und kube-proxy hat die iptables-Regeln von dem alten Subnetz auf das neue geändert. Im Folgenden werden mögliche Optionen beschrieben, um Ausfallzeiten zu minimieren.
Wir korrigieren die ConfigMaps im Namespace kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
— hier ersetzen wir clusterDNS durch die neue IP-Adresse des kube-dns-Services: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
— wir korrigieren data.ClusterConfiguration.networking.serviceSubnet in das neue Subnetz.
Da sich die Adresse von kube-dns geändert hat, muss die Konfiguration von kubelet auf allen Knoten aktualisiert werden:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```

Es bleibt, alle Pods im Cluster neu zu starten:

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

Minimierung der Ausfallzeit

Überlege, wie du den Downtime minimieren kannst:

Nach Änderungen der Manifeste des Steuerungsplans, erstelle einen neuen Dienst kube-dns, zum Beispiel mit dem Namen kube-dns-tmp und einer neuen Adresse 172.24.0.10.
Erstelle wenn in etcdhelper, der den Dienst kube-dns nicht modifizieren wird.
Ersetze in allen Kubelets die Adresse ClusterDNS durch die neue, während der alte Dienst weiterhin gleichzeitig mit dem neuen läuft.
Warte, bis die Pods mit den Anwendungen entweder von selbst aus natürlichen Gründen oder zu einem vereinbarten Zeitpunkt umgeschaltet werden.
Lösche den Dienst kube-dns-tmp und ändere serviceSubnetCIDR für den Dienst kube-dns.

Dieser Plan ermöglicht es, die Ausfallzeit auf etwa eine Minute zu minimieren – während der Löschung des Dienstes kube-dns-tmp und der Änderung des Subnetzes für den Dienst kube-dns.

Modifikation des podNetwork

Gleichzeitig haben wir entschieden, zu zeigen, wie man das podNetwork mit dem resultierenden etcdhelper modifizieren kann. Der Ablauf sieht wie folgt aus:

wir korrigieren die Konfigurationen in kube-system;
wir korrigieren das Manifest des kube-controller-managers;
wir ändern podCIDR direkt in etcd;
wir starten alle Knoten im Cluster neu.

Jetzt im Detail zu diesen Aktionen:

1. Modifizieren Sie die ConfigMaps im Namespace kube-system:

kubectl -n kube-system edit cm kubeadm-config

— wir beheben data.ClusterConfiguration.networking.podSubnet auf das neue Subnetz 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

— wir beheben data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Ändern Sie das Manifest des Controller-Managers:

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

— wir beheben --cluster-cidr=10.55.0.0/16.

3. Überprüfen Sie die aktuellen Werte .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses für alle Knoten im Cluster:

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. Wir ersetzen podCIDR, indem wir Änderungen direkt in etcd vornehmen:

./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. Überprüfen wir, ob podCIDR tatsächlich geändert wurde:

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. Lassen Sie nacheinander alle Knoten des Clusters neu starten.

7. Wenn bei mindestens einem Knoten der alte podCIDR, kann kube-controller-manager nicht gestartet werden, und die Pods im Cluster werden nicht geplant.

In der Tat kann die Änderung des podCIDR auch einfacher durchgeführt werden (zum Beispiel, so). Aber wir wollten lernen, direkt mit etcd zu arbeiten, denn es gibt Fälle, in denen das Bearbeiten von Kubernetes-Objekten in etcd — die einzige Möglichkeit ist. (Zum Beispiel kann man das Feld spec.clusterIP.)

Zusammenfassung

bei einem Service nicht einfach ohne Stillstand ändern. Der Artikel behandelt die Möglichkeit, direkt mit Daten in etcd zu arbeiten, das heißt, den Kubernetes API zu umgehen. Manchmal ermöglicht dieser Ansatz, "clevere Tricks" zu machen. Die im Text aufgeführten Operationen haben wir in realen K8s-Clustern getestet. Ihr Status in Bezug auf die breite Anwendbarkeit ist jedoch — PoC (Proof of Concept). Daher, wenn Sie eine modifizierte Version des Dienstprogramms etcdhelper in Ihren Clustern verwenden möchten, tun Sie dies auf eigene Gefahr.