前言

上篇提到使用 Kubernetes 的一些基本的網路元件。這次本篇主要在紀錄 Kubernetes 常用的水平擴展元件 Deployment 的觀念以及使用方法。最後會提到 Kubernetes 缺乏的要素以及如何透過 Service Mesh 的引入，在具體上給 Kubernetes 增添什麼樣的變化。

Depolyment

讓服務可以 zero downtime 升級的組建 （不停機）

自動產生和維護 ReplicaSet
可隨時 rollback 到先前的版本 (預設是保留兩個版本)
Version-based Rollout (Canary deployment)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia-dp
  labels:
    app: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: oliwave/kubia
        ports:
        - containerPort: 8080

LAB : 在 k8s 上實踐不同版本服務的 rollout

Play with k8s

複製以下檔案

kubia-dp-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia-dp
  labels:
    app: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: oliwave/kubia:v1
        ports:
        - containerPort: 8080

kubia-dp-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubia-dp
  labels:
    app: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: oliwave/kubia:v2
        ports:
        - containerPort: 8080

kubia-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  #sessionAffinity: ClientIP # 根據需要來設定
  ports:
  - port: 80 # service 的 port
    targetPort: 8080 # service 會將封包轉送的 port
  selector:
    app: kubia

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: kubia.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia
          servicePort: 80

kubectl apply -f kubia-dp-v1.yaml
- kubectl get po -o wide 檢查 pod 是否部署在叢集中
- kubectl get rs 檢查 replicasets 是否有被 deployment 自動的產生
kubectl apply -f kubia-svc.yaml
- kubectl get svc 取得 Service 的 IP
kubectl apply -f ingress.yaml
while true; do curl <service IP>; done
- 不停得向服務發送請求
kubectl apply -f kubia-dp-v2.yaml

Service Mesh

傳統 Microservice 不同服務間的交互

每個微服務必須個別實現 Security (公有雲)、Tracing、Logging 等機制。

導致 不易開發和維護
違反微服務 Do One Thing, Do it Best 的原則

What is Service mesh ?

在不影響既有 Application container 的情況下，植入 Sidecar Container
Sidecar Container 負責管理和設定不同服務實體之間的網路通訊

輕鬆簡單地為現有已經部署的微服務進行 load-balancing, service-to-service authentication, monitoring 等等，而 無需改動現有的服務

Istio

Istio 在架構上大量的使用 Service Mesh 模式

實現 Sidecar Injection 的方式

istio-init (init container) 負責修改 iptables 的規則，讓所有進來或出去 Pod 的流量都經過 sidecar proxy
istio-proxy 就是 sidecar proxy (based on Envoy)

架構

Istio service mesh 在邏輯上可以分為 Control plane 和 Data plane

Data plane 是由一組 proxies (envoy) 所組成，並以 Sidecar 的方式來部署
Control plane 專門用來管理和設定這些 路由流量 的 proxies

Pilot

為 Envoy Sidecar 提供 Service Discovery 的服務

Citadel

Enables strong service-to-service and end-user authentication with built-in identity and credential management.

Sidecar deployment 的效果

使 Istio 可以將大量有關流量的訊號抽取出來成為不同的屬性。Istio 可以通過這些屬性來執行不同的 政策決定 (policy decisions) ，並將他們送到監控系統來提供當前 service mesh 的行為資訊。
可以將不同的功能加入到現有 Istio 而無需重構架構或是程式碼。

Traffic

流量在 Istio 的定義中可以分為 Data plane traffic 和 Control plane traffic 。 Envoy proxies 是 Istio 架構中唯一與 Data plane traffic 有關的組件。

流量管理

Istio 的流量管理模組是使用 envoy proxies ，隨著你的服務一起部署上去。所有的流量不論是由 service mesh 接收或送出都會由 envoy 來 proxy。

Envoy 是一種 L7 proxy 和 communication bus (API gateway) 被設計用來在大型 SOA Service-oriented Architectures 上。

透過簡單規則配置和流量路由控制服務之間的流量和API調用的流量。簡化了 Service 一些屬性上的配置。

Circiut breaker
- 服務自我檢查的機制
- 避免單一服務崩潰，造成整體服務連鎖崩壞
A/B Testing
Canary rollouts
Failure recovery

Kubernetes 就有做了為什麼還需要 Istio ?

舉例： Version-based Rollout (Canary deployment)

k8s 使用 pod 的數量 來調整不同版本的比例
Istio 透過 Virtual service 直接控制流量進入不同流量的比例

Learn by sharing

kubernetes 筆記 - Component 3

前言