Introduction to service mesh with Istio and Kiali Riga dev days

Slide 1

Slide 1 text

Introduction to service mesh with Istio and Kiali Alissa Bonas mikeyteva

Slide 2

Slide 2 text

Evolution of application architecture How did we get to service mesh?

Slide 3

Slide 3 text

Monolith application Single unit of executable = Application = Single process

Slide 4

Slide 4 text

Application modules Application Handle HTTP requests Data processing UI Alerts

Slide 5

Slide 5 text

Multiple processes Application UI Data processing Alerts Handle HTTP requests

Slide 6

Slide 6 text

Microservices Language agnostic Scaled separately Upgraded separately

Slide 7

Slide 7 text

A shift in Application Packaging and Runtime

Slide 8

Slide 8 text

Containerizing an app

Slide 9

Slide 9 text

Run multiple containers

Slide 10

Slide 10 text

● Run many containers on multiple hosts ● Scale - manage several instances (replicas) of the same container ● Manage a container based environment Orchestrate containers

Slide 11

Slide 11 text

Container orchestration platforms Kubernetes Κυβερνήτης OKD (Openshift)

Slide 12

Slide 12 text

Kubernetes building blocks (some…) ● Pod - a group of one or more containers, with shared storage/network ● Deployment - manages pod deﬁnition and deﬁnes replicas of pods ● Service - an abstraction, an access point to a set of Pods ○ Sometimes called a microservice

Slide 13

Slide 13 text

Replica 3 Microservices - the Kubernetes way Service A Service B Replica 2 Pod Pod Replica 1 Access point = microservice Code Container Container

Slide 14

Slide 14 text

High Complexity

Slide 15

Slide 15 text

Multiple points of failure !!! ? ?

Slide 16

Slide 16 text

Challenges ● How are the requests routed between services? ● How do I detect failures and downtime? ● How to upgrade and test new versions of a service? ● Securing the communication

Slide 17

Slide 17 text

Service mesh to the rescue

Slide 18

Slide 18 text

What is a service mesh ● Infrastructure/framework that handles communication between services ● Often implemented as network proxies deployed alongside the microservices

Slide 19

Slide 19 text

Istio - Ιστίο Open source service mesh

Slide 20

Slide 20 text

The dry facts ● Started in May 2017 ● Means “sail” in Greek ● Developed in Go

Slide 21

Slide 21 text

Istio features ● Load balancing (HTTP, gRPC, TCP...) ● Trafﬁc control (routing rules, retries, timeouts, fault injection, mirroring) ● Secure service-to-service communication ● Access controls (authorization) ● Metrics and traces for trafﬁc

Slide 22

Slide 22 text

Important Terminology ● Workload - anything owning/controlling pods (like a Deployment) or the pods themselves ● Service - a microservice ● Application - label “app” on a pod/service ● Version - label “version” on a pod/service

Slide 23

Slide 23 text

Before Istio POD A Container Routing code Circuit breaker code Business logic code POD B Container2 Routing code2 Circuit breaker code2 Business logic code2

Slide 24

Slide 24 text

Istio POD A Container Routing code Circuit breaker code Business logic code POD B Container2 Routing code2 Circuit breaker code2 Business logic code2

Slide 25

Slide 25 text

Sidecar Proxy ● A proxy is deployed in a container next to each instance of microservice (inside a pod) ● Container name: istio-proxy ● It is transparent to application code ● Envoy open source proxy is currently used

Slide 26

Slide 26 text

How is the sidecar injected? ● Manually ● Automatically injected to pod on creation ○ kubectl label namespace default istio-injection=enabled ○ Mutating Admission Webhook is used for sidecar injection ○ Actually… 2 containers are injected: istio-init and istio-proxy

Slide 27

Slide 27 text

Istio architecture

Slide 28

Slide 28 text

Sidecar Proxy in Istio and Kubernetes POD Container Business logic code POD Container Business logic code Sidecar container Before Istio, no sidecar With sidecar Routing code Circuit breaker code

Slide 29

Slide 29 text

With Istio - sidecar intercepts all traffic Envoy sidecar container POD A Sidecar container Container Business logic code HTTP, TCP, TLS... HTTP, TCP, TLS... Envoy sidecar container POD C Sidecar container Container Business logic code Sidecar container Container Business logic code Envoy sidecar container POD B Sidecar container Container Business logic code Conﬁguration is transparent to the services and not part of the code

Slide 30

Slide 30 text

Istio routing in Kubernetes Service A Service B Pod Replica 2 Pod Pod Replica 1 Container Container Sidecar container Container Sidecar container Sidecar container Communication is “Envoy to Envoy” bypassing the Kubernetes Service

Slide 31

Slide 31 text

Different routing scenarios ● A/B testing ● Traffic shifting ○ Canary deployment (an example of traffic shifting) ● Mirroring traffic

Slide 32

Slide 32 text

Weighted Routing with Istio - A/B Service A Service B Replica 2 Pod Version 2 Pod Pod Version 1 Replica 1 50% traffic 50% traffic Proportion of trafﬁc routed to a version is independent of number of instances of that version

Slide 33

Slide 33 text

Weighted Routing - Canary Service A Service B Replica 2 Pod Pod Version 2 Pod Version 1 Replica 1 90% traffic 10% traffic Proportion of trafﬁc routed to a version is independent of number of instances of that version

Slide 34

Slide 34 text

Matching Routing with Istio Service A Service B Pod Version 1 Pod Pod Version 2 User Alissa All other users

Slide 35

Slide 35 text

Mirroring traffic Service A Service B Pod Version 1 Pod Pod Version 2 Copy of traffic Response disregarded Real traffic

Slide 36

Slide 36 text

"Anything that can go wrong will go wrong" (Murphy’s law)

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

Chaos engineering with Istio ● Inject delays ○ Simulate network latency ○ Simulate an overloaded service ● Deﬁne aborts (Inject Errors) ○ Simulate failure in a service (return a predeﬁned HTTP Error) ○ A good alternative for a manual shutdown or “scale to zero”

Slide 39

Slide 39 text

Inject delay Service A Service B Instance 2 Pod Pod Version 2 Pod Version 1 Instance 1 Add 7 seconds delay to response

Slide 40

Slide 40 text

Inject Error Service A Service B Instance 2 Pod Pod Version 2 Pod Version 1 Instance 1 Return Error 500 for user Alissa Work as usual for all the users

Slide 41

Slide 41 text

Circuit breaker ● Set a connection pool to limit connections and requests ● Example: “Set a connection pool of 100 connections with no more than 10 req/connection to service A”

Slide 42

Slide 42 text

Outlier detection ● Classify instances as healthy/unhealthy ● Eject unhealthy instances for a deﬁned timeframe which can be increased over time ● Example: “Scan all pods every 5 mins, any instance that fails 7 consecutive times with 5XX error code will be ejected for 15 minutes.”

Slide 43

Slide 43 text

Authorization and Authentication ● Authentication ● Authorization ○ Can service send to service ? ○ Roles are visible across namespaces ○ ServiceRole and ServiceRoleBinding ● Citadel monitors service accounts being created and creates a certiﬁcate for them ● Certiﬁcates only in memory, sent to Envoy via SDS API

Slide 44

Slide 44 text

Security ● Defining a Gateway ingress/egress to enable traffic in/out of mesh ● mTLS can be defined on multiple levels ○ Client and server exchange certificates, 2 way ○ All mesh, specific service, etc.

Slide 45

Slide 45 text

Conﬁguration objects • VirtualService != Kubernetes service • Rules for how requests to a service are routed within service mesh • Routing logic, load weighting, chaos injection • DestinationRule • Conﬁgures policies to be applied to a request after VirtualService routing has occurred • Load balancer, circuit breaker • MeshPolicy, Gateway, ServiceEntry and more...

Slide 46

Slide 46 text

Conﬁguration Yaml example All Istio objects are CRD (CustomResource Deﬁnition)

Slide 47

Slide 47 text

New set of challenges ● How many versions exist for service A? ● Is there any traffic now? ● Is routing configured for service B? ● Is my configuration even valid? ● Is security on? ● Is the app healthy?

Slide 48

Slide 48 text

Kiali - Κιάλι Open source Istio service mesh observability

Slide 49

Slide 49 text

Dry facts ● Started in January 2018 ● Means “spyglass” or “monocular” in Greek ● Developed in Go and React

Slide 50

Slide 50 text

Kiali Features ● Visualize mesh connections and traffic ● Service and application health ● Configure routing via UI ● Validate Istio configurations ● View metrics, traces and logs ● Visualize security configuration

Slide 51

Slide 51 text

A picture is worth a thousand yamls

Slide 52

Slide 52 text

Demos based on Bookinfo example

Slide 53

Slide 53 text

Let’s see Kiali in action ● Mesh visualization ● Fault Injection ● Configuration Validation ● Configure routing rules ● Tracing ● Traffic stats

Slide 54

Slide 54 text

Bookinfo example

Slide 55

Slide 55 text

Bookinfo on Kiali

Slide 56

Slide 56 text

Kiali Features

Slide 57

Slide 57 text

Overview page

Slide 58

Slide 58 text

Mesh Topology Graph

Slide 59

Slide 59 text

Hide and Seek

Slide 60

Slide 60 text

Details Page

Slide 61

Slide 61 text

Viewing Logs

Slide 62

Slide 62 text

Runtime metric dashboards

Slide 63

Slide 63 text

Weighted Routing

Slide 64

Slide 64 text

Conﬁguration validations

Slide 65

Slide 65 text

Tracing (integration with Jaeger)

Slide 66

Slide 66 text

Visualizing security

Slide 67

Slide 67 text

Connect with the community Kiali.io Istio.io KialiProject IstioMesh github.com/kiali github.com/istio

Slide 68

Slide 68 text

Icon credits ● Twitter by Lubos Volkov, the Noun Project ● Light Bulb by artworkbean, the Noun Project ● Magnifying Glass by Musket from the Noun Project ● Questions by Rediffusion from the Noun Project ● Mug by Alex Getty from the Noun Project ● Diamond by MarkieAnn Packer from the Noun Project ● Box by Cornelius Danger from the Noun Project

Slide 69

Slide 69 text

Thank you! mikeyteva