这是一个应用程序。
它本身是一个完整的功能单元，但它无法独立生存。它需要一个正确配置的环境。
这个鱼程序特别需要水才能生存。
我们可以将它与所有其他随机应用和程序一起扔到海洋中。
但是它必须竞争资源并应对海洋中的其他一切。
它没有自己专用的空间和资源。
这就是我们进行容器化的原因。
使用诸如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有很多东西。这么多名词，就是包裹在事物中的事物，包裹在与事物重叠的事物中。它像洋葱一样分层。
许多图看起来像这样，解释了这里涵盖的所有名词。
从技术上讲它是准确的，但对我不是很有帮助。将类似鱼类和水族馆的类比应用于一项技术，有助于我将所有这些解析在脑海中。
