❶ 2021-10-這一篇 K8S（Kubernetes）我覺得可以了解一下！！！28
Kubernetes 是Google開源的分布式容器管理平台，是為了更方便的在伺服器中管理我們的容器化應用。
Kubernetes 簡稱 K8S，為什麼會有這個稱號？因為K和S是 Kubernetes 首字母和尾字母，而K和S中間有八個字母，所以簡稱 K8S，加上 Kubernetes 比較繞口，所以一般使用簡稱 K8S。
Kubernetes 即是一款容器編排工具，也是一個全新的基於容器技術的分布式架構方案，在基於Docker的基礎上，可以提供從 創建應用>應用部署>提供服高絕務>動態伸縮>應用更新 一系列服務，提高了容器集群管理的便捷性。
大家可以先看一下，下面一張圖，裡面有我們的 mysql，redis，tomcat，nginx 等配置信息，如果我們想要安裝裡面的數據，我們需要一個一個手動安裝，好像也可以，反正也就一個，雖然麻煩了一點，但也不耽誤。
但是隨著技術的發展和業務的需要，單台伺服器已經不能滿足我們日常的需要了，越來越多的公司，更多需要的是集群環境和多容器部署，那麼如果還是一個一個去部署，運維恐怕要瘋掉了，一天啥也不幹就去部署機器了，有時候，可能因為某一個環節出錯，要重新，那真的是吐血。。。。。，如下圖所示：
如果我想要部署，以下幾台機器：
如果要一個一個去部署，人都要傻掉了，這什麼時候是個頭，如果是某里巴的兩萬台機器，是不是要當場提交辭職信，所以 K8S 就是幫助我們來做這些事情的，方便我們對容器的管理和應用的自動化部署，減少重復勞動，並且能夠自動化部署應用和故障自愈。
並且如果 K8S 對於微服務有很好的支持，並且一個微服務的副本可以跟著系統的負荷變化進行調整，K8S 內在的服務彈性擴容機制也能夠很好的應對突發流量。
Docker-Compose 是用來管理容器的，類似用戶容器管家，我們有N多台容器或者應用需要啟動的時候，如果手動去操作，是非常耗費時間的，如果有了 Docker-Compose 只需要一個配置文件就可以幫我們搞定，但是 Docker-Compose 只能管理當前主機上的 Docker，不能去管理其他伺服器上的服務。意思就是單機環境。
Docker Swarm 是由Docker 公司研發的一款用來管理集群上的Docker容器工具，彌補了 Docker-Compose 單節點的缺陷， Docker Swarm 可以幫助我們啟動容器，監控容器的狀態，如果容器服務掛掉會重新啟動一個新的容器，保證正常的對外提供服務，也支持服務之間的負載均衡。而且這些東西 Docker-Compose 是不支持的，
Kubernetes 它本身的角色定位是和 Docker Swarm 是一樣的，也就是說他們負責的工作在容器領域來說是相同的部分，當然也要一些不一樣的特點， Kubernetes 是谷歌自己的產品，經過大量的實踐和宿主機的實驗，非常的成熟，所以 Kubernetes 正在成為容器編排領域的領導者，其 可配戚則姿置性、可靠性和社區的廣大支持，從而超越了 Docker Swarm ，作為谷歌的開源項目，它和整個谷歌的雲平台協調工作。
在下圖中，是K8S的一個集群，在這個集群中包含三台宿主機，這里的每一個方塊都是我們的物理虛擬機，盯悔通過這三個物理機，我們形成了一個完整的集群，從角色劃分，可以分為兩種
打一個比較形象的比喻，我們可以把Pod理解成一個豆莢，容器就是裡面的豆子，是一個共生體。
Pod裡面到底裝的是什麼？
具體怎麼部署Pod裡面的容器，是按照我們項目的特性和資源的分配進行合理選擇的。
pause容器：
Pause容器 全稱infrastucture container（又叫infra）基礎容器，作為init pod存在，其他pod都會從pause 容器中fork出來，這個容器對於Pod來說是必備的
一個Pod中的應用容器共享同一個資源：
在上圖中如果沒有 pause容器 ，我們的Nginx和Ghost，Pod內的容器想要彼此通信的話，都需要使用自己的IP地址和埠，才可以彼此進行訪問，如果有 pause容器 ，對於整個Pod來說，我們可以看做一個整體，也就是我們的Nginx和Ghost直接使用localhost就可以進行訪問了，他們唯一不同的就只是埠，這裡面可能看著覺得比較簡單，但其實是使用了很多網路底層的東西才實現的，感興趣的小夥伴可以自行了解一下。
在 Kubernetes 中，每個Pod都會被分配一個單獨的IP地址，但是Pod和Pod之間，是無法直接進行交互的，如果想要進行網路通信，必須要通過另外一個組件才能交流，也就是我們的 Service
Service 是服務的意思，在K8S中 Service 主要工作就是將多個不同主機上的Pod，通過 Service 進行連通，讓Pod和Pod之間可以正常的通信
我們可以把 Service 看做一個域名，而相同服務的Pod集群就是不同的ip地址， Service 是通過 Label Selector 來進行定義的。
使用NodePort提供外部訪問，只需要在每個Node上打開一個主機的真實埠，這樣就可以通過Node的客戶端訪問到內部的Service。
Label 一般以 kv的方式附件在各種對象上，Label 是一個說明性的標簽，它有著很重要的作用，我們在部署容器的時候，在哪些Pod進行操作，都需要根據Label進行查找和篩選，我們可以理解Label是每一個Pod的別名，只有取了名稱，作為K8S的Master主節點才能找到對應的Pod進行操作。
用戶通過 Kubectl 提交一個創建 Replication Controller 請求，這個請求通過 API Server 寫入 etcd 中，這個時候 Controller Manager 通過 API Server 的監聽到了創建的命名，經過它認真仔細的分析以後，發現當前集群裡面居然還沒有對應的Pod實例，趕緊根據 Replication Controller 模板定義造一個Pod對象，再通 過Api Server 寫到我們 etcd 裡面
到下面，如果被 Scheler 發現了，好傢伙不告訴我？？？，無業遊民，這傢伙一看就不是一個好人啊，它就會立即運行一個復雜的調度流程，為這個新的Pod選一個可以落戶的Node，總算有個身份了，真是讓人操心，然後通過 API Server 將這個結果也寫到etcd中，隨後，我們的 Node 上運行的小管家 Kubelet 進程通過 API Server 檢測到這個 新生的小寶寶——「Pod」，就會按照它，就會按照這個小寶寶的特性，啟動這個Pod並任勞任怨的負責它的下半生，直到Pod的生命結束。
然後我們通過 Kubectl 提交一個新的映射到這個Pod的Service的創建請求， Controller Manager 會通過Label標簽查詢到相關聯的Pod實例，生成Service的Endpoints的信息，並通過 API Server 寫入到etcd中，接下來，所有 Node 上運行的Proxy進程通過 Api Server 查詢並監聽 Service對象 與其對應的 Endpoints 信息，建立一個軟體方式的負載均衡器來實現 Service 訪問到後端Pod的流量轉發功能。
kube-proxy： 是一個代理，充當這多主機通信的代理人，前面我們講過Service實現了跨主機、跨容器之間的網路通信，在技術上就是通過 kube-proxy 來實現的，service是在邏輯上對Pod進行了分組，底層是通過 kube-proxy 進行通信的
kubelet： 用於執行K8S的命令，也是K8S的核心命令，用於執行K8S的相關指令，負責當前Node節點上的Pod的創建、修改、監控、刪除等生命周期管理，同時Kubelet定時「上報」本Node的狀態信息到API Server里
etcd： 用於持久化存儲集群中所有的資源對象，API Server提供了操作 etcd的封裝介面API，這些API基本上都是對資源對象的操作和監聽資源變化的介面
API Server ： 提供資源對象的操作入口，其他組件都需要通過它提供操作的API來操作資源數據，通過對相關的資源數據「全量查詢」+ 「變化監聽」，可以實時的完成相關的業務功能。
Scheler ： 調度器，負責Pod在集群節點中的調度分配。
Controller Manager： 集群內部管理控制中心，主要是實現 Kubernetes 集群的故障檢測和恢復的自動化工作。比如Pod的復制和移除，Endpoints對象的創建和更新，Node的發現、管理和狀態監控等等都是由 Controller Manager 完成。
到這里K8S的基本情況我們就講解完畢了，有喜歡的小夥伴記得 點贊關注 ，相比如Docker來說K8S有著更成熟的功能，經過谷歌大量實踐的產物，是一個比較成熟和完善的系統。
關於K8S大家有什麼想要了解或者疑問的地方歡迎大家留言告訴我。
我是牧小農，一個卑微的打工人，如果覺得文中的內容對你有幫助，記得一鍵三連，你們的三連是小農最大的動力。
❷ 通過K8S部署對象存儲MinIO
MinIO 是全球領先的對象存儲先鋒，以 Apache License v2.0 發布的對象存儲伺服器，是為雲應用和虛擬機而設計的分布式對象存儲伺服器。在標准硬體上，讀/寫速度上高達183GB/s和171GB/s。它與 Amazon S3 雲存儲服務兼容。 它最適用租察於存儲非結構迅念化數據，如照片、視頻、日誌文件、備份和容器/虛擬機映像。 對象的大小可以從幾KB 到最大5TB。
MinIO是一個非常輕量的服務,可以很簡單的和其他應用的結弊昌茄合，類似 NodeJS, Redis 或者 MySQL。
MinIO支持多種靈活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，詳見官網： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux
這里著重介紹K8S下部署
1、standalone模式
由於service採用NodePort類型，通過主機IP:32593訪問web
2、distributed模式
分布式部署，實例數至少4個，所以需要另外創建4個pv
❸ 請問一下，伺服器、雲伺服器和虛擬主機有什麼區別
物理伺服器是一種為客戶機提供服務的高性能計算機，是構建雲計算和數據中心的最核心基礎設備，而雲伺服器和虛擬主機都是基於雲計算技術進行研發的。伺服器、雲伺服器和虛擬主機的區別主要表現在以下幾個方面：
1、性能方面：伺服器的性能好壞影響著後續開發的使用效果，所以伺服器必須要有承擔服務、保障服務的能力。物理伺服器的高性能主要體現在高速度的運算能力、長時間的可靠運行、強大的外部數據吞吐能力等方面，性能方面是最好的。由於雲伺服器屬於公有性質，它的性能瓶頸受到底層伺服器的硬體制約。而虛擬主機在使用中一旦數據訪問量過大，就會變得卡慢，而且虛擬主機升級也比較麻煩。
2、安全性：傳統的物理伺服器是獨立伺服器，只有一個操作系統直接安裝在伺服器上，專用於單個租戶，租戶與租戶之間是基於物理隔離，安全性最高。雲伺服器基於雲計算的架構，可自主切換故障節點到正常的主機，其穩定性較強，提供多種數據恢復的措施，安全性也是可以的。虛擬主機由於帶寬是共享的，虛擬主機使用共享IP的話，安全性就會降低。
3、實惠性：隨著雲平台的產品的推廣逐漸得到大眾的認可，雲的發展前景越來越好，雲伺服器的價格也有所降低。這樣，用戶不僅可以節約自身成本，還能獲得高性能、可靈活擴展的計算機資數前源。與傳統物理伺服器相比，雲伺服器更經濟實惠。虛擬主機跟相同配置的雲伺服器相比，會更便宜一些。
4、靈活擴展性：雲伺服器可支持彈性擴展，可根據需求選擇雲伺服器再付費。當伺服器性能不能滿足企業或用戶的業務發展需求時，可以隨時進行擴容，升級雲伺服器的主衫彎機CPU、內存、硬碟和帶寬等系統配置，能夠靈活擴展。而虛擬主機的升級或擴容就相對麻煩，需重新租用新的虛擬主機空間。
5、技能門檻：雲伺服器通常在控制台中提供先進的管理功能，使雲伺服器的管理變得更加簡單。虛擬主機同樣管理相對簡單，使用效率更高。物理伺服器則需要具備伺服器配置知識、細致的薯塌清規劃和管理，以及了解相關所需的資源，需要較為完備的知識儲備。
總體來說，雲伺服器的綜合能力是最平均的，隨著雲計算技術的不斷發展，在信息化建設模式上上雲是大勢所趨。由數通暢聯自主研發的UMC雲管理平台是雲平台開發、部署、管理、運維的統一管理中心，對K8S集群配置、運行狀態等進行統一管理，滿足雲原生四個基本要素：容器化、微服務、DevOPS持續交付、多租戶管理。由UMC、容器化的AEAI套件及CI/CD管理機制組合形成了AEAIiPaaS平台。主要通過連接、協同實現業務集成，支撐業務中台，通過連接、共享實現數據集成，成就數據中台。
❹ 雲計算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：日新月異的中國保險業
❺ 什麼是K8S
k8s是什麼?
Kubernetes 是一個可移植的，可擴展的開源容器編排平台，用於管理容器化的工作負載和服務，方便了聲明式配置和自動化。它擁有一個龐大且快速增長的生態系統。Kubernetes 的服務，支持和工具廣泛可用。
為什麼現在流行使用容器?
早期: 在物理伺服器上面部署應用程序存在資源分配問題,因為其不能在物理伺服器中的應用程序定義資源邊界,導致應用程序資源利用不足而無法擴展.
後來: 為了解決該問題,引入了虛擬化技術, 虛擬化技術是指允許你在單個物理伺服器的 CPU 上運行多個虛擬機,可以讓多個應用程序在虛擬機之間進行隔離,具有一定的安全性, 每一個虛擬機就是一台完整的計算機, 在虛擬化硬體之上運行所有組件.
現在: 多數在物理伺服器上面部署應用程序都是采kubectl用容器的方式,容器類似於虛擬機,它們都具有自己的文件系統、CPU、內存、進程空間等, 且由於它們與基礎架構分離，因此可以跨雲和 OS 發行版本進行移植。基於此特點被企業大范圍使用.
為什麼需要使用k8s容器?
若出現這樣一個環境: 在生產環境中如果一個容器發生故障,則我們需要手動去啟動另外一個容器,這樣的操作是對我們的管理員來說是不太方便的, 若一個容器出現故障,另一個容器可以自動啟動容器接管故障的容器,這樣是最好的.
k8s就可以實現該效果,Kubernetes 提供了一個可彈性運行分布式系統的框架。 Kubernetes 會滿足你的擴展要求、故障轉移、部署模式等。
k8s功能: 服務發現和負載均衡, 存儲編排, 自動部署和回滾, 自動完成裝箱計算, 自我修復, 密鑰與配置管理
名詞解釋
secret
Secret有三種類型：
k8s的組成
k8s是由組件,API,對象等組成.
包含所有相互關聯組件的 Kubernetes 集群圖如下:
組件
API
Kubernetes 控制面 的核心是 API 伺服器。 API 伺服器負責提供 HTTP API，以供用戶、集群中的不同部分和集群外部組件相互通信。
對象
Kubernetes對象是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示集群的狀態.
具體來說，他們可以描述：
Kubernetes 架構
Kubernetes 架構由節點,控制面到節點通信, 控制器, 雲控制器管理器組成.
master 流程圖
節點
節點可以是一個虛擬機或者物理機器，取決於所在的集群配置。 每個節點包含運行 Pods 所需的服務， 這些 Pods 由 控制面 負責管理.
節點上的組件包括 kubelet、 容器運行時以及 kube-proxy。
節點狀態
可以使用 kubectl 來查看節點狀態和其他細節信息：
kubectl describe node <�節點名稱>
一個節點包含以下信息:
控制面到節點通信
控制器
在 Kubernetes 中，控制器通過監控集群 的公共狀態，並致力於將當前狀態轉變為期望的狀態。
舉個例子: 當前室內溫度為20度, 我們通過調節遙控器,使其溫度上升至24度, 這20度到24度的變化即為讓其從當前狀態接近期望狀態。
控制器模式分為直接控制和通過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架構常見問題
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架構下常見的開放服務指紋如下:
注:前六個重點關注: 一旦被控制可以直接獲取相應容器、相應節點、集群許可權的服務
了解各個組件被攻擊時所造成的影響
組件分工圖:
假如用戶想在集群裡面新建一個容器集合單元, 流程如下:
攻擊apiserver
apiserver介紹:
在Kubernetes中,對於未鑒權對apiserver, 能訪問到 apiserver 一般情況下就能獲取了集群的許可權.
在攻擊者眼中Kubernetes APIServer
默認情況下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總體步驟如下:
攻擊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 設置如下:
後通過skip登陸dashboard便有了管理集群的許可權.
創建Pod控制node節點,該pod主要是將宿主機根目錄掛載到容器tmp目錄下。
新建一個Pod如下:
通過該容器的tmp目錄管理node節點的文件
攻擊etcd
Kubernetes默認使用了etcd v3來存儲數據, 若能na
etcd對內暴露2379埠，本地127.0.0.1可免認證訪問. 其他地址要帶—endpoint參數和cert進行認證。
未授權訪問流程:
攻擊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 從而使功能實現的。
例如:
類似於這樣去調用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
❻ k8s之存儲
k8s的存儲常用的就是上面幾種模式，分為臨時存儲，半持久化存儲鏈消，與持久化存儲這三類，本章我們著重講解emptydir與hostpath與pvc跟pv等
當pod的存儲方案設定為emptydir的時候，pod啟動時，就會在pod所在節點的磁碟空間開辟出一塊空卷，最開始裡面是什麼都沒有的，pod啟動後容器產生的數據會存放到那個空卷中。空卷變成了一個臨時卷
供pod內的容器讀取和寫入數據，一旦pod容器消失，節點上開辟出的這個臨時卷就會隨著pod的銷毀而銷毀
一般來說emptydir的用途都是用來充當臨時存儲空間，例如一些不需要數據持久化的微服務，我們都可以用emptydir來當做微服務pod的存儲方案
k8s存儲emptdir實戰例子：以之前的myapp應用為例
創建應用
觀察是否生產data目錄，並在/data目錄創建文件test.txt
手動刪除容器模擬容器銷毀，用於是pod是被控制器管理的，刪除後會被重建新棚橘知的pod
這時候在看我們之前創建的data.txt已經不見了
hostPath類型則是映射node文件系統中的文件或者目錄到pod里。在使用hostPath類型的存儲卷時，也可以設置type欄位，支持的類型有文件、目錄、File、Socket、CharDevice和BlockDevice（我只映射過文件與目錄）。
其實這個功能就相當於docker中的-v 目錄映射，只不過在k8s中的時候，pod會漂移，當pod漂移到其他node節點的時候，pod不會跨節點的去讀取目錄。所以說hostpath只能算一種半持久化的存儲方式
實戰例子
創建應用
在node節點可以看到生成了/data/volume目錄，在裡面創建測試文件
檢驗pod裡面的/data是否存在這個映射目錄的文件
可以看到剛才創建的文件已經映射到我們的目錄里邊了
為了驗證是否映射到容器裡面的目錄也會隨著pod生命周期的消失而消失，我們手動刪除pod模擬容器終止
可以看到容器被刪除後，新建的pod也可以看到我們映射的目錄，而且裡面數據test.txt還在伍伏。
這有個缺點就是不能夠跨容器去讀取數據，如果刪除後的pod被調度到其他節點的話，原來的數據也就沒有了，如果能不受節點的影響，並且掛載的數據不會隨生命周期的結束而結束，我們應該怎麼解決呢？就是我們後面講到的持久化存儲了
上面介紹了倆種臨時存儲於半持久化存儲的方案。在k8s實際生產環境中，一般會選用私有雲持久化存儲方案還有公有雲持久化存儲方案，私有雲存儲方案包括nfs，ceph，glusterfs等方案。公有雲存儲會用到AWS等方案
存儲方案各有各的優缺點，可參考 https://www.cnblogs.com/yswenli/p/7234579.html 這篇文章。今天我們主要講解pvc，pv，nfs之間的關系。
簡單來說，要使用持久化存儲，就需要使用pvc去跟pv去申請，然後pv查看自己有沒有合適的存儲空間卷，有合適的就與pvc進行綁定。pv與pvc是一一對應綁定的。現在我們用一幅圖來說明pvc，pv，nfs的關系
實戰例子
准備存儲服務安裝nfs
接下來創建pv與nfs綁定
創建pvc與pv關聯
創建並查看結果
注意：STATUS為Bound說明該pvc已經與pv綁定了
接下來創建pod來引用pvc
創建pod
接下來驗證一下在nfs創建一個測試文件，看是否被映射到容器中
可以看到容器裡面也可以看到創建的文件
手動刪除容器，或者調度到其他節點原來的文件還是不會被刪除的，這里就省略驗證了，這就是nfs的好處，不過企業一般不會選用nfs，磁碟IO,性能讀取方面不太理想，畢竟是本地存儲，還是有一定的風險。推薦用用雲存儲。
文件存儲提供無限擴展的文件系統來給雲伺服器存取數據實際上相當於nfs
1、已注冊阿里雲賬號，並完成實名認證。
如果沒有，請先注冊阿里雲賬號，詳情請參見阿里雲賬號注冊流程。
2、已開通NAS服務。
首次登錄NAS控制台時，根據頁面提示開通NAS服務。
3、在需要創建文件系統的地域，已有可用的雲伺服器ECS。
k8s應用NAS實戰例子
1、打開阿里雲NAS控制台確認已創建好文件系統
2、把復制掛載參數把它掛載到伺服器中創建測試目錄，前提是伺服器需要安裝nfs客戶端。
安裝完成掛載到本地目錄並創建test目錄作為測試目錄
並在裡面創建一個測試文件1.txt
接下來可以創建pvc和pv了
創建並查看
接下來創建pod去引用pvc
創建pod
檢驗剛才的1.txt是否掛到容器的/data/nas下
雲存儲適合於生產環境k8s的存儲解決方案
❼ kubernetes cloud-provider for aliyun
CloudProvider 提供kubernetes與雲廠商基礎服務的對接能力，由 cloud-controller-manager組件實現(lb,雲盤，安全組等等)。
aliyun-cloud-provider這個組件主要是aliyun平台的對接插件，可以讓用戶在創建k8s LoadBalancer 類型的service的時候自動的為用戶創建一個阿里雲SLB，同時動態的綁定與解綁SLB後端，並且提供了豐富的配置允許用戶自定義生成的LoadBalancer.
其他cloud-provider比如aws可提供elb，ebs，安全組等能力，阿里雲這里實現了service_controller和route_controller，所以暫時只提供了對接slb資源，其他資源需要單獨插件在cloud-provider上層實現，比如cluster-autoscaler需依賴cloud-provider完成node初始化.
所以cloud-provider的能力僅僅對接雲廠商基礎服陵和歷務給kubernetes集群使用,我們使用aliyun-cloud-provider 主要也是對接aliyun ess資源，使用cluster-autoscaler動態/定時伸縮kubernetes node節點。
集群環境：
kubele 啟動參數添加--cloud-provider=external --hostname override= instance id--provider id= instance id參數並重啟kubelet。棚扮格式為 Instance。
以下命令可找到REGION_ID 和INSTANCE_ID
然後重啟kubelet kubectl get node 查看hostname是否生效，也可以delete node,重新注冊到集群。
cloud-provider需要一定的許可權才能訪問阿里雲，需要為ECS實例創建一些RAM策尺搜略，或者直接使用accesskeyid&secret，由於我們容器部署cloud-provider所以這里採用AK。
1.配置aliyun-cloud-provider AK(access key) 許可權
創建自定義策略，然後將策略綁定到k8s-cloud-provider用戶，創建其AK提供給aliyun-cloud-provider使用，保證只能訪問我們授權的資源。或者參考地址: https://github.com/kubernetes/cloud-provider-alibaba-cloud/blob/master/docs/examples/master.policy
創建cloud-config configmap 為cloud-provider提供配置，主要存放AK信息
替換$CA_DATA 為cat /etc/kubernetes/pki/ca.crt|base64 -w 0輸出結果或者kubectl config view --flatten=true可查看CA data ,以及將apiserver替換自己kubernetes apiserver的伺服器地址. 我們通過configmap 掛載到cloud-provider容器中.
一旦雲控制器管理器啟動並運行，運行一個示例nginx部署：
然後使用以下類型創建服務：LoadBalancer:
其他SLB相關創建annotation參考： https://github.com/kubernetes/cloud-provider-alibaba-cloud/blob/master/docs/zh/usage.md
cloud-provider注意事項 :
通過cloud-provider動態管理SLB最佳實踐：
FAQ:
參考鏈接:
❽ 騰訊輕量雲伺服器搭建k8s環境
4C4G機器設置為k8smaster節點，另外一台機器設置為k8snode節點
分別進入兩台的 /ect/hosts 目錄，設置r如下host
由於k8s內部節點之間的通訊使用的是內網ip，我們需要把內網ip的重定向到公網ip上
由於兩台機器是處於公網環境，且k8s節點之間需要通訊，所以需要開放一些埠，埠配置可以直接進到騰訊雲控制台進行配置
以下是官網要求的master節點的埠配置
可以進入騰訊雲伺服器的防火牆配置開放相應埠，埠可以限定來源，只允許node節點(192.168.2.2)訪問
以下是官網要求的node節點的埠配置
同理，也設置node節點的埠
master節點需要安裝
node節點需要安裝
添加安裝源(所有節點)
安裝命令
設置開機啟動
修改docker配置（所有節點）
組件安裝完成後就可以啟動了，首先啟動master節點，然後讓node節點加入master幾點即可。
在master節點使用kubeadm初始化集群
這里需要保存token，token是用於node節點加入maste節點的憑證
node節點加入master節點
安裝網路插件，否則node是NotReady狀態（主節點跑）
kubectl get nodes
❾ Docker+ Kubernetes已成為雲計算的主流（二十六）
最近正在抽時間編寫k8s的相關教程，很是費時，等相關內容初步完成後，再和大家分享。對於k8s，還是上雲更為簡單、穩定並且節省成本，因此我們需要對主流雲服務的容器服務進行了解，以便更好地應用於生產。
主流雲服務容器服務介紹
Docker+ Kubernetes已成為雲計算的主流
亞馬遜AWS
Amazon Web Services (AWS) 是亞馬遜公司旗下雲計算服務平台，為全世界范圍內的客戶提供雲解決方案。AWS面向用戶提供包括彈性計算、存儲、資料庫、應用程序在內的一整套雲計算服務，幫助企業降低IT投入成本和維護成本。
那麼如何在AWS上運行Docker呢？AWS 同時為 Docker 開源解決方案和商業解決方案提供支持，並且可通過多種方式在 AWS 上運行容器：
微軟Azure
Microsoft Azure 是一個開放而靈活的企業級雲計算平台。通過 IaaS + PaaS 幫助用戶加快發展步伐，提高工作效率並節省運營成本。
Azure是一種靈活和支持互操作的平台，它可以被用來創建雲中運行的應用或者通過基於雲的特性來加強現有應用。它開放式的架構給開發者提供了Web應用、互聯設備的應用、個人電腦、伺服器、或者提供最優在線復雜解決方案的選擇。
在容器這塊，Azure同樣的提供了眾多解決方案：
下面我們側重介紹下以下服務：
阿里雲
阿里雲（www.aliyun.com）創立於2009年，是全球領先的雲計算及人工智慧 科技 公司，為200多個國家和地區的企業、開發者和政府機構提供服務。2017年1月阿里雲成為奧運會全球指定雲服務商。2017年8月阿里巴巴財報數據顯示，阿里雲付費雲計算用戶超過100萬。阿里雲致力於以在線公共服務的方式，提供安全、可靠的計算和數據處理能力，讓計算和人工智慧成為普惠 科技 。阿里雲在全球18個地域開放了49個可用區，為全球數十億用戶提供可靠的計算支持。此外，阿里雲為全球客戶部署200多個飛天數據中心，通過底層統一的飛天操作系統，為客戶提供全球獨有的混合雲體驗。
飛天（Apsara）是由阿里雲自主研發、服務全球的超大規模通用計算操作系統。 它可以將遍布全球的百萬級伺服器連成一台超級計算機，以在線公共服務的方式為 社會 提供計算能力。 從PC互聯網到移動互聯網到萬物互聯網，互聯網成為世界新的基礎設施。飛天希望解決人類計算的規模、效率和安全問題。飛天的革命性在於將雲計算的三個方向整合起來：提供足夠強大的計算能力，提供通用的計算能力，提供普惠的計算能力。飛天誕生於2009年2月，目前為全球200多個國家和地區的創新創業企業、政府、機構等提供服務。
同樣，阿里雲對容器也提供了友好的支持：
容器服務提供高性能可伸縮的容器應用管理服務，支持用Docker和Kubernetes進行容器化應用的生命周期管理，提供多種應用發布方式和持續交付能力並支持微服務架構。容器服務簡化了容器管理集群的搭建工作，整合了阿里雲虛擬化、存儲、網路和安全能力，打造雲端最佳容器運行環境。
容器服務 Kubernetes 版（簡稱 ACK）提供高性能可伸縮的容器應用管理能力，支持企業級 Kubernetes 容器化應用的全生命周期管理。容器服務 Kubernetes 版簡化集群的搭建和擴容等工作，整合阿里雲虛擬化、存儲、網路和安全能力，打造雲端最佳的 Kubernetes 容器化應用運行環境。
阿里雲彈性容器實例（Elastic Container Instance）是 Serverless 和容器化的彈性計算服務。用戶無需管理底層 ECS 伺服器，只需要提供打包好的鏡像，即可運行容器，並僅為容器實際運行消耗的資源付費。
容器鏡像服務（Container Registry）提供安全的鏡像託管能力，穩定的國內外鏡像構建服務，便捷的鏡像授權功能，方便用戶進行鏡像全生命周期管理。容器鏡像服務簡化了Registry的搭建運維工作，支持多地域的鏡像託管，並聯合容器服務等雲產品，為用戶打造雲上使用Docker的一體化體驗。
騰訊雲
騰訊雲為騰訊傾力打造的雲計算品牌，以卓越 科技 能力助力各行各業數字化轉型，為全球客戶提供領先的雲計算、大數據、人工智慧服務，以及定製化行業解決方案。其基於QQ、微信、騰訊 游戲 等海量業務的技術錘煉，從基礎架構到精細化運營，從平台實力到生態能力建設，騰訊雲將之整合並面向市場，使之能夠為企業和創業者提供集雲計算、雲數據、雲運營於一體的雲端服務體驗。
在容器這塊，騰訊雲提供了如下解決方案：
騰訊雲容器服務（Tencent Kubernetes Engine ，TKE）基於原生 kubernetes 提供以容器為核心的、高度可擴展的高性能容器管理服務。騰訊雲容器服務完全兼容原生 kubernetes API ，擴展了騰訊雲的 CBS、CLB 等 kubernetes 插件，為容器化的應用提供高效部署、資源調度、服務發現和動態伸縮等一系列完整功能，解決用戶開發、測試及運維過程的環境一致性問題，提高了大規模容器集群管理的便捷性，幫助用戶降低成本，提高效率。容器服務提供免費使用，涉及的其他雲產品另外單獨計費。
容器實例服務（Container Instance Service , CIS）可以幫用戶在雲上快捷、靈活的部署容器，讓用戶專注於構建程序和使用容器而非管理設備上。無需預購 CVM（雲伺服器），就可以在幾秒內啟動一批容器來執行任務。同時，開發者也可以通過 kubernetes API 把已有kubernetes 集群的 pod 調度到 CIS 上以處理突增業務。CIS 根據實際使用的資源計費，可以幫用戶節約計算成本。使用 CIS 可以極大降低用戶部署容器的門檻，降低用戶執行 batch 型任務或處理業務突增的成本。
從上面主流的雲服務中我們可以看到，沒有哪家雲廠商不支持Docker，同樣的，也沒有哪家雲廠商不支持Kubernetes！也就是說，Docker+ Kubernetes已經成為雲計算的主流！
什麼是Kubernetes（k8s）
Kubernetes（簡稱k8s）誕生於谷歌，是一個開源的，用於管理雲平台中多個主機上的容器化的應用，k8s的目標是讓部署容器化的應用簡單並且高效，其提供了應用部署、規劃、更新、維護的機制。
k8s主要有以下特點：
支持公有雲，私有雲，混合雲，多重雲（multi-cloud） 。可以將容器化的工作負載從本地開發計算機無縫移動到生產環境。在本地基礎結構以及公共雲和混合雲中，在不同環境中協調容器，保持一致性。
支持模塊化，插件化，可掛載，可組合。並且k8s的擴展和插件在社區開發者和各大公司的支持下高速增長，用戶可以充分利用這些社區產品/服務以添加各種功能。
支持自動部署，自動重啟，自動復制，自動伸縮/擴展，並且可以定義復雜的容器化應用程序並將其部署在伺服器群集甚至多個群集上——因為k8s會根據所需狀態優化資源。通過內置的自動縮放器，k8s可輕松地水平縮放應用程序，同時自動監視和維護容器的正常運行。
Kubernetes正在塑造應用程序開發和管理的未來
k8s構建於 Google 數十年經驗，一大半來源於 Google 生產環境規模的經驗。結合了社區最佳的想法和實踐，而且還在不斷地高速迭代和更新之中。
她銜著金鑰匙出生，一誕生就廣受歡迎，更是在2017，其打敗了所有的競爭對手，贏得了雲計算的戰爭——主流的雲廠商基本上都紛紛放棄了自己造「輪子」的舉動，終止了各自的容器編排工具，加盟了k8s陣營，其中包括Red Hat、微軟、IBM、阿里、騰訊、華為和甲骨文等。
k8s像風暴一樣席捲了應用開發領域，並且已成為雲原生應用程序（架構、組件、部署和管理方式）的事實標准，大量的開發者和企業正在使用k8s創建由微服務和無伺服器功能組成的現代架構。
Docker+ Kubernetes已成為雲計算的主流
容器是現代軟體交付的未來，而Kubernetes是編排容器的最佳方案（事實上的標准）。
Docker 和Kubernetes相輔相成，聯手打下了雲計算的「萬里江山」。Docker 為打包和分發容器化應用程序提供了一個開放的標准，而 Kubernetes 則協調和管理通過 Docker 創建的分布式容器化應用程序。換句話說，Kubernetes 提供了部署和運行通過Docker生成的應用程序所需的基礎結構。
在主流的雲服務，基於Docker+k8s的新型PaaS平台具有敏捷部署、彈性伸縮、靈活調度、故障自動恢復等優勢，充分滿足業務擴展中的資源支持，因此在短短兩年之內，便從Docker Swarm、Cloud Foundry Diego、Kontena、Apache Mesos、Amazon ECS…等大量對手中脫穎而出，拿下了皇冠。
k8s和Docker的勝利意味著這是有史以來第一次，無論使用哪一種雲平台，研發人員都可以擁有完全相同的計算環境。
❿ 如何搭建小企業的私有雲伺服器
首先確定私有雲服務是什麼類型的服務：
用來共享文檔等資料的私有雲存儲。
這種私有雲存儲的可以搭建owncloud，seafile等這些是免費的產品。如果想才有商業版可以采購堅果雲。這個雲存儲我目前一直在用很穩定，而且實時同步的功能太爽了。
2.用來支持業務系統運行的運行平台
搭建基於dockerswarm的雲平台旁物，這種方案比較簡單，搭建速度快，運維簡單。
搭建基於k8s+docker的雲平台，功能超強，搭建難度大，運維難度也大。需要有專業運維人員。
針對以上兩種情況搭建方案是：
采購基礎設施資源，伺服器，網路設備等硬體設備
安裝操作系統，一般情況下都是安裝Linux操作系統
安裝運行環境軟體，然後將軟體包放入運行目錄直接運行即可。（針對雲存儲）
docker公司官方文檔部署docker軟體，然後通過dockerswarm構建一個集群。（針對dockerswarm私有雲）
安裝運襲液docker然後參考k8s官方部署軟體進行部署等。不推禪亮薦使用二進制的方式部署k8s平台。
筆者多年專注雲計算工作，該領域有一定的積累，希望和大家一份分享。