Kubernetes стал популярной платформой для развертывания контейнерных приложений. Но даже в таких надежных системах, как Kubernetes, могут возникать проблемы. Когда в вашем кластере Kubernetes возникают проблемы, наличие надежной методологии устранения неполадок является ключом к быстрому разрешению.
В этой статье я предоставлю подробное руководство по устранению неполадок Kubernetes. Я расскажу о методах проверки работоспособности кластера, проверки запуска Pod, проверки сети и хранилища, анализа журналов и мониторинга взаимодействия кластера. Я также рассмотрю конкретные сценарии, такие как отладка DNS для служб.
Исследование сбоев при запуске модуля
Прежде чем углубляться в устранение неполадок, важно понять, как модули работают в Kubernetes. Модули — это наименьшие развертываемые модули, инкапсулирующие один или несколько контейнеров. Контейнеры внутри модуля совместно используют ресурсы и сетевые пространства имен.
Чтобы устранить проблемы с запуском модуля, сначала определите симптомы из журналов или мониторинга. К частым причинам неисправности относятся:
- Чрезмерное использование ресурсов. Слишком много модулей на узле может привести к исчерпанию ресурсов и сбою узла. Проверьте нагрузку на память, процессор или диск.
- Превышен лимит ресурса. Утечки памяти в приложении могут привести к увеличению объема памяти модуля. Настройте ограничения памяти и процессора.
- Проблемы с сетью. Модули не могут обмениваться данными, что, скорее всего, указывает на неправильную настройку сетевого плагина. Проверьте подключение и статус плагина.
- Подключение к хранилищу. Если не удалось подключиться к общему хранилищу, запуск модуля будет заблокирован. Убедитесь, что серверная часть хранилища работает и определения томов верны.
- Сбои приложений. Сбои кода приложения могут привести к циклам перезапуска модуля. Просмотрите журналы приложений на наличие исключений и трассировок стека.
- Ошибки конфигурации. Проблемы с манифестами ресурсов Kubernetes могут помешать созданию модулей. Дважды проверьте допустимые конфигурации модуля, развертывания и набора состояний.
Наконец, используйте системы мониторинга и журналирования, такие как Prometheus и ElasticSearch, чтобы получить представление о запуске и производительности модулей. Комплексное представление помогает быстрее выявлять и устранять основные причины.
Проверка работоспособности кластера
Команда kubectl get nodes предоставляет обзор работоспособности кластера, показывая состояние узла. Неготовые или ненормальные узлы часто указывают на проблемы с основными компонентами, такими как etcd, kubelet или kube-proxy. Это может помешать правильной работе приложений в кластере. Всегда начинайте устранение неполадок с проверки работоспособности узлов.
Изучите журналы событий кластера
Журналы событий содержат ценную информацию о действиях и ошибках, происходящих в кластере. Используйте kubectl get events для просмотра журналов событий. Ищите предупреждения или ошибки, связанные с компонентами Kubernetes, системными службами или сбоями приложений. Сообщения о событиях могут указывать на основные причины, такие как проблемы с конфигурацией, нехватка ресурсов или сбои компонентов.
Проверить статус модуля
Статус модуля предоставляет моментальный снимок состояния контейнера. Запустите kubectl get pods --all-namespaces, чтобы увидеть все модули в масштабе кластера. Поды в состояниях ожидания, аварийного цикла или ошибки требуют более тщательного изучения. Используйте kubectl describe pod <pod-name>, чтобы получить более подробную информацию о проблемном модуле. Статус и описания модулей показывают проблемы с приложениями, сетью, хранилищем, зависимостями и т. д. Сосредоточьтесь на устранении неполадок модуля на контейнерах, которые работают неправильно.
Проверка подключения к сети
Проблемы с сетью могут проявляться по-разному. Просмотрите статус обслуживания с помощью kubectl get services и kubectl describe service, чтобы проверить наличие аномалий. Проверьте соединение между модулями и узлами. Убедитесь, что сетевые политики разрешают ожидаемые потоки трафика. Проверьте конфигурацию и состояние плагина CNI. Сетевые сбои, такие как задержка, потеря пакетов и неправильная маршрутизация, могут вызвать проблемы.
Изучите конфигурацию хранилища
Для приложений с отслеживанием состояния проверьте компоненты хранилища, такие как PersistentVolumes (PV), PersistentVolumeClaims (PVC) и StorageClasses. Используйте kubectl get pv, kubectl get pvc и kubectl get storageclass для проверки конфигурации. Неправильно настроенные классы хранения, несвязанные виртуальные виртуальные каналы, недостаточное количество физических ресурсов и сбои внутреннего хранилища могут помешать запуску модуля.
Анализ журналов контейнера
Ошибки и сбои приложений часто регистрируются контейнерами до возникновения проблем. kubectl logs обеспечивает доступ к выводам журнала. Для модулей с несколькими контейнерами используйте kubectl logs -c, чтобы выбрать контейнер. Просмотрите журналы на предмет исключений, трассировки стека, задержек и любых очевидных ошибок. Данные журнала предоставляют жизненно важный контекст для устранения проблем приложений.
Проверка разрешения DNS службы
Службам Kubernetes назначаются записи DNS A, которые модули используют для обнаружения и подключения. Запуск из модуля в том же пространстве имен:
u@pod$ nslookup hostnames Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
Если это не помогло, то ваш модуль и служба могут находиться в разных пространствах имен. Попробуйте использовать имена с указанием пространства имен:
u@pod$ nslookup hostnames.default Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames.default Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
В случае успеха вам необходимо настроить приложение для использования имен в разных пространствах имен для доступа к службам или запуска приложений и служб в одном пространстве имен. Если это по-прежнему не помогло, попробуйте полное имя:
u@pod$ nslookup hostnames.default.svc.cluster.local Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: hostnames.default.svc.cluster.local Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
Обратите внимание на суффикс: «default.svc.cluster.local». «по умолчанию» — это пространство имен, в котором я работаю. «svc» указывает, что это служба. «cluster.local» — это домен вашего кластера, в вашем кластере он может отличаться.
Вы также можете попробовать это на узле вашего кластера:
Примечание. 10.0.0.10 — это моя служба DNS, ваша может отличаться.
u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10 Server: 10.0.0.10 Address: 10.0.0.10#53 Name: hostnames.default.svc.cluster.local Address: 10.0.1.175
Если вы можете искать, используя полные имена, но не относительные имена, вам необходимо проверить правильность файла /etc/resolv.conf.
u@pod$ cat /etc/resolv.conf nameserver 10.0.0.10 search default.svc.cluster.local svc.cluster.local cluster.local example.com options ndots:5
Строка поиска должна содержать соответствующий суффикс для имени искомой службы. В этом контексте он ищет службы в различных областях, включая локальное пространство имен (default.svc.cluster.local), службы во всех пространствах имен (svc.cluster.local) и весь кластер (cluster.local). В зависимости от вашей установки могут существовать дополнительные записи, максимум шесть.
Суффикс кластера передается в kubelet через флаг —cluster-domain. В этом документе предполагается, что суффикс — «cluster.local», но ваша конфигурация может отличаться. Если да, обязательно отрегулируйте его во всех командах, представленных выше.
В строке «options» должно быть установлено значение «ndots», чтобы клиентская библиотека DNS учитывала путь поиска. По умолчанию Kubernetes устанавливает это значение равным 5, что может повлиять на поведение разрешения DNS для имен, содержащих пять или более точек. Этот параметр может переопределить домены поиска.
Отладка сети кластера
Кластеры Kubernetes полагаются на сетевые плагины, такие как Calico, Flannel и Canel, для обеспечения внутреннего управления IP-адресами и подключения. Общие пути связи для проверки включают в себя:
- Трафик между модулями в одном пространстве имен
- Межпространственная связь между модулями
- Под получает доступ к внутрикластерным сервисам через DNS
- Внешний трафик, входящий/выходящий из кластера
Используйте nslookup из модулей, чтобы проверить разрешение служб DNS. Если не удается решить проблему, проверьте:
- Домены поиска в
/etc/resolv.confсоответствуют пространству имен и содержат соответствующий суффикс домена кластера. - IP-адрес службы DNS настроен правильно как сервер имен
- Параметр ndots установлен достаточно высоко для использования поисковых доменов
Также проверьте установку плагина, назначение IP, конфигурацию политики и журналы компонентов. Сетевые плагины, такие как Calico, предоставляют расширенные инструменты отладки.
Задержка, потеря пакетов, неправильная маршрутизация и проблемы с подключением могут указывать на неправильно настроенный сетевой плагин, политики, блокирующие трафик, или проблемы с инфраструктурой. Тщательно проверяйте и наблюдайте за сетевыми потоками, чтобы выявить проблемы в сети кластера.
Заключение
Устранение неполадок Kubernetes — сложный, но важный навык. Хотя я рассмотрел несколько ключевых аспектов, необходимые действия будут зависеть от вашей конкретной настройки кластера, приложений и режимов сбоя. Считайте это руководство отправной точкой для приобретения опыта отладки Kubernetes.
Когда возникают проблемы, не делайте поспешных выводов. Вместо этого методично проверяйте работоспособность кластера, состояние модуля, события, журналы, сеть, хранилище и конфигурации. Переходите от проверки всей системы к изучению конкретных компонентов и слоев.
Используйте такие инструменты, как Prometheus, Linkerd и Kubernetes Dashboard, чтобы обеспечить прозрачность. По возможности воссоздайте проблемы в промежуточных средах. Документируйте каждую неудачу, чтобы постоянно совершенствовать знания по устранению неполадок.
Приобретя опыт, вы научитесь быстро диагностировать широкий спектр проблем Kubernetes. Освоение этих методов устранения неполадок поможет минимизировать время простоя приложений и поддерживать высокую доступность сервисов в Kubernetes. Несмотря на сложность, отладка проблем кластера со временем становится проще. Будьте настойчивы и думайте целостно во время каждого пути по устранению неполадок.
