Kubernetes资源类型的使用指南

署、管理和连接，这很难手动完成。这就是Kubernetes的作用。可以把它想象成一个容器调度程序。

Kubernetes被设计成与Docker一起工作，Docker是一个容器化平台，它将应用程序和所有依赖项打包成一个容器。

举例:Docker用于隔离、打包和以容器的形式运输应用程序。Kubernetes是用于部署和扩展应用程序的容器调度器。

关于Kubernetes，我们可以:

• 在不停机的情况下部署服务和推出新版本
• 在私有或公共云上运行
• 在最合适的服务器上放置和缩放服务的副本
• 验证服务的运行状况
• 有状态应用程序的挂载卷

现在我们已经复习了Kubernetes，让我们跳到它的一些资源并讨论何时使用它们。从pods开始。

Pods是什么?

pod是Kubernetes中应用程序的最低或更原子的单元。需要注意的是，在Docker世界中，pod并不等于容器。一个pod可以由多个容器组成。如果您有纯Docker背景，这可能很难理解。

可以将其看作Kubernetes抽象，它表示一组容器和它们的共享资源。例如，Pod可以包括一个带有Node.js应用程序的容器和另一个向web服务器提供数据的容器。

pod是表示集群中正在运行的进程的一种方法。

如果一个pod可以有多个容器，它是如何工作的?我们需要注意一些限制。pod有以下内容:

• 单一IP地址
• 共享主机
• 共享的IPC空间
• 共享网络端口范围
• 共享卷

pod中的容器通过本地主机相互通信，而pod-to-pod的通信是通过服务完成的。从图中可以看到，pod中的容器共享一个IP地址。应用程序的好方法，但是pod资源类型有一些限制。pod是单个实体，如果它失败了，它就不能重新启动自己。这并不适合大多数用例，因为我们希望应用程序具有高可用性。

但是Kubernetes已经解决了这个问题，我们将在文章中进一步研究如何处理高可用性。

在Kubernetes中，pod总是在节点上运行。可以将节点看作由主服务器管理的工作机器。一个节点可以有多个pods，主节点会自动在一个节点上安排这些pods。

Pods原理

Pods被设计成一个运行多个进程的内聚单元。这些进程被包装在容器中。组成pod的所有容器都运行在同一台机器上，不能跨多个节点拆分。

Pod中的所有进程(或容器)共享相同的资源(例如存储)，它们可以通过本地主机彼此通信。卷就像具有可共享数据的目录。所有容器都可以访问它们并共享相同的数据。

Replication controller

我们刚刚得知pods是会死的。如果他们死了，那就是他们的结局。但是，如果您希望运行同一版本的三个pod以获得高可用性，该怎么办呢?那就是replication controller的作用了。

replication controller的主要职责是防止失败。它位于pod资源类型之上并对其进行控制。

这个功能处理了pods的这个问题。但是，需要注意的是，replication controller并不处理与pods相关的所有内容，即生命周期。

假设我们想在不停机的情况下升级pod。replication controller将不负责此操作。

现在我们已经了解了pods，让我们进入下一个Kubernetes资源: services。

什么是Services?

如果我们想要连接到pods，就需要创建一个Service。在Kubernetes中，Service是一组pods上的网络抽象。可以将其看作在集群上运行的一组pods。Kubernetes服务通常用于支持微服务体系结构。

Kubernetes为一组pods提供了它们自己的IP地址和单个DNS名称，并可以在它们之间实现负载平衡。它们提供了标准化集群的特性，例如:

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!