Поиск по сайту:

Используйте сходство узлов в Kubernetes

На этой странице

  1. Предварительные условия
  2. Что мы будем делать?
  3. Настройка привязки узлов
  4. Заключение

Соответствие узлов – это набор правил. Он используется планировщиком для определения места размещения модуля в кластере. Правила определяются с помощью ярлыков на узлах и селекторов ярлыков, указанных в определении модулей. Привязка к узлам позволяет поду указать привязку к группе узлов, для которых он может быть запланирован. Мы можем ограничить Pod, чтобы он мог работать только на определенных узлах.

nodeSelector — это простейшая форма ограничения выбора узла. nodeSelector — это свойство PodSpec. Чтобы модуль мог работать на узле, узел должен иметь каждую из указанных меток.

Привязка узлов концептуально похожа на NodeSelector – она позволяет нам ограничивать, какие узлы могут быть запланированы для нашего модуля, на основе меток на узле.

В настоящее время существует два типа привязки узлов:

  1. requiredDuringSchedulingIgnoredDuringExecution и
  2. preferredDuringSchedulingIgnoredDuringExecution.

  • Здесь модуль еще не создан и будет создан впервые.
  • Обычно при создании модуля применяются правила сходства.

  • Здесь модуль работает, и в среду вносятся изменения, влияющие на nodeAffinity.

Чтобы узнать больше о Node Affinity, посетите kubernete.io — официальную документацию Kubernetes.

В этой статье мы увидим, как назначить модуль Kubernetes определенному узлу, используя привязку узла «requiredDuringSchedulingIgnoredDuringExecution» в кластере Kubernetes.

Предпосылки

  1. Кластер Kubernetes по крайней мере с 1 рабочим узлом.
    Если вы хотите научиться создавать кластер Kubernetes, нажмите здесь. Это руководство поможет вам создать кластер Kubernetes с 1 мастером и 2 узлами на инстансах AWS Ubuntu EC2.

Что мы будем делать?

  1. Настройка привязки узлов

Настройка привязки узлов

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

kubectl get nodes #Get all the nodes in the cluster

Проверьте, есть ли на узлах Taints.

kubectl describe node node01 | grep Taints #Describe the node node01 and grep Taints
kubectl describe node master | grep Taints #Describe the node master and grep Taints

Добавьте метку к рабочему узлу node01.

kubectl label node node01 app=qa #Add a label

Создайте файл определения развертывания и добавьте в него следующее определение.

vim my-deployment-without-affinity.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-without-affinity
spec:
  replicas: 20
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx

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

kubectl get pods #Get pods in the default namespace
kubectl get deployment #Get deployments in the default namespace

Создайте развертывание из созданного нами определения.

kubectl create -f my-deployment-without-affinity.yml #Create a deployment object
kubectl get deployment #Get deployments in the default namespace
kubectl get pods #Get pods in the default namespace

Получите подробную информацию о модулях, созданных развертыванием.

Здесь видно, что поды также получают места в главном узле. Причина этого в том, что на узлах нет Taints, поэтому модули могут занимать места на любом из доступных узлов.

kubectl get pods -o wide #Get pods in the default namespace with more information about them using -o wide

Теперь создайте определение развертывания с определением сходства узлов.

vim my-deployment-with-affinity.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-afiinity
spec:
  replicas: 6
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - qa

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

kubectl get deployments #Get deployments in the default namespace
kubectl create -f my-deployment-with-affinity.yml #Create a deployment object
kubectl get deployments #Get deployments in the default namespace

Теперь видно, что на этот раз поды были размещены только на рабочем узле node01. Причина этого в том, что мы определили сходство узлов в определении развертывания, которое гарантирует, что модули будут развернуты на узлах, соответствующих определенному условию/метке.

kubectl  get pods -o wide | grep app-with-afiinity #Get pods in the default namespace with more information about them using -o wide and grep app-with-afiinity

Заключение

В этой статье мы научились добавлять метки к узлам и увидели, как можно ограничить поды для планирования на нужных узлах с помощью Node Affinity. Мы также увидели, что модули могут быть развернуты даже на главном узле, если на нем нет заражения.