对k8s的相关知识

1、k8s简介

​ Kubernetes简称k8s，是google公司用go语言开发的系统，是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。

2、k8s架构的组成

大体架构

​ k8s集群至少需要一个主节点和多个计算节点

1. 主节点用于暴露API，调度部署和节点管理
2. 计算节点运行一个容器运行的环境，如docker，同时运行一个k8s代理（kubelet）用于和master通信，计算节点还运行一些额外的组件，像记录日志，节点监控，服务发现等等。是真正的工作节点

架构细分

master节点

1. kubectl：客户端命令行工具，作为整个k8s集群的操作入口
2. api server：作为资源的唯一入口，提供认证、授权、访问控制、API注册和发现等机制。客户端与k8s集群及k8s内部组件的通信，都要通过api server这个组件
3. controller-manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
4. scheduler：负责资源调度，按照预定的调度策略将pod调度到相应的node节点上
5. etcd：担任数据中心的角色，保存了整个集群的状态

node节点

1. kubelet：负责维护容器的生命周期、volume和网络管理，运行在node工作节点上。master的scheduler确定某个node要运行pod之后，将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据信息创建和运行容器，向master返回运行状态
2. kube-proxy：负责为service提供cluster内部的服务发现和负载均衡（service接收到请求后通过kube-proxy转发到pod）
3. container-runtime：是负责管理运行容器的软件，比如docker
4. pod：k8s里面最小的单位，每个pod能运行一个或多个container，多个container的资源，如USER（用户）、MNT（挂载点）、PID（进程号）相互隔离。如UTS（主机名、域名），IPC（消息队列）、NET（网格栈）相互共享

3、容器和主机部署应用的区别

​ 容器的中心思想是秒级启动 ，一次封装、到处运行，主机部署无法达到这效果，但是容器部署要注意数据持久化问题。容器可以将各个服务进行隔离，互补影响。

4、k8s对pod资源对象的监控检测机制

​ k8s提供三类probe（探针）来执行对pod的健康检测

1. livenessProbe探针

   可以根据用户自定义的规则来判定pod是否健康，如果为不健康，kubelet会根据重启策略来决定是否重启。如果容器不包含livenessProbe探针，则总是认为是健康的
   

2. readinessProbe探针

   可以根据用户自定义的规则来判定pod是否健康，如果为不健康，控制器将pod从对应service的endpoint列表中移除，从此不再将任何请求调度到该pod，直到下次探测成功
   

3. startupProbe探针

   启动检测机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉
   

5、控制滚动更新过程

通过以下命令查看更新时可以控制的参数：

kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge：控制滚动更新过程，副本总数超过预期pod数量的上限，可以是百分比也可以是具体的值，默认是1

maxUnavailable：次参数控制滚动更新过程中，不可用的pod数量

6、k8s中镜像的下载策略

可以通过命令查看

kubectl explain pod.spec.containers

imagePullPolicy有以下三种

1. Always：镜像标签为latest时，总是从指定仓库获取镜像
2. Never：禁止从仓库下载镜像，只能使用本地镜像
3. IfNotPresent：仅当本地没有相应镜像时，才从仓库下载

7、image的状态

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

8、pod的重启策略

可以通过命令查看

kubectl explain pod.spec

restartPolicy重启策略有以下2种

1. Always：pod对象终止就重启（默认）
2. OnFailure：pod出现错误时重启

9、service的作用

给相同的多个pod对象提供一个固定的统一访问接口，常用于服务发现和服务访问，

pod每次重启或者重新部署，ip都会发生变化，使得pod之间通信和pod与外部通信变得困难，service就能定义一个统一固定的访问入口

service的endpoint列表通常绑定一组相同配置的pod，通过负载均衡把外界的请求分配到多个pod

10、版本回滚相关命令

1. 运行yaml文件，并记录版本信息；

   kubectl apply -f httpd2-deploy1.yaml  --record
   

2. 查看该deployment的历史版本

   kubectl rollout history deployment httpd-devploy1
   

3. 执行回滚操作，指定回滚到版本1

   kubectl rollout undo deployment httpd-devploy1 --to-revision=1
   

4. 在yaml文件的spec字段中，可以写以下选项（用于限制最多记录多少个历史版本）

   spec:
     revisionHistoryLimit: 5
   

11、DaemonSet的特征

​ DaemonSet会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是和deploymentSet最大的也是唯一的区别，在yaml文件中不支持replicas属性，除此之外和DeploymentSet的写法相同

使用场景

1. 每个节点上的日志收集
2. 监控每个节点的运行状态

12、job资源

job和其他服务类容器不同，job是一种工作类容器，一般做一次性任务，使用不多

13、pod生命周期

1. pending：pod已经被同意创建，等待schedule选择合适的节点创建，一般在准备镜像

2. running：pod中所有容器都被创建、并且至少一个容器正在运行或者正在启动或者正在重启

3. succeeded：所有容器已经成功终止，并且不再启动

4. failed：pod中所有容器都是非0（不正常）状态退出

5. unknown：无法读取pod的状态，通常是controller-manager无法与pod通信

14、创建pod的流程

1. kubectl客户端提交pod的配置信息（可以是yaml文件）到api server
2. api server收到指令后，通知controller manager创建一个资源对象
3. controller manager通过api server将pod的配置信息存储到etcd数据中心
4. scheduler 检测到pod信息会开始调度预选，先过滤掉不符合pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发到node节点的kubelet组件上
5. kubelet收到pod配置信息，创建并运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行状况信息存储到etcd数据中心

15、删除pod的流程

api server收到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，此时pod状态为Terminating，kubelet看到pod标记为Terminating就开始了关闭pod的工作

关闭流程

1. pod从service的endpoint列表中被移除
2. 如果该pod定义了一个停止前的钩子，会在pod内部调用
3. 进程被发送TERM信号(kill -14)
4. 当超过优雅退出时间后，pod中所有进程会被发送SIGKILL信号（kill -9）

16、服务注册

pod启动会加重当前环境所有的service信息，以便不同pod根据service名进行通信

17、k8s集群外流量访问pod

可以通过service的NodePort方式访问，会在所有节点监听同一个端口，访问的流量会被重定向到对应的service上面

18、k8s持久化方式

1. EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由pod内部映射到宿主机上，类似docker的manager volume

2. Hostpath：将宿主机上已经存在的目录或文件挂载到容器内部，类型docker中的bind mount挂载方式

3. PersistentVolume：基于nfs服务的pv，也可以是基于gfs的pv，依赖文件系统，优点是统一数据持久化目录，方便管理