做擦边网站 服务器,html5企业网站建设,网站开发课题开发背景,c2c网站类型调度 一、Kurbernetes的list-watch机制1.1 list-watch机制简介1.2 创建pod的流程#xff08;结合list-watch机制#xff09; 二、Scheduler的调度策略2.1 简介2.2 预选策略#xff08;predicate#xff09;2.3 优选策略#xff08;priorities#xff09; 三、标签管理3.1… 调度 一、Kurbernetes的list-watch机制1.1 list-watch机制简介1.2 创建pod的流程结合list-watch机制 二、Scheduler的调度策略2.1 简介2.2 预选策略predicate2.3 优选策略priorities 三、标签管理3.1 查看标签的帮助信息3.2 查看标签信息3.3 添加标签3.4 修改标签3.5 删除标签3.6 根据标签值查找资源对象 四、kubernetes对Pod的调度策略五、定向调度5.1 调度策略简介5.2 调度实例5.2.1 通过nodeName字段5.2.2 通过nodeSelector字段配置测试 六、亲和性调度6.1 Node亲和性6.2 Pod亲和性6.3 Pod反亲和性6.4 拓扑域6.4.1 拓扑域的定义6.4.2 如何判断是否在同一个拓扑域 6.5 亲和性的策略6.6 亲和性调度实例6.6.1 node亲和性6.6.2 Pod亲和性6.6.3 Pod反亲和性 六、污点和容忍7.1 节点设置污点7.2 Pod设置容忍7.3 调度实例 八、Pod启动阶段8.1 Pod启动过程8.2 Pod生命周期的5种状态 九、小结9.1 理论部分9.2 K8s常用故障排错流程/手段 一、Kurbernetes的list-watch机制
1.1 list-watch机制简介
Kubernetes 通过 List-Watch 的机制进行每个组件的协作保持数据同步每个组件之间的设计实现了解耦。
list 机制通过调用资源的list API罗列资源基于HTTP短链接实现
watch机制通过调用资源的watch API监听资源变更事件基于HTTP 长链接实现
这种机制对于需要持续跟踪 Kubernetes 集群中资源的状态变化的应用程序非常有用例如自动伸缩、监控、日志收集等。
1.2 创建pod的流程结合list-watch机制 1客户端向apiserver发送创建Pod的请求然后apiserver将请求信息存入到etcd中
2存入完成后etcd会通过apiserver发送创建Pod资源的事件
3controller manager通过list-watch机制监听apiserver发送出来的事件并创建相关的Pod资源创建完成后通过apiserver将信存入到etcd中
4 etcd存入更新信息之后再次通过apiserver发送调度Pod资源的事件
5scheduler通过list-watch机制监听到apiserver发出的调度事件通过调度算法将Pod资源调度到合适的node节点上调度完成后通过apiserver将调度完成后的信息更新到etcd中
6etcd收到更新信息后再次向apiserver发送创建Pod的事件
7kubelet通过list-watch机制监听apiserver发出的创建Pod的事件然后根据事件信息在相应的node节点完成Pod的创建。
二、Scheduler的调度策略 2.1 简介
Scheduler 是 kubernetes 的调度器主要的任务是把定义的 pod 分配到集群的节点上。
Sheduler 是作为单独的程序运行的启动之后会一直监听 APIServer获取 spec.nodeName 为空的 pod对每个 pod 都会创建一个 binding表明该 pod 应该放到哪个节点上。 调度规则 1公平如何保证每个节点都能被分配资源
2资源高效利用集群所有资源最大化被使用
3效率调度的性能要好能够尽快地对大批量的 pod 完成调度工作
4灵活允许用户根据自己的需求控制调度的逻辑 调度的流程 1首先是过滤掉不满足条件的节点这个过程称为预算策略predicate
2然后对通过的节点按照优先级排序这个是优选策略priorities
3最后从中选择优先级最高的节点。如果中间任何一步骤有错误就直接返回错误。
2.2 预选策略predicate
预选策略过滤掉不满足条件的节点的过程。
常见的算法描述PodFitsResources节点上剩余的资源是否大于 pod 请求的资源。PodFitsHost如果 pod 指定了 NodeName检查节点名称是否和 NodeName 匹配。PodFitsHostPorts节点上已经使用的 port 是否和 pod 申请的 port 冲突。PodSelectorMatches过滤掉和 pod 指定的 label 不匹配的节点。NoDiskConflict已经 mount 的 volume 和 pod 指定的 volume 不冲突除非它们都是只读。
如果在 predicate 过程中没有合适的节点pod 会一直在 Pending 状态不断重试调度直到有节点满足条件。
2.3 优选策略priorities
**优选策略**对通过的节点按照优先级排序。
优先级由一系列键值对组成键是该优先级项的名称值是它的权重该项的重要性。
常见的优先级选项描述LeastRequestedPriority通过计算CPU和Memory的使用率来决定权重使用率越低权重越高。也就是说这个优先级指标倾向于资源使用比例更低的节点。BalancedResourceAllocation节点上 CPU 和 Memory 使用率越接近权重越高。这个一般和上面的一起使用不单独使用。比如 node01 的 CPU 和 Memory 使用率 20:60node02 的 CPU 和 Memory 使用率 50:50虽然 node01 的总使用率比 node02 低但 node02 的 CPU 和 Memory 使用率更接近从而调度时会优选 node02。ImageLocalityPriority倾向于已经有要使用镜像的节点镜像总大小值越大权重越高。
通过算法对所有的优先级项目和权重进行计算得出最终的结果。
三、标签管理
#基本语法
kubectl label 资源类型 资源名称 标签键标签值 [options]字段功能资源类型要添加或修改标签的资源类型如 pod、deployment、service 等资源名称要添加或修改标签的资源对象的名称标签键标签值要添加或修改的标签及其对应的值
3.1 查看标签的帮助信息
kubectl label --help3.2 查看标签信息
--show-labels选项
#基本语法
kubectl get 资源类型 [资源名称] [-n namespace] --show-labels 举个例子 #查看指定命名空间中所有pod的标签
kubectl get pods -n my-ns --show-labels3.3 添加标签
使用 kubectl label 命令可以为资源对象添加标签在命令中指定资源类型、名称和要添加的标签及其值。
kubectl label 资源类型 资源名称 [-n namespce] keyvaluekeyvalue 表示要添加或修改的标签键值对。
键key是一个字符串可以是任何你指定的名字
值value是一个字符串可以是任何你指定的值。
键和值之间使用等号连接。 举个例子 #为名为 nginx-test1 的 Pod 添加appbackend 和 version1.15 两个标签
kubectl label pod nginx-test1 -n my-ns appbackend version1.153.4 修改标签
使用--overwrite选项 可以修改已存在的标签值。
如果不使用该选项则只会添加新标签或更新值不同的标签。
#基本格式
kubectl label 资源类型 资源名称 标签键新标签值 --overwrite举个例子 kubectl label pod nginx-test1 -n my-ns app1234 version1222 --overwrite3.5 删除标签
要删除 Kubernetes 资源对象的标签可以使用 kubectl label 命令将标签值设置为空。
#基本格式
kubectl label 资源类型 资源名称 标签键-使用 -减号指示要删除标签。
删除标签不会删除整个资源对象只会删除指定的标签键和值。 举个例子 #删除app标签
kubectl label pod nginx-test1 -n my-ns app-3.6 根据标签值查找资源对象
-l选项根据标签值查找 Kubernetes 资源对象。
标签选择器支持逻辑操作符例如逗号表示逻辑与和等价性操作符 表示等于。
#基本格式
kubectl get/describe 资源类型 -l key[value]使用 kubectl get 命令和自定义选择器查询语句来进行更复杂的标签筛选。
使用 kubectl describe 命令查找具有指定标签的资源对象的详细信息。 举个例子 kubectl get pod -n my-ns -l app
kubectl get pod -n my-ns -l versionkubectl describe pod -n my-ns -l nametest1四、kubernetes对Pod的调度策略
在 Kubernetes 中调度 是指将 Pod 放置到合适的节点上以便对应节点上的 Kubelet 能够运行这些 Pod。
1定向调度 使用 nodeName 字段指定node节点名称使用 nodeSelector 字段指定node节点的标签
2亲和性调度 使用 节点/Pod 亲和性NodeAffinity、PodAffinity、PodAntiAffinity
3污点与容忍 使用 节点设置污点结合 Pod设置容忍。
4全自动调度运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
#补充Pod和node的关系
Node 是 Kubernetes 集群中的工作节点
一个 Node 可以运行多个 Pod而一个 Pod 只能运行在一个 Node 上
使用标签和选择器可以管理 Node 和 Pod 之间的关系从而实现灵活的调度和管理。五、定向调度
5.1 调度策略简介
nodeName指定节点名称用于将Pod调度到指定的Node上不经过调度器。
nodeSelector在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器在 Pod 调度的时候只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。
5.2 调度实例
5.2.1 通过nodeName字段 配置清单文件 apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:nodeName: node02containers:- name: my-containerimage: nginx创建与测试 kubectl apply -f test2.yamlkubectl get pods 5.2.2 通过nodeSelector字段
配置 1.为在 Kubernetes 集群的节点设置标签 kubectl label nodes node01 mylabelbackend
kubectl label nodes node02 mylabelfrontend2.创建一个 Deployment 定义 Pod 调度策略为使用 NodeSelector在创建时选择具有 mylabelbackend 的节点上运行。
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:nodeSelector:mylabel: backendcontainers:- name: myapp-containerimage: nginxkubectl apply -f test1.yaml测试
kubectl get pods -o wide所有的 Pod 都运行在具有 mylabelbackend 的节点上。
六、亲和性调度
官方文档将 Pod 指派给节点 | Kubernetes
kubectl explain pod.spec.affinity键值运算关系描述Inlabel 的值在某个列表中NotInlabel 的值不在某个列表中Gtlabel 的值大于某个值Ltlabel 的值小于某个值Exists某个 label 存在DoesNotExist某个 label 不存在
6.1 Node亲和性
节点亲和性(nodeAffinity)匹配指定node节点的标签将要部署的Pod调度到满足条件的node节点上
6.2 Pod亲和性
Pod亲和性(podAffinity)匹配指定的Pod的标签将要部署的Pod调度到与指定Pod所在的node节点处于同一个拓扑域的node节点上。
如果有多个node节点属于同一个拓扑域通过Pod亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到处于同一个拓扑域的node节点上
6.3 Pod反亲和性
Pod反亲和性(podAntiAffinity)匹配指定的Pod的标签将要部署的Pod调度到与指定Pod所在的node节点处于不同的拓扑域的node节点上
如果有多个node节点不在同一个拓扑域通过Pod反亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到不在同一个拓扑域的node节点上
6.4 拓扑域
6.4.1 拓扑域的定义
拓扑域Topology Domain是用于描述和控制Pod调度和部署的一种机制,它基于节点的拓扑信息来限制Pod的调度位置以满足用户定义的性能和资源需求。
使用拓扑域特性可以在Pod的调度过程中指定节点的拓扑约束这意味着可以定义一个Pod只能被调度到带有某些特定标签的节点上或者避免被调度到具有某些标签的节点上。
例如可以指定要求一个Pod只能调度到同一个机架或同一个区域中的节点上以满足高可用性或数据局部性的需求。
6.4.2 如何判断是否在同一个拓扑域
通过拓扑域key(topologyKey)判断。
如果有其它node节点拥有和指定Pod所在的node节点相同的拓扑域key的标签key和值那么它们就属于同一个拓扑域。
6.5 亲和性的策略
#查看字段信息
kubectl explain pod.spec.affinity.xxAffinity字段字段名描述required…硬策略强制性的满足条件如果没有满足条件的node节点Pod会处于Pending状态直到有符合条件的node节点出现preferred…软策略非强制性的会优先选择满足条件的node节点进行调度即使没有满足条件的node节点Pod依然会完成调度
如果有多个软策略选项的话权重越大优先级越高。
如果把硬策略和软策略合在一起使用则要先满足硬策略之后才会满足软策略。
6.6 亲和性调度实例
6.6.1 node亲和性 1.添加标签 kubectl label nodes node01 diskssd
kubectl label nodes node02 diskdds配置清单文件 使用节点亲和性调度规则要求将 Pod 调度到标签为 “diskssd” 的节点。
vim pod1.yamlapiVersion: v1
kind: Pod
metadata:name: frontend-pod
spec:containers:- name: frontendimage: nginxaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: diskoperator: Invalues:- ssd创建并测试 kubectl apply -f pod1.yaml -n my-ns
kubectl get pods -n my-ns -o wide6.6.2 Pod亲和性
多个pod在一个节点 添加标签 kubectl label nodes node01 appbackend
kubectl label nodes node02 appfrontend配置清单文件 apiVersion: v1
kind: Pod
metadata:name: frontend-pod
spec:containers:- name: frontendimage: nginxaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: NotInvalues:- frontendtopologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Pod
metadata:name: backend-pod
spec:containers:- name: backendimage: mysqlaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: NotInvalues:- backendtopologyKey: kubernetes.io/hostname创建并测试 kubectl apply -f pod2.yaml -n my-ns
kubectl get pods -n my-ns -o wideKubernetes 将会创建一个具有 Pod Anti-Affinity 配置的 Deployment确保这三个 Pod 尽量运行在不同的节点上。
6.6.3 Pod反亲和性
多个pod不在同一个节点 配置清单文件 apiVersion: apps/v1
kind: Deployment
metadata:name: my-app-deployment
spec:replicas: 3selector:matchLabels:app: my-apptemplate:metadata:labels:app: my-appspec:containers:- name: my-app-containerimage: my-app-imageaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- my-apptopologyKey: kubernetes.io/hostname创建并测试 kubectl apply -f pod3.yaml -n my-ns
kubectl get pods -n my-ns -o wide六、污点和容忍
通过使用污点和容忍机制可以更精确地控制Pod的调度行为确保Pod被调度到满足特定条件的节点上。
7.1 节点设置污点 基本概念 在 Kubernetes 中Node节点上的污点Taint是用于标记节点的属性以控制 Pod容器在节点上的调度行为。
通过给节点打上污点可以限制节点上可以调度的 Pod从而实现更精细的调度策略。
污点由三个部分组成
Key键标记的名称。Value值标记的值可选。Effect作用标记的作用。
污点的组成格式如下
keyvalue:effecttaint effect 支持的选项描述NoSchedule一定不会被调度表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上PreferNoSchedule尽量不被调度表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上NoExecute不会被调度并驱逐Pod表示 k8s 将不会将 Pod 调度到具有该污点 相关命令 #给节点打上污点
kubectl taint node node名称 key[value]:effect#覆盖现有的污点
kubectl taint node node名称 key[value]:effect --overwrite#删除
kubectl taint node node名称 key[value:effect]-kubectl describe nodes node名称 | grep Taints##举个例子##
#给名为 node-1 的节点打上键为 special值为 true 的污点并设置作用为 NoSchedule
kubectl taint node node-1 specialtrue:NoSchedule这将导致 Pod 除非声明容忍该污点否则不会被调度到 node-1 节点上。7.2 Pod设置容忍
Pod 可以使用容忍Toleration来声明对污点的容忍以允许在具有相应污点的节点上调度。 配置清单格式 #Pod设置容忍 toleration
spec:tolerations:- key: 污点键名operator: Equal|Existsvalue: 污点键值effect: NoSchedule|PreferNoSchedule|NoExecute相关命令 设置node节点不可调用
kubectl cordon node名称
kubectl uncordon node名称设置node节点不可调用并驱逐Pod
kubectl drain node名称 --ignore-daemonsets --force --delete-emptydir-data7.3 调度实例 1.打上污点 kubectl taint node node01 key1value1:NoSchedule2.编写测试清单文件 apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-appimage: my-app-imagetolerations:- key: key1operator: Equalvalue: value1effect: NoSchedule3.测试 kubectl apply -f pod4.yaml -n my-nskubectl get pod -o wide -n my-ns八、Pod启动阶段
8.1 Pod启动过程
0控制器创建Pod副本
1调度器scheduler根据调度算法选择一台最适合的node节点调度Pod
2kubelet拉取镜像
3kubelet挂载存储卷等
4kubelet创建并运行容器
5kubelet根据容器的探针探测结果设置Pod状态。
8.2 Pod生命周期的5种状态
状态描述PendingPod已经创建但是Pod还处于包括未完成调度到node节点的过程或者还处于在镜像拉取过程中、存储卷挂载失败的情况RunningPod所有容器已被创建且至少有一个容器正在运行SucceededPod所有容器都已经成功退出且不再重启。completedFailedPod所有容器都退出且至少有一个容器是异常退出的。errorUnknownmaster节点的controller manager无法获取到Pod状态通常是因为master节点的apiserver与Pod所在node节点的kubelet通信失联导致的
九、小结
9.1 理论部分
K8S是通过 List-Watch 机制实现每个组件的协作
controller manager、scheduler、kubelet 通过 List-Watch 机制监听 apiserver 发出的事件apiserver 通过 List-Watch 机制监听 etcd 发出的事件scheduler的调度策略
预选策略/预算策略通过调度算法过滤掉不满足条件的node节点如果没有满足条件的node节点Pod会处于Pending状态直到有符合条件的node节点出现
PodFitsResources、PodFitsHost、PodFitsHostPorts、PodSelectorMatches、NoDiskConflict优选策略根据优先级选项为满足预选策略条件的node节点进行优先级权重排序最终选择优先级最高的node节点来调度Pod
LeastRequestedPriority、BalancedResourceAllocation、ImageLocalityPriority标签的管理操作
kubectl label 资源类型 资源名称 标签key标签value
kubectl label 资源类型 资源名称 标签key标签value --overwrite
kubectl label 资源类型 资源名称 标签key-kubectl get 资源类型 [资源名称] --show-labels
kubectl get 资源类型 -l 标签key[标签value]指定node节点调度Pod的方式
1使用 nodeName 字段指定node节点名称
2使用 nodeSelector 字段指定node节点的标签
3使用 节点/Pod 亲和性
4使用 节点设置污点 Pod设置容忍亲和性
节点亲和性(nodeAffinity)匹配指定node节点的标签将要部署的Pod调度到满足条件的node节点上Pod亲和性(podAffinity)匹配指定的Pod的标签将要部署的Pod调度到与指定Pod所在的node节点处于同一个拓扑域的node节点上如果有多个node节点属于同一个拓扑域通过Pod亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到处于同一个拓扑域的node节点上Pod反亲和性(podAntiAffinity)匹配指定的Pod的标签将要部署的Pod调度到与指定Pod所在的node节点处于不同的拓扑域的node节点上如果有多个node节点不在同一个拓扑域通过Pod反亲和性部署多个Pod时则调度器会试图将Pod均衡的调度到不在同一个拓扑域的node节点上如何判断是否在同一个拓扑域
通过拓扑域key(topologyKey)判断如果有其它node节点拥有与指定Pod所在的node节点相同的拓扑域key的标签key和值那么它们就属于同一个拓扑域亲和性的策略
硬策略(required....)要强制性的满足条件如果没有满足条件的node节点Pod会处于Pending状态直到有符合条件的node节点出现软策略(preferred....)非强制性的会优先选择满足条件的node节点进行调度即使没有满足条件的node节点Pod依然会完成调度节点设置污点 taint
kubectl taint node node名称 key[value]:effectNoSchedule(一定不会被调度) PreferNoSchedule(尽量不被调度) NoExecute(不会被调度并驱逐Pod)kubectl taint node node名称 key[value]:effect --overwritekubectl taint node node名称 key[value:effect]-kubectl describe nodes node名称 | grep TaintsPod设置容忍 toleration
spec:tolerations:- key: 污点键名operator: Equal|Existsvalue: 污点键值effect: NoSchedule|PreferNoSchedule|NoExecute设置node节点不可调用
kubectl cordon node名称
kubectl uncordon node名称设置node节点不可调用并驱逐Pod
kubectl drain node名称 --ignore-daemonsets --force --delete-emptydir-dataPod的启动过程
0控制器创建Pod副本
1调度器scheduler根据调度算法选择一台最适合的node节点调度Pod
2kubelet拉取镜像
3kubelet挂载存储卷等
4kubelet创建并运行容器
5kubelet根据容器的探针探测结果设置Pod状态Pod生命周期的5种状态
Pending Pod已经创建但是Pod还处于包括未完成调度到node节点的过程或者还处于在镜像拉取过程中、存储卷挂载失败的情况
Running Pod所有容器已被创建且至少有一个容器正在运行
Succeeded Pod所有容器都已经成功退出且不再重启。completed
Failed Pod所有容器都退出且至少有一个容器是异常退出的。error
Unknown master节点的controller manager无法获取到Pod状态通常是因为master节点的apiserver与Pod所在node节点的kubelet通信失联导致的比如kubelet本身出故障
总结Pod遵循预定义的生命周期起始于Pending阶段如果至少其中有一个主容器正常运行则进入Running阶段之后取决于Pod是否有容器以失败状态退出而进入Succeeded或者Failed阶段。
9.2 K8s常用故障排错流程/手段
kubectl get pods 查看Pod的运行状态和就绪状态
kubectl describe 资源类型|pods 资源名称 查看资源的详细信息和事件描述主要是针对没有进入Running阶段的排查手段
kubectl logs pod名称 -c 容器名称 [-p] 查看Pod容器的进程日志主要是针对进入Running阶段后的排查手段
kubectl exec -it pod名称 -c 容器名称 sh|bash 进入Pod容器查看容器内部相关的进程、端口、文件等状态信息
kubectl debug -it pod名称 --image临时容器的镜像名 --target目标容器 在Pod中创建临时容器进入目标容器进行调试主要是针对没有调试工具的容器使用
nsenter -n --target 容器pid 在Pod容器的宿主机使用nsenter转换网络命名空间直接在宿主机进入目标容器的网络命名空间进行抓包等调试kubectl get nodes 查看node节点运行状态
kubectl describe nodes 查看node节点详细信息和资源描述
kubectl get cs 查看master组件的健康状态
kubectl cluster-info 查看集群信息journalctl -u kubelet -f 跟踪查看kubelet进程日志
