Использование kubectl для развёртывания приложения

Узнайте про деплойменты приложения. Разверните первое приложение в Kubernetes с помощью kubectl.

Цели

  • Узнать про деплойменты приложения
  • Развернуть первое приложение в Kubernetes с помощью kubectl

Deployments в Kubernetes

Как только вы запустили кластер Kubernetes, вы можете развернуть на нём свои контейнеризированные приложения. Для этого вам нужно создать деплоймент (Deployment). Deployment в Kubernetes определяет, как создавать и обновлять экземпляры вашего приложения. После создания деплоймента control plane в Kubernetes запланирует запуск экземпляров приложения на отдельных узлах в кластере.

После того, как экземпляры приложения были созданы, контроллер деплойментов Kubernetes будет непрерывно отслеживать их. Если узел, на котором размещен экземпляр, вышёл из строя или был удалён, контроллер деплойментов заменит этот экземпляр экземпляром на другом узле в кластере. Этот процесс представляет собой механизм самовосстановления, обеспечивающий работу кластера в случае возникновения аппаратных неисправностей либо технических работ.

До того, как появились системы оркестровки, для запуска приложений обычно использовались установочные скрипты, которые не перезапускались после сбоя компьютера. Создавая экземпляры приложений и поддерживая их работу на нескольких узлах, деплойменты Kubernetes используют принципиально другой подход к управлению приложениями.

Краткое содержание:

  • Деплойменты
  • Kubectl

Deployment отвечает за создание и обновление экземпляров приложения


Развёртывание вашего первого приложения на Kubernetes


Вы можете создавать и управлять деплойментами через консольный инструмент Kubernetes под названием kubectl. Kubectl использует Kubernetes API для работы с кластером. В этом модуле вы узнаете про наиболее используемые команды kubectl, необходимые для создания деплойментов, которые будут запускать приложения в кластере Kubernetes.

При создании развертывания нужно указать образ контейнера приложения и количество запущенных реплик. Впоследствии эти параметры можно изменить. В модулях 5 и 6 рассказывается про масштабирование и обновление деплойментов.

Чтобы приложение запускалось в Kubernetes, оно должно быть упаковано в один из поддерживаемых форматов контейнеров

Для своего первого деплоймента возьмём приложение hello-node, упакованное в Docker-контейнер и использующее NGINX, чтобы выводить на экран все запросы. (Если вы ещё не пробовали создавать приложение hello-node и деплоить контейнер с ним, можете сначала выполнить инструкции из руководства "Привет, Minikube").

Вам также потребуется установленная утилита kubectl. По вопросам её инсталляции см. Установку инструментов.

Теперь, когда понятие деплойментов вам знакомо, давайте задеплоим первое приложение!


Основы kubectl

Общий формат команд kubectl выглядит так: kubectl действие ресурс

Эта команда выполнит указанное действие (например, create, describe или delete) с указанным ресурсом (например, node или deployment). Можно воспользоваться справкой через флаг --help после подкоманды, чтобы получить дополнительные сведения о возможных параметрах (например: kubectl get nodes --help).

Убедитесь, что kubectl настроена на подключение к вашему кластеру, выполнив команду kubectl version.

Убедитесь, что kubectl установлена и вы можете увидеть версию и у клиента, и у сервера.

Чтобы увидеть список узлов кластера, выполните команду kubectl get nodes.

Вы увидите доступные узлы. Позже Kubernetes выберет, куда задеплоить ваше приложение, руководствуясь данными о доступных узлах.

Деплой приложения

Давайте развернём первое приложение в Kubernetes с помощью команды kubectl create deployment. Для этого потребуется указать имя деплоймента и путь к образу приложения (используйте полный URL репозитория для образов, которые располагаются вне Docker Hub).

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

Отлично! Создав этот Deployment, вы только что развернули первое приложение. Команда привела к выполнению следующих действий:

  • поиск подходящего узла, на котором можно запустить экземпляр приложения (у нас доступен только 1 узел);
  • планирование (размещение) приложения для запуска на этом узле;
  • настройка кластера на повторное размещение экземпляра на новом узле, когда это потребуется.

Чтобы увидеть список деплойментов, выполните команду kubectl get deployments:

kubectl get deployments

Вы увидите, что есть 1 деплоймент, в котором запущен единственный экземпляр приложения. Этот экземпляр работает в контейнере на узле кластера.

Просмотр приложения

Поды, которые запущены внутри Kubernetes, работают в частной, изолированной сети. По умолчанию они видны для других подов и сервисов того же Kubernetes-кластера, однако не за пределами этой сети. Когда мы используем утилиту kubectl, мы взаимодействуем с нашим приложением через API-эндпоинт.

О других возможностях сделать приложение доступным вне кластера Kubernetes мы расскажем позже, в разделе Открытие доступа к приложению.

Команда kubectl proxy создаст прокси, который перенаправляет взаимодействие в частную сеть, доступную в рамках кластера. Во время своей работы прокси не выводит никаких сообщений, а остановить его можно нажатием на control-C.

Для запуска прокси потребуется открыть второе окно с терминалом.

kubectl proxy

Теперь у нас есть соединение между хостом (терминалом) и Kubernetes-кластером. Прокси обеспечивает прямой доступ к API из терминала.

Через эндпоинт от прокси можно увидеть все API. Например, с помощью curl мы можем напрямую через API узнать версию:

curl http://localhost:8001/version

Сервер API автоматически создаст эндпоинт для каждого пода в соответствии с именем пода, который будет также доступен через прокси.

Для начала узнаем имя пода и сохраним его в переменной окружения 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

Теперь получим доступ к поду через проксированный API, выполнив команду:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

Чтобы новый деплоймент был доступен без использования прокси, потребуется сервис (объект Service), о котором будет рассказано в следующих разделах.

Когда всё готово, переходите к разделу Просмотр подов и узлов.

Изменено December 15, 2024 at 6:24 PM PST: Merge pull request #49087 from Arhell/es-link (2c4497f)