Назад в блог

Как устранять неполадки и проверять сетевое взаимодействие в Kubernetes

Как устранять неполадки и проверять сетевое взаимодействие в Kubernetes

Kubernetes — это инструмент с открытым исходным кодом, который имеет решающее значение для оркестрации контейнеров. Kubernetes помогает оркестровать и масштабировать кластеры и управлять ими в различных облачных средах или даже на локальных серверах. Кластер — это набор хостов, предназначенных для запуска контейнеризированных приложений и служб. Для работы кластера требуется как минимум два узла – один управляющий узел (master node) и один рабочий узел (worker node). Вы можете масштабировать инфраструктуру Kubernetes, добавляя новые рабочие узлы. Управляющий узел и его рабочие узлы должны иметь возможность взаимодействовать по сети для обеспечения работы инфраструктуры. Обзор наиболее важных функций Kubernetes представлен в нашем руководстве Знакомство с Kubernetes.

В этом руководстве мы покажем вам несколько инструментов и методов, которые помогут в проверке и устранении неполадок в сети Kubernetes.

Предварительные требования

  • У вас также должен быть kubectl установлен локально. В зависимости от вашей локальной среды, следуйте официальной документации по установке инструментов Kubernetes. kubectl должен быть настроен для подключения к вашему кластеру. Мы объясним это подробнее в разделе ниже.

Мы будем запускать несколько команд как локально, так и на узле Kubernetes. Давайте начнем!

Настройка локального kubectl для подключения к удаленному кластеру Kubernetes

Давайте начнем с установки kubectl. Наша локальная среда работает под управлением Ubuntu, перейдите по этой ссылке, если вы используете другую локальную среду. Чтобы установить инструменты kubectl в локальной среде Ubuntu/Debian с помощью пакетного менеджера apt, выполните следующие команды для обновления репозитория apt и установки необходимых пакетов:

Затем выполните следующую команду, чтобы загрузить публичный ключ подписи Google Cloud:

Затем добавьте apt-репозиторий Kubernetes:

После этого обновите индекс apt и установите kubectl с помощью следующей команды:

Затем убедитесь, что kubectl установлен, проверив версию с помощью следующей команды:

Вот вывод, если вы только что установили kubectl локально:

kubectl version

На скриншоте выше kubectl пытается подключиться к локальному кластеру Kubernetes. Однако это не удается, так как на нашей локальной машине еще не запущен кластер Kubernetes.

Чтобы подключиться к удаленному кластеру Kubernetes, сначала загрузите учетные данные Kubernetes с удаленного кластера. Вот команда для копирования учетных данных с управляющего узла (master node):

Замените выделенные части вашим ssh именем пользователя и публичным IP-адресом управляющего узла. После завершения загрузки учетных данных скопируйте их в свой домашний каталог:

Вот и все. Ваш локальный kubectl должен иметь возможность подключаться и отправлять команды на ваш удаленный кластер Kubernetes. Чтобы подтвердить, что ваш локальный kubectl подключен к удаленному кластеру, снова проверьте это с помощью команды version:

Вот вывод, показывающий успешное подключение:

kubectl version json

При желании вы можете выполнить get nodes команду следующим образом:

kubectl get nodes

Получение Cluster IP пода

Вы можете получить Cluster IP пода, выполнив команду kubectl get pod на вашей локальной машине. Чтобы вывести дополнительную информацию, такую как узел, на котором размещен под, и Cluster IP пода, добавьте флаг -o wide к команде:

Вот вывод из нашего кластера Kubernetes. Как вы можете видеть, в предварительном руководстве мы развернули веб-сервер Nginx:

kubectl get pod -o wide

В столбце IP показан внутренний IP-адрес отдельных подов. Если нужный вам под не отображается в списке, возможно, вы находитесь в другом пространстве имен. Вы можете выполнить следующую команду, чтобы вывести список подов во всех пространствах имен:

Получение IP-адреса службы (Service)

Вы также можете получить IP-адрес службы (Service) в вашем кластере. Добавив флаг --all-namespaces вы получите все службы, запущенные в кластере:

Вывод вышеуказанной команды выглядит следующим образом. IP-адрес службы находится в столбце cluster-ip :

kubectl get svc

Получение и доступ к сетевым пространствам имен подов

Каждому поду Kubernetes назначено сетевое пространство имен. Сетевые пространства имен, также называемые netns, представляют собой встроенные сетевые библиотеки в Linux, обеспечивающие изоляцию между сетевыми устройствами.

Чтобы проверить разрешение DNS или общее сетевое подключение, вы можете запускать команды внутри сетевого пространства имен пода. Для этого сначала нужно узнать идентификатор процесса (PID) одного из контейнеров в поде. Вы можете легко сделать это в Docker с помощью команд, специфичных для Docker. Первая команда выводит список контейнеров, запущенных на узле. Войдите на один из ваших рабочих узлов и выполните следующую команду:

docker ps

В выводе нас интересует столбец ID контейнера (container ID) или Names. Обратите внимание на контейнер Nginx, который мы развернули в предварительном руководстве Как установить и использовать Kubernetes на Ubuntu 20.04.

Затем скопируйте ID или имя контейнера, так как мы будем использовать его в следующей команде для поиска идентификатора процесса:

Замените выделенную часть вашим значением, скопированным из предыдущей команды. Ниже приведен полученный нами вывод, который представляет собой идентификатор процесса:

docker inspect

Теперь, когда у нас есть идентификатор процесса, мы можем использовать его для запуска команды nsenter внутри сетевого пространства имен процесса:

Замените выделенную часть идентификатором процесса, полученным в предыдущей команде. Затем вместо ip addr, вы можете подставить любую команду, которую хотите запустить внутри сетевого пространства имен пода. Вы также можете запустить ее с sudo, если получите ошибку отсутствия прав доступа (permission denied).

Команда nsenter позволяет запускать более широкий спектр команд, доступных на узле, в отличие от использования docker exec которая ограничивает вас только командами, установленными внутри контейнера.

Получение виртуального Ethernet-интерфейса пода

Сетевое пространство имен пода взаимодействует с корневым netns узла через виртуальный ethernet-канал (pipe). Со стороны узла этот канал выглядит как устройство, имя которого начинается с veth и заканчивается уникальным идентификатором, например veth742f721 или veth90. В то время как внутри пода этот канал идентифицируется как eth0.

Возможно, вы захотите узнать, какое устройство veth связано с конкретным подом. Вы можете начать с вывода списка всех сетевых устройств на узле, а затем вывести список всех устройств в сети пода. Чтобы определить, какое устройство veth связано с конкретным подом, вы можете сопоставить номера устройств между двумя списками.

Используйте команду nsenter, чтобы запустить команду ip addr в сетевом пространстве имен пода. Вам потребуется знать идентификатор процесса одного из контейнеров. Для этого обратитесь к предыдущему разделу Получение и доступ к сетевым пространствам имен подов.

Затем выполните следующую команду в терминале вашей рабочей ноды, заменив выделенную часть соответствующим образом:

Команда выводит список интерфейсов пода:

nsenter ip addr

Обратите внимание на if7 символы после eth0@ в выводе выше. Это означает, что eth0 связан с 7-м интерфейсом ноды. Затем выведите список интерфейсов внутри пространства имен ноды по умолчанию, выполнив команду ip addr :

Команда выводит список интерфейсов, как показано ниже:

Kubernetes Networking ip addr

В выводе 7-м интерфейсом является veth254b50e6@if3  – виртуальный ethernet-канал, связанный с подом, который мы тестируем.

Просмотр правил Iptables

Вы можете выполнить команду iptables-save для вывода списка всех iptables на ноде:

Вывод команды может быть длинным, поэтому вы можете сохранить его в файл для последующего анализа:

Вы также можете использовать less для постраничного просмотра вывода:

Поскольку нас интересуют только правила NAT Kubernetes, добавьте флаг -L для указания правильной цели:

Вот вывод:

Kubernetes Networking iptables

Проверка сведений об IPVS

Kube-proxy — это сетевой прокси-сервер, работающий на каждой ноде в вашем кластере Kubernetes. Его можно использовать для настройки IPVS для трансляции виртуальных IP-адресов служб (Service IP) в IP-адреса подов. Чтобы вывести таблицу трансляции IP-адресов, вы можете использовать команду ipvsadm . Сначала вам нужно установить ее на вашей ноде:

Теперь вы можете выполнить следующую команду:

Чтобы показать один IP-адрес службы, добавьте флаг -t , указав нужный IP-адрес:

Запросы к DNS кластера

Есть несколько способов отладки разрешения имен DNS в кластере. Официальная документация описывает один из способов: развертывание отладочного контейнера со всеми необходимыми инструментами и последующее использование kubectl для выполнения nslookup.

Кроме того, вы можете отправить запрос к DNS с помощью команд dig и nsenter непосредственно с самой ноды. Сначала вам нужно будет установить dig на вашей мастер-ноде. Для Ubuntu установите ее с помощью команды apt :

Kubernetes Networking install dnsutils

Вернитесь в терминал на локальном компьютере и выполните команду ниже, чтобы найти кластерный IP-адрес службы kube-dns :

Команда выводит:

get kube dns service

Столбец cluster-ip содержит нужное нам значение. Теперь мы можем использовать nsenter для запуска dig в пространстве имен контейнера. Однако для доступа к пространству имен контейнера вам понадобится идентификатор его процесса (PID). Инструкции см. в разделе Getting and Accessing Pod Network Namespaces выше.

Как только у вас будет container-id, выполните следующую команду на вашей мастер-ноде:

Команда dig принимает IP-адрес службы DNS кластера ( @10.96.0.10) и ищет полное доменное имя службы service-name.namespace.svc.cluster.local:

Kubernetes Networking nsenter dig

Для получения информации о поиске имен служб и пространств имен обратитесь к разделу Getting the IP address of a Service.

Просмотр отслеживания соединений Conntrack

Вы можете использовать команду conntrack для просмотра всех отслеживаемых в данный момент соединений:

Вывод выглядит примерно так, как на скриншоте:

Kubernetes Networking conntrac -l

Добавьте флаг -E для непрерывного наблюдения за входящими соединениями:

Чтобы просмотреть соединения, отслеживаемые для определенного адреса назначения, добавьте флаг -d и укажите адрес назначения:

Иногда таблица отслеживания соединений переполняется, в результате чего новые соединения сбрасываются. Это приводит к проблемам, мешающим вашим узлам устанавливать надежные соединения. Если это произойдет, вы увидите в системных журналах сообщения, подобные следующим, по пути /var/log/syslog:

Существует системная настройка для максимального количества отслеживаемых соединений. Используйте следующую команду, чтобы вывести текущее значение:

Вывод:

conntrack max

Вы можете изменить значение с помощью -w флага:

Возможно, вы захотите изменить свой /etc/sysctl.conf файл, чтобы сделать это значение постоянным и сохранить его после перезагрузки. Откройте файл с помощью nano:

Затем измените значение, если эта строка существует, или добавьте строку в конец файла, указав новое значение:

Заключение

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

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

Приятной работы!

author

Pranay Kapgate

Автор · CloudSigma

Preslav Dobrev — креативный дизайнер в CloudSigma, сосредоточенный на формировании последовательного корпоративного образа с помощью традиционных и инновационных маркетинговых каналов. Он умело сочетает художественное видение со стратегическим маркетингом, создавая убедительные истории бренда.

Комментарии

Комментариев пока нет. Будьте первым.