Kubernetes — это инструмент с открытым исходным кодом, который имеет решающее значение для оркестрации контейнеров. Kubernetes помогает оркестровать и масштабировать кластеры и управлять ими в различных облачных средах или даже на локальных серверах. Кластер — это набор хостов, предназначенных для запуска контейнеризированных приложений и служб. Для работы кластера требуется как минимум два узла – один управляющий узел (master node) и один рабочий узел (worker node). Вы можете масштабировать инфраструктуру Kubernetes, добавляя новые рабочие узлы. Управляющий узел и его рабочие узлы должны иметь возможность взаимодействовать по сети для обеспечения работы инфраструктуры. Обзор наиболее важных функций Kubernetes представлен в нашем руководстве Знакомство с Kubernetes.
В этом руководстве мы покажем вам несколько инструментов и методов, которые помогут в проверке и устранении неполадок в сети Kubernetes.
Предварительные требования
-
Для выполнения шагов из этого руководства вам понадобится кластер Kubernetes. У нас есть руководство, объясняющее Как установить и использовать Kubernetes на Ubuntu 20.04, которое поможет вам настроить базовый кластер для демонстрации.
-
У вас также должен быть kubectl установлен локально. В зависимости от вашей локальной среды, следуйте официальной документации по установке инструментов Kubernetes. kubectl должен быть настроен для подключения к вашему кластеру. Мы объясним это подробнее в разделе ниже.
Мы будем запускать несколько команд как локально, так и на узле Kubernetes. Давайте начнем!
Настройка локального kubectl для подключения к удаленному кластеру Kubernetes
Давайте начнем с установки kubectl. Наша локальная среда работает под управлением Ubuntu, перейдите по этой ссылке, если вы используете другую локальную среду. Чтобы установить инструменты kubectl в локальной среде Ubuntu/Debian с помощью пакетного менеджера apt, выполните следующие команды для обновления репозитория apt и установки необходимых пакетов:
|
1 2 |
sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl |
Затем выполните следующую команду, чтобы загрузить публичный ключ подписи Google Cloud:
|
1 |
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg |
Затем добавьте apt-репозиторий Kubernetes:
|
1 |
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list |
После этого обновите индекс apt и установите kubectl с помощью следующей команды:
|
1 2 |
sudo apt-get update sudo apt-get install -y kubectl |
Затем убедитесь, что kubectl установлен, проверив версию с помощью следующей команды:
|
1 |
kubectl version |
Вот вывод, если вы только что установили kubectl локально:

На скриншоте выше kubectl пытается подключиться к локальному кластеру Kubernetes. Однако это не удается, так как на нашей локальной машине еще не запущен кластер Kubernetes.
Чтобы подключиться к удаленному кластеру Kubernetes, сначала загрузите учетные данные Kubernetes с удаленного кластера. Вот команда для копирования учетных данных с управляющего узла (master node):
|
1 |
scp -r hackins@178.22.66.253:/home/hackins/.kube . |
Замените выделенные части вашим ssh именем пользователя и публичным IP-адресом управляющего узла. После завершения загрузки учетных данных скопируйте их в свой домашний каталог:
|
1 |
cp -r .kube $HOME/ |
Вот и все. Ваш локальный kubectl должен иметь возможность подключаться и отправлять команды на ваш удаленный кластер Kubernetes. Чтобы подтвердить, что ваш локальный kubectl подключен к удаленному кластеру, снова проверьте это с помощью команды version:
|
1 |
kubectl version --output='json' |
Вот вывод, показывающий успешное подключение:

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

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

В столбце IP показан внутренний IP-адрес отдельных подов. Если нужный вам под не отображается в списке, возможно, вы находитесь в другом пространстве имен. Вы можете выполнить следующую команду, чтобы вывести список подов во всех пространствах имен:
|
1 |
kubectl get pod -o wide --all-namespaces |
Получение IP-адреса службы (Service)
Вы также можете получить IP-адрес службы (Service) в вашем кластере. Добавив флаг --all-namespaces вы получите все службы, запущенные в кластере:
|
1 |
kubectl get service --all-namespaces |
Вывод вышеуказанной команды выглядит следующим образом. IP-адрес службы находится в столбце cluster-ip :

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

В выводе нас интересует столбец ID контейнера (container ID) или Names. Обратите внимание на контейнер Nginx, который мы развернули в предварительном руководстве Как установить и использовать Kubernetes на Ubuntu 20.04.
Затем скопируйте ID или имя контейнера, так как мы будем использовать его в следующей команде для поиска идентификатора процесса:
|
1 |
docker inspect --format '{{ .State.Pid }}' container-id-или-name |
Замените выделенную часть вашим значением, скопированным из предыдущей команды. Ниже приведен полученный нами вывод, который представляет собой идентификатор процесса:

Теперь, когда у нас есть идентификатор процесса, мы можем использовать его для запуска команды nsenter внутри сетевого пространства имен процесса:
|
1 |
sudo nsenter -t container-pid -n ip addr |
Замените выделенную часть идентификатором процесса, полученным в предыдущей команде. Затем вместо ip addr, вы можете подставить любую команду, которую хотите запустить внутри сетевого пространства имен пода. Вы также можете запустить ее с sudo, если получите ошибку отсутствия прав доступа (permission denied).
Команда nsenter позволяет запускать более широкий спектр команд, доступных на узле, в отличие от использования docker exec которая ограничивает вас только командами, установленными внутри контейнера.
Получение виртуального Ethernet-интерфейса пода
Сетевое пространство имен пода взаимодействует с корневым netns узла через виртуальный ethernet-канал (pipe). Со стороны узла этот канал выглядит как устройство, имя которого начинается с veth и заканчивается уникальным идентификатором, например veth742f721 или veth90. В то время как внутри пода этот канал идентифицируется как eth0.
Возможно, вы захотите узнать, какое устройство veth связано с конкретным подом. Вы можете начать с вывода списка всех сетевых устройств на узле, а затем вывести список всех устройств в сети пода. Чтобы определить, какое устройство veth связано с конкретным подом, вы можете сопоставить номера устройств между двумя списками.
Используйте команду nsenter, чтобы запустить команду ip addr в сетевом пространстве имен пода. Вам потребуется знать идентификатор процесса одного из контейнеров. Для этого обратитесь к предыдущему разделу Получение и доступ к сетевым пространствам имен подов.
Затем выполните следующую команду в терминале вашей рабочей ноды, заменив выделенную часть соответствующим образом:
|
1 |
sudo nsenter -t container-pid -n ip addr |
Команда выводит список интерфейсов пода:

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

В выводе 7-м интерфейсом является veth254b50e6@if3 – виртуальный ethernet-канал, связанный с подом, который мы тестируем.
Просмотр правил Iptables
Вы можете выполнить команду iptables-save для вывода списка всех iptables на ноде:
|
1 |
iptables-save |
Вывод команды может быть длинным, поэтому вы можете сохранить его в файл для последующего анализа:
|
1 |
iptables-save > iptables.txt |
Вы также можете использовать less для постраничного просмотра вывода:
|
1 |
iptables-save | less |
Поскольку нас интересуют только правила NAT Kubernetes, добавьте флаг -L для указания правильной цели:
|
1 |
sudo iptables -t nat -L KUBE-SERVICES |
Вот вывод:

Проверка сведений об IPVS
Kube-proxy — это сетевой прокси-сервер, работающий на каждой ноде в вашем кластере Kubernetes. Его можно использовать для настройки IPVS для трансляции виртуальных IP-адресов служб (Service IP) в IP-адреса подов. Чтобы вывести таблицу трансляции IP-адресов, вы можете использовать команду ipvsadm . Сначала вам нужно установить ее на вашей ноде:
|
1 |
sudo apt install ipvsadm |
Теперь вы можете выполнить следующую команду:
|
1 |
sudo ipvsadm -Ln |
Чтобы показать один IP-адрес службы, добавьте флаг -t , указав нужный IP-адрес:
|
1 |
ipvsadm -Ln -t 10.244.1.255 |
Запросы к DNS кластера
Есть несколько способов отладки разрешения имен DNS в кластере. Официальная документация описывает один из способов: развертывание отладочного контейнера со всеми необходимыми инструментами и последующее использование kubectl для выполнения nslookup.
Кроме того, вы можете отправить запрос к DNS с помощью команд dig и nsenter непосредственно с самой ноды. Сначала вам нужно будет установить dig на вашей мастер-ноде. Для Ubuntu установите ее с помощью команды apt :
|
1 |
sudo apt install dnsutils |

Вернитесь в терминал на локальном компьютере и выполните команду ниже, чтобы найти кластерный IP-адрес службы kube-dns :
|
1 |
kubectl get service -n kube-system kube-dns |
Команда выводит:

Столбец cluster-ip содержит нужное нам значение. Теперь мы можем использовать nsenter для запуска dig в пространстве имен контейнера. Однако для доступа к пространству имен контейнера вам понадобится идентификатор его процесса (PID). Инструкции см. в разделе Getting and Accessing Pod Network Namespaces выше.
Как только у вас будет container-id, выполните следующую команду на вашей мастер-ноде:
|
1 |
sudo nsenter -t 27168 -n dig kubernetes.default.svc.cluster.local @10.96.0.10 |
Команда dig принимает IP-адрес службы DNS кластера ( @10.96.0.10) и ищет полное доменное имя службы service-name.namespace.svc.cluster.local:

Для получения информации о поиске имен служб и пространств имен обратитесь к разделу Getting the IP address of a Service.
Просмотр отслеживания соединений Conntrack
Вы можете использовать команду conntrack для просмотра всех отслеживаемых в данный момент соединений:
|
1 |
sudo conntrack -L |
Вывод выглядит примерно так, как на скриншоте:

Добавьте флаг -E для непрерывного наблюдения за входящими соединениями:
|
1 |
sudo conntrack -E |
Чтобы просмотреть соединения, отслеживаемые для определенного адреса назначения, добавьте флаг -d и укажите адрес назначения:
|
1 |
sudo conntrack -L -d 80.45.6.4 |
Иногда таблица отслеживания соединений переполняется, в результате чего новые соединения сбрасываются. Это приводит к проблемам, мешающим вашим узлам устанавливать надежные соединения. Если это произойдет, вы увидите в системных журналах сообщения, подобные следующим, по пути /var/log/syslog:
|
1 |
Mar 07 19:12:11 worker-105 kernel: nf_conntrack: таблица заполнена, сброс пакет. |
Существует системная настройка для максимального количества отслеживаемых соединений. Используйте следующую команду, чтобы вывести текущее значение:
|
1 |
sysctl net.netfilter.nf_conntrack_max |
Вывод:

Вы можете изменить значение с помощью -w флага:
|
1 |
sudo sysctl -w net.netfilter.nf_conntrack_max=231074 |
Возможно, вы захотите изменить свой /etc/sysctl.conf файл, чтобы сделать это значение постоянным и сохранить его после перезагрузки. Откройте файл с помощью nano:
|
1 |
sudo nano /etc/sysctl.conf |
Затем измените значение, если эта строка существует, или добавьте строку в конец файла, указав новое значение:
|
1 |
net.netfilter.nf_conntrack_max=231074 |
Заключение
При развертывании нескольких контейнеризированных служб вы получите огромную выгоду от использования Kubernetes, поскольку он предоставляет централизованную точку управления. Чтобы обеспечить связь между различными подами Kubernetes, мы показали вам несколько команд проверки сети, которые можно использовать для устранения любых неполадок в инфраструктуре Kubernetes.
Чтобы узнать больше о Kubernetes, его преимуществах, настройке и развертывании приложений в Kubernetes, ознакомьтесь с нашими различными руководствами по Kubernetes.
Приятной работы!
Комментарии
Комментариев пока нет. Будьте первым.