© Liashko/Shutterstock.com
Entwickler Magazin
Das Service Mesh im Griff

Best Practices für Istio

von Michael Hofmann

Michael Hofmann


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.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.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 und Fault Injection...

Entwickler Magazin
Das Service Mesh im Griff

Best Practices für Istio

von Michael Hofmann

Michael Hofmann


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.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.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 und Fault Injection...

Neugierig geworden?


   
Loading...

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