Как перенести Kubernetes podы на другую ноду (машину)?

Question

[Вадим]

есть задача перевести работающие pods на другую машину, все равно какую... как бы вы к ней подошли самым простым и легким способом. При этом желательно, чтобы количество pods в каждом deplyment в любой момент времени не было бы меньше чем N, как указано в replicas: N

Оба pods в составе deployment... при удалении система новые pods ставит на этот же сервер.

Answer 1

[Дмитрий]

Отключить ноду, кубер поднимет поды на другой свободной ноде

Comments

[Вадим]

Хорошо kubectl drain node --ignore-daemonsets

а при этом будет момент когда количество pods уменьшится до 0?

[shurshur]

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

Answer 2

[bankinobi]

Здравствуйте.
Поды не переносятся, они пересоздаются.
Старый - убивается, новый создаётся.
Запускайте деплойменты через replicaset, там указываете минимальное minReplicas и максимальной maxReplicas число реплик и кластер будет их поддерживать.
Или настройте у деплоймента стратегию: обновление: RollingUpdate
и настроить параметра maxSurge и maxUnavailable.
А чтоб поды не лежали на одной ноде прикрутите podAntiAffinity с лейблами.

Comments

[Вадим]

Спасибо Джедай Обиван )

можете уточнить некоторые вещи

1) Запускайте деплойменты через replicaset, там указываете минимальное minReplicas и максимальной maxReplicas - извиняюсь, а это где? В deployment yaml их разве можно указать? Толькo через новый обьект -
HorizontalPodAutoscaler

2) Добавил в deployment
strategy:
rollingUpdate:
maxSurge: 2
maxUnavailable: 1 (пробовал и 0 ставить)

не совсем работает - делаю kubectl drain node01 - под работающий на ноде - удаляется и только потом начинает создаваться новый - не есть хорошо!

[bankinobi]

1. replicaset

spec:
  # modify replicas according to your case
  replicas: 3

Указывает на создание 3 реплик деплоймента, шаблон которого прописывается ниже в секции template
2.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-nginx
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 2
  selector:
    matchLabels:
      app: rolling-nginx
  template:
    metadata:
      labels:
        app: rolling-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9

В этом деплойменте 4 реплики, при этом максимально недоступны (maxUnavailable) могут быть 2 пода, и превышать число заданных реплик (maxSurge) могут на 1.

У дрейна перед деплойментами приоритет выше, поэтому он сначало убивате, потом создает.
Есть полиси специальное PodDisruptionBudget, задает количество сбоев для объектов.
В нем и указывают, что во время дрейна "сначало создай,потом убивай".

Answer 3

[kabelsea]

Сделать ноде drain ... шедулер освободит ноду пересозданием подов на других нодах сам с учетом всех указанных стратегий для update и тд

Если нужно поды перенести на определенные ноды, то использовать node labels и соответствующие annotations для deployment