Kubernetes对象模型

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的对象模型进行一个初略的讲解。后续文章会对重点对象模型进行一个详细的讲解或者实战的演示。

（转载本站文章请注明作者和出处 方志朋-forezp）