《Istio in Action》书摘

2022-10-30  本文已影响0人  AlphaHinex

原文地址：https://alphahinex.github.io/2022/10/30/istio-in-action/

cover

description: "深入浅出的讲解了 Istio 的原理、用法等，并配有实际例子，可作为快速了解 Istio 的读物"
date: 2022.10.30 10:34
categories:
- Book
- Cloud Native
tags: [Kubernetes, Istio]
keywords: Kubernetes, Istio, Serivce Mesh, Envoy

Chapter 1. Introducing Istio Service Mesh

1.4 Pushing these concerns to the infrastructure

1.4.3 Meet Envoy proxy

1.5 What’s a service mesh?

1.6 Introducing Istio service mesh

  1. Traffic comes into the cluster (ie, a client issues a POST "/checkout" request to our shopping cart service)
  2. Traffic goes to the shopping-cart service but goes to the Istio service proxy (Envoy). Note, this traffic (and all inter-service communication in the mesh) is secured with mutual TLS by default. The certificates for establishing mTLS are provided by (7).
  3. Istio determines (by looking at the request headers) that this request was initiated by a customer in the North America region, and for those customers, we want to route some of those requests to v1.1 of the Tax service which has a fix for certain tax calculations; Istio routes the traffic to the v1.1 Tax service
  4. Istio Pilot is used to configure the istio proxies which handle routing, security, and resilience
  5. Request metrics are periodically sent back to the Istio Mixer which stores them to back end adapters (to be discussed later)
  6. Distributed tracing spans (like Jaeger or Zipkin) are sent back to an tracing store which can be used to later track the path and latency of a request through the system
  7. Istio Auth which manages certificates (expiry, rotation, etc) for each of the istio proxies so mTLS can be enabled transparently

Chapter 2. First steps with Istio

2.2 Getting to know the Istio control plane

2.2.1 Istiod

2.3 Deploy your first application in the service mesh

$ istioctl kube-inject -f services/catalog/kubernetes/catalog.yaml

$ istioctl kube-inject -f services/catalog/kubernetes/catalog.yaml \ 
| kubectl apply -f -

serviceaccount/catalog created 
service/catalog created 
deployment.extensions/catalog created

Chapter 3. Istio’s data plane: Envoy Proxy

3.4 How Envoy fits with Istio

Chapter 4. Istio Gateway: getting traffic into your cluster

4.1 Traffic ingress concepts

4.1.2 Virtual Hosting: multiple services from a single access point

4.2 Istio Gateway

4.2.2 Gateway routing with Virtual Services

4.2.4 Istio Gateway vs Kubernetes Ingress

4.3 Securing Gateway traffic

4.3.1 HTTP traffic with TLS

$ curl -H "Host: apiserver.istioinaction.io" \ 
https://apiserver.istioinaction.io:443/api/catalog \ 
--cacert certs/2_intermediate/certs/ca-chain.cert.pem \ 
--resolve apiserver.istioinaction.io:443:127.0.0.1

4.3.3 HTTP traffic with mutual TLS

Chapter 5. Traffic control: fine-grained traffic routing

5.3 Traffic shifting

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
    - mesh 
  http:
  - route:
    - destination:
        host: catalog
        subset: version-v1 
      weight: 90
    - destination: 
        host: catalog
        subset: version-v2 
      weight: 10

most traffic to v1, some traffic to v2

5.4 Lowering risk even further: Traffic mirroring

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog 
  gateways:
    - mesh 
  http:
  - route:
    - destination:
        host: catalog
        subset: version-v1
      weight: 100
    mirror:
      host: catalog 
      subset: version-v2

5.5 Routing to services outside your cluster by using Istio’s service discovery

Chapter 6. Resilience: solving application-networking challenges

6.2 Client-side load balancing

6.2.1 Getting started with client-side load balancing

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-backend-dr
spec:
  host: simple-backend.istioinaction.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

6.2.4 Understanding the different load balancing algorithms

6.3 Locality aware load balancing

6.3.1 Hands on with locality load balancing

6.3.2 More control over locality load balancing

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-backend-dr
spec:
  host: simple-backend.istioinaction.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        distribute:
        - from: us-west1/us-west1-a/*
          to:
            "us-west1/us-west1-a/*": 70
            "us-west1/us-west1-b/*": 30
    connectionPool:
      http:
        http2MaxRequests: 10
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 5s
      baseEjectionTime: 30s
      maxEjectionPercent: 100
  • loadBalancer: Add load balancer config
  • from: Set origin zone
  • to: Set two dest zones

6.4 Transparent timeouts and retries

6.4.2 Retries

  1. connect-failure
  2. refused-stream
  3. unavailable (grpc status code 14)
  4. cancelled (grpc status code 1)
  5. retriable-status-codes (default to HTTP 503 in istio)

6.4.3 Advanced retries

6.5 Circuit breaking with Istio

6.5.1 Guarding against slow services with connection pool control

Chapter 7. Observability with Istio: understanding the behavior of your services

7.1 What is observability?

7.1.1 Observability vs Monitoring

7.2 Collecting metrics from Istio data plane

7.2.2 Pulling Istio Metrics into Prometheus

7.4 Distributed tracing with OpenTracing

7.4.1 How does it work

  1. x-request-id
  2. x-b3-traceid
  3. x-b3-spanid
  4. x-b3-parentspanid
  5. x-b3-sampled
  6. x-b3-flags
  7. x-ot-span-context

7.4.4 Limiting tracing apeture

7.5 Visualization with Kiali

  1. A workload is a running binary that can be deployed as a set of identical-running replicas. For example, in Kubernetes this would be the Pods part of a Deployment. If we had a "service A" deployment with 3 replicas, this would be a workload.
  2. An application is a grouping of workloads and associated constructs like services and configuration. In Kubernetes this would be a "service A" along with a "service B" and maybe a "database". These would each be their own workload, but they would together make up a Kiali application.

Chapter 8. Istio Security: Effortlessly secure

8.1 Application Security refresher

8.1.4 Comparison of security in Monoliths and Microservices

8.2 SPIFFE - Secure Production Identity Framework for Everyone

8.2.1 SPIFFE ID - Workload Identity

8.2.4 SPIFFE Verifiable Identity Document

8.2.5 How Istio implements SPIFFE

  1. The Workload Endpoint is implemented by the Pilot-Agent that performs identity bootstrapping
  2. The Workload API is implemented by Istio CA that issues certificates
  3. The Workload for whom the identity is issued in Istio is the service proxy

8.2.6 Step by step bootstrapping of Workload Identity

  1. Service account token is assigned to the Istio Proxy container
  2. The token and a Certificate Signing Request are sent to Istiod
  3. Istiod validates the token using the Kubernetes Token Review API
  4. On success, it signs the certificate and provides it as a response
  5. The Pilot Agent uses the Secrets Discovery Service of Envoy to configure it to use the certificate containing the identity.

8.6 What is a request identity anyway?

8.6.3 Overview of the flow of one request

本书中涉及的 Istio 中定义的资源

VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog-service
spec:
  hosts:
  - catalog.prod.svc.cluster.local
  http:
  - match:
    - headers:
        x-dark-lauch:
          exact: "v2"
    route:
    - destination:
        host: catalog.prod.svc.cluster.local
        subset: v2
  - route:
    - destination:
        host: catalog.prod.svc.cluster.local
        subset: v1

DestinationRule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: catalog
spec:
  host: catalog
  subsets:
  - name: version-v1
    labels:
      version: v1
  - name: version-v2
    labels:
      version: v2

Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "apiserver.istioinaction.io"

ServiceEntry

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: jsonplaceholder
spec:
  hosts:
  - jsonplaceholder.typicode.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL

EnvoyFilter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: simple-backend-retry-status-codes
  namespace: istioinaction
spec:
  workloadSelector:
    labels:
      app: simple-web
  configPatches:
  - applyTo: HTTP_ROUTE
    match:
      context: SIDECAR_OUTBOUND
      routeConfiguration:
        vhost:
          name: "simple-backend.istioinaction.svc.cluster.local:80"
    patch:
      operation: MERGE
      value:
        route:
          retry_policy:
            retry_back_off:
              base_interval: 50ms
          retriable_status_codes:
          - 402
          - 403

metric

apiVersion: "config.istio.io/v1alpha2"
kind: metric
metadata:
  name: apigatewayrequestcount
  namespace: istio-system
spec:
  value: "1"
  dimensions:
    source: source.workload.name | "unknown"
    destination: destination.workload.name | "unknown"
    destination_ip: destination.ip
  monitored_resource_type: '"UNSPECIFIED"'

prometheus

apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
  name: apigatewayrequestcounthandler
  namespace: istio-system
spec:
  metrics:
    - name: apigateway_request_count
      instance_name: apigatewayrequestcount.metric.istio-system
      kind: COUNTER
      label_names:
        - source
        - destination
        - destination_ip

PeerAuthentication

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

AuthorizationPolicy

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "allow-catalog-requests-in-api-gw"
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: apigateway
  rules:
  - to:
    - operation:
        paths: ["/api/catalog*"]
  action: ALLOW

RequestAuthentication

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "jwt-token-request-authn"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  jwtRules:
  - issuer: "auth@istioinaction.io"
    jwks: |
     { "keys": [{"e":"AQAB","kid":"##REDACTED##","kty":"RSA","n":"##REDACTED##"}]}
上一篇 下一篇

猜你喜欢

热点阅读