Вступление
А у вас есть Kubernetes?
Есть множество путей развернуть свой Kubernetes. Все они разные, выбор зависит от вашего бюджета, от того, какие задачи вы планируете решать, для каких нагрузок и что в конечном итоге вы планируете получить. В этой статье мы быстро пройдёмся по различным способам инсталляции, а затем попробуем развернуть свой K8s кластер на виртуальных машинах, воспользовавшись гипервизором второго типа (VirtualBox). Но это будет не условная Ubuntu, на которую мы будем ставить необходимые компоненты, а целая операционная система, разработанная специально для Kubernetes - Talos Linux!
Оглавление
Раскрыть оглавление
Почему я решил написать об этом статью
Последние полтора года я занимаю позицию DevOps инженера и активно взаимодействую с Kubernetes. Но весь мой коммерческий опыт с этим инструментов ограничивается облачными Managed-решениями. Конечно, когда я впервые "щупал" K8s, я начинал с minikube, затем уже "боевой" кластер Yandex Managed Service for Kubernetes. Для собственных инсталляции на личный ноутбук/ВМ я перестал использовать minikube, найдя ему отличную замену: k3s, который ставится одной командой, а затем легко превращается в кластер с несколькими рабочими узлами. Но это сложно назвать Production-ready, так как при первой же серьезной нагрузке начнутся проблемы. И тут мне стало интересно: а что же на самом деле используют для установки Kubernetes на своих серверах?
Способы инсталяции K8s
K8s дистрибутивы для тестов: minikube, k3s, etc
Для первого ознакомления не обязательно прибегать к использованию облачных решений или установке полноценного кластера. Для этого хватит minikube или k3s. Я советую ставить второй - он весит менее 70 мегабайт и сразу готов к использованию.
Установим k3s:
$ curl -sfL https://get.k3s.io | sh
$ sudo k3s kubectl get node
NAME STATUS ROLES AGE VERSION
azamat-lenovo Ready control-plane,master 67s v1.29.6+k3s1
Текущее устройство выполняет роль мастер и воркера узла.
Облачные managed решения
Самый лёгкий способ установить кубер, чтобы сразу начать его использовать для рабочих нагрузок - воспользоваться услугами облака. Поддержка такого кластера будет осуществлятся специалистами облака. Поднятие такого кластера происходит по нажатию кнопки на мощностях провайдера. Немного ожидания и ваш Kubernetes готов! Чаще всего у вас может не оказаться прямого доступа к мастер или рабочим узлам (например, Yandex.Cloud позволяет заходить по SSH на воркеры, на мастеры - нет). Одним из главных преимуществ такого развертывания, помимо поддержки со стороны облачного провайдера, является возможность размещения узлов в разных датацентрах облака, что позволит сделать кластер отказоустойчивим, а также автоматическое масштабирование при больших нагрузках.
Но с другой стороны, мы доверяем облаку наши рабочие нагрузки и данные, разворачивая приложения в его контуре, дополнительно завязываясь на особенности конкретного облачного провайдера. Стоимость аренды может составлять внушительную сумму, так как в неё, помимо самих мощностей, входит, например, оплата специалистов.
Возьмем Yandex Managed Service for Kubernetes. Стомость регионального (три мастера в разных ДЦ) кластера с трёмя рабочими узлами со следющей конфигурацией будет 41 973,12 ₽ в месяц:
Платформы с технической поддержкой (OpenShift, Deckhouse)
Если вы хотите развернуть кластер Kubernetes в своём контуре, и при этом иметь те же самые преимущества, как при использовании облаков, то вы можете воспользоваться платформами от компании RedHat (OpenShift) или Флант (Deckhouse). Они предоставляют поддержку своим клиентам, а также берут на себя часть работ по обеспечению мониторинга и сбора логов, сетевого доступа (Ingress-контроллеры и балансировщики нагрузки), системе аутентификации и прочему.
Преимуществом является то, что для инсталяции подобной платформы подойдет любая инфрасруктура: Bare-metal, собственные виртуальные машины или облако. Но не забывайте про оплату: такие платформы являются коммерческими продуктами.
kubeadm/kubespray
Самый классический способ развернуть компоненты кластера на линукс серверах - утилиты kubeadm или kubespray. Автор статьи не сталкивался с подобными инструментами, но наслышан про выбор в пользу первого. Для ознакомления советую воспользоваться документацией.
Kubernetes The Hard Way
Если вы ищете приключений, то этот способ установки для вас!
Talos Linux
И тут мы подходим к тому, чему посвещена дальнейшая часть статьи. Впервые про Talos я услышал в Telegram сообществе Kubernetes. На вопросы "что лучше использовать для собственного куба" я чаще всего видел ответ "talos.dev"
Но что же это за монстр? Talos Linux - это операционная система, которая была специально разработана для запуска Kubernetes. В её основе лежит Linux, но он и близко не стоит к стандартным дистрибутивам по типу Ubuntu или CentOS. Дело в том, что Talos был разработан с целью сделать кластер "безопасным, иммутабельным и минималистичным". Если верить разработчикам, то их операционная система содержит всего 12 бинарных файлов, тогда как одни из самых популярных Linux дистрибутивов в 100 раз больше!
Наглядный пример на бобах
Как вы обычно управляете сервером? Наверное у вас установлен openssh-server, вы настраиваете пару ключей, а затем входите в командую оболочку. Забудьте! Всё взаимодействие с Talos Linux происходит через API, никакого SSH. Всё ради безопасности.
Подробнее про преимущества и особенности Talos вы можете прочитать в англоязычной документации или в русскоязычной статье в блоге от компании Флант. А мы приступаем к практике!
Kubernetes кластер при помощи Talos Linux
Подготовка перед запуском
Ознакомиться с конфигурацией можно в GitHub-репозиторий.
Манифесты, которые находятся в директорий config только для просмотра, не используйте их при настройке своего кластера!
Устанавливаем iso-образ
Talos можно установить несколькими путями: на различные bare-metal платформы, посредством гипервизора, в облаке или Docker. В этой статье я буду использовать VirtualBox, поэтому необходимо установить iso-образ Talos Linux.
Установить ОС можно с GitHub. Если вам нужны специфичные настройки ядра или системные дополнения, то можно воспользоваться Image Factory.
Итак, установим актуальную на момент написания статьи версию Talos Linux:
wget https://github.com/siderolabs/talos/releases/download/v1.7.5/metal-amd64.isoЗапускаем виртуальную машину с необходимыми настройками
Заходим в VirtualBox и создаём три виртуальные машины (один Control Plane и два Worker Node). Выбираем для всех ранее установленный образ:
Назначим ресурсы в соответсвии с минимальными системными требованиями:
В VirtualBox:
Это не всё!
Теперь перейдем в Settings -> Network и сменим "Attached to" с NAT на Bridge Adapter. Выберите название вашего сетевого интерфейса. Это важная настройка, так как в ином случае мы не сможем обращаться к API Talos'а:
Таким образом, мы подготовили Talos Linux для запуска. Далее рассмотрим его запуск и конфигурацию.
Control Plane
Запуск
Стартуем! Выбираем Talos ISO:
Теперь ждём....
Через какое-то время у вас должен появиться экран со следующим содержимым. Обратите внимание: IP должен быть указан, а значение Stage должно быть Maintenance:
Теперь мы можем приступить к настройке главного узла нашего Kubernetes кластера!
talosctl
Помимо iso-образа нам также понадобится утилита talosctl. С помощью неё происходит всё взаимодействие с Talos Linux. Устанавливаем:
$ curl -sL https://talos.dev/install | shИдём дальше.
Генерируем конфигурацию кластера
Для начала запишем в переменную окружения IP-адрес ранее запущенной виртуальной машины:
export TALOS_CONTROL_PLANE_IP=192.168.77.143Теперь сгенерируем конфигурацию. Необходимо указать произвольное название кластера и путь до узла:
$ talosctl gen config habr-demo https://$TALOS_CONTROL_PLANE_IP:6443
generating PKI and tokens
Created /home/azamat/devops/terralink/talos-demo/controlplane.yaml
Created /home/azamat/devops/terralink/talos-demo/worker.yaml
Created /home/azamat/devops/terralink/talos-demo/talosconfigВ текущей директорий должны появиться YAML файлы с конфигурацией главного и рабочих узлов, а также talosconfig, который необходим для подключения к API Talos'а.
Обратите внимание на machine.install.disk поле в controlplane.yaml и worker.yaml. По-умолчанию значение этого поля равно /dev/sda, оно указывает какой раздел использовать для установки системы. Если вы планируете использовать другой диск, то измените это значение.
Применяем конфигурацию
Применим ранее созданный controlplane.yaml:
$ talosctl apply-config --insecure -n $TALOS_CONTROL_PLANE_IP --file ./controlplane.yamlВернёмся в панель с Talos. Значение стадии должно поменяться на Installing:
Спустя некоторое время должна произойти перезагрузка. После этого стадия станет равна Booting:
Осталась одна команда, чтобы Control Plane стал запущенным: talosctl bootstrap!
Bootstraping
Теперь необходимо выполнитьtalosctl bootstrap. Данная команда выполняется один раз для каждого из главных узлов. На этом этапе происходит запуск компонентов Control Plane. Тут нам впервые понадобится передать talosconfig:
$ talosctl bootstrap --nodes $TALOS_CONTROL_PLANE_IP --endpoints $TALOS_CONTROL_PLANE_IP --talosconfig=./talosconfigЗначение Stage в очередной раз должно смениться на Running. Дождёмся готовности узла (поле Ready):
Всё замечательно!
Получаем kubeconfig
Теперь мы можем получить привычный для всех Kubernetes конфиг:
$ talosctl kubeconfig kubeconf --nodes $TALOS_CONTROL_PLANE_IP --endpoints $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfigТеперь передадим полученный конфигурационный файл в утилиту kubectl. Получим список всех узлов:
$ kubectl --kubeconfig ./kubeconf get nodes
NAME STATUS ROLES AGE VERSION
talos-npa-q79 Ready control-plane 23m v1.30.1У нас появился первый узел! Так как он является главным, мы не можем запускать на нём рабочие нагрузки. В любом случае попробуем:
$ kubectl --kubeconfig ./kubeconf run nginx-deployment --image=nginx:1.27-alpine
pod/nginx-deployment created
$ kubectl --kubeconfig ./kubeconf describe pods
[...]
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 31s default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.Вы можете использовать один Talos инстанс сразу как главный и рабочий узел. Подробнее читайте тут.
Но мы не будем пользоваться данной возможностью и развернем дополнительно два рабочих узла.
Worker nodes
Все необходимые конфиги у нас уже есть, поэтому давайте снова запустим Talos Linux, но теперь в качестве рабочих узлов.
Конфигурируем ВМ в VirtualBox для рабочих узлов
Воспользуемся таблицой с минимальными требованиями, но теперь для рабочих узлов. Укажем те же самые настройки в VirtualBox, единственное уменьшив количество CPU и оперативной памяти:
Конфигурация виртуальной машины для рабочих узлов кластера
Не забудем указать сетевые настройки по аналогии с мастер узлом.
Запишем IP-адрес рабочего узла в переменную окружения:
$ export TALOS_WORKER_1_IP=192.168.1.243Применяем Talos конфигурацию
Теперь применим конфигурацию Talos для рабочего узла:
$ talosctl apply-config --insecure -n $TALOS_WORKER_1_IP --file worker.yamlВыполним те же самые операции для второго рабочего узла. Когда один из рабочих узлов перейдёт в статус Ready, начнётся запуск пода с nginx. Посмотрим на список узлов и подов:
$ kubectl --kubeconfig ./kubeconf get nodes
NAME STATUS ROLES AGE VERSION
talos-5i8-gt4 Ready <none> 12m v1.30.1
talos-gph-5c3 Ready control-plane 29m v1.30.1
talos-uw0-8ez Ready <none> 87s v1.30.1
$ kubectl --kubeconfig ./kubeconf get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment 1/1 Running 0 11mЗапускаем Deployment и открываем к нему доступ
Давайте удалим под и попробуем запустить Deployment с несколькими репликами. Затем откроем к ним доступ через NodePort Service:
$ kubectl --kubeconfig ./kubeconf delete pods/nginx-deployment
pod "nginx-deployment" deleted
$ kubectl --kubeconfig ./kubeconf apply -f https://raw.githubusercontent.com/AzamatKomaev/talos-demo-habr/main/k8s/deploy.yaml
deployment.apps/nginx-deployment created
$ kubectl --kubeconfig ./kubeconf apply -f https://raw.githubusercontent.com/AzamatKomaev/talos-demo-habr/main/k8s/nodeport.yaml
service/nginx-service createdУбедимся, что все поды запущены, а также распределены между рабочими узлами:
$ kubectl --kubeconfig ./kubeconf get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-855cf47bc-2dnjz 1/1 Running 0 10m 10.244.2.2 talos-uw0-8ez <none> <none>
nginx-deployment-855cf47bc-69xqh 1/1 Running 0 10m 10.244.1.4 talos-5i8-gt4 <none> <none>
nginx-deployment-855cf47bc-nbncf 1/1 Running 0 10m 10.244.2.3 talos-uw0-8ez <none> <none>NodePort должен открыть 30000 порт на каждом рабочем узле. Попробуем достучаться до Nginx:
$ curl -s http://$TALOS_WORKER_1_IP:30000 | grep nginx | head -n 2
<title>Welcome to nginx!</title>
<h1>Welcome to nginx!</h1>
$ curl -s http://$TALOS_WORKER_2_IP:30000 | grep nginx | head -n 2
<title>Welcome to nginx!</title>
<h1>Welcome to nginx!</h1>CLI
Если у нас нет прямого доступа к операционной системе, на которой запускаются компоненты Kubernetes, то как в таком случае отслеживать состояние кластера и его компонентов? talosctl!
Dashboard
Например, мы можем открыть уже знакомый нам дашборд через talosctl dashboard:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig dashboardВывод
Список всех сервисов
Получим список всех сервисов, запускаемых на узлах:
$ talosctl -n $TALOS_CONTROL_PLANE_IP,$TALOS_WORKER_1_IP -e $TALOS_CONTROL_PLANE_IP,$TALOS_WORKER_1_IP --talosconfig ./talosconfig service
NODE SERVICE STATE HEALTH LAST CHANGE LAST EVENT
192.168.1.243 apid Running OK 54m16s ago Health check successful
192.168.1.243 containerd Running OK 54m54s ago Health check successful
192.168.1.243 cri Running OK 54m20s ago Health check successful
192.168.1.243 dashboard Running ? 54m53s ago Process Process(["/sbin/dashboard"]) started with PID 1769
192.168.1.243 kubelet Running OK 54m16s ago Health check successful
192.168.1.243 machined Running OK 54m59s ago Health check successful
192.168.1.243 syslogd Running OK 54m58s ago Health check successful
192.168.1.243 udevd Running OK 54m58s ago Health check successful
192.168.1.139 apid Running OK 56m50s ago Health check successful
192.168.1.139 containerd Running OK 56m54s ago Health check successful
192.168.1.139 cri Running OK 56m52s ago Health check successful
192.168.1.139 dashboard Running ? 56m52s ago Process Process(["/sbin/dashboard"]) started with PID 1802
192.168.1.139 etcd Running OK 56m46s ago Health check successful
192.168.1.139 kubelet Running OK 56m49s ago Health check successful
192.168.1.139 machined Running OK 56m59s ago Health check successful
192.168.1.139 syslogd Running OK 56m58s ago Health check successful
192.168.1.139 trustd Running OK 56m52s ago Health check successful
192.168.1.139 udevd Running OK 56m57s ago Health check successfulСтатус ETCD
Посмотрим на статус etcd посредством talosctl etcd status. ETCD является базой данных ключ-значение, который является одним из главных компонентов Control Plane и отвечает за хранение конфигурации всего кластера:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig etcd status
NODE MEMBER DB SIZE IN USE LEADER RAFT INDEX RAFT TERM RAFT APPLIED INDEX LEARNER ERRORS
192.168.1.139 5cde1d32b0847247 2.1 MB 1.3 MB (63.53%) 5cde1d32b0847247 9339 2 9338 false Как видно из вывода у нас всё в порядке.
Информция о дисках
Теперь получим информацию об используемых дисках:
$ export ENDPOINTS=$TALOS_CONTROL_PLANE_IP,$TALOS_WORKER_1_IP,$TALOS_WORKER_2_IP
$ talosctl -n $ENDPOINTS -e $ENDPOINTS --talosconfig ./talosconfig disks
NODE DEV MODEL SERIAL TYPE UUID WWID MODALIAS NAME SIZE BUS_PATH SUBSYSTEM READ_ONLY SYSTEM_DISK
192.168.1.139 /dev/sda VBOX HARDDISK - HDD - t10.ATA VBOX HARDDISK VB6fe28057-ef7ab08d scsi:t-0x00 - 11 GB /pci0000:00/0000:00:0d.0/ata3/host2/target2:0:0/2:0:0:0/ /sys/class/block *
192.168.1.210 /dev/sda VBOX HARDDISK - HDD - t10.ATA VBOX HARDDISK VB7bc38640-5d9fa0c9 scsi:t-0x00 - 11 GB /pci0000:00/0000:00:0d.0/ata3/host2/target2:0:0/2:0:0:0/ /sys/class/block *
192.168.1.243 /dev/sda VBOX HARDDISK - HDD - t10.ATA VBOX HARDDISK VB61133d46-e8aea93b scsi:t-0x00 - 11 GB /pci0000:00/0000:00:0d.0/ata3/host2/target2:0:0/2:0:0:0/ /sys/class/blockВ статье мы используем VirtualBox, поэтому диски у нас также виртуальные.
Состояние кластера
Давайте взлгянем на состояние кластера командой talosctl health:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig health
discovered nodes: ["192.168.1.139" "192.168.1.243" "192.168.1.210"]
waiting for etcd to be healthy: ...
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: ...
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: ...
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: ...
waiting for apid to be ready: OK
waiting for all nodes memory sizes: ...
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: ...
waiting for all nodes disk sizes: OK
waiting for kubelet to be healthy: ...
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: ...
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: ...
waiting for all k8s nodes to report: OK
waiting for all k8s nodes to report ready: ...
waiting for all k8s nodes to report ready: OK
waiting for all control plane static pods to be running: ...
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: ...
waiting for all control plane components to be ready: OK
waiting for kube-proxy to report ready: ...
waiting for kube-proxy to report ready: OK
waiting for coredns to report ready: ...
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: ...
waiting for all k8s nodes to report schedulable: OKЛоги сервиса
Ранее мы получали список всех сервисов через команду talosctl service . Зная имя сервиса можно получить его логи. Взглянем на логи kubelet первого рабочего узла:
$ talosctl -n $TALOS_WORKER_1_IP -e $TALOS_WORKER_1_IP --talosconfig ./talosconfig logs kubelet | tail -n 3
192.168.1.243: {"ts":1721557377049.4885,"caller":"memorymanager/memory_manager.go:354","msg":"RemoveStaleState removing state","v":0,"podUID":"46cf6469-d0c0-4b47-8f76-04faa2eaf8ba","containerName":"nginx"}
192.168.1.243: {"ts":1721557377057.5786,"caller":"reconciler/reconciler_common.go:247","msg":"operationExecutor.VerifyControllerAttachedVolume started for volume \"kube-api-access-mv8kd\" (UniqueName: \"kubernetes.io/projected/a9b5b804-728a-4152-902d-94bfed9b2c57-kube-api-access-mv8kd\") pod \"nginx-deployment-855cf47bc-4jk9b\" (UID: \"a9b5b804-728a-4152-902d-94bfed9b2c57\") ","v":0,"pod":{"name":"nginx-deployment-855cf47bc-4jk9b","namespace":"default"}}
192.168.1.243: {"ts":1721557395478.2058,"caller":"topologymanager/scope.go:117","msg":"RemoveContainer","v":0,"containerID":"23e90063b4bf6b0ba0946059e60378a1d2c7e9dded4fad08606dccecd55f109b"}Логи ядра
Пойдем чуть глужбе и посмотрим логи ядра посредством talosctl dmesg. Их также можно увидеть в дашборде по-умолчанию:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig dmesg | head -n 2
192.168.1.139: kern: notice: [2024-07-21T09:21:21.134719876Z]: Linux version 6.6.33-talos (@buildkitsandbox) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.42) #1 SMP Tue Jun 18 14:02:42 UTC 2024
192.168.1.139: kern: info: [2024-07-21T09:21:21.134719876Z]: Command line: BOOT_IMAGE=/boot/vmlinuz talos.platform=metal console=ttyS0 console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512Список директории и файлов
Так, а можно ли посмотреть какие директории и файлы содержит ОС, на которой мы запускаем Kubernetes-узлы? Мы можем воспользоваться командой talosctl list, у которой есть множество параметров:
Flags:
-d, --depth int32 maximum recursion depth (default 1)
-h, --help help for list
-H, --humanize humanize size and time in the output
-l, --long display additional file details
-r, --recurse recurse into subdirectories
-t, --type strings filter by specified types:
f regular file
d directory
l, L symbolic linkДавайте посмотрим на содержимое корневой директорий ВМ, где запущен Control Plane:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig list -d 1 -l -H
NODE MODE UID GID SIZE(B) LASTMOD NAME
192.168.1.139 drwxr-xr-x 0 0 248 B 4 weeks ago .
192.168.1.139 drwxr-xr-x 0 0 3 B 4 weeks ago .extra
192.168.1.139 drwxr-xr-x 0 0 99 B 4 weeks ago bin
192.168.1.139 drwxr-xr-x 0 0 26 B 4 weeks ago boot
192.168.1.139 drwxr-xr-x 0 0 2.8 kB 42 minutes ago dev
192.168.1.139 drwxr-xr-x 0 0 258 B 4 weeks ago etc
192.168.1.139 drwxr-xr-x 0 0 412 B 4 weeks ago lib
192.168.1.139 drwxr-xr-x 0 0 3 B 4 weeks ago mnt
192.168.1.139 drwxr-xr-x 0 0 17 B 1 day ago opt
192.168.1.139 dr-xr-xr-x 0 0 0 B 42 minutes ago proc
192.168.1.139 drwxr-x--- 0 0 3 B 4 weeks ago root
192.168.1.139 drwxr-xr-x 0 0 160 B 41 minutes ago run
192.168.1.139 drwxr-xr-x 0 0 1.4 kB 4 weeks ago sbin
192.168.1.139 dr-xr-xr-x 0 0 0 B 42 minutes ago sys
192.168.1.139 drwxr-xr-x 0 0 220 B 42 minutes ago system
192.168.1.139 drwxr-xr-x 0 0 40 B 42 minutes ago tmp
192.168.1.139 drwxr-xr-x 0 0 150 B 4 weeks ago usr
192.168.1.139 drwxr-xr-x 0 0 65 B 1 day ago varПросмотр netstat & df
Кроме того, нам доступны команды netstat и df:
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig mounts | head -n 10
NODE FILESYSTEM SIZE(GB) USED(GB) AVAILABLE(GB) PERCENT USED MOUNTED ON
192.168.1.139 devtmpfs 0.99 0.00 0.99 0.00% /dev
192.168.1.139 tmpfs 1.02 0.00 1.02 0.11% /run
192.168.1.139 tmpfs 1.02 0.00 1.02 0.03% /system
192.168.1.139 tmpfs 0.07 0.00 0.07 0.00% /tmp
192.168.1.139 /dev/loop0 0.07 0.07 0.00 100.00% /
192.168.1.139 tmpfs 1.02 0.00 1.02 0.00% /dev/shm
192.168.1.139 tmpfs 1.02 0.00 1.02 0.03% /etc/cri/conf.d/hosts
192.168.1.139 overlay 1.02 0.00 1.02 0.03% /usr/etc/udev
192.168.1.139 /dev/sda5 0.10 0.01 0.09 6.31% /system/state
$ talosctl -n $TALOS_CONTROL_PLANE_IP -e $TALOS_CONTROL_PLANE_IP --talosconfig ./talosconfig netstat | head -n 10
NODE Proto Recv-Q Send-Q Local Address Foreign Address State
192.168.1.139 tcp 0 0 127.0.0.1:43286 127.0.0.1:7445 ESTABLISHED
192.168.1.139 tcp 0 0 127.0.0.1:7445 127.0.0.1:45340 ESTABLISHED
192.168.1.139 tcp 0 0 192.168.1.139:37740 192.168.1.139:6443 ESTABLISHED
192.168.1.139 tcp 0 0 127.0.0.1:38382 127.0.0.1:10248 TIME_WAIT
192.168.1.139 tcp 0 0 127.0.0.1:32872 127.0.0.1:50000 TIME_WAIT
192.168.1.139 tcp 0 0 127.0.0.1:33520 127.0.0.1:50001 TIME_WAIT
192.168.1.139 tcp 0 0 127.0.0.1:37660 127.0.0.1:50001 TIME_WAIT
192.168.1.139 tcp 0 0 127.0.0.1:7445 127.0.0.1:53274 ESTABLISHED
192.168.1.139 tcp 0 0 127.0.0.1:59634 127.0.0.1:50000 TIME_WAITЭто лишь небольшая часть команд, которая нам доступна. Список всех можно посмотреть в документаций CLI.
Конец
Таким образом, в этой статье мы сравнили основные способы инсталляции Kubernetes и развернули свой кластер при помощи Talos Linux. Также мы изучили некоторые команды утилиты talosctl, которая обладает огромным функционалом для работы с кластером.
Полезные ресурсы: