Kubernetes资源类型的示例分析
这篇文章给大家分享的是有关Kubernetes资源类型的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
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资源类型有一些限制。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名称，并可以在它们之间实现负载平衡。它们提供了标准化集群的特性，例如:
负载平衡
零宕机的部署
应用程序之间的服务发现
它允许在出现故障时，对流量进行负载平衡。一项服务允许Kubernetes为pods设置单一的DNS记录。如前所述，每个pod都有一个单独的IP地址。对于服务资源类型，你通常会像下面的例子一样定义一个选择器:
除此之外，kube-proxy还在集群中创建一个虚拟IP来访问服务。然后，这个虚拟IP路由到pod IP。如果pod ip更改或部署了新的pods，service资源类型将跟踪更改，并代表您更新内部路由。
deployments是什么?
现在是拼图的最后一部分:deployments。deployments资源类型位于一个副本集(ReplicaSet)之上，可以对其进行操作。换句话说，deployments为pods副本集提供更新。
为此，您需要在deployments中描述所需的状态，然后部署控制器将以可控的速度更改为所需的状态。这允许您运行无状态应用程序。如果需要进行升级，则需要替换副本集。此操作将导致应用程序停机。
Kubernetes的主要优点之一是高可用性。deployment使我们能够在不停机的情况下进行升级。与在复制集中所做的一样，指定要运行的pods数量。
一旦触发更新，deployment将对pods执行滚动升级，同时确保每个pod的升级成功，然后再转移到下一个。
让我们看一个deployment示例，看看它们是如何创建的。
后一个命令的输出如下所示。
那么，如果我们推出了一个新版本的应用程序，但出现了错误，会发生什么情况呢?deployment也有解决方法，我们可以很容易地回滚部署。
这里有一个警告:如果您正在使用pvc(持久卷声明)并在声明中写入了一些内容。这是不会逆转的。
Deployment控制ReplicaSet，而ReplicaSet控制Pods。因此，在使用Deployment资源类型时，您仍然需要一个Service来访问它。
感谢各位的阅读！关于"Kubernetes资源类型的示例分析"这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
