Kubernetes Networking and Istio Apurva Bhandari $whoami SRE / - PowerPoint PPT Presentation

Kubernetes Networking and Istio Apurva Bhandari

$whoami SRE / DevOps Docker & Kubernetes Enthusiast Speaker at Meetups Email: apurvbhandari@gmail.com LinkedIn: https://www.linkedin.com/in/apurvabhandari-linux GitHub: https://github.com/apurvabhandari/Kubernetes Apurva Bhandari

Agenda 1. Kubernetes Networking Basic 2. Advance routing 3. Introduction to Service Mesh Istio 4. Traffic Routing by Istio 5. Networking with and without Istio Apurva Bhandari

Services Types of Services 1. ClusterIP (Default) 2. NodePort 3. LoadBalancer 4. ExternalName Apurva Bhandari

a. ClusterIP apiVersion: v1 kind: Service metadata: P Pod name: example-prod Labels: O kube-proxy spec: env: prod D app: nginx selector: N Host A app: nginx E T env: prod W ports: Pod O Labels: - protocol: TCP kube-proxy R env: prod port: 80 app: nginx K Host B targetPort: 80 type: ClusterIP Apurva Bhandari

b. NodePort apiVersion: v1 kind: Service metadata: name: nginx Pod Labels: namespace: default kube-proxy port env: prod spec: app: nginx Host A ports: - port: 80 Access protocol: TCP Pod targetPort: 80 Labels: kube-proxy 30001 nodePort: 30001 env: prod app: nginx selector: Host B run: nginx type: NodePort Apurva Bhandari

c. LoadBalancer apiVersion: v1 kind: Service metadata: name: tomcat Pod namespace: default Labels: kube-proxy port env: prod spec: app: nginx ports: Host A - name: healthz Load Access Balancer nodePort: 31768 Pod port: 8080 Labels: kube-proxy 30001 protocol: TCP env: prod targetPort: 8080 app: nginx Host B selector: run: tomcat type: LoadBalancer Apurva Bhandari

d. ExternalName apiVersion: v1 kind: Service metadata: name: my-service namespace: prod spec: type: ExternalName externalName: my.database.example.com Apurva Bhandari

User space proxy mode iptables proxy mode IPVS proxy mode

Introduction to Service Mesh - Istio

Secure, monitor and manage services Intelligent routing Resilience Security & policy Telemetry Control traffjc between Increase reliability by Transparently inject mutual Understand the services with dynamic shielding applications from TLS on each call, securing dependencies between route confjguration , fmaky networks and and encrypting traffjc. services , the nature and conduct A/B tests , release cascading failures in Apply organizational fmow of traffjc between canaries , and gradually adverse conditions. policy to the interaction them, and quickly identify upgrade versions using Timeouts , retries , health between services, ensure issues with distributed red/black deployments. checks and circuit access policies are tracing breakers -- all applied enforced and resources are regardless of language, fairly distributed among across the fmeet. consumers.

Istio Value Proposition Securing service Uniform service-level Traffjc management communications observability and operational agility Strongly authenticate services (not Monitor the “ golden signals ” (traffjc, Send inter-cluster and inter- hosts) across heterogeneous error rates and latency) for all environment without manually deployment environments. Limit services, and collect logs on all calls. provisioning ingress, egress, edge access of sensitive data to Use distributed tracing for in-depth layers or hardware LBs. Change authorized services without relying pergormance analysis . Service service behavior and traffjc fmow on L3 controls. Understand security dependency graphs make it easy to without redeploying or change of posture of production environment debug and to understand latency code. Control which services can talk through service dependency and hotspots. to whom via policy and routing graphs. rules .

Uniform observability Collect the golden signals for every service and logs for every call. Understand services and their dependencies . Set, monitor and enforce SLOs on services Bird’s eye view of service behavior for issue triage, reduce time to detect, triage

Operational Service B Service A 95% agility Service B 5% Scale by directing traffic to Service B multiple versions Canary Service B’ Roll out new versions without worrying about ops challenges User-agent Android Service B Service A Apply access control, rate Service B User-agent Apple limiting policies to protect services from bad Service B behavior Canary Service B’

Policy driven security Enable mTLS for authentication and encryption. Defence in depth - security does not stop at Authorize access based on service identity or any the edge. channel aturibute. Confjgure fjner grained RPC-level access control for REST and gRPC.

Networking proxy types Middle Proxy ● Edge Proxy ● Client Side Load Balancing, no SPoF ● Embedded Client Library ● Traditional Load Balancer is Layer 4 ● Lightweight sidecars to manage traffjc ● Client Side / Sidecar Proxy ● between services Scaling capabilities + polyglot aspect ● Sidecars can do much more than just load ● balancing!

The magic of the sidecar! Deployed with every ● workload what Envoy listens for Listeners Proxies all traffjc into ● and out of a service where traffic can be sent Routes Directs traffjc (including ● routing rules) Clusters how to send traffic Enforces policy ● Reporus telemetry ● All with no embedded ● hosts able to receive traffic Endpoints client library

Envoy Goodies: HTTP/2 & gRPC ● Zone-aware load balancing w/ failover ● A C++ based L4/L7 proxy ● Health checks, circuit breakers, timeouts, retry ● Lightweight, low memory footprint ● budgets No hot reloads - API driven confjg updates ● Batule-tested @ Lyfu ● 100+ services ○ 10,000+ VMs ○ Istio’s contributions: 2M req/s ○ ● Transparent proxying w/ SO_ORIGINAL_DST Traffjc routing and splituing ● ● Request tracing using Zipkin Fault injection ●

Architectural components Envoy: Network proxy to intercept ● Service A Service B communication and apply policies. Pilot : Control plane to confjgure and push ● proxy proxy service communication policies Policy checks, Mixer: Policy enforcement with a fmexible ● telemetry plugin model for providers for a policy. Config data TLS certs to to Envoys Envoys Istio Auth: Service-to-service auth[n,z] using ● Pilot Mixer Citadel mutual TLS, with built-in identity and Control Plane API credential management.

Service A Service B Via egress gateway Egress Ingress External Service Public Internet gateway gateway Mesh proxy Mesh proxy Directly via sidecar Mesh Boundary

Public Internet Ingress Gateway Gateway Host www.myapp.com Poru 80 TLS Cerus Service A ViruualService Host www.myapp.com Rewrite URL Goto service B, subset v1 Service B DestinationRule Deployment version: production Host service B Subset v1 (prod), v2 (canary) Service B TLS setuings Deployment Circuit breaker version: canary LoadBalancer setuings

Traffic Management Application rollout (in percentage distribution) ● ● Traffic steering (content based) ● Resiliency ● Efficiency

Thank You