kubernetes对象概述

Pod是在Kubernetes集群中运行部署应用或服务的最小单元， 设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

概念

一个Pod中运行一个容器。可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。

在一个Pod中同时运行多个容器。一个Pod中同时封装几个需要紧密耦合互相协作的容器，之间共享资源。

一个Pod中同时运行多个容器是一种比较高级的用法。 有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件

注：同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。

使用方式 

网络：每个Pod都会被分配一个唯一的IP地址。 Pod中的所有容器共享网络空间，包括IP地址和端口。

存储：可以为Pod指定多个共享的Volume。 Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

注：Pod不会自愈，有问题就会被干掉再起一个；Pod下的容器重启，不代表Pod会重启。 虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。

Pod中可以共享资源：网络和存储。

Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。 例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。

Pod和Controller

Pod模版是包含了其他object的Pod定义，例如Replication Controllers，Jobs和 DaemonSets。 Controller根据Pod模板来创建实际的Pod。

Pod Templates 

数据结构图V1

示例流程如下：1、用户发送删除pod的命令，默认优雅删除时期是30秒；2、在Pod超过该优雅删除期限后API server就会更新Pod的状态为“dead”；3、在客户端命令行上显示的Pod状态为“terminating”；4、跟第三步同时，当kubelet发现pod被标记为“terminating”状态时，开始停止pod进程：5、如果在pod中定义了preStop hook，在停止pod前会被调用。如果在优雅删除期限过期后，preStop hook依然在运行，第二步会再增加2秒的优雅时间；6、向Pod中的进程发送TERM信号；7、跟第三步同时，该Pod将从该service的端点列表中删除，不再是replication controller的一部分。关闭的慢的pod将继续处理load balancer转发的流量；8、过了优雅周期后，将向Pod中依然运行的进程发送SIGKILL信号而杀掉进程。9、Kublete会在API server中完成Pod的的删除，通过将优雅周期设置为0（立即删除）。Pod在API中消失，并且在客户端也不可见。

默认优雅删除

强制删除是通过在集群和etcd中将其定义为删除状态。API server不会等待该pod所运行在节点上的kubelet确认，就会立即将该pod从API server中移除，这时，在节点上的pod会被立即设置为terminating状态，不过在被强制删除之前依然有一小段优雅删除周期。

支持强制删除

Pod删除

Init 容器总是运行到成功完成为止。

一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功，下一个才能够运行。

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。 除非Pod 对应的 restartPolicy 为 Never，

而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。

和普通容器的差别

Pod的Init 容器

基于布尔值控制：这种类型的字段默认为最严格限制的值。

基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。

基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。

由设置和策略组成用以控制 Pod 访问。分为三类

Pod 安全策略

Pod 的 status 在信息保存在 PodStatus 中的phase（相位） 字段。 Pod 相位的数量和含义是严格指定的。除了本文档中列举的状态外，不应该再假定 Pod 有其他的 phase 值。

挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。成功（Successed）：Pod 中的所有容器都被成功终止，并且不会再重启。失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。未知（Unkonwn）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

phase值 

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

成功：容器通过了诊断。 失败：容器未通过诊断。未知：诊断失败，因此不会采取任何行动。

探针结果：

指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器

存活（liveness）探针

指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址

就绪（readiness）探针

探针类型

容器探针 

Pod 状态(PodStatus对象) 

Pod生命周期

后端节点物理机的硬件故障集群管理员错误地删除虚拟机（实例）云提供商或管理程序故障使虚拟机消失内核恐慌（kernel panic）节点由于集群网络分区而从集群中消失由于节点资源不足而将容器逐出

非自愿中断

删除管理该 pod 的 Deployment 或其他控制器更新了 Deployment 的 pod 模板导致 pod 重启直接删除 pod（意外删除）

自愿中断

PDB 将限制在同一时间自愿中断的复制应用程序中宕机的 Pod 的数量。例如，基于定额的应用程序希望确保运行的副本数量永远不会低于仲裁所需的数量。Web 前端可能希望确保提供负载的副本的数量永远不会低于总数的某个百分比。

PDB（PodDisruptionBudget对象)

Pod中断

为什么单个pod中不应该同时运行一个应用的多个实例？

1、透明。让Pod中的容器对基础设施可见，以便基础设施能够为这些容器提供服务，例如进程管理和资源监控。这可以为用户带来极大的便利。2、解耦软件依赖。每个容器都可以进行版本管理，独立的编译和发布。未来kubernetes甚至可能支持单个容器的在线升级。3、使用方便。用户不必运行自己的进程管理器，还要担心错误信号传播等。4、效率。因为由基础架构提供更多的职责，所以容器可以变得更加轻量级。

为什么不直接在一个容器中运行多个应用程序？

Pod

部署表示用户对Kubernetes集群的一次更新操作。比RC更大，如部署可以标示RC减到0再增加到制定Pad数的复合操作。为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

字段图 

1. 创建一个Deployment

2.1 创建Pod Template； .spec.template 是 .spec中唯一要求的字段。

2.2 配置 Replicas； .spec.replicas指定期望的pod数量，默认是1

2.3 设置Selector；  .spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。

.spec.strategy.type==Recreate时，在创建出新的Pod之前会先杀掉所有已存在的Pod。

.spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。

.spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。

.spec.strategy.type==RollingUpdate时，Deployment使用rolling update 的方式更新Pod 。

2.4 制定策略； .spec.strategy 指定新的Pod替换旧的Pod的策略。

在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。

type=Progressing

Status=False

Reason=ProgressDeadlineExceeded

failed progressing类型

2.5 设置Progress Deadline Seconds .spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing前可以等待的Deployment进行的秒数。

2.6 设置Min Ready Seconds .spec.minReadySeconds是一个可选配置项，用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0

.spec.rollbackTo.revision是一个可选配置项，用来指定回退到的revision。默认是0，意味着回退到上一个revision。

2.7 设置Rollback To .spec.rollbackTo 是一个可以选配置项，用来配置Deployment回退的配置。

2.8 设置Revision History Limit .spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。没有设置的话默认所有旧的Replicaset或会被保留设置为0则所有旧的Replicaset都会被删除

2.9 设置Paused .spec.paused是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。

2. 编写 Deployment Spec

Demo

部署(Deployment) 

典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持Kubernetes集群运行的服务。

后台支撑服务集(DaemonSet)

而PetSet是用来控制有状态服务(RC控制无状态Pod)，PetSet中的每个Pod的名字都是事先确定的，不能更改。 PetSet中Pod的名字的作用是关联与该Pod对应的状态。一般会有本地存储用以保存状态特点：（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）如：ZK，Mysql，etcd等需要用PetSet管理。

有状态服务集(PetSet) 

RS是新一代RC，提供同样的高可用能力，能支持更多种类的匹配模式。 

副本集(Replica Set，RS) 

通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。 少于指定数目的Pod副本，RC就会启动运行新的；多于指定数目，RC就会杀死多余的Pod副本。 

副本控制器(Replication Controller，RC) 

Kubernetes的设计定位是单一集群在同一个Zone(跨主机同可用区)。 而联合集群服务就是为提供跨Region(跨同地区可用区)跨服务商Kubernetes集群服务而设计的。 

集群联邦(Federation) 

Job是Kubernetes用来控制批处理型任务的API对象。 和Service区别是运行有头有尾，任务成功完成就自动退出了。 

任务(Job) 

CronJob

HorizontalPodAutoscaling 

资源对象

什么容器化应用在运行（以及在哪个 Node 上） 

可以被应用使用的资源 

关于应用如何表现的策略，比如重启策略、升级策略，以及容错策略 

Kubernetes 对象是持久化的条目，Kubernetes 使用这些条目去表示整个集群的状态。 

用来描述该对象的期望状态，以及关于对象的一些基本信息（例如，名称）创建对象时必须提供 

apiVersion - 创建该对象所使用的 Kubernetes API 的版本 

kind - 想要创建的对象的类型 

metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace 

创建对象必填字段 

对象 spec 

对象 status

核心字段 

对象概念

etcd保存了整个集群的状态；

apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；

kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

核心组件

Service是供客户端调用的一组业务功能接口(webapi) ，每个Service对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务，背后是运行在一组Pod上的程序。在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。

服务(Service)

Pod运行所在的工作主机，可以是物理机也可以是虚拟机。 Node是用来在至上运行kubelet管理的容器。

HostName：可以被kubelet中的--hostname-override参数替代。 ExternalIP：可以被集群外部路由到的IP地址。InternalIP：集群内部使用的IP，集群外部无法访问。

Address

OutOfDisk：磁盘空间不足时为True Ready：Node controller 40秒内没有收到node的状态报告为Unknown，健康为True，否则为False。MemoryPressure：当node没有内存压力时为True，否则为False。DiskPressure：当node没有磁盘压力时为True，否则为False。

Condition

CPU，内存，可运行的最大Pod个数

Capacity 

节点的一些版本信息，如OS、kubernetes、docker等

info

Node的状态信息

节点(Node)

命名空间为Kubernetes集群提供虚拟的隔离作用

命名空间(Namespace)

用户帐户(User Account)&服务帐户(Service Account)

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。 用以避免把敏感信息明文写在配置文件里。

密钥对象(Secret)

基于角色的访问控制（Role-based Access Control，RBAC）。 RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。

RBAC访问授权

ConfigMap

Ingress

Label

ThirdPartyResource

配置对象

SecurityContext

ResourceQuota

LimitRange

策略对象

持久存储卷(Persistent Volume，PV)&持久存储卷声明(Persistent Volume Claim，PVC)

Kubernetes的存储卷的生命周期和作用范围是一个Pod（Docker的存储卷作用范围为一个容器）。 每个Pod中声明的存储卷由Pod中的所有容器共享。

支持多种公有云平台的存储，包括AWS，Google和Azure云

支持多种分布式存储包括GlusterFS和Ceph

支持较容易使用的主机本地目录hostPath和NFS 

支持使用Persistent Volume Claim即PVC这种逻辑存储 

支持存储类型

存储卷(Volume)

存储对象

Kubernetes对象