как узнать версию kubernetes
Полезные команды и советы при работе с Kubernetes через консольную утилиту kubectl
Автоматическое дополнение в shell
В kubectl есть отличное встроенное автодополнение для bash и zsh, что значительно упрощает работу с командами, флагами и объектами вроде пространств имён и названий подов. В документации есть готовые инструкции по его включению. А GIF-анимация ниже показывает, как автодополнение работает:
Слияние конфигов с контекстами через KUBECONFIG
Слияние конфигураций Kubernetes — популярный паттерн, если вы взаимодействуете со множеством кластеров Kubernetes. При работе с разными конфигами используется концепция контекста ( context ), указывающего на параметры, которые kubectl будет использовать для поиска конкретного, целевого кластера. Но добиться нужного результата с контекстами бывает сложно. Чтобы упростить себе жизнь, воспользуйтесь переменной окружения KUBECONFIG — она позволяет указать на конфигурационные файлы, которые используются при слиянии. Подробнее о KUBECONFIG можно прочитать в официальной документации.
Например, у вас есть два конфига Kubernetes для разных кластеров, и требуется провести их слияние.
Конфиг первого кластера:
Конфиг второго кластера:
У каждого конфигурационного файла есть единственный контекст, так что они не конфликтуют между собой. Слияние двух файлов через KUBECONFIG показывает оба контекста. Для сохранения текущего контекста создайте новый пустой файл с названием cluster-merge :
Новый контекст можно использовать так:
Изучение Kubernetes API
Чтобы узнать больше о возможностях, предоставляемых Kubernetes API, запросите файл swagger.json :
Можно также зайти на http://localhost:8001/api/ и посмотреть на имеющиеся в Kubernetes API пути.
Просмотр swagger.json поможет понять Kubernetes API. Это сложный API, функции в котором разбиты на группы, что затрудняет его восприятие:
А вот следующая команда описывает API, доступные в кластере Kubernetes и к которым у вас есть доступ. Команда в примере ниже выполнена под пользователем-администратором. Если у вас включён контроль доступа по RBAC, вывод может отличаться:
Команда kubectl explain помогает лучше понять, что делают разные компоненты API:
Операции с подами через kubectl
Если у вас нет запущенного приложения, для знакомства с примерами можно создать поды с лейблом run=shop и запустить их как сервис на порту 80:
Фильтрация подов Kubernetes по времени их создания
Поиск пода Kubernetes по селектору лейбла и просмотр его логов
Укажите пространство имён ( your-namespace ) и свой запрос на наличие лейбла, который поможет найти нужные поды, и получите логи этих подов. Если под не единственный, логи будут получены из всех подов параллельно:
Поиск пода Kubernetes по селектору лейбла и подключение к нему
Укажите пространство имён ( your-namespace ) и свой запрос на наличие лейбла, который поможет найти нужные поды, и подключитесь к нему по имени (к первому из найденных подов). Замените 8080 на нужный порт пода:
Операции с узлами (нодами) через kubectl
Комбинация jq и JSON-вывода kubectl позволяет делать сложные запросы, такие как фильтрация всех ресурсов по времени их создания.
Подсчёт количества подов в узле Kubernetes
Зачастую высокоуровневая статистика помогает в отладке. Эта команда подсчитает количество всех подов на каждом из узлов:
Фильтрация узлов по лейблу
Список всех подов для каждого узла
Генерируется JSON-документ с названием узла Kubernetes и список всех названий подов, запущенных на этом узле. Очень полезная команда при отладке:
Получение внешних IP для узлов Kubernetes
Примечание: Читайте в нашем блоге перевод другой статьи от CoreOS про работу с Kubernetes из консоли: «Автоматизация SSH-доступа к нодам Kubernetes с помощью Fabric и интеграции от CoreOS», а также заметку «Полезные утилиты при работе с Kubernetes» (в ней представлены преимущественно консольные инструменты).
Шпаргалка по Kubectl для администраторов Kubernetes и подготовка к экзамену CKA
Шпаргалка по Kubectl для администраторов Kubernetes и подготовка к экзамену CKA
Это самоуверенный чит-лист, созданный для использования в качестве ориентира для ежедневных операций Kubernetes и администрирования, выполняемых через интерфейс командной строки с помощью kubectl. Если вы готовитесь к экзаменам CKA или CKAD, шпаргалка содержит команды, которые помогут вам быстро выполнить экзаменационные задания. При подготовке к экзамену не следует полностью полагаться на этот документ, а лучше пройти курс по содержанию с большой практикой.
Если у вас есть команда kubectl для экономии времени, которую мы пропустили в этом посте, не стесняйтесь оставить ее в разделе комментариев. Мы будем рады обновить документ в любое время.
Мы начнем с полезных общих команд, прежде чем рассмотрим команды для конкретных задач, используемые при развертывании администрирования и приложений в Kubernetes или OpenShift Cluster.
Полезные команды для общего использования
Ниже приведены некоторые из наиболее полезных команд общего пользования при работе с Kubernetes.
1. Установите kubectl
Вот как установить kubectl в Linux и macOS:
Linux
macOS:
Подтвердите установку, проверив версию:
2. Включите завершение Bash.
По умолчанию завершение Bash не включено после установки команды kubectl. Включите его с помощью команд ниже.
Bash:
3. Список и переключение контекста
Контекст — это группа параметров доступа. Каждый контекст содержит кластер Kubernetes, пользователя и пространство имен.
Переключайтесь между кластерами, задав текущий контекст в файле kubeconfig :
Установите запись контекста в kubeconfig:
Если вы хотите изменить предпочтение пространства имен, используйте:
См. Текущий контекст:
4. Проверьте синтаксис файла yaml манифеста.
Если вы создали yaml-файл развертывания и хотите проверить синтаксис, используйте команду:
Если есть синтаксические ошибки, вы получите из вывода:
5. О чистите узел при удалении локальных данных.
Узел может быть очищен, а также очищены локальные данные, используемые запущенными контейнерами. Для этого используется синтаксис команды:
Для принудительного слива вы можете добавить —force флаг, хотя это не рекомендуется.
6. Примените файлы и папки yaml.
Вы можете использовать аргумент apply, чтобы применить конфигурацию к ресурсу по имени файла или стандартному вводу. Синтаксис команды:
Для папки с несколькими ямл-филами используйте:
С абсолютным путем:
7. Создавайте псевдонимы для экономии времени.
Вы также можете создать несколько псевдонимов, которые значительно ускорят использование командной строки.
8. Запустите временный модуль, который умирает при выходе.
Вы можете быстро создать временный модуль с сеансом оболочки для целей тестирования, который будет уничтожен при выходе.
9. Создайте пространство имен.
Пространство имен создается с помощью команды:
Чтобы переключиться в пространство имен для всех операций, используйте:
10. Запустите команду оболочки в Pod без tty.
Давайте создадим модуль, работающий в фоновом режиме.
Подтвердите, что Pod запущен:
Запуск сеанса оболочки с модулем:
Запуск команды прямо в контейнере без tty.
11. Проверьте переменные среды в модуле.
Чтобы перечислить все переменные среды в модуле, используйте команду:
12. Получите объяснение использования ресурсов.
13. Сортировка ресурсов по названию.
Чтобы перечислить ресурсы, отсортированные по имени, вы будете использовать.
14. Создайте YAML-файл манифеста модуля.
Вы можете использовать kubectl run для создания файла манифеста yaml для развертывания Pods.
Страница справки по командам.
Следующая команда печатает соответствующие объекты API, не создавая их:
С ограничениями памяти и ЦП:
С запросами и ограничениями как ЦП, так и памяти.
Вы можете направить вывод в файл.
Затем вы можете создать модуль, применив файл.
Подтвердите, что Pod запущен:
15. Создайте файл YAML для развертывания.
Вы можете изменить файл и применить создание ресурсов.
Список модулей, соответствующих Nginx.
16. Предоставление доступа к модулю или развертыванию в службе.
Используйте команду kubectl expose, чтобы сделать развертывание или Pod доступными на ClusterIP или NodePort.
Вы также можете вручную указать порт, предоставляемый контейнером (порт приложения).
17. Масштабирование модулей в развертывании.
Вы можете увеличить количество модулей в развертывании, не редактируя какой-либо файл.
18. Перенесите все модули в узел и сделайте его недоступным для планирования.
Определите узел, над которым нужно действовать:
Затем скажите Kubernetes, чтобы он опустошил узел:
Возможно, вам придется игнорировать наборы демонов и удалить данные локального контейнера.
Скажите Kubernetes, чтобы он прекратил планировать новые поды на ноде:
Чтобы возобновить планирование на узле, используйте команду:
19. Создание нескольких контейнеров в модуле
Отредактируйте файл и добавьте другие контейнеры в названный модуль.
Мы добавили два контейнера — nginx и redis. Чтобы применить конфигурации, выполните команду:
Убедитесь, что в капсуле есть два контейнера.
20. Создание учетной записи службы, роли и привязки ролей
Создайте сервис под названием demo.
Создайте роль с именем demo, которая позволяет пользователю выполнять «получение», «просмотр» и «список» для модулей, развертывания, ds, rs, sts:
Создайте RoleBinding для demo роли.
21. Получение журналов для пакетов
Получить последние журналы на именованном поде:
Следите за потоком логов в реальном времени.
Получите последние журналы из всех модулей в развертывании:
Используйте регулярное выражение для извлечения журналов.
Записать вывод в файл:
Распечатайте журналы для предыдущего экземпляра контейнера в модуле, если он существует.
22. Получите лучшие стручки
Получите лучшие модули использования ресурсов.
Получите лучшие модули с высокой загрузкой ЦП:
Фильтр с помощью меток.
Получите только один модуль с максимальной загрузкой ЦП и запишите вывод в файл.
23. Развернуть и откатить развертывание
Разверните контейнер Nginx.
Обновление развертывания для использования образа nginx версии 1.14.2
Проверить статус внедрения
Просмотрите историю развертывания развертывания:
Откат к предыдущему развертыванию:
Развертывание до конкретной версии
24. Обозначьте узел и назначьте модули узлам.
Как добавить метки к Node.
Затем вы можете назначить модули для узлов.
25. Копирование файлов в модули и из модулей.
В kubectl CP команды могут быть использованы для копирования файлов в стручках или из стручки.
В этом примере мы скопируем файлы из модуля в нашу локальную систему.
Давайте подтвердим, что два скопированных файла доступны локально.
Скопируйте файл в Pod.
Дополнительные примеры см. На странице справки.
26. Отладка DNS.
Запустите модуль DNS Utils:
Подтвердите, что модуль запущен:
Или получить доступ к оболочке
Проверка настроек конфигурации локального DNS:
Проверка того, запущены ли DNS Pods:
Убедитесь, что конечные точки DNS доступны:
Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием
На начало декабря 2020 у нас во «Фланте» было около 150 кластеров на Kubernetes 1.16. Это кластеры с разной степенью загруженности: как находящиеся под высоким трафиком production-кластеры, так и использующиеся для разработки и демонстрации новых возможностей. Кластеры работают поверх различной инфраструктуры, начиная с облачных провайдеров, таких как AWS, Azure, GCP, Яндекс.Облако, различных инсталляций OpenStack и vSphere, и заканчивая железками.
Все эти кластеры находятся под управлением Deckhouse, который является нашей внутренней разработкой и позволяет не только иметь один инструмент для создания кластеров, но и общий интерфейс для управления всеми компонентами кластера на всех поддерживаемых типах инфраструктуры. Для этого Deckhouse состоит из различных подсистем. Например, есть подсистема candi (cluster and infrastructure), которая наиболее интересна в рамках данной статьи, поскольку отвечает за управление control-plane Kubernetes и настройку узлов, предоставляет готовый к работе, актуальный кластер.
(Оценить плюсы Deckhouse пока можно в рамках нашего Managed Kubernetes, а уже в ближайшее время мы планируем сделать первый Open Source-релиз проекта для всех желающих посмотреть на него изнутри и развернуть для своих задач. Присоединиться к числу ожидающих можно в Telegram-канале.)
Итак, почему мы вообще застряли на версии 1.16, когда уже достаточно давно вышли 1.17, 1.18 и даже выпустили патч версии для 1.19? Дело в том, что у нас затянулось предыдущее обновление кластеров — с 1.15 на 1.16. Оно было очень тяжелым и вот почему:
Обновление с 1.15 на 1.16 приводило к рестарту контейнеров на узле, поэтому приходилось выполнять drain узла, что в случае большого количества stateful-приложений приводило к необходимости выполнять работы в согласованные окна и требовало особого внимания инженеров.
Эти 2 фактора сильно тормозили процесс обновления на 1.16. С одной стороны необходимо было добиваться от клиентов обновления чартов и выпуска обновлений, а с другой — аккуратно обновлять кластеры в наполовину ручном режиме. Была проделана большая работа со всеми пользователями кластеров, потому что требовалось донести, что существует реальная необходимость обновления, а подход «работает — не трогай» в данном случае может сыграть злую шутку… Попробую убедить в этом и вас.
Зачем вообще обновлять Kubernetes?
Одной из самых очевидных вещей, которой проще всего объяснить обновление, является устаревание программного обеспечения. В проекте Kubernetes поддерживаются только 3 последние минорные версии. Таким образом, на момент выхода 1.19 наша текущая версия 1.16 должна была покинуть список поддерживаемых. Хотя так совпало, что именно в этом релизе (1.19) разработчики Kubernetes пошли навстречу сообществу и увеличили окно поддержки до 1 года. Это изменение стало ответом на грустную статистику, которая показала, как медленно обновляются инсталляции K8s в реальной жизни (по результатам опроса в начале 2019 года лишь 50-60% кластеров K8s имели поддерживаемую версию).
На момент этого опроса актуальной версией Kubernetes была 1.13, т.е. все пользователи K8s 1.9 и 1.10 работали с релизами, которые уже не поддерживались.
Примечание. Тема обновлений релизов Kubernetes вообще широко обсуждается в сообществе инженеров эксплуатации. Например, опросы Platform9 от 2019-го года (№1, №2) показали, что обновление — в топ-3 главных вызовов при обслуживании Kubernetes. Легко найти в интернете и связанные с обновлениями failure stories, вебинары и т.д.
Но вернёмся к релизу 1.16. С ним также был ряд проблем, которые мы вынужденно затыкали «костылями». Вполне возможно, что большинство из читателей не сталкивались с описанным ниже, однако у нас на поддержке большое количество кластеров (с тысячами узлов), поэтому даже редкие ошибки регулярно генерировали нам дополнительную работу. К декабрю мы обросли различными забавными компонентами как в самом Kubernetes, так и в системных юнитах:
Иногда случалось совсем страшное. В кластерах можно было получить целую пачку проблем с узлами, потому что зависали kube-proxy на обращении к kube-apiserver. Причиной всему являлось отсутствие health check для HTTP/2-соединений для всех клиентов, использующихся в Kubernetes. При зависшем kube-proxy по понятным причинам начинались сетевые проблемы на узлах, что могло приводить к простою. Исправление было выпущено для 1.20 и сделан backport только в 1.19. Кстати, этот же фикс решил проблемы с зависанием kubelet. Были также проблемы, что периодически мог зависать kubectl на каких-то длительных операциях и приходилось всегда помнить, что следует использовать timeout.
Как устроен процесс обновления Kubernetes
В начале статьи уже кратко упоминался Deckhouse и подсистема candi, которая отвечает в том числе и за процесс обновления control-plane и узлов кластера. Если не погружаться в нюансы, то внутри имеется немного допиленный kubeadm, поэтому структурно процесс обновления совпадает с документацией Kubernetes по обновлению кластеров под управлением kubeadm.
Этапы обновления с 1.16 на 1.19 выглядят следующим образом:
Обновление версии control-plane до версии 1.17;
Обновление версии kubelet на узлах до версии 1.17;
Обновление версии control-plane до версии 1.18;
Обновление версии kubelet на узлах до версии 1.18;
Обновление версии control-plane до версии 1.19;
Обновление версии kubelet на узлах до версии 1.19.
В Deckhouse эти этапы выполняются автоматически. Для этого в каждом кластере есть Secret, в котором описана конфигурация кластера в YAML’е следующего формата:
Для обновления достаточно изменить значение kubernetesVersion на желаемое (можно менять сразу с 1.16 на 1.19). Внутри подсистемы candi есть два модуля, которые отвечают за управление control-plane и управление узлами.
В сontrol-plane-manager автоматически отслеживаются изменения в данном YAML.
Вычисляется текущая версия Kubernetes в кластере на основании версии control-plane и узлов кластера. Например, если kubelet на всех узлах версии 1.16 и все control-plane компоненты версии 1.16, то можно запускать обновление на следующую версию 1.17 — и так далее, пока версия не будет той, что указана в конфигурации.
Также control-plane-manager следит, чтобы обновление компонентов control-plane выполнялось по очереди на каждом из мастеров: для этого реализован алгоритм запроса и выдачи разрешения на обновление через специальный диспетчер.
Node-manager отвечает за управление узлами, в том числе и за обновление kubelet’а:
Каждый узел в кластере принадлежит к одной из NodeGroup. Как только node-manager определяет, что версия control-plane на всех узлах обновилась, то он приступает к обновлению версии kubelet. Если обновление узла не приводит к простою, оно считается безопасным и выполняется в автоматическом режиме. В данном случае обновление kubelet больше не приводит к перезапуску контейнеров, что позволило безопасно выкатывать его.
Наш опыт обновления Kubernetes на 1.19
Итак, мы решили обновляться сразу на 1.19, фактически минуя версии 1.17 и 1.18, по нескольким причинам.
Основная причина была в том, что не хотелось затягивать процесс обновления. Каждый цикл обновления требует различных согласований с пользователями кластеров, инженерного времени на контроль процесса обновления. Таким образом, мы снова продолжали бы рисковать отставать от upstream’а на несколько версий. Мы хотели, чтобы к февралю 2021 все наши кластеры были версии 1.19. Поэтому было твёрдое желание одним волевым усилием получить максимально свежую версию Kubernetes в наших кластерах — тем более, уже на подходе был 1.20 (его релиз состоялся 8 декабря 2020).
Как уже написано выше, у нас есть кластеры, которые работают поверх различных облачных провайдеров. Чтобы реализовать это требуется использование нескольких компонентов, специфичных для каждого провайдера. Для управления дисками используется Container Storage Interface, а для взаимодействия с API облачных провайдеров — Cloud Controller Manager. Тестирование работоспособности этих компонентов для каждой версии Kubernetes требует достаточно большого количества ресурсов. В данном случае нет потребности тратить столько времени впустую на «промежуточные» версии.
Процесс
Было проведено полное тестирование совместимости компонентов с версией Kubernetes 1.19 и принято решение обновляться сразу на 3 версии вперёд. Так как стандартный процесс обновления выполняется последовательно, то на момент, когда версия control-plane в облачных кластерах соответствовала 1.17 и 1.18, были отключены компоненты, описанные выше.
Фактическое время обновления зависело от числа worker-узлов и узлов control-plane, занимало от 20 до 40 минут. На это время в облачных кластерах не работал заказ и удаление узлов, любые операции с дисками. При этом уже работающие в кластере узлы и примонтированные диски продолжали работать корректно. Это был единственный очевидный минус запланированного обновления, с которым пришлось смириться на старте. Только из-за этого было принято решение проводить работы по обновлению большинства кластеров в ночное время, когда нет высокой нагрузки.
Сам процесс обновления мы сначала прогнали несколько раз на внутренних dev-кластерах, после чего начали проводить на клиентских. Естественно, тоже по нарастающей, стартовав с dev-кластеров, которые можно было обновить даже с небольшим простоем.
Первые апгрейды и первое препятствие
Массовые обновления
К концу декабря 2020 года мы имели около 50 кластеров Kubernetes, обновленных до 1.19. До сих пор выполнялось параллельное обновление по несколько (2-3, максимум — 5) кластеров. Но так как уверенность в стабильности и корректности обновления росла, отлично отметив 2021-й Новый Год, мы решили запустить обновление около 100 оставшихся кластеров одновременно, чтобы к концу января иметь только парочку последних кластеров на 1.16. Кластеры были разбиты на две группы, в каждой — около 50 кластеров.
Failed to initialize CSINodeInfo: error updating CSINode annotation
Отлаживать, к сожалению, времени не было: так как кластер находился на железе, которое почти всегда полностью загружено, выход одного узла из строя уже начинал сказываться на работоспособности приложения. Было найдено быстрое решение, которое, надеюсь, поможет и вам, если столкнётесь с похожей проблемой. Однако повторюсь, данная проблема в итоге возникла только на одном(!) из 150 кластеров в процессе обновления, поэтому вероятность получить такую же проблему минимальна.
Чтобы успеть в сроки, которые мы сами себе обозначили, на 28 января в 00:00 было запланировано обновление второй группы кластеров, в которой остались самые нагруженные producton’ы: простой в них приводит к написанию постмортемов, нарушению SLA и штрафам. Процесс обновления контролировал лично наш CTO — @distol… И всё прошло как по маслу: совсем ничего примечательно во время обновления не случилось, никакое ручное вмешательство не потребовалось. В нашем Telegram-канале появилось радостное сообщение:
Последняя боль
Но позже выяснилось, что нам досталась одна проблема, которая произошла из-за обновления, но последствия её проявились только через пару дней (и как обычно в одном из самых нагруженных и ответственных проектов…).
Во время обновления несколько раз перезапускается kube-apiserver. Исторически сложилось, что в части кластеров под управлением Deckhouse активно используется flannel, где всё это время была упоминавшаяся ранее в статье проблема с зависанием Go-клиента из-за отсутствия health check для HTTP/2-соединений при обращении к API Kubernetes. В итоге, на части узлов в кластере в логах flannel появились ошибки:
Это привело к тому, что на этих узлах некорректно работал CNI и проскакивали 500-е ошибки при обращении к сервисам. Рестарт flannel исправил проблему, а для глобального решения необходимо обновлять flannel.
К счастью, относительно недавно (15 декабря 2020) появился pull request, который обновляет версию client-go. На момент написания данной статьи это исправление доступно в релизе v0.13.1-rc2, и мы планируем глобально обновить версию flannel во всех кластерах под управлением Deckhouse.
В чем же удовольствие?
У нас уже готова и поддержка версии Kubernetes 1.20, так что в скором времени мы обновим кластеры на неё по аналогичной схеме. А уж если столкнёмся с какими-то интересными особенностями — обязательно об этом расскажем.