Kubernetes对象模型
原文发表于https://www.fangzhipeng.com/kubernetes/2018/10/13/k8s-object-model/
欢迎访问我的方志朋的博客
Kubernetes对象
在之前的文章已经讲到了很多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的对象模型进行一个初略的讲解。后续文章会对重点对象模型进行一个详细的讲解或者实战的演示。
扫码关注有惊喜
（转载本站文章请注明作者和出处 方志朋的博客）
