Einführung
Der Hauptzweck des statischen Routenoperators besteht darin, mehr Flexibilität und Kontrolle über den Netzwerkverkehr in Ihrer Kubernetes-Umgebung zu ermöglichen. Er erlaubt Ihnen, die Routing-Konfiguration präzise an die Anwendungsanforderungen anzupassen und die Netzwerkleistung zu optimieren. Er wird als DaemonSet bereitgestellt und läuft daher auf jedem Knoten Ihres von DigitalOcean verwalteten Kubernetes-Clusters.
In diesem Tutorial lernen Sie, die Routingtabelle jedes Worker-Knotens anhand der CRD-Spezifikation zu verwalten und ein Failover-Gateway einzurichten.
Das Hauptziel dieses Tutorials ist es, zu zeigen, wie man die Routingtabelle jedes Worker-Knotens auf Basis der CRD-Spezifikation verwaltet und ein Failover-Gateway einrichtet.
Voraussetzungen
- Ein von DigitalOcean verwalteter Kubernetes-Cluster, auf den Sie Zugriff haben.
- Die Kubectl-CLI ist auf Ihrem lokalen Rechner installiert (und so konfiguriert, dass sie auf Ihren von DigitalOcean verwalteten Kubernetes-Cluster verweist).
- NAT GW Droplets (2 oder höher) werden wie hier beschrieben konfiguriert und implementiert.
- Entwickeln Sie ein System zur Fehlererkennung im Gateway-Droplet, das auf die Bedürfnisse des Nutzers zugeschnitten ist und eine klare und präzise Erkennung mit minimalen Fehlalarmen gewährleistet. Nutzen Sie Überwachungsdienste wie Prometheus oder Nagios, richten Sie Health-Check-Endpunkte im Droplet ein oder verwenden Sie Benachrichtigungstools wie Alertmanager. Hierfür können Sie einen Überwachungs-Stack aus unserem Marketplace verwenden.
Nachfolgend das Architekturdiagramm:
Bereitstellung des Kubernetes-Operators für statische Routen
Stellen Sie die neueste Version des Operators für statische Routen in Ihrem von DigitalOcean verwalteten Kubernetes-Cluster mithilfe von kubectl bereit:
kubectl apply -f https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml
Prüfen Sie, ob die Operator-Pods betriebsbereit sind:
Lassen Sie uns überprüfen, ob die Operator-Pods betriebsbereit sind.
“bash kubectl get staticroutes -o wide -n staticroutes
The output looks similar to the below:
```bash
[secondary_label Output]
NAME AGE DESTINATIONS GATEWAY
static-route-ifconfig.me 119s ["XX.XX.XX.XX"] XX.XX.XX.XX
static-route-ipinfo.io 111s ["XX.XX.XX.XX"] XX.XX.XX.XXNun überprüfen wir die Berichte der Bediener; es sollten keine Ausnahmen gemeldet werden:
kubectl logs -f ds/k8s-staticroute-operator -n static-routes
Sie sollten folgende Ausgabe beobachten:
Output
Found 2 pods, using pod/k8s-staticroute-operator-498vv
[2023-05-15 14:12:32,282] kopf._core.reactor.r [DEBUG ] Starting Kopf 1.35.6.
[2023-05-15 14:12:32,282] kopf._core.engines.a [INFO ] Initial authentication has been initiated.
[2023-05-15 14:12:32,283] kopf.activities.auth [DEBUG ] Activity 'login_via_pykube' is invoked.
[2023-05-15 14:12:32,285] kopf.activities.auth [DEBUG ] Pykube is configured in cluster with service account.
[2023-05-15 14:12:32,286] kopf.activities.auth [INFO ] Activity 'login_via_pykube' succeeded.
[2023-05-15 14:12:32,286] kopf.activities.auth [DEBUG ] Activity 'login_via_client' is invoked.
[2023-05-15 14:12:32,287] kopf.activities.auth [DEBUG ] Client is configured in cluster with service account.
[2023-05-15 14:12:32,288] kopf.activities.auth [INFO ] Activity 'login_via_client' succeeded.
[2023-05-15 14:12:32,288] kopf._core.engines.a [INFO ] Initial authentication has finished.
[2023-05-15 14:12:32,328] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for customresourcedefinitions.v1.apiextensions.k8s.io cluster-wide.
[2023-05-15 14:12:32,330] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for staticroutes.v1.networking.digitalocean.com cluster-wide.Um die Auswirkungen eines Gateway-Ausfalls zu minimieren, wird empfohlen, ein Standby-Gateway bereitzuhalten, das bei Bedarf einspringen kann. Obwohl der Betreiber derzeit keine echte Hochverfügbarkeit (HA) unterstützt, trägt ein Failover dazu bei, die Dauer der Dienstunterbrechung zu minimieren.
Angenommen, Sie haben eine festgelegte Ziel-IP-Adresse, 34.160.111.145, die das aktive oder primäre Gateway darstellt, mit der IP-Adresse 10.116.0.4, die für die Weiterleitung des Datenverkehrs zuständig ist. Diese Konfiguration ist in der Datei primar.yaml gespeichert.
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: primary
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.4"Zusätzlich steht Ihnen ein Standby- oder Sekundärgateway mit der IP-Adresse 10.116.0.12 zur Verfügung, das bereit ist, Datenverkehr von derselben Ziel-IP-Adresse zu verarbeiten. Die Definition der statischen Route in der Datei secondary.yaml ist bis auf die Gateway-IP-Adresse (und den Objektnamen) identisch mit der primären Definition. Diese wird in der Datei secondary.yaml gespeichert.
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: secondary
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.12"Der eigentliche Ausfallprozess umfasst dann die folgenden Schritte:
- Erkennen, dass das aktive Gateway mit der IP-Adresse 10.116.0.5 ausgefallen ist.
- Löschen Sie die aktuell aktive StaticRoute.
- Wenden Sie die vorgefertigte StaticRoute an.
Aktive statische Route löschen
Löschen wir nun die aktuell aktive StaticRoute.
kubectl delete -f primary.yaml
Warten Sie 30–60 Sekunden, damit jede Operatorinstanz genügend Zeit hat, die Objektlöschung zu verarbeiten. Das heißt, reagieren Sie, indem Sie den Pfad von allen Knoten löschen.
Standby-Statikroute anwenden
Aktivieren wir die sekundäre StaticRoute.
kubectl apply -f secondary.yaml
Der Operator muss die neue Standby-StaticRoute auswählen und die entsprechenden Routingtabelleneinträge einfügen. Danach ist das Failover abgeschlossen.
Setup-Test
Jede CRD-Instanz erstellt eine statische Route zu zwei Websites, die Ihre öffentliche IP-Adresse melden – ifconfig.me/ip und ipinfo.io/ip. Eine typische Definition einer statischen Route sieht folgendermaßen aus:
apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: static-route-ifconfig.me
spec:
destinations:
- "34.160.111.145"
gateway: "10.116.0.5"Um die Einstellungen zu testen, laden Sie ein Beispielmanifest vom Beispielverzeichnis herunter:
Beispiel für ifconfig.me und ipinfo.io-
curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ifconfig.me.yaml
curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ipinfo.io.yaml
Nach dem Herunterladen der Manifeste ersetzen Sie jede Manifestdatei durch <>. Wenden Sie anschließend jedes Manifest mit kubectl an:
kubectl apply -f static-route-ifconfig.me.yaml
kubectl apply -f static-route-ipinfo.io.yaml
Prüfen Sie abschließend, ob der curl-test-Pod für jede Route auf die öffentliche IP-Adresse Ihres NAT-Gateways antwortet:
kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ipSie sollten denselben Test auch während des Failover-Tests verwenden. Beim Failover des primären Gateway-Droplets sollte das Ergebnis dem NAT-Gateway die öffentliche IP-Adresse des primären Droplets liefern, und beim Failover des sekundären Droplets sollte das Ergebnis die öffentliche IP-Adresse des NAT-Gateways des sekundären Droplets liefern.
Fehlerbehebung
Sie sollten das StaticRoute-Objekt überprüfen: Wenn ein Fehler auftritt, suchen Sie zuerst im Ereignis der statischen Route nach dem Fehler für jeden Knoten, auf den die Regel zutrifft.
kubectl get StaticRoute <static-route-name> -o yaml
Protokolle prüfen: Um der Sache genauer auf den Grund zu gehen, können Sie die Protokolle des statischen Routenbetreibers auf Fehler überprüfen.
kubectl logs -f ds/k8s-staticroute-operator -n static-routes
Löschen
Um den Operator und die zugehörigen Ressourcen zu entfernen, führen Sie bitte den folgenden kubectl-Befehl aus (stellen Sie sicher, dass Sie dieselbe Release-Version verwenden, die Sie während der Installation verwendet haben):
kubectl delete -f deploy https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml
Ausgabe ähnlich wie:
customresourcedefinition.apiextensions.k8s.io "staticroutes.networking.digitalocean.com" deleted
serviceaccount "k8s-staticroute-operator" deleted
clusterrole.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
clusterrolebinding.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
daemonset.apps "k8s-staticroute-operator" deletedWenn Sie nun denselben curl-Befehl ausführen, erhalten Sie die IP-Adresse des Worker-Knotens als Ausgabe:
kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ip
Überprüfen Sie nun die öffentliche IP-Adresse des Worker-Knotens:
kubectl get nodes -o wide
Ergebnis
Die Implementierung von Failover-Funktionen ist auch dann empfehlenswert, wenn eine echte Hochverfügbarkeit (HA) nicht vollständig unterstützt wird, um die Auswirkungen von Gateway-Ausfällen zu minimieren.
Organisationen können die Dauer von Serviceunterbrechungen erheblich reduzieren, indem sie ein Standby-Gateway bereithalten, das bei Bedarf als Failover-Gateway einspringt.
Es ist wichtig, ein Backup-Gateway bereitzuhalten und einen reibungslosen Übergang im Fehlerfall zu gewährleisten. Die Umsetzung kann je nach spezifischen Anforderungen variieren, doch die Priorisierung der Ausfallsicherheit trägt dazu bei, eine zuverlässige und unterbrechungsfreie Dienstbereitstellung aufrechtzuerhalten.
