Kubernetes16个资源对象
Kubernetes包含多种类型的资源对象:Pod、Replication Controller、Service、Deployment、Job、DaemonSet等。所有的资源对象都可以通过Kubernetes提供的kubectl工具进行增、删、改、查等操作,并将其保存在Etcd中持久化存储。从这个角度来看,Kubernets其实是一个高度自动化的资源控制系统,通过跟踪对比Etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。下面对常用的资源对象分别进行介绍。
一、Pod
Pod(豆荚 相当于毛豆角和其的豆)是Kubernetes中创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。一个Pod由一个或多个容器组成,Pod中容器可以共享存储和网络,在同一台Docker主机上运行。每个Pod都有一个特殊的被称为“根容器”的Pause容器,Pause容器对应的镜像属于Kubernetes平台的一部分。除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。
二、Label
label(标签)是kubernetes系统中另外一个核心概念。一个Label是一个key-value的键值对,其中key与value由用户自己指定。Label可以附加到各种资源对象上,例如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者别除。另外可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多纬度的资源分组管理功能,以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。给某个资源对象定义一个Label,就相当于给它打了一个标签,随后可以通过Label selector标签选择器查询和筛选拥有某些Label的资源对象,Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。
三、RS (ReplicaSet)(副本|pod 控制器)
Replication Controller(复制控制器,RC)是Kubernetes集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod 来保证集群中运行指定数目的Pod副本。指定的数目可以是1个或多个:如果少于指定数目,RC就会运行新的Pod副本。如果多于指定数目,RC就会杀死多余的Pod副本。即使在数目为1的情况下,通过RC运行Pod也比直接运行Pod更明智,因为RC可以发挥它高可用的能力,保证永远有1个Pod在运行。
RC与RS(ReplicaSet)唯一区别就是label selector支持不同,RS支持新的基于集合的标签,RC仅支持基于等式的标签。推荐使用RS,后面RC将可能被淘汰。
四、Deployment(无状态)
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。Deployment主要用于部署无状态应用。
典型的应用场景包括:
1.定义Deployment来创建Pod和ReplicaSet
2.滚动升级和回滚应用·
3.扩容和缩容
4.暂停和继续Deployment
五、service 绑定pod
RS和Deployment只是保证了支撑Service(服务)的Pod的数量,但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例,随时可能在一个节点上停止,在另一个节点以一个新的IP地址启动一个新的Pod,因此不能以固定的P地址和端口号提供服务。要稳定地提供服务,需要服务发现和负载均衡能力。服务发现完成的工作,是针对客户端访问的服务,找到对应的的后端服务实例。
在K8s集群中,客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP,集群内部通过虚拟IP访问一个服务。在K8S集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器,在K8s的每个Node节点上都会运行一个Kube-proxy组件;这一设计体现了它的伸缩性优势,需要访问服务的节点越多,提供负载均衡能力的Kube-proxy就越多,高可用节点也随之增多。与之相比,通过在服务器端部署反向代理做负载均衡,还需要进一步解决反向代理负载均衡和高可用的问题。
六、DaemonSet(每个节点有且只有一个,通常用于监控和日志收集)
DaemonSet确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。
删除DaemonSet将会删除它创建的所有Pod,使用DaemonSet的一些典型用法:
1、运行集群存储daemon,例如在每个Node上运行glusterd、ceph。
2、在每个Node上运行日志收集daemon,例如fluentd、logstash。
3、在每个Node上运行监控daemon,例如Prometheus Node Exporter。
七、StatefulSet(有状态)
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计),其应用场景包括:
1、稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
2、稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于HeadlessService(即没有Cluster IP的Service)来实现,
3、有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的POd必须都是Running和Ready状态),基于init containers来实现,
4、有序收缩,有序删除(即从N-1到0)
⚠️ 1.有主从先后启动顺序时,2.指定名称不同,3.数据存储不同 就算有状态!(端口,IP,等等不算!)
⚠️ 有状态与无状态的区别在于,有状态必须有一个,先后顺序或者存储数据不同等等...... | 无状态则是,无所谓你宕了或者有故障倾向,我直接从新起一个新的
无状态:deployment
- 认为所有pod都是一样的,不具备与其他实例有不同的关系。
- 没有顺序的要求。
- 不用考虑再哪个Node运行。
- 随意扩容缩容。
有状态:SatefulSet
- 集群节点之间的关系。
- 数据不完全一致。
- 实例之间不对等的关系。
- 依靠外部存储的应用。
- 通过dns维持身份
八、Volume 持久化
容磁盘上的文件生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet会重启它,但是容器中的文件将丢失——容器已干净的状态(镜像最初的状态)重新启动。其次,在pod中同时运行多个容器时,这些容器之间通常需要共享文件。kubernetes中的Volume就很好的解决了这些问题。
九、Namespace 不同项目进行隔离
命名空间将对象逻辑分配到不同namespace,可以是不同的项目、用户等区分管理,并设定控制策略,从而实现多租户。命名空间也称为虚拟集群。
十、PersistentVolume(PV)存储资源
PersistentVolume是由管理员设置的存储,它是群集的一部分。就像节点是集群中的资源一样,PV也是集群中的资源。PV是Volume之类的卷插件,但具有独立于使用PV的Pod的生命周期。此API对象包含存储实现的细节,即NFS、iSCSI或特定于云供感商的存储系统。
十一、PersistentVolumeClaim(PVC) 调用存储资源
PersistentVolumeClaim是用户存储的请求。它与Pod相似。Pod消耗节点资源,PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或只读多次模式挂载)。
十二、Job(一次性周期定时任务)
Job复制批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod。
十三、Cron Job (周期定时任务)
Cron Job管理基于时间的Job:
1、在给定时间点只运行一次
2、周期性的定时间点运行
十四、ConfigMap 服务于配置文件
ConfigMap功能在Kubernetes1.2版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API给我们提供了向容器中注入配置信息的机制,ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象。
十五、Secret 解决密码、token、秘钥等敏感问题
secret解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者Pod Spec中。secret可以 以Volume或者环境变量的方式使用。
十六、HPA(Horizontal Pod Autoscaling)动态扩缩容
Horizontal Pod Autoscaling仅适用于Deployment 和ReplicaSet,在v1版本中仅支持根据Pod的CPU利用率扩容,在v1alpha版本中,支持根据内存和用户自定义的metric扩容缩容。