Docker+k8s 容器雲建設中 10 個常見難點

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

随着雲計算、DevOps和微服務應用架構的發展，容器雲成為IT的主要基礎設施平台之一。以Docker為代表的容器技術，是目前有效的應用傳遞模式之一;以Kubernetes為代表的容器編排技術，是目前流行的應用部署方案。雲平台的基礎設施、DevOps的工程體系和微服務應用架構是IT技術轉型的底座。而容器雲又是這個底座下的一塊基石。

下面幾個問題是在Docker+K8S容器雲建設過程中，最常被問起和需要解決的難點問題。來自社群交流活動，多位社群會員分享解答，整理者：gavin_zhang

1、企業是應該選擇原生的Docker還是定制化的Docker，比如胖容器/富容器?

【問題描述】Docker是目前企業在進行容器化時首選的容器技術，但是原生的Docker在實際使用的過程中，特别是在傳統虛機運維到容器化運維的過渡中，會碰到以下類似問題：

1、如何ssh登入到容器，像登入虛機那樣，可以通過ssh進行管理

2、對于普通使用者來說，如何從容器中拷貝檔案到外部

3、虛機中一般會配置定時任務，在容器中如何實作

4、虛機中一般會安裝各種agent，容器中怎麼去安裝

若企業直接采用原生的Docker，那麼以上問題是比較棘手的。是以企業在容器技術選型上，是否應該為了最大程度相容虛機運維模式，對Docker進行定制化改造，滿足實際需求呢?

@某銀行 技術經理：

是使用原生還是定制就要看企業實力了。一般的企業不會去動原生的東西，不願意将人力花在這個方面。很多企業是通過應用的改造來适配容器化的方案，包括運維上的問題。

4個問題：

1、docker exec可以進入容器，如果是k8s或者ocp，還有有相應的api

2、友善拷貝的方式第一個容器中應用産生的檔案目錄挂載到本地;第二個使用相應的指令如docker cp;也許你說的不僅限一些簡單場景，其實都是有方法的，不僅以上兩種

3、容器中也是可以使用crontab定時任務操作的

4、agent的功能要先說清楚，如果上k8s或者ocp，一個pod可以完成你要說的内容。如果僅僅是用docker，根據功能需要應該也是有方法的。

@gavin_zhang 某股份制銀行 系統架構師：

1、docker exec可以滿足要求

2、最直接就是挂在本地磁盤存儲到容器上

3、可以考慮一下，定時排程起一個Docker執行任務

4、主要是這些Agent是用來幹什麼的?Docker執行個體本來就是作為一種一次性的，不可變的運作執行個體，傳統虛拟機的那個操作Agent，不符合容器的設計理念

定制化最大的問題在于，目前技術更新比較快，一旦定制，就鎖定在幾個版本了，後續更新維護工作量會很大。

2、容器雲平台主流技術和成熟産品選型及如何制定相關的标準和規範探讨?

【問題描述】在引入容器平台時，需先了解目前主流的容器平台技術和成熟産品，然後制定相關的标準和規範。具體如下：

• 想了解目前主流容器平台openshift3、openshift4、Rancher、博雲等國産容器産商的有哪些差別?容器平台如何選型?這些産品的功能、性能比較。
• 除了資金成本，容器平台後期的使用和運維需要如何考慮，目前公司自己對容器平台的開發能力不在，運維人員需要具體具備哪些能力，運維與開發如何協作，投入運維人員的規模如何估算?
• 容器平台早期實施的過程中需要做哪些規劃，避免哪些坑?

此問題有多位同行進行詳細的解答分享，我們已經專門整理成一篇文章，并在不久前向讀者們推送過，點選下面的标題即可回顧閱讀：

3、Kubenetes在金融多安全域的環境中，架構規劃問題?

【問題描述】金融行業網絡架構中存在多安全域的設計，kubenetes在多安全域網絡隔離的情況下，每個安全域都部署一套k8s叢集嗎?生産環境k8s叢集中calico有哪些網絡控制政策最佳實踐?

@nameless 某雲計算廠商 技術總監 ：

理論上來說各個安全域的網絡時隔離的，如果部署一套k8s叢集，所有的node節點和master節點是聯通的，node直接預設也是聯通的。可以每個安全域部署一套k8s叢集，使用同一的容器管理平台，這是k8s多叢集管理。

calico是k8s其中一個網絡插件，其他還有flannel、ovs等不同的網絡插件，生産使用哪一種網絡插件需根據自身業務需求選擇。

其實不需要這麼複雜，比如分了網際網路區、中間業務區、核心業務區，k8s叢集有6個node節點，可以兩個放網際網路、兩個放中間業務，兩個放核心業務，比如master節點都在OA區，隻要将master跟着6個node網絡上能通即可，不需要node間都能互相通路，一個叢集也是可以的。

calico是可以解決叢集内外通路的問題，但是随着需要通路叢集的外部節點的增加，那運維成本就很高了。可以使用ingress類似的解決方案。

4、容器雲平台建設難點之網絡如何選擇?如果選SDN網絡，那麼SDN網絡實作方案又應該如何選擇?

【問題描述】容器網絡如何選擇?容器雲平台的網絡一直是一個技術難題，是采用SDN網絡還是橋接到Underlay網絡;如果使用SDN網絡，那麼多的SDN網絡實作方案，如何選擇?

@liufengyi 某網際網路銀行 軟體架構設計師：

優先考慮公司整個網絡扁平化，互聯互通，這樣對應用改造成本要小很多，即基于公司原來的網絡打通來進行。如果容器的應用是一個相對獨立的服務，可以考慮overlay。規模不大的情況下一些開源網絡元件可以考慮采用。

@某金融企業 系統工程師：

calico、bgp、ingress、nginx等都是可以的

1、calico将叢集内與叢集外網絡打通，但是随着叢集外通路叢集内的節點越來越多，運維難度會加大

2、bgp需配置内部路由協定，性能上有損耗

3、ingress、nginx道理類似，将需要被外部通路的應用使用這兩個元件外部負載進到叢集内部

4、hostnetwork方式

5、nodeport方式

……

如何選擇要根據自身IT架構及監管要求定了

@zhuqibs 軟體開發工程師：

關于SDN還是underlay，如果你是自建的，一定不會選用SDN， 成本啊，兄弟們!Cisco去年要給我們搭建個ACI， 一個交換機就是1萬多，如果是銀行錢多沒有關系，中小企業資金緊張加上疫情，哪會選擇。

VMware的NST-G我們也用過，有bug，這個PKS每個月都會有一次“月經”，每次網絡存儲全堵死，IO基本龜速，廠商派人解決了大半年，連交換機都換了都沒有解決，結果賠了3台伺服器，幫我們全換成普通的vcentor。

SDN聽上去美好，現實很骨感，當然如果你有錢并願意試錯，又追求新技術，當然也是沒問題的。比如阿裡雲、騰訊雲這些公有雲，基本必然是SDN，人家有錢有人，來填坑。

是以，一般公司Underlay就可以了，加上Kubernetes自己的calico，fannel，或cattle，一般都沒問題，就是網絡上沒有硬隔離，沒有客戶化的東東，但我們可以用公有雲的啊，自己去建，多費錢。

@xiaoping378 某行科技公司 系統架構師：

1. 既然是說容器雲平台建設，肯定已經有了網絡基礎設施，那不考慮資料中心級别的SDN方案。隻考慮在已有的網絡建設成果上建設。
2. 不用迷信商業方案，無論是開源還是商業方案，大家都得遵守k8s的cni接口。不建議在容器網絡方案中寄托太多的功能，如網絡限速、安群政策等等。
3. 考慮目前主機層面大都可以保障二層是通的。最簡單方案方案可以選flannel。目前flannel發展到現在，已經支援vxlan模式下啟用DR網絡了，通俗講，就是同一子網下，走hostgw，主控端充當軟路由，性能接近裸網，垮子網的情況走vxlan。即兼顧了性能，又考慮了可擴充性。另外flannel目前也重點優化了大規模容器雲的路由表或arp占用過多問題，做到了：每擴充一個主機隻增加一個路由項、一個fdb項、一個arp項。
4. 如果考慮容器網絡隔離和安全政策的話(其實沒必要，網絡隔離，可以從項目級别來設定排程政策做到實體隔離)，可以考慮Canal網絡方案，他是calico和flannel的結合體。

@Garyy 某保險 系統工程師：

關于容器網絡的建設思路：

容器網絡發展到現在，已經是雙雄會的格局。雙雄會其實指的就是Docker的CNM和Google、CoreOS、Kuberenetes主導的CNI。首先明确一點，CNM和CNI并不是網絡實作，他們是網絡規範和網絡體系，從研發的角度他們就是一堆接口，你底層是用Flannel也好、用Calico也好，他們并不關心，CNM和CNI關心的是網絡管理的問題。

網絡需求調研發現，業務部門主要關注以下幾點：1、容器網絡與實體網絡打通;2、速度越快越好;3、改動越少越好;4、盡可能少的風險點。

容器的網絡方案大體可分為協定棧層級、穿越形态、隔離方式這三種形式

協定棧層級：二層比較好了解，在以前傳統的機房或虛拟化場景中比較常見，就是基于橋接的 ARP+MAC 學習，它最大的缺陷是廣播。因為二層的廣播，會限制節點的量級;三層(純路由轉發)，協定棧三層一般基于 BGP，自主學習整個機房的路由狀态。它最大的優點是它的 IP 穿透性，也就是說隻要是基于這個 IP 的網絡，那此網絡就可以去穿越。顯而易見，它的規模是非常有優勢，且具有良好的量級擴充性。但在實際部署過程中，因為企業的網絡大多受控。比如，有的企業網絡的 BGP 是基于安全考慮不給開發者用或者說企業網絡本身不是 BGP，那這種情況下你就受限了;協定棧二層加三層，它的優點是能夠解決純二層的規模性擴充問題，又能解決純三層的各種限制問題，特别是在雲化 VPC 場景下，可以利用 VPC 的跨節點三層轉發能力。

穿越形态：這個與實際部署環境十分相關。穿越形态分為兩種：Underlay、Overlay。

Underlay：在一個較好的可控的網絡場景下，我們一般利用 Underlay。可以這樣通俗的了解，無論下面是裸機還是虛拟機，隻要整個網絡可控，容器的網絡便可直接穿過去 ，這就是 Underlay。

Overlay：Overlay 在雲化場景比較常見。Overlay 下面是受控的 VPC 網絡，當出現不屬于 VPC 管轄範圍中的 IP 或者 MAC，VPC 将不允許此 IP/MAC 穿越。出現這種情況時，我們可利用 Overlay 方式來做。

Overlay網絡使實體網絡虛拟化、資源池化，是實作雲網融合的關鍵。把Overlay網絡和SDN技術結合使用，把SDN控制器作為Overlay網絡控制平面的控制器，這種方式更容易使網絡與計算元件整合，是網絡向雲平台服務轉變的理想選擇。

隔離方式：隔離方式通常分為VLAN和VXLAN 兩種。

VLAN：VLAN 機房中使用偏多，但實際上存在一個問題。就是它總的租戶數量受限。衆所周知，VLAN 具有數量限制。

VXLAN：VXLAN 是現今較為主流的一種隔離方式。因為它的規模性較好較大，且它基于 IP 穿越方式較好。

@Steven99 軟體架構設計師：

容器網絡選擇我個人覺得不是重點，其實不管哪種網絡，都應該對終端使用者透明，是以不應該糾結于網絡模型。

需要考慮的重點可能是安全性，穩定性，易用性等，我們使用calico網絡，發現也是很多問題，在考慮替換。開源産品總是需要很多額外的工作，測試驗證，逐漸優化，不實際使用，很難說哪種更合适，在使用過程中可能會逐漸清晰自己的需求。

容器安全，容器網絡安全可能是重點，特别上生産業務，服務數量達到一定量後，會有很多想不到的問題，當然，不實際做過，也很難選擇，是以可以嘗試先用起來，經常使用會逐漸清晰明白自己要什麼。

5、容器東西向網絡安全是怎麼考慮的?

@zhuqibs Mcd 軟體開發工程師：

東西向流量的控制，是服務網格的控制範疇，istio可以實作，但目前istio不完善，所有很不好用。建議使用kong、traefik為代表的api gateway，其中Kong基于nginx，可以在容器中部署到每個pod中去，控制pod和pod之間的流量。

東西向流量指同一主控端上與其他容器互相通路，同一主機上pod預設是互通的。

我認為可以從上層邏輯控制上減少安全隐患，即根據業務劃分不同的邏輯叢集，盡量讓有血緣關系的業務放在同一邏輯叢集。

6、容器中的應用問題排查方法探讨?

【問題描述】如何擷取容器裡面的堆棧資訊，如何抓包分析，當有容器外應用通路容器内應用或容器内應用通路容器外應用，如何根據ip追蹤通路鍊路?

從監控元件考慮，可以使用skywalking進行鍊路上api調用中端口資訊的跟蹤，如果用商業化apm元件，cisco、聽雲都有不錯的産品。

在微服務架構中，每個pod就是一個服務，在每個應用pod中加入kong元件，每個kong元件都可以輸入流量監控資料到prometheus，這樣，也能不友善取代鍊路監控軟體的功能，當然隻是“部分”，skywalking和apm還能取到其他類型的資料。

我們內建了apm來做故障發現和排查，可以通過查詢容器在哪台主控端上，然後抓指定虛拟網卡上容器的網絡包。

堆棧資訊可以在應用架構加入dump功能，以日志的方式輸出到日志系統。

實作應用的全鍊路最終，解決方案有Spring cloud sleuth等

7、容器雲平台的整體規劃：包括計算資源、存儲、網絡的選型?

【問題描述】我想了解一下容器雲平台的一個整體規劃，包括計算資源、存儲、網絡的選型，我們打算将微服務遷移到容器雲平台。

個人意見：

1、首先确定目标，建設容器雲平台的目标，規劃哪些業務上容器，大概的資源需求是多少，叢集規模多大等等;

2、容器平台選型，基本是k8s，這個應該沒問題;

3、計算資源：基本是采用裸機還是虛拟機作為計算資源，兩種方案各有優劣，如果已有IaaS平台，可以采用虛拟機，如果沒有IaaS平台，也可以直接使用裸機;

4、網絡資源：需要考慮業務上容器是否需要對業務進行改造，另外就是将來業務向容器平台遷移過程，比如一個微服務業務，遷移至容器平台時，先遷移部分微服務，還是整體遷移?遷移部分微服務後，已上容器微服務和未上微服務網絡網絡通信等等;

5、存儲資源：考慮業務上容器是有狀态業務還是無狀态業務，已經業務對性能的影響，選擇合适的存儲資源;

綜上，還需要考慮運維團隊的運維能力、以及和開發對接等等。

8、使用容器雲平台，如何提升系統開發和測試的能力?

【問題描述】目前公司選擇springcloud微服務體系，在開發測試過程中，如何使用容器雲平台提升系統開發測試能力?能夠提升哪些能力?

有沒有較好的實踐路徑和應注意的關鍵點?比如是否在開發測試雲上先搭建通用的服務(注冊中心等，是否開發測試雲通用一套服務?)，maven私倉管理、基礎鏡像管理等等?

對于測試，可以使用容器平台的持續傳遞的能力，縮短測試版本周期和環境準備的時間;使用平台靈活的路由功能，進行多版本相容性測試。

較好的實踐路徑和應注意的關鍵點 ：

1.通用的服務建議統一建設成平台服務，但是不建議測試開發使用同一個運作執行個體。

2.建立私有的鏡像倉庫，制定基礎鏡像白名單。

3.做好鏡像的版本管理，利用容器和git的tag，做到執行個體和鏡像，鏡像和源碼的對應。

9、銀行重要的業務場景如何用k8s做滾動更新?

這個問題細說的話就多了，需要看業務場景。強一緻性交易類業務，像消費之類的需要應用本身來保證，事務失敗要能復原。那版本更新復原就要有優雅停機的動作，一些管道類交易，隻是做中間轉接，一般是可以直接做更新復原的。

更新復原的操作，主要是通過替換應用依賴的鏡像版本。k8s的更新復原是利用新版本鏡像或者舊版本鏡像拉起一個新pod，下線一個舊pod依次完成此操作的，保證業務正常運作。

平台方面：結合K8s的流量分發，實作金絲雀釋出機制，通過精細的流量控制，來實作業務的滾動更新。應用方面：應用需要有合理的設計，在規劃時就需要有相關的設計，對應用有合理的低耦合的切分，盡量減少釋出應用的涉及面，這其中最重要的如何實作問題的回退，特别是影響到賬務資料的，采用資料染色或是零時表的方式，盡量做到應用可回溯。

@rangeryu 螞蟻金服 産品經理：

這個問題可以結合着螞蟻作大規模釋出的時候所關注的變更管理來回答。

原生 deployment 做灰階或者金絲雀釋出時，預設情況下在 Pod 變更和流量治理層面的管控還稍顯不足，無法完全做到無損釋出或按需過程管控。是以，我們在 PaaS 産品層面做了定制，在 Kubernetes 層面做了自定義資源的擴充，目的是能夠在雲原生的場景下，依然對整個釋出過程實作精細化管控，使得大規模叢集釋出、灰階、復原時更加優雅，符合技術風險三闆斧原則。

在實際的生産環境中，圍繞容器大規模變更會配合業務監控及更多元度的觀察，確定每一步都是符合預期、驗證通過的。這樣在應用執行個體層面的精細化管控，為運維提供了能夠及時刹車復原的機會，是線上應用釋出的一個重要的保險繩。

簡單來說，在螞蟻内部所有的變更要滿足” 可灰階、可監控、可應急 “，當基礎設施全面轉向雲原生，就開始基于Kubernetes作了非常多擴充和補充。對于金融業務場景，從實際産品層，需要做到：

1. 感覺底層拓撲
2. 分組/beta/分批釋出
3. 優雅摘流

10、 容器雲的高可用問題?為了實作高可用，容器雲内部需要多個獨立的Kubernetes叢集，底層網絡和基礎設施應該如何部署才能實作故障隔離?應用如何在多個叢集之間實作故障轉移?

k8s應用高可用的功能都是k8s本身完成的，如果需要做到叢集間的單個應用的高可用，應該是要做高度定制，在容器雲平台上監控應用的狀态，公用鏡像倉庫。

目前的一種實作方案是有應用層來做跨叢集的高可用方案，利用Euraka或是Zookeeper這種跨叢集的管理中心，來實作應用之間的跨叢集調用。如果實作了服務網格(Service Mesh)，可以考慮在Service Mesh層實作。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/live

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-04-09

本文作者：twt社群

本文來自：“

51CTO

”，了解相關資訊可以關注“

”