在之前的文章已经讲到了很多Kubernets对象,包括pod,service,deployment等等。Kubernets对象是一种持久化,表示集群状态的实体。它是一种声明式的意图的记录,一般使用yaml文件描述对象,它使用Kubernetes对象来表示集群的状态,通过API/kubectl管理Kubernetes对象。
name和uid
在Kubernetes对象模型中,使用了name和uid作为对象的唯一标识,其中name在同一种对象中是唯一的,在不同类型对象可以是相同的;uid是唯一标识的。
在API中对象的访问路径:/api/{version}/namespaces/{namespaxe/{object-kind}/name,比如:/api/v1/namespace/default/pods/hello-kubernetes
在Kubernetes集群的整个生命周期内创建的每个对象实例都具有不同的UID.
Namespace(名字空间)
Namesapce,不仅仅是一个属性,本身也是一个object。
-
Namesapce:用于将物理集群划分为多个虚拟集群。
-
Namespace间完全隔离,因此也常被用来隔离不同的用户以及权限。
-
Kubernetes内置了三个Namesapces:default、kube-system和kube-public,Node和PersistentVolume不属于任何namespace。
Label(标签)
Label用于建立集群对象之间的灵活、松耦合的多维关联关系。
-
一个label是一个键-值对,其中的key、value均由用户自己定义。
-
lable可以附着在任何对象上,每个对象也可以有任意个标签。标签可在对象定义时附加上,也可以通过命令动态管理标签。
-
label可以将有组织目的的结构映射到集群对象上,从而形成一个与现实世界管理结构同步对应松耦合的、多维的对象管理结构。
通过lable selector 查询和筛选建立对象间的关系的。
如上图所示,有两个service1和 service2,对应的pod有标签release:stable和标签release:rc-1,通过selector,就可以筛选出相应的标签的pod。而pod由通过nodeselector筛选出不同环境的node。
Annotations
Annotations:可以将任意非标识性元数据附加到对象上。
-
Annotations也是以键值对的形式呈现。
-
工具和库可以检索并使用这些Annotations元数据
-
将数据作为Annotations附着在对象上,有利于创建一些用于部署、管理和做内部检查的共享工具和客户端。
Kubernetes对象分类
常用的对象分类有以下几种:
-
workload类,即工作负载类
-
pod
-
controller
-
deployment
-
stateful
-
daemonset
-
job
-
-
discovery&loadbalance类,与服务相关的对象
-
service
-
endpoint
-
ingress
-
-
config&storage,向应用初始化配置话信息
-
configmap
-
secret
-
volume
-
persistentVolumeClaim
-
cluster,集群类对象
-
Node
-
namespace
-
persitenceVolume
-
clusterRole
-
ClusterRoleVindeing
-
ResoruceQuota
工作负载,以pod为中心
pod是一个有特定关系的容器集合。
-
Pod是集群中可以创建和部署的最小且最简单的Kubernetes对象的单元。
-
Pod也是一种封装。它封装了应用容器,存储资源、独立的网络IP以及决定容器如何运行的策略选项。
-
每个pod中预置了一个Pause容器,其namespace、IPC资源、网络和存储资源被pod内其它容器共享。Pod中的所有容器紧密协作,并且作为一个整体被管理、调度和运行。
pod的生命周期
pod是一个非持久化实体。
如图所示,pod有如下几个生命周期:
-
pending,即挂起,即pod对象已经被kubernetes所接受,但有一个或者多个pod尚未创建。
-
running,运行中,pod已经绑定到node上,所有pod中所有容器已经创建
-
succeed,成功状态,pod的所有的容器已经成功终止。
-
failed,失败状态,即有最少又一个容器正常退出。
service
pod是一个非持久化的实体,pod随时都有可能被销毁掉或者重新创建,所以pod的所在节点是不确定的,为了防止因pod的提供服务不确定性而采用了地址唯一的service用来提供服务,service可以通过负载均衡的调用它背后的pod对象,从而提供稳定的服务。
servie是与云原生应用中“微服务”概念一一对应。
-
kubernetes集群为每一个service分配一个集群唯一的IP地址,在 service的生命周期内,该ip地址不变;在内部DNS指出下,轻松实现服务发现机制。
-
service通过label selector关联到实际支撑业务运行的pod上,并通过集群内置的服务负载均衡分发到后端pod上。
-
通过nodeport或者设置loadbalance机制实现集群外部对service的访问。
controllers
controller是kubernetes的核心对象之一。
-
controller用于保证集群内一组pod能始终按照某种期望的状态正常运行
-
状态包括:Pod副本数量、节点选择、资源约束、持久化数据运维等
-
kubernetes支持多种controller,常用的deployment、replicaseet、statefulset、daemonset等。
ReplicaSet
ReplicaSet:确保健康Pod的副本始终满足用户定义的数量。
-
前身是ReplicationController()rc
-
相比rc,增加了集合式label selector的支持。
-
支持单独使用,但更多隐藏在Deployment控制器后面,由deployment自动管理。
Deployment
Deployment:为pod和 ReplicaSet提供声明式的定义。
-
用户在deployment文件中描述期望状态,Deployment Controller就会自动将Pod和Replica Set的实际状态改变到期望状态。
-
Deployment支持Pod的滚动更新,并自动管理背后的ReplicaSet
-
Deployment支持将Pod滚动到任意版本。
StatefulSet
StatefulSet:提供对有状态应用的部署和控制的支持,1.9版本GA,正式毕业。可以用于生产环境中。
-
使用场景:文档的持久化存储,稳定的网络标志,有序部署有序扩展,有序收缩有序删除,有序自动滚动升级等。
-
Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class 进行配置,或由管理员预先配置好。
-
考虑数据安全性,伸缩或删除StatefulSey不会删除关联的存储;另外StartefulSet目前要求Headless Service 负责Pod的网络身份,用户有责任创建此服务。
DaemonSet
保证在每个Node上都运行一个Pod副本。
-
适用于系统Daemon程序、系统跟踪、日志收集等
-
Kubernetes1.6之后,可设置更新策略:支持滚动更新
-
可指定Node:nodeSelector、nodeAffinity、podAffinity
ConfigMap
常用来向pod提供非敏感的配置信息。
-
ConfigMap用于保存配置数据的键值对,可以用来保存单个,也可以用来保存配置文件。
-
ConfigMap可以使用命令行基于字面值、文件或者目录来创建或者通过configmap对象定义文件创建。
-
ConfigMap可以通过三种形式在pod中使用:环境变量、容器命令行参数货以文件形式通过数据卷插件挂载到pod中。
Secret
secret解决的事集群内密码、token、密钥等敏感数据的配置问题。
-
常用于与ServiceAccount关联,存储在tmpfs文件系统中,Pod删除后sercret文件也会对应删除
-
支持opaque,kubernetes.io/Service Account,kubernetes.io/dockerconfigjson三种类型。
总结
本文主要对Kubernetes的对象模型进行一个初略的讲解。后续文章会对重点对象模型进行一个详细的讲解或者实战的演示。
-更多