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


---------------------
【转载】
作者：方志朋
原文：https://blog.csdn.net/forezp/article/details/83042018

ヾ(◍°∇°◍)ﾉﾞ