Задача стояла простая – развернуть кубер в закрытом периметре. Для этого в этот самый периметр надо передать используемые контейнеры. Загрузить их в локальное хранилище оных. Банальная операция:
docker save -> ctr image import
Дальше теги, пуши и установка кубера.
И вот… Ставлю это я кубер. Запускается контейнер coredns и отваливается. Запускается и отваливается. Мягко говоря – необычная ситуация. Ясное дело, без внутреннего DNS ничего работать не будет.
Дескрайб пода показывает, что не срабатывают пробы. Судя по сообщению, очень похоже на то, когда кто-то режет подключение по сети к порту. Логов контейнер не дает, только сообщения о рестарте контейнера кубелетом из-за проваленных проб. Это очень странно.
Линукс, используемый на ноде, импортозамещенный с наворотами по безопасности. Первая мысль – опять что-то ИБ закрутило. Но нет. Там все оказалось в пределах нормы. Но время на проверку потратили много.
Дольше смотрим CNI куба. Первый раз в жизни я по логам containerd и calico отследил процесс от загрузки контейнера до выдачи поду IP адреса. Серьезно прокачал эту тему. Не то что бы что-то новое узнал, но погрузился значительно глубже чем нырял раньше.
В итоге картина: контейнер загружен, под запущен, сетевой интерфейс для пода создан, IPAM IP выделил, маршруты в таблице маршрутизации есть. В кубе это все видно. В Linux это все видно. Но не работает. Curl говорит, что отказано в подключении.
В голову полезли нехорошие мысли: потерял квалификацию, пора на пенсию, придется возвращать гонорар.
Ладно, проведем еще один эксперимент: вместо стандартного coredns, который ставит по умолчанию kubeadm, поставлю его последнюю версию. Закачали образ, намутил манифесты. Установил кубер без coredns по умолчанию. Запустил свой coredns – заработало! Эээ!
И тут я вспомнил – Telegram! В качестве среды передачи контейнера от меня к ним на первом хопе был Telegram. Где-то года полтора назад, мы через телегу перекидывали большой конфиг одного приложения. После подкидывания конфига, приложение тупо не заводилось. Обнаружили, что телега внесла изменения в файл, пока передавала его на ту сторону. Вот так вот.
Проверил контрольную сумму файла контейнера предыдущего coredns на своей машине и на сервере. Оба на! Контрольная сумма не совпадает.
Получается, что containerd запустил контейнер из битого образа! Скорее всего какой-то слой контейнера не того. (Это что получается, в файле контейнера не передаются контрольные суммы слоев?) Все остальные приложения обращаются к containerd, тот уверенно говорит: все Ок! Запущен, работает. Вот вам контейнер ID, работаем! Да уж.
Долго и витеевато матерился. Мораль:
- — Telegramm не торт.
- — CRC придумали не просто так.