这篇文章给大家分享的是有关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资源类型的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。