ISTIO Deep Dive
•Als PPTX, PDF herunterladen•
3 gefällt mir•2,609 views
Presentation in IBM Cloud Meet-up of Toronto https://www.meetup.com/IBM-Cloud-Toronto/events/253903913/?_xtd=gatlbWFpbF9jbGlja9oAJGU3NmM3ZjdmLWE2NzgtNGVlNC1iNGZiLTBlZGE5ZWM0NDZjOQ
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie ISTIO Deep Dive
Ähnlich wie ISTIO Deep Dive (20)
Mehr von Yong Feng
Mehr von Yong Feng (10)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
ISTIO Deep Dive
- 1. IBM Cloud / © 2018 IBM Corporation ISTIO A service mesh for microservices at scale Yong Feng – ICP STSM yongfeng@ca.ibm.com
- 2. 1. Microservices Architecture ▸The Problem Space & Challenges 2. ISTIO ▸What Is It? ▸Architecture Overview 3. Demo AGENDA
- 3. An engineering approach focused on decomposing an application into single function modules with well defined interfaces which are independently deployed and operated by a small team who owns the entire lifecycle of the service. UI DB DB DB Micro service Micro service Micro service Micro service Micro service MICROSERVICES ARCHITECTURE
- 4. Improved delivery velocity in exchange for increased operational complexity. Containers and Kubernetes are great enablers to these design goals: clean packaging, rapid deployment, consistency, reliability & scalability This is the reality of microservices implementation at scale. Kubernetes and containers in of themselves does not address these complexity challenges Hailo microservices Cited from https://medium.com/@mattheath/a-long-journey-into- a-microservice-world-a714992d2841 THE TRADE OFF
- 5. • Applications aren’t running in green-field environments • Challenges in the network in between the Services • Network layer is hard to manage • Tooling is nascent MICROSERVICES ARE HARD
- 6. Things to consider • Security • Canary deployments • A/B testing • Circuit breaking • Rate limiting • Fault injection • Tracing • Monitoring • Many more….
- 7. It’s doable, but… It will require a lot of coding
- 8. Service Mesh A dedicated infrastructure layer for managing service- to-service communication to make it manageable, visible and controlled A Control Plane & Network Overlay in between the Services
- 9. Istio A service mesh designed to connect, manage and secure micro services. Using Open Source & Open Standards (Joint project between IBM, Google, Lyft & others) With Zero Application Code Changes
- 10. Traffic management ▸A/B tests, Canary Releases, Red/Black deployments, Circuit Breaker, Fault Injection Observability ▸Dependancies and traffic, Distributed Tracing, Performance metrics Security ▸Enterprise access policy, Security policy, Certification management MAIN FEATURES
- 11. Proxy: Based on Envoy, mediates inbound and outbound traffic for all Istio-managed services. Pilot: Configures Istio deployments and propagate configuration to the other components of the system. Mixer: Responsible for policy decisions and aggregating telemetry data from the other components in the system using a flexible plugin architecture. Citadel: Secures the service-to-service communication and provides a key management system to manage keys and certificates. Data Plane: Composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub. Control Plane: Manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry. ISTIO CONCEPTS
- 12. Cited from https://www.infoq.com/presentations/istio-service-mesh https://github.com/envoyproxy/envoy • L7 proxy and communication bus • Written in C++11 • Pluggable architecture (L3 and L7) • HTTP/1.1, HTTP/2 and gRPC • Health checking • L7 routing • Advanced loadbalancer • Dynamic configuration • Metrics and tracing • Battle tested at Lyft ENVOY SIDE CAR TECHNOLOGY OF CHOICE
- 13. • Ingress • Gateway: configures a load balancer (one or multiple FQDN) for HTTP/TCP traffic at the edge of the mesh • Inside mesh • VirtualService: defines the rules that control how requests for a service (one or multiple FQDN) are routed. • DestinationRule: configures the set of policies (a set of instances) to be applied to a request after VirtualService routing has occurred • Egress • ServiceEntry: commonly used to enable requests to services outside of an Istio service mesh ROUTING CONTROL
- 14. • Maintain platform-agnostic model of services in the mesh • Platform-specific adapter implement platform specific logic • Service discovery • Ingress resource • Rule definition • Push configuration to Envoy and apply without restarts TRAFFIC MANAGEMENT - PILOT
- 15. • Route to specific version of service • Route based on request attribute • … Three versions of the service of reviews TRAFFIC MANAGEMENT REQUEST ROUTE (DEMO)
- 16. • Route to existing version of service • Route part of the request to new version of service • Route all the request to the new version of service Three versions of the service of reviews TRAFFIC MANAGEMENT TRAFFIC SHIFT (DEMO)
- 17. Cited from https://www.infoq.com/presentations/istio-service-mesh • Collect metrics and logs emitted by Envoys without instrumenting apps • Provide a uniform abstraction between application and infra backend • Adapters in the Mixer normalize and forward to backends (monitoring, billing …) • Trace flow of requests across services • Mixer is stateless with caching and buffering OBSERVABILITY - MIXER
- 18. • Instrumentation • Transport or agent • Collector • Storage • API and UI OBSERVABILITY TRACING WITH ZIPKIN AND JAEGER
- 19. Zipkin has been replaced by Jaeger in Istio 0.8 and newer version Application is required 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 OBSERVABILITY TRACING WITH ZIPKIN AND JAEGER (DEMO)
- 20. • Generation of instances (in this example, metric values) from Istio attributes • Creation of handlers (configured Mixer adapters) capable of processing generated instances • Dispatch of instances to handlers according to a set of rules OBSERVABILITY METRICS WITH MIXER + PROMETHEUS (DEMO)
- 21. Need a management service to • Secure microservices and their communication without instrumenting apps • ID management • Key/cert management • Access control SECURITY
- 22. • Key management system • Automate key and certificate generation for service account • Distribute key/certs as kuberentes secret • Rotate keys/certs periodically • Revoke key/certs when required • Self-signed (root) CA vs user defined (root) CA • Identity management • Identify service by service account in SPIFFE format “spiffe://<domain>/ns/<namespace>/sa/<serviceaccount >” SECURITY CERT MANAGEMENT - CITADEL
- 23. • Generate the config with proper information of key/certs and secure naming information, and then pass to envoy SECURITY ID MANAGEMENT - PILOT
- 24. • Access control between services • Rule based by defining “Rule” with “match”, “handler” and “instance” • RBAC based by defining “ServiceRole” with “action”, and defining “ServiceRoleBinding” with “subject” and “roleRef” SECURITY ACCESS CONTROL - PILOT
- 25. • Inject sidecar by leveraging MutatingAdmissionWebhook • Manage policy and configuration by leveraging Custom Resource Definitions • Identify account by leveraging Service Account and Secret • Identify service by leveraging Service Discovery KUBERNETES INTEGRATION
- 26. • 1 vCPU per peak thousand requests per second for the sidecar(s) with access logging (which is on by default) and 0.5 without, fluentd on the node is a big contributor to that cost as it captures and uploads logs. • Assuming typical cache hit ratio (>80%) for mixer checks: 0.5 vCPU per peak thousand requests per second for the mixer pods. • Latency cost/overhead is approximately 10 millisecond for service-to-service (2 proxies involved, mixer telemetry and checks) as of 0.7.1, we expect to bring this down to a low single digit ms. • mTLS costs are negligible on AES-NI (aes in /proc/cpuinfo) capable hardware in terms of both CPU and latency. PERFORMANCE AND SCALABILITY
- 27. ‣ Web istio.io ‣ Twitter: @Istiomesh ‣ Github: https://github.com/istio/istio ‣ Community Doc: https://istio.io/docs ‣ Traffic management using Istio: https://ibm.co/2F7xSnf ‣ Resiliency and fault-tolerance using Istio: https://bit.ly/2qStF2B ‣ Reliable application roll out and operations using Istio: https://bit.ly/2K9IRQX USEFUL LINKS
- 28. 28IBM Cloud / © 2018 IBM Corporation
Hinweis der Redaktion
- Thing to keep in mind It’s not about technology. It’s about people, processes and culture
- Docker
- IBM’s Amalgam8 project is a unified service mesh that provides a traffic routing fabric with a programmable control plane to help internal and enterprise customers with A/B testing, canary releases, and to systematically test the resilience of services against failures. Google’s Service Control provides a service mesh with a control plane that focuses on enforcing policies such as ACLs, rate limits, and authentication in addition to gathering telemetry data from various services and proxies. Lyft developed the Envoy proxy to aid its microservices journey, which brought the company from a monolithic app to a production system spanning 10,000 or more VMs handling 100 or more microservices.
- ISTIO delivers the needed functions for inflight changes, improved resiliency and policy enforcement.
- ISTIO delivers the needed functions for inflight changes, improved resiliency and policy enforcement.
- https://github.com/istio/istio/wiki/Proxy-redirection https://github.com/istio/istio/blob/master/tools/deb/istio-iptables.sh https://github.com/istio/istio/blob/master/pilot/docker/Dockerfile.proxy_init Inbound: iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port ${ISTIO_PROXY_PORT} Outbound: iptables -t nat -A OUTPUT -p tcp -j REDIRECT ! -s 127.0.0.1/32 \ --to-port ${ISTIO_PROXY_PORT} -m owner '!' --uid-owner ${ISTIO_PROXY_UID}
- https://istio.io/docs/concepts/traffic-management/
- ISTIO delivers the needed functions for inflight changes, improved resiliency and policy enforcement.
- https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio/ https://github.com/IBM/microservices-traffic-management-using-istio
- https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio/ https://github.com/IBM/microservices-traffic-management-using-istio
- Mixer collects metrics emitted by Envoys Adapters in the Mixer normalize and forward to backends (monitoring, billing …) Metrics backend can be swapped at runtime Mixer is stateless with caching and buffering Mixer as an intermediation layer allows operators to have fine-grained control over all interactions https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio/ https://github.com/IBM/microservices-traffic-management-using-istio
- https://istio.io/docs/concepts/policies-and-telemetry/overview/
- https://istio.io/docs/tasks/telemetry/distributed-tracing/ mixer/pkg/runtime/dispatcher/ pkg/tracing
- https://istio.io/docs/concepts/security/ https://github.com/istio/istio/tree/master/security Citadel: Key management system Automate key and certificate generation for service account Distribute key/certs as kuberentes secret Rotate keys/certs periodically Revoke key/certs when required Self-signed (root) CA vs user defined (root) CA Identity management Identify service by service account in SPIFFE format “spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>” Pilot: Generate the config with proper information of key/certs and secure naming information, and then pass to envoy Access control between services Rule based by defining “Rule” with “match”, “handler” and “instance” RBAC based by defining “ServiceRole” with “action”, and defining “ServiceRoleBinding” with “subject” and “roleRef”
- https://github.com/istio/istio/tree/master/security
- https://github.com/istio/istio/tree/master/security
- https://istio.io/docs/ https://medium.com/ibm-cloud/tagged/istio
- https://istio.io/docs/performance-and-scalability/overview/