今天继续给大家介绍Linux运维相关知识，本文主要内容是Kubernetes的核心对象。
一、Pod资源对象
Pod资源对象是一种集合了一个到多个应用容器、存储资源、专用IP以及其他支撑容器运行的资源组成。在Kubernetes集群中，一个Pod就是一个集群，也是Kubernetes的最小调度单位。“Pod”单词在英文中是“豆荚”的含义，在Kubernetes集群中引申为最小的调度单元。
在Kubernetes集群中，Pod中的容器都运行与一个节点上，不同的Pod都处于一个网段内，并且可以互相通信。需要注意的是，在Kubernetes集群中，任何结点对Pod的访问都是等价的，例如，若Pod资源运行在Node1上，那么在其他Node上或者是Master上也都可以实现对Pod资源的访问。
在Pod中，不同的容器会共享网络和存储卷。在Pod被创建后，Kubernetes会给该Pod分配一个IP地址，在一个Pod中的所有容器共享网络和UTS名称空间，包括主机名、IP地址以及端口。Pod结点内部的容器之间互相访问需要使用本地环回地址，而Pod外对Pod内容器的访问则需要借助Service对象的流量转发来完成。Pod可以配置一组“存储卷”资源，这些资源被Pod中的所有容器共享。并且即使是Pod对象宕机或者是被删除，存储卷上的数据依旧存在，从而实现了Pod全声明周期内的数据持久化存储。
Kubernetes支持Pod的扩展，即如果单个Pod不能满足巨大的访问需求时，Kubernetes集群中可以运行多个Pod实例，每个实例都被称为一个“副本”。这些“副本”对象的创建和管理通常由Controller控制器实现。
Pod在创建时，可以使用Pod Preset对象为Pod注入特定的信息，如ConfigMap、Secret、存储卷、挂载卷和Metadata数据等等。有了Pod Preset对象，Pod模板的创建者就无需为每个模板展示提供所有信息，因此，也就无需了解Pod创建的每个细节。Kubernetes在收到创建Pod的命令后，会将Pod调度至选定的某个节点运行，该节点会在本地的容器运行环境中启动容器。Master会将整个集群的状态保存到ETCD中，并通过API Server共享给集群的各组件以及客户端。
在Kubernetes集群中，Pod是有声明周期的，它由运维人员手动创建或者由控制器Controller直接创建，直至进程运行结束，然后会被删除。除此之外，工作结点或者是调度器故障、节点资源耗尽等其他原因也会导致Pod对象被删除。
二、Controller资源对象
在Kubernetes集群中，Controller被用来对Pod对象的管理。通过Controller，Pod会按照我们的设定来运行，包括Pod的副本数、Pod的创建、扩容、缩容更新以及自动恢复等功能。
控制器Controller本身也是一种资源类型，常用的有Replication Controller、Deployment、StatefulSet、DaemonSet和Jobs等等。
Controller的定义一般由期望Pod的副本数量、Pod模板以及标签选择器构成。Controller会根据标签选择器对Pod对象的标签进行匹配检查，所有满足条件的Pod都会被计算为一个副本。
三、Service资源对象
Kubernetes集群中Service对象示意图如下所示：
在Kubernetes集群中，Service资源对象有三种形式，第一种是仅用于集群内部通信的Cluster IP类型；第二种是接入集群外部请求的NodePort类型；第三种是实现Node间负载均衡的LoadBalancer类型。这三种类型中，每一种都是前一种的实现为前提的。
Cluster IP类型的Service，只能用于集群内部通信。在这种模式下，Service向上提供了一个IP地址，向下会将数据流量转发到各个Pod中，对于Kubernetes集群内部的设备而言，对该Service IP的访问和对Pod IP的访问结果是相同的。并且，不论是Pod IP，还是Service IP，都只在Kubernetes集群内部科大。但是Cluster IP的好处在于，一旦Pod对象被删除重启，那么Pod的IP地址会发生变动，但是Service的IP地址是不变的。
NodePort类型的Service保留了Cluster IP的全部功能，同时会将Node结点的某个端口绑定到Pod对象的服务端口上，这样，我们就可以实现在集群外部对该Node结点IP和端口的访问，进而访问Kubernetes集群中的Pod服务。此外，Kubernetes集群一个很大的好处在于，NodePort类型的Service会在任意一个Kubernetes集群节点上生效，这也就意味着我们对该服务的访问可以通过Kubernetes集群中的任意一个节点而实现。
在NodePort类型Service实现的基础上，如果在Kubernetes集群外部提供一个负载均衡器，实现把用户的请求负载均衡至每个Node节点，就成为了LoadBalancer类型的Service，这种负载均衡组件不接受Kubernetes集群的管理，因此需要协同集群外部的组件实现。
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/weixin_40228200/article/details/124283396
