剛開(kāi)始接觸容器集群的人會(huì)發(fā)現(xiàn)，與在單節(jié)點(diǎn)上使用容器相比，容器集群一個(gè)很復(fù)雜的領(lǐng)域就是網(wǎng)絡(luò)。Kubernetes 作為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，對(duì)容器集群的網(wǎng)絡(luò)進(jìn)行了合理抽象，并開(kāi)放了容器網(wǎng)絡(luò)標(biāo)準(zhǔn) CNI，供各公司根據(jù)自身應(yīng)用場(chǎng)景和底層基礎(chǔ)設(shè)施選用開(kāi)源方案或者自行實(shí)現(xiàn)一套網(wǎng)絡(luò)插件。本文主要介紹騰訊云容器平臺(tái)針對(duì)私有化不同場(chǎng)景的一些網(wǎng)絡(luò)方案實(shí)踐。

本文6128字，約16分鐘。

Kubernetes網(wǎng)絡(luò)架構(gòu)

Kubernetes 沒(méi)有提供網(wǎng)絡(luò)模型供用戶直接使用，而是開(kāi)放了容器網(wǎng)絡(luò)標(biāo)準(zhǔn)CNI。CNI 的目標(biāo)是用戶可以不再需要額外考慮如何建立 Pod 之間的連接，它規(guī)定所有 Pod 都必須在一個(gè)可以直接連通的扁平網(wǎng)絡(luò)空間中，并且每個(gè) Pod 都要有自己獨(dú)立的 IP。對(duì)此，Kubernetes 對(duì)容器網(wǎng)絡(luò)做出了如下要求：

1）所有容器都可以在不用 NAT 方式的情況下和其他的容器通信。

2）所有節(jié)點(diǎn)都可以在不用 NAT 方式的情況下和其他的容器通信。

3）容器自己看的地址和別人看到的地址是同一個(gè)地址。

針對(duì)上述的網(wǎng)絡(luò)要求，Kubernetes 設(shè)計(jì)了 Pod-Workload-Service-Ingress 這樣的服務(wù)發(fā)現(xiàn)機(jī)制。并且業(yè)界實(shí)現(xiàn) CNI 網(wǎng)絡(luò)標(biāo)準(zhǔn)也開(kāi)源了很多企業(yè)級(jí)網(wǎng)絡(luò)解決方案，比如 Flannel 和 Calico。這些不同的方案有不同的應(yīng)用場(chǎng)景和要求，要根據(jù)實(shí)際需要進(jìn)行選擇。

綜合來(lái)說(shuō)所有的網(wǎng)絡(luò)方案可以分為 Overlay 和 Underlay 兩大類(lèi)，其中 Overlay 網(wǎng)絡(luò)在原始3層網(wǎng)絡(luò)的基礎(chǔ)上又封裝了一層虛擬的網(wǎng)絡(luò)，使得網(wǎng)絡(luò)包可以在 K8S 集群的不同節(jié)點(diǎn)中傳遞，這種方案不依賴于宿主機(jī)底層網(wǎng)絡(luò)架構(gòu)，用戶只需要了解基本的網(wǎng)絡(luò)知識(shí)就可以方便地進(jìn)行使用。不過(guò)這種方案一個(gè)明顯的缺點(diǎn)是性能較差，因?yàn)樵谠芯W(wǎng)絡(luò)的基礎(chǔ)上疊加了一層 Overlay 網(wǎng)絡(luò)，封包解包或者NAT 對(duì)網(wǎng)絡(luò)性能都有一定損耗。

Underlay 網(wǎng)絡(luò)是二層或三層的網(wǎng)絡(luò)方案。Calico 就是一個(gè)純?nèi)龑拥木W(wǎng)絡(luò)方案，它通過(guò)在 K8S 集群中使用 BGP 路由協(xié)議在不同節(jié)點(diǎn)中來(lái)分發(fā)各個(gè) Pod互聯(lián)的路由信息，使得Pod在整個(gè)集群中進(jìn)行通信。Underlay 網(wǎng)絡(luò)沒(méi)有解包封包和 NAT 的過(guò)程，性能很好。但是受宿主機(jī)網(wǎng)絡(luò)架構(gòu)的制約,不是所有場(chǎng)景都可以使用 Underlay 網(wǎng)絡(luò)，比如 Calico 就需要手動(dòng)配置路由、交換機(jī)需要支持BGP 協(xié)議等，而且它的上手成本較高。

Kubernetes網(wǎng)絡(luò)局限性

盡管 Kubernetes 提出了 Service 和 Ingress 等網(wǎng)絡(luò)概念，業(yè)界也開(kāi)源了很多 CNI 網(wǎng)絡(luò)插件，但是在實(shí)際應(yīng)用中很多人還是會(huì)感覺(jué)到 Kubernetes 的網(wǎng)絡(luò)功能比較匱乏，使用也不夠靈活。其網(wǎng)絡(luò)方案經(jīng)常受到一些公司傳統(tǒng)業(yè)務(wù)部門(mén)的挑戰(zhàn)，例如 Pod 網(wǎng)絡(luò)無(wú)法被外部服務(wù)直接訪問(wèn)、有狀態(tài)應(yīng)用希望保持 Pod IP固定、外部服務(wù)通過(guò) Ingress 或 Nodeport 訪問(wèn) Pod 丟失源 IP 等等。

上述問(wèn)題造成的結(jié)果是業(yè)務(wù)方在容器化過(guò)程中會(huì)產(chǎn)生很多顧慮，要上容器只能放棄基于 IP 的服務(wù)訪問(wèn)方式，并割舍掉一些原有的網(wǎng)絡(luò)功能。我們希望可以通過(guò)一個(gè)功能更全面的網(wǎng)絡(luò)插件來(lái)豐富 Kubernetes 現(xiàn)有的能力，協(xié)助業(yè)務(wù)方更順利地落地容器。

騰訊云私有化容器平臺(tái)自研網(wǎng)絡(luò)方案

騰訊云私有化容器平臺(tái)有 Tencent Cloud Enterprise (TCE) 和 Tencent Cloud Enterprise (TKE) 兩個(gè)版本。

TCE 是基于騰訊公有云成熟產(chǎn)品體系推出的專(zhuān)有云解決方案，采用Kubernetes on Kubernetes 架構(gòu)，支持私有化輸出，提供計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、負(fù)載均衡、中間件等全套產(chǎn)品能力。其容器服務(wù)使用的網(wǎng)絡(luò)是基于私有網(wǎng)絡(luò) VPC 自研的 Global-Route 插件以及 VPC-CNI 插件。

TKE 是騰訊云專(zhuān)門(mén)為企業(yè)打造的高性能私有云容器平臺(tái)，基于原生 Kubernetes 提供高度可擴(kuò)展的高性能容器管理服務(wù)。沒(méi)有 TCE 上的 VPC 等概念，而是直接在業(yè)務(wù)方 IASS 環(huán)境中部署集群，支持自行選擇 Overlay 或 Underlay 網(wǎng)絡(luò)，其使用的網(wǎng)絡(luò)方案由 Galaxy 插件進(jìn)行支持。

下面分別介紹這兩個(gè)平臺(tái)不同網(wǎng)絡(luò)方案的技術(shù)原理和應(yīng)用場(chǎng)景。

TCE：Global-Route 插件

Global-Route（全局路由）模式是 TCE 默認(rèn)采用的網(wǎng)絡(luò)方案，該模式依托于 VPC 底層路由能力，不需要在節(jié)點(diǎn)上配置 Vxlan 等 Overlay 設(shè)備，就可以實(shí)現(xiàn)容器網(wǎng)絡(luò)和 VPC 網(wǎng)絡(luò)的互訪。

節(jié)點(diǎn)跨母機(jī)場(chǎng)景下， Pod1 數(shù)據(jù)包會(huì)先經(jīng)過(guò)默認(rèn)路由轉(zhuǎn)發(fā)到 Node1 eth0 網(wǎng)卡，隨后 Node1 會(huì)將數(shù)據(jù)包轉(zhuǎn)發(fā)到母機(jī)1 br，母機(jī)1查詢?nèi)致酚杀眄?xiàng)依據(jù) RemoteIP 封裝 gre 頭，并將目標(biāo)節(jié)點(diǎn) IP 填入 gre option，再經(jīng)由母機(jī)1 eth1 發(fā)出。母機(jī)2 eth1收到數(shù)據(jù)包后會(huì)解封 gre 包頭，并從 gre option 獲取節(jié)點(diǎn)IP，于是將數(shù)據(jù)包轉(zhuǎn)給Node2 eth0，最終送至 Pod2。最終再由 Pod2 處理回包，回包鏈路和發(fā)包鏈路對(duì)稱(chēng)。

節(jié)點(diǎn)不跨母機(jī)場(chǎng)景下，Pod 互訪數(shù)據(jù)鏈路相同，經(jīng)由母機(jī) eth1 發(fā)出后，又由 eth1 收到，解封 gre 報(bào)文，轉(zhuǎn)發(fā)給 br，最終轉(zhuǎn)發(fā)給 pod。

這種模式同時(shí)是騰訊云公有云容器服務(wù)TKE的默認(rèn)網(wǎng)絡(luò)方案，支持集群內(nèi)容器與容器之間互通，集群內(nèi)容器與節(jié)點(diǎn)互通，集群內(nèi)容器與云數(shù)據(jù)庫(kù)、云存儲(chǔ)等資源同一 VPC 下內(nèi)網(wǎng)互通，容器集群與 IDC 互通，TCE 容器集群與公有云 TKE 容器集群互通。

TCE : VPC-CNI 插件

VPC-CNI 網(wǎng)絡(luò)利用騰訊云的多彈性網(wǎng)卡能力，為集群內(nèi)的 Pod 分配 VPC 內(nèi)的 IP 地址，由 VPC 負(fù)責(zé)路由，可實(shí)現(xiàn) Pod 和 Node 的控制面和數(shù)據(jù)面完全在同一網(wǎng)絡(luò)層面。針對(duì)每一個(gè)節(jié)點(diǎn)，如果該節(jié)點(diǎn)和容器子網(wǎng)處于同一個(gè)可用區(qū)，我們會(huì)為該節(jié)點(diǎn)額外創(chuàng)建一塊彈性網(wǎng)卡。當(dāng) Pod 調(diào)度到節(jié)點(diǎn)上，Pod 請(qǐng)求 IP 時(shí)，輔助 IP 才會(huì)綁定到節(jié)點(diǎn)的輔助彈性網(wǎng)卡，IP 不會(huì)預(yù)先分配。

并且 VPC-CNI 網(wǎng)絡(luò)支持通過(guò) IPAMD 插件固定 StatefulSet 類(lèi)型 Pod 的 IP，當(dāng)有 Statefulset 新建/更新/刪除時(shí)，IPAMD 插件會(huì)監(jiān)聽(tīng)到該事件，為 Statefulset 預(yù)留/解預(yù)留 IP，適用于需要對(duì) IP 來(lái)源做訪問(wèn)限制、通過(guò) IP 查詢?nèi)罩镜葓?chǎng)景。

一般來(lái)說(shuō)，如果你希望支持 StatefulSet 類(lèi)型 Pod IP 固定功能，并打算將容器集群與 TCE 提供的存儲(chǔ)、負(fù)載均衡等成熟模塊打通，那么就可以選擇使用基于 VPC-CNI 插件的 TCE 版容器服務(wù)。

TKE : Galaxy插件

針對(duì)用戶的不同應(yīng)用場(chǎng)景，騰訊 Gaia 團(tuán)隊(duì)自研的 Galaxy CNI 插件實(shí)現(xiàn)了 Overlay、Floating-IP、NAT、Host 四種網(wǎng)絡(luò)解決方案，可以動(dòng)態(tài)地為容器配置 Underlay/Overlay 網(wǎng)絡(luò)以及端口映射。

Overlay

Flannel 作為 Overlay 網(wǎng)絡(luò)的代表，可能是目前應(yīng)用最廣泛也最受歡迎的CNI 插件。它通過(guò) Kubernetes 集群的 etcd 服務(wù)存儲(chǔ)節(jié)點(diǎn)和網(wǎng)段之間的映射關(guān)系，Pod 只能在所在節(jié)點(diǎn)的網(wǎng)段中分配 IP 地址，保證了 Pod IP 的唯一性。在做跨節(jié)點(diǎn)通信時(shí)，F(xiàn)lannel 默認(rèn)使用 Vxlan 協(xié)議將額外的節(jié)點(diǎn)信息添加為包頭進(jìn)行傳輸，但是這種傳輸方式一直在解包封包，性能損失較大。

而 Flannel 的 Host-Gateway 模式則通過(guò)每個(gè)節(jié)點(diǎn)上的 Agent 進(jìn)程配置容器網(wǎng)絡(luò)的路由信息，只要是在同一個(gè)二層網(wǎng)絡(luò)中，數(shù)據(jù)就可以直接通過(guò)主機(jī)的路由表進(jìn)行轉(zhuǎn)發(fā)，相較于前面一直解包封包提升了性能。但是當(dāng)數(shù)據(jù)傳輸需要跨三層路由器時(shí)，單單配置主機(jī)路由表是不能解決問(wèn)題的。

區(qū)別于 Flannel 的 Host-Gateway 模式只能修改主機(jī)路由表，Calico 則是模擬了三層路由器，通過(guò) vRouter 在主機(jī)配置 BGP 路由協(xié)議將節(jié)點(diǎn)的路由信息廣播到整個(gè)集群的其他路由設(shè)備中，從而實(shí)現(xiàn)了無(wú)解包封包的跨網(wǎng)段數(shù)據(jù)轉(zhuǎn)發(fā)能力。當(dāng)網(wǎng)絡(luò)不支持 BGP 協(xié)議時(shí)，Calico 使用 IPIP 協(xié)議來(lái)封包傳輸數(shù)據(jù)， IPIP 即將原 Pod IP 的數(shù)據(jù)包添加 Host IP和 Host Mac 作為包頭，因?yàn)?IPIP 包頭較小，相較于 VxLAN 速度更快。

騰訊自研的 Overlay 網(wǎng)絡(luò)汲取了 Flannel/Calico 容器網(wǎng)絡(luò)開(kāi)源項(xiàng)目的優(yōu)點(diǎn)，實(shí)現(xiàn)了基于 IPIP 和 Host Gateway 的 Overlay 網(wǎng)絡(luò)方案。最終達(dá)到如下效果：

◆ 同節(jié)點(diǎn)容器報(bào)文無(wú)橋接，利用主機(jī)路由表進(jìn)行轉(zhuǎn)發(fā)，避免跨主機(jī)容器訪問(wèn)時(shí) bridge 的二層端口查詢

◆ 同網(wǎng)段節(jié)點(diǎn)容器報(bào)文無(wú)封包，利用主機(jī)路由表進(jìn)行轉(zhuǎn)發(fā)，無(wú)封包解包方案的性能最優(yōu)

◆ 跨網(wǎng)段節(jié)點(diǎn)容器數(shù)據(jù)利用 IPIP 協(xié)議封包， IPIP 性能好于 vxlan。

經(jīng)過(guò)測(cè)試，Vxlan比HOST差33%，IPIP 比HOST差23%，Gateway比HOST只差6%，目前該方案已被 Flannel 社區(qū)合并：

https://github.com/coreos/flannel/pull/842coreos/flannel#842

總的來(lái)說(shuō)，Overlay 網(wǎng)絡(luò)適用于對(duì)網(wǎng)絡(luò)性能沒(méi)有特殊要求、并且只使用Kubernetes 原生網(wǎng)絡(luò)能力，不需要額外支持 Pod IP 對(duì)外暴露、Pod IP 固定等功能的場(chǎng)景。它是大多數(shù)用戶的不錯(cuò)選擇，通過(guò)騰訊云 TKE 創(chuàng)建的私有云Kubernetes 集群默認(rèn)采用該方案。

Floating-IP

Floating-IP 介紹

在很多場(chǎng)景下業(yè)務(wù)方希望容器、物理機(jī)和虛擬機(jī)可以在同一個(gè)扁平面中直接通過(guò)IP進(jìn)行通信，由此我們實(shí)現(xiàn)了 Floating-IP 網(wǎng)絡(luò)。

Floating-IP 模式將宿主機(jī)網(wǎng)絡(luò)同一網(wǎng)段的IP直接配置到容器中，有別于Openstack（將 FloatingIP 配置到宿主機(jī)的網(wǎng)絡(luò)空間再通過(guò) NAT 轉(zhuǎn)發(fā)）的實(shí)現(xiàn)，其性能更好，容器與物理機(jī)可以直接路由。

這種模式為了保證容器與宿主機(jī)的交換機(jī)二層連通，需要在物理機(jī)上搭一個(gè) vbridge/vswitch 虛擬網(wǎng)橋，我們目前支持 Linux bridge、MacVlan、SRIOV 三種模式，用戶可以根據(jù)業(yè)務(wù)場(chǎng)景和硬件環(huán)境，具體選擇使用哪種網(wǎng)橋。

◆ Bridge：Bridge 設(shè)備內(nèi)核是 Linux 最早實(shí)現(xiàn)的網(wǎng)橋，它跟虛擬機(jī)橋接模式原理一樣，可以應(yīng)用到所有的場(chǎng)景。

◆ MacVlan：MacVlan 和 Bridge 比較相似，其相比 bridge 沒(méi)有源地址學(xué)習(xí)功能，不支持 STP，可以利用網(wǎng)卡的 unicast filter 功能，因此擁有更好的性能。但是 MacVlan 的問(wèn)題是，為了隔離需要內(nèi)核實(shí)現(xiàn)時(shí)不允許 MacVlan 容器訪問(wèn)其宿主機(jī)的 IP，也無(wú)法訪問(wèn)容器所在宿主機(jī)上配置的 Service Cluster IP和 NodePort，但是可以通過(guò)訪問(wèn)其他宿主機(jī)的 NodePort來(lái)規(guī)避這個(gè)問(wèn)題。

◆ SRIOV：SRIOV是網(wǎng)卡硬件功能，可以將一個(gè)物理網(wǎng)卡虛擬成多個(gè)物理網(wǎng)卡設(shè)備。SR-IOV 引入了 PFs(physical functions)和 VFs(virtual functions)的概念，每個(gè)VF都可以看做是一個(gè)獨(dú)立的物理網(wǎng)卡( PCIe 設(shè)備)可以被容器或虛擬機(jī)直接訪問(wèn)，較 Linux 軟件交換機(jī)其性能更好，且消耗 CPU 更少。

Floating-IP IP漂移能力

在 Kubernetes 中，Pod 會(huì)不斷地銷(xiāo)毀重建，這就導(dǎo)致 Pod IP 一直在改變。但是很多場(chǎng)景都需要 Pod 支持 IP 固定。比如，集群外部存量業(yè)務(wù)基于 IP進(jìn)行服務(wù)發(fā)現(xiàn)、基于 Pod IP 進(jìn)行白名單認(rèn)證，支持有狀態(tài)服務(wù) Statefulset等。對(duì)此 Floating-IP 模式提供了 IP 漂移能力，支持 Pod 重啟或遷移時(shí) IP 不變。

但是這個(gè)特性實(shí)現(xiàn)起來(lái)有一些問(wèn)題需要考慮：

1) 在發(fā)生 Pod 遷移時(shí)，如果IP可遷移范圍內(nèi)沒(méi)有備份機(jī)器或者備份機(jī)器的剩余CPU/內(nèi)存無(wú)法滿足 Pod 需求，Pod 將長(zhǎng)時(shí)間無(wú)法被調(diào)度

2) 微服務(wù)（Deployment）的 Pod 發(fā)生遷移時(shí)，Pod 實(shí)際是先被刪除，然后replicaset創(chuàng)建新的 Pod，新老 Pod 名稱(chēng)不相同，無(wú)法關(guān)聯(lián)到之前的 IP

3) Pod 發(fā)生遷移時(shí)，如何限制其可調(diào)度范圍

針對(duì)第一個(gè)問(wèn)題，我們將這個(gè)特性做成了可選的，在提交 App 時(shí)由用戶決定是否需要開(kāi)啟IP漂移功能。

針對(duì)第二個(gè)問(wèn)題，我們保證微服務(wù)的 Pod 發(fā)生遷移后微服務(wù)整體 IP 不變，通用服務(wù) TAPP（后續(xù)文章會(huì)介紹），Pod 遷移后由于名稱(chēng)不變，所以每個(gè)實(shí)例分配的IP不變。

針對(duì)最后一個(gè)問(wèn)題，必須要在調(diào)度時(shí)考慮使用 FloatingIP 的 Pod 的遷移范圍，所以我們實(shí)現(xiàn)了 kube-scheduler 的一個(gè)調(diào)度插件 FloatingIP Plugin。FloatingIP Plugin會(huì)watch Replicaset/TApp的縮容和刪除操作，釋放IP，也會(huì)定時(shí)校對(duì)已分配的IP是否還有對(duì)應(yīng)的Pod，防止scheduler重啟期間的事件丟失。

對(duì)于那些想要使用 Underlay 網(wǎng)絡(luò)的人來(lái)說(shuō) Floating-IP 模式是一個(gè)很好的選擇。它支持 Pod IP 對(duì)外暴露和 Pod IP 固定功能，基于這兩個(gè)特性可以很好地支持存量業(yè)務(wù)升級(jí)、集群內(nèi)外服務(wù)IP互訪的場(chǎng)景。但是使用 Floating-IP 模式需要單獨(dú)提供 IP 資源，對(duì)于 IP 資源不足的場(chǎng)景則無(wú)法使用。

NAT

如果業(yè)務(wù)方想要在集群外訪問(wèn)一個(gè)應(yīng)用的所有容器實(shí)例，而IP資源又不夠用，這時(shí)可以選用 Galaxy 插件的 NAT 模式。雖然我們可以通過(guò)給應(yīng)用創(chuàng)建多個(gè) Nodeport 來(lái)將這些 Pod 對(duì)外暴露，但是 Kubernetes 原生 Service 的Nodeport 模式端口范圍有限制（30000-32767），并且不管是否運(yùn)行指定應(yīng)用的容器，所有節(jié)點(diǎn)都需要開(kāi)放多個(gè)相同端口。當(dāng)這類(lèi)應(yīng)用數(shù)目很多時(shí)，可能會(huì)導(dǎo)致集群節(jié)點(diǎn)端口不夠用并丟失。

Galaxy 插件的 NAT 網(wǎng)絡(luò)與 Docker 的 NAT 網(wǎng)絡(luò)很像，都是通過(guò)配置iptables 規(guī)則來(lái)實(shí)現(xiàn)。Galaxy插件取消了端口范圍的限制，并且給每個(gè)實(shí)例配置容器到主機(jī)的隨機(jī)端口映射。

外部數(shù)據(jù)包訪問(wèn)容器時(shí)會(huì)先訪問(wèn)宿主機(jī)網(wǎng)卡端口，通過(guò) DNAT 數(shù)據(jù)包的目標(biāo)地址修改為容器 IP，最終將數(shù)據(jù)包送至容器；

容器發(fā)送數(shù)據(jù)包也會(huì)先訪問(wèn)宿主機(jī)，通過(guò) SNAT 修改數(shù)據(jù)包源地址為宿主機(jī) IP 。不過(guò)不同于 Docker 的 NAT 網(wǎng)絡(luò)，Galaxy 插件分給容器的是 Overlay 的 IP，應(yīng)用容器通過(guò)環(huán)境變量獲取宿主機(jī)的IP和隨機(jī)端口。

Host

Host 模式下容器直接與宿主機(jī)共享網(wǎng)絡(luò)，沒(méi)有進(jìn)行虛擬化網(wǎng)絡(luò)隔離。這樣一來(lái)，Pod 中所有的容器都直接暴露在宿主機(jī)網(wǎng)絡(luò)環(huán)境中。它最大的好處是性能高、延遲低，但是需要處理宿主機(jī)端口沖突問(wèn)題，并且也有安全隱患。Kubernetes 原生支持這種網(wǎng)絡(luò)方案，所以 Galaxy 插件也支持了這種方式。

如果對(duì)你的環(huán)境而言，網(wǎng)絡(luò)性能是非常重要的一點(diǎn)。并且你能夠處理主機(jī)端口的映射關(guān)系和占用問(wèn)題，那么這種方式仍然有其使用價(jià)值。

總結(jié)

不同企業(yè)之間的網(wǎng)絡(luò)架構(gòu)千差萬(wàn)別，本文主要介紹了 Kubernetes 的網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)以及騰訊基于多年深耕私有云 PASS 平臺(tái)經(jīng)驗(yàn)自研的 VPC-CNI 插件、GLobal-Route插件和 Galaxy 插件，這三個(gè)網(wǎng)絡(luò)插件針對(duì)不同應(yīng)用場(chǎng)景擁有多種解決方案，可以在滿足業(yè)務(wù)方獨(dú)特需求的前提下，提供給業(yè)務(wù)方一致的使用體驗(yàn)，降低服務(wù)容器化成本，進(jìn)而享受容器技術(shù)帶來(lái)的輕量、靈活、一致性使用體驗(yàn)。