© Liashko/Shutterstock.com
Das Service Mesh im Griff

Best Practices für Istio


von Michael Hofmann

Infografik_1.jpg_fmt1.png

Nutze die automatische Sidecar Injection

Eins der grundlegenden Elemente deines Service-Mesh-Tools ist die Nutzung eines Sidecars. Die gesamte Kommunikation zu und von der Anwendung durchläuft diesen Proxy. Daher ist es von essenzieller Wichtigkeit, dass das Sidecar mit dem Anwendungscontainer im gleichen Kubernetes Pod deployt wird.

Die automatische Sidecar Injection macht das möglich. Ist sie aktiviert, injiziert Istio ein Sidecar neben jedem Anwendungscontainer, ohne dass man selbst Hand anlegen muss – das ist der beste Weg dafür. Durch die automatische Sidecar Injection wird sichergestellt, dass alle Pods Teil des Service Mesh und alle Metriken verfügbar sind.

In manchen Situationen (etwa beim Debuggen von Problemen im Service Mesh) mag es sein, dass man das Deployment von Sidecars ändern muss, um mehr Metriken zu erhalten, deren Sammlung im Proxy standardmäßig deaktiviert ist. In den Deployment-Einstellungen kann man einfach von der automatischen auf die manuelle Sidecar Injection umsteigen. Aber das sollte eine Ausnahme von dieser Best Practice sein.

Infografik_2.jpg_fmt1.png

Verwalte dein Service Mesh mit einem umfassenden Regelwerk

Dein Service Mesh ohne Istios Traffic-Rules zu betreiben, ist zwar möglich, aber damit richtest du eine Mesh-Kommunikation ein, die unverwaltet und daher schwierig zu handhaben ist. Wenn du für jede Anwendung im Mesh ein paar Istio-Regeln aktivierst, wird das Leben sehr viel leichter. In den Cluster eingehende Kommunikation sollte nicht nur durch einen Load Balancer verteilt werden. Zusätzlich zu dieser Infrastrukturkomponente sollte die Kommunikation auch durch ein Ingress-Gateway gesteuert werden. Ein Istio-Gateway kann dann anfangen, deine Kommunikation zu überwachen und Route-Regeln aktivieren, die auf den Traffic angewendet werden, der in den Cluster eingeht.

Die gleichen Argumente gelten auch dann, wenn ein Istio-Egress-Gateway auf sämtliche Kommunikation angewendet wird, die das Service Mesh verlässt. Jede Kommunikation mit einem Service innerhalb deines Mesh sollte mit Hilfe eines Istio Virtual Service und einer Destination Rule definiert werden. Eine Destination Rule kann Subsets von Routingdestinationen definieren, die auf verschiedenen innerhalb des Mesh koexistierenden Versionen eines Service basieren. Diese Subsets können in der Virtual-Service-Regel referenziert werden. Eine Virtual-Service-Regel kann zusätzliche Features wie headerbasiertes Routing, URL Rewriting, A/B Testing, Canary Rollout, Resilience ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang