一文带你理解云原生
作者：William 孟祥龍，騰訊 CDG 系統(tǒng)架構(gòu)師，從事云原生技術(shù)賦能金融科技。
本文是一篇云原生的關(guān)鍵知識(shí)科普，希望給大家提供一扇云原生的“窗戶”，傳達(dá)三個(gè)目標(biāo)：1、透過(guò)窗戶看到一棵大樹(shù)代表：云原生的藍(lán)圖全貌；2、樹(shù)上會(huì)有很多核心樹(shù)干代表：云原生的關(guān)鍵技術(shù)；3、希望樹(shù)干上能摘到果實(shí)代表：云原生對(duì)我的啟發(fā)。
開(kāi)始閱讀文章前，請(qǐng)角色切換：設(shè)想你作為一位中小型 IT 公司 CTO，面對(duì)云原生技術(shù)決策，你需要回答兩個(gè)問(wèn)題：
1、為什么需要上云？
2、上云有何弊端？
作為一家公司的技術(shù)決策者，必須理解上云的利與弊，并結(jié)合公司各階段發(fā)展目標(biāo)給出最適合的技術(shù)方案。
1 云原生-概述
1.1 云原生-定義
云原生的定義，業(yè)界也是“百家爭(zhēng)鳴”各持觀點(diǎn)，從技術(shù)視角理解云原生會(huì)相對(duì)清晰。云原生的關(guān)鍵技術(shù)包括：
? 微服務(wù)架構(gòu)：服務(wù)與服務(wù)之間通過(guò)高內(nèi)聚低耦合的方式交互；
? 容器：作為微服務(wù)的最佳載體，提供了一個(gè)自包含的打包方式；
? 容器編排：解決了微服務(wù)在生產(chǎn)環(huán)境的部署問(wèn)題；
? 服務(wù)網(wǎng)絡(luò)：作為基礎(chǔ)設(shè)施，解決了服務(wù)之間的通信；
? 不可變基礎(chǔ)：設(shè)施提升發(fā)布效率，方便快速擴(kuò)展；
? 聲明式 API:讓系統(tǒng)更加健壯；
命令式 API：可以直接發(fā)出讓服務(wù)器執(zhí)行的命令，例如：“運(yùn)行容器”、”停止容器”等；
聲明式 API：可以聲明期望的狀態(tài)，系統(tǒng)將不斷地調(diào)整實(shí)際狀態(tài)，直到與期望狀態(tài)保持一致。
? DevOps：縮短研發(fā)周期，增加部署頻率，更安全地方便：
Culture ：達(dá)成共識(shí)
Automation：基礎(chǔ)設(shè)施自動(dòng)化
Measurement：可度量
Sharing：你中有我，我中有你
【私人觀點(diǎn)】
云原生的定義：應(yīng)用因云而生，即云原生。
應(yīng)用原生被設(shè)計(jì)為在云上以最佳方式運(yùn)行，充分發(fā)揮云的優(yōu)勢(shì)，是上云的最短路徑。
1.2 云原生-技術(shù)生態(tài)
1.3 云原生-關(guān)鍵技術(shù)
云原生關(guān)鍵技術(shù)包括：微服務(wù)，容器，容器編排，服務(wù)網(wǎng)絡(luò)，不可變基礎(chǔ)，聲明式 API。
1.3.1 微服務(wù)
微服務(wù)是一種用于構(gòu)建應(yīng)用的架構(gòu)方案。
將一個(gè)復(fù)雜的應(yīng)用拆分成多個(gè)獨(dú)立自治的服務(wù)，服務(wù)與服務(wù)間通過(guò)“高內(nèi)聚低耦合”的形式交互。
微服務(wù)典型架構(gòu)包括：
服務(wù)重構(gòu)：單體改造成符合業(yè)務(wù)的微服務(wù)架構(gòu)；
服務(wù)注冊(cè)與發(fā)現(xiàn)：微服務(wù)模塊間的服務(wù)生命周期管理；
服務(wù)網(wǎng)關(guān)：身份認(rèn)證、路由服務(wù)、限流防刷、日志統(tǒng)計(jì)；
服務(wù)通信：通信技術(shù)方案如，RPC vs REST vs 異步消息；
可靠性：服務(wù)優(yōu)雅降級(jí)，容災(zāi)，熔斷，多副本。
1.3.2?容器
容器是一種打包應(yīng)用的方式，可以打包應(yīng)用中的所有軟件和軟件所依賴的環(huán)境，并可實(shí)現(xiàn)跨平臺(tái)部署。
容器關(guān)鍵技術(shù)：namespac 視圖隔離，cgroups 資源隔離 ，Union File System 聯(lián)合文件系統(tǒng)。
容器優(yōu)勢(shì)：
更高效的利用資源；
更快速的啟動(dòng)時(shí)間；
一致性的運(yùn)行環(huán)境。
1.3.3 容器編排
容器編排包括：自動(dòng)化管理和協(xié)調(diào)容器的系統(tǒng)，專注于容器的生命周期管理和調(diào)度。
核心功能：
容器調(diào)度：依據(jù)策略完成容器與母機(jī)綁定；
資源管理：CPU、MEM、GPU、Ports、Device；
服務(wù)管理：負(fù)載均衡、健康檢查。
1.3.4 服務(wù)網(wǎng)格
服務(wù)網(wǎng)格（Service Mesh）是致力于解決服務(wù)間通訊的基礎(chǔ)設(shè)施層。
Service Mesh 應(yīng)對(duì)云原生應(yīng)用的復(fù)雜服務(wù)拓?fù)?#xff0c;提供可靠的通信傳遞；
通過(guò)一組輕量級(jí)網(wǎng)絡(luò)代理（Sidecar proxy），與應(yīng)用程序代碼部署在一起來(lái)實(shí)現(xiàn)，且對(duì)應(yīng)用程序透明。
Service Mesh 特點(diǎn)：
應(yīng)用程序間通訊的中間層；
輕量級(jí)網(wǎng)絡(luò)代理，應(yīng)用程序無(wú)感知；
解耦應(yīng)用的重試、監(jiān)控、追蹤、服務(wù)發(fā)現(xiàn)。
Service Mesh 主流組件：Istio、MOSN（Modular Open Smart Network）Linkerd。
1.3.5 不可變基礎(chǔ)設(shè)施
不可變基礎(chǔ)設(shè)施（Immutable Infrastructure）（寵物 VS 牲畜）
任何基礎(chǔ)設(shè)施實(shí)例（服務(wù)器、容器等各種軟硬件）一旦創(chuàng)建之后便成為一種只讀狀態(tài)，不可對(duì)其進(jìn)行任何更改；
如果需要修改或升級(jí)實(shí)例，唯一方式是創(chuàng)建一批新實(shí)例以替換。
不可變基礎(chǔ)設(shè)施的優(yōu)勢(shì)
提升發(fā)布應(yīng)用效率；
沒(méi)有雪花服務(wù)器；
快速水平擴(kuò)展。
1.3.6 聲明式 API
命令式 API：可直接發(fā)出讓服務(wù)器執(zhí)行的命令，例如：“運(yùn)行容器”、“停止容器”等；
聲明式 API：可聲明期望的狀態(tài)，系統(tǒng)將不斷地調(diào)整實(shí)際狀態(tài)，直到與期望狀態(tài)保持一致。
為什么聲明式使系統(tǒng)更加健壯？
可以類比理解成自動(dòng)化工程學(xué)的閉環(huán)自適應(yīng)模型。
1.3.7?DevOps
DevOps 目標(biāo) ：縮短開(kāi)發(fā)周期，增加部署頻率，更可靠地發(fā)布。
從歷史上開(kāi)發(fā)和運(yùn)維相對(duì)孤立到開(kāi)發(fā)和運(yùn)維之間建立合作，可以增加信任，更快速地發(fā)布新版本。
DevOps 是一組過(guò)程，方法和系統(tǒng)的統(tǒng)稱包括：
Culture：
文化是 DevOps 中的第一成功要素。
由于目標(biāo)不同，開(kāi)發(fā)和運(yùn)維形成一堵墻，DevOps 通過(guò)建立開(kāi)發(fā)和運(yùn)維之間合作和溝通的文化來(lái)消除墻。
Automation：
自動(dòng)化軟件的開(kāi)發(fā)和交付，通常包含持續(xù)集成，持續(xù)交付和持續(xù)部署，云原生時(shí)代還包括基礎(chǔ)架構(gòu)的自動(dòng)化，即 IaC(Infrastructureas code)。
Measurement：
度量尤其重要，通過(guò)客觀的測(cè)量來(lái)確定正在發(fā)生的事情的真實(shí)性，驗(yàn)證是否按預(yù)期進(jìn)行改變。并為不同職能部門達(dá)成一致建立客觀基礎(chǔ)。
Sharing：
開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)之間長(zhǎng)期存在摩擦的主要原因是缺乏共同的基礎(chǔ)。
開(kāi)發(fā)參與運(yùn)維值班，參與軟件的部署和發(fā)布，運(yùn)維參與架構(gòu)設(shè)計(jì)。
2 容器-Docker
2.1 Docker 概述
為什么學(xué)習(xí)容器技術(shù)?
云時(shí)代從業(yè)者：Docker 已成云平臺(tái)運(yùn)行分布式、微服務(wù)化應(yīng)用的行業(yè)標(biāo)準(zhǔn)。
作為有技術(shù)追求的程序員，有必要理解云原生的關(guān)鍵技術(shù)：容器。
Docker 核心概念：鏡像、容器、倉(cāng)庫(kù)。
鏡像(Image)：
一個(gè)只讀模板；
由一堆只讀層（read-only layer）重疊；
統(tǒng)一文件系統(tǒng)（UnionFileSystem）整合成統(tǒng)一視角。
容器(Container)：
通過(guò)鏡像創(chuàng)建的相互隔離的運(yùn)行實(shí)例；
容器與鏡像區(qū)別：最上面那一層可讀可寫層；
運(yùn)行態(tài)容器定義：一個(gè)可讀寫的統(tǒng)一文件系統(tǒng)，加上隔離的進(jìn)程空間，以及包含在其中的應(yīng)用進(jìn)程。
倉(cāng)庫(kù)（Repository）：
集中存放鏡像文件的地方；
Docker Registry 可包含多個(gè)倉(cāng)庫(kù)（Repository），每個(gè)倉(cāng)庫(kù)可包含多個(gè)標(biāo)簽（Tag），每個(gè)標(biāo)簽對(duì)應(yīng)一個(gè)鏡像。
2.2 Docker 關(guān)鍵技術(shù)
2.2.1 Namespace 視圖隔離
Linux namespace 是一種內(nèi)核級(jí)別的環(huán)境隔離機(jī)制，使得其中的進(jìn)程好像擁有獨(dú)立的系統(tǒng)環(huán)境。
Network namespace 在 Linux 中創(chuàng)建相互隔離的網(wǎng)絡(luò)視圖，每個(gè)網(wǎng)絡(luò)名字空間都有自己獨(dú)立的網(wǎng)絡(luò)配置，包括：網(wǎng)絡(luò)設(shè)備、路由表、IPTables 規(guī)則，路由表、網(wǎng)絡(luò)協(xié)議棧等。（默認(rèn)操作是主機(jī)默認(rèn)網(wǎng)絡(luò)名字空間）
2.2.2 control groups（資源隔離）
Linux Control Group 是內(nèi)核用于限制進(jìn)程組資源使用的功能。資源包括：CPU，內(nèi)存，磁盤 IO 等。
2.2.3 Union File System（聯(lián)合文件系統(tǒng)）
Union File System， 聯(lián)合文件系統(tǒng)：將多個(gè)不同位置的目錄聯(lián)合掛載(union mount)到同一個(gè)目錄下。
Docker 利用聯(lián)合掛載能力，將容器鏡像里的多層內(nèi)容呈現(xiàn)為統(tǒng)一的 rootfs(根文件系統(tǒng))；
Rootfs 打包整個(gè)操作系統(tǒng)的文件和目錄，是應(yīng)用運(yùn)行所需要的最完整的“依賴庫(kù)”。
2.3 Docker-網(wǎng)絡(luò)技術(shù)
Bridge 模式：Docker0 充當(dāng)網(wǎng)橋，在默認(rèn)情況下，被限制在 Network Namespace 里的容器進(jìn)程，是通過(guò) Veth Pair 設(shè)備 +宿主機(jī)網(wǎng)橋的方式，實(shí)現(xiàn)跟同其他容器的數(shù)據(jù)交換。
一旦一張?zhí)摂M網(wǎng)卡被“插”在網(wǎng)橋上，它就會(huì)變成該網(wǎng)橋的“從設(shè)備”。
從設(shè)備會(huì)被“剝奪”調(diào)用網(wǎng)絡(luò)協(xié)議棧處理數(shù)據(jù)包的資格，從而“降級(jí)”成為網(wǎng)橋上的一個(gè)端口。
而這個(gè)端口唯一的作用，就是接收流入的數(shù)據(jù)包，然后把這些數(shù)據(jù)包全部交給對(duì)應(yīng)的網(wǎng)橋，由網(wǎng)橋完成轉(zhuǎn)發(fā)或者丟棄。
Veth 提供一種連接兩個(gè) network namespace 的方法。Veth 是 Linux 中一種虛擬以太設(shè)備，總是成對(duì)出現(xiàn)常被稱為 Veth pair。
可以實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的虛擬連接，可看成一條連接兩張網(wǎng)卡的網(wǎng)線。一端網(wǎng)卡在容器的 Network Namespace 上，另一端網(wǎng)卡在宿主機(jī) Network Namespace 上。任何一張網(wǎng)卡發(fā)送的數(shù)據(jù)包，都可以對(duì)端的網(wǎng)卡上收到。
在物理網(wǎng)絡(luò)中，如果需要連接多個(gè)主機(jī)，會(huì)用交換機(jī)。在 Linux 中，能夠起到虛擬交換機(jī)作用的網(wǎng)絡(luò)設(shè)備，是網(wǎng)橋（Bridge）。它是一個(gè)工作在數(shù)據(jù)鏈路層的設(shè)備，主要功能是根據(jù) MAC 地址學(xué)習(xí)來(lái)將數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)橋的不同端口（Port）上。
Bridge 網(wǎng)橋類似交換機(jī)，兩個(gè)以上 namespace 接入同一個(gè)二層網(wǎng)絡(luò)。veth pair 一端虛擬網(wǎng)卡加入到 namespace，另一端到網(wǎng)橋上。
路由 routing是通過(guò)互聯(lián)的網(wǎng)絡(luò)把信息從源地址傳輸?shù)侥康牡刂返幕顒?dòng)，發(fā)生在 OSI 模型的第三層（網(wǎng)絡(luò)層）。Linux 內(nèi)核提供 IPForwarding 功能，實(shí)現(xiàn)不同子網(wǎng)接口間轉(zhuǎn)發(fā) IP 數(shù)據(jù)包。
路由器工作原理：
路由器上有多個(gè)網(wǎng)絡(luò)接口，每個(gè)網(wǎng)絡(luò)接口處于不同的三層子網(wǎng)上。
根據(jù)內(nèi)部路由轉(zhuǎn)發(fā)表將從一個(gè)網(wǎng)絡(luò)接口中收到的數(shù)據(jù)包轉(zhuǎn)發(fā)到另一個(gè)網(wǎng)絡(luò)接口，實(shí)現(xiàn)不同三層子網(wǎng)間互通。
3 容器編排-Kubernetes
3.1 概述&架構(gòu)&核心組件
我認(rèn)為 Kubernetes 最大成功：讓容器應(yīng)用進(jìn)入大規(guī)模工業(yè)生產(chǎn)。
Kubernetes 的提供特性，幾乎覆蓋一個(gè)分布式系統(tǒng)在生產(chǎn)環(huán)境運(yùn)行的所有關(guān)鍵事項(xiàng)。包括：
Automated rollouts and rollbacks(自動(dòng)化上線和回滾)
使用 Kubernetes 描述已部署容器的所需狀態(tài)，受控的速率將實(shí)際狀態(tài)更改為期望狀態(tài)。
Self-healing(自我修復(fù))
Kubernetes 重新啟動(dòng)失敗的容器、替換容器、殺死不響應(yīng)用戶定義的運(yùn)行狀況檢查的容器，并且在準(zhǔn)備好服務(wù)之前不將其通告給客戶端。
Service discovery and load balancing(服務(wù)發(fā)現(xiàn)與負(fù)載均衡)
Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開(kāi)容器，如果進(jìn)入容器的流量很大，Kubernetes 可以負(fù)載均衡并分配網(wǎng)絡(luò)流量，從而實(shí)現(xiàn)部署穩(wěn)定。
Storage orchestration(存儲(chǔ)編排)
Kubernetes 允許你自動(dòng)掛載選擇的存儲(chǔ)系統(tǒng)，例如本地存儲(chǔ)、公廠商等。
Automatic bin packing(自動(dòng)裝箱)
Kubernetes 允許指定每個(gè)容器所需 CPU 和內(nèi)存（RAM）。當(dāng)容器指定資源請(qǐng)求時(shí)，Kubernetes 可以做出更好的決策來(lái)管理容器的資源。
Secret and configuration management(安全和配置管理)
Kubernetes 允許存儲(chǔ)和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。你可在不重建容器鏡像的情況下部署和更新密鑰和應(yīng)用程序配置，也無(wú)需在堆棧配置中暴露密鑰。
API Service: Kubernetes 各組件通信中樞。
資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API 注冊(cè)和發(fā)現(xiàn)等機(jī)制；
為 Pod， Deployment， Service 等各種對(duì)象提供 Restful 接口；
與 etcd 交互的唯一組件。
Scheduler：負(fù)責(zé)資源調(diào)度，按照預(yù)定調(diào)度策略將 Pod 調(diào)度到相應(yīng)的機(jī)器。
Predicates(斷言)：淘汰制
Priorities（優(yōu)先級(jí)）：權(quán)重計(jì)算總分。
Controller manager：負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等。
etcd：分布式的 K-V 存儲(chǔ)，獨(dú)立于 Kubernetes 的開(kāi)源組件。
主要存儲(chǔ)關(guān)鍵的原數(shù)據(jù)，支持水平擴(kuò)容保障元數(shù)據(jù)的高可用性；
基于Raft 算法實(shí)現(xiàn)強(qiáng)一致性，獨(dú)特的watch 機(jī)制是 Kubernetes 設(shè)計(jì)的關(guān)鍵。
kubelet ：負(fù)責(zé)維護(hù) Pod 的生命周期，同時(shí)負(fù)責(zé) Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理。
kube-proxy：負(fù)責(zé)為 Service 提供 cluster 內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡
kube-proxy 通過(guò)在節(jié)點(diǎn)上添加 iptables 規(guī)則以及從中移除這些規(guī)則來(lái)管理此端口重新映射過(guò)程。
控制器模式的設(shè)計(jì)思想：
容器類比集裝箱，集裝箱固然好用，但是如果它各面光禿禿的，吊車還怎么把它吊起來(lái)擺放好呢？
Pod 對(duì)象其實(shí)就是容器的升級(jí)版，對(duì)容器進(jìn)行組合，添加更多屬性和字段。就好比在集裝箱上安裝了吊環(huán)，Kubernetes 這臺(tái)“吊車”可以更輕松操作容器。
然而Kubernetes 操作這些“集裝箱”的邏輯都是由控制器完成的。
Kubernetes 通過(guò)“控制器模式” 的設(shè)計(jì)思想，來(lái)統(tǒng)一編排各種對(duì)象和資源。
3.2 部署&資源控制&存儲(chǔ)
Kubernetes-集群部署架構(gòu)
所有組件通過(guò) kubelet staticpod 的方式啟動(dòng)保證宿主機(jī)各組件的高可用，systemd 提供 kubelet 的高可用；
每個(gè) Master 的使用 hostNetwork 網(wǎng)絡(luò)，controller-manager 和 scheduler 通過(guò) localhost 連接到本節(jié)點(diǎn) apiserver；
controller-manager 和 scheduler 的高可用通過(guò)自身提供的 leader 選舉功能（--leader-elect=true）；
apiserver 高可用，可通過(guò)經(jīng)典的 haporxy+keepalived 保證，集群對(duì)外暴露 VIP;
外部訪問(wèn)通過(guò) TLS 證書，在 LB 節(jié)點(diǎn)做 TLS Termination，LB 出來(lái) http 請(qǐng)求到對(duì)應(yīng) apiserver 實(shí)例。apiserver 到 kubelet、kube-proxy 類似。
3.3 Kubernetes-網(wǎng)絡(luò)技術(shù)
3.3.1 對(duì)外服務(wù)
Service是一個(gè)邏輯概念，一組提供相同功能 Pods 的邏輯集合，并提供四層負(fù)載統(tǒng)一入口和定義訪問(wèn)策略。
交互流程：Service 可通過(guò)標(biāo)簽選取后端服務(wù)。匹配標(biāo)簽的 Pod IP 和端口列表組成 endpoints，有 kube-proxy 負(fù)責(zé)均衡到對(duì)應(yīng) endpoint。
為什么需要 service？
對(duì)外提供入口（容器如何被外部訪問(wèn)）；
克服 Pod 動(dòng)態(tài)性（Pod IP 不一定可以穩(wěn)定依賴）；
服務(wù)發(fā)現(xiàn)和穩(wěn)定的服務(wù)（ Pod 服務(wù)發(fā)現(xiàn)、負(fù)載、高可用）。
Service Type 四種方式
Cluster IP：配置 endpoint 列表；
NodePort：默認(rèn)端口范圍：30000-32767，通過(guò) nodeIP：nodePort 訪問(wèn) ；
LoadBalancer：適用于公有云，云廠商實(shí)現(xiàn)負(fù)載，配置 LoadBalance 到 podIP ；
ExternalName：服務(wù)通過(guò) DNS CNAME 記錄方式轉(zhuǎn)發(fā)到指定的域名。
Service Type 為 Cluster IP：
Kubernetes 的默認(rèn)服務(wù)，配置 endpoint 列表，可以通過(guò) proxy 模式來(lái)訪問(wèn)該對(duì)應(yīng)服務(wù)；
類似通過(guò) Nginx 實(shí)現(xiàn)集群的 VIP。
Service Type 為 Node Port：
在集群所有節(jié)點(diǎn)上開(kāi)放特定端口，任何發(fā)送到該端口流量借助 Service 的 Iptables 規(guī)則鏈發(fā)送到后端 Pod。
注意事項(xiàng)：
每個(gè)服務(wù)對(duì)應(yīng)一個(gè)端口，端口范圍只有 30000–32767；
需要感知和發(fā)現(xiàn)節(jié)點(diǎn)變化，流量轉(zhuǎn)發(fā)增加 SNAT 流程，Iptables 規(guī)則會(huì)成倍增長(zhǎng)。
適用場(chǎng)景：服務(wù)高可用性要求不高或成本不敏感，例如：樣例服務(wù)或臨時(shí)服務(wù)。
Service Type 為 Load Balancer：
對(duì)公網(wǎng)暴露服務(wù)建議采用此方式，Service 沒(méi)有對(duì)其行為做任何規(guī)范，依賴云廠商 LB 具體實(shí)現(xiàn)（云廠商收費(fèi)服務(wù)）如：騰訊公有云：CLB。
Service Type 為 External Name ：
DNS 作為服務(wù)發(fā)現(xiàn)機(jī)制，在集群內(nèi)提供服務(wù)名到 Cluster IP 的解析。
CoreDNS ：DNS 服務(wù)，CNCF 第 04 個(gè)畢業(yè)項(xiàng)目，KUBERNETES 的 1.11 版本已支持。
CoreDNS 實(shí)現(xiàn)的高性能、插件式、易擴(kuò)展的 DNS 服務(wù)端，支持自定義 DNS 記錄及配置 upstream DNS Server，可以統(tǒng)一管理 Kubernetes 基于服務(wù)的內(nèi)部 DNS。
Ingress Controller：定義入流量規(guī)則，可做七層 HTTP 負(fù)載君合。
Egress Controller：定義出流量規(guī)則。
交互流程：通過(guò)與 Kubernetes API 交互，動(dòng)態(tài)感知集群 Ingress 規(guī)則，按照自定義的規(guī)則生成（負(fù)載均衡器）配置文件，并通過(guò) reload 來(lái)重新加載。
3.3.2 Underlay 與 Overlay 網(wǎng)絡(luò)
Underlay 網(wǎng)絡(luò)模式: 底層承載網(wǎng)絡(luò)，是網(wǎng)絡(luò)通信的基礎(chǔ)。
優(yōu)勢(shì)：復(fù)用基建，網(wǎng)絡(luò)扁平，性能優(yōu)勢(shì)；
劣勢(shì)：協(xié)作復(fù)雜，安全問(wèn)題，管理成本。
很多場(chǎng)景下業(yè)務(wù)方希望容器、物理機(jī)和虛擬機(jī)可以在同一個(gè)扁平面中直接通過(guò) IP 進(jìn)行通信，通過(guò) Floating-IP 網(wǎng)絡(luò)實(shí)現(xiàn)。
Floating-IP 模式將宿主機(jī)網(wǎng)絡(luò)同一網(wǎng)段的 IP 直接配置到容器中。
這種模式為了保證容器與宿主機(jī)的交換機(jī)二層連通，需要在物理機(jī)上搭一個(gè)虛擬網(wǎng)橋。具體選擇哪種網(wǎng)橋，主流有：Linux bridge、MacVlan、SRIOV 三種模式。
BridgeBridge：設(shè)備內(nèi)核最早實(shí)現(xiàn)的網(wǎng)橋，性能與 OVS 相當(dāng)，可以使用到所有場(chǎng)景；
MacVlan：一個(gè)簡(jiǎn)化版的 bridge 設(shè)備，為了隔離需要內(nèi)核，實(shí)現(xiàn)時(shí)不允許 MacVlan 容器訪問(wèn)其宿主機(jī) IP 和 ServiceCluster IP；
SR-IOV 技術(shù)：一種基于硬件的虛擬化解決方案，可提高性能和可伸縮性；
SR-IOV 標(biāo)準(zhǔn)允許在虛擬機(jī)之間高效共享 PCIe（快速外設(shè)組件互連）設(shè)備，并且它是在硬件中實(shí)現(xiàn)的，可以獲得能夠與本機(jī)性能媲美的 I/O 性能。
Overlay 網(wǎng)絡(luò)：是一種建立在另一網(wǎng)絡(luò)之上的計(jì)算機(jī)網(wǎng)絡(luò)。
優(yōu)勢(shì)：獨(dú)立自治，快速擴(kuò)展，網(wǎng)絡(luò)策略；
劣勢(shì)：復(fù)雜層級(jí)，性能損失，定制成本。
Kubernetes 相當(dāng)于云原生的操作系統(tǒng)。
有人會(huì)問(wèn)，憑什么云原生的操作系統(tǒng)這桿大旗？
主要原因是：Kubernetes 解決了一個(gè)分布式操作系統(tǒng)最核心的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)三種資源。
CNI 容器網(wǎng)絡(luò)統(tǒng)一標(biāo)準(zhǔn)：
CNCF 項(xiàng)目，為 Linux 容器提供配置網(wǎng)絡(luò)接口的標(biāo)準(zhǔn)和以該標(biāo)準(zhǔn)擴(kuò)展插件提供基礎(chǔ)函數(shù)庫(kù)；
CNI 命令行調(diào)用規(guī)范，其插件在主機(jī)上直接切換進(jìn)入容器網(wǎng)絡(luò)命名空間，為容器創(chuàng)建網(wǎng)絡(luò)設(shè)備，配置 IP，路由信息。
CNI 規(guī)范內(nèi)容：
輸入：ADD/DEL 控制指令，CNI 目錄，容器 ID，網(wǎng)絡(luò)命名空間，網(wǎng)卡名稱。
配置文件：標(biāo)準(zhǔn)部分：cniVersion，Name，Type，IPAM。
輸出：設(shè)備列表、IP 資源列表、DNS 信息。
插件應(yīng)用如：
Bridge：Linux 網(wǎng)橋 CNI 實(shí)現(xiàn)，采用網(wǎng)卡對(duì)鏈接網(wǎng)橋和容器；
Host-device：將主機(jī)設(shè)備直接移動(dòng)到容器命名空間中；
PTP：創(chuàng)建虛擬網(wǎng)卡對(duì)，采用路由方式實(shí)現(xiàn)對(duì)外互聯(lián)；
MacVlan：網(wǎng)卡多 Mac 地址虛擬技術(shù)完整支持 vlan；
Vlan：Vlan 設(shè)備 CNI 實(shí)現(xiàn)，允許容器和主機(jī)分屬不同 LAN；
IPVlan：網(wǎng)卡上基于 IP 實(shí)現(xiàn)流量轉(zhuǎn)發(fā)。
3.3.3 Overlay 網(wǎng)絡(luò)-Flannel 方案
CoreOS（被 Red Hat 收購(gòu)）為 Kubernetes 專門定制設(shè)計(jì)的 overlay 網(wǎng)絡(luò)方案。
03 層網(wǎng)絡(luò)方案實(shí)現(xiàn)：在每臺(tái)主機(jī)部署 flanneld 進(jìn)程實(shí)現(xiàn)網(wǎng)段分配，路由控制，采用多種轉(zhuǎn)發(fā)機(jī)制實(shí)現(xiàn)流量跨機(jī)交互。
Flannel 職責(zé)
子網(wǎng)管理：每個(gè)主機(jī)分配唯一的子網(wǎng)；
互聯(lián)方式：為同 Overlay 平面容器分配唯一 IP。
Etcd 存儲(chǔ)：容器之間路由映射；
SubNetManager：子網(wǎng)資源劃分、IP 資源申請(qǐng)釋放的接口定義；
Backend：針對(duì)網(wǎng)絡(luò)互聯(lián)方式的接口定義。
UDP，UDP 封包轉(zhuǎn)發(fā)，建議僅調(diào)試使用；
VxLAN(建議)，使用內(nèi)核 vxlan 特性實(shí)現(xiàn)封包轉(zhuǎn)發(fā)；
Host-GW，主機(jī) 2 層互聯(lián)情況下較高性能互聯(lián)方式；
IPIP，使用 IPIP 隧道完成封包和轉(zhuǎn)發(fā)；
IPSec，使用 IPSecurity 實(shí)現(xiàn)加密封包轉(zhuǎn)發(fā)；
AliVPC，對(duì)接阿里云 VPC 路由表實(shí)現(xiàn)網(wǎng)絡(luò)互聯(lián)；
AWSVPC，對(duì)接 Amazon VPC 路由表實(shí)現(xiàn)網(wǎng)絡(luò)互聯(lián)。
Flannel 的單機(jī)互聯(lián)方案：
子網(wǎng)分配：充當(dāng)虛擬交換機(jī)/網(wǎng)關(guān)角色，連接所有本機(jī)容器，完成虛擬子網(wǎng)構(gòu)建；
Bridge：通過(guò) NAT 借助主機(jī)網(wǎng)絡(luò)實(shí)現(xiàn)外部服務(wù)訪問(wèn)；
Veth pair：一端設(shè)置到容器網(wǎng)絡(luò) namespace，一端鏈接 bridge 實(shí)現(xiàn)容器接入網(wǎng)絡(luò)；
對(duì)外訪問(wèn)：為每個(gè)節(jié)點(diǎn)分配獨(dú)立不沖突的 24 位子網(wǎng)。
Overlay 解決方案：跨 Node 的 Pod 之間通信通過(guò) Node 之間的 Overlay 隧道。
職責(zé)：路由控制，數(shù)據(jù)轉(zhuǎn)發(fā)。
主要流程：
本節(jié)點(diǎn)設(shè)置：設(shè)備創(chuàng)建、本地路由創(chuàng)建、回寫本地信息；
監(jiān)聽(tīng)其他節(jié)點(diǎn)信息：更新 ARP 信息、更新 FDB、更新路由信息。
3.3.4 Overlay 網(wǎng)絡(luò)-Calico 方案
Calico 項(xiàng)目：是純?nèi)龑拥奶摂M網(wǎng)絡(luò)解決方案，旨在簡(jiǎn)化、擴(kuò)展和保護(hù)云網(wǎng)絡(luò)的容器方案。
Calico 優(yōu)勢(shì)：
可擴(kuò)展性：采用 IP 路由支持大規(guī)模網(wǎng)絡(luò)。擴(kuò)展便利，容錯(cuò)性高；
網(wǎng)絡(luò)安全：支持 Kubernetes 網(wǎng)絡(luò)策略，支持自定義網(wǎng)絡(luò)策略；
廣泛集成：集成 Kubernetes ，Mesos，支持 OpenStack，AWS，GCE，Azure。
Calico 不足：
BGP 支持問(wèn)題：需要網(wǎng)路設(shè)備支持 BGP 協(xié)議，否則需要追加 IPIP 隧道；
規(guī)劃 2 層直連：需要節(jié)點(diǎn)做良好的規(guī)劃實(shí)現(xiàn) 2 層網(wǎng)絡(luò)直接互聯(lián)；
大規(guī)模配置復(fù)雜：網(wǎng)絡(luò)規(guī)劃，手動(dòng)部署 Route Reflector，增加 API 代理。
關(guān)鍵組件：
BGP Client：和其他節(jié)點(diǎn)互聯(lián)，發(fā)布當(dāng)前節(jié)點(diǎn)路由并學(xué)習(xí)其他節(jié)點(diǎn)路由；
Confd：同步節(jié)點(diǎn)配置信息啟動(dòng) BGPClient；
Felix：負(fù)責(zé)虛擬設(shè)備監(jiān)控，ACL 控制、狀態(tài)同步的 agent；
Calico：CNI 插件，負(fù)責(zé)容器設(shè)備創(chuàng)建；
Calico-IPAM：CNI 插件，負(fù)責(zé)容器網(wǎng)段管理與 IP 地址管理；
RouteReflector：對(duì)接 BGPclient 實(shí)現(xiàn)路由中轉(zhuǎn)；
Etcd/Kube-apiserver：Calico 數(shù)據(jù)存儲(chǔ)；
typha：應(yīng)對(duì)大規(guī)模節(jié)點(diǎn)接入時(shí)作為數(shù)據(jù)緩存 proxy；
RouteReflector 安裝：集群超過(guò)100 個(gè)節(jié)點(diǎn)時(shí)強(qiáng)烈建議啟用，通過(guò) RR 中轉(zhuǎn)全局路由信息。
Calico 單機(jī)互聯(lián)方案：
Veth-pair：一端設(shè)置到容器，一端放置在主機(jī)上，為容器提供網(wǎng)絡(luò)出入口；
路由策略：針對(duì) IP 和設(shè)備設(shè)置路由條目，在主機(jī)上實(shí)現(xiàn)互聯(lián)。
Calico 跨機(jī)互聯(lián)方案：
同網(wǎng)段/BGP 支持：主機(jī)之間通過(guò) 2 層直連或者網(wǎng)絡(luò)支持路由轉(zhuǎn)發(fā)至目標(biāo)主機(jī)；
跨網(wǎng)段 IPIP 互聯(lián)：網(wǎng)絡(luò)設(shè)備不支持 BGP 協(xié)議情況下，采用 IPIP 隧道實(shí)現(xiàn)跨網(wǎng)段互聯(lián)；
跨網(wǎng)段 VxLAN 互聯(lián)（Cannel）：集成 flannel，底層通過(guò) VxLAN 實(shí)現(xiàn)跨機(jī)轉(zhuǎn)發(fā)。
4 服務(wù)網(wǎng)格 Istio
4.1 服務(wù)網(wǎng)格概述
4.2 Istio 控制面
4.3 Istio 數(shù)據(jù)面
5 云原生-主流組件
5.1 Prometheus
5.2 Grafana
5.3 Elasticsearch + Fluentd + Kibana
5.4 Jaeger
5.5 Chaos Engineering
6 云原生-常用網(wǎng)絡(luò)技術(shù)
6.1 主機(jī)網(wǎng)絡(luò)
iptables是運(yùn)行在用戶空間的應(yīng)用軟件，通過(guò)控制Linux 內(nèi)核 netfilter，來(lái)管理網(wǎng)絡(luò)數(shù)據(jù)包的處理和轉(zhuǎn)發(fā)。
存在“表（tables）”、“鏈（chain）”和“規(guī)則（rules）”三個(gè)層面：
每個(gè)“表”指的是不同類型的數(shù)據(jù)包處理流程，例如 filter 表表示進(jìn)行數(shù)據(jù)包過(guò)濾，而 NAT 表針對(duì)連接進(jìn)行地址轉(zhuǎn)換操作；
每個(gè)表中又可以存在多個(gè)“鏈”，系統(tǒng)按照預(yù)訂的規(guī)則將數(shù)據(jù)包通過(guò)某個(gè)內(nèi)建鏈，例如將從本機(jī)發(fā)出的數(shù)據(jù)通過(guò) OUTPUT 鏈；
在“鏈”中可以存在若干“規(guī)則”，這些規(guī)則會(huì)被逐一進(jìn)行匹配，如果匹配，可以執(zhí)行相應(yīng)的動(dòng)作，例如修改數(shù)據(jù)包，或者跳轉(zhuǎn)。
6.2 Underlay 網(wǎng)絡(luò)技術(shù)
VLAN 虛擬局域網(wǎng)：是將一個(gè)物理 LAN 在邏輯上劃分成多個(gè)廣播域的通信技術(shù)。每個(gè) VLAN 是一個(gè)廣播域，VLAN 內(nèi)的主機(jī)間通信就和在一個(gè) LAN 內(nèi)一樣。
沒(méi)有劃分 VLAN：LAN 局域網(wǎng)：
優(yōu)勢(shì)：簡(jiǎn)單，靜態(tài)，IP 地址與交換機(jī)關(guān)聯(lián)；
劣勢(shì)：遷移域受限，不能機(jī)房?jī)?nèi)隨意遷移。交換機(jī)下 IP 需要提前規(guī)劃好，約束虛擬比。
劃分 VLAN：虛擬局域網(wǎng)：
優(yōu)勢(shì)：IP 地址與交換機(jī)無(wú)關(guān)，虛擬機(jī)可以在機(jī)房范圍內(nèi)遷移。VLAN 間則不能直接互通，這樣廣播報(bào)文就被限制在一個(gè) VLAN 內(nèi)。
有人會(huì)問(wèn)：交換如何區(qū)分不同 VLAN？
交換機(jī)能夠分辨不同 VLAN 的報(bào)文，需要在報(bào)文中添加標(biāo)識(shí) VLAN 信息的字段。數(shù)據(jù)幀中的VID（VLAN ID）字段標(biāo)識(shí)了該數(shù)據(jù)幀所屬的 VLAN，數(shù)據(jù)幀只能在其所屬 VLAN 內(nèi)進(jìn)行傳輸。
6.3 Overlay 網(wǎng)絡(luò)技術(shù)
VXLAN 虛擬擴(kuò)展局域網(wǎng)：
是對(duì)傳統(tǒng) VLAN 協(xié)議的一種擴(kuò)展；
是一種網(wǎng)絡(luò)虛擬化技術(shù)，試圖改善云計(jì)算部署的可擴(kuò)展性問(wèn)題。
解決哪些問(wèn)題？
vlan 的數(shù)量限制（12bit->24bit），VLAN 報(bào)文 Header 預(yù)留長(zhǎng)度只有 12bit，只支持 4096 個(gè)終端；
VNI（VXLAN Network Index）標(biāo)識(shí)某條指定隧道；
不改變 IP 實(shí)現(xiàn)服務(wù)器遷移。
傳統(tǒng)二三層網(wǎng)絡(luò)架構(gòu)限制了虛擬機(jī)的動(dòng)態(tài)遷移范圍。
VXLAN 在兩臺(tái) TOR 交換機(jī)之間建立一條隧道，將服務(wù)器發(fā)出的原始數(shù)據(jù)幀加以“包裝”，好讓原始報(bào)文可以在承載網(wǎng)絡(luò)（比如 IP 網(wǎng)絡(luò)）上傳輸。
當(dāng)?shù)竭_(dá)目的服務(wù)器所連接的 TOR 交換機(jī)后，離開(kāi) VXLAN 隧道，并將原始數(shù)據(jù)幀恢復(fù)出來(lái)，繼續(xù)轉(zhuǎn)發(fā)給目的服務(wù)器。VXLAN 將整個(gè)數(shù)據(jù)中心基礎(chǔ)網(wǎng)絡(luò)虛擬成了一臺(tái)巨大的“二層交換機(jī)”
VXLAN 網(wǎng)絡(luò)模型
UDP 封裝（L2 over L4）：將 L2 的以太幀封裝到 UDP 報(bào)文即（L2overL4）中，并在 L3 網(wǎng)絡(luò)中傳輸；
VTEP，VXLAN 隧道端點(diǎn)，對(duì) VXLAN 報(bào)文進(jìn)行封裝和解封裝；
VNI，VXLAN 隧道標(biāo)識(shí)，用于區(qū)分不同 VXLAN 隧道。
矢量性協(xié)議：使用基于路徑、網(wǎng)絡(luò)策略或規(guī)則集來(lái)決定路由；
AS（自治域）：AS 是指在一個(gè)實(shí)體管轄下的擁有相同選路策略的 IP 網(wǎng)絡(luò)；
BGP 網(wǎng)絡(luò)中的每個(gè) AS 都被分配一個(gè)唯一的 AS 號(hào)，用于區(qū)分不同的 AS；
eBGP（域外 BGP）：運(yùn)行于不同 AS 之間的 BGP，為了防止 AS 間產(chǎn)生環(huán)路；
為了防止 AS 間產(chǎn)生環(huán)路，當(dāng) BGP 設(shè)備接收 EBGP 對(duì)等體發(fā)送的路由時(shí)，會(huì)將帶有本地 AS 號(hào)的路由丟棄；
iBGP（域內(nèi) BGP）：運(yùn)行于同一 AS 內(nèi)部的 BGP，為了防止 AS 內(nèi)產(chǎn)生環(huán)路；
RR（路由反射器）：通過(guò)集中反射同步，解決全連通的網(wǎng)狀網(wǎng)格結(jié)構(gòu)路由同步問(wèn)題。
EBGP+IBGP 實(shí)現(xiàn) AS 間的路由傳遞：一個(gè)常見(jiàn)的 IP 骨干網(wǎng)的拓?fù)浣Y(jié)構(gòu)，骨干層和匯聚層分別是兩個(gè)自治系統(tǒng)，AS100 有兩個(gè)出口設(shè)備 SwitchC 和 SwitchD，兩個(gè) AS 之間需要進(jìn)行路由互通。
7 總結(jié)-云原生
云原生應(yīng)用：docker 應(yīng)用打包、發(fā)布、運(yùn)行，Kubernetes 服務(wù)部署和集群管理，Istio 構(gòu)建服務(wù)治理能力。
云計(jì)算以“資源”為中心，關(guān)鍵技術(shù)：
虛擬化：SDX，NFV；
資源池化：彈性快速擴(kuò)縮容；
多租化：提升云廠商的資源利用率；
典型代表：計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)三大基礎(chǔ)設(shè)施的云化。
云計(jì)算以“應(yīng)用”為中心，關(guān)鍵導(dǎo)向：
設(shè)計(jì)之初，關(guān)注更好適應(yīng)云，充分發(fā)揮云優(yōu)勢(shì)；
云原生已成為企業(yè)數(shù)字創(chuàng)新的最短路徑；
云原生一系列 IAAS、PAAS、SAAS 層技術(shù)，支撐產(chǎn)品高效交付、穩(wěn)定運(yùn)維、持續(xù)運(yùn)營(yíng)。
【私人觀點(diǎn)】
以“資源”為中心的云，將成為“底層基礎(chǔ)設(shè)施”，利用云原生以“應(yīng)用”為中心賦能自身業(yè)務(wù)；
云的時(shí)代，已經(jīng)來(lái)臨。作為云的使用者、從業(yè)者，更多思考如何利用云賦能業(yè)務(wù)產(chǎn)品；
商業(yè)市場(chǎng)模式從“大魚吃小魚”靠信息不對(duì)稱，向“快魚吃慢魚”轉(zhuǎn)變。我們必須利用趨勢(shì)，擁抱云原生。
8 鳴謝
以下小伙伴給出寶貴建議，非常感謝。
鳴謝 CDG-FiT 線：Hawkliu、Cafeeqiu
鳴謝騰訊 OTeam：Kubernetes 開(kāi)源協(xié)同技術(shù)講師
9 學(xué)習(xí)資料
《SRE Google 運(yùn)維解密》
《Kubernetes 權(quán)威指南》
《Kubernetes in Action》
《深入剖析 Kubernetes》
《Docker 容器與容器云》-浙大
《云原生服務(wù)網(wǎng)格 Istio》華為叢書
《Kubernetes 開(kāi)源協(xié)同技術(shù)課程》
CNCF 官網(wǎng)：https：//www.cncf.io/
Huawei-Cloud Native : https：//github.com/huawei-cloudnative
Docker 官方文檔：https：//docs.docker.com/
Kubernetes 官網(wǎng)：https：//kubernetes.io/
Istio 官網(wǎng)：https：//istio.io/
10 英雄帖
歡迎對(duì) 云原生或金融科技 感興趣的小伙伴隨時(shí)交流，更歡迎加入我們團(tuán)隊(duì)。
郵箱地址：williammeng@tencent.com
視頻號(hào)最新視頻
總結(jié)
- 上一篇： 效能优化实践：C/C++单元测试万能插桩
- 下一篇： NCMMSC2021喊你开赛！汉语长短视