我的父母一直從事食品業務。 在我的一生中，我父親一直都是廚師，這有點諷刺，因為我是一個糟糕的廚師。 長大後，我的家人或親戚對這個技術都不怎麼了解，當我不得不向父母解釋"技術"時，我會使用食物類比來借鑑他們已經熟悉的東西，這使我開始思考如何 我可以用食物來解釋Kubernetes …
在我們跳到廚房之前，讓我們先嚐試一下一些食品安全準則。 換句話說，在我們進入Kubernetes之前，讓我們先討論容器的重要性。
等等，什麼是容器？
根據Docker的說法，容器是打包代碼及其所有依賴項的軟件的標準單元，因此應用程序可以從一個計算環境快速運行到另一個計算環境。
要真正理解這意味著什麼，讓我們討論一下我們通常如何用餐。 如果您的回答是"食譜和雜貨店購物"，那麼您只是部分正確。 當我們製造東西時，我們往往會忘記無聊的東西，例如硬件，在這種情況下，就是廚房和廚房工具。 而且，如果您真的對廚房工具大肆宣傳，那麼我必須為冒犯您而道歉。 將此餐視為應用程序。 我們如何提出申請？ 如果您的回答是"寫一些代碼"，那麼您只是部分正確。 就像吃飯一樣，我們必須考慮製作和運行此應用程序所需的硬件。
通常，您要做的是通過承包商（建築商）或自己建造廚房。 擁有可操作的廚房後，您可以選擇做任何您想要的飯菜。 但是，一旦您的廚房設置成可以做頓飯，您就只能提供一頓飯。 這意味著，如果您想舉辦" API派對"之類的活動，需要很多餐和許多不同類型的餐食，那麼您將不得不建造更多的廚房來迎合那個聚會。
然後有人想到了"虛擬廚房"的想法。 因此，想法是，您擁有一個物理廚房，每天僅在下午5點至7點之間使用。 其餘時間它閒置，空著並且未被使用。 因此，請想象一下，如果您不使用廚房時可以將其出租。 例如，在下午4點至6點之間，其他人可以進餐。 在這兩個小時內，即使他們可能並不實際擁有廚房，您的廚房也像他們的廚房一樣運轉。 這引入了一個想法，即您不必親自擁有廚房就可以做飯。 在技術世界中，本質上就是虛擬機。 現在，您無需具有多個硬件服務器即可運行多個應用程序。 您可以簡單地將服務器虛擬化為多個虛擬機，每個虛擬機都可以運行和託管自己的獨立應用程序。 因此，實質上，您是在共享整個廚房的硬件資源。
但是後來有人想到，如果你只是做一頓飯，例如然後設置一些方便麵，然後為整個廚房準備一些方便麵，這似乎有點浪費。因此，他們提出了"公用廚房"的想法。就像名稱一樣，公用廚房與廚房中的許多其他廚房共用廚房空間和工具，因此在任何給定時間點可能會有一個以上的人做一種或多種不同類型的餐點。以及我們如何應對食物汙染等問題？當然，每頓飯都有單獨的工作站！您可以將這些工作站視為技術世界中的容器。工作站可以製作任何種類的飯菜，就像可以將任何種類的應用容器化一樣。每個工作站或每個容器彼此獨立運行，但可以共享一些廚房工具，例如烤箱，微波爐，水槽和其他操作系統資源。一個工作站可以在另一個工作站完成工作之前啟動，進餐和關閉。由於工作站是彼此獨立運行的，因此如果一個工作站陷入困境，就不會影響另一工作站。這也意味著工作站無法瞭解其他工作站的工作情況，除非您明確授予他們許可，這就是容器化的美。這個公用廚房有一個名字，叫做" Docker"，它是世界上最受歡迎的公用廚房之一。
等等，Docker是什麼？
Docker是一個容器引擎，可為全球數百萬個Docker容器提供支持。 Docker的一大優點是它可以在任何地方運行Docker容器，因此，如果您已將應用程序容器化，則可以在任何地方安裝Docker並運行這些容器。 在某種程度上，您的應用程序幾乎可以與環境無關，因為容器化過程將應用程序需要的所有依賴項打包到一個容器中，從而為您的應用程序提供了更大的靈活性和移動性。
容器聽起來很棒，為什麼我們需要Kubernetes？
Kubernetes是一個開源項目，旨在自動化部署，擴展和管理Docker容器之類的容器化應用程序。
所有這些公用廚房和工作站都很棒，但是您如何擴展規模呢？ 您如何確定工作站壞了時有人來修理它，以免影響進餐？ 您如何管理和安排誰來使用烤箱，微波爐，水槽等？
在介紹Kubernetes的技術之前，讓我們快速介紹一下容器的創建方式。 現在就忘了公用廚房和工作站。 那只是用來解釋虛擬機和容器之間的區別。 容器化過程始於Dockerfile。 Dockerfile用於組裝Docker映像。 您可以將Dockerfile視為一頓飯。 食譜包含一頓飯所需的一堆配料，以及概述如何將這些配料組裝成一頓飯的方法。 它變成的一餐本質上就是您的Docker映像。 例如，在我的Dockerfile配方中，我概述瞭如何通過混合blueberry.py並遵循與以下等效的一系列步驟來創建藍莓派：
· 打開烤箱並將其預熱至180度
· 將餡餅混合物放入餡餅盤中
· 將餡餅盤放入烤箱中的一個架子上
然後，我調用$ docker build，該構建實際上是通過這些步驟來烘烤我的藍莓派的。 一旦將我美麗的藍莓派烤成可用於Instagram的圖像，我就可以通過調用$ docker run來使用它，但是（儘管我愛吃甜食）我可能不會一口氣吃掉整個東西，所以我想存儲我的藍莓派 我以後可以吃的地方 這是容器註冊表的來源。我可以將藍莓派圖像存儲在Docker Hub等公共容器註冊表中，或者如果它真的是一個非常好的藍莓派，並且我不希望我的家人隨機找到它並吃掉它 ，我可以使用私有容器註冊表，例如Azure容器註冊表。 容器註冊表本質上是一個您可以在其中存儲和分發圖像的地方，就像食物架一樣。
通過將我的藍莓派圖像存儲在容器註冊表中，我不必每次都要切片就可以烤一個新的藍莓派。 我只是將藍莓派從架子上拉下來，然後吃掉一片藍莓派。 但是，與實際的藍莓餡餅不同，食用圖像實際上並不會耗盡藍莓派，因此，一旦將圖像放入容器註冊表中，就可以隨時將其拉下並在容器中啟動。
好的，現在我們可以進行一些Kubernetes聊天了：
男孩，我們還有很多要談的嗎？ Kubernetes是一個大話題，我的意思是自2014年首次發佈以來，它一直是一個正在進行且仍在進行中的項目。我絕不是Kubernetes領域的專家，但我將盡我所能解釋我 知道了…
烤藍莓派很有趣，但是如果我們想將它商業化怎麼辦？
這就是自制容器和帶有Kubernetes的生產級容器之間的區別。現在，我們不再處理一個藍莓派，而是處理成千上萬個藍莓派。那是很多藍莓派。現在，您必須擔心所有藍莓派的質量標準。藍莓派＃24與藍莓派＃202是否一致？您如何將藍莓派交付給客戶？您如何確保一個架子或一個商店沒有庫存過多而另一個沒有庫存不足？如果您不小心釋放了錯誤的批次怎麼辦？您如何召回那一批？您如何確保滿足美國客戶，歐洲客戶，亞洲客戶等的需求？您如何無縫地對品牌的配方進行新的更改而又不打擾客戶呢？就像將藍莓派商業化一樣，將容器投入生產並不是一件容易的"在公園散步"的任務。但是瞭解Kubernetes如何在成功的旅程中幫助您，可以使您的生活變得簡單得多。
那麼，Kubernetes將如何幫助我將藍莓派商業化？
您經常會聽到與Kubernetes相關的術語是"自我修復"。 自我修復並不完全是冥想或療法課程，但會給您帶來相同的副作用； 安心。 自我修復意味著Kubernetes將重新啟動出現故障的容器，殺死沒有響應的容器並以非常無縫的方式替換並用新容器重新安排它們的時間。 想象一下，如果我們建立了一個非常智能的藍莓派製作系統，該系統能夠檢測到藍莓派不好，並在它到達消費者口中（並最終到達胃部）之前非常快地進行替換。 由於可以快速更換，因此消費者不知道他們的藍莓派幾乎差勁了，這可能會使他們感到非常噁心，並將繼續信任我們的藍莓派品牌。
但是，自我修復實際上是如何工作的？
在Kubernetes中，存在Kubernetes控制平面和Kubernetes節點的概念。 控制平面就像CEO，節點是實際執行工作但需要CEO（控制平面）指導的員工。 就像任何首席執行官一樣，控制平面也有一些技巧。 這些技巧之一稱為kube-controller-manager。 實際上有很多控制器，但是由於它們都控制某事，因此CEO不會忘記記住他們的名字，因此通常將它們分組為kube-controller-manager。 Kubernetes中控制器的工作是監視狀態。
為什麼？
好吧，請回想一下我們糟糕的藍莓派例子。 我們怎麼知道它是不好的藍莓派？ 我們只是隨機猜測嗎？ 不，這不是概率等級。 我們可能一直都有想要的藍莓派，因此我們監視當前的藍莓派，以瞭解它達到此理想狀態的程度。 如果距離理想狀態還很遠，那麼我們知道這是一個糟糕的藍莓派。 在Kubernetes中，控制器執行相同的操作（除了豆莢而不是藍莓派）。
等一下，什麼是Pod豆莢？
啊，好問題！ 因此，您不能僅僅告訴Kubernetes直接管理您的容器。 您需要先將它們放入容器中。 當我第一次學習這一點時，我不明白為什麼。 但是考慮一下當地的郵局。 您可以使用郵局發送和接收郵件，但是實際上如何使郵局到達該地址？
您需要先打包您的郵件。 無論是在信封中，某種塑料包裝中還是在盒子中，我們都需要先將包裹包裹起來。
這是為什麼？
好吧，如果您想將多個物品發送到同一地址，則可以在一個包裹中完成。 但通常，每個包裹只發送一件物品。 另一個原因是收件人地址的位置。 如果您沒有包裹商品，那麼您將在哪裡寫郵件地址？ 郵局是否必須通讀您的郵件才能確定發給誰的地址？ 還是看一下T恤的標籤，希望它位於其中？ 還是檢查杯子的底部，並祈禱杯子底部印有它？
從某種意義上說，Pod有點像集裝箱的包裹。 容器是一組具有共享存儲和網絡以及如何運行容器的規範的一個或多個容器的組。 容器中的容器共享一個IP地址，端口空間（發送者和接收者地址），並且可以通過localhost相互查找。 Pod中的應用程序也可以訪問共享卷（例如共享宗地空間）。
那麼為什麼要裝Pod呢？ 是：
· 易於管理，例如 包裹的地址很容易找到
· 資源共享和交流 您可以將多個物品包裝到同一個包裹中
好的，我們有些偏頗，但是，您明白我對Kubernetes成為BIG主題的意思。 您閱讀了一個定義，該定義中至少會有3個您之前從未聽說過的單詞（或者可能只是我一個人）。
在被誤解之前我們在說什麼？ 哦，是的，控制器。 以及控制器如何在Kubernetes中提供"自我修復"功能。 這些控制器之一被稱為ReplicationController。
缺少的空間是錯字嗎？
是的，它實際上被稱為ReplicationController，ReplicationController的作用是確保您指定的"需要一直運行"的Pod數量始終在運行。 因此，這意味著如果沒有足夠的Pod，ReplicationController將啟動更多的Pod，如果有太多Pod，它將關閉Pod，直到達到所需的Pod數量。 這就好比我們將藍莓派包裝到盒子裡，突然意識到它們需要分8批交付。如果我們包裝的藍莓派超過8個，我們就開始從盒子裡取出藍莓派，直到再次達到8個。 如果包裝少於8個，我們將繼續添加更多的藍莓派，直到達到8個。不僅如此，ReplicationController還將檢查不良的藍莓派，並自動將不良的藍莓派替換為良好的藍莓派，因此，我們始終保證有一個藍莓派。 一批8個好的藍莓派。
但是，您知道在做同一件事時總是有更好的方法嗎？ 好吧，讓我向您介紹一個更好的ReplicationController或更常用的名稱：ReplicaSet。 ReplicaSet保持穩定的一組穩定運行的複製pod。
區別基本上是"相同，但不同"。
我不會為您煩惱ReplicaSet為什麼比ReplicationController更好的細節，只是（Kubernete的話，不是我的）。 推薦的創建ReplicaSet的方法是在部署中定義它。
嗯，什麼是部署？
部署可讓您定義所需的狀態，並通過部署控制器維護狀態，使其始終處於所需的狀態。 基本上，在部署中，您可以指定：
... replicas: 8 ...
它將創建8個複製的Pod，ReplicaSet將始終為您維護。
但是，Deployment可以完成比ReplicaSets更多的工作，它可以讓您回滾到早期的Deployments，因此，我們嘗試了一種新的藍莓派配方，人們對此非常討厭。 好吧，在我們將其推廣給所有人之前，我們會回滾並回顧我們已經推出的所有新配方批次，並用舊配方批次替換它。
要解決我們的錯誤，我們只需檢查我們的推出歷史記錄：
kubectl rollout history deployment.v1.apps/blueberry-pie-deployment
然後回滾到上一個：
kubectl rollout undo deployment.v1.apps/blueberry-pie-deployment
您還可以通過執行以下操作來擴展部署：
kubectl scale deployment.v1.apps/blueberry-pie-deployment --replicas=12
現在，它告訴ReplicaSet維護我的Pod的12個副本。
好的，但是我不知道人們有多餓。 有些人可能會食用大量藍莓餡餅，而有些人可能無法食用那麼多藍莓餡餅。 那麼我應該將副本設置為多少？
好吧，有了Kubernetes，您實際上可以使用它們的Horizontal Pod Autoscaler為您做出決定。 水平Pod自動縮放器會根據CPU利用率自動縮放複製控制器，部署，副本集或有狀態集中的pod數量。
因此，使用Horizontal Pod Autoscaler，我們可以設置以下內容：
kubectl autoscale deployment blueberry-pie-deployment --cpu-percent=80 --min=8 --max=12
基本上，在任何時候我們都將運行8個副本，但是如果有人開始消耗大量藍莓派，自動縮放器將檢測到這一點並擴展另一個Pod實例，直到達到最多12個副本。
好吧，讓控制器暫時停在一邊，也許再改天，因為Kubernetes提供的控制器類型以及每個控制器的作用本身就是一個完整的話題，而當我每次瀏覽完每個藍莓餡餅時，我們的藍莓派可能會變質 其中一個。
讓我們深入研究一些網絡內容。
在Kubernetes中，有一個稱為服務的概念。 我認為服務是Pod的IP地址和端口映射。
等待，等等，IP地址和端口映射？
讓我們重用我們的郵購和郵寄示例。 當您需要向某人發送郵件時，通常會有一個收件人和一個發件人地址，以指示將郵件發送到何處以及郵件來自何處。 同樣，當應用程序相互發送流量（郵件）時，通常會有一個源（發送者）IP地址和一個目標（收件人）IP地址。 除了地址，您還需要添加特定郵件或包裹的收件人，因為通常可能有不止一個人住在同一家庭。 這就是應用程序還存在的方式。 通常，應用程序並不單獨存在，而是與同一臺計算機上的其他應用程序一起生存，因此您需要指定端口（人的名字）才能與特定的應用程序（人）進行通信。
但是，為什麼我們需要將流量映射到Pod？ 為什麼不將其直接發送到Pod呢？
假設您發送的郵件不是發給您的朋友或親戚，而是發給人力資源總監，財務主管或您工作的公司的首席執行官。現在，擁有這些頭銜的人可能會隨時更改。也許Kubernetes檢測到它們是不良的藍莓派（工作不好），然後用新的藍莓派代替。舉例來說，您一直在將所有人力資源郵件發送給Katherine，但是突然她離開了，由Jonathan代替。您可能不知道此更改，而是繼續寫給凱瑟琳的信，現在您想知道為什麼她突然讓您迷惑了。服務的工作是在此基礎上加一個抽象層，這樣他們不會直接將您的信件發送給凱瑟琳或喬納森，而是告訴您將其發送給人力資源總監，然後服務將處理您的信件，以便其處理。實際上得到了現任人力資源總監的接見。
如果您考慮一下，Services實際上很有用，因為Pod會不斷地啟動，卸下，銷燬，更換等，以確保一切正常運行，因此您需要保證始終可以連接到運行良好的Pod 自從宇宙開始以來Pod就一直在運行，或者是半秒前開始運行。
就像控制器一樣，Kubernetes網絡還有很多其他部分，我現在也將這些部分停在一邊，以便我們接下來可以深入存儲…
當談到存儲時，我們通常在Volumes中談論它，這正是Kubernetes中的存儲。 考慮一下您曾經做過的每一項工作。 您可能開始了這項工作，完成了一些工作，將其保存，以後再返回，再進行一些處理，然後重複此過程，直到完成該工作為止。 想象一下，如果您無法保存您的工作。 然後，每次回到它時，都必須從頭開始，這意味著您可能永遠也做不完。
但是，您實際上將文件保存到哪裡？
您可以使用Azure託管磁盤或Azure文件將存儲裝載到Pod。 您可能已經知道了這個詞，所以多次瀏覽" mount"一詞，並假設它是什麼意思，因為它"聽起來像是在包含存儲和磁盤的詞的句子中使用的正確詞"（或者也許就是我）。
當您將存儲"掛載"到某物時，您只需將該存儲附加到該操作系統的文件系統。 這樣，用戶實際上可以通過文件系統訪問此存儲介質，然後在其中存儲內容。 您可以將操作系統視為您的房屋，並想在您的房屋中添加一個架子（存儲介質）。 您的房子由許多不同的房間組成，例如廚房，浴室，臥室等。這些實際上是文件系統中的目錄。 您可以將此架子添加到任何房間（將存儲設備安裝到任何目錄）。 假設您將架子安裝到廚房中。 這成為您的食物架子，您可以在其中存放藍莓餡餅。 您還可以卸下（從廚房卸下架子），將其安裝到客廳，這現在成為您的書架。 文件系統實際上要比這複雜得多，但是我不會再深入探討它了（到目前為止）。
嗯不錯。 我為什麼要關心存儲或卷？
好吧，如果我們回到Docker容器，我們基本上就不想在容器中存儲任何東西，因為當我們刪除該容器時，所有保存在該容器中的文件，數據以及所有內容都會丟失。因此，您要使用的是永久性存儲（將其視為永久性存儲）。您可以通過兩種方式通過卷或綁定安裝將持久性存儲安裝到Docker容器中。區別在於，卷優先於綁定掛載（Docker的話，不是我的）。卷是由Docker創建和管理的，這意味著您可以將同一卷同時裝載到多個正在運行的容器中。另一方面，綁定安裝會將文件和目錄從基礎主機安裝到容器中，這實際上意味著容器中運行的進程可以更改基礎主機系統的文件和目錄。在Kubernetes中，Pod也可以安裝了卷，您還可以指定將這些Volume安裝到Pod內的容器。
最後，我認為我應該介紹的最後一件事是Kubernetes Scheduler。 Kubernetes Scheduler的主要工作是確保為所有Pod分配一個要在其上運行的節點。 想想Kubernetes Scheduler就像學校的老師，而Pod是小學生，而Node是操場。 學校老師的職責是確保每個孩子都可以在操場上玩耍，但不是每個孩子都可能想在滑梯或鞦韆上走（有些孩子可能怕身高），因此老師需要安排每個孩子在操場上的轉彎時間。 根據他們的喜好（或要求）。 如果教師以Kubernetes之類的最佳方式安排課程，那麼他們可能會遵循兩步過程：
· 過濾條件：找到所有可以滿足孩子喜好的遊樂場項目
· 得分：對這些項目進行排名，並嘗試為孩子提供排名最高的項目
嗯，那是一個半程的旅程，我只介紹了Kubernetes的一些基礎知識。 學習曲線不僅陡峭（總是具有挑戰性和樂趣），而且我們還必須考慮Kubernetes和我們的容器所運行的硬件。 這就是為什麼大多數企業轉向某種形式的託管Kubernetes服務（例如AKS）（Azure Kubernetes服務而非Azure廚房服務）或Azure Red Hat OpenShift（ARO）來幫助運行其容器化生產工作負載的原因。 這並不意味著您不必學習Kubernetes，它只意味著像CI / CD，日誌記錄和監視，身份驗證之類的事情，底層的基礎架構已為您服務，並且可以輕鬆地集成到您所需要的其他服務中 在生產環境中也需要考慮。
(本文翻譯自Michelle Xie的文章《Explain By Example: Kubernetes》，參考：https://medium.com/swlh/explain-by-example-kubernetes-ea34c60d22ce)
