Kubernetes04 - 從容器到雲原生
容器到雲原生的路線：
容器 -> Kubernetes -> 微服務 ->雲原生 -> 服務網格 -> 使用場景 -> 開源。
為什麼使用K8S
下面這張圖是K8s的架構圖，顯示了元件間的CNI，CRI，OCI等，這些將Kubernetes 與某款具體產品解耦，給使用者最大的定製程度，使得 Kubernetes 有機會成為跨雲的真正的雲原生應用的作業系統。
雲原生的核心目標
雲已經可以為我們提供穩定可以唾手可得的基礎設施，但是業務上雲成了一個難題，Kubernetes 的出現與其說是從最初的容器編排解決方案，倒不如說是為了解決應用上雲（即雲原生應用）這個難題。
包括微服務和 FaaS/Serverless 架構，都可以作為雲原生應用的架構。
但就 2017 年為止，Kubernetes 的主要使用場景也主要作為應用開發測試環境、CI/CD 和執行 Web 應用這幾個領域
另外基於 Kubernetes 的構建 PaaS 平臺和 Serverless 也處於爆發的準備的階段，如下圖中 Gartner 的報告中所示：
2017 年時各大公有云如 Google GKE、微軟 Azure ACS、亞馬遜 EKS（2018 年上線）、VMware、Pivotal（後被VMware 收購）、騰訊雲、阿里雲等都提供了 Kubernetes 服務。
微服務
下圖列出了微服務所需關心的主題，圖片來自RedHat Developers。
微服務帶給我們很多開發和部署上的靈活性和技術多樣性，但是也增加了服務呼叫的開銷、分散式系統管理、除錯與服務治理方面的難題。
當前最成熟最完整的微服務框架可以說非 Spring 莫屬，而 Spring 又僅限於 Java 語言開發，其架構本身又跟 Kubernetes 存在很多重合的部分，如何探索將 Kubernetes 作為微服務架構平臺就成為一個熱點話題。
就拿微服務中最基礎的服務註冊發現功能來說，其方式分為客戶端服務發現和服務端服務發現兩種，Java 應用中常用的方式是使用 Eureka 和 Ribbon 做服務註冊發現和負載均衡，這屬於客戶端服務發現，而在 Kubernetes 中則可以使用 DNS、Service 和 Ingress 來實現，不需要修改應用程式碼，直接從網路層面來實現。
微服務中的2種服務發現方式
服務網格
Kubernetes 中的應用將作為微服務執行，但是 Kubernetes 本身並沒有給出微服務治理的解決方案，比如服務的限流、熔斷、良好的灰度釋出支援等。
Service Mesh 可以用來做什麼
- Traffic Management：API 閘道器
- Observability：服務呼叫和效能分析
- Policy Enforcment：控制服務訪問策略
- Service Identity and Security：安全保護
Service Mesh 的特點
- 專用的基礎設施層
- 輕量級高效能網路代理
- 提供安全的、快速的、可靠地服務間通訊
- 擴充套件 kubernetes 的應用負載均衡機制，實現灰度釋出
- 完全解耦於應用，應用可以無感知，加速應用的微服務和雲原生轉型
都有哪些Service Mesh
使用 Service Mesh 將可以有效的治理 Kubernetes 中執行的服務，當前開源的流行的 Service Mesh 有：
- Linkerd：由最早提出 Service Mesh 的公司 Buoyant 開源，創始人來自 Twitter
- Envoy：由 Lyft 開源，可以在 Istio 中使用 Sidecar 模式執行以作為資料平面，也可以基於它來構建自己的服務網格
- Istio：由 Google、IBM、Lyft 聯合開發並開源
Istio VS Linkerd
Linkerd 和 Istio 是最早開源的 Service Mesh，它們都支援 Kubernetes，下面是它們之間的一些特性對比。
| Feature | Istio | Linkerd |
|---|---|---|
| 部署架構 | Envoy/Sidecar | DaemonSets |
| 易用性 | 複雜 | 簡單 |
| 支援平臺 | Kubernetes | Kubernetes/Mesos/Istio/Local |
| 是否已有生產部署 | 是 | 是 |
Istio 的元件複雜，可以分別部署在 Kubernetes 叢集中，但是作為核心路由元件 Envoy 是以 Sidecar 形式與應用執行在同一個 Pod 中的，所有進入該 Pod 中的流量都需要先經過 Envoy。
Linker 的部署十分簡單，本身就是一個映象，使用 Kubernetes 的 DaemonSet 方式在每個 node 節點上執行。
使用場景
GitOps
我們知道 Kubernetes 中的所有應用的部署都是基於YAML檔案的，這實際上就是一種 Infrastructure as code，完全可以通過 Git 來管控基礎設施和部署環境的變更。
大資料
Spark 現在已經非官方支援了基於 Kubernetes 的原生排程，其具有以下特點：
- Kubernetes 原生排程：與 yarn、mesos 同級
- 資源隔離，粒度更細：以 namespace 來劃分使用者
- 監控的變革：單次任務資源計量
- 日誌的變革：pod 的日誌收集
| 特性 | Yarn | Kubernetes |
|---|---|---|
| 佇列 | queue | namespace |
| 例項 | ExcutorContainer | Executor Pod |
| 網路 | host | plugin |
| 異構 | no | yes |
| 安全 | RBAC | ACL |
下圖是在 Kubernetes 上執行三種排程方式的 spark 的單個節點的應用部分對比：
從上圖中可以看到在 Kubernetes 上使用 YARN 排程、standalone 排程和 Kubernetes 原生排程的方式，每個 node 節點上的 Pod 內的 Spark Executor 分佈，毫無疑問，使用 Kubernetes 原生排程的 Spark 任務才是最節省資源的。
開源
對於一個初次接觸 Kubernetes 的人來說，看到這樣一個龐大的架構選型時會望而生畏，但是 Kubernetes 的開源社群幫助了我們很多。