Kubernetes的核心对象 kubernetes特点

1、Pod资源对象

Pod资源对象是一种集合了一个到多个应用容器，存储对象、专用IP及支撑容器运行的其他选项的逻辑组件，Pod代表着Kubernetes的部署单元及院子运行单元，即 一个应用程序的单一运行实例，他通常由共享资源且关系紧密的一个或多个应用容器组成。

Kubernetes的网络模型要求其各个Pod对象的Ip地址位于同一网络平面内，无论他们位于哪个工作节点之上，这些Pod对象都像是运行于同一局域网中的多个主机。

可以将Pod对象想象成一个逻辑主句，他类似于现实世界中的物理主机或VM，运行于同一个Pod对象中的多个进程也类似于物理机或VM上独立运行的进程，不过Pod对象中的各进程均运行于彼此隔离的容器中，并于各容器间共享两张关键资源：网络和存储卷

网络：每个Pod对象都会被分配一个集群内专用的IP地址，也通常被称为Pod Ip，同一Pod内的所有容器共享Pod对象的Network和UTS名称空间，其中包括主机名、Ip地址和端口等。因此，这些容器间的通信可以基于本地回环接口lo进行，而与Pod外的其他的组件的通信则需要使用Service资源对象的ClusterIp及其相应的端口完成。

存储卷：用户可以为Pod对象配置一组存储卷资源，这些资源可以共享给其内部的所有容器使用，从而完成容器间的数据的共享。存储卷还保证在容器终止后被重启，甚至被删除后也能确保数据不会丢失，从而保证了声明周期内的Pod对象数据的持久化存储。

一个Pod对象代表某个应用程序的特定实例，如果需要扩展应用程序，则意味着为此应用程序创建多个Pod实例，每个实例均代表应用程序的一个应用程序的一个副本，这些副本化的Pod对象的创建和管理通常由另一组称之为控制器的对象实现（Controller）

创建Pod时，还可以使用Pod Preset对象为Pod注入特定的信息，如ConfigMap、Secret、存储卷、挂载卷和环境变量等，有了Pod Preset对象，Pod模板的创建者就无需为每个模板提供所有信息，也就无需了解需要配置的每个应用的细节即可完成模板定义

基于期望的目标状态和个节点资源可用性，Master会将Pod对象调度至某选定的工作节点运行，工作节点于指向的镜像仓库下载镜像，并于本地的容器运行时环境中启动容器，Master会将整个集群的状态存于etcd中，并通过API Service共享给各组件及客户端。

2、Controller（控制器）

在Kubernetes集群的设计中，Pod是有生命周期的对象，用户通过手工创建或由控制器（Controller）直接创建的Pod对象会被调度器（Scheduler）调度至集群中的某个工作节点运行，待到容器应用进程运行结束之后正常终止，随后就会被删除，另外节点资源耗尽或故障也会导致Pod对象被回收。

但Pod对象本身不具有自愈能力，若是因为工作节点甚至是调度器自身导致了运行失败，那么它将会被删除，同样资源耗尽或节点故障导致的回收操作也会删除相关的Pod对象。在设计上，Kubernetes使用Controller实现对一次性的Pod对象的操作管理，例如，要确保部署的应用程序的Pod副本数量严格反应用户期望的数目，以及基于Pod模板来重建Pod对象等，从而实现Pod对象的扩缩容、滚动更新和自愈能力等。例如某节点发生故障时候，相关的控制器会将此节点上运行的pod对象重新调度到其他节点进行重建。

控制器本身也是一种资源类型，它有着多种实现，其中与工作负载相关的实现如ReplicationController，Deployment，StatefulSet、DaemonSet和Jobs等，也可统称他们为Pod控制器。

Pod控制器的定义通常由期望的副本数量、Pod模板和标签选择器组成。Pod会根据标签选择器对Pod对象的标签进行匹配检查，所有满足选择条件的Pod对象都将受控于当前控制器并计入其副本总数，并确保此数目能够精确反映期望的副本数。

在实际的应用场景中，在接收到的请求流量负载显著低于或接近于已有pod副本的整体承载能力时，用户需要手动修改Pod控制器中的期望副本数量以实现应用规模的扩容或缩容，如果集群中部署了HeapSter或Prometheus一类的资源指标监控附件时候，用户还可以使用HorizontalPodAutoscaler（HPA）计算出合适的Pod副本数量，并自动修改Pod控制器中期望的副本数量以实现应用规模的动态伸缩，提高集群利用率。

Kubernetes集群中的每个节点都运行着cAdvisor以收集容器及节点的CPU、内存及磁盘资源的利用率指标数据，这些统计数据Heapster集合后可通过Api Server访问。HorizontalPodAutoscaler基于这些统计数据监控容器监控状态并做出扩展决策。

3、Service

尽管Pod对象可以拥有IP地址，但此地址无法确保在Pod对象重启或被重建后保持不变，这会为集群中的Pod应用间依赖关系的维护带来麻烦；前端Pod应用（调用方）无法基于固定地址持续跟踪后端Pod应用（被依赖方）。于是，Service资源被应用于在被访问的Pod对象中添加一个有着固定ip的中间层，客户端向此地址发起访问请求后由相关的service资源调度并代理至后端的Pod对象

Service是微服务的一种实现，事实上是一种抽象：通过规则定义出由多个Pod对象组合而成的逻辑集合，并附带访问这组Pod对象的策略。Service对象挑选、关联Pod对象的方式同Pod控制器一样，都是要基于标签选择器进行定义。

Service Ip是一种虚拟Ip，也称为Cluster Ip，专用于集群内通信，通常使用专用的地址段，如“10.96.0.0/12”网络，各个service对象的Ip地址在此范围内由系统动态分配。

集群内的Pod对象可直接请求此类的Cluster Ip，Pod client的访问请求即可以Service的Cluster Ip作为目标地址，但集群网络属于私有的网络地址，他们仅在集群内部可达。将集群外部的访问流量引入集群内部的常用方法是通过节点网络进行。实现方法是通过节点的Ip地址和某端口接入请求并将其代理至相应的service对象的Cluster Ip上的服务端口，而后由service对象将请求代理至后端Pod对象的Pod IP及应用程序监听的端口。

事实上NodePort会部署于集群的每一个节点，这就意味着，集群外部的客户端通过任何一个工作节点的Ip地址来访问定义好的NodePort都可以到达相应的Service对象，此种场景中，如果存在集群外部的一个负载均衡器，即可将用户请求负载均衡至集群中的部分或所有节点。这是一种被称为LoadBalancer类型的Service，他通常是有Cloud provider 自动创建并提供的软件负载均衡器，也可以是由管理员手动配置的诸如F5Big-ip一类的硬件设备。

简单来说，service主要有常用的三种类型：

（1）仅用于集群内部通信的ClusterIp

（2）接入集群外部请求的NodePort类型 工作与每个节点的主机Ip之上

（3）第三种是LoadBalance类型 可以把外部请求负载均衡至多个Node主机Ip的NodePort之上。

三种类型中每一种都以其前一种为基础才能实现，而且第三种的LoadBalance需要协同集群外部的组件才能实现，并且此外部组件并不接受Kubernetes的管理。

4、部署应用程序的主体过程。

Docker容器技术使得部署应用程序从传统的安装、配置、启动应用程序的方式转化为在容器引擎上基于镜像创建和运行容器，而Kubernetes又使得创建和运行容器的操作不必关心其位置，并在一定程度上赋予他动态扩缩容及自愈的能力，从而让用户从主机。系统及应用程序的维护工作中解脱出来。

用到某个应用程序时候，用户只需要向API server请求创建一个Pod控制器，由控制器根据镜像等信息向Api Service请求创建一定数量的Pod对象，并有Master之上的调度器指派至选定的工作节点以运行容器化应用。此外，用户一般还需要创建一个具体的Service对象以便于为这些Pod对象建立起一个固定的访问入口，从而使得其客户端能够通过其服务名称或Cluster Ip进行访问。

Api Server的常用客户端程序是Kubernetes系统自带的命令行工具Kubectl，他通过一些子命令用于实现集群及其相关资源对象的管理操作，并支持直接命令式、命令式配置清单及声明式配置清单等三种操作方式、特性丰富且功能强大，而作为集群附件额外部署的Dashboard则提供了基于Web界面的图形客户端，它是一个通用的管理工具，与Kubernetes紧密集成，支持多级别用户授权，能够在一定程度上代替kubectl的大多数操作。