НОВОСТИ Kubernetes tips & tricks: удобные заготовки для kubectl

NewsBot · 03.08.2020

Внутри компании мы активно делимся между собой полученными знаниями: не только в виде формальных wiki-инструкций, но и сообщениями в Slack (а чтобы ничего не терялось, предусмотрена умная система поиска, но это уже отдельная история…). У нас накопилось уже большое количество разнообразных заготовок для консольных операций в Kubernetes с kubectl. Про них и пойдет речь в этой статье.

Какие-то команды могут оказаться повседневной обыденностью для некоторых читателей, но если найдутся и те, кто откроет для себя новое, улучшив тем самым свою эффективность, — цель статьи будет достигнута.

NB: Некоторые из перечисленных ниже команд были составлены нашими инженерами, а другие — найдены на просторах интернета. В последнем случае они были проверены и признаны полезными.

Итак, поехали!

Получение списков pod'ов и узлов

Думаю, что получение всех pod'ов из всех пространств имён путем указания ключа --all-namespaces не является секретом ни для кого. Но многие так привыкли к нему, что не заметили появления более короткой версии — -A (по меньшей мере, такая возможность точно присутствует начиная с релиза Kubernetes 1.15).
Как найти все проблемные pod'ы, которые не в запущенном состоянии (т.е. не Running)?

kubectl get pods -A --field-selector=status.phase!=Running | grep -v Complete

Кстати, присмотреться к --field-selector вообще очень полезно (см.
You must be registered for see links
).
Получить список узлов с указанием объема их оперативной памяти:

kubectl get no -o json | \
jq -r '.items | sort_by(.status.capacity.memory)[]|[.metadata.name,.status.capacity.memory]| @tsv'
Получить список узлов и количество pod'ов на них:

kubectl get po -o json --all-namespaces | \
jq '.items | group_by(.spec.nodeName) | map({"nodeName": .[0].spec.nodeName, "count": length}) | sort_by(.count)'
Бывает, что по какой-то причине DaemonSet не выехал на какой-то узел. Искать вручную — утомительное занятие, поэтому вот мини-скрипт для получения списка узлов, на которые не выехали DaemonSet'ы:

ns=my-namespace
pod_template=my-pod
kubectl get node | grep -v \"$(kubectl -n ${ns} get pod --all-namespaces -o wide | fgrep ${pod_template} | awk '{print $8}' | xargs -n 1 echo -n "\|" | sed 's/[[:space:]]*//g')\"
Вот так с kubectl top можно получить pod'ы, которые потребляют максимальное количество процессора или памяти:

# cpu
kubectl top pods -A | sort --reverse --key 3 --numeric
# memory
kubectl top pods -A | sort --reverse --key 4 --numeric
Сортировка списка pod'ов — в данном случае, по количеству рестартов:

kubectl get pods --sort-by=.status.containerStatuses[0].restartCount

Разумеется, сортировка может быть и по другим полям (см.
You must be registered for see links
и
You must be registered for see links
).

Получение другой информации

Когда производится отладка работы Ingress'а, мы неизбежно доходим до сервиса и далее ищем pod'ы по его селектору. Сначала я искал селектор в манифесте сервиса, но со временем позже начал применять -o wide:

kubectl -n jaeger get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR

jaeger-cassandra ClusterIP None 9042/TCP 77d app=cassandracluster,cassandracluster=jaeger-cassandra,cluster=jaeger-cassandra

Как легко увидеть, в этом случае мы сразу получаем селектор, по которому сервис находит нужные pod'ы.
- Получить по каждому контейнеру каждого pod'а его limits и requests:
  
  kubectl get pods -n my-namespace -o=custom-columns='NAME:spec.containers
- .name,MEMREQ:spec.containers
- .resources.requests.memory,MEMLIM:spec.containers
- .resources.limits.memory,CPUREQ:spec.containers
- .resources.requests.cpu,CPULIM:spec.containers
- .resources.limits.cpu'
- У команды kubectl run (а также create, apply, patch) есть замечательная возможность посмотреть изменения до их применения — это делает флаг --dry-run. А если применить вкупе с -o yaml, можно получить манифест требуемой сущности. Например:
  
  kubectl run test --image=grafana/grafana --dry-run -o yaml
  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
  creationTimestamp: null
  labels:
  run: test
  name: test
  spec:
  replicas: 1
  selector:
  matchLabels:
  run: test
  strategy: {}
  template:
  metadata:
  creationTimestamp: null
  labels:
  run: test
  spec:
  containers:
  - image: grafana/grafana
  name: test
  resources: {}
  status: {}
  
  Осталось только сохранить в файл, удалить пару системных/ненужных полей и можно использовать дальше.
- Получить пояснение по манифесту какого-либо ресурса:
  
  kubectl explain hpa
  
  KIND: HorizontalPodAutoscaler
  VERSION: autoscaling/v1
  
  DESCRIPTION:
  configuration of a horizontal pod autoscaler.
  
  FIELDS:
  apiVersion
  APIVersion defines the versioned schema of this representation of an
  object. Servers should convert recognized schemas to the latest internal
  value, and may reject unrecognized values. More info:
  
  You must be registered for see links
  
  kind
  Kind is a string value representing the REST resource this object
  represents. Servers may infer this from the endpoint the client submits
  requests to. Cannot be updated. In CamelCase. More info:
  
  You must be registered for see links
  
  metadata

НОВОСТИ Kubernetes tips & tricks: удобные заготовки для kubectl

NewsBot