Kubernetes tips & tricks: удобные заготовки для kubectl

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

-orbnzg04igjb7nhzdh0y485pa8.png

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

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

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

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


  1. Думаю, что получение всех pod’ов из всех пространств имён путем указания ключа --all-namespaces не является секретом ни для кого. Но многие так привыкли к нему, что не заметили появления более короткой версии — -A (по меньшей мере, такая возможность точно присутствует начиная с релиза Kubernetes 1.15).
  2. Как найти все проблемные pod’ы, которые не в запущенном состоянии (т.е. не Running)?
    kubectl get pods -A --field-selector=status.phase!=Running | grep -v Complete
    

    h3wgl2hcy3t_pgrm-bagppkrsfe.png

    Кстати, присмотреться к --field-selector вообще очень полезно (см. документацию).

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

    dmvngaibjad6h4nkqu1-yqr9as0.png
  4. Получить список узлов и количество pod’ов на них:
    kubectl get po -o json --all-namespaces | \
      jq '.items | group_by(.spec.nodeName) | map({"nodeName": .[0].spec.nodeName, "count": length}) | sort_by(.count)'
    

    ehghf8yzi49w7g7_xctxh39p_pk.png
  5. Бывает, что по какой-то причине 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')\"
    
  6. Вот так с kubectl top можно получить pod’ы, которые потребляют максимальное количество процессора или памяти:
    # cpu
    kubectl top pods -A | sort --reverse --key 3 --numeric
    # memory
    kubectl top pods -A | sort --reverse --key 4 --numeric
  7. Сортировка списка pod’ов — в данном случае, по количеству рестартов:
    kubectl get pods --sort-by=.status.containerStatuses[0].restartCount

    cwzhpxlgc1akjxknzk-euvvahac.png

    Разумеется, сортировка может быть и по другим полям (см. PodStatus и ContainerStatus).


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


  1. Когда производится отладка работы 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’ы.
  2. Получить по каждому контейнеру каждого 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'

    5ervr6m0o01lkg_6s7dnahn0bhc.png
  3. У команды 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: {}
    

    Осталось только сохранить в файл, удалить пару системных/ненужных полей и можно использовать дальше.
  4. Получить пояснение по манифесту какого-либо ресурса:
    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:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
    
       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:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
    
       metadata    
         Standard object metadata. More info:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
    
       spec    
         behaviour of autoscaler. More info:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status.
    
       status    
         current information about the autoscaler.
    Полная и весьма полезная информация!


    Сети


    1. Получить внутренние IP-адреса узлов кластера:
      kubectl get nodes -o json | \
        jq -r '.items[].status.addresses[]? | select (.type == "InternalIP") | .address' | \
        paste -sd "\n" -
      

      p89eily3zmvc6a4vjxgwmji_wjm.png
    2. Вывести все сервисы и nodePort, которые они занимают:
      kubectl get --all-namespaces svc -o json | \
        jq -r '.items[] | [.metadata.name,([.spec.ports[].nodePort | tostring ] | join("|"))]| @tsv'
      

      wa-jmt3guqxmtfxkoit7zxs4jic.png
    3. В ситуациях, когда возникают проблемы с CNI (например, с Flannel), для выявления проблемного pod’а надо проверить маршруты. Здесь очень пригодятся подсети pod’ов, которые используются в кластере:
      kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' | tr " " "\n"
      

      5vsayl5imukxs_mzni-wzyygfoq.png


    Логи


    1. Получение логов pod’а c человекочитаемым timestamp на случай его отсутствия:
      kubectl -n my-namespace logs -f my-pod --timestamps
      
      2020-07-08T14:01:59.581788788Z fail: Microsoft.EntityFrameworkCore.Query[10100]
      

      Выглядит намного удобнее, не так ли?
    2. Не ждите, пока выведется весь лог контейнера pod’а — используйте --tail:
      kubectl -n my-namespace logs -f my-pod --tail=50
      
    3. Получить логи со всех контейнеров pod’а:
      kubectl -n my-namespace logs -f my-pod --all-containers
      
    4. Получить логи со всех pod’ов на основании label’а:
      kubectl -n my-namespace logs -f -l app=nginx
    5. Получить логи предыдущего контейнера, который, к примеру, упал:
      kubectl -n my-namespace logs my-pod --previous
      


    Другие быстрые действия


    1. Как скопировать все секреты из одного пространства имён в другое?
      kubectl get secrets -o json --namespace namespace-old | \
        jq '.items[].metadata.namespace = "namespace-new"' | \
        kubectl create-f  -
      
    2. Быстро создать самоподписанный сертификат для тестов:
      openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=grafana.mysite.ru/O=MyOrganization"
      kubectl -n myapp create secret tls selfsecret --key tls.key --cert tls.crt


    Полезные ссылки по теме


    Вместо заключения — небольшой список схожих материалов и коллекций, найденных в интернете:

    P.S.


    Читайте также в нашем блоге:

    © Habrahabr.ru