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