Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Manage Kuberentes Deployment with Istio

Manage Kuberentes Deployment with Istio

The service mesh is an infrastructure component that helps manage services running within our clusters. Without any changes to service or application code, solutions like Istio and Linkerd provide features to manage container deployments at scale. With Istio we get traffic management, security, rate limiting, monitoring, and many more things out of the box. We will discuss these solutions and some of their features at a high level, then roll in some specific demonstrations of using a service mesh to route and shift service traffic, easily manage deployments and test our services with micro benchmarks and fault injection. We will also look at some of the error scenarios you may encounter and how to deal with some of them while keeping your sanity.

Avatar for Mofizur Rahman

Mofizur Rahman

June 07, 2019
Tweet

More Decks by Mofizur Rahman

Other Decks in Technology

Transcript

  1. Agenda • Learn what Istio is • Understanding app deployment

    in the kubernetes world. • See why we need Istio.
  2. Mofizur Rahman (Mofi) Developer Advocate @IBM Works On Container And

    Cloud Native Technologies Favorite Programming Language Is Golang. Collect Stickers @moficodes
  3. Microservices • Microservices are the de facto standard for cloud

    native software • Microservices allow development teams to deploy portable and scalable applications 7
  4. Docker • Docker changed the way we build and ship

    software • Application and host are decoupled, making application services portable • Containers are an implementation detail, but a critical one 11
  5. Dockerfile 13 FROM ruby:2.3-slim COPY details.rb /opt/microservices/ ARG service_version ENV

    SERVICE_VERSION ${service_version:-v1} ARG enable_external_book_service ENV ENABLE_EXTERNAL_BOOK_SERVICE ${enable_external_book_service:-false} EXPOSE 9080 WORKDIR /opt/microservices CMD ruby details.rb 9080
  6. Docker Is a Start But, once we abstract the host

    away by using containers, we no longer have our hands on an organized platform. 14
  7. 16

  8. Kubernetes as a Platform • Infrastructure resource abstraction • Cluster

    architecture where one or more masters control worker nodes • Scheduler deploys work to the nodes • Work is deployed in groups of containers 18
  9. Kubernetize our App 19 apiVersion: v1 kind: Service metadata: name:

    details labels: app: details service: details spec: ports: - port: 9080 name: http selector: app: details apiVersion: extensions/v1beta1 kind: Deployment metadata: name: details-v1 labels: app: details version: v1 spec: replicas: 1 template: metadata: labels: app: details version: v1 spec: containers: - name: details image: istio/examples-bookinfo-details-v1:1.10.1 imagePullPolicy: IfNotPresent ports: - containerPort: 9080
  10. …to Cloud Native Kubernetes Hotness • Microservices running in orchestrated

    containers • Everybody's happy • What happens now? 21 Load balancer Service Service Database Service Queue
  11. …to Cloud Native Kubernetes Hotness • Microservices running in orchestrated

    containers • Everybody's happy • What happens now? 22 Load balancer Service Service Service Service Service Database Service Queue
  12. 24

  13. 25

  14. In Kubernetes • Load balance all pods under service Traffic

    Routing is Round-Robin • 3 V1 pod and 1 V2 pod means 75% - 25% split Controlled by Pod Numbers
  15. Multiversioned Services •Features, compatibility, regional Might want a Service with

    Few Versions •Experimental Features, Browser etc Choose Route Based on App Requirements
  16. Table Stakes for Services at Cloud Scale 31 We require

    a method to simply and repeatably deploy software, and simply and recoverably modify deployments We require telemetry, observability, and diagnosability for our software if we hope to run at cloud scale
  17. What Do We Do Ingress and Traffic Management 35 Metrics

    and Analytics Tracing and Observability Identity and Security
  18. Service Mesh • This is not a new solution which

    solves all the world’s problems, but a different way to apply existing solutions • Enables integration of existing (as well as future) best-in-class solutions for All The Things 36
  19. What Is a Service Mesh? • Infrastructure layer for controlling

    and monitoring service-to-service traffic • A data plane deployed alongside application services, and a control plane used to manage the mesh 37
  20. Service Mesh • Provides DevOps teams a stable and extensible

    platform to monitor and maintain deployed services • For the most part, invisible to development teams 38
  21. Let’s Talk About Istio Istio is a service mesh that

    allows us to connect, secure, control and observe services at scale, often requiring no service code modification 39
  22. Istio Components • Envoy • Sidecar proxy • Pilot •

    Propagates rules to sidecars 40 • Mixer – Enforces access control, collects telemetry data • Citadel – Service-to-service and end-user AuthN and AuthZ
  23. Istio Features • Traffic Management • Fine-grained control with rich

    routing rules, retries, failovers, and fault injection • Observability • Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress 41
  24. Istio Features • Security • Strong identity-based AuthN and AuthZ

    layer, secure by default for ingress, egress and service-to-service traffic • Policy • Extensible policy engine supporting access controls, rate limits and quotas 42
  25. Envoy High performance proxy which mediates inbound and outbound traffic.

    48 • Dynamic service discovery • Load balancing • TLS termination • HTTP/2 and gRPC proxies • Circuit breakers • Health checks • Split traffic • Fault injection • Rich metrics
  26. Goal Shift Traffic from V1 of review to V3 of

    review (Blue/Green) Do traffic routing based on specific user
  27. Traffic Management • Integrated Ingress and Egress • Error handling,

    retries, circuit breaking • Application knowledge can be leveraged for intelligent routing • Fault injection for end-to-end testing 54
  28. Telemetry • Istio’s Mixer is stateless and does not manage

    any persistent storage of its own • Capable of accumulating a large amount of transient ephemeral state • Designed to be a highly reliable, goal is > 99.999% uptime for any individual instance • Many adapters available: Prometheus, Cloud providers, Datadog, Solarwinds… 55
  29. Performance and Scalability • Code level micro-benchmarks • Synthetic end-to-end

    benchmarks across various scenarios • Realistic complex app end-to-end benchmarks across various settings • Automation to ensure performance doesn’t regress 56
  30. Security • Traffic encryption to defend against the man- in-the-middle

    attacks • Mutual TLS and fine-grained access policies to provide flexible access control • Auditing tools to monitor all of it 57
  31. Final Thoughts There is no free lunch in this world.

    Istio gives you a lot of things built in but it uses some CPU resources. Two articles that cover this. • Ivan Sim —Linkerd 2.0 and Istio Performance Benchmark • Michael Kipper— Benchmarking Istio & Linkerd CPU