Облачная платформа

К разделу «Облачная платформа

Облачные ресурсы IaaS
Облачные ресурсы IaaS
Облачная платформа на базе собственных дата-центров уровня TIER III
Ускоренные вычисления на базе NVIDIA GPU
Ускоренные вычисления на базе NVIDIA GPU
Для сложных вычислений, машинного обучения и обработки видео/3D-графики
Частное облако
Частное облако
Защищенное частное облако (УЗ-1, К-1, лицензии ФСБ и ФСТЭК)
Кластеры Kubernetes
Кластеры Kubernetes
Развертывание, масштабирование, репликация и мониторинг контейнерных приложений
Защищенное облако 152-ФЗ
Защищенное облако 152-ФЗ
Размещение конфиденциальных данных в защищенной инфраструктуре и аудит работы с персональными данными
Резервное копирование для бизнеса
Резервное копирование для бизнеса
Автоматизированное управление резервными копиями виртуальных машин и баз данных
База данных в облаке
База данных в облаке
Управляемые СУБД с масштабированием по мере необходимости и высоким SLA
Миграция в облако Linx Cloud
Миграция в облако Linx Cloud
Перенос IT-инфраструктуры в облако Linx Cloud из других платформ
Объектное хранилище S3
Объектное хранилище S3
Защищенное объектное хранилище S3 по стандартам 152-ФЗ на платформе Linx Cloud
Облако для ВУЗов
Облако для ВУЗов
25% скидка на облачные сервисы от цены прайса на год!
Безопасность

К разделу «Безопасность

Статический анализ исходного кода SAST
Статический анализ исходного кода SAST
Облачный сервис для защиты приложений на этапе разработки исходного кода
Двухфакторная аутентификация MFA
Двухфакторная аутентификация MFA
Удаленный доступ – легко и безопасно. Сервис MFA подходит для любого типа инфраструктуры
Облачная защита WAF + AntiDDoS
Облачная защита WAF + AntiDDoS
Многоуровневая защита интернет-ресурсов и веб-приложений с минимальными вложениями
Аварийное восстановление в AWS
Аварийное восстановление в AWS
Быстрое и экономичное восстановление данных и приложений. RPO — секунды, RTO — минуты
DRaaS — аварийное восстановление
DRaaS — аварийное восстановление
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Межсетевой экран нового поколения NGFW
Межсетевой экран нового поколения NGFW
Виртуальный межсетевой экран нового поколения для комплексной защиты ресурсов в облаке
Антивирус
Антивирус
Защита инфраструктуры от вирусов и шифровальщиков
Сканирование на уязвимости
Сканирование на уязвимости
Мониторинг и оценка уязвимостей ИТ-инфраструктуры
Security Operations Center (SOC)
Security Operations Center (SOC)
Центр противодействия кибератакам на любом этапе инцидента
ГОСТ-VPN
ГОСТ-VPN
Защищенный канал связи для ИСПДн
Межсетевой экран
Межсетевой экран
Защита сети компании от несанкционированного доступа извне
Аттестация частного облака для ГИС
Аттестация частного облака для ГИС
Размещение госинформационных систем «под ключ» с соблюдением К1 и УЗ-1 (ИСПДн)
Security Awareness
Security Awareness
Обучение сотрудников навыкам информационной безопасности на базе онлайн-платформы
Тарифы База знаний
Облако
Деплой приложений через API

Деплой приложений через API

Развертывание приложения в Kubernetes (k8s) осуществляется с помощью утилиты kubectl. Полный синтаксис команд утилиты можно найти в официальной документации.

Подготовка

Kubectl работает в командной строке или терминале.


Убедиться что kubectl установлен можно при помощи команды:





                    

Общий формат команды kubectl: kubectl action resource (kubectl -> действие -> сущность, на которую направлено действие)


Эта последовательность команд выполняет указанное действие (например, создание, описание) для указанного ресурса (например, узла, контейнера). Можно использовать —help после команды, чтобы получить дополнительную информацию о возможных параметрах, например





                    

Перед выполнением работы на кластере необходимо подключиться к нему, предварительно импортировав конфигурационный файл, загруженный при создании кластера:





                    

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





                    

В ответ должно получиться примерно следующее:


Просмотреть узлы в кластере можно при помощи команды:





                    

Должно получиться примерно следующее:





                    

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

Развертывание приложений

Развернем первое приложение в Kubernetes с помощью команды kubectl create deployment. Нужно указать имя развертывания и расположение образа приложения.





                    

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

  • поиск подходящего узла, на котором можно было бы запустить экземпляр приложения
  • планирование запуска приложения на этом узле
  • настройка кластера, чтобы при необходимости запустить экземпляр на новом узле

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





                    

Результатом выполнения команды будет:





                    

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

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

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


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


Следующим шагом запустим прокси в новом окне командной строки или терминала:





                    

Затем нужно выполнить команду kubectl proxy:





                    

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


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

curl https://localhost:8001/version

Результатом вывода команды будет:





                    

Если порт 8001 недоступен, необходимо убедиться, что прокси kubectl запущен.


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


Сначала нужно получить имя Pod, и сохранить в переменной окружения POD_NAME:





                    

Должно получиться примерно следующее:





                    

Примечание


Прокси-сервер запускался в новой вкладке (Терминал 2), а последние команды выполнялись на исходной вкладке (Терминал 1). Прокси-сервер по-прежнему работает на второй вкладке, и это позволило команде curl работать с использованием localhost: 8001

Было полезно?

Остались вопросы?

Опишите вашу задачу, и мы поможем вам ее решить

Или напишите нам info@linxdatacenter.com
Нажимая кнопку «Отправить», вы соглашаетесь с Политикой обработки персональных данных ООО «Связь ВСД»