Несмотря на кажущуюся незначительность, использование kubectl CLI может стать решающим фактором для устранения неполадок или понимания конфигурации рабочих нод без необходимости входить в консоль.
Этот мощный инструмент позволяет без особых усилий получить подробную информацию о рабочих нодах.
Недавно пришлось искать команду, чтобы перечислить все рабочие ноды вместе с их AMI-идентификаторами с помощью kubectl.
Потребовалось некоторое время, чтобы найти именно ту команду, которая отвечала этимтребованиям.
Хотя описание нод предоставляет необходимые сведения, представьте себе сложность, когда речь идет о сотнях нод в кластере.
Именно здесь и проявляется мощь kubectl – он выходит за рамки пользовательского интерфейса или eksctl/awscli, предлагая универсальный инструмент для глубокого анализа и изучения вашей среды Kubernetes”.
Хотя изначально нужно было перечислить все узлы вместе с их AMI ID с помощью kubectl, вскоре было обнаружено его универсальность в предоставлении большого количества информации.
Этот мощный инструмент может помочь в различных сценариях, например, перечислить рабочие ноды Kubernetes на основе определенных типов инстансов, определить ноды, работающие на SPOT или On-Demand инстансов, определить ноды в определенном регионе или зоне, отфильтровать по шаблону запуска или версии и даже сузить результаты на основе пользовательских лейблов, назначенных при создании инстанса.
Это комплексное решение для разнообразного анализа и управления нодами в вашем кластере Kubernetes.
Это небольшая статья, но она может сэкономить вам время.
Изначально для сбора необходимых данных мы прибегаем к использованию цикла for с помощью kubectl describe.
Однако со временем мы обнаружили более простой подход к получению нужных сведений.
Показать ноды с данными об их AMI.
Способ 1: Изначально я выполнял describe в цикле for и получал детали.
Например, я создавал список узлов в файле и передавал его для поиска деталей AMI.
Сохраним ноды в текстовый файл
kubectl get nodes | grep -v NAME| awk {'print $1'} > nodes.txtЗатем получите сведения об AMI, выполнив kubectl describe в цикле
for i in $(cat nodes.txt); do echo "Node: $i and its AMI is: $(kubectl describe nodes $i | grep "eks.amazonaws.com/nodegroup-image"| cut -d "=" -f 2) "; doneОднако у нас есть несколько лучших способов сделать это.
Способ 2: Используя kubectl напрямую
kubectl get nodes -o custom-columns=NAME:.metadata.name,AMI:'{.metadata.labels.eks\.amazonaws\.com/nodegroup-image}'Мы можем использовать лейблы для получения подробной информации о рабочих нодах из CLI.
EKS по умолчанию добавляет несколько лейблов, а также включает те, которые мы передаем при создании групп хостов.
Поэтому мы можем использовать эти метки для анализа рабочих узлов из CLI.
Добавим несколько других примеров ниже:
Пример 1: Составление списка рабочих нод, использующих экземпляры SPOT / ON DEMAND, с помощью kubectl
kubectl get nodes -o custom-columns=NAME:.metadata.name,TYPE:'{.metadata.labels.eks\.amazonaws\.com/capacityType}'Пример 2: Вывод списка рабочих нод с типом инстанса EC2 с помощью kubectl
kubectl get nodes -o custom-columns=NAME:.metadata.name,TYPE:'{.metadata.labels.node\.kubernetes\.io/instance-type}'Пример 3: Вывести список рабочих хостов, работающих в зависимости от зоны доступности, с помощью kubectl
kubectl get nodes -o custom-columns=NAME:.metadata.name,TYPE:'{.metadata.labels.failure-domain\.beta\.kubernetes\.io/zone}'Вы можете описать один рабочий хост и проверить доступные лейблов и вывести на основе ваших конкретных требований.
Вы можете направить и провести дальнейший анализ grep/awk/sort для ваших требований.
Это поможет вам создать быструю инвентаризацию рабочих узлов EKS с помощью этой информации.
см. также:
- ☸️ Безопасно удаляем worker ноду из кластера Kubernetes
- ☸️ Как перезапустить Kubernetes на Linux
- ☸️ Как использовать пространства имен Kubernetes
- ☸️ Как использовать команду Scale в Kubernetes
- ☸️ Как создать и управлять подом на Kubernetes
- ☸️ k0s, k3s и microk8s Сравнение дистрибутивов Kubernetes
- ☸️ Получение событий Kubernetes по дате с помощью kubectl
