Отключение Kubernetes, стручки просто исчезли, отказались начать

Question

Я прошу некоторого совета, пожалуйста.

У нас был кластер Kubernetes (1.8.x), работающий на AWS, настроенный с помощью KOPS.1 мастер и 2 узла.

В выходные половина наших контейнеров исчезла и отказалась запускаться.Развертывания еще существовали, но капсулы не работали.Я попытался завершить работу узлов в AWS, и они были автоматически заменены на Kubernetes, но все же блоки не были восстановлены.

Это было производственное приложение, и после оставления его на 8 часов для самостоятельного восстановления(это не так), я удалил кластер, используя KOPS, и успешно воссоздал все это, используя новую версию Kubernetes.

Весь этот опыт был довольно тревожным, особенно в том, что я не мог выяснить, что былочто-то не так с кластером.

Мне нужна помощь в следующем:

1. Что можно / нужно было проверить, чтобы диагностировать проблему?
2. Чтомог предположительно вызвать проблему в первую очередь?Я понимаю, что сейчас это невозможно точно определить, но, пожалуйста, не стесняйтесь делать предположения.
3. Как я могу снизить будущий риск этого явления?

Большое спасибо за любые ответы.

Answer 1

Что можно / нужно было проверить, чтобы диагностировать проблему?

journalctl -u kubelet.service и / или docker logs --tail=150 ${anything_that_talks_to_the_apiserver} для поиска сообщений об ошибках. Исходя из вашего опыта с истечением срока действия сертификата x509, я бы предположил, что весь кластер будет переполнен сообщениями об ошибках

Также очень вероятно , что ваши Узлы перешли на NotReady, так как kubelet не удалось зарегистрироваться с помощью apiserver после фиксированной продолжительности. Если вы используете SDN, который обменивается данными с аписервером, например, с некоторыми фланелевыми настройками или настройками ситца, то работа с модулем Pod также тоже будет неуспешной, что является кластерной кровавой баней

Что могло быть причиной проблемы? Я понимаю, что сейчас это невозможно точно определить, но, пожалуйста, не стесняйтесь делать предположения.

Сертификаты всегда имеют срок службы, который включает время начала и время окончания; это конечное время может быть очень продолжительным - 10 лет, 100 лет, что угодно, но оно существует , и по истечении этого времени сертификат становится недействительным, и любой, кто проходит проверку сертификата, отклоняет его использование.

Как я могу снизить будущий риск этого случиться?

Существует несколько способов контроля истечения срока действия важных сертификатов в вашей системе, в том числе удобный экспортер прометея, возвращающий probe_ssl_earliest_cert_expiry, позволяющий установить оповещение на основе этого показателя. Современные kubernetes - которых 1.8 нет - позволяют кластеру поворачивать свои собственные сертификаты, концептуально обходя этот беспорядок полностью.