KubernetesArchitecture
Кластер Kubernetes состоит из двух типов ресурсов:
-
Master координирует кластер. Мастер координирует всю деятельность в кластере, такие как планирование приложений, поддержание необходимого состояния приложений, масштабирования приложений и развертывание новых обновлений.
-
Node это рабочие, которые выполняют приложения. Node представляет собой виртуальный или физический компьютер, который служит в качестве рабочей машины в кластере Kubernetes. На каждой Node должен быть Kubelet, который представляет собой средство для управления нодой и связи с Мастером Kubernetes. Узел должен также иметь инструменты для работы с контейнерами, такихи как Docker или rkt. Продакшен-кластер Kubernetes, должен иметь как минимум три ноды.
Ноды связываются с Мастером через API Kubernetes, который предоставляет Мастер. Конечные пользователи также могут использовать API Kubernetes, чтобы непосредственно взаимодействовать с кластером.
Управление кластером из командной строки происходит с помощью утилиты kubectl. Команда kubectl version покажет версию клиента (сама kubectl) и сервера Kubernetes (это версия компонента Master). Также здесь будет выведена информация о билде. Таким образом, кластер и клиент установлены и нормально работают.
Общий формат работы с командой kubectl таков: kubectl action resource. Это выполнит конкретную операцию (как создание, опись) на конкретном ресурсе (как Node, Container). Используйте флаг --help после команды, чтобы получить дополнительную информацию о возможных параметрах: kubectl get nodes --help.
Команда kubectl cluster-info показывает информацию о кластере. Мы видим, что запушен Мастер и Панель управдения.
Команда kubectl get nodes покажет список Node в кластере. Статус Ready показывает, что нода готова разворачивать придожения.
Чтобы развернуть приложение, нужно создать Deployment (Развертывание). Deployment отвечает за создание и обновление экземпляров приложения. После того как вы создали Deployment, Мастер-компонент Kubernetes назначает экземпляры приложения, которые создал Deployment, на отдельные Node в кластере.
После того, как экземпляры приложения созданы, контроллер Kubernetes Deployment Controller непрерывно следит за этими экземплярами. Контроллер заменяет экземпляр, если Нода что хостит его, падает или удаляется. Это обеспечивает механизм самовосстановления решая вопрос неисправности машин или технического обслуживания.
Вы можете создавать и управлять Deployment с помощью интерфейса командной строки Kubernetes, Kubectl. Kubectl использует API Kubernetes для взаимодействия с кластером. При создании Deployment, вам необходимо указать контейнерный образ для вашего приложения, и количество копий, которые вы хотите запустить. Вы можете изменить эту информацию позже при обновлении Deployment. Приложения должны быть упакованы в один из поддерживаемых форматов контейнеров для того, чтобы их можно было развернуть на Kubernetes.
Для нашего первого развертывания, мы будем использовать NodeJS-приложение упакованное в Docker-контейнер. Исходный код и Dockerfile доступны в репозитории GitHub.
Команда kubectl get nodes покажет список Node в кластере. Kubernetes выберет ноду для запуска приложения, основываясь на ее доступных ресурсах.
Команда kubectl run создает новый Deployment. Нужно предоставить имя для Deployment, местоположение образа с приложением (включая полный URL для образов, расположенных вне Docker hub). Нам нужно запустить приложение на определенном порту, так что мы добавляем параметр --port:
kubectl run kubernetes-bootcamp --image=docker.io/jocatalin/kubernetes-bootcamp:v1 --port=8080
Вы только что развернули ваше первое приложение, создав Deployment. Эта команда сделала следующее:
- нашла подходящюю Node, на которой можно было запустить экземпляр приложения (у нас есть только одна доступная Node)
- назначила приложение для запуска на этой Node
- настроила кластер перепланировать экземпляр на новой Node, когда это необходимо
Команда kubectl get deployments покажет ваши Deployment.
Мы видим, что есть 1 Deployment, выполняющий один экземпляр приложения. Экземпляр работает внутри контейнера Docker на вашей Node.
По умолчанию развернутые приложения видны только внутри кластера Kubernetes. Выставление приложений наружу будет рассмотрено позже. Для просмотра вывода приложения, без выставления его наружу, мы создадим маршрут между нашим терминалом и кластером Kubernetes используя прокси:
kubectl proxy
Терминал, в котором вы запустили эту команду, будет занят, и чтобы продолжить работать с кластером в командной строке, нужно запустить другой терминал.
Теперь у нас есть соединение между нашим хостом (терминалом) и кластером Kubernetes. Запустившийся прокси обеспечивает прямой доступ к API. Приложение работает внутри Pod (Под) (мы рассмотрим концепцию Pod в следующем модуле). Следующая команда получит имя Pod и сохранить его в переменной окружения POD_NAME:
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME
Чтобы увидеть вывод нашего приложения выполните следующий запрос с помощью curl:
curl http://localhost:8001/api/v1/proxy/namespaces/default/pods/$POD_NAME/
URL - это путь к API Pod. Обратите внимание, что curl использует localhost - это благодаря ранее поднятому прокси.
При создании Deployment в модуле 2, Kubernetes создал Pod для размещения вашего экземпляра приложения. Pod является абстракцией Kubernetes, которая представляет собой группу из одного или нескольких контейнеров приложений (таких как Docker или rkt), а также некоторые общие ресурсы для этих контейнеров. Эти ресурсы включают в себя:
- Общее хранилище данных: Volumes (тома)
- Сеть: уникальный IP-адрес кластера
- Информация о том, как запустить каждый контейнер, например, версия образа или определенные используемые порты
Pod моделирует "логический хост" для конкретного приложения и может содержать различные контейнеры приложений, которые относительно тесно связаны. Например, Pod может включать в себя как контейнер с вашим приложением NodeJS, так и другой контейнер, подающий данные, которые будут опубликованы веб-сервером NodeJS. Контейнеры в Pod разделяют IP-адрес и пространство портов, всегда размещаются и назначаются совместно, и запущены в общем контексте на той же Node.
Pods это неделимая единица на платформе Kubernetes. Когда мы создаем Deployment на Kubernetes, этот Deployment создает Pods с контейнерами внутри них (в отличие от создания контейнеров непосредственно). Каждый Pod привязан к Node, на которую он назначен, и остается там до завершения (в соответствии с политикой перезапуска) или удаления. В случае выхода Node из строя, идентичные Pods назначаются на другие доступные Node в кластере.
Контейнеры должны быть вместе в одном Pod только в том случае, если они тесно связаны и должны совместно использовать ресурсы, такие как диск.
Подробнее про Pods можно почитать на выделенной странице руководства Kubernetes.
Pod всегда работает на Node. Node представляет собой рабочую машину в Kubernetes и может быть виртуальным или физическим компьютером, в зависимости от кластера. Каждая Node управляется Master'ом. Node может иметь несколько Pod'ов, и Kubernetes Master автоматически обрабатывает назначение подов между нодами в кластере. Автоматическое планирование Мастера учитывает имеющиеся ресурсы на каждой ноде.
На каждой ноде Kubernetes работают, по крайней мере:
- Kubelet, процесс отвечает за связь между Kubernetes Master и Nodes; он управляет Pods и контейнерами, работающими на машине.
- Среда выполнения контейнеров (например, Docker, rkt), ответственная за загрузку образа контейнера из реестра, распаковку контейнера, и запуск приложения.
В модуле 2, вы использовали интерфейс командной строки kubectl. Вы будете продолжать использовать его в модуле 3, чтобы получить информацию о развернутых приложениях и их окружению. Наиболее распространенные операции можно выполнить с помощью следующих команд kubectl:
-
kubectl get- список ресурсов -
kubectl describe- показать подробную информацию о ресурсе -
kubectl logs- печать журналов контейнера внутри Pod -
kubectl exec- выполнить команду на контейнере внутри Pod
Вы можете использовать эти команды, чтобы увидеть, когда приложения были развернуты, каков их текущий статус, где они работают, и какова их конфигурация.
Теперь, когда мы знаем больше о кластерных компонентах и командной строке kubectl, давайте исследуем наше приложение.
Давайте проверим, что приложение, которое мы развернули в предыдущем модуле, работает. Мы будем использовать команду kubectl get и искать существующие Pods:
kubectl get pods
Далее, чтобы посмотреть, что за контейнеры находятся внутри Pod, и какие образы использованы для создания этих контейнеров мы запускаем команду:
kubectl describe pods
Мы видим здесь подробности о Pod'е контейнера: IP-адрес, используемые порты и список событий, связанных с жизненным циклом Pod.
Вывод команды kubectl describe pods обширен и охватывает некоторые понятия, которые мы еще не проходили, но не волнуйтесь, они станут знакомыми к концу этого курса.
Примечание: команда describe может быть использована для получения подробной информации о большинстве примитивов Kubernetes: Nodes, Pods, Deployments. Вывод describe предназначен для чтения человеком, а не для скриптования.
Покажем приложение в терминале. Для начала, освежим то, что мы уже изучили. В другом терминале запустим прокси:
kubectl proxy
Потом прочитаем имя пода в переменную:
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME
Чтобы прочитать логи из контейнера, используем команду kubectl logs:
kubectl logs $POD_NAME
Имейте в виду, что нам не надо указывать имя контейнера, поскольку у нас только один контейнер в Pod.
Мы можем выполнить команды непосредственно в контейнере. Для этого мы используем команду exec и передаем имя Pod'а в качестве параметра. Перечислим переменные окружения:
kubectl exec $POD_NAME env
Опять же, стоит отметить, что название самого контейнера может быть опущен в данном случае, потому что у нас есть только один контейнер в Pod.
Далее давайте начнем bash-сессию в контейнере Pod'а:
kubectl exec -ti $POD_NAME bash
Теперь мы имеем открытую консоль на контейнере, где мы запусти наше NodeJS-приложение. Исходный код приложения находится в файле server.js:
cat server.js
Вы можете проверить, что приложение запущено, запустив следующую curl-команду:
curl localhost:8080
Примечание: здесь мы использовали Localhost, потому что мы выполнили команду внутри контейнера с NodeJS.
Чтобы закрыть подключение наберите exit.
Несмотря на то, что Pod'ы имеют свой собственный уникальный IP-адрес в пределах кластера, эти IP-адреса, не выставлены снаружи Kubernetes. Принимая во внимание, что с течением времени Pod'ы могут быть остановлены, удалены или заменены другими Pod'ами, нам нужен способ, чтобы другие Pod'ы и приложения автоматически обнаруживали друг друга. Kubernetes решает эту проблему путем группировки Pod'ов в Services (службы, или сервисы). Сервис Kubernetes представляет собой слой абстракции, который определяет логическое множество Pod'ов и позволяет получать трафик извне, балансировать нагрузку и обеспечивает обнаружение служб для этих Pods.
Эта абстракция позволит нам выставить Pods для трафика, приходящего извне кластера. Сервисы имеют свой собственный уникальный приватный IP-адрес в кластере и выставляют порт для получения трафика. Если вы решили выставить службу за пределы кластера, имеются следующие варианты:
- LoadBalancer - предоставляет публичный IP-адрес (то, что вы обычно используете при запуске Kubernetes на GKE или AWS)
- NodePort - выставляет службу на тот же порт на каждой Node кластера. используя NAT (доступно на всех кластерах Kubernetes, и в Minikube)
Сервис обеспечивает балансировку нагрузки трафика для содержащихся в ней Pod'ов. Это полезно, когда сервис создается, чтобы сгруппировать все Pods от конкретного Deployment (наше приложение воспользуется этим в следующем модуле, когда у нас будет несколько работающих экземпляров приложения).
Сервисы также отвечают за обнаружение сервисов в рамках кластера (рассматривается в модуле 6). Например, это может позволить фронтенд-сервису (например, веб-серверу), получать трафик от бэкенд-службы (например, базы данных), не беспокоясь о Pods.
Сервисы группируют наборы Pods с помощью Label Selectors (селекторы меток), примитива для группировки, который позволяет логические операции на Labels (метках).
Вы можете создать Service при запуске Deployment путем добавления параметра --expose для команды kubectl run.
Labels (метки) это пары ключ/значение, которые присоединены к объектам, таким как Pods, и вы можете думать о них как о хештегах из социальных медиа. Они используются для организации связанных объектов удобным для пользователей образом, например:
- Окружение (production, test, dev)
- Версия приложения (beta, v1.3)
- Тип сервиса/сервера (frontent, backend, база данных)
Метки могут быть прикреплены к объектам в момент создания или позже, и могут быть изменены в любое время. Команда kubectl run устанавливает некоторые метки/селекторы меток по умолчанию на свежесозданных Pods/Deployments. Связь между метками и селекторами меток определяет отношения между Deployments и Pods, которые он создает.
Давайте теперь выставим наше приложение с помощью служб, и применить некоторые новые метки.
Давайте проверим, что наше приложение работает. Мы будем использовать команду kubectl get и искать существующие Pods:
kubectl get pods
Теперь давайте получим список текущих сервисов из нашего кластера:
kubectl get services
У нас есть сервис под названием kubernetes, который создается по умолчанию при запуске minikube-кластера. Для того, чтобы создать новую службу и выставить её на внешний трафик мы будем использовать команду expose с параметром NodePort (minikube пока что не поддерживает опцию LoadBalancer)
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
Снова запустим команду get services:
kubectl get services
Теперь у нас работает служба под названием kubernetes-bootcamp. Здесь мы видим, что служба получила уникальный кластерный IP, внутренний порт и внешний IP (IP ноды, Node IP).
Чтобы выяснить, какой порт был открыт снаружи (с помощью опции NodePort) мы выполним команду describe service:
kubectl describe services/kubernetes-bootcamp
Создадим переменную окружения с именем NODE_PORT, которая в качестве значения будет зранить порт ноды (NodePort):
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Теперь мы можем проверить, что приложение выставлено наружу кластера с использованием curl, IP ноды, и выставленного наружу порта:
curl host01:$NODE_PORT
И мы получим ответ от сервера. Сервис выставлен.
Примечание: В случае, если вы используете minikube на VirtualBox, и выполняете curl на хост системе, то скорее всего host01 не отрезолвится. Для того, чтобы выполнить запрос, выясните IP виртуальной машины в сети хостовой машины и сделайте запрос по IP.
Deployment автоматически создал метку для нашего Pod. С помощью команды describe deployment вы можете увидеть имя метки:
kubectl describe deployment
Используем эту метку для получения списка наших Pods. Мы будем использовать команду get pods с параметром -l, за которым следуют значения меток:
kubectl get pods -l run=kubernetes-bootcamp
Вы можете сделать то же самое, чтобы получить список сервисов:
kubectl get services -l run=kubernetes-bootcamp
Получите имя Pod'а и сохраните его в переменной окружения POD_NAME:
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME
Чтобы задать новую метку, мы используем команду label, за которой следует тип объекта, имя объекта и новая метка:
kubectl label pod $POD_NAME app=v1
Это применит новую метку к нашему Pod (мы прикрепили версию приложения к Pod), и мы можем проверить его с помощью команды describe pods:
kubectl describe pods $POD_NAME
Здесь мы видим, что метка теперь приложена к нашему Pod. И мы можем запросить теперь список Pods, помеченных новой меткой:
kubectl get pods -l app=v1
И мы видим Pod.
Удаление службы. Это можно осуществить с помощью команды delete service. Здесь также можно использовать метки:
kubectl delete service -l run=kubernetes-bootcamp
Подтвердим, что сервиса больше нет:
kubectl get services
Это подтверждает, что наш сервис был удален. Для подтверждения того, что маршрут больше не выставлен наружу, вы можете воспользоваться curl на ранее выставленные IP и порт:
curl host01:$NODE_PORT
Это доказывает, что приложение больше не доступно за пределами кластера. Вы можете подтвердить, что приложение все еще работает, используя curl внутри Pod:
kubectl exec -ti $POD_NAME curl localhost:8080
Так мы увидим, что приложение работает.
В предыдущих модулях мы создали Deployment, а затем выставили его публично через сервис. Deployment создал только один Pod для запуска нашего приложения. При увеличении трафика, нам нужно будет масштабировать приложение, чтобы не отставать от спроса со стороны пользователей.
Масштабирование осуществляется путем изменения количества копий (replicas) в Deployment.
Вы можете с самого начала создать Deployment с несколькими экземплярами с помощью параметра --replicas для команды kubectl run.
Масштабирование осуществляется путем изменения количества копий (replicas) в Deployment.
При масштабировании вверх, Deployment удостоверится, что новые Pods будут созданы и назначены на ноды с имеющимися ресурсами. Масштабирование вниз приведет к сокращению числа Pods к новому желаемому состоянию. Kubernetes также поддерживает авто-масштабирование Pods, но это выходит за рамки данного руководства. Масштабирование до нуля также возможно, и оно отменит все Pods указанного Deployment.
Запуск нескольких экземпляров приложения потребует способ распределения трафика на каждый из них. Сервисы имеют встроенный балансировшик нагрузки, который будет распределять сетевой трафик на все Pods выставленного Deployment. Сервисы будут постоянно контролировать запущенные Pods, используя endpoints, чтобы удостовериться, что трафик посылается только в доступные Pods.
Как только у вас появилось несколько экземпляров запущенного приложения, вы можете делать постоянные обновления без простоев. Мы рассмотрим это в следующем модуле. Теперь, давайте вернемся к терминалу и масштабируем наше приложение.
Выведем список всех Deployments:
kubectl get deployments
У нас есть 1 Pod:
DESIRED (желаемое) состояние показывает настроенное количество реплик.
CURRENT (текущее) состояние показывают, сколько реплик работает прямо сейчас.
UP-TO-DATE (актуальное) состояние показывает количество копий, которые были обновлены в соответствии с желаемым (сконфигурированным) состоянием.
AVAILABLE (доступное) состояние показывает, сколько реплик на самом деле являются доступными для пользователей.
Далее, давайте масштабируем Deployment до 4 реплик. Мы будем использовать команду kubectl scale, за которым следует тип Deployment, имя и желаемое количество экземпляров:
kubectl scale deployments/kubernetes-bootcamp --replicas=4
Чтобы отобразить список ваших Deployments еще раз, выполните:
kubectl get deployments
Изменения были применены, и нам доступно 4 экземпляра приложения. Далее, давайте проверим, изменилось ли число Pods:
kubectl get pods -o wide
Теперь есть 4 Pods, с разными IP-адресами. Изменение было зарегистрировано в журнале событий Deployment. Для проверки, используйте команду describe:
kubectl describe deployments/kubernetes-bootcamp
Вы также можете просмотреть в выводе этой команды, что есть 4 реплики в настоящее время.
Балансировка нагрузки. Давайте проверим, что сервис балансирует нагрузку. Чтобы выяснить выставленный IP-адрес и порт, мы можем использовать describe service, как мы узнали в предыдущем модуле:
kubectl describe services/kubernetes-bootcamp
Создадим переменную окружения с именем NODE_PORT, которая в качестве значения будет зранить порт ноды (NodePort):
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Далее, мы сделаем curl к выставленному IP и порту. Выполните команду несколько раз:
curl host01:$NODE_PORT
Мы попадали на различные Pod с каждым запросом. Это свидетельствует о том, что балансировка нагрузки работает.
Для масштабирования сервиса вниз до 2 реплик, снова запустите команду scale:
kubectl scale deployments/kubernetes-bootcamp --replicas=2
Отобразмите список Deployments, чтобы проверить, что изменение было применено:
kubectl get deployments
Число копий уменьшилось до 2. Выведите список Pods:
kubectl get pods -o wide
Это подтверждает, что 2 Pods были остановлены.
Пользователи ожидают, что приложения будут доступны все время, а разработчики ожидают, что могут развертывать новые его версии несколько раз в день. В Kubernetes это делается с помощью непрерывных обновлений. Непрерывные обновления позволяют Deployments происходить с нулевым временем простоя посредством постепенного обновления Pods новыми экземплярами. Новые Pods будут назначены на Nodes со свободными ресурсами.
В предыдущем модуле мы масштабировали наше приложение, запуская несколько экземпляров. Это необходимо для выполнения обновления, не влияя на доступность приложения. По умолчанию, максимальное количество Pods, которые могут быть недоступны во время обновления, и максимальное число новых Pods, которые могут быть созданы, равны одному. Оба варианта могут быть заданы как числами, так и в процентах (от количества Pods). В Kubernetes, обновление версионировано и любое обновление Deployment может быть возвращено к ранее (стабильной) версии.
Резюме: непрерывные обновления позволяют обновлять Deployments с нулевым временем простоя посредством постепенного обновления Pod'ов новыми экземплярами.
Подобно ситуации при масштабировании приложения, если Deployment выставлен публично, во время обновления сервис будет балансировать трафик только на доступные Pods. Доступный считается тот экземпляр Pod, который доступен для пользователей приложения.
Непрерывные обновления позволяют сделать следующие действия:
- Сменить окружение приложения из одного в другое (через обновление образа контейнера)
- Откат к предыдущим версиям
- Непрерывная интеграция и непрерывная доставка приложений с нулевым временем простоя
В следующем интерактивном учебном пособии мы обновим наше приложение до новой версии, а также выполним откат.
Шаг 1: обновляем версию приложения. Выведем список Deployments:
kubectl get deployments
Выведем список Pods:
kubectl get pods
Для просмотра текущей версии образа приложения, запустите команду describe на Pod'ах (смотрете на поле Image (образ)):
kubectl describe pods
Для обновления образа приложения до версии 2, используйте команду set image, после которой должны идти имя Deployments и новой версии образа:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
Команда уведомила Deployment, что надо использовать другой образ для вашего приложения и инициировала непрерывное обновление. Проверьте состояние новых Pods, а также просмотрите старые завершающиеся с помощью команды get pods:
kubectl get pods
Шаг 2: проверим обновление. Сперва, давайте проверим, что приложение работает. Чтобы выяснить выставленный IP и порт мы можем использовать команду describe service:
kubectl describe services/kubernetes-bootcamp
Создадим переменную окружения с именем NODE_PORT, которая в качестве значения будет зранить порт ноды (NodePort):
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Далее, мы сделаем curl к выставленному IP и порту:
curl host01:$NODE_PORT
С каждым запросом мы попадаем на различные Pod, и мы видим, что все Pods установлена последняя версия (v2).
Обновление может быть подтверждено также выполнение команды rollout status:
kubectl rollout status deployments/kubernetes-bootcamp
Для просмотра текущей версии образа приложения, запустите команду describe на Pods:
kubectl describe pods
Теперь у нас запущена версия 2 приложения (смотреть на поле Image (образ)).
Шаг 3: Отмена обновления. Давайте выполним еще одно обновление, и развернем образ, помеченный v10:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v10
И что-то не так ... У нас нет нужного количества доступных Pods. Отобразим снова список Pods:
kubectl get pods
Команда describe на Pods должна дать больше понимания:
kubectl describe pods
В репозитории нет образа, помеченного v10. Давайте откатим к нашей ранее рабочей версии. Мы будем использовать команду rollout undo:
kubectl rollout undo deployments/kubernetes-bootcamp
Команда rollout undo вернула Deployment к предыдущему известному состоянию (образ версии v2). Обновления версионируются и вы можете вернуться к любому ранее известному состоянию Deployment. Снова покажем список Pods:
kubectl get pods
Два Pods работают. Проверьте еще раз какой образ развернут в них:
kubectl decribe pods
Мы видим, что Deployment использует стабильную версию приложения (v2). Откат был успешным.
Прочитать первый Pod:
kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | sed -n '1p'
Примечание: если в вышеприведенной команде вместо sed использовать head, то может возникнуть ошибка.
error: error executing template "{{range .items}}{{.metadata.name}}{{\"\\n\"}}{{end}}": write /dev/stdout: The pipe is being closed.
Прочитаем в переменную POD_NAME имя Pod, в чьем имени есть example:
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep example)
Прочитаем какой-либо существующий ресурс Kubernetes в yaml-файл:
kubectl get -o yaml > example.yaml deployments/example
Создадим Deployment из файла:
kubectl create -f /tmp/example.yaml