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 Deployment

全自动调度，用户配置好应用容器的副本数量后RC会自动调度+持续监控始终让副本数量维持在规定的个数当中。

调度算法 系统内置的调度算法/NodeSelector/NodeAffinity

内置调度算法：对外无感知，无法预知会调度到哪个节点上，系统内完成的。
NodeSelector 定向调度：在Pod上如果设置了NodeSelector属性 Scheduler会将该节点调度到和NodeSelector属性一致的带有Label的特定Node上去。【NodeSelector和Node Label精确匹配】
NodeAffinity 亲和性调度：在NodeSelector的基础上做了一些改进，可以设置在Node不满足当前调度条件时候，是否移除之前调度的Pod，以及在符合要求的Node节点中那些Node会被优先调度。

2 DaementSet

和RC类似，不同之处在于DaementSet控制每一台Node上只允许一个Pod副本实例，适用于需要单个Node运行一个实例的应用：

分布式文件存储相关在每台Node上运行一个应用实例如GlusterFS Ceph
日志采集程序 logStach
每台Node上运行一个健康程序，来对当前Node的健康状态进行采集。

3 Job 批处理任务调度

批处理模型

Job Template Expansion ：一个待处理的工作项就对应一个Job，效率较低。
Queue with Per Pod Work Item ：使用队列存储工作项，一个Job作为消费者消费队列中的工作项，同时启动和队列中work Item数量对应的Pod实例。
Queue with Variable Pod Work Item ：同per Pod 模式，不同之处在于Job数量是可变的。

这里在项目中的具体应用待更新，现在项目所用的k8s 调度模型【后续会单独写篇文章更新】

2.4.9 Pod的扩缩容

手动更新 kubectl scale命令更新RC的副本实例数量
自动更新 使用HAP控制器，基于在controller-manager设置好的周期，周期性的对Pod的cup占用率进行监控，自动的调节RC或者Deployment中副本实例进行调整来达到设定的CPU占用率。

2.5 service

service可以为一组具有相同功能的容器提供一个统一的入口地址，并将请求负载进行分发到后端各个容器应用上。

2.5.2 service的基本使用

直接使用RC创建多个副本和创建SVC提供服务的异同

直接创建RC

先定义RC yaml文件，如上所示
执行创建命令 kubectl create -f name.yaml
查看提供服务的Pod地址 kubectl get pods -l app=webapp -o yaml | grep podIP

因为RC配置的副本实例数量为2 所以可得2个可用的Pod EndPoint 分别为172.17.172.3:80 172.17.172.4:80 无论任何一个Pod出现问题，kubelet 会根据重启策略对Pod进行重新启动，再次查询PodIP会发现PodIP发生变化

使用SVC

因为Pod的不可靠，重新启动被k8s调度到其他Node上会导致实例的endpoint不一样。且在分布式部署的情况下，多个容器对外提供服务，还需要在Pod前自己动手解决负载均衡的问题，这些问题都可通过SVC解决。

创建方式 : kubectl expose命令/配置文件

kubectl expose命令

创建SVC kubectl expose rc webapp 此时端口号会根据之前RC设置的containerPort 来进行设置
查看SVC kubectl get SVC

配置文件方式启动
定义的关键在于 selector 和ports

负载分发策略 RoundRobin/SessionAffinity/自定义实现

RoundRobin : 轮询策略
SessionAffinity ：基于客户端IP的回话保持策略，相同IP的会话，会落在后端相同的IP上面。
自定义实现：不给SVC设置clusterIP 通过label selector拿到所有的实例地址，根据实际情况来选用。

2.5.3 集群外部访问SVC或者Pod

思路是把SVC或者pod的虚拟端口映射到宿主机的端口，使得客户端应用可以通过宿主机端口访问容器应用。

将容器应用的端口号映射到主机
1 容器级别设置hostPort = prodNum yaml中的配置表为hostPort: 8081，指的是绑定到的宿主机端口。HostPort和containerPort可以不相等

2 Pod级别设置hostNetWork = true 这时候设置的所有的containerPort 都会直接映射到宿主机相同的端口上。默认且必须是HostPort = containerPort，若显示的指定HostPort和containerPort不相等则无效。

将SVC端口号映射到主机
关键配置为 kind = service type = NodePort nodePort = xxxxx,同时在物理机上对防火墙做对应的设置即可。

2.5.4 搭建DNS

可以直接完成服务名称到ClusterIP的解析。由以下部分组成

1 etcd DNS信息存储
2 kube2sky 将k8sMaster中的 service注册到etcd
3 skyDNS 提供DNS解析
4 healthz 提供对skyDNS的健康检查

第三章原理分析

3.1 API Server

主要提供了各类资源对象【SVC Pod RC】等的增删查改以及Watch等Http Rest接口，是各个模块之间的数据交互和通讯的枢纽。

Kubernetes API Server : 提供API接口来完成各种资源对象的创建和管理，本身也是一个SVC 名称为Kubernetes

Kubernetes Proxy API :负责把收到的请求转到对应Node上的kubelet守护进程的端口上，kubelet负责相应，来查询Node上的实时信息包括node pod SVC等多用于集群外想实时获取Node内的信息用于状态查询以及管理。【kubelet也会定时和etcd 同步自身的状态，和直接查询etcd存在一定的差异，这里强调实时】

集群模块之间的通信： 都需要通过API Server 来完成模块之间的通信，最终会将资源对象状态同步到etcd，各个集群模块根据通过API Server在etcd定时同步信息，来对所管理的资源进行相应处理。

3.2 Controller Manager

集群内部的管理中心，负责集群内部的Node Pod Endpoint Namespace 服务账号（ServiceAccount）资源定额（ResourceQuota）等的管理。出现故障时候会尝试自动修复，达到预期工作状态。

3.2.1 Replication Controller

一般我们把资源对象 Replication Controller 简写为RC 是为了区别于Controller Manager 中的Replication Controller【副本控制器】，副本控制器是通过管理资源对象RC来达到动态调控Pod的

副本控制器Replication Controller的作用：

【重新调度】确保当前集群中存在N个pod实例，N是在RC中定义的Pod实例数量
【弹性扩容】通过调整RC中配置的副本实例个数在实现动态扩缩容。
【滚动升级】通过调整RC中Pod模板的镜像版本来实现滚动升级。

3.2.2 Node Controller

Node节点在启动时候，会同kubelet 主动向API Server汇报节点信息，API Server将节点信息存储在etcd中，Node Controller通过API Server获取到Node的相关信息对Node节点进行管理和监控。
节点状态包括：就绪未就绪未知三种状态

3.2.3 ResourceQuota Controller

资源配额管理，确保指定资源对象在任一时刻不会超量占用系统物理资源。支持以下维度的系统资源配额管理

容器级别可以CPU和Memory进行限制
Pod级别可以对一个Pod内的所有容器进行限制。
Namespace级别，可以对多租户进行限制，包括Pod数量，Replication Controller数量，SVC数量 ResourceQuota 数量等。

3.2.4 Namespace Controller

用户通过API server 设置的Namespace会保存在etcd中，Namespace Controller会定时的获取namespace状态，根据所得状态对不同的namespace进行相应的删除，释放namespace下对应的物理资源。

3.2.5 SVC Controller& Endpoint Controller

Endpoints 表示一个svc对应的所有的pod的访问地址，Endpoint Controller是负责维护和生成所有endpoint对象的控制器。
每个Node对应的kube-proxy获取到svc对应的Endpoints来实现svc的负载均衡。

3.3 Scheduler

Scheduler 主要是接受controller Manager创建的pod为Pod选定目标Node，调度到合适的Node后，由Node中的kubelet负责接下来的管理运维。
过程中涉及三个对象待调度的Pod列表，空闲的Node列表，调度算法和策略。
也就是根据调度算法和策略为待调度的每个Pod从空闲的Node中选择合适的。随后kubelet通过API Server监听到Pod的调度事件，获取对应的Pod清单，下载Image镜像，并启动容器。

3.3.1 默认的调度流程如下：1&2

1【预选调度】遍历所有的Node节点，选出合适的Node
2优选策略确定最优节点

3.4 Kubelet

每个Node节点中都会启动一个Kubelet，该进程用于处理Master节点下发到本节点的任务，管理Pod以及Pod中的容器，每个Kubelet都会向API Server注册自身信息，定期和Master节点汇报Node节点资源使用情况。

容器健康检查

使用2类探针LivenessProbe 和ReadinessProbe

资源监控

使用cAdvisor

总结：kubelet 作为连接K8s Master节点机和Node机器的桥梁，管理运行在Node机器上的Pod和容器，同时从cAdvisor中获取容器使用统计信息，然后通过API Server上报资源使用信息。

3.5 Kube-Proxy

SVC是对一组提供相同服务Pod的抽象，会根据访问策略来访问这一组Pod。在每一个Node节点上都存在一个Kube-proxy，可以在任意Node上发起对SVC的访问请求。

SVC的ClusterIp和NodePort等概念是kube-proxy服务通过IPtables的NAT转换实现重定向到本地端口，再均衡到后端的Pod

3.6 集群安全机制

待补充

3.7 网络原理

k8s+docker 网络原理常常涉及到以下问题

1 k8s的网络模型是什么？
2 Docker的网络基础是什么？
3 Docker的网络模型和局限？
4 k8s的网络组件之间是如何通讯的？
5 外部如何访问k8s集群？
6 有哪些开源组件支持k8s网络模型？

1 k8s的网络模型

IP-per-Pod:每个Pod都有自己独立的IP,无论是否处于同一个Node节点，Pod直接都可以通过IP相互访问。同时Pod内的容器共享一个网络堆栈【=网络命名空间包括IP地址，网络设备，配置等】按照这个网络模型抽象出来的一个Pod对应一个IP也叫IP-per-Pod

Pod内部应用程序看到的自己的IP+port和pod外部的应用程序看到的IP+port是一致的，他们都是Pod实际分配的ip地址，从docker0上分配的。这样可以不用NAT来进行转换，设计的原则是为了兼容以前的应用。

K8S对网络的要求：

所有容器在不通过NAT的方式下和其他容器进行通讯
所有节点在不使用NAT的方式下和容器相互通讯
容器的地址和外部看到的地址是同一个地址

2 Docker的网络基础是什么？

Docker使用网络命名空间来达到不同容器之间的网络隔离【不同的网络命名空间内的 IP地址网络设备配置等是相互隔离不可见的】
Docker 使用Veth设备对来达到2个不同的网络命名空间的相互访问。【Veth设备对可以直接将2个不同的网络命名空间连接起来，其中一端称为另一端的peer 从a端发送数据时候会直接触发b端的接受操作，从而达到不同容器之间相互访问的目的】

由于网络命名空间以及Veth设备对是建立在同一个linux内核的基础上。所以Docker的跨主机通讯处理的不够友好。

3 Docker的网络模型和局限？

host模式使用--net= host指定
container模式使用--net = container: Id_or_NAME指定
none模式使用--net= none指定
bridge模式使用--net = bridge指定

bridge模式： 也是docker默认的网络模型，在这个模型下Docker第一次启动会创建一个新的网桥大名鼎鼎的docker0，每个容器独享一个网络命名空间，且每一个容器具有一个Veth设备对，一端连接容器设备eth0一端连接网桥，docker0。如下图：

4 k8s的网络组件之间是如何通讯的？

容器到容器之间的通讯
Pod到Pod之间的通讯
Pod到Service之间的通讯
集群外与内部组件之间的通讯

容器到容器之间的通讯

同一个Pod内的容器共享同一个网络命名空间，可以直接使用Localhost进行通讯,不同Pod之间容器的通讯可以理解为Pod到Pod OR Pod到SVC之间的通讯

Pod到Pod之间的通讯

可以分为同一个Node内Pod之间的通讯&不同Node内Pod之间的通讯

同Node内Pod

同一Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，可以直接进行通讯。

不同Node的Pod

docker0网段和宿主机的网卡是2个不同的IP段，Pod地址和docker0处于同一网段。所以为了使不同Node之间的Pod可以通讯，需要将PodIP和所在Node的IP进行关联且保证唯一性。

Pod到Service之间的通讯

SVC是对一组Pod服务的抽象，相当于一组服务的负载均衡。且对外暴露统一的clusterIP,所以Pod到SVC之间的通讯可以理解为Pod到Pod之间的通讯

集群外与内部组件之间的通讯

集群外和内部组件之间通讯，将Pod OR SVC端口绑定到物理机端口即可。

好了，就展示到这里，欢迎大家评论区和我交流，指出笔记中的错误，大家一起成长

如果我笔记整理的还不错的话，也想要我学习的时候参考的文档，可以添加微信：msbxq2020免费获取，备注csdn

我的公众号：Java架构师联盟，每日更新技术好文

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家小花儿/article/detail/401280

码云标星87.6K的K8S学习笔记，学完分享学习笔记，怎么样自己看_码云 dolphscheduler

读书笔记

第一章 k8s入门

第二章 实践指南

第三章 原理分析

第二章实践指南

第三章原理分析