Использование kubectl#

Сценарии эксплуатации кластера DropApp с помощью kubectl#

Kubectl — это инструмент командной строки используемый в DropApp для управления кластерами. Kubectl осуществляет поиск файла config в директории $HOME/.kube. Возможно указание других файлов путем установления переменной окружения KUBECONFIG или флага --kubeconfig.

Синтаксис#

1. Для выполнения команд kubectl в терминале используйте следующий синтаксис:

   kubectl [command] [TYPE] [NAME] [flags]
   

   Где command, TYPE, NAME и flags:

   • command: определяет выполняемую операцию с одним или несколькими ресурсами, например, create, get, describe, delete.

   • TYPE : определяет тип ресурса. Типы ресурсов не чувствительны к регистру, кроме этого, возможно использовать единственную, множественную или сокращенную форму. Например, следующие команды приведут к одному результату:

     shell
     kubectl get pod pod1
     kubectl get pods pod1
     kubectl get po pod1
     

   • NAME: определяет имя ресурса. Имена чувствительны к регистру. Если имя не указано, то отображаются подробности по всем ресурсам, например, kubectl get pods.

   При выполнении операции с несколькими ресурсами можно выбрать каждый ресурс по типу и имени, либо сделать это в одном или нескольких файлов.

   Выбор ресурсов по типу и имени позволяет:

   • группировать ресурсы, если все они одного типа: TYPE1 name1 name2 name<#>. Например, kubectl get pod example-pod1 example-pod2.

   • осуществить выбор нескольких типов ресурсов по отдельности. Например, TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>.

2. Выберите ресурс по типу и имени следующей командой:

   kubectl get pod/example-pod1 replicationcontroller/example-rc1
   

3. Выберите ресурсы по одному или нескольким файлам, введите команду:

   -f file1 -f file2 -f file5
   

4. Используйте YAML в файлах конфигурации, введите команду:

   kubectl get pod -f ./pod.yaml
   

   Файл конфигурации flags: определяет дополнительные флаги. Использование флагов -s или –server используется, чтобы указать адрес и порт API-сервера.

   Внимание

   Указанные флаги из командной строки переопределяют значения по умолчанию и связанные переменные окружения. При необходимости вызова справки выполните команду kubectl help.

Используйте kubectl apply -f <directory>. Команда ищет конфигурацию DropApp во всех .yaml, .yml и .json файлах в <directory> и передает ее apply.

Используйте селекторы меток для get и delete операций вместо конкретных имен объектов. Смотрите разделы, посвященные селекторам меток и эффективному использованию меток.

Используйте kubectl create deployment и kubectl expose для быстрого создания одноконтейнерных развертываний и служб.

Операции#

В следующей таблице приведены краткие описания и общий синтаксис всех операций kubectl:

Типы ресурсов#

В таблице перечислены все доступные типы ресурсов вместе с сокращенными аббревиатурами.

Опции вывода#

Опции вывода команд kubectl#

В следующих разделах рассматривается форматирование и сортировка вывода определенных команд.

Форматирование вывода#

Стандартный формат вывода всех команд kubectl представлен в понятном для человека текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги -o или --output к команде kubectl.

Синтаксис команд#

Команды должны иметь следующую форму:

kubectl [command] [TYPE] [NAME] -o <output_format>

В зависимости от операции, вkubectl поддерживаются форматы вывода, представленные в таблице ниже:

Пример формата вывода представлен следующей командой, которая выводит подробную информацию по указанному pod в виде объекта в YAML-формате:

kubectl get pod web-pod-13je7 -o yaml

Пользовательские столбцы#

Для определения пользовательских столбцов и вывода в таблицу только нужных данных, можно использовать опцию custom-columns. Возможно так же определить пользовательские столбцы в самой опции, либо сделать это в файле шаблона: -o custom-columns=<spec> или -o custom-columns-file=<filename>.

Опциональные примеры команд*#

• Столбцы указаны в самой команде:

  kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
  

• Столбцы указаны в файле шаблона:

  kubectl get pods <pod-name> -o custom-columns-file=template.txt
  

  Где файл template.txt содержит следующий вывод:

  NAME          RSRC
  
  metadata.name metadata.resourceVersion
  

  Результат выполнения любой из показанной выше команды представлен ниже:

  NAME           RSRC
  submit-queue   610995
  

Получение вывода с сервера#

kubectl может получать информацию об объектах с сервера. Это означает, что для любого обозначенного объекта сервер вернет столбцы и строки. Благодаря тому, что сервер изолирует реализацию вывода – гарантируется единообразный и понятный для человека вывод на всех машинах, использующих один и тот же кластер DropApp.

Эта функциональность включена по умолчанию. Чтобы отключить ее, необходимо добавить флаг --server-print=false в команду kubectl get.

Пример вывода информации о состоянии pod с использованием команды kubectl get:

kubectl get pods <pod-name> --server-print=false

Вывод будет выглядеть следующим образом:

NAME       READY     STATUS              RESTARTS   AGE
pod-name   1/1       Running             0          1m

Сортировка списка объектов#

Для вывода объектов в виде отсортированного списка в терминал используется флаг --sort-by к команде kubectl. Для сортировки объектов нужно указать любое числовое или строковое поле в флаге --sort-by. Для определения поля следует использовать выражение jsonpath.

Синтаксис команды будет выглядеть следующим образом:

kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>

Чтобы вывести список pods, отсортированных по имени, необходимо выполнить команду:

kubectl get pods --sort-by=.metadata.name

Распространенные сценарии использования kubectl#

В разделе приведены наиболее распространенные сценарии использования операций kubectl: kubectl apply. Эта команда необходима для внесения изменения или обновления ресурса из файла/потока stdin.

Чтобы использовать kubectl:

1. Создайте сервис из определения в example-service.yaml:

   kubectl apply -f example-service.yaml
   

2. Создайте контроллер репликации из определения в example-controller.yaml:

   kubectl apply -f example-controller.yaml
   

3. Создайте объекты, которые определены в файлах с расширением .yaml, .yml или .json в директории directory.

   kubectl apply -f <directory>
   

4. Выведите один или несколько ресурсов и все pods в текстовом формате:

   kubectl get pods -A
   

5. Проверить все pods в определенном namespace.

   kubecti get pods -n [namespace]
   

6. Выведите все pods в текстовом формате вывода и включите дополнительную информацию (например, имя узла).

   kubectl get pods -o wide
   

7. Выведите контроллер репликации с указанным именем в текстовом формате вывода:

   kubectl get replicationcontroller <rc-name>
   

8. Выведите все контроллеры репликации и сервисы вместе в текстовом формате вывода:

   kubectl get rc,services
   

9. Выведите все наборы демонов в текстовом формате вывода:

   kubectl get ds
   

10. Выведите все pods, запущенные на узле server01:

    kubectl get pods --field-selector=spec.nodeName=server01
    

11. Посмотрите подробное состояние одного или нескольких ресурсов. Обратите внимание, что по умолчанию также включаются неинициализированные ресурсы. Например, описать состояние pod в namespace cube system.

    kubectl describe pod <pod-name> -n kube-system
    

12. Посмотрите информацию об node с именем <node-name>.:

    kubectl describe nodes <node-name>
    

13. Посмотрите подробности pod <pod-name>:

    kubectl describe <pod-name>
    

14. Посмотрите подробности всех pods, управляемых контроллером репликации <rc-name>.

    Примечание

    Любые pods, созданные контроллером репликации, имеют префикс с именем контроллера репликации:

    kubectl describe pods

15. Посмотрите подробности по всем pods:

    kubectl describe pods
    

    Примечание

    Команда kubectl get используется для получения одного или нескольких ресурсов одного и того же типа. Она поддерживает большой набор флагов, с помощью которых можно настроить формат вывода, например, с помощью флага -o или --output.

    Чтобы отслеживать изменения в конкретном объекте, необходимо указать флаг -w или --watch. Команда kubectl describe фокусируется на описании взаимосвязанных аспектов указанного ресурса. При генерации вывода для пользователя она может обращаться к API-серверу. Например, команда kubectl describe node выдает не только информацию об узле, но и краткий обзор запущенных на нем pods, генерируемых событий и т.д.

16. Удалите ресурсы из файла потока stdin при помощи селекторов меток, селекторов ресурсов или имен ресурсов:

    kubectl delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])
    

    Примеры:

    # Удалить pod, используя тип и имя, указанные в pod.json.
    kubectl delete -f ./pod.json
    
    # Удалить pod на основе типа и имени в JSON, переданном в stdin.
    cat pod.json | kubectl delete -f -
    
    # Удалить pod и сервисы с одинаковыми названиями "baz" и "foo"
    kubectl delete pod,service baz foo
    
    # Удалить pod и сервисы с именем метки=myLabel.
    kubectl delete pods,services -l name=myLabel
    
    # Удалить pod с UID 1234-56-7890-234-456.
    kubectl delete pod 1234-56-7890-234234-456456
    
    # Удалить все pods
    kubectl delete pods --all
    

17. Удалите pod по типу и имени, которые указаны в файле pod.yam:

    kubectl delete -f pod.yaml
    

18. Удалите все pods и сервисы с именем метки <label-name>:

    kubectl delete pods,services -all name=<label-name>
    

19. Удалите все pods, включая неинициализированные:

    kubectl delete pods --all
    

20. Получите вывод от запущенной команды date в pod <pod-name>. По умолчанию отобразится следующий вывод из первого контейнера:

    kubectl exec <pod-name> date
    

21. Получите вывод из запущенной команды date в контейнере <container-name> для pod <pod-name>:

    kubectl exec <pod-name> -c <container-name> date
    

22. Запустите интерактивный терминал (TTY) и /bin/bash в pod <pod-name>. По умолчанию отобразится следующий вывод из первого контейнера:

    kubectl exec -ti <pod-name> /bin/bash
    

23. Выведите логи контейнера в pod:

    kubectl logs
    

24. Выведите текущие логи в pod, как представлено ниже при помощи команды<pod-name>:

    kubectl logs <pod-name>
    

25. Выведите логи в pod <pod-name> в режиме реального времени. Это похоже на команду 'tail -f' Linux.

    kubectl logs -f <pod-name>
    

Управление рабочей нагрузкой посредством Kubectl#

Создание нового namespace#

1. Для создания нового namespace используйте команду:

   kubectl create namespace <test>
   

2. Для создания/редактирования ресурсов используйте команду:

   kubectl edit / kubectl patch
   

3. Для удаления ресурсов используйте команду:

   kubectl delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])
   

   Пример создания нового namespace с названием myapp:

   kubectl create namespace myapp
   

   В результате будет получен вывод:

   ~# kubectl create namespace myapp
   namespace/myapp created
   ~#
   

4. Убедитесь, что новое namespace отображается, при помощи команды:

   kubectl get namespace
   

   В результате будет получен вывод:

   ~# kubectl get ns
   NAME              STATUS   AGE
   default           Active   71m
   kube-system       Active   71m
   kube-public       Active   71m
   kube-node-lease   Active   71m
   myapp             Active   49s
   ~#
   

Запуск рабочей нагрузки kubectl#

Сценарий возможно осуществить с помощью команды kubectl create. Для изменения и создания объектов, используйте команды kubectl, которые берут на вход описание объектов:

• kubectl create -f {файл с описанием объекта} для создания объектов;

• kubectl apply -f {файл с описанием объекта} для обновления объектов;

• kubectl delete -f {файл с описанием объекта} для удаления объекта.

На основе текущего namespace и по стандартным для объекта полям - apiVersion, kind, metadata.name, kubectl находит соответствующий ресурс в API и совершает запросы к API Server. Для этого:

1. Воспользуйтесь описанием ресурса в файле { }.json и создайте объект pod с помощью следующей команды:

   kubectl create -f hello-service.json
   

   Запрос сделанный kubectl в API Server, будет идентичен запросу в сценарий запуска нагрузки.

2. После этого шага запросите статус объекта pod:

   kubectl get pod hello-demo
   

   В результате будет получен вывод:

   ~# kubectl get pod hello-demo
   NAME         READY   STATUS    RESTARTS   AGE
   hello-demo   1/1     Running   0          4m34s
   ~#
   

3. При необходимости удалите ресурс, отвечающий за рабочую нагрузку с помощью команды:

   kubectl delete -f hello-service.json
   

   В результате будет получен вывод:

   ~# kubectl delete -f hello-service.json
   pod "hello-demo" deleted
   ~#
   

Сетевые политики (Network Policies)#

Если необходимо управлять потоком трафика на уровне IP-адреса или порта (уровень OSI 3 или 4), то можно рассмотреть возможность использования NetworkPolicies для конкретных приложений в кластере DropApp. Сетевые политики – это конструкция, ориентированная на приложения, которая позволяет указать, как pod разрешено взаимодействовать с различными сетевыми «объектами» (термин «объект» используется здесь, чтобы избежать перегрузки более распространенных терминов, таких как «конечные точки» и «службы», которые имеют специфические коннотации DropApp) по сети. Сетевые политики применяются к соединению с pods на одном или обоих концах и не имеют отношения к другим подключениям.

Объекты, с которыми pod может взаимодействовать, идентифицируются с помощью комбинации следующих 3 идентификаторов:

• других pods, которые разрешены (исключение: pod не может заблокировать доступ к себе);

• разрешенные namespaces;

• IP-блоки (исключение составляет трафик к узлу, на котором запущен pod. С этого узла трафик всегда разрешен, независимо от IP-адреса pod или самого узла).

При определении сетевой политики на основе pod или namespace используйте селектор, чтобы указать, какой трафик разрешен для и из pod, которые соответствуют селектору. Когда создаются сетевые политики на основе IP, пользователи определяют политики на основе блоков IP (диапазонов CIDR).

Предварительные требования#

Сетевые политики реализуются с помощью сетевого плагина. Чтобы использовать сетевые политики, необходимо использовать сетевое решение, поддерживающее NetworkPolicy. Создание ресурса NetworkPolicy без контроллера, который его реализует, не будет иметь эффекта.

Два вида изоляции pod#

Существует два вида изоляции для pod: изоляция для «Egress» и изоляция для «Ingress». Они касаются того, какие соединения могут быть установлены. «Изоляция» здесь не является абсолютной, скорее это означает «применяются некоторые ограничения». Альтернатива «неизолированный для $direction» означает, что в указанном направлении не применяются никакие ограничения. Два вида изоляции (или более, чем два вида) объявляются независимо, и оба имеют отношение к соединению от одного pod к другому.

По умолчанию pod не изолирован для выхода: разрешены все исходящие подключения. Pod изолирован для выхода, если существует какая-либо сетевая политика, которая одновременно выбирает pod и имеет «Egress» в своем policyTypes. Когда pod изолирован для выхода, единственными разрешенными подключениями из pod являются те, которые разрешены Egress списком сетевой политики и применяются к pod.

По умолчанию pod не изолирован для входа: разрешены все входящие подключения. Pod изолирован для входа, если существует какая-либо сетевая политика, которая одновременно выбирает pod и имеет «Ingress» в policyTypes: такая политика применяется к pod для входа. Когда pod изолирован для входа, единственными разрешенными подключениями к pod являются соединения с узла pod и те, которые разрешены Ingress списком сетевой политики и применяются к pod для входа.

Сетевые политики не конфликтуют: они дополняют друг друга. Если какая-либо политика или положения применяются к данному pod для данного направления, соединения, разрешенные в этом направлении из этого pod, являются объединением того, что разрешено применимыми политиками. Таким образом, порядок оценки не влияет на результат политики.

Для того чтобы соединение из pod источника в pod назначения было разрешено, необходимо разрешить подключение как политикой «Ingress» в pod источника, так и политикой «Egress» в pod назначения. Если какая-либо из сторон не разрешает подключение, этого не произойдет.

Ресурс сетевой политики#

Пример сетевой политики может выглядеть следующим образом:

service/networking/networkpolicy.yaml Скопируйте сервис / сеть/networkpolicy.yaml в буфер обмена
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 00.0.0.0/24
ports:
- protocol: TCP
port: 5978

Обязательные поля (Mandatory Fields): как и во всех других конфигурациях DropApp, для сетевой политики необходимы поля apiVersion, kind и metadata.

Спецификация (spec): спецификация NetworkPolicy содержит всю информацию, необходимую для определения конкретной сетевой политики в данном namespace.

Pod-cелектор (podSelector): каждая сетевая политика включает в себя podSelector, выбирающий группировку pods, к которым применяется политика. В примере политики выбираются pods с меткой role=db. Пустое значение podSelector выбирает все pods в namespace.

Типы политик (policyTypes): каждая сетевая политика включает в себя policyTypes список, который может включать в себя ingress, egress или сразу оба типа. Поле policyTypes указывает, применяется ли данная политика к входящему трафику в выбранный pod, исходящему трафику из выбранных pods или к обоим типам. Если в сетевой политике указано не policyTypes, то по умолчанию всегда будет установлено ingress, а egress установится, если сетевая политика имеет какие-либо правила выхода.

Вход (ingress): каждая сетевая политика может включать список разрешенных ingress правил. Каждое правило разрешает трафик, соответствующий разделам from и ports. Пример политики (представлен выше) содержит единственное правило, которое сопоставляет трафик на одном порту с одним из трех источников, первый из них указан через ipBlock, второй через namespaceSelector, а третий через podSelector.

Выход (egress): каждая сетевая политика может содержать список разрешенных egress правил. Каждое правило разрешает трафик, соответствующий разделам to и ports. Пример политики (представлен выше) содержит единственное правило, которое сопоставляет трафик по одному порту в любой выбранной подсети (в примере 00.0.0.0/24).

Ниже представлен пример сценария NetworkPolicy:

1. Изолируйте role=db pods в default namespace как для входящего, так и для исходящего трафика (если они еще не были изолированы).

2. Используйте правила входа для разрешения подключения ко всем pods в default namespace с меткой role=db на TCP-порту 6379 из:

   • любого pod в default пnamespace с меткой role=frontend;

   • любого pod в namespace с меткой project=myproject;

   • IP–адреса в диапазонах 172.17.0.0–172.17.0.255 и 172.17.2.0-172.17.255.255 (т.е. все из них, 172.17.0.0/16 кроме 172.17.1.0/24).

3. Используйте правила выхода для разрешения подключения из любого pod в default namespace с меткой role=db к CIDR 00.0.0.0/24 на TCP-порту 5978.