Контейнеры, несомненно, стали технологическим модным словом в последние годы. Появление и расцвет технологий контейнеризации, а также порождённые ими микросервисная архитектура, DevOps и облачные концепции, оказали глубокое влияние на индустрию программного обеспечения.
Контейнеры предлагают множество преимуществ. Их всесторонняя инкапсуляция, удобное развёртывание, лёгкий запуск и планирование способствовали их широкому распространению. В сочетании с системами оркестрации контейнеры упрощают управление приложениями и их итерацию, независимо от сложности системы. Более того, контейнеризированные приложения обладают отличной переносимостью и беспрепятственно работают в любой среде, где есть совместимый со стандартами runtime для контейнеров.
Лёгкие контейнеры и эластичные облачные вычисления идеально дополняют друг друга. Адаптируемость контейнеров к различным средам выполнения и их быстрый запуск в сочетании с масштабируемостью ресурсов за счёт динамического расширения облака позволяют облачным контейнеризированным приложениям масштабироваться до тысяч экземпляров за короткое время. Поэтому облако является идеальной платформой для контейнеризированных приложений, облегчая их выполнение и расширение.
До того как Docker получил широкое признание, облачные провайдеры уже исследовали и использовали технологии, подобные контейнерам. Мультитенантная природа облака требует изоляции окружений, поэтому облачные провайдеры являются как пользователями, так и бенефициарами контейнеризации. Некоторые из них выбирали собственные решения, но не все напрямую приняли Docker.
Например, AWS Elastic Beanstalk использовал частную технологию, похожую на контейнеры, для изоляции веб-приложений. Впоследствии была добавлена поддержка приложений, упакованных как Docker-контейнеры.
С ростом популярности Docker все крупные публичные облачные провайдеры единогласно начали предлагать стандартизированные PaaS-сервисы, связанные с контейнерами, и постоянно их совершенствовать. Прослеживая эволюцию контейнерных PaaS, можно выделить чёткие этапы развития.
Первоначально облачные контейнерные платформы сосредотачивались на бесперебойном запуске Docker-контейнеров в облаке. Эти сервисы в основном помогали пользователям создавать кластеры базовых виртуальных машин, снимая бремя ручного управления виртуальными машинами. Однако по мере усложнения контейнеризированных приложений возникла насущная потребность в оркестрации. В результате вендоры внедрили и усилили свои решения для оркестрации контейнеров.
В эпоху конкурирующих фреймворков оркестрации некоторые вендоры применяли многовекторный подход. Например, Azure Container Service от Microsoft поддерживал Docker Swarm, Apache Mesos (DC/OS) и Kubernetes. Другие, как AWS с сервисом Elastic Container Service (ECS), выбирали собственные методы оркестрации для улучшения интеграции с существующими облачными сервисами.
Как известно, Kubernetes одержал победу в борьбе фреймворков оркестрации, став де-факто стандартом. Облачные провайдеры быстро переключились, уделяя первостепенное внимание поддержке Kubernetes в облаке и запуская специализированные сервисы, такие как AWS Elastic Kubernetes Service (EKS) и Azure Kubernetes Service (AKS). Аналогично, Alibaba Cloud постепенно прекратила поддержку Swarm в своём контейнерном сервисе, сосредоточившись на редакции Kubernetes (ACK).
Облачная поддержка контейнерных технологий развивалась параллельно с экосистемой контейнеров, причём облачные провайдеры играли значительную роль как участники и посредники. Например, Google Kubernetes Engine (GKE) в Google Cloud, будучи «рождённым и выросшим» в этой экосистеме, всегда задавал стандарт для облачных сервисов Kubernetes.
Облачные сервисы Kubernetes предлагают несколько явных преимуществ по сравнению с самостоятельно развёрнутыми кластерами Kubernetes.
Во-первых, из-за мультитенантной природы облака многие облачные сервисы Kubernetes устраняют необходимость предоставления Master-узлов. Пользователям нужно только создавать и оплачивать Worker-узлы, а облачная платформа предоставляет и управляет Master-узлами, уменьшая потребление ресурсов и операционные расходы.
Во-вторых, несмотря на свою сложность, Kubernetes обладает исключительным абстрактным дизайном, который позволяет выполнять обширные и гибкие расширения. Облачные провайдеры вложили значительные средства в эту область, что позволяет различным компонентам IaaS и PaaS на их платформах легко интегрироваться в экосистему Kubernetes, обеспечивая более тесную интеграцию.
Например, в области Ingress Controller, обычно используемых для направления внешнего трафика, существуют реализации облачных балансировщиков нагрузки, такие как AWS ALB Ingress Controller и Azure AKS Application Gateway Ingress Controller. Эти контроллеры создают соответствующие экземпляры PaaS-сервисов для обслуживания кластера Kubernetes.
Кроме того, на уровне StorageClass, где в Kubernetes определяются политики динамического выделения томов хранения, можно указать использование облачных сервисов блочного хранения для предоставления и монтирования постоянного хранилища по требованию.
С точки зрения гибкости архитектуры, облачные сервисы Kubernetes вводят ещё одно преимущество: развёртывание нескольких кластеров.
Поскольку барьер для создания кластеров Kubernetes снизился, если между бизнес-подразделениями существует минимальная взаимозависимость, для каждого подразделения можно создать отдельный кластер Kubernetes. Такой подход повышает изоляцию и позволяет независимо масштабировать различные кластеры.
От Docker до Kubernetes — непрерывная эволюция экосистемы контейнеров привела к волне облачных технологий (cloud-native). Разработчики не одиноки в своём стремлении изучать и внедрять контейнерные технологии. Поставщики облачных вычислений также соревнуются за позиционирование себя как оптимальных платформ для запуска контейнеров, представляя множество сервисов, связанных с контейнерами, чтобы привлечь пользователей контейнеров в свои облака.
Интересно, что между контейнерами и некоторыми активно продвигаемыми облачными сервисами существует тонкая взаимосвязь. Присутствует элемент конкуренции и замещения.
Подобно тому, как некоторые функции PaaS могут быть воспроизведены с помощью IaaS, контейнеры с их исключительной свободой сборки и удобными механизмами упаковки и развёртывания могут частично заменить определённые многократно используемые компоненты внутри облака. Более того, контейнеры можно оркестрировать как часть более крупной системы, что служит средством снижения зависимости от конкретного вендора.
Несмотря на потенциальную угрозу, которую контейнеры представляют для некоторых облачных сервисов, облачные вычисления в очередной раз продемонстрировали свою технологическую нейтральность. Облачные платформы открыто приняли и поддержали выполнение контейнеров, даже обозначив их как ключевые сервисы для разработки. Предоставление пользователям выбора олицетворяет инклюзивность облака.
Novita AI — это универсальная облачная платформа, которая расширяет ваши AI-амбиции. Интегрированные API, бессерверные вычисления, GPU-инстансы — экономически эффективные инструменты, которые вам нужны. Избавьтесь от инфраструктуры, начните бесплатно и воплотите своё AI-видение в реальность.
Рекомендуемое чтение:
