k8s  容器编排   
容器应用，自动部署，弹性伸缩和管理



K8s架构组成
主节点（Master）和 多个计算节点（Node）
主节点暴露API，调度部署和节点管理
计算节点运行容器运行环境 （docker  rkt等）
kubelet  和master通信

Master
Kubectl  客户端命令行工具，K8s集群的操作入口
Api Server    提供了认证、授权、访问控制、API注册和发现等机制 ， 客户端与k8s群集及K8s内部组件通信
Controller-manager   负责维护群集的状态，比如故障检测、自动扩展、滚动更新等
Scheduler  负责资源的调度，按照预定的调度策略将pod调度到相应的node节点上
Etcd  保存群集状态

Node节点
Kubelet  
负责维护容器的生命周期，负责Volume和网络的管理，
当Scheduler确定某个node上运行pod之后，会将pod的具体信息（image，volume）等发送给该节点的kubelet，
kubelet根据这些信息创建和运行容器，并向master返回运行状态。

Kube-proxy
Service在逻辑上代表后端的多个pod
负责为Service提供cluster内部的服务发现和负载均衡

container-runtime

Pod
每个pod可以运行一个或多个container（容器）
container的USR（用户）、MNT（挂载点）、PID（进程号）是相互隔离的，
UTS（主机名和域名）、IPC（消息队列）、NET（网络栈）是相互共享的。
pod 豌豆夹， 豌豆就是pod中的container
Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。
Pod是k8s进行创建、调度和管理的最小单位，


controller-manager 包含 replication controller、node controller、deployment controller、endpoint controller等各种资源对象的控制器，
每种控制器都负责一种特定资源的控制流程



基础概念


label

可以附加到各种资源对象上，如Node、Pod、Service、RC等
k8s通过Label Selector（标签选择器）查询和筛选资源对象；


Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。

集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。

Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心

Deployment
相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度；

HPA（Horizontal Pod Autoscaler）

Pod的横向自动扩容，也是k8s的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量；


Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。

Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod



Volume是Pod中能够被多个容器访问的共享目录，k8s中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下；


Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中





pod资源对象的健康状态检测
三类probe（探针）
livenessProbe   探测容器是否健康，kubelet根据其重启策略决定是否重启
ReadinessProbe   如果探测失败，控制器会将此pod从对应service的endpoint列表中移除
startupProbe

检查参数

initialDelaySeconds 初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
periodSeconds  检查间隔，默认10s
timeoutSeconds 检查超时
successThreshold  成功探测阈值

探测方法
Exec  Httpget  tcpSocket



滚动更新过程
控制参数 
参数查看
kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge  滚动更新过程，副本总数超过预期pod数量的上限。 百分比 或 具体的值 ，默认 1
maxUnavailable  滚动更新过程中，不可用的Pod的数量


镜像下载策略
kubectl explain pod.spec.containers
imagePullPolicy

Always Never IFNotPresent
Always  镜像标签为latest时，总是从指定的仓库中获取镜像
Never  禁止从仓库中下载镜像，只使用本地镜像
IfNotPresent  仅当本地没有对应镜像时，才从目标仓库中下载

默认的镜像下载策略
当镜像标签是latest时，默认策略是Always
当镜像标签是自定义时，默认策略是IfNotPresent


image 状态

Running Pod所需的容器已经被成功调度到某个节点，且已经成功运行，
Pending APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程
Unknown APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致




pod 重启策略
kubectl explain pod.spec
restartPolicy字段
Always  pod对象终止就重启，默认策略
OnFailure  仅在pod对象出现错误时才重启



Service 资源对象

来给相同的多个pod对象提供一个固定的统一访问接口，常用于服务发现和服务访问
Service的Endpoint列表通常绑定了一组相同配置的pod，通过负载均衡的方式把外界请求分配到多个pod上。

集群外流量访问Pod
通过Service的NodePort方式访问，会在所有节点监听同一个端口

服务注册
Pod启动后会加载当前环境所有Service信息，以便不同Pod根据Service名进行通信。









版本回滚相关的命令

运行yaml文件，并记录版本信息
kubectl apply -f httpd2-deploy1.yaml  --record

查看该deployment的历史版本
kubectl rollout history deployment httpd-devploy1

执行回滚操作，指定回滚到版本1
kubectl rollout undo deployment httpd-devploy1 --to-revision=1


限制最多记录多少个历史版本 配置 

spec:
  revisionHistoryLimit: 5
kubectl explain deploy.spec  



标签与标签选择器的作用
相同类型的资源对象 分组 ， 提升资源对象的管理效率
标签选择器：就是标签的查询过滤条件。


基于等值关系，如  = == !=  (matchLabels)
基于集合，如 in notin exists（ matchExpressions ）

selector:
  matchLabels:           #基于等值
    app: nginx
  matchExpressions:         #基于集合
    - {key: name,operator: In,values: [zhangsan,lisi]}     #key、operator、values这三个字段是固定的
    - {key: age,operator: Exists,values:}   #如果指定为exists，那么values的值一定要为空




常用的标签分类

版本类标签（release）：stable（稳定版）、canary（金丝雀版本）、beta（测试版）；
环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；
应用类（app）：ui、as、pc、sc；
架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；
分区标签（partition）：customerA（客户A）、customerB（客户B）；
品控级别（Track）：daily（每天）、weekly（每周）。




标签查看 

查看pod，并且显示标签内容
kubectl get pod --show-labels    

显示资源对象标签的值
kubectl get pod -L env,tier  

只显示符合键值资源对象的pod，-L 显示所有的pod
kubectl get pod -l env,tier      



添加、修改、删除标签

对pod标签的操作
给名为label-pod的pod添加标签
kubectl label pod label-pod abc=123     

修改标签
kubectl label pod label-pod abc=456 --overwrite

删除标签
kubectl label pod label-pod abc-             
kubectl get pod --show-labels

对node节点的标签操作
给节点node01添加disk标签
kubectl label nodes node01 disk=ssd  

修改节点node01的标签
kubectl label nodes node01 disk=sss –overwrite 

删除节点node01的disk标签
kubectl label nodes node01 disk-         


DaemonSet资源对象

在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod
在其yaml文件中，不支持定义replicas

常见使用场景
每个节点的日志收集工作
监控每个节点的的运行状态


pod生命周期

Pending   等待kube-scheduler选择合适的节点创建，一般是在准备镜像
Running   pod中所有的容器已经被创建，并且至少有一个容器正在运行或者是正在启动或者是正在重启；
Succeeded 所有容器已经成功终止，并且不会再启动；
Failed    pod中所有容器都是非0（不正常）状态退
Unknown   无法读取Pod状态，通常是kube-controller-manager无法与Pod通信


创建一个pod的流程

客户端提交Pod的配置信息（ 一般是yaml文件定义）到kube-apiserver
Apiserver收到指令后，通知给controller-manager创建一个资源对象
Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心
Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发送到node节点上的kubelet组件上
Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行状况的信息存储到etcd数据中心


删除一个Pod

Kube-apiserver 接收删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，
此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始关闭Pod的工作；
关闭流程
pod从service的endpoint列表中被移除；
如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
进程被发送TERM信号（kill -14）
当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）



k8s数据持久化的方式

EmptyDir（空目录）
没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。类似于docker中的manager volume。
同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。
如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。
emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。


Hostpath

将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。
这种数据持久化方式，运用场景不多，因为它增加了pod与节点之间的耦合。
一般对于k8s集群本身的数据持久化和docker本身的数据持久化会使用这种方式，

PersistentVolume（PV）
基于 NFS 或 GFS 
统一数据持久化目录，方便管理

在一个PV的yaml文件中，可以对其配置PV的大小，指定PV的访问模式
ReadWriteOnce：只能以读写的方式挂载到单个节点；
ReadOnlyMany：能以只读的方式挂载到多个节点；
ReadWriteMany：能以读写的方式挂载到多个节点。

pv的回收策略：
recycle：清除PV的数据，然后自动回收；
Retain：需要手动回收；
delete：删除云存储资源，云存储专用；

这里的回收策略指的是在PV被删除后，在这个PV下所存储的源文件是否删除

PVC是向PV申请应用所需的容量大小，K8s集群中可能会有多个PV，PVC和PV若要关联，其定义的访问模式必须一致。
定义的storageClassName也必须一致，
若群集中存在相同的（名字、访问模式都一致）两个PV，那么PVC会选择向它所需容量接近的PV去申请，或者随机申请。