Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Atlanta Meetup on Service Mesh Interface
Similar to Atlanta Meetup on Service Mesh Interface (20)
Recently uploaded
Recently uploaded (20)
Atlanta Meetup on Service Mesh Interface
- 1. Service Mesh Interface Atlanta Meetup
- 2. Barry Williams ● 17+ years in Software Engineering - DevOps focus ● Started off using Cloud Foundry ● Responsible for automated deployment of ELK stack on Kubernetes at AT&T ● Father of four girls ● Enjoy electronic music, smoked BBQ, and homemade rockets altoros.com altoros.com/blog twitter.com/altoros
- 3. SERVICE MESH INTERFACE What is a service mesh? What is the Service Mesh Interface? SMI Spec Current Implementations
- 4. SERVICE MESH
- 5. SERVICE MESH “Keep your endpoints smart and your pipes dumb” Becomes “Keep your endpoints simple and your pipes smart”
- 6. SERVICE MESH Service Discovery Routing and Traffic Configuration Encryption and Authentication/Authorization Metrics and Monitoring Source: Wikipedia
- 9. SERVICE MESH INTERFACE Project from Deislabs at Microsoft Initial Commit March 2019
- 10. SERVICE MESH INTERFACE Traffic Access Control Traffic Specs Traffic Split Traffic Metrics
- 11. SERVICE MESH INTERFACE Flagger Kiali Kubecost
- 12. SERVICE MESH INTERFACE How to integrate? - Implement SMI directly - Implement an Adapter
- 13. SMI SPEC
- 15. SMI SPEC - TRAFFIC ACCESS CONTROL Backend Frontend
- 16. SMI SPEC - TRAFFIC ACCESS CONTROL Frontend Backend /metrics TrafficTarget Source Spec (HTTPRouteGroup) Destination
- 17. TRAFFIC TARGET --- kind: TrafficTarget apiVersion: access.smi-spec.io/v1alpha1 metadata: name: backend-spec namespace: default sources: - kind: ServiceAccount name: frontend-sa namespace: default specs: - kind: HTTPRouteGroup name: backend-routes matches: - metrics destination: kind: ServiceAccount name: backend-sa namespace: default port: 8080
- 18. TRAFFIC SPEC
- 19. SMI SPEC - TRAFFIC SPEC Name GET PUT POST /metrics Methods PathRegex “metrics”
- 20. HTTP ROUTE GROUP apiVersion: v1beta1 kind: HTTPRouteGroup metadata: name: the-routes matches: - name: metrics pathRegex: "/metrics" methods: - GET - name: everything pathRegex: ".*" methods: ["*"]
- 21. TRAFFIC SPLIT
- 22. SMI SPEC - TRAFFIC SPLIT Frontend Frontend-v1 Frontend-v2 90 10 Root Service Old Service New Service Weights
- 23. TRAFFIC SPLIT apiVersion: split.smi-spec.io/v1alpha1 kind: TrafficSplit metadata: name: frontend-rollout spec: service: frontend backends: - service: frontend-v1 weight: 900m - service: frontend-v2 weight: 100m
- 24. TRAFFIC METRICS
- 25. SMI SPEC - TRAFFIC METRICS Backend Pod Resource Edge To From Frontend Pod
- 26. TRAFFIC METRICS apiVersion: metrics.smi-spec.io/v1alpha1 kind: TrafficMetrics metadata: name: my-metric resource: name: backend-775b9cbd88-ntxsl namespace: default kind: Pod edge: direction: to resource: name: frontend-577db7d977-lsk2q namespace: default kind: Pod timestamp: 2019-06-08T22:25:55Z window: 30s Metrics: ...
- 27. TRAFFIC METRICS metrics: - name: p99_response_latency unit: seconds value: 10m - name: p90_response_latency unit: seconds value: 10m - name: p50_response_latency unit: seconds value: 10m - name: success_count value: 100 - name: failure_count value: 100
- 28. SMI SPEC - TRAFFIC METRICS
- 29. TRAFFIC METRICS LIST apiVersion: metrics.smi-spec.io/v1alpha1 kind: TrafficMetricsList resource: name: backend-775b9cbd88-ntxsl namespace: default kind: Pod selector: matchLabels: app: foo items: ...
- 31. CURRENT IMPLEMENTATIONS ● Traffic Access Control
- 32. CURRENT IMPLEMENTATIONS ● Traffic Metrics ● Traffic Split (Coming Soon)
- 33. CURRENT IMPLEMENTATIONS Adapter ● Operator for Traffic Split
- 34. MY THOUGHTS
- 35. QUESTIONS?
- 36. THANK YOU
Editor's Notes
- 17+ years in Software Engineering - DevOps focus Started off using Cloud Foundry Responsible for automated deployment of ELK stack on Kubernetes at AT&T Created Mel - an online retail platform startup Father of four girls Enjoy electronic music, smoked BBQ, and homemade rockets
- Today I will discuss: What is a service mesh? What is the Service Mesh Interface? SMI Spec Current Implementations
- “Keep your endpoints smart and your pipes dumb” Push to have endpoints do everything keep the communication layer without logic probably a knee-jerk reaction to the Enterprise Service Bus pattern As the number of microservices grow and scale, it becomes difficult to maintain these endpoints. The natural progression is this that this philosophy <click> becomes “Keep your endpoints simple and your pipes smart” endpoints now do not contain so much logic network gains some intelligence.
- Provides: Service Discovery Routing and Traffic Configuration Encryption and Authentication/Authorization Metrics and Monitoring Extremely Scalable as a mesh Communication goes from Source to Destination no middle interpreter Usually a proxy is placed as sidecar to application Application does not know it is part of a mesh No client libraries No special configuration Application calls are handled by the proxy Service Mesh Logic is performed by the proxy
- People like to compare Service Mesh to Enterprise Service Bus. <click> Service Mesh != ESB model Service mesh does not require client library in apps language agnostic does not interpret traffic Basic translation of traffic, if any Applications don’t even know they are on a mesh Similarities to ESB: Service discovery Routing encryption
- Project from Deislabs at Microsoft Initial commit March 2019 A Unifying interface for service meshes users and providers Akin to CNI (container network interface), CSI (container storage interface), but for Service Mesh
- Provides APIs for: Traffic Access Control What apps should talk to other apps Traffic Specs What endpoints are allowed on certain apps Traffic Split Send incoming traffic to two different backends Useful app upgrades with a blue/green/canary deployments Traffic Metrics Observability with: Metrics Telemetry Tracing
- SMI can standardize tooling. Flagger From waveworks Blue/Green/Canary tool Manipulates services and deployments Istio only Kiali Comprehensive set of observability tools Topology, Metrics, Tracing, etc. Istio only Kubecost Calculate total operating costs of Kubernetes Includes network costs I don’t see integration with a service mesh Could definitely benefit from having standardized metrics
- Lets say you are a mesh provider, How can you integrate with SMI? Implement SMI directly. Your code directly implements the interface spec. (linkerd) Create an adapter. The adapter implements the interface, then adapts objects to your implementation (istio)
- As I talk about SMI’s Spec, it will sound like I’m describing a service mesh in-and-of-itself. I am not. The functionality of SMI must be implemented by service mesh components that adhere to SMI
- Traffic Access Control Access Control Policy Only Authorization, not authentication Rules are additive - meanining that zero access is granted by default, and access must be given Authentication must be handled on another layer Currently done with Service Accounts
- Traffic Access Control Consider a normal scenario. A frontend app needs to talk to a backend app. We want to ensure only the frontend app talks to the backend only on specific endpoints
- Traffic Access Control Traffic Target - Sources (Yellow) are allowed to talk to a destination Spec (blue) uses a HTTPRouteGroup to define allowed endpoints (could define TCP as well, depends on protocol) Destinations (green) are also defined
- Note the use of service accounts Allow Frontend-SA in default namespace Endpoints “metrics” defined in “backend-routes” HTTPRouteGroup Destination Backend-SA service account Port 8080
- Traffic Spec Defines endpoints Used with Traffic Access Control Intended to handle many protocols Right now primarily HTTP
- HTTPRouteGroup Has a list of objects name methods path regex Docs say: Can be generated from: OpenAPI (Swagger) Protobuf
- In this example Define a “/metrics” endpoint Associate methods “GET” Give a name of “metrics” - used by the TrafficTarget Also an example for allowing all endpoints
- Traffic Split Allow traffic to span multiple destinations Weight based Useful to coordinate blue/green/canary releases Uses Services
- In this setup perform a blue/green deployment Slowly send a percentage of traffic to a new service Weights are provided 90% traffic on Frontend-v1 10% on Frontend-v2
- Weights are defined in terms of a resource (think CPU resources) 1000m = 1 resource Root Service (in red): The service clients connect to Backends (blue and green) are: Services inside the namespace with their own selectors, endpoints and configuration.
- Traffic Metrics An integration point for tooling Provides instantaneous metrics for: CLI Tools Horizontal Pod Autoscalers Canary Updates Two types of metrcis can be exposed: Metrics for latency, success or failures Topology between services Metrics are patterned after metrics.k8s.io They are exposed through the kubernetes API
- This first method exposes metrics for latency, success and failure between specified pods. In this example: Metrics are gathered between a resource and edge Traffic can be monitored in both directions In our example, we are monitoring traffic between a specific Backend Pod and a specific Frontend Pod However, Resources can be: Pods Namespaces Deployments Services And more
- In this example, we define a resource (green) (being a specific pod) We then define an edge (yellow) which contains a direction and a resource We also define what metrics (orange) to gather, that will be on the next slide
- Here we are gathering various latency percentiles Count of Successes Count of Failures
- In our second example, you can get the topology of pods The list is a directed graph of traffic This list can be queried for: all pods generally pods in a namespace traffic to a specific pod
- This example gets a list of connections to and from our backend Our search is narrow because we specified Namespace Selector pod name We can widen our search by removing these elements We can open search up to just specifying that the kind is pod.
- Hashicorp Consul implements Traffic Access Control “At Launch” “Consul-smi-controller” will support it Requires Consul 1.5 or higher More to come soon
- Linkerd 2.3 already implements SMI Traffic Metrics specs. Working on Traffic Split for 2.4 More to come soon
- Adapter will perform Traffic Splitting Seems early alpha No official container for the adapter, and build is difficult
- SMI seems to be a lowest-common-denominator spec. As such, it does not fully replace the experience of using a specific mesh directly. You may still need to directly call your service mesh if you need a particular feature not in SMI Unifying tooling sounds mega awesome! A great start! I hope the spec tries to expand, such as traffic splitting on headers