這是一個應用程式。

它本身是一個完整的功能單元，但它無法獨立生存。它需要一個正確配置的環境。

這個魚程式特別需要水才能生存。

我們可以將它與所有其他隨機應用和程式一起扔到海洋中。

但是它必須競爭資源並應對海洋中的其他一切。

它沒有自己專用的空間和資源。

這就是我們進行容器化的原因。

使用諸如Docker之類的工具，我們可以為我們的應用程式設定容器，以將它們分開併為其提供自己的環境。

這是Pod，是Kubernetes的基本構建塊。

這只是我們放置容器化應用程式的一個盒子。它帶有標籤，以便Kubernetes知道它是什麼以及如何引用它。

現在我們的魚已經在Pod中安全地進行了調配，因此可以透過Kubernetes水族館進行管理。

有時，應用程式需要資源，例如記憶體和CPU。

在這裡，我們的魚缸容器需要60W的功率才能使用其濾水器。

水族館裡有不同的房間可以放水箱。

在這裡，這裡的第一個房間沒有更多可用資源-兩個電源插座已在使用中。

第二個房間有可用的插座，但是這個房間讓我們知道它的插座僅提供40W的功率，我們的魚缸需要60瓦。

這些房間是我們Kubernetes叢集中的節點-執行Pod的工作人員。

Kubernetes是水族館總監。

它知道它擁有哪些房間，擁有哪些資源，並根據所有這些資訊來決定將新魚缸放在哪裡。

在沒有任何其他限制的情況下，他們預設將水箱均勻地放置在所有房間中。

我們通常不會在單個水箱中處理一條魚。水族館負責人經常將展品放在一起-放在一起的水箱集合。

在這裡，深海展品由一些魚缸，一些水母缸和巨型魷魚缸組成。在將它們建立為展覽的一部分時，我們將確定要建立的每個容器有多少個。

設計展品時，我們提供有關在展品中建立每個專案的說明。

我們詳細介紹了我們想要的每個儲罐數量，以及在需要修復的情況下如何建立新儲罐。我們列出了要填充的水量，所需的水溫，獲取的食物量。

將這些說明提供給Kubernetes水族館主管，他們便可以將維護每個應用程式正確數量的水箱的實際工作委託給其他人-水族館實習生。

他們的工作是確保水族館中始終顯示正確數量的魚缸。用Kubernetes講，這個與部署一起建立的實習生稱為副本集。

水族館的遊客不在乎他們在看弗雷德·海還是珍珠海，他們只是想看看海。

實習生會按照顯示的水母疲倦需要休息時提供的說明將水母換成全新的水母。

在Kubernetes的世界中，副本集確保當Pod掉落時，會旋轉一個新的Pod，以保持正確數量的Pod可用。

設計展覽時，還有另一個重要的考慮因素。

到目前為止，出於說明目的，我們一直在顯示這樣的Pod，即一個放置容器化應用的盒子。

可以更準確地描述Pod。從外面看，它只是一個帶有一些標籤的Pod。

當然，我們可以請Kubernetes水族館主管告訴我們更多有關內部內容的資訊。但這對我們進行展示並不是很有用，因此我們的使用者（水族館訪問者）可以看到該應用程式並與之互動。

我們需要的是某種方法，允許來水族館的遊客窺探Pod。

我們需要開啟某種視窗，以便他們可以訪問其中的魚。

在Kubernetes水族館中，答案是服務。服務具有幾個不同的角色，但是主要的角色是公開容器中的埠，以便可以從外部訪問它。

向我們的Pod應用服務將使水族館的訪客可以體驗內部的魚類體驗。

服務還起到了允許Pod和容器相互訪問的作用。

如果我們希望兩個水箱中的魚能夠來回交換水和食物，則可以設定一項服務來實現這種互動。

網路策略是我們可以在此處應用的另一種方式。

在這裡，它是一個單向閥，使該魚缸的水可以向外流動，而不能向內流動。

配置對映是Pod進行操作所需的一組變數或值。

魚需要一箱食物才能運轉。將裝置安裝在容器上。

我們還會看到透明和不透明的配置對映-因為它們可以包含平凡或秘密值。

Kubernetes還有很多其他作品，但這些是構成水族館並描述其館長所做出選擇的許多基本構件。

我為什麼要做出這個比喻？這就是東西-Kubernetes有很多東西。這麼多名詞，就是包裹在事物中的事物，包裹在與事物重疊的事物中。它像洋蔥一樣分層。

許多圖看起來像這樣，解釋了這裡涵蓋的所有名詞。

從技術上講它是準確的，但對我不是很有幫助。將類似魚類和水族館的類比應用於一項技術，有助於我將所有這些解析在腦海中。

Anne LoVerso是VMware Pivotal Labs的全棧軟體工程師和顧問。