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