目录
3.2.3 ResourceQuota Controller
3.2.5 SVC Controller& Endpoint Controller
读书笔记
互联网编程随时代发展,现在也是开发的重中之重,没得办法,虽然身在传统crud中,那也不能不学习不是,这不,最近在看K8S的一份文档,自我感觉不错,但是出于个人的习惯,我比较习惯整理知识图谱和做笔记
下面和大家分享我的学习笔记和做的知识图谱,和大家进行交流
先展示思维导图
由于所由笔记展现较多,这里先暂时展示一部分和大家分享,若是大家还想交流,我后期会继续更新
注:有需要我的思维导图以及学习参考文档的,可以关注+转发后,私信“资料”即可获取
第一章 k8s入门
k8s是什么: 一个开源的容器集群管理平台,可提供容器集群的自动部署,扩缩容,维护等功能。分为管理节点Master和工作节点Node
核心组件:
- etcd保存了整个集群的状态;
- apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
- controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
- kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;
- Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
- kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;
分层架构:
- 核心层:k8s最核心的功能,对外提供API构建高层应用,对内可提供插件式的应用执行环境。
- 应用层:部署和路由
- 管理层:策略管理,自动化管理,以及系统度量。
- 接口层:kubectl命令行工具。
- 生态系统:外部:日志、监控、配置管理、CI、CD等 内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等。
第二章 实践指南
2.1 基本配置
apiVersion : v1 用来标识版本
kind : Pod/Service 类型可选Pod Service等
metadata: name: nameSpace:
2.4 Pod
- pod中的容器要求启动命令必须以前台命令作为启动命令【避免k8s 监控到pod运行结束 销毁,根据配置的RC副本数量重新启动,从而进入死循环】
- pod 可以由一个或者多个容器组合而成。
- pod中的多个容器只需要localhost就可以相互访问。
2.4.3 静态pod
静态pod 是由kubelet进行管理创建的只存在于特定Node上的Pod,kubelet无法对其进行静态检查,且一般只存在于kubelet所在的节点上。
且无法通过API server进行管理,也不会和ReplicationController Deployment产生关联。
创建方式: yml文件【配置文件】或者http请求
如何删除: 无法通过API server进行管理,所以Master无法对静态pod进行删除【状态更新为pending】。删除只能通过所在的node节点删除配置文件
2.4.4 容器共享volume
在同一个pod内的容器可以共享pod级别的volume
2.4.5 pod配置管理
pod可以通过k8s提供的集群化配置管理方案 configMap来实现配置信息和程序分离。
创建方式: yaml文件
2.4.6 生命周期和重启策略
生命周期 在系统内被定义为各种状态。可以分为 Pending Running Succeeded Failed Unknow
- Pending : API Server 已经创建好Pod,但是Pod内还有一个或者多个容器的镜像没创建,包括正在下载的镜像。
- Running : Pod内所有的容器已经创建成功,至少有一个容器处于运行,正在启动或者重启状态。
- Succeeded : Pod内的所有容器均成功执行退出,且不会再重新启动。
- Failed : 所有容器都已退出,至少有一个容器为退出失败状态。
- Unknow: 无法获取到Pod的状态。
重启策略 应用于Pod内的所有容器,并由Pod所在node节点上的kubelet进行状态判断和重启。当容器异常退出或者健康检查状态失败的时候,kubelet会根据所设置的重启策略重新启动该container
- always : 当容器失效时,由kubelet自动重启该容器。
- OnFailure : 容器运气终止且状态码不为0的时候。
- Never :无论状态如何都不重启该容器。
重启的间隔时间以设定的间隔时间的2n来计算,且在成功重启的10分钟后重置该时间。
不同的控制器对Pod的重启策略的要求是不一样的:
- RC和DaemonSet: 这2类控制器要求所管理的Pod 必须设置为Always,才能保障整个k8s周期内,提供服务的副本数量是满足要求的。
- Job: 这类控制器可根据需求灵活设定OnFailure 或者Never
- Kubelet: 由kubelet管理的一般是静态Pod,kubelet不会对其进行健康检查,Pod失效就会进行重启。和设置的重启策略没有关联。
2.4.7 健康检查
pod的健康检查可使用2类探针: LivenessProbe 和ReadinessProbe
- LivenessProbe :用来判断容器是否存活【running状态】若容器不处于running状态,则会有kubelet对容器根据设定的重启策略进行操作。若容器内不存在LivenessProbe探针,kubelet会认为容器的状态是succeed
- ReadinessProbe :用来判断容器是否是ready状态【这个状态下可以正常接收请求 处理任务】若ReadinessProbe 探针检查失败,EndPoint controller 会从service的endPoint中删除包含该容器所在Pod的endPoint不让该容器对外提供服务。
LivenessProbe 探针的实现方法
- ExecAction 在容器内执行命令若返回状态码为0 表示容器正常。
- TcpSocketAction 成功建立Tcp连接表示状态正常。
- HttpGetAction 对容器路径内调用httpGet方法若返回的状态码在200-400之间表示容器状态正常。
2.4.8 Pod的调度方式
1 RC