Имея дело с контейнерными приложениями, мы могли бы захотеть узнать, какую роль в этом контексте играют Docker Compose и Kubernetes.
В этом руководстве мы обсудим некоторые из наиболее распространенных вариантов использования, чтобы увидеть разницу между ними.
Docker Compose — это инструмент командной строки для запуска нескольких контейнеров Docker с определением шаблона YAML. Мы можем создавать контейнеры из существующих изображений или определенного контекста.
В этом руководстве мы рассмотрим, как развернуть бессерверную рабочую нагрузку на платформе Kubernetes. Мы будем использовать Knative в качестве основы для выполнения этой задачи. В процессе мы также узнаем о преимуществах использования Knative в качестве фреймворка для наших бессерверных приложений .
Разработка бессерверного приложения без вспомогательных инструментов — это не весело! Помните, как сочетание Docker и Kubernetes изменило управление облачными приложениями, созданными с помощью архитектуры микросервисов. Конечно, мы можем извлечь выгоду из фреймворков и инструментов и в бессерверном пространстве. Что ж, нет никаких причин, по которым Kubernetes не может нам здесь помочь.
В этом руководстве мы поймем основные потребности в системе оркестрации контейнеров.
Оценим желаемую характеристику такой системы. Исходя из этого, мы попытаемся сравнить две самые популярные системы оркестрации контейнеров, используемые сегодня, Apache Mesos и Kubernetes .
Прежде чем мы начнем сравнивать Mesos и Kubernetes, давайте потратим некоторое время на то, чтобы понять, что такое контейнеры и зачем нам все-таки нужна оркестрация контейнеров.
Helm — это менеджер пакетов для приложений Kubernetes . В этом руководстве мы разберемся с основами Helm и узнаем, как они образуют мощный инструмент для работы с ресурсами Kubernetes.
За последние годы Kubernetes значительно вырос, как и поддерживающая его экосистема. Недавно Helm получил статус выпускника от Cloud Native Computing Foundation (CNCF) , что свидетельствует о его растущей популярности среди пользователей Kubernetes.
Хотя эти термины довольно распространены в наши дни, особенно среди тех, кто работает с облачными технологиями, давайте быстро пройдемся по ним для тех, кто не знает:
Поработав какое-то время с Kubernetes, мы скоро поймем, что здесь задействовано много шаблонного кода. Даже для простого сервиса нам нужно предоставить все необходимые данные, обычно в форме довольно подробного документа YAML.
Кроме того, при работе с несколькими службами, развернутыми в данной среде, эти документы YAML, как правило, содержат много повторяющихся элементов. Например, мы можем захотеть добавить данный ConfigMap или некоторые контейнеры sidecar во все развертывания.
В этой статье мы рассмотрим, как мы можем придерживаться принципа DRY и избежать всего этого повторяющегося кода, используя контроллеры доступа Kubernetes.
Kubernetes (K8s) — это система оркестрации контейнеров с открытым исходным кодом. Это позволяет нам автоматизировать развертывание, масштабирование и управление контейнерными приложениями.
В этом руководстве мы обсудим два разных способа развертывания нашего приложения (модулей) в Kubernetes с использованием разных ресурсов Kubernetes. Ниже приведены два разных ресурса, которые Kubernetes предоставляет для развертывания модулей:
Давайте начнем с рассмотрения разницы между приложением с сохранением состояния и приложением без сохранения состояния.
При работе с Kubernetes нам не хватает инструмента, помогающего в локальной разработке — инструмента, который может запускать локальные кластеры Kubernetes, используя контейнеры Docker в качестве узлов.
В этом руководстве мы изучим Kubernetes с видом. В первую очередь инструмент тестирования для Kubernetes, kind также удобен для локальной разработки и CI.
В качестве предварительного условия мы должны убедиться, что Docker установлен в нашей системе. Самый простой способ установить Docker — использовать Docker Desktop , подходящий для нашей операционной системы (и процессора в случае macOS).
В этом руководстве мы продолжим изучение Java Kubernetes API. На этот раз мы покажем, как использовать часы для эффективного мониторинга событий кластера.
В наших предыдущих статьях, посвященных Kubernetes API , мы показали, как восстановить информацию о заданном ресурсе или их наборе. Это нормально, если все, что нам нужно, — это получить состояние этих ресурсов в определенный момент времени. Однако, учитывая, что кластеры Kubernetes очень динамичны по своей природе, этого обычно недостаточно.
Чаще всего мы также хотим отслеживать эти ресурсы и отслеживать события по мере их возникновения . Например, нас может заинтересовать отслеживание событий жизненного цикла модуля или изменений состояния развертывания. Хотя мы могли бы использовать опрос, этот подход имел бы несколько ограничений. Во-первых, это не будет хорошо масштабироваться по мере увеличения количества ресурсов для мониторинга. Во-вторых, мы рискуем потерять события, происходящие между циклами опроса.
В этом руководстве мы рассмотрим операции CRUD с ресурсами Kubernetes с использованием официального Java API.
Мы уже рассмотрели основы использования этого API в предыдущих статьях, включая базовую настройку проекта и различные способы его использования для получения информации о работающем кластере.
Как правило, развертывания Kubernetes в основном статичны. Мы создаем некоторые артефакты (например, файлы YAML), описывающие то, что мы хотим создать, и отправляем их в конвейер DevOps. Затем части нашей системы остаются неизменными, пока мы не добавим новый компонент или не обновим существующий.
Однако бывают случаи, когда нам нужно добавлять ресурсы на лету. Распространенным является запуск заданий в ответ на запрос, инициированный пользователем. В ответ приложение запускало фоновое задание для обработки отчета и делало его доступным для последующего извлечения.
Ключевым моментом здесь является то, что, используя эти API, мы можем лучше использовать доступную инфраструктуру, поскольку мы можем потреблять ресурсы только тогда, когда они необходимы, а затем освобождать их.
В этом руководстве мы рассмотрим различные способы фильтрации ресурсов с помощью Java API Kubernetes.
В наших предыдущих статьях, посвященных Kubernetes Java API, мы сосредоточились на доступных методах запроса, управления и мониторинга ресурсов кластера.
В этих примерах предполагалось, что мы либо искали ресурсы определенного типа, либо нацеливались на один ресурс. На практике, однако, большинству приложений требуется способ обнаружения ресурсов на основе некоторых критериев.
API Kubernetes поддерживает три способа ограничения области поиска: