許多 Kubernetes 的介紹圖都是這樣的，解釋了涵蓋的所有名詞。

從技術上講，它是準確的，但是對一些人而言不是很有幫助，本文將其類比于魚類和水族館，可能會有助于部分人將這些解析記錄在腦海中。

這是一個應用程序。

它本身是一個完整的功能單元，但不能單獨生存，因為它需要正確配置的環境。這個特殊的“魚”程序需要水才能生存。

我們可以將它與所有其他應用程序一起扔到海洋中，但它必須競爭資源并應對海洋中的其他一切，因為它沒有自己的專屬空間和資源。

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

使用類似 Docker 的工具，我們可以為應用程序提供容器，將他們分開，給予他們各自的空間。

這是一個 Pod，它是 Kubernetes 的基本構建單元。這是我們放置容器化應用程序的一個盒子。我們給它一個標簽，以便 Kubernetes 知道它是什么以及如何使用它。

現在魚程序已經在 Pod 中安全地進行了調配，現在可以通過 Kubernetes 水族館進行管理。

有時候，應用程序需要資源，例如內存和 CPU。在這里，我們的魚缸容器則是需要 60W 功率才能使用濾水器。

水族館里有不同的房間可以放魚缸。

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

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

這些房間是 Kubernetes 集群中的節點，也就是運行 Pod 的工作人員。

Kubernetes 是水族館館長。

他知道擁有哪些房間，有哪些資源，并可以根據這些信息來決定將新魚缸放在哪里。在沒有任何其他限制的情況下，他默認將魚缸均勻地放置在所有房間中。

我們通常不會在單個魚缸中處理單條魚。館長經常將魚缸放在一起，作為一個魚缸集合展品。

在這里，深海集合展品由一些鮟鱇魚缸、水母缸和魷魚缸組成。在將它們歸到集合展品中時，我們要確定需要創建多少個容器。

設計展品時，我們提供了有關在展品中每個項目的說明。

這里詳細介紹了我們想要的每個魚缸數量，以及在需要修復時，如何創建新魚缸。我們列出了要填充的水量、所需的水溫、需要的食物量。

將這些說明提供給 Kubernetes 水族館館長后，他可以將維護每個應用程序魚缸的工作委托給“水族館實習生”。

實習生的工作是確保水族館中始終有正確數量的魚缸。用 Kubernetes 講，這個與 Deployment 一起創建的實習生稱為副本集（Replica Set）。

水族館的游客不在乎他們在看水母 A 還是水母 B，他們只是想看看水母。實習生會在水母 A 疲倦需要休息時，通過說明將水母 A 換成全新的水母 B。

在 Kubernetes 中，副本集可確保當 Pod 掛掉時，會替換一個新的 Pod，以保持有正確數量的 Pod 可用。

設計展品時，還有一個重要的考慮因素。目前為止，我們一直在展示這樣的 Pod，一個放置容器化應用的盒子。

實際上，我們可以更準確地描述 Pod。從外面看，它只是帶有某些標簽的 Pod。至于內部，我們雖然可以通過 Kubernetes 水族館館長得知更多內部信息，但這對展示并沒有幫助，我們的用戶（水族館訪問者）要能看到該應用程序，并與之交互。

我們需要一種方法，允許水族館游客觀察到 Pod。我們需要打開窗口，以便他們可以觀察其中的魚。

在 Kubernetes 水族館中，解決答案是 Service。Service 具有幾個不同的作用，但主要作用是公開容器中的端口，以便從外部訪問。

在 Pod 中通過 Service 可以讓水族館訪客觀察內部的魚。

Service 還起到了允許 Pod 和容器相互訪問的作用。如果我們希望兩個水箱中的魚能夠來回交換水和食物，可以設置 Service 來實現這種交互。

網絡策略（Network Policy）是我們可以應用的另一種方式。

在這里，它是一個單向閥，能使該魚缸的水向外流動，但不能向內流動。

Config Map 是 Pod 進行操作所需的一組變量或值。魚兒需要食物才能生活，我們將設備安裝在容器上。

我們還會看到透明和不透明的 Config Map，它們分別代表了普通信息和機密信息。Kubernetes 還有很多其他內容，以上這些是構成水族館，以及描述館長工作的基本構件。