Заметки Kubernetes (17) — Стратегия планирования

задняя часть Kubernetes
Заметки Kubernetes (17) — Стратегия планирования

Это 20-й день моего участия в Gengwen Challenge, пожалуйста, проверьте подробности мероприятия:Обновить вызов

17 Политика планирования

Мастер в основном запускает компоненты плоскости управления кластера, apiserver, планировщик, диспетчер контроллеров и мастер также зависят от узлов хранения, таких как etcd.

Кластер, развернутый kubeadm, будет запускать управляющие компоненты мастера как статические POD.По сути, эти компоненты представляют собой процессы, запущенные на главном узле для предоставления услуг кластеру, и мастер не несет ответственности за выполнение рабочих нагрузок.

Узел узла является соответствующим узлом, отвечающим за выполнение POD рабочей нагрузки. Пользователю нужно только отправить текущую задачу мастеру. Пользователю не нужно заботиться о том, на каком узле выполняется узел. Мастер интегрирует все узлы в виртуальный ресурс бассейн.

17.1 Процесс создания POD

Узел, на котором должно выполняться задание, созданное пользователем, определяется планировщиком на узле Master, а также планировщик позволяет пользователю определять его рабочие характеристики, по умолчанию мы его не определяем, но используется значение по умолчанию. планировщик планировщик.

Когда мы используем kubectl описать pods myapp для просмотра информации о POD, появится поле Events с соответствующей информацией о результате планирования.

Планировщик выберет узлы, отвечающие требованиям работы POD, из множества узлов узлов, а затем запишет информацию о выбранном узле узла в etcd. перейдите на apiserver, чтобы получить его.Что касается списка конфигурации информации об изменениях, POD создается в соответствии с определением списка конфигурации.

17.2 Процесс создания службы

Когда пользователь создает службу, запрос будет отправлен на apiserver, и apiserver запишет файл манифеста в etcd, а затем kube-proxy на каждом узле будет следить за apiserver на предмет изменений, связанных с ресурсами службы. -proxy создаст службу как правило iptables/ipvs.

С точки зрения связи: kubectl, kubelet и kube-proxy — все клиенты apiserver, когда эти компоненты взаимодействуют с apiserver, формат данных — json, а внутренний метод сериализации данных — protocolbuff.

17.3 Измерения ограничений ресурсов

  1. Требования к ресурсам: минимальные требования к ресурсам, необходимые для запуска POD.
  2. Ограничение ресурсов: максимальное ограничение ресурсов, которое может занимать POD.

17.4 Процесс планирования планировщика

  1. Этап предварительного выбора: исключить узлы, которые не соответствуют требованиям для запуска этого POD, таким как минимальные требования к ресурсам, максимальный предел ресурсов, занят ли порт
  2. Этап оптимизации: вычислить приоритет каждого узла на основе ряда функций алгоритма, отсортировать по приоритету и получить узел с наивысшим баллом.
  3. Этап выбора: если этап выбора дает несколько результатов, выберите узел случайным образом.
  • Поля в POD, которые влияют на планирование, в kubectl, объясняют pods.spec
nodeName          # 直接指定 POD 的运行节点
nodeSelector      # 根据 node 上的标签来对 node 进行预选，这就是节点的亲和性
  • Другие факторы, влияющие на планирование

Планирование сходства узлов: отображается как поле nodeSelector

Сходство между POD: POD, как правило, работают вместе с определенными POD, например, в одном и том же компьютерном зале, на одной и той же машине.

Антиаффинность между POD: POD и POD, как правило, не работают вместе, это называется антиаффинностью, например: мониторинг одного и того же порта узла с конфиденциальными данными.

Taints: испортить некоторые узлы,

Допуски: устройство POD может допустить наличие загрязнения на узле.Если во время работы на узле появляется новое повреждение, устройство POD может

Исключить POD: Узел дает POD ограниченное время, чтобы покинуть узел.

17.4 Факторы предварительного отбора

Следующие условия предварительного отбора должны соответствовать всем условиям предварительного отбора, чтобы пройти предварительный отбор

  1. CheckNodeConditionPred
检查节点是否正常
  1. GeneralPredicates
подполитика эффект
HostName Проверьте, является ли имя хоста именем узла, указанным в pod.spec.hostname.
PodFitsHostPorts Проверьте, не занят ли список pods.spec.containers.ports.hostPort каждого контейнера в поде другими контейнерами.Если требуемый HostPort не соответствует требованиям, то под нельзя запланировать на этот хост
MatchNodeSelector Убедитесь, что pods.spec.nodeSelector определен в контейнере POD, чтобы увидеть, может ли метка узла соответствовать
PodFitsResources Основные требования для проверки достаточности ресурсов узла для запуска этого POD
  1. NoDiskConflict (не включено по умолчанию)
检查 pod 定义的存储是否在 node 节点上使用。
  1. PodToleratesNodeTaints
检查节点的污点 nodes.spec.taints 是否是 POD 污点容忍清单中 pods.spec.tolerations 的子集
  1. PodToleratesNodeNoExecuteTaints
检查 pod 是否容忍节点上有 NoExecute 污点。NoExecute 这个污点是啥意思呢。如果一个 pod 上运行在一个没有污点的节点上后，这个节点又给加上污点了，那么 NoExecute 表示这个新加污点的节点会驱逐其上正在运行的 pod；不加 NoExecute 不会驱逐节点上运行的 pod，表示接受既成事实，这是默认策略。
  1. CheckNodeLabelPresence (по умолчанию не включено)
检查节点上指定标签的存在性，如果节点有pod指定的标签，那么这个节点就被选中。
  1. CheckServiceAffinity (по умолчанию не включено)
一个 Service 下可以有多个 POD，比如这些 POD 都运行在 1、2、3 机器上，而没有运行在 4、5、6 机器上，那么CheckServiceAffinity 就表示新加入的 POD 都集中运行在 1、2、3 机器上，这样集中好处是一个 Service 下 POD 之间内部通信的效率变高了。
  1. MaxEBSVolumeCount
确保已挂载的亚马逊 EBS 存储卷不超过设置的最大值，默认39
  1. MaxGCEPDVolumeCount
确保已挂载的GCE存储卷不超过设置的最大值，默认16

10 MaxAzureDiskVolumeCount

确保已挂载的Azure存储卷不超过设置的最大值，默认16
  1. CheckVolumeBinding
检查节点上的 PVC 是否被别的 POD 绑定了
  1. NoVolumeZoneConflict
检查给定的 zone (机房) 限制前提下，检查如果在此主机上部署 POD 是否存在卷冲突
  1. CheckNodeMemoryPressure
检查 node 节点上内存是否存在压力
  1. CheckNodeDiskPressure
检查磁盘 IO 是否压力过大
  1. CheckNodePIDPressure
检查 node 节点上 PID 资源是否存在压力
  1. MatchInterPodAffinity
检查 Pod 是否满足亲和性或者反亲和性

17.5 Предпочтительные функции

Выполните оптимальную функцию в каждом узле, сложите результаты каждой оптимальной функции, и побеждает тот, у кого больше баллов.

  1. least_requested.go
选择消耗最小的节点（根据空闲比率评估 cpu(总容量-sum(已使用)*10/总容量)）
  1. balanced_resource_allocation.go
均衡资源的使用方式，表示以 cpu 和内存占用率的相近程度作为评估标准，二者占用越接近，得分就越高，得分高的胜出。
  1. node_prefer_avoid_pods.go
看节点是否有注解信息 "scheduler.alpha.kubernetes.io/preferAvoidPods" 。没有这个注解信息，说明这个节点是适合运行这个 POD 的。
  1. taint_toleration.go
将 pods.spec.tolerations 与 nodes.spec.taints 列表项进行匹配度检查，匹配的条目越多，得分越低。
  1. selector_spreading.go
查找当前 POD 对象对应的 service、statefulset、replicatset 等所匹配的标签选择器，在节点上运行的带有这样标签的 POD 越少得分越高，这样的 POD 优选被选出。 这就是说我们要把同一个标签选择器下运行的 POD 散开(spreading)到多个节点上。
  1. interpod_affinity_test.go
遍历 POD 对象亲和性的条目，并将那些能够匹配到节点权重相加，值越大的得分越高，得分高的胜出。
  1. most_requested.go
表示尽可能的把一个节点的资源先用完，这个和 least_requested 相反，二者不能同时使用。
  1. node_label.go
根据节点是否拥有标签，不关心标签是什么，来评估分数。
  1. image_locality.go
表示根据满足当前 POD 对象需求的已有镜的体积大小之和来选择节点的。
  1. node_affinity.go
根据 POD 对象中的 nodeselector，对节点进行匹配度检查，能够成功匹配的数量越多，得分就越高。

17.6 Выбор функций

При наличии нескольких предпочтительных узлов выберите один случайным образом.

разное

Публикуйте свои заметки по адресу:GitHub.com/RedHat Series/Арвин…Добро пожаловать в один клик

Категории