# 云原生的未來 要想搞明云原生的未來，首先我們要弄明白云原生是什么。CNCF給出的定義是： - 容器化 - 微服務 - 容器可以動態調度 我認為云原生實際上是一種理念或者說是方法論，它包括如下四個方面： - 容器化：作為應用包裝的載體 - 持續交付：利用容器的輕便的特性，構建持續集成和持續發布的流水線 - DevOps：開發與運維之間的協同，上升到一種文化的層次，能夠讓應用快速的部署和發布 - 微服務：這是應用開發的一種理念，將單體應用拆分為微服務才能更好的實現云原生，才能獨立的部署、擴展和更新 一句話解釋什么是云原生應用：云原生應用就是為了在云上運行而開發的應用  要運行這樣的應用必須有一個操作系統，就像我們運行PC或手機應用一樣，而Kubernetes就是一個這樣的操作系統。 我們再來看下操作系統寶庫哪些層次。  - 硬件管理：可以管理CPU、內存、網絡和存儲 - 設備接口、虛擬化工具、實用工具 - Shell、用戶界面 - 各種終端工具，如awk、sort、grep、vim等 下面是CNCF給出的云原生景觀圖。  該圖中包括云原生的各種層次的提供者和應用，通過該圖可以組合出一些列的云原生平臺。 - IaaS云提供商（公有云、私有云） - 配置管理，提供最基礎的集群配置 - 運行時，包括存儲和容器運行時、網絡等 - 調度和管理層，協同和服務發現、服務管理 - 應用層 也可以有平臺提供以上所有功能，還可以有提供可觀測性、分析和擴展應用。 看到這個景觀圖，大家覺得Kubernetes真的還只做了容器編排嗎？實際上它是制定了一個標準。就像一個系統一樣，所有的應用和插件都是基于它來構建的。 ## Kubernetes的現狀與未來 Kubernetes發展已經有3年多的時間了，它已經基本成為了容器編排調度框架的標準。它的各種抽象與資源定義已經被大家廣為接受。其中最基礎的調度單元Pod。 創建一個自定義資源類型需要滿足的條件。 這是KubeVirt的架構圖。  我們看到圖中有兩個是Kubernetes原生的組件，API server和kubelet，我們創建了virt-controller就是為了創建CRD的controller，它擴展了kube-controller的功能，用于管理虛擬機的生命周期，同時在每個節點上都用DaemonSet的方式運行一個virt-handler，這個handler是用于創建虛擬機的處理器，每個節點上即可用運行虛擬機也可以運行容器，只要這個節點上有virt-handler就可以運行和調度虛擬機。 ### Kubernetes做了什么？ Kubernetes優秀的分布式架構設計，給我們提供了眾多了可擴展接口，可以讓我們很方便的擴展自己的運行時、網絡和存儲插件，同時還可以通過CRD管理我們自己的分布式應用。它的聲明式配置方式可以讓我們利用Kubernetes的原語快速的編排出一個云原生應用。 Kubernetes的資源隔離也能保證對集群資源的最大化和最優利用率。 下圖中展示了Kubernetes中的資源隔離層次。  - 容器 - Pod：命名空間的隔離，共享網絡，每個Pod都有獨立IP，使用Service Account為Pod賦予賬戶 - Sandbox：是對最小資源調度單位的抽象，甚至可以是虛擬機 - Node：網絡隔離，每個節點間網絡是隔離的，每個節點都有單獨的IP地址 - Cluster：元數據的隔離，使用Federation可以將不同的集群聯合在一起 Kubernetes中的基本資源類型分成了三類： - 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob - 服務：Service、Ingress - 存儲：PV、PVC、ConfigMap、Secret 在最近一屆的KubeCon & CloudNativeCon上Operator已經變得越來越流行。下面是OpenEBS的一個使用Operator的例子。  OpenEBS是一款容器化存儲，它基于Ceph構建，容器化存儲最大的好處就是復用Kubernetes的資源類型，簡化存儲應用的部署，將單體的存儲拆分為“微服務化”的存儲，即每個應用在聲明PV的時候才會創建存儲，并與PV的生命周期一樣都是獨立于應用的。 OpenEBS的存儲也是分控制平面和數據平面的，下圖是OpenEBS的架構圖。  黃色部分是OpenEBS的組件（除了kube-dashboard），它是使用Kubernetes的各種原語和CRD來創建的，架構跟Kubernetes本身也很類似。 用戶在使用OpenEBS的StorageClass創建PV的時候，OpenEBS會為每個PV創建一個用戶管理該PV的Deployment，這個Deployment再來創建存儲副本，每個PV的存儲副本都可以不同，這取決的用戶如何定義的StorageClass。這樣就可以將原來的單體存儲拆分為微服務化的存儲。 上面說到了Operator的一個應用，下面再來看一個我們之前在Kubernetes中部署Hadoop YARN和Spark的例子。   Kubernetes始于12因素應用的PaaS平臺，它是微服務的絕佳部署管理平臺，基于它可以應用多種設計模式。它的未來將變成什么樣呢？  - Service Mesh：解決微服務治理問題 - Auto Pilot：自動駕馭能力，服務自動擴展，智能運維 - FaaS/Serverless：用戶無需再關注底層平臺，只需要部署服務，根據服務的資源消耗和使用時間付費 **Serverless的發展** 為了實現上述的各種能力，急需解決的就是基于Kubernetes的持續集成和發布問題。 當前出現了一系列的基于Kubernetes的CI/CD工具，如Jenkins-x、Gitkube，它提供了從代碼提交、自動編譯、打包鏡像、配置注入、發布部署到Kubernetes平臺的一系列自動化流程。 甚至出現了像ballerina這樣的云原生編程語言，它的出現就是為了解決應用開發到服務集成之間的鴻溝的。它有以下幾個特點。  - 使用云原生語義的DSL - 注解式配置 - 序列圖式操作 - 支持微服務的治理 要完成云的集成CI/CD，或者用一個詞代替來說就是GitOps的需求越來越強烈。  ### Kubernetes沒有做什么 看下這張圖中的兩個服務，它們使用的是kube-proxy里基于iptables的原生的負載均衡，并且服務間的流量也沒有任何控制。  Kubernetes缺少的最重要的一個功能就是微服務的治理，微服務比起單體服務來說使得部署和運維起來更加復雜，對于微服務的可觀測性也有更高的要求，同時CI/CD流程Kubernetes本身也沒有提供。 ## Service Mesh Service Mesh是一個專用的基礎設施層，它能夠將微服務的治理層應用層下沉到基礎設施層，將原來開發人員很多活給分擔出去，讓開發人員更注重業務邏輯和應用的性能本身，將服務治理的能力交給平臺來解決。使用Service Mesh能夠提供安全的服務間通訊、在服務間通訊應用各種策略實現灰度發布、流量切分等功能，它還能適配多語言，讓微服務應用無感知的遷移到云原生。 這是Istio在Kubenetes中創建的各種CRD，這些CRD有些是作為路由策略、有些是做監控指標和權限控制的。 這是Istio Service Mesh的架構圖。  - Pilot：提供用戶接口，用戶可以通過該接口配置各種路由規則，Pilot還可以通過適配器獲取平臺上各種服務之間的管理，Evnoy這個使用Sidecar方式部署到每個應用pod中的進程會通過Pilot中的Envoy API獲得平臺上各個服務之間的管理，同時也會應用用戶配置的路由規則。 - Mixer：獲取各種平臺屬性，服務間通訊時會先訪問Mixer兼容各平臺的屬性信息，如quota、訪問控制和策略評估，將服務間的訪問信息記錄后上報到mixer形成遙測報告。 - 每個Pod上還有SA和SPIFFE做權限管控。 Service Mesh實際上為了解決社會分工問題，它本身是為了解決微服務的治理。  Pilot和控制平面是為了運維人員準備的。 數據平面是為開發人員準備的。 Isito在每個上下游服務之間部署一個Envoy，Envoy中有幾個基本的服務發現服務，監聽器即Envoy要轉發的流量端口，Endpoint是要轉發的目的地，Cluster是一系列Endpoint用來做負載均衡，Route是定義各種路由規則，每個Envoy進程里可以設置多個Listener。  --- 本文根據 [Jimmy Song](https://jimmysong.io) 于2018年5月20日在[第四屆南京全球技術周](http://njsd-china.org/)上【互聯網技術專場】上的題為【云原生應用的下一站】的演講的部分內容的文字整理而成。