Seite 2: Wie lassen sich Dienste in Istio aufnehmen?

Inhaltsverzeichnis

Wie kann man nun einen Dienst in Istio aufnehmen? Wie bereits beschrieben, läuft Envoy in einem separaten Container im Pod. Damit muss also der Pod mit dem Proxy angereichert werden. Das kann auf zwei Arten geschehen.

Der Deployment-Deskriptor für den Pod muss die Daten für den Proxy erhalten. Das geht beim Deployen der Anwendung mit dem istioctl-Werkzeug:

----
$ istioctl kube-inject -f original.yaml | kubectl apply -f -  
----

Alternativ ist es denkbar, Kubernetes so zu konfigurieren, dass die Projekte bei Namespaces automatisch ein Proxy erhalten, wenn sie ein bestimmtes Label haben:

----
$ kubectl label namespace myproject istio-injection=enabled
----

Nach dem Deployment sollte kubectl get pods zwei aktive Container im Pod anzeigen.

----
$ kubectl get pods
NAME                                        READY     STATUS 
bob-deployment-b878ff5b5-5js9c              2/2       Running

$ kubectl describe pod bob-deployment-b878ff5b5-5js9c
Name:   bob-deployment-b878ff5b5-5js9c
[...]
Init Containers:
  istio-init:
  [...]
Containers:
  bob:
    [...]
  istio-proxy:
----

Es gibt streng genommen noch einen weiteren Container im Pod, der sofort nach getaner Arbeit wieder terminiert. Mit dem Init-Container lassen sich die die Routing-Regeln im Pod (via iptables) so ändern, dass die Kommunikation über den Proxy geleitet wird. Hierzu benötigt er aktuell (noch) erweiterte Privilegien. Das sorgt in vielen Unternehmen für Stirnrunzeln: Normalerweise versucht man dort, die Privilegien möglichst einzuschränken.

Namen bitte ...

Um die Istio-Welt für Benutzer etwas spannender zu machen, haben die Macher neue Konzepte und Namen eingeführt (das Problem ist wohl eher, dass die Kubernetes-Welt sich bisher noch nicht auf einheitliche Wege geeinigt hat, Labels anzuwenden, um zum Beispiel eine Applikation zu kennzeichnen). Eine "Workload" bezeichnet einen oder mehrere Pods, die alle dieselben Labels haben. Üblicherweise ist das ein Deployment, das skaliert worden sein kann.

"Services" können auf eine oder mehrere Workloads zeigen und sie als Workload(s) für Clients zur Verfügung stellen. "Applikationen" sind Workloads, die dasselbe "app"-Label haben. Sie können durchaus unterschiedliche Versionen haben (beispielsweise für ein A/B-Deployment).