对k8s的相关知识

对k8s的相关知识

1、k8s简介

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

2、k8s架构的组成

大体架构

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

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

架构细分

master节点

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

node节点

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

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

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

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

​ k8s提供三类probe&＃xff08;探针&＃xff09;来执行对pod的健康检测

1. livenessProbe探针

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


2. readinessProbe探针

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


3. startupProbe探针

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


5、控制滚动更新过程

通过以下命令查看更新时可以控制的参数&＃xff1a;

kubectl explain deploy.spec.strategy.rollingUpdate


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

maxUnavailable&＃xff1a;次参数控制滚动更新过程中&＃xff0c;不可用的pod数量

6、k8s中镜像的下载策略

可以通过命令查看

kubectl explain pod.spec.containers


imagePullPolicy有以下三种

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

7、image的状态

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

8、pod的重启策略

可以通过命令查看

kubectl explain pod.spec


restartPolicy重启策略有以下2种

1. Always&＃xff1a;pod对象终止就重启&＃xff08;默认&＃xff09;
2. OnFailure&＃xff1a;pod出现错误时重启

9、service的作用

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

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

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

10、版本回滚相关命令

1. 运行yaml文件&＃xff0c;并记录版本信息&＃xff1b;

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


2. 查看该deployment的历史版本

   kubectl rollout history deployment httpd-devploy1


3. 执行回滚操作&＃xff0c;指定回滚到版本1

   kubectl rollout undo deployment httpd-devploy1 --to-revision&＃61;1


4. 在yaml文件的spec字段中&＃xff0c;可以写以下选项&＃xff08;用于限制最多记录多少个历史版本&＃xff09;

   spec:revisionHistoryLimit: 5


11、DaemonSet的特征

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

使用场景

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

12、job资源

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

13、pod生命周期

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

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

3. succeeded&＃xff1a;所有容器已经成功终止&＃xff0c;并且不再启动

4. failed&＃xff1a;pod中所有容器都是非0&＃xff08;不正常&＃xff09;状态退出

5. unknown&＃xff1a;无法读取pod的状态&＃xff0c;通常是controller-manager无法与pod通信

14、创建pod的流程

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

15、删除pod的流程

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

关闭流程

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

16、服务注册

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

17、k8s集群外流量访问pod

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

18、k8s持久化方式

1. EmptyDir&＃xff08;空目录&＃xff09;&＃xff1a;没有指定要挂载宿主机上的某个目录&＃xff0c;直接由pod内部映射到宿主机上&＃xff0c;类似docker的manager volume

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

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