伺服器容器雲設計

A. 什麼是容器雲

容器技術是近幾年雲行業發展中不可缺少的一環。Docker和k8s的大熱極大可能會推動雲計算PAAS層的完善和普及。

容器（Container）是一種更輕量級，更靈活的虛擬化處理方式，它將一個應用程序所需的一切打包在一起。

容器包括所有代碼，各種依賴甚至操作系統，這讓應用程序幾乎在任何地方都可以運行。因此它的誕生，解決了一個重要問題：如何確保應用程序從一個環境移動到另一個環境的正確運行。它只是虛擬了操作系統，而不像虛擬機一樣去虛擬底層計算機。

Docker 容器是一個開源的應用容器引擎，讓開發者可以以統一的方式打包他們的應用以及依賴包到一個可移植的容器中，然後發布到任何安裝了docker引擎的伺服器上（包括流行的Linux機器、windows機器），也可以實現虛擬化。

容器是完全使用沙箱機制，相互之間不會有任何介面（類似 iPhone 的 app）。幾乎沒有性能開銷,可以很容易地在機器和數據中心中運行。最重要的是,他們不依賴於任何語言、框架包括系統。

• 定期滲透測試，安全審計；

• 盡量採用image的正規鏡像來源，相對於傳統安全，容器安全受質疑很大程度上是在於鏡像的維護及升級，因此在鏡像源頭保證安全和及時更新；

• 及時升級容器服務，比如採用rollingupdate的方式對跑服務的容器進行升級等方式。

Docker容器與其他的容器技術都是大致類似的。但是，Docker在一個單一的容器內捆綁了關鍵的應用程序組件，這也就讓這容器可以在不同平台和雲計算之間實現便攜性。其結果就是，Docker就成為了需要實現跨多個不同環境運行的應用程序的理想容器技術選擇。

Docker還可以讓使用微服務的應用程序得益，所謂微服務就是把應用程序分解成為專門開發的更小服務。 這些服務使用通用的RESTAPI來進行交互。使用完全封裝Docker容器的開發人員可以針對採用微服務的應用程序開發出一個更為高效的分發模式。

B. 雲計算2020展望（技術篇）：Serverless、K8s、服務網格、OSS、HPC

回顧2019年中國雲計算產業的發展，趁著「產業互聯網」火熱的東風，雲計算也一路高歌前行。阿里巴巴、騰訊、網路、華為等 科技 互聯網巨頭企業都在持續布局。

Salesforce與阿里巴巴達成戰略合作，阿里巴巴推出政務釘釘，網路雲升級為網路智能雲，網路推出愛番番CRM開放平台，銷售易獲騰訊獨家1.2億美元E輪融資，騰訊雲全面升級彈性計算產品序列，計算性能提升30%；金山辦公正式登陸科創板上市、華為新成立「華為雲計算技術有限公司」 ……這些「新鮮「的雲計算故事，也都曾轟動一時，甚至時至今日，仍對雲計算領域影響至深。

2020年剛起步，中國雲計算「第一股」——UCloud成功登陸科創板，成為眾多業內人士在武漢的新型冠狀病毒肺炎爆發前，最關注的"熱點」之一。

展望2020年，億歐智庫堅定看好雲計算領域的發展機會，並將持續輸出雲計算產業細分領域，如PaaS、SaaS、雲安全等領域的研究報告。

值得注意的是，億歐智庫此前發布的《2019年中國雲計算行業發展研究報告》所總結的六條雲計算產業發展趨勢依舊具備長期預判價值。以下列出概括性的內容，具體詳見報告正文：

基於此，億歐智庫進一步總結雲計算產業的未來發展趨勢，幫助業內人士更加及時把握雲計算產業最新發展機遇。本篇將重點介紹五條雲計算產業有希望快速落地或爆發的主流技術：

無伺服器計算（Severless Computing，以下簡稱Serverless）是一種包含第三方BaaS（後端即服務）服務的應用程序設計方式，與包括FaaS（函數即服務）平台上的託管臨時容器中運行的自定義代碼。與很多技術趨勢一樣，Serverless至今還沒有明確且清晰的定義，對於開發人員來說，其重點代表兩個截然不同但有重合的概念：

Serverless相比IaaS和SaaS，可以更好更快的在雲服務商平台上部署應用，完全不用提前測算資源需求，所有功能根據事件驅動，按需載入，執行完畢，資源釋放，真正實現了用多少付費多少，降低成本的同時，還提高了開發人員的生產力。

Serverless主要適合於新興的、事件驅動性的，類似於IoT等感測設備、金融交易類型等場景。

Serverless興起於2017年，在最近兩年伴隨雲原生概念的推廣逐漸火熱。

目前 Serverless 在國內的發展和採用依然處於初期階段，業務實踐偏少，仍在不斷 探索 之中。相比之下，國外整體要領先 1-2 年，國外幾大雲廠商前期對整個研發生態的教育和布局較多，應用較早。

現在國外也已經出現不少 Serverless 框架，比較知名包括 Serverless.com 和 Zeit.com。

根據RightScale的2018年雲狀態報告，無伺服器是當今增長速度很快的雲服務模型，年增塑達75%，並有望於2020年超越該增速。億歐智庫也對Serverless的增長速度和市場規模持樂觀態度。

Kubernetes（以下簡稱K8s） 是一個針對容器應用，進行自動部署，彈性伸縮，和管理的開源系統。主要負責在大規模伺服器環境中管理容器組（pod）的擴展、復制、 健康 ，並解決 pod 的啟動、負載均衡等問題。

K8s 能在實體機或虛擬機集群上調度和運行程序容器。K8s 也能讓開發者斬斷聯系著實體機或虛擬機的「鎖鏈」，從以主機為中心的架構躍至以容器為中心的架構。該架構最終提供給開發者諸多內在的優勢，例如可移動、可擴展、自修復等。

K8s 也能兼容各種雲服務提供商，例如 Google Cloud、Amazon、Microsoft Azure，還可以工作在 CloudStack、OpenStack、OVirt、Photon、VSphere。

K8s 源於 Google 內部的 Borg 項目，經 Google 使用 Go 語言重寫後，被命名為Kubernetes，並於 2014 年 6 月開源。目前已有多家大公司，例如 Microsoft、 RedHat、 IBM、Docker，都支持K8s。

從近年來國外K8s發展來看， 巨頭公司為自有K8s部門增添活力或構建全新產品的有效手段之一為收購 。

隨著專注於容器初創公司逐漸增加，預計2020年各大雲服務商將繼續收購表現優秀的容器初創公司，以進軍K8s市場，完善其產品體系。

不可否認，K8s作為一項新興技術距全球普及它還有很長的路要走。但很明顯，K8s已經是，並且將繼續是軟體世界中的主導力量。

服務網格（Service Mesh）是用於控制和監視微服務應用程序中的內部服務到服務流量的軟體基礎結構層。服務網格的獨特之處在於它是為適應分布式微服務環境而構建的。

服務網格的興起主要是為了解決Docker和Kubernetes無法解決的運行問題。因為諸如Docker和Kubernetes這樣的工具主要解決的是部署的問題。但部署不是生產的最後一步，部署完之後，應用程序還必須運行，服務網格因解決運行問題應運而生。

2016年服務網格提出之後，以Linkerd和Envoy為代表的框架開始嶄露頭角。目前市面上沒有現成的商業產品，大多數服務網格都是開源項目，需要一些技巧才能實現。最著名的有：

關於服務網格技術的並購目前也逐漸升溫，著名的並購案有VMware在2019年7月以4.2億美元收購了Avi Networks以及F5 Networks在2019年5月斥資2.5億美元收購了NGINX。

2019年是被確定是適合解決服務網格問題的一年，2020年將會是核心服務網格用例出現的一年。

開源軟體（Open Source Software，以下簡稱OSS）被定義為描述其源碼可以被公眾使用的軟體，並且此軟體的使用，修改和分發也不受許可證的限制。

1998年2月，「開源」一詞首先被運用於軟體。最初的開源軟體項目並不是真正的企業，而是一些頂級程序員針對Microsoft、Oracle、SAP等老牌閉源公司對軟體收費較高的一場革命。頂級開發人員通常以非同步方式協同編寫一些出色的軟體。每個人不僅可以查看公開的軟體，而且通過一種鬆散的治理模型，他們可以添加，改進和增強它。這是第一代的開源軟體項目。

而經過10多年的發展，Linux、MySQL的成功為第二代開源軟體公司奠定基礎，比如Cloudera和Hortonworks。但第二代開源軟體公司中，沒有一家公司對軟體擁有絕對的控制權，對手經常通過免費提供軟體來進行競爭。

之後出現了像Elastic、Mongo和Confluent等第三代開源軟體公司提供的Elastic Cloud，Confluent Cloud和MongoDB Atlas這樣的服務，這種進化代表著開源軟體公司這種模式有機會成為軟體基礎設施的主要商業模式。

經過22年的發展，如今OSS已經無處不在。OSS領域也發聲了一些「大事件」：IBM以320億美元的價格收購了Redhat（是2014年市值的3倍）；Mulesoft在上市後以65億美金的價格被Salesforce收購；MongoDB現在市值超過40億美元；Elastic則為60億美元；並且，通過Cloudera和Hortonworks的合並，將出現一個市值超過40億美元的新公司……

當然還有很多OSS的公司在路上，例如Confluent、HashiCorp、DataBricks、Kong、Cockroach Labs等。

展望2020年，OSS的理念將與雲計算SaaS（軟體即服務）的理念更加契合，將大大推動軟體產業的創新，並有機會迎來新一輪的發展高潮。

高性能計算（High Performance Computing，以下簡稱HPC）指能夠執行一般個人電腦無法處理的大資料量與高速運算的電腦，其基本組成組件與個人電腦的概念無太大差異，但規格與性能則強大許多。

HPC能夠在非常短的時間內執行大量計算，正從過去主要傳統科研領域計算密集型為主，逐漸向新興的大數據、人工智慧以及深度學習等方向進行融合和演進。

從應用領域來看，HPC是不同行業中非常專業的領域，可以用於預報天氣，也可以是分析風險，還可以分析農場數據，以根據不斷變化的天氣條件找到最佳的農作物種植地點。

在中國市場當中，主要有聯想、浪潮和曙光三家公司處於領先的地位，占據了超過90%的市場份額。這三家公司作為中國HPC市場的狀元、榜眼和探花，共同將中國HPC推上了世界第一的位置。

其中，聯想連續五年蟬聯「HPC China TOP100榜單」第一名，並於2019年11月8日發布「深騰X9000」高性能融合計算平台，該平台在兼顧算的更快、更准、更全面的同時，也使聯想成為HPC綠色數據中心的積極倡導者，繼續領跑HPC水冷解決方案。

除此之外，聯想還在全球160多個國家開展眾多領域的突破性研究，這些領域包括癌症、大腦研究、天體物理學、人工智慧、氣候科學、化學、生物學、 汽車 和航空等。

公開調研資料顯示，2018年企業中使用了HPC的比例是36%。隨著雲計算領域的基礎設施完備、資源和數據的增加，HPC的需求也將在2020年有所增加，雲服務商有望對HPC進行投資。

眾所周知，技術的進步對產業發展和創新具有積極推動作用。

正如近年來區塊鏈、5G、機器學習等技術的發展對傳統產業的轉型促進一樣，Serverless、Service Mesh、K8s、OSS、HPC這些雲技術也必將提升IaaS、PaaS、SaaS等傳統雲計算模式的彈性、靈活性、計算能力等，並與傳統模式融合互補，協同助推各產業轉型升級。

推薦閱讀：

千淘萬漉，吹盡黃沙，中國智能製造哨聲洪亮 | 預見2020

2020銀行業展望：對外開放加快，理財轉型提速， 科技 深度賦能……

2020物流業新態勢：巨頭效應顯著、 科技 賦能、智慧物流建設加快……

撥雲見日，始得真金，產業互聯網迎來高光時刻丨預見2020

預見2020：日新月異的中國保險業

C. Docker容器與容器雲 這本書看過嗎

Docker是什麼？

簡單得來說，Docker是一個由GO語言寫的程序運行的「容器」（Linux containers， LXCs）； 目前雲服務的基石是操作系統級別的隔離，在同一台物理伺服器上虛擬出多個主機。Docker則實現了一種應用程序級別的隔離； 它改變我們基本的開發、操作單元，由直接操作虛擬主機（VM）,轉換到操作程序運行的「容器」上來。

Docker是為開發者和系統管理員設計的，用來發布和運行分布式應用程序的一個開放性。由兩部分組成：

Docker Engine: 一個攜帶型、輕量級的運行環境和包管理器。（注* 單OS vs 單線程，是不是跟NodeJS特別像？）

Docker Hub: 為創建自動化工作流和分享應用創建的雲服務組成。（注* 雲端鏡像/包管理 vs npm包管理，是不是跟npm特別像？）

從2013年3月20日，第一個版本的Docker正式發布到 2014年6月Docker 1.0 正式發布，經歷了15個月。 雖然發展歷程很短，但Docker正在有越來越流行的趨勢。

其實Container技術並非Docker的創新，HeroKu, NodeJitsu 等雲服務商都採用了類似這種輕量級的虛擬化技術，但Docker是第一個將這這種Container技術大規模開源並被社區廣泛接受的。

好的部分
Docker相對於VM虛擬機的優勢十分明顯，那就是輕量和高性能和便捷性， 以下部分摘自：KVM and Docker LXC Benchmarking with OpenStack

快
運行時的性能可以獲取極大提升（經典的案例是提升97%）

管理操作（啟動，停止，開始，重啟等等） 都是以秒或毫秒為單位的。

敏捷
像虛擬機一樣敏捷，而且會更便宜，在bare metal（裸機）上布署像點個按鈕一樣簡單。

靈活
將應用和系統「容器化」，不添加額外的操作系統，

輕量
你會擁有足夠的「操作系統」，僅需添加或減小鏡像即可。在一台伺服器上可以布署100~1000個Containers容器。

便宜
開源的，的，低成本的。由現代Linux內核支持並驅動。注* 輕量的Container必定可以在一個物理機上開啟更多「容器」，註定比VMs要便宜。

生態系統
正在越來越受歡迎，只需要看一看Google的趨勢就知道了，docker or LXC.

還有不計其數的社區和第三方應用。

雲支持
不計其數的雲服務提供創建和管理Linux容器框架。

有關Docker性能方面的優勢，還可參考此IBM工程師對性能提升的評測，從各個方面比VMs（OS系統級別虛擬化）都有非常大的提升。轉載，僅供參考。

D. 什麼是K8S

‍

k8s是什麼?

Kubernetes 是一個可移植的，可擴展的開源容器編排平台，用於管理容器化的工作負載和服務，方便了聲明式配置和自動化。它擁有一個龐大且快速增長的生態系統。Kubernetes 的服務，支持和工具廣泛可用。

為什麼現在流行使用容器?

早期: 在物理伺服器上面部署應用程序存在資源分配問題,因為其不能在物理伺服器中的應用程序定義資源邊界,導致應用程序資源利用不足而無法擴展.

後來: 為了解決該問題,引入了虛擬化技術, 虛擬化技術是指允許你在單個物理伺服器的 CPU 上運行多個虛擬機,可以讓多個應用程序在虛擬機之間進行隔離,具有一定的安全性, 每一個虛擬機就是一台完整的計算機, 在虛擬化硬體之上運行所有組件.

現在: 多數在物理伺服器上面部署應用程序都是采kubectl用容器的方式,容器類似於虛擬機,它們都具有自己的文件系統、CPU、內存、進程空間等, 且由於它們與基礎架構分離，因此可以跨雲和 OS 發行版本進行移植。基於此特點被企業大范圍使用.

為什麼需要使用k8s容器?

若出現這樣一個環境: 在生產環境中如果一個容器發生故障,則我們需要手動去啟動另外一個容器,這樣的操作是對我們的管理員來說是不太方便的, 若一個容器出現故障,另一個容器可以自動啟動容器接管故障的容器,這樣是最好的.

k8s就可以實現該效果,Kubernetes 提供了一個可彈性運行分布式系統的框架。 Kubernetes 會滿足你的擴展要求、故障轉移、部署模式等。

k8s功能: 服務發現和負載均衡, 存儲編排, 自動部署和回滾, 自動完成裝箱計算, 自我修復, 密鑰與配置管理

名詞解釋

secret

Secret有三種類型：

• Service Account：用來訪問Kubernetes API，由Kubernetes自動創建，並且會自動掛載到Pod的目錄中；
• /run/secrets/kubernetes.io/serviceaccount
• Opaque：base64編碼格式的Secret，用來存儲密碼、密鑰等；
• kubernetes.io/dockerconfigjson：用來存儲私有docker registry的認證信息。

k8s的組成

k8s是由組件,API,對象等組成.

包含所有相互關聯組件的 Kubernetes 集群圖如下:

組件

• 控制平面組件
  • kube-apiserver: 為k8s的api伺服器,公開了所有Kubernetes API, 其他所有組件都必須通過它提供的API來操作資源數據.
    • 保證集群狀態訪問的安全
    • 隔離集群狀態訪問的方式和後端存儲實現的方式：API Server是狀態訪問的方式，不會因為後端存儲技術etcd的改變而改變。
  • etcd: 為k8s的鍵值資料庫,保存了k8s所有集群數據的後台資料庫。
  • kube-scheler: 收集和分析當前Kubernetes集群中所有Node節點的資源(內存、CPU)負載情況，然後依此分發新建的Pod到Kubernetes集群中可用的節點。 kube-controller-manager: 在主節點上運行 控制器 的組件。
  • cloud-controller-manager: 雲控制器管理器是指嵌入特定雲的控制邏輯的 控制平面組件
• Node 組件
  • kubelet: 一個在集群中每個節點（node）上運行的代理。 它保證容器（containers）都 運行在 Pod 中。
  • kube-proxy: kube-proxy是集群中每個節點上運行的網路代理,維護節點上的網路規則。這些網路規則允許從集群內部或外部的網路會話與 Pod 進行網路通信。
  • 容器運行時: 負責運行容器的軟體。
• 插件(Addons)
  • DNS: 集群 DNS 是一個 DNS 伺服器，和環境中的其他 DNS 伺服器一起工作，它為 Kubernetes 服務提供 DNS 記錄。
  • Web 界面（儀表盤）: Dashboard 是Kubernetes 集群的通用的、基於 Web 的用戶界面。
  • 容器資源監控: 容器資源監控 將關於容器的一些常見的時間序列度量值保存到一個集中的資料庫中，並提供用於瀏覽這些數據的界面。
  • 集群層面日誌: 集群層面日誌 機制負責將容器的日誌數據 保存到一個集中的日誌存儲中，該存儲能夠提供搜索和瀏覽介面。

API

Kubernetes 控制面 的核心是 API 伺服器。 API 伺服器負責提供 HTTP API，以供用戶、集群中的不同部分和集群外部組件相互通信。

對象

Kubernetes對象是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示集群的狀態.

具體來說，他們可以描述：

• 容器化應用正在運行(以及在哪些節點上)
• 這些應用可用的資源
• 關於這些應用如何運行的策略，如重新策略，升級和容錯

Kubernetes 架構

Kubernetes 架構由節點,控制面到節點通信, 控制器, 雲控制器管理器組成.

master 流程圖

• Kubecfg將特定的請求，比如創建Pod，發送給Kubernetes Client。
• Kubernetes Client將請求發送給API server。
• API Server根據請求的類型，比如創建Pod時storage類型是pods，然後依此選擇何種REST Storage API對請求作出處理。
• REST Storage API對的請求作相應的處理。
• 將處理的結果存入高可用鍵值存儲系統Etcd中。
• 在API Server響應Kubecfg的請求後，Scheler會根據Kubernetes Client獲取集群中運行Pod及Minion/Node信息。
• 依據從Kubernetes Client獲取的信息，Scheler將未分發的Pod分發到可用的Minion/Node節點上。

節點

節點可以是一個虛擬機或者物理機器，取決於所在的集群配置。 每個節點包含運行 Pods 所需的服務， 這些 Pods 由 控制面 負責管理.

節點上的組件包括 kubelet、 容器運行時以及 kube-proxy。

節點狀態

可以使用 kubectl 來查看節點狀態和其他細節信息：

kubectl describe node <�節點名稱>

一個節點包含以下信息:

• 地址
  • HostName：由節點的內核設置。可以通過 kubelet 的 —hostname-override 參數覆蓋。
  • ExternalIP：通常是節點的可外部路由（從集群外可訪問）的 IP 地址。
  • InternalIP：通常是節點的僅可在集群內部路由的 IP 地址。
• 狀況(conditions 欄位描述了所有 Running 節點的狀態)
  • Ready 如節點是健康的並已經准備好接收 Pod 則為 True；False 表示節點不健康而且不能接收 Pod；Unknown 表示節點控制器在最近 node-monitor-grace-period 期間（默認 40 秒）沒有收到節點的消息
  • DiskPressure為True則表示節點的空閑空間不足以用於添加新 Pod, 否則為 False
  • MemoryPressure為True則表示節點存在內存壓力，即節點內存可用量低，否則為 False
  • PIDPressure為True則表示節點存在進程壓力，即節點上進程過多；否則為 False
  • NetworkUnavailable為True則表示節點網路配置不正確；否則為 False
• 容量與可分配
  • 描述節點上的可用資源：CPU、內存和可以調度到節點上的 Pod 的個數上限。
• 信息
  • 關於節點的一般性信息，例如內核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系統名稱。這些信息由 kubelet 從節點上搜集而來。

控制面到節點通信

• 節點到控制面
  • apiserver在安全的 HTTPS 埠（443）上監聽遠程連接請求
  • 以客戶端證書的形式將客戶端憑據提供給 kubelet
• 控制面到節點
  • API 伺服器到 kubelet連接用於
    • 獲取 Pod 日誌
    • 掛接（通過 kubectl）到運行中的 Pod
    • 提供 kubelet 的埠轉發功能。
    • (注: 在連接狀態下, 默認apiserver 不檢查 kubelet 的服務證書。容易受到中間人攻擊，不安全.)
  • apiserver 到節點、Pod 和服務
    • SSH 隧道(目前已經廢棄)
      • 產生原因: 若無服務證書, 又要求避免在非受信網路或公共網路上進行連接,則可以在apiserver 和 kubelet 之間使用ssh隧道.
      • Kubernetes 支持使用 SSH 隧道來保護從控制面到節點的通信路徑。
    • Konnectivity 服務
      • 為ssh隧道的替代品, Konnectivity 服務提供 TCP 層的代理，以便支持從控制面到集群的通信。

控制器

在 Kubernetes 中，控制器通過監控集群 的公共狀態，並致力於將當前狀態轉變為期望的狀態。

舉個例子: 當前室內溫度為20度, 我們通過調節遙控器,使其溫度上升至24度, 這20度到24度的變化即為讓其從當前狀態接近期望狀態。

控制器模式分為直接控制和通過API伺服器來控制.

雲控制器管理器

雲控制器管理器是指嵌入特定雲的控制邏輯的 控制平面組件。 雲控制器管理器允許您鏈接聚合到雲提供商的應用編程介面中， 並分離出相互作用的組件與您的集群交互的組件。

雲控制器管理器中的控制器包括：

• 節點控制器
  • 節點控制器負責在雲基礎設施中創建了新伺服器時為之 創建 節點（Node）對象。 節點控制器從雲提供商獲取當前租戶中主機的信息。
  • 執行功能:
    • 針對控制器通過雲平台驅動的 API 所發現的每個伺服器初始化一個 Node 對象
    • 利用特定雲平台的信息為 Node 對象添加註解和標簽
    • 獲取節點的網路地址和主機名
    • 檢查節點的健康狀況。
• 路由控制器
  • Route 控制器負責適當地配置雲平台中的路由，以便 Kubernetes 集群中不同節點上的 容器之間可以相互通信。
• 服務控制器
  • 服務（Service）與受控的負載均衡器、 IP 地址、網路包過濾、目標健康檢查等雲基礎設施組件集成。 服務控制器與雲驅動的 API 交互，以配置負載均衡器和其他基礎設施組件。

Kubernetes 安全性

雲原生安全

雲原生安全4個C: 雲(Cloud)、集群(Cluster)、容器(Container)和代碼(Code)

雲原生安全模型的每一層都是基於下一個最外層，代碼層受益於強大的基礎安全層（雲、集群、容器）。我們無法通過在代碼層解決安全問題來為基礎層中糟糕的安全標准提供保護。

基礎設施安全

Kubetnetes 基礎架構關注領域

建議

通過網路訪問 API 服務（控制平面)

所有對 Kubernetes 控制平面的訪問不允許在 Internet 上公開，同時應由網路訪問控制列表控制，該列表包含管理集群所需的 IP 地址集。

通過網路訪問 Node（節點)

節點應配置為 僅能 從控制平面上通過指定埠來接受（通過網路訪問控制列表）連接，以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務連接。如果可能的話，這些節點不應完全暴露在公共互聯網上。

Kubernetes 雲訪問提供商的 API

每個雲提供商都需要向 Kubernetes 控制平面和節點授予不同的許可權集。為集群提供雲提供商訪問許可權時，最好遵循對需要管理的資源的最小特權原則。Kops 文檔提供有關 IAM 策略和角色的信息。

訪問 etcd

對 etcd（Kubernetes 的數據存儲）的訪問應僅限於控制平面。根據配置情況，你應該嘗試通過 TLS 來使用 etcd。更多信息可以在 etcd 文檔中找到。

etcd 加密

在所有可能的情況下，最好對所有驅動器進行靜態數據加密，但是由於 etcd 擁有整個集群的狀態（包括機密信息），因此其磁碟更應該進行靜態數據加密。

集群組件安全

• 運行的應用程序的安全性關注領域
  • 訪問控制授權(訪問 Kubernetes API)
  • 認證方式
  • 應用程序 Secret 管理 (並在 etcd 中對其進行靜態數據加密)
  • Pod 安全策略
  • 服務質量（和集群資源管理）
  • 網路策略
  • Kubernetes Ingress 的 TLS 支持

容器安全

• 容器安全性關注領域
  • 容器搭建配置(配置不當,危險掛載, 特權用戶)
  • 容器服務自身缺陷
  • Linux內核漏洞
  • 鏡像簽名和執行

代碼安全

• 代碼安全關注領域
  • 僅通過 TLS 訪問(流量加密)
  • 限制通信埠范圍
  • 第三方依賴性安全
  • 靜態代碼分析
  • 動態探測攻擊(黑盒)

Kubernetes架構常見問題

Kubernetes ATTACK 矩陣

信息泄露

雲賬號AK泄露

API憑證（即阿里雲AccessKey）是用戶訪問內部資源最重要的身份憑證。用戶調用API時的通信加密和身份認證會使用API憑證.

API憑證是雲上用戶調用雲服務API、訪問雲上資源的唯一身份憑證。

API憑證相當於登錄密碼，用於程序方式調用雲服務API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有關Kubernetes集群的詳細信息，包括它們的位置和憑據。

雲廠商會給用戶提供該文件,以便於用戶可以通過kubectl對集群進行管理. 如果攻擊者能夠訪問到此文件（如辦公網員工機器入侵、泄露到Github的代碼等），就可以直接通過API Server接管K8s集群，帶來風險隱患。

Master節點SSH登錄泄露

常見的容器集群管理方式是通過登錄Master節點或運維跳板機，然後再通過kubectl命令工具來控制k8s。

雲伺服器提供了通過ssh登陸的形式進行登陸master節點.

若Master節點SSH連接地址泄露,攻擊者可對ssh登陸進行爆破,從而登陸上ssh,控制集群.

容器組件未鑒權服務

Kubernetes架構下常見的開放服務指紋如下:

• kube-apiserver: 6443, 8080
• kubectl proxy: 8080, 8081
• kubelet: 10250, 10255, 4149
• dashboard: 30000
• docker api: 2375
• etcd: 2379, 2380
• kube-controller-manager: 10252
• kube-proxy: 10256, 31442
• kube-scheler: 10251
• weave: 6781, 6782, 6783
• kubeflow-dashboard: 8080

注:前六個重點關注: 一旦被控制可以直接獲取相應容器、相應節點、集群許可權的服務

了解各個組件被攻擊時所造成的影響

組件分工圖:

假如用戶想在集群裡面新建一個容器集合單元, 流程如下:

1. 用戶與 kubectl進行交互,提出需求(例: kubectl create -f pod.yaml)
2. kubectl 會讀取 ~/.kube/config 配置，並與 apiserver 進行交互，協議：http/https
3. apiserver 會協同 ETCD, kube-controller-manager, scheler 等組件准備下發新建容器的配置給到節點，協議：http/https
4. apiserver 與 kubelet 進行交互，告知其容器創建的需求，協議：http/https；
5. kubelet 與Docker等容器引擎進行交互，創建容器，協議：http/unix socket.
6. 容器已然在集群節點上創建成功

攻擊apiserver

apiserver介紹:
在Kubernetes中,對於未鑒權對apiserver, 能訪問到 apiserver 一般情況下就能獲取了集群的許可權.

在攻擊者眼中Kubernetes APIServer

• 容器編排K8S總控組件
• pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,
• endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,
• persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …
• 可控以上所有k8s資源
• 可獲取幾乎所有容器的互動式shell
• 利用一定技巧可獲取所有容器母機的互動式shell

默認情況下apiserver都有鑒權:

未鑒權配置如下:

對於這類的未鑒權的設置來說，訪問到 apiserver 一般情況下就獲取了集群的許可權：

如何通過apiserver來進行滲透,可參考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

攻擊kubelet

每一個Node節點都有一個kubelet(每個節點上運行的代理)服務，kubelet監聽了10250，10248，10255等埠。

10250埠,是kubelet與apiserver進行通信對主要埠, 通過該埠,kubelet可以知道當前應該處理的任務.該埠在最新版Kubernetes是有鑒權的, 但在開啟了接受匿名請求的情況下，不帶鑒權信息的請求也可以使用10250提供的能力, 在Kubernetes早期,很多挖礦木馬基於該埠進行傳播.

在配置文件中,若進行如下配置,則可能存在未授權訪問漏洞.

/var/bin/kubulet/config/yaml

若10250埠存在未授權訪問漏洞,我們可以直接訪問/pods進行查看

根據在pods中獲取的信息,我們可以在容器中執行命令

curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} -d 'input=1' -d 'output=1' -d 'tty=1' -d 'command=whoami'

上述命令得到websocket地址，連接websocket得到命令結果：

使用wscat工具連接websocket

wscat -c 「https://X.X.X.X:10250/{websocket}」 --no-check

即可得到我們執行命令的結果.

獲取token

/var/run/secrets/kubernetes.io/serviceaccount

然後即可訪問kube-api server,獲取集群許可權

curl -ks -H "Authorization: Bearer ttps://master:6443/api/v1/namespaces/{namespace}/secrets

"

攻擊kubelet總體步驟如下:

• 訪問pods獲取信息
• 獲取namespace、podsname、containername
• 執行exec獲取token
• /var/run/secrets/kubernetes.io/serviceaccount
• 利用Token訪問API Server進行對pods操作。

攻擊dashboard

dashboard登陸鏈接如下:

http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的圖形化界面.在Kubernetes配置不當導致dashboard未授權訪問漏洞的情況下，通過dashboard我們可以控制整個集群。

默認情況下, dashboard是需要進行鑒權操作的,當用戶開啟了enable-skip-login時可以在登錄界面點擊Skip跳過登錄進入dashboard.

通過skip登陸的dashboard默認是沒有操作集群的許可權,因為Kubernetes使用RBAC(Role-based access control)機制進行身份認證和許可權管理，不同的serviceaccount擁有不同的集群許可權。

但有些開發者為了方便或者在測試環境中會為Kubernetes-dashboard綁定cluster-admin這個ClusterRole（cluster-admin擁有管理集群的最高許可權）.

為Kubernetes-dashboard綁定cluster-admin 設置如下:

1. 新建dashboard-admin.yaml內容
2. apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
3. kubectl create -f dashboard-admin.yaml

後通過skip登陸dashboard便有了管理集群的許可權.

創建Pod控制node節點,該pod主要是將宿主機根目錄掛載到容器tmp目錄下。

新建一個Pod如下:

通過該容器的tmp目錄管理node節點的文件

攻擊etcd

Kubernetes默認使用了etcd v3來存儲數據, 若能na
etcd對內暴露2379埠，本地127.0.0.1可免認證訪問. 其他地址要帶—endpoint參數和cert進行認證。

未授權訪問流程:

• 檢查是否正常鏈接
• etcdctl endpoint health
• 讀取service account token
• etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
• 通過token認訪問API-Server埠6443，接管集群：
• kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="[ey...]" -n kube-system get pods

攻擊docker remote api(Docker daemon公網暴露)

2375是docker遠程操控的默認埠，通過這個埠可以直接對遠程的docker 守護進程進行操作。Docker 守護進程默認監聽2375埠且未鑒權.

當機器以方式啟動daemon時，可以在外部機器對該機器的docker daemon進行直接操作：

docker daemon -H=0.0.0.0:2375

之後依次執行systemctl daemon-reload、systemctl restart docker

外部主機使用 即可操作暴露2375埠的主機.

-H

因此當你有訪問到目標Docker API 的網路能力或主機能力的時候，你就擁有了控制當前伺服器的能力。我們可以利用Docker API在遠程主機上創建一個特權容器，並且掛載主機根目錄到容器.

檢測目標是否存在docker api未授權訪問漏洞的方式也很簡單，訪問http://[host]:[port]/info路徑是否含有ContainersRunning、DockerRootDir等關鍵字。

攻擊kubectl proxy

二次開發所產生的問題

管理Kubernetes無論是使用 kubectl 或 Kubernetes dashboard 的UI功能，其實都是間接在和 APIServer 做交互.

如果有需求對k8s進行二次開發的話,大部分的開發功能請求了 APIServer 的 Rest API 從而使功能實現的。

例如:

• 給用戶銷毀自己POD的能力
• DELETE https://apiserver:8443/api/v1/namespaces/default/pods/sleep-75c6fd99c-g5kss

類似於這樣去調用apiserver, 攻擊者若修改namespace、pod和容器名, 那麼即可造成越權.

推薦工具

Kube-Hunter掃描漏洞

kube-hunter是一款用於尋找Kubernetes集群中的安全漏洞掃描器

下載地址: https://github.com/aquasecurity/kube-hunter

CDK(強推)

CDK是一款為容器環境定製的滲透測試工具，在已攻陷的容器內部提供零依賴的常用命令及PoC/EXP。集成Docker/K8s場景特有的 逃逸、橫向移動、持久化利用方式，插件化管理。

下載地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN

參考鏈接

https://developer.aliyun.com/article/765449?groupCode=aliyunsecurity
https://xz.aliyun.com/t/4276#toc-2
https://www.secrss.com/articles/29544
https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-pod
https://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.html
https://www.kubernetes.org.cn/service-account
https://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
https://www.cdxy.me/?p=827

E. 雲容器和虛擬機哪個好

原生的對立面當然是非原生（虛擬化），即使是在CPU 和操作系統內核支持的情況下虛擬機上的操作系統及業務系統所使用硬體資源仍然不直接定址的。一個基於虛擬機運行的業務系統與原生操作系統中間隔著一個虛擬系統，有如人與人之間隔閡，不僅會損失硬體性能還會讓多可以直接定址的介面操作都需要驅動級的映射才能完成，兼容性的問題有時也困擾運維人員。而容器技術越發成熟之後各個沙盒間的相互獨立互不影響，卻能直接使用原生系統的資源。硬體資源的利用率更高。而且容器的創建與維護比虛擬機更簡單，一個業務系統在虛擬機上交付，需要有足夠的資源來創建虛擬機，然後為虛擬機安裝操作系統、部署業務系統所需的各種支持環境。如果多個業務系統所需要支持環境依賴庫間有沖突互斥你則需要新建更多的虛擬機。反之對於容器而言只需要再開一個鏡像即可。

雲原生更節省物理伺服器的硬體資源；更易於業務系統的快速交付。是微服務架構、無伺服器架構的時代這項技術更為雲平台服務提供了基礎支撐，在虛擬化時代一個開發人員為了發布自己的應用，需要去租用一個雲主機或VPS ，自由的按需配置管理雲主機的操作系統與支持環境配置及參數，然後發布自己業務和WEB應用。在採用無服務架構在模式下，你可能根本不需要一台伺服器，更不用去關於如何去配置伺服器，需要只是服務本身，雲端的容器中的WEB 服務或資料庫服務會提供介面給開發者，開發者只用關心程序的實現，不用折騰伺服器與環境的配置。

F. 容器雲技術有什麼特點

1.容器雲技術在計算形態上面是一種輕量級的虛擬化技術，是進程級的虛擬化形態封裝，容器的啟動和部署的迅速，可以在應用層面按照資源進行快速的部署和調度的，這樣生命周期的變化速度也就很快了。
2.它是可以移植的一種技術，能夠降低成本。當前容器雲技術的現代形式，主要是體現在應用程序容器化和系統容器化方面。這兩種形式的容器都是可以讓IT團隊從底層的架構中抽象出程度代碼的，這樣就可以實現跨各種部署環境的可移植性了。
3.容器一般是位於物理伺服器以及主機操作系統之上的。它可以通過單個的操作系統安裝去運行多個工作環境，因此容器是非常輕的，它們只有幾兆的位元組，只需要幾秒鍾就可以啟動了。另外，內存，存儲和CPU效率的提高，是容器雲技術的關鍵優勢。它可以在同一基礎架構上面支持更多的容器，這樣就可以減少管理方面的開支了。
國內做的比較好的我推薦時速雲，他們服務過500+的中大型客戶，不僅涵蓋容器雲 PaaS、DevOps、微服務、ServiceMesh、API 網關等核心雲原生產品，還可以為企業提供數據開發、數據治理、數據資產、數據服務等數據能力。感興趣的可以去了解一下！

G. 容器雲部署前後應該注意的事情有哪些

第一，在進行容器雲部署之前先要做到事情就是了解目標伺服器，因為伺服器締造了整個系統的環境，因此就要先了解其特徵如何。像伺服器的內存參數多大以及伺服器的代碼優化做到哪一步，這些都會和項目所需要的內存多大以及代碼性能優化工作有直接關系，同樣是在部署之前要做的工作還有對於資料庫的了解和目標機器的基本了解等。
第二，在進行容器雲部署的時候自然要委託專業團隊來做，這里需要專業的開發團隊，可以了解一下時速雲的案例，他們服務過500+的中大型客戶，有豐富的經驗，過程中要注意隨時記錄問題。在實際部署過程中需要考慮的情況很多，更多的問題都是需要隨機應變的，同時還應該注意的就是使用的軟體應該是新版本的以及網路環境的勘測和了解。
第三，在容器雲部署之後還要重視客戶的反饋情況，然後根據客戶反饋來進行系統的隱患排查和代碼程序的優化，同時還要注意的就是反饋後找到系統中同類問題，這樣才能更好的進行優化。

H. 容器雲技術的優勢是什麼

1.容器雲技術在計算形態上面是一種輕量級的虛擬化技術，是進程級的虛擬化形態封裝，容器的啟動和部署的迅速，可以在應用層面按照資源進行快速的部署和調度的，這樣生命周期的變化速度也就很快了。
2.它是可以移植的一種技術，能夠降低成本。當前容器雲技術的現代形式，主要是體現在應用程序容器化和系統容器化方面。這兩種形式的容器都是可以讓IT團隊從底層的架構中抽象出程度代碼的，這樣就可以實現跨各種部署環境的可移植性了。
3.容器一般是位於物理伺服器以及主機操作系統之上的。它可以通過單個的操作系統安裝去運行多個工作環境，因此容器是非常輕的，它們只有幾兆的位元組，只需要幾秒鍾就可以啟動了。另外，內存，存儲和CPU效率的提高，是容器雲技術的關鍵優勢。它可以在同一基礎架構上面支持更多的容器，這樣就可以減少管理方面的開支了。
國內做的比較好的我推薦時速雲，他們服務過500+的中大型客戶，不僅涵蓋容器雲 PaaS、DevOps、微服務、ServiceMesh、API 網關等核心雲原生產品，還可以為企業提供數據開發、數據治理、數據資產、數據服務等數據能力。感興趣的可以去了解一下！

I. 容器雲是什麼技術對比於虛擬機有什麼特點

容器雲是近兩年在雲計算技術中新興的一種產品形式，容器在計算形態上是歸屬於輕量級的虛擬化技術。和傳統虛擬化內核級的Guest OS的封裝不同，容器服務是進程級的虛擬化形態封裝，啟動速度和部署的速度都十分迅速，能夠在應用層面根據資源的需求進行快速部署與調度，生命周期變化速度快。
之所以會有容器雲的出現，主要還是因為時代的發展趨勢所導致。由於在2010年，國外Cloud，Docker等容器技術剛剛創立，這無非給雲計算指明了一條明確的道理，此後K8s和Docker等技術就火的一塌糊塗。
而對比於傳統虛擬機，容器雲有什麼特點呢？
一：可移植性
目前容器技術主要體現在應用程序容器化（Docker）和系統容器化上。這兩種形式的容器都能讓IT團隊從底層架構中抽象出程序代碼，進一步實現各種部署環境的可移植性。
二：輕量級
容器通常部署在物理伺服器及其主機操作系統上，它可以通過單個操作系統安裝來運行多個工作環境，因此容器雲特別「輕」，僅僅需要幾秒鍾就可以啟動。
三：降低成本
與傳統虛擬機相比，CPU,內存和存儲效率的提高是容器技術最大優勢。在同一基礎架構上支持更多容器，那麼這些資源的減少就轉化成巨大的成本，同時也大大減少了管理開銷。

J. 什麼是容器雲

容器雲是PaaS 層的雲交付模式。容器雲可以通過兩種方式部署：一種是在虛擬機上部署容器(在許多傳統企業中，容器部署在虛擬機上)；另一種方法是在裸機伺服器上直接部署容器。將容器部署到虛擬機的原因是它們需要虛擬機的隔離和安全特性。
事實上，為了達到同樣的效果，不需要使用虛擬機，或者隨著技術的發展，這些問題都有可能在容器中解決。將來，那些可以在虛擬機上運行的應用程序可以運行到容器中，因此容器雲將取代傳統的IaaS。然而，對於大多數企業來說，這仍然是一件相對遙遠的事情。現在，最重要的是結合自身實際需要，充分利用集裝箱技術。
無論是虛擬機與容器的結合，還是容器直接部署在裸金屬伺服器上，只要容器技術能為企業創造業務價值，就有價值和意義。