После удаления ситца новые поды застревают в состоянии создания контейнера.

После удаления calico, kubectl -f calico.yaml не удалось создать новые поды в кластере. Все новые поды в кластере застревают в состоянии создания контейнера. Kubectl description показывает следующие ошибки:

Предупреждение FailedCreatePodSandBox 2m kubelet, 10.0.12.2 Failed create pod sandbox: rpc error: code = Unknown desc = [не удалось настроить контейнер для песочницы «f15743177fd70c5eabf70c60be5b8b354e5346837d1b5d59bf99d1-7d1b5dd59bf99d16cd1b5d-сеть для тестирования сети» -сеть для сети pod "test-9465-768b57b5df-fv9d4_policy-demo" сеть: ошибка при получении ClusterInformation: соединение неавторизовано: неавторизовано, не удалось очистить контейнер песочницы "f15743177fd70c5eabf70c60be5b8b354e5346837d1b5d16d1bf5dbd1b5d16d1bf9d-сеть модуль teardown "test-9465-768b57b5df-fv9d4_policy-demo" сеть: ошибка получения ClusterInformation: соединение неавторизовано: Unauthorized]


kubernetes calico
person qstack    schedule 08.05.2020    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Основная проблема вызвана тем, что у calico есть контейнер инициализации, но нет контейнера очистки. Т

Чтобы отменить развертывание calico, мы должны сделать обычный kubectl delete -f <yaml>, а затем удалить файл конфигурации calico на каждом из узлов /etc/cni/net.d/. Этот файл конфигурации вместе с другими двоичными файлами загружается на хост контейнером инициализации.

https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/

Из этой ссылки мы видим, что kubelet считывает файл конфигурации из каталога по умолчанию, и, если есть несколько файлов конфигурации, он применяет подключаемый модуль CNI из файла конфигурации, который появляется первым в алфавитном порядке (почему, о боже, почему ?? ).

Итак, в нашем случае после удаления calico он будет удален из всех прав администратора, но узлы все равно будут пытаться применять правила calico на основе файла конфигурации, который он получил из каталога по умолчанию. Затем перезапустите узел, чтобы избавиться от правил iptable.

Удаление файла и перезапуск узла решают проблему, и мы возвращаемся к нормальному поведению. Другой способ решить ту же проблему - просто отключить узел из кластера, если вы находитесь в управляемом кластере Kubernetes. Поскольку инфраструктура общедоступного облака автоматически загружает другой узел, чтобы сохранить то же состояние, у него больше нет файла конфигурации calico.

person qstack    schedule 08.05.2020