VY
начнем с того - что они могут в журналди лететь
Тоже верно. Стоило уточнить, что это один из вариантов
Size: a a a
2020 June 23
S
начнем с того - что они могут в журналди лететь
Зависит от настройки докера
GG
Зависит от настройки докера
так точно
ST
Кто мне может подсказать как правильно дрейнить ноды с кластера? Вроде все делается по доке куба по graceful shutdown
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Warning FailedCreatePodSandBox 7s (x4 over 34s) kubelet, tw02 (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "9e90d1f770448d82f390939ec560f1668b520f2bb24b82d7a0437ac1e0e3e411" network for pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121": networkPlugin cni failed to set up pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121_airflow" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.117.1/24
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
BD
Кто мне может подсказать как правильно дрейнить ноды с кластера? Вроде все делается по доке куба по graceful shutdown
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Warning FailedCreatePodSandBox 7s (x4 over 34s) kubelet, tw02 (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "9e90d1f770448d82f390939ec560f1668b520f2bb24b82d7a0437ac1e0e3e411" network for pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121": networkPlugin cni failed to set up pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121_airflow" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.117.1/24
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
У меня тупой кластер по типу bare-metal есть.
Я если хочу ноду вывести из кластера делаю:
kubectl cordon <node_name>, что делает ее не доступной для шедулинга новых подов.
kubectl drain <node_name>, выселяет все поды с этой ноды и шудулит их на доступных нодах.
kubectl delete <node_name>, удаляет ноду из кластера
Я если хочу ноду вывести из кластера делаю:
kubectl cordon <node_name>, что делает ее не доступной для шедулинга новых подов.
kubectl drain <node_name>, выселяет все поды с этой ноды и шудулит их на доступных нодах.
kubectl delete <node_name>, удаляет ноду из кластера
BD
После этого все корректно работает.
ST
У меня тупой кластер по типу bare-metal есть.
Я если хочу ноду вывести из кластера делаю:
kubectl cordon <node_name>, что делает ее не доступной для шедулинга новых подов.
kubectl drain <node_name>, выселяет все поды с этой ноды и шудулит их на доступных нодах.
kubectl delete <node_name>, удаляет ноду из кластера
Я если хочу ноду вывести из кластера делаю:
kubectl cordon <node_name>, что делает ее не доступной для шедулинга новых подов.
kubectl drain <node_name>, выселяет все поды с этой ноды и шудулит их на доступных нодах.
kubectl delete <node_name>, удаляет ноду из кластера
а если допустим ты бы хотел сделать автоудаление ноды, но твоя локальная нода просто отвалилась по сети и была удалена
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
BD
а если допустим ты бы хотел сделать автоудаление ноды, но твоя локальная нода просто отвалилась по сети и была удалена
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
Мне кажется нужно тюнить CloudControllerManager. Я как то делал давно это для OpenStack, и там очень много нюансов.
ST
Мне кажется нужно тюнить CloudControllerManager. Я как то делал давно это для OpenStack, и там очень много нюансов.
вот и мы к такому пришли, я вижу вариант только иключать из списка удаления
ST
но дефолтный CCM вроде так не умеет =(
BD
вот и мы к такому пришли, я вижу вариант только иключать из списка удаления
Возможно и так. Тут нужно пробовать всяческие варианты конфигурации. Более опыта у меня нет, может кто еще подскажет.
BD
а если допустим ты бы хотел сделать автоудаление ноды, но твоя локальная нода просто отвалилась по сети и была удалена
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
А как она была удалена к примеру?
VR
Кто мне может подсказать как правильно дрейнить ноды с кластера? Вроде все делается по доке куба по graceful shutdown
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
Есть условный кластер который провижнит aws-ec2 ноды через autoscaler. Простаивающие ноды нужно удалять. Для этого существует CloudControllerManager. Он должен удалить ноду из кластера, после того как она допустим выключится или удалится из aws.
После введения ноды обратно через kubeadm join появляются проблемы вида:
Warning FailedCreatePodSandBox 7s (x4 over 34s) kubelet, tw02 (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "9e90d1f770448d82f390939ec560f1668b520f2bb24b82d7a0437ac1e0e3e411" network for pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121": networkPlugin cni failed to set up pod "updatedevdbv01updateham-e35fd36d9b1c440289cee988f8ff1121_airflow" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.117.1/24
Я правильно понимаю что "graceful delete" в данном случае должен быть по схеме:
- на ноду ничего не падает
- делается drain node(удалить поды с тачки и если дизрапшен стоит, перекинуть на соседа)
- нода уходит в статус unschedulable
- нода удаляется
- CloudControllerManager видит что нода недоступна физически и удаляет ее из кластера
Такая схема правильная?
Кажется что CCM тупо удаляет ноду, а потом пытается после ре-джойна шедулить на нее поды с корявыми адресами. Или неправильно думаю?
схема правильная, но ты потом ноду не трогаешь и не ресетишь? Тогда если ввести её обратно на cni0 у неё будет неправильные адреса, о чем кубелет тебе и сообщает
ST
схема правильная, но ты потом ноду не трогаешь и не ресетишь? Тогда если ввести её обратно на cni0 у неё будет неправильные адреса, о чем кубелет тебе и сообщает
у меня по некоторым причинам гибридный кластер с дц
тонель рухнул и нода была удалена из кластера
после реджойна пошла такая вакханалия с фланелем
тонель рухнул и нода была удалена из кластера
после реджойна пошла такая вакханалия с фланелем
ST
то есть я не могу дать ему команду на дрейн заранее если сетевая связность утеряна
ST
схема правильная, но ты потом ноду не трогаешь и не ресетишь? Тогда если ввести её обратно на cni0 у неё будет неправильные адреса, о чем кубелет тебе и сообщает
вот, это оно, ресет пропустили вот и траблы
если нельзя exclude из ccm то этот вариант сойдет
если нельзя exclude из ccm то этот вариант сойдет
ST
но это сработает только для тестовых задач
например если во время прод работы отвалится нода, там ресеты делать не вариант будет
ишью в гитхабе нарыл, но дошли до обсуждения только в мае
например если во время прод работы отвалится нода, там ресеты делать не вариант будет
ишью в гитхабе нарыл, но дошли до обсуждения только в мае
VR
вот, это оно, ресет пропустили вот и траблы
если нельзя exclude из ccm то этот вариант сойдет
если нельзя exclude из ccm то этот вариант сойдет
делай юнит который переконфигурирует cni при каждом буте?
VR
у нас вся сеть устанавливается daemonset'ом, потому он всё сам умеет переписывать
DS
а если допустим ты бы хотел сделать автоудаление ноды, но твоя локальная нода просто отвалилась по сети и была удалена
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
она получит косяки как сверху
как бы нормально удалять чтобы потом при перевводе косяков не было вот думаю
cluster-autosclaer не удаляет из api куба. Да он евиктит все поды из нее, а потом дропает саму ноду через API облака. Далее Cloud controller manager видит что ноды такой в облаке нету, и удаляет ее из API куба