istioctl ist der schnellste Weg, Istio auf einem Cluster zum Laufen zu bringen, was es zum richtigen Startpunkt zum Lernen des Mesh macht, auch wenn Helm (in der nächsten Anleitung behandelt) die bessere Wahl für eine produktive Installation ist, die du langfristig verwaltest. Diese Anleitung installiert Istio, bestätigt, dass es gesund ist, und schleust einen Sidecar in einen echten Workload ein.

Vor der Installation: Cluster-Ressourcen

Istios Control Plane und Ingress-/Egress-Gateways brauchen echte CPU und echten Speicher, mehr, als ein lokaler Standard-Cluster typischerweise zuteilt. Starte den Cluster speziell auf minikube mit Reserve:

minikube start --cpus=4 --memory=8192

Zu knappe Ressourcen sind eine häufige Ursache für Istio-Pods, die bei einer Erstinstallation in Pending oder CrashLoopBackOff hängen, und es lohnt sich, sie auszuschließen, bevor du etwas anderes untersuchst.

istioctl installieren

Lade das Release für deine Plattform von Istios Releases-Seite herunter oder nutze das Installationsskript:

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version --remote=false

Die Zeile export PATH gilt nur für deine aktuelle Shell-Sitzung; füge sie deinem Shell-Profil (~/.bashrc, ~/.zshrc) hinzu, wenn du istioctl in jedem neuen Terminal verfügbar haben willst, ohne diesen Schritt zu wiederholen.

Istio im Cluster installieren

istioctl install --set profile=demo -y

-y überspringt die Bestätigungsabfrage. Das Profil demo installiert die Control Plane plus Ingress- und Egress-Gateways, mit Ressourceneinstellungen, die leicht genug für einen lokalen Cluster sind; produktive Installationen beginnen typischerweise stattdessen mit dem schlankeren Profil default, das in der Helm-Anleitung behandelt wird. Liste die verfügbaren Profile auf, wenn du sehen willst, was jedes enthält, bevor du wählst:

istioctl profile list

Bestätige die Installation:

kubectl get pods -n istio-system

Du solltest istiod und, mit dem Profil demo, istio-ingressgateway und istio-egressgateway sehen, alle Running.

Bestätigen, dass die Installation von Istio noch nichts verändert hat

Das lohnt sich ausdrücklich zu prüfen, da es beim ersten Mal überrascht: Die Installation von Istio hat keine Wirkung auf bestehende Workloads. Es erscheinen keine Sidecars, nichts daran, wie deine Anwendungen laufen, ändert sich, bis du Injection ausdrücklich aktivierst. Istio ungenutzt im Cluster zu haben kostet dich nur die Ressourcen, die seine eigene Control Plane und seine Gateways verbrauchen.

Sidecar-Injection für einen Namespace aktivieren

kubectl label namespace default istio-injection=enabled
kubectl get namespace default --show-labels

Das betrifft nur Pods, die nach dem Anwenden des Labels erstellt werden. Für Pods, die in diesem Namespace bereits existierten, erstelle sie neu:

kubectl delete pods --all -n default
kubectl rollout restart deployment -n default

(Oder wende die Manifeste, die sie ursprünglich erstellt haben, erneut an; ein einfaches kubectl delete gefolgt von kubectl apply derselben unveränderten Dateien funktioniert identisch; an den Manifesten selbst muss nichts geändert werden, damit Injection greift.)

Bestätigen, dass tatsächlich ein Sidecar gelandet ist

kubectl get pods -n default

Ein Pod mit vorhandenem Sidecar zeigt unter READY 2/2 statt 1/1. Bestätige, was dieser zweite Container tatsächlich ist:

kubectl describe pod <pod-name> -n default

Du solltest einen Init-Container istio-init (der die Traffic-Abfangung konfiguriert) und einen Container istio-proxy neben dem deiner Anwendung sehen, aufgelistet unter Containers in der Ausgabe.

Einen einzelnen Workload manuell injizieren, ohne einen Namespace zu labeln

Manchmal ist nicht das Meshen eines ganzen Namespaces gewollt, sondern nur ein bestimmter Workload. istioctl kube-inject fügt den Sidecar zu einem Manifest hinzu, bevor es angewendet wird, statt sich auf die namespace-weite automatische Injection zu verlassen:

istioctl kube-inject -f my-deployment.yaml | kubectl apply -f -

Das ist das manuelle Äquivalent dessen, was das Namespace-Label automatisch auslöst: eine von istioctl erzeugte und in dein Manifest eingefügte Sidecar-Spec, in einem Schritt angewendet. Nützlich für einen Namespace mit gemischten gemeshten und ungemeshten Workloads, bei dem das Labeln des ganzen Namespaces mehr meshen würde, als du beabsichtigst.

Deinstallieren

istioctl uninstall --purge -y
kubectl delete namespace istio-system

--purge entfernt alles, was die Installation hinzugefügt hat, einschließlich Ressourcen aus anderen Profilen als dem aktuell aktiven, was zählt, wenn du beim Testen Profile gewechselt hast und eine saubere Entfernung statt Überbleibsel einer früheren Installation willst.