● 應用構建
○ Java、C++、JavaScript——編程各異
○ 打成軟件包
○ .exe（類似Windows，最終也只是生產exe執行）
○ 使用docker build … 打包成 鏡像——這就類似于exe

● 應用分享
○ 所有軟件的鏡像放到一個指定地方 docker hub
○ 類似——安卓，應用市場

● 應用運行
○ 統一標準的 鏡像
○ docker run 就好（以前的方法是java -ja…、C++編譯再整很多東西等等都不一樣）

● …

區別于虛擬化技術：

• 容器化其實是Linux做的，docker對此進行簡單封裝。docker不帶操作系統，既然有了操作系統，只需做一些差異化的工作，所以每一個應用只是差異化環境
  
• 為了隔離應用，使用了虛擬化。但是鏡像系統都很大占用。移植起來，需要應用帶上整個虛擬機和環境，一起移植到其他設備——非常重量級
  

● cpu、memory資源隔離與限制
● 訪問設備隔離與限制
● 網絡隔離與限制
● 用戶、用戶組隔離限制
● …

● Docker_Host：
○ 安裝Docker的主機
● Docker Daemon：
○ 運行在Docker主機上的Docker后臺進程
● Client：
○ 操作Docker主機的客戶端（命令行、UI等）
● Registry：
○ 鏡像倉庫
○ Docker Hub
● Images：
○ 鏡像，帶環境打包好的程序，可以直接啟動運行
● Containers：
○ 容器，由鏡像啟動起來正在運行中的程序

交互邏輯：

裝好Docker，然后去 軟件市場 尋找鏡像，下載并運行，查看容器狀態日志等排錯

• 傳統的部署模式中，應用部署在一個操作系統中。如果一個應用內存泄露了，就會把其他應用擠下線，非常不安全
• 虛擬化的部署中，一個應用炸了只能影響到虛擬機內
• 容器化的部署中，在原有的操作系統中有了容器化的運行環境，然后應用就會以容器化的形式運行起來。也能做到資源隔離且輕便

容器化也會帶來一個問題：當服務模塊眾多，每個小項目的微服務都已以容器化的形式部署，并且放到很多臺服務器。以前用docker run跑一兩個應用，人肉可以運維和操作 ，但是如果幾千個容器的話，就難以管理 。因此大規模容器編排系統應運而生（編：同一個應用的容器劃分成一組；排：比如A應用在這個服務器不夠了，就在別的服務器拿來擴充幾個）

kubernetes具有以下特性：
● 服務發現和負載均衡：

• 服務發現：發現宕機有問題的容器，不降任務給他
• 負載均衡：Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器，如果進入容器的流量很大， Kubernetes 可以負載均衡并分配網絡流量，從而使部署穩定。

● 存儲編排
Kubernetes 允許你自動掛載你選擇的存儲系統，例如本地存儲、公共云提供商等。應用需要內存則找k8s要，k8s開辟一塊存儲空間。應用刪了后存儲也沒了
● 自動部署和回滾
你可以使用 Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態 更改為期望狀態。例如，你可以自動化 Kubernetes 來為你的部署創建新容器， 刪除現有容器并將它們的所有資源用于新容器。——回滾到上一次部署的版本
● 自動完成裝箱計算
Kubernetes 允許你指定每個容器所需 CPU 和內存（RAM）。 當容器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。——指定了這么多內存，超過了就會被殺掉
● 自我修復
Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應用戶定義的 運行狀況檢查的容器，并且在準備好服務之前不將其通告給客戶端。——一個機器掛了，可以將其中的容器部署到其他機器
● 密鑰與配置管理
Kubernetes 允許你存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。 你可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置，也無需在堆棧配置中暴露密鑰。

Kubernetes 為你提供了一個可彈性運行分布式系統的框架。 Kubernetes 會滿足你的擴展要求、故障轉移、部署模式等。
例如，Kubernetes 可以輕松管理系統的 Canary 部署。

Kubernetes Cluster = N Master Node + N Worker Node：N主節點+N工作節點； N>=1

工作起來的核心組件如下圖的右側所示：

為便于理解，以硅谷集團部署飛機項目為例：

1. 一個飛機項目下設的的三個節點即東廠、西廠、南廠 ——node
2. 主節點master為硅谷總部——control plane
3. 決定要干什么的決策者（任何人如廠里的都找不到決策者）——controller manager
4. 整個集團運行的核心數據得用資料庫保存——etcd（類似redis的存儲庫，就像mysql）
5. 負責將數據存進資料庫、干雜活則需要秘書干——API server
6. 負責看哪些廠可以做這個項目，需要調度者。但是當調度者決定哪個廠搞了后，需要告訴秘書部，秘書部存檔進資料庫后再告訴某個廠——Scheduler
7. 當決定后，秘書部需要告訴廠長——kubelet
8. 當有領導視察的時候，不知道飛機項目在哪個廠，則需要問門衛（門衛消息互通，問一個即可）——kube-proxy
9. 跟外部合作時，是外聯部——Cloud controller manager
   

• 當廠長kubelet發現廠里有飛機項目做不下去了之后，就會發現并上報給秘書api-server，
• 秘書api-server再通報給決策者controller-manager說西廠的飛機項目搞不定了，
• 決策者說給別的廠搞把，于是告訴秘書，秘書再把決策存入數據庫etcd，秘書再將決策通知調度者scheduler。
• 調度者隨后動態地計算其他廠哪些適合搞飛機項目，其方案也會存入數據庫etcd。
• 東廠每天都會和秘書通電話，當知道決策之后就會開始在東廠開始飛機項目

• 當整個項目搞起來，別人要訪問則需要門衛大爺kube-proxy。
• 門衛大爺則負責接受傳達消息。當其他項目如造船項目應用1需要參觀造車項目應用3的時候，則去找門衛大爺，門衛大爺再告訴他應用三是在哪里。
• 故門衛大爺是打通整個網絡訪問的，誰想要訪問、去哪訪問
  
• 需要說明的是，整個集團架構，master總部其實是一個傀儡，真正決定的是程序員kubectl——挾天子以令諸侯
  

---------------------
作者：別出BUG求求了
來源：CSDN
原文：https://blog.csdn.net/weixin_39589455/article/details/124459859
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件