Unmeshing the service mesh
Download as PPTX, PDF0 likes298 views
The document discusses Istio, a service mesh platform that uses Envoy sidecar proxies. It describes how Istio implements the service mesh using Envoy sidecars injected into application pods. This provides traffic management, security features like authentication and encryption, and observability tools for microservices. The presentation includes demos of Istio configuration, traffic routing, distributed tracing using Jaeger, and monitoring metrics with Prometheus and Grafana.
![Kiali in Action
kubectl -n istio-system port-
forward $(kubectl -n istio-
system get pod -l app=kiali -o
jsonpath='{.items[0].metadata.
name}') 20001:20001
24](https://image.slidesharecdn.com/unmeshingtheservicemesh-190627044534/85/Unmeshing-the-service-mesh-24-320.jpg)
![Jaeger in Action
kubectl port-forward -n istio-
system $(kubectl get pod -n
istio-system -l app=jaeger -o
jsonpath='{.items[0].metadata.
name}') 16686:16686
26](https://image.slidesharecdn.com/unmeshingtheservicemesh-190627044534/85/Unmeshing-the-service-mesh-26-320.jpg)
![Metrics in Action
View metrics in Prometheus
kubectl -n istio-system port-
forward $(kubectl -n istio-system
get pod -l app=prometheus -o
jsonpath='{.items[0].metadata.nam
e}') 9090:9090
View dashboards in Grafana
kubectl -n istio-system port-
forward $(kubectl -n istio-system
get pod -l app=grafana -o
jsonpath='{.items[0].metadata.nam
e}') 3000:3000
28](https://image.slidesharecdn.com/unmeshingtheservicemesh-190627044534/85/Unmeshing-the-service-mesh-28-320.jpg)
Unmeshing the service mesh
- 1. Unmeshing the Service Mesh (for the absolute beginner) Omer Barel Senior DevOps Consultant omerb@codevalue.net @omerbarel https://about.me/omerbarel http://codevalue.net
- 2. About Me Omer Barel Husband to Naama Father of Leo & Theo Love Whiskey & Travelling (preferably together! ) Kubernetes Advocate @omerbarel 2
- 3. Agenda Istio Envoy Side-car injection process Ingress traffic management Service Mesh visualization Distributed Tracing Monitoring 3
- 4. The problem Networking is hard Microservices networking is even harder Multiple languages and frameworks Multiple protocols Key Concerns Implementation Authentication and Authorization Encryption Observability 4
- 5. Istio 5
- 7. 7 The Control Plane The Data Plane Kubernetes
- 8. 8 The Control Plane The Data Plane Your Application Istio
- 9. The Data Plane • Pronounced Onvoy • Originated @ Lyft, CNCF graduate (11/2018) • The promise: Abstracts network infrastructure logic and concerns from the developer • High performance, edge, middle and service proxy • Sidecar container, inside the service pod • Out-of-process, stand alone distributed proxy • Any application, any language or runtime • APIs for configuration management (via control planes such as Istio) • Rich observability (L7 traffic, distributed tracing, etc.) 9
- 10. net Networking Implementation • Envoy is injected to the pod via K8s mutating webhook admission controller • Both containers in the pod share the same network namespace (iptables, routes, etc.) • Envoy modifies iptables rules to route all traffic destined to the service to route through it • Envoy, in turn, redirects traffic to the service 10 Pod envoy service a 192.168.0.105 eth0 loopback iptables routes sockets
- 11. Pilot 11 • Routing between services • Ingress traffic control • Traffic Shifting (A-B Deployments) • Canary deployments • Circuit breaking
- 12. 12 • Check • ACLs / Authorization - Can service A talk to service B? • Rate limiting • Report telemetry to backend adapters • Metrics (Prometheus) • Logs (Elasticsearch) • Tracing (Jaeger / Zipkin) Mixer
- 13. 13 • Certificate system for Envoy • Mutual-TLS (bi-directional validation) Citadel
- 14. 14 • Handles the configuration of Istio control-plane components: • Validation • Ingestion • Processing • Distribution Galley
- 17. Side Car Injection Process 17
- 18. Deploy Hipster Application Deploy Istio helm install istio-init/ --name istio- init --namespace istio-system helm install istio/ --name istio -- namespace istio-system --values istio/values-istio-demo.yaml Label the namespace kubectl label namespace default istio- injection=enabled Deploy the application kubectl apply -f hipster- app/kubernetes-manifests.yaml 18
- 20. Traffic Management Components CRDs (Custom Resource Definitions) A way to extend Kubernetes with custom configurations kind: Gateway Load balancer to route traffic into the mesh (ingress) or from the mesh (egress) kind: VirtualService Routing rules for a service inside the mesh kind: DestinationRule Policies to apply to the request post-routing kind: ServiceEntry Enable requests to services outside the mesh Kind: Sidecar Envoy sidecar proxy configuration 20
- 21. Traffic Management 21 kind: Gateway kind: VirtualService kind: DestinationRule kind: ServiceEntry
- 22. Ingress Traffic 1. Traffic reaches the gateway 2. Traffic to /frontend redirected to the frontend service kubectl apply -f hipster- app/istio-manifests.yaml 22
- 24. Kiali in Action kubectl -n istio-system port- forward $(kubectl -n istio- system get pod -l app=kiali -o jsonpath='{.items[0].metadata. name}') 20001:20001 24
- 26. Jaeger in Action kubectl port-forward -n istio- system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata. name}') 16686:16686 26
- 27. Monitoring 27
- 28. Metrics in Action View metrics in Prometheus kubectl -n istio-system port- forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.nam e}') 9090:9090 View dashboards in Grafana kubectl -n istio-system port- forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.nam e}') 3000:3000 28
- 29. Try it on your own! https://bit.ly/2HSp1t5 29
- 30. Takeaways Service mesh moves the networking logic to the platform level Istio implements service mesh using envoy side-car proxy container We gain: Granular network & traffic management control Security (Authentication, Authorization & Encryption) Observability into key telemetry data of our microservices How to get started? Find a compelling use case Implement Incrementally Ask for help 30
- 31. Omer Barel Senior DevOps Consultant omerb@codevalue.net @omerbarel https://about.me/omerbarel http://codevalue.net
Editor's Notes
- #5: Multiple languages and frameworks (network library per language) Multiple protocols (HTTP/1, HTTP/2, gRPC, databases, caching, etc.) Implementation (retry, circuit breaking, rate limiting, timeouts, etc.) Observability (tracing, metrics & logging)
- #7: Service Mesh: Network of Microservices Connect – Traffic Management: Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection. Routing, circuit breaking, timeouts and retries. A/B Testing, Canary deployments & staged rollouts (percentage-based) Secure: Secure service-to-service communication in a cluster with strong identity-based authentication and authorization. Service to service mTLS encryption Control: A pluggable policy layer and configuration API supporting access controls, rate limits and quotas. Observe: Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress. Tracing (Jaeger), monitoring (Prometheus) and logging (Elasticsearch)
- #10: Envoy modifies the routing table of the service to only talk to local host and all the traffic is between Envoy side cars Features: Modern C++ Filters and extensions in L3 / L4 and L7 Built in service discovery and health checking (active and passive)
- #11: Admission controller: a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized Mutating: modify the object
- #12: Circuit breaking – Envoy reads the response to the http and can tell if it’s a good / bad response and stop sending traffic based on the response (passive health check)
- #13: The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. The sidecar has local caching such that a large percentage of precondition checks can be performed from cache. Additionally, the sidecar buffers outgoing telemetry such that it only calls Mixer infrequently. Rate limit – did service A maxed its rate to talk to service B (more than 1000 requests per minutes, for example)
- #19: Using 2 admission webhooks: Mutating Validating kubectl api-versions | grep admissionregistration Init Container Sidecar container When Kubernetes invokes the webhook, the admissionregistration.k8s.io/v1beta1#MutatingWebhookConfiguration configuration is applied. The default configuration injects the sidecar into pods in any namespace with the istio-injection=enabled label. The istio-sidecar-injector configuration map specifies the configuration for the injected sidecar The istio-init container sets up the pod network traffic redirection to/from the Istio sidecar proxy
- #21: Notice that a VirtualService is tied to a specific Gateway and it defines a host that refers to the Kubernetes Service. (https://medium. /google-cloud/istio-routing-basics-14feab3c040e) A DestinationRule essentially maps labels to Istio subsets.
- #25: The App graph type aggregates all versions of an app into a single graph node. The following example shows a single reviews node representing the three versions of the reviews app The Versioned App graph type shows a node for each version of an app, but all versions of a particular app are grouped together. The following example shows the reviews group box that contains the three nodes that represents the three versions of the reviews app. The Workload graph type shows a node for each workload in your service mesh. This graph type does not require you to use the app and versionlabels so if you opt to not use those labels on your components, this is the graph type you will use. The Service graph type shows a node for each service in your mesh but excludes all apps and workloads from the graph.
- #27: https://istio.io/docs/tasks/telemetry/distributed-tracing/overview/ application needs to collect and propagate the following headers from the incoming request to any outgoing requests: x-request-id, x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, x-b3-flags, x-ot-span-context
- #31: Observability: metrics, tracing, logging Control: routing rules, traffic management, circuit breaking Security: mtls