前言

從研究所開始接觸到 OpenStack、分散式系統設計，甚至開始工作後都不斷在相關領域打轉。接觸到 Kubernetes 前，其陡峭的學習曲線 (和 Docker Swarm 相比) 讓許多人為之卻步 ，但從設使用方式甚至架構設計便能夠深刻體會，Kubernetes 是如何真正解決許多分散式系統上的困難點，並且將分散式系統內大部分的難題交由平台來處理，也可以說它將「開發」與「維運」間的高牆打掉不少。

Kubernetes 有以下幾個特點非常吸引我:

1. 維運方便: 內建滾動升級、健康度檢測、標籤組合調控流量分流
2. 生態系完整: 從本地開發到線上部署皆有對應工具處理，加速整體系統迭代
3. 跨雲提供商: 橫跨三本柱 GKE、AWS、Azure，從而避免 Vendor lock-in

正好前陣子微軟釋出 Desigining Distributed Systems 的電子書，內容主要針對在 Kubernetes 上的分散式系統設計模式，最近在練習英文以及重新回顧分散式系統設計的相關知識，趁此機會為該書內容做個導讀，重點會擺放在設計模式的講解與搭配不同的實際案例作為說明。

開發流程發生什麼問題

對於一般開發者來說要架設 Kubernetes 是件吃力不討好的事情，自從 minikube 推出後大幅減低進入門檻，讓任何人都可以輕易在電腦上執行本地端的 Kubernetes。minikube 原理是利用 Hyperviosr 在電腦上執行已經安裝好 Kubernetes 的虛擬機，再將 kubelet 的設定指向 minikube 內。

一般開發流程大概是:

1. 修改程式
2. 打包成映像檔，送到 remote registry
3. 更新 pod spec
4. docker daemon 從 registry 拉最新映像檔

系列文章

• Fission 基本介紹

前言

Fission 是基於 Kubernetes 之上的 Serverless 框架，而 Istio 是前陣子由 Google、IBM、Lyft 共同推出用來管理、連結微服務的開放平台，透過將兩者整合在一起便能夠提供使用者更多強大的功能。

這陣子花了些時間做實驗跟開發將 Fission 跟 Istio 做初步的整合。雖就目前的狀況來說還有許多地方尚待改進，但相信過陣子就能夠將兩者更好的結合在一起了。

若對 Fission 以及 Istio 整合有興趣的人，下面是完整的安裝教學。

安裝

測試環境

• Google Kubernetes Engine: 1.9.2-gke.1 cluster
• Fission: 0.6.0
• Istio: 0.6.0

建立 Kubernetes v1.9+ alpha cluster

可用的區域 (ZONE) 可看這裡

$ export ZONE=<zone name>
$ gcloud container clusters create istio-demo-1 \
    --machine-type=n1-standard-2 \
    --num-nodes=1 \
    --no-enable-legacy-authorization \
    --zone=$ZONE \
    --cluster-version=1.9.2-gke.1

前言

對於提供 HTTP 服務的系統來說，取得來源 IP 方式有兩種:

• 利用封包標頭取得來源 IP

此方案是直接讀取封包的來源 IP，但由於容器和外界溝通不像傳統 Linux 主機有實體網卡對接，而是透過一系列的 NAT 規則置換封包標頭後才傳進容器內 (Understand container communication)，導致取得錯誤的使用者 IP。

• 通過夾帶在 HTTP 請求的 X-Forwarded-For 來取得

此方案則是利用 PROXY Protocol，此方案是讓 Proxy Server 將 IP 附加在 HTTP 標頭 X-Forwarded-For 內，因此該標頭內的第一個位址即是使用者的真實 IP。

X-Forwarded-For:[61.219.125.41, 10.140.0.2]

下面會介紹在 GKE (Google Container Engine) 上透過 L7 HTTP Load Balancer 取得使用者真實 IP。

架構說明

下圖為目前 Google 支援三種 LB

系列文章

• Kubernetes Service - 概念詳解及應用
• Kubernetes Service - 存取路徑差異、注意要點

前言

前篇文章介紹 Service 不同存取路徑間的差異，這次我們來討論 Service 和 Label 之間是如何互相影響的。

Service 與 Label Selector 共舞

We encourage use of a unique collection of labels rather than a single unique label value since the additional attributes are generally needed — bgrant0607

在 Kubernetes 最佳實踐中，Pod 本身會帶著許多不同標籤 (Label) 來辨別其實際用途。透過賦予一組唯一的標籤組合 (a unique collection of labels)，不僅能擁有更精確的粒度 (granularity) 以外，也能避免操作上出現異常。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: python-http-server
spec:
  replicas: 1
  selector:
    matchLabels:
      env: python
      svc: http-server
  template:
    metadata:
      labels:
        env: python
        svc: http-server
    spec:
      containers:
      - name: http-server
        image: trinitronx/python-simplehttpserver
        command:
          - python
        args:
          - -m
          - SimpleHTTPServer
          - "80"
        ports:
        - containerPort: 80
          protocol: TCP