Оглавление:
Сетевая связность и пропускная способность
CNI и CRI
DNS, L4/L7
Захват трафика
Сетевая связность и пропускная способность
Кубернетес использует стандартное сетевое оборудование и примитивы ОС Linux в качестве фундамента для построения различных типов SND (Software-defined networking). Способы отладки сетей в Кубернетес, принципиально не отличается, от привычных методов.
iperf
https://iperf.fr
iperf – это хорошо известный для сетевых инженеров и системных администраторов инструмент,
предназначенный для тестирования сетевого оборудования пропускной способности сетевых каналов.
Также как и обычными хостами Linux, его можно использовать для тестирования сетей в кластере Кубернетес.
Для того, чтобы развернуть iperf в Кубернетес необходимо создать манифест развертывания использующий нужный образ:
apiVersion: apps/v1
kind: Deployment
metadata:
name: iperf3-deployment
spec:
replicas: 3
selector:
matchLabels:
app: iperf3
template:
metadata:
labels:
app: iperf3
spec:
containers:
- name: iperf3
image: leodotcloud/swiss-army-knife
ports:
- containerPort: 5201
Для того, чтобы развернуть созданный манифест в кластере:
kubectl apply -f iperf3-deployment.yaml
Планируемый результат:
~$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
iperf3-deployment-64c767596d-9r4jm 1/1 Running 0 3h36m 10.244.0.13 minikube <none> <none>
iperf3-deployment-64c767596d-jgqx9 1/1 Running 0 3h36m 10.244.0.14 minikube <none> <none>
iperf3-deployment-64c767596d-l5tg8 1/1 Running 0 3h36m 10.244.0.15 minikube <none> <none>
Сначала нужно запустить iperf в одном из подов, в режиме сервера:
kubectl exec -it <pod-name> -- iperf3 -s -p 12345
В данном случае необходимо поменять [pod-name] на имя одного из подов в развертывании:
kubectl exec -it [pod-name] -- iperf3 -s -p 12345
Планируемый результат:
~$ kubectl exec -it pod/iperf3-deployment-64c767596d-l5tg8 -- iperf3 -s -p 12345
-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------
В другой сессии терминала нужно запустить Iperf в режиме клиента, и подключится из этого пода к серверу:
~$ kubectl exec -it iperf3-deployment-64c767596d-9r4jm -- iperf3 -c 10.244.0.15 -p 12345
Connecting to host 10.244.0.15, port 12345
[ 4] local 10.244.0.13 port 43842 connected to 10.244.0.15 port 12345
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 2.78 GBytes 23.9 Gbits/sec 1296506932 0.00 Bytes
[ 4] 1.00-2.00 sec 2.56 GBytes 22.0 Gbits/sec 0 0.00 Bytes
[ 4] 2.00-3.00 sec 3.02 GBytes 25.9 Gbits/sec 0 0.00 Bytes
[ 4] 3.00-4.00 sec 3.17 GBytes 27.2 Gbits/sec 0 0.00 Bytes
[ 4] 4.00-5.00 sec 2.91 GBytes 25.0 Gbits/sec 0 0.00 Bytes
[ 4] 5.00-6.00 sec 2.76 GBytes 23.7 Gbits/sec 0 0.00 Bytes
[ 4] 6.00-7.00 sec 2.47 GBytes 21.2 Gbits/sec 0 0.00 Bytes
[ 4] 7.00-8.00 sec 2.43 GBytes 20.9 Gbits/sec 0 0.00 Bytes
[ 4] 8.00-9.00 sec 2.43 GBytes 20.9 Gbits/sec 0 0.00 Bytes
[ 4] 9.00-10.00 sec 2.82 GBytes 24.2 Gbits/sec 2998460368 0.00 Bytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 27.3 GBytes 23.5 Gbits/sec 4 sender
[ 4] 0.00-10.00 sec 27.3 GBytes 23.5 Gbits/sec receiver
Основное предназначение iperf - это анализ пропускной способности сети: между географически удаленными узлами в одном кластере Кубернетес
или между хостом внутри кластера и машиной которая находится за его пределами.
Iperf может тестировать не только TCP но и UDP:
~$ kubectl exec -it iperf3-deployment-64c767596d-9r4jm -- iperf3 -c 10.244.0.15 -u -p 12345
Connecting to host 10.244.0.15, port 12345
warning: Unable to set socket pacing, using application pacing instead
[ 4] local 10.244.0.13 port 51612 connected to 10.244.0.15 port 12345
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 120 KBytes 983 Kbits/sec 15
[ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 16
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.24 MBytes 1.04 Mbits/sec 0.207 ms 0/159 (0%)
[ 4] Sent 159 datagrams
В случаи если при тестировании наблюдаются потери пакетов, то это может говорить о:
Неисправности "железа" (CRC ошибки NIC проблемы с коммутаторами)
Не правильно настроенный межсетевой экран
Не правильно настроенный протокол (например MTU)
Link congestion
CNI и CRI
Кубернетес построен на принципах UNIX: Делайте что-то одно, но делайте это хорошо. Каждый компонент Кубернетес – это отдельная программа, которая выполняет определенный набор операций и не имеет жесткой привязки (decoupling) к другим компонентам.
CRI
Кубернетес занимается оркестрацией контейнеров, но за работу непостредственно связаной с запуском и остановкой контейнеров на узлах кластера отвечает другой компонент – CRI (Container Runtime Interface). CRI использует примитивы Linux (cgroups и пространства имен) для работы с образами контейнеров. Kubelet – это компонент Кубернтес, который управляет Container Runtime.
Для того, чтобы быстро посмотреть какие с какими параметрами был запущен сервис kubelet можно использовать команду strings /proc/$(pgrep kubelet)/cmdline:
$ strings /proc/$(pgrep kubelet)/cmdline
/usr/bin/kubelet
--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf
--config=/var/lib/kubelet/config.yaml
--container-runtime=remote
--container-runtime-endpoint=/run/containerd/containerd.sock
--node-ip=192.168.61.11
--pod-infra-container-image=k8s.gcr.io/pause:3.4.1
Для отладки проблем связанных с сетевым доступом на узлах Кубернетес, можно использовать бинарные файлы CRI (Container Runtime Interface).
crio:
https://github.com/cri-o/cri-o/blob/main/docs/crio.8.md
$ crictl pull docker.io/library/busybox:latest
containerd:
https://github.com/projectatomic/containerd/blob/master/docs/cli.md
$ ctr images pull docker.io/library/busybox:latest
crictl inspect выводит информацию о контейнере в формате JSON. Можно использовать утилиту jq для того, чтобы отфильтровать PID:
crictl ps
crictl inspect $CONTAINER_ID
PID=$(crictl inspect $CONTAINER_ID | jq '.info.pid')
ps -ef | grep $PID | grep -v grep
CNI
У CNI плагина есть две главные обязанности: аллоцировать и назаначять уникальные IP адреса для Подов и добавлять маршруты в кластере Кубернетес для каждого IP адреса Пода.
Это означает, что сеть в которой находится узлы кластера, диктует поведение CNI плагина. Существует два категории в сетевой модели CNI: flat networks и overlay networks. flat networks использует IP из сети кластера, для чего обычно требуется большое количество свободных адресов. В сетях overlay, драйвер CNI создает свою сеть в Кубернетес, и затем использует кластерную сеть (которая называется ]underlay network]) для передачи пакетов.
Пример вывода команды ip route на узле кластера использующего CNI плагин Calico:
$ ip route
default via 10.6.16.1 dev eth0
10.6.16.0/21 dev eth0 proto kernel scope link src 10.6.22.111
111.97.95.0/26 via 10.6.145.224 dev tunl0 proto bird onlink
111.98.108.64/26 via 10.6.144.128 dev tunl0 proto bird onlink
111.98.163.0/26 via 10.6.147.100 dev tunl0 proto bird onlink
111.101.172.128/26 via 10.6.86.141 dev tunl0 proto bird onlink
111.103.57.192/26 via 10.6.17.44 dev eth0 proto bird
111.103.80.128/26 via 10.6.85.178 dev tunl0 proto bird onlink
111.105.231.0/26 via 10.6.23.120 dev eth0 proto bird
111.115.208.128/26 via 10.6.80.11 dev tunl0 proto bird onlink
blackhole 111.126.117.128/26 proto bird
111.126.117.129 dev cali8934275ty scope link
111.126.117.132 dev cali983hfsdf4 scope link
111.126.117.140 dev cali443gfby45 scope link
kubelet подключает Поды к CNI. Сетевой трафик CNI предстваляет из себя стандартный TCP/IP (здесь могут быть особенности реализации конкертного плагина CNI). Шифрованием трафика занимается CNI, приложение или service mesh. Если трафик передается в незашифрованном виде, то его можно прослушивать из скомпрометированного Пода или непостредственно на узле Кубернетес.
По-умолчанию kubelet читает конифиг CNI из директории /etc/cni/net.d/ и ожидает найти бинарный файл CNI в директории /opt/cni/bin/.
Эти параметры может использовать в командной строки с помощью фалгов --cni-config-dir=[directory] и --cni-bin-dir=[directory].
Cilium
Cilium - это одна из реализаций CNI. Это первый плагин использующий Berkeley Packet Filter (eBPF). Это означает, что обработка сетевых пакетов происходит в ядре (Linux kernel space). При использовании вместе с технологией Xpress Data Path (XDP), это позволяет маршрутизировать трафик сразу после передачи сетевых пакетов. Cilium имеет ряд преимуществ по сравнению с другими плагинами. При этом выбор CNI это одно из ключевых решений, которое должно приниматься на этапе планирования кластера администраторами, сетевыми инженерами и разработчиками.
NetworkPolicy
По-умолчанию Кубернетес открывает доступ для любого трафика между Подами в кластерной сети.
NetworkPolicy Это ресурс Кубернетес, который позволяет настраивать правила доступа аналогичные правилам для межсетевого экрана.
Ресурсы NetworkPolicy используется используются для конфигурации плагинов CNI – это компонент который отвечает за сетевую связность между Подами.
Iptables
Большинство имплементаций CNI используют kube-proxy и iptables для фильтрации сетевых пакетов. Исключением является Cilium и другие плагины использующие eBPF.
Некоторые компоненты Кубернетес (kube-proxy) создают правила iptables для выполнения определенных операций. Пример таких правил можно увидеть, выполнив команду на узле в кластере Кубернетес:
$ sudo iptables -t nat -L KUBE-SERVICES
Эти правила предназначены для внутреннего использования в Кубернетес. Они создаются автоматически и не предназначены для редактирования пользователями.
DNS, L4/L7
По-умолчанию Кубернетес автоматически настраивает DNS сервис, который используется для обнаружения сервисов в кластере. Кубернетес это динамическая инфраструктура: Поды и контейнеры создаются, удаляются и перемещаются между узлами кластера в автоматическом режиме. Встроенное обнаружение сервисов необходимо для коммуникации между приложениями в условиях динамической инфраструктуры: кубернетес постоянно создает, удаляет и перемещает Поды и контейнеры между узлами кластера в автоматическом режиме.
CoreDNS
https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution
Кубернетес использует CoreDNS в качестве внутрикластерного DNS сервера для Подов.
CoreDNS отслеживает состояние ресурсов API Сервера. Для каждого Сервиса Кубернетес CoreDNS создает запись следующего формата: [service-name].[namespace-name].svc.cluster.local.
К примеру Сервис, который называется nginx в пространстве имен default, получит запись - nginx.default.svc.cluster.local.
Во время выполнения процедуры запуска Подов, kubelet сохраняет в контейнере файл /etc/resolv.conf. Если изучить содержимое этого файла, то в качестве nameserver там будет указан CoreDNS. Каждый раз когда Под запрашивает Сервис Кубернетес по имени - этот запрос отправляется в CoreDNS:
cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
Сервис kube-dns подключается к развертыванию (Deployment) CoreDNS:
kubectl -n kube-system get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 2d3h
Сервис kube-dns не имеет отношения к легковесной реализации DNS сервера, которая устанавливалась по-умолчанию в предыдущих версиях Кубернетес. Сервис kube-dns является частью CoreDNS и устанавливается на этапе установки кластера.
CoreDNS настраивается с помощью плагинов.
CoreDNS использует так называемый Corefile для того, чтобы конфигурировать поведение DNS сервера.
Конфиг CoreDNS нужно читать сверху вниз - каждая новая строчка это один из используемых плагинов.
Для того, чтобы изучить конфигурацию CoreDNS можно воспользоваться следующей командой:
kubectl get configmaps coredns -n kube-system -o yaml
dnstools
Для отладки сетей в Кубернетес, зачастую не хватает привычных для сетевых инженеров и системных администраторов инструментов: dig, nslookup, curl, ping, nc и так далее. Для того, чтобы получить доступ к этим необходимым инструментам, можно собрать служебный образ контейнера с набором предустановленных программ, или использовать один из существующих публично доступных образов Docker, например - dnstools:
dnstools.yaml:
apiVersion: v1
kind: Pod
metadata:
name: dnstools
spec:
containers:
- name: dnstools
image: infoblox/dnstools
command: ['sh', '-c', 'while true; do sleep 1; done']
Для того, чтобы развернуть созданный манифест в кластере:
kubectl apply -f dnstools.yaml
Планируемый результат:
kubectl get pods dnstools
NAME READY STATUS RESTARTS AGE
dnsutils 1/1 Running 0 36s
С помощью dnstools можно проверить L4\L7 соединение между Подами, порты и доступ в Интернет из кластера:
~$ kubectl exec -i -t dnstools -- nc -z -vv 10.244.0.6 80
nc: 10.244.0.6 (10.244.0.6:80): Connection refused
sent 0, rcvd 0
command terminated with exit code 1
~$ kubectl exec -i -t dnstools -- nc -z -vv 10.244.0.6 8080
10.244.0.6 (10.244.0.6:8080) open
sent 0, rcvd 0
~$ kubectl exec -i -t dnstools -- ping google.com -c 4
PING google.com (64.233.165.100): 56 data bytes
64 bytes from 64.233.165.100: seq=0 ttl=36 time=200.956 ms
64 bytes from 64.233.165.100: seq=1 ttl=36 time=18.517 ms
64 bytes from 64.233.165.100: seq=2 ttl=36 time=31.825 ms
64 bytes from 64.233.165.100: seq=3 ttl=36 time=16.783 ms
layer 7 HTTP API:
~$ kubectl exec -i -t dnstools -- wget -qO- 10.244.0.6:8080
Hello, world!
Проверить разрешение доменных имен в кластере:
$ kubectl exec -i -t dnstools -- nslookup kubernetes.default
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: kubernetes.default.svc.cluster.local
Address: 10.96.0.1
$ kubectl exec -i -t dnstools -- dig hello-world.default.svc.cluster.example.com
Для того, чтобы быстро получить доступ к контейнеру с dnstools:
kubectl run --restart=Never -it --image infoblox/dnstools dnstools dnstools#
Сделать снимок сетевого трафика DNS (UDP 53) в контейнере dnstools:
kubectl exec -it dnstools sh
dnstools# tcpdump -ni eth0 udp and port 53
В случае проблем с DNS в кластере Кубернетес, сначала следует проверить содержимое /etc/resolv.conf:
dnstools# cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
https://linux.die.net/man/5/resolv.conf
Захват трафика
Wireshark и tcpdump – являются де-факто стандартными инструментами в арсенале сетевого инженера и хотя контейнеры значительно меняют подход к проектированию и отладки сетей, эти две не заменимые программы можно использовать для анализа сетевого трафика в Кубернетес.
ksniff
https://github.com/eldadru/ksniff
ksniff - это плагин kubectl, который использует tcpdump для захвата сетевого трафика.
Трафик в формате PCAP можно затем импортировать в Wireshark для последующего анализа.
Для установки ksniff лучше использовать krew - менеджер плагинов для kubectl:
kubectl krew install sniff
Инструкции по установке krew для разных ОС:
https://krew.sigs.k8s.io/docs/user-guide/setup/install
Ksniff устанавливается на пользовательской машине с настроенным kubectl.
При запуске ksniff использует эфемерный контейнер с tcpdump для подключения к нужному Поду. Для работы с PCAP файлами, на машине должен быть установлен Wireshark.
Интерфейс кsniff достаточно прост:
kubectl sniff <POD_NAME> [-n <NAMESPACE_NAME>] [-c <CONTAINER_NAME>] [-i <INTERFACE_NAME>] [-f <CAPTURE_FILTER>] [-o OUTPUT_FILE] [-l LOCAL_TCPDUMP_FILE] [-r REMOTE_TCPDUMP_FILE]
Следующая команда сохранит перехваченные tcpdump сететвые пакеты в файл out.pcap:
kubectl sniff -n <NAMESPACE> <POD_NAME> -p -f "port 80" -o out.pcap
В данном случае мы отправляем tcpdump инструкции - отслеживать только запросы POST протокола HTTP на порту 8080:
kubectl sniff -p <POD_NAME> -n <NAMESPACE> -f 'tcp dst port 8080 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)' -o - | tshark -r -
С помощью флагов --image и --tcpdump-image можно указывать кастомизированные образы Docker. Эта функция может быть использована для работы в закрытом контуре.
Kubeshark
https://docs.kubeshark.co
Инструкции по установке:
https://docs.kubeshark.co/en/install
Это развитие идей, которые были апробированы в ksniff. Принцип работы похож на ksniff – для захвата трафика используется контейнер с tcpdump.
Кроме этого Kubeshark добавляет графический веб-интерфейс и ряд возможностей, которые доступены лишь в системах для анализа трафика класса enterprise.
kubeshark позволяет:
добавлять кастомизированные пользовательские функции и триггеры написанные на Javascript. Это необходимо для отслеживания и реагирования на инциденты и подозрительное поведение в сети Кубернетес.
cохранять снимок сетевого трафика в формате PCAP для последующего импорта в Wireshark.
С kubeshark можно в режиме реального времени отслеживать перемещение трафика (REST, gRPC, Kafka, AMQP и Redis) в кластере,
и визуализировать связи между Сервисами Кубернетес - https://docs.kubeshark.co/en/service_map
