Сегодня мы поговорим о том, о чем слышал почти каждый, но не может объяснить о Кубернетес. Это сбивает с толку, потому что решает проблему, которую большинство людей не замечают, пока не столкнутся с ней. Все знают, что это важно, но спросите, что он делает, и вы получите в ответ пустой взгляд. Это не замена докер или облачная операционная система, хотя люди часто предполагают именно это. Путаница вполне объяснима, потому что Кубернетес решает проблему, о существовании которой вы не знаете, пока не столкнетесь с ней. Это инструмент, который становится незаменимым, когда у вас появляется больше, чем просто несколько контейнеров для управления. К концу этого эпизода вы поймете, что такое Кубернетес на самом деле, как он взаимодействует с контейнерами и почему Azure Кубернетес сервис делает его практичным для команд, которые не хотят создавать все с нуля. Заварите кофе и давайте начнем. Проблема до появления контейнеров.

Вернемся к проблеме. Представьте себе компанию разработчика программного обеспечения 10 лет назад. У вас есть несколько приложений, которые нужно запустить, поэтому вы покупаете серверы, устанавливаете операционные системы и развертываете все вручную. Каждое приложение получает свой собственный сервер, и ресурсы между ними нельзя совместно использовать. Если одному приложению требуется много памяти, а другому почти ничего, то каждому из них все равно нужен свой собственный сервер. Это приводило к огромным потерям ресурсов. Серверы работали, возможно, на 20% мощности, но их нельзя было объединить, потому что приложения конкурировали бы из-за зависимости. В итоге получалась комната, полная серверов, каждый из которых почти ничего не делал, потреблял электроэнергию и охлаждал, и все они требовали постоянного обслуживания. Одному приложению нужен Python 3.7, другому — Python 3.8. Одному нужна более старая библиотека, другому — самая новая. Запустить их на одном компьютере без поломки чего-либо было невозможно, поэтому приходилось покупать больше серверов и платить за оборудование, которое большую часть времени простаивает. Виртуальные машины немного помогли, позволив разделить физический сервер на более мелкие части, каждая из которых работала под управлением своей ОС, но каждая виртуальная машина была тяжелой, с полноценной ОС, которая занимала дисковое пространство и память и запускалась за считанные минуты. И каждую из них нужно было настраивать отдельно, что отнимало много времени.

При этом приходилось управлять всеми этими операционными системами, устанавливать патчи, обновления и обеспечивать их безопасность. Командам требовалось что-то более легкое и портативное, способ упаковать приложение, совсем необходимым для его работы без дополнительных затрат на полноценную виртуальную машину, и чтобы его можно было легко перемещать между машинами. Вот тут-то и пригодились контейнеры. Что же такое контейнеры на самом деле? Контейнер — это небольшой пакет, который включает в себя ваше приложение и все необходимое для его работы. Это означает, что код, среда выполнения, библиотеки и файлы конфигурации — все это объединено в одном блоке. Представьте это как транспортный контейнер для программного обеспечения. Транспортный контейнер может быть отправлен на грузовике, поезде или корабле, а сам контейнер остается неизменным. Ваш программный контейнер работает точно так же. Вы создаете его один раз, и он работает одинаково на вашем ноутбуке, тестовом сервере и в производственной среде. Ключевое различие между контейнерами и виртуальными машинами заключается в их эффективности. Виртуальная машина работает со своей собственной полноценной операционной системой, поэтому каждая ВМ имеет свое ядро, системные файлы и все остальное. Контейнер использует ту же операционную систему, что и хост. Это просто процесс со своим собственным изолированным представлением о мире. Это означает, что контейнеры запускаются за секунды, а не за минуты. Они используют меньше памяти, и вы можете разместить больше контейнеров на одной машине. Докер сделал контейнеры популярными, предоставив разработчикам простой способ создавать и запускать их одной командой.

Внезапно проблема «работает на моей машине» начала исчезать. Если ваше приложение работает в контейнере на вашем ноутбуке, оно будет работать так же и на сервере. Среда везде одинакова, но контейнеры решают одну проблему и создают другую. С небольшим количеством контейнеров ручное управление вполне подходит. Вы можете запускать их, останавливать и отслеживать самостоятельно. Но что происходит, когда у вас сотни контейнеров? Вам нужно решить, на каком сервере работает какой контейнер, перезапустить вышедшие из строя, соединить их друг с другом и масштабировать при резком увеличении трафика. Это новая задача, и именно здесь на помощь приходит Кубернетес. Проблема оркестровки. Итак, у вас работают контейнеры, вы упаковали свое приложение, оно работает стабильно везде, и все хорошо. Но только некоторое время. С 10 или 20 контейнерами вы можете управлять всем вручную. Вы знаете, на каком сервере работает какой контейнер, можете перезапустить что-либо в случае сбоя и обновить кое-что. Это управляемо. Но затем ваше приложение разрастается. Вы переходите на микросервисы. Таким образом, вместо одного большого приложения у вас появляется 20 меньших. Каждому из них требуется несколько работающих копий для обеспечения надежности. И теперь вы имеете дело с двумя стами контейнерами.

Ручное управление больше не работает. Вам нужно решить, на каком сервере работает каждый контейнер, перезапускать контейнеры при сбоях и соединять их для обмена данными. Вам также нужно масштабироваться при пиковых нагрузках, например, во время распродажи или запуска продукта, и уменьшать масштаб, когда ситуация успокаивается. И вам нужно развертывать обновления без простоев, что означает замену старых контейнеров новыми по одному, осторожно, не нарушая ничего. Это проблемы оркестровки, и именно для их решения был создан Кубернетес. Кубернетес — это платформа с открытым исходным кодом, который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Представьте себе это как операционную систему для вашего центра обработки данных. Подобно тому, как Windows или Linux управляют ресурсами на одном компьютере, такими как процессор, память и диск, Кубернетес управляет ресурсами на всех ваших серверах. Он рассматривает все ваши машины как один большой пул вычислительной мощности. Вы указываете, что хотите запустить, а он определяет, где это разместить, как поддерживать его работу и как подключить ко всему остальному. Основные понятия — поды, узлы и кластеры.

Давайте посмотрим, как Кубернетес работает на самом деле. Самая маленькая единица в Кубернетес называется подом. Под — это оболочка одного или нескольких контейнеров. Контейнеры внутри одного пода совместно используют хранилище и сеть, поэтому они могут общаться друг с другом через Localhost. Вы можете рассматривать под как единую единицу развертывания. Вы не развертываете контейнеры напрямую в Кубернетес. Вы развертываете поды. Поды не работают сами по себе, они работают на узлах. Узел — это сервер, физический или виртуальный, который является частью вашего кластера Кубернетес. На каждом узле работает программное обеспечение, необходимое для запуска подов, а также несколько других вещей, о которых мы поговорим чуть позже. Кластер — это совокупность всех узлов, управляемых как единая система. Проще говоря, под — это ваше приложение. Узел — это место, где оно работает, а кластер — это вся среда.

Поды эфемерны. Их можно создавать, уничтожать или перемещать в любое время. Это предусмотрено разработчиками. Если узел выходит из строя, Кубернетес перемещает поды на другой. Для масштабирования он создает новые поды. А когда под выходит из строя, он автоматически заменяется. Вся система рассматривает поды как временные. Но если поды появляются и исчезают, вам нужен способ взаимодействовать с ними. Вместо того, чтобы напрямую взаимодействовать с подом, вы взаимодействуете с сервисом. Сервис предоставляет стабильный сетевой адрес, который направляет трафик к нужным подам, даже когда поды меняются. Представьте себе отель. Номер телефона отеля — это сервис. Номера постоянно меняют гостей, но номер телефона остается неизменным. Вы звоните на ресепшн, и ваш звонок перенаправляется в нужный кабинет. Именно это и делает сервис в Кубернетес. Он предоставляет вам фиксированный адрес, который всегда указывает на те поды, которые в данный момент запускают ваше приложение. Это плоскость управления, мозг кластера. Итак, у вас есть поды, узлы и кластер.

Вопрос в том, кто решает, что где работает. Это задача плоскости управления. В каждом кластере Kubernetes она есть, и это мозг всей системы. Все решения принимаются здесь. Плоскость управления состоит из нескольких компонентов. Первый — это API-сервер, который выступает в качестве входной двери в ваш кластер. Каждая команда, которую вы отправляете в Kubernetes, будь то из командной строки, панели мониторинга или автоматизированного скрипта, проходит через API-сервер. Он аутентифицирует ваш запрос, проверяет, разрешено ли вам делать-то, что вы запрашиваете, а затем передает его в нужное место. В Kubernetes ничего не происходит без предварительного прохождения через API-сервер. Далее идет планировщик, который решает, на каком узле запускается каждый под. Когда вы говорите «я хочу, чтобы это приложение работало», планировщик проверяет все доступные узлы, оценивает имеющиеся ресурсы, такие как ЦП, память и дисковое пространство, и выбирает наиболее подходящие для этой задачи. Это похоже на то, как менеджер отеля распределяет номера в зависимости от потребностей каждого гостя. Гость с большим количеством багажа получает номер побольше, а легковесное приложение – меньший узел с запасом мощности.

Затем есть контроллер-менеджер. Этот компонент следит за кластером и гарантирует, что фактическое состояние соответствует заявленному. Вы сказали, что хотите запустить три копии вашего веб-приложения. Контроллер-менеджер проверяет, действительно ли работают три копии. Если одна из них выходит из строя, он это замечает и запускает замену. Если кто-то случайно удаляет под, он создает новый. Это компонент, который обеспечивает корректную работу кластера. И, наконец, есть ETCD – база данных кластера. Она хранит все, что запущено, где оно запущено и как оно настроено. Это источник достоверной информации для всего кластера. Если API-сервер – это входная дверь, то ETCD – это картотека в бэк-офисе, где хранятся все записи. Прелесть такой архитектуры в том, что вы описываете свои желания, а Кубернетес сам определяет, как их реализовать. Вы не указываете, как что-то делать, вы указываете, как должен выглядеть конечный результат. Это декларативная модель, и это основная идея всего, что делает Кубернетес рабочие нагрузки, развертывание, сервисы и масштабирование. Итак, давайте поговорим о том, как на самом деле запускаются приложения в Кубернетес. Вы не будете создавать поды напрямую. Вместо этого вы будете использовать объект более высокого уровня, называемый развертыванием. Представьте себе развертывание как менеджер, который сообщает Кубернетес, сколько копий вашего пода должно работать, какой образ контейнера использовать и как обновлять их при выходе новой версии. Это стандартный способ запуска приложения без состояния. Когда вы обновляете развертывание, например, отправляете новую версию своего приложения, Кубернетес выполняет скользящее обновление. Он заменяет поды один за другим, гарантируя, что как минимум одна копия всегда работает. Это означает отсутствие простоев и внезапных прерываний для ваших пользователей. А если что-то пойдет не так с новой версией, вы можете откатиться к предыдущей версии одной командой. Это мощная система безопасности. Но ваши поды все еще должны быть доступны. Вот тут-то и вступают в игру сервисы. Сервис предоставляет стабильный сетевой адрес, который направляет трафик к нужным подам. Он также может предоставлять доступ к этим подам другим частям вашего приложения или внешнему миру. Сервис может быть внутренним, доступным только внутри кластера или внешним, с публичным IP-адресом, которому пользователи могут получить доступ из интернета. Теперь о масштабировании. Кубернетес может автоматически увеличивать и уменьшать размер вашего приложения в зависимости от спроса. Вы устанавливаете целевой показатель, скажем, 70% использования ЦП, и Кубернетес добавляет больше подов, когда использование превышает этот порог и удаляет их, когда оно падает. Ваше приложение масштабируется вверх во время пика трафика и обратно вниз, когда все успокаивается. Никакого ручного вмешательства не требуется, но вся эта мощь сопряжена со сложностью. Управление собственным кластером Кубернетес означает, что вы отвечаете за плоскость управления, обновление, исправление безопасности и резервное копирование.

Вам необходимы глубокие знания для обработки сбоев узлов, настройки сети и масштабирования кластера. Многие команды тратят больше времени на управление кластером, чем на разработку приложений. И вот тут на помощь приходит управляемый Кубернетес. Самостоятельное управление против управляемого Кубернетес. Итак, давайте поговорим о реальности самостоятельного управления Кубернетес. Когда вы настраиваете собственный кластер, вы отвечаете за все, плоскость управления, обновление, исправление безопасности и резервное копирование ETCD. Если API-сервер выходит из строя, это ваша проблема. Если в используемой вами версии обнаружена уязвимость безопасности, вам необходимо ее исправить. Если ETCD поврежден, вам необходимо восстановить данные из резервной копии. Все это требует глубоких знаний. Вам необходимо понимать, как выходит из строя узлы, как работает сеть на уровне кластера и как масштабировать систему, не нарушая ее работу.

Вот что удивляет многие команды. Многие организации тратят больше времени на управление кластером Кубернетес, чем на разработку приложений, работающих на немецком. Они постоянно борются с обновлениями, устраняют неполадки в сети и сталкиваются со сбоями узлов. Кластер становится работой на полный рабочий день. Но Кубернетес используется не для этого. Вот тут-то и пригодятся управляемые сервисы Кубернетес. Такие сервисы, как Azure Kubernetes Service, AKS, берут на себя управление плоскостью управления. Azure управляет API-сервером, ETCD, планировщиком и диспетчером контролеров. Вам не нужно беспокоиться об их обновлении или поддержании работоспособности. Вы платите только за рабочие узлы, виртуальные машины, которые фактически запускают ваши рабочие нагрузки. Сама плоскость управления бесплатна. Это кардинально меняет ситуацию. Вместо того, чтобы тратить время на обслуживание кластера, ваша команда может сосредоточиться на действительно важных вещах, приложениях, которые вы разрабатываете. Для большинства команд, особенно начинающих, выбор. Вы получаете всю мощь Кубернетес без операционных издержек. AKS, Кубернетес, упрощенный на Azure. Итак, что же такое AKS? Это управляемая служба Кубернетес от Azure, предоставляющая полнофункциональный кластер без необходимости его создания с нуля. Как мы уже упоминали, управляющая плоскость бесплатна, поэтому вы платите только за виртуальные машины, на которых работают ваши рабочие нагрузки. Это означает, что вы можете начать с малого, платить очень мало и масштабироваться по мере роста ваших потребностей. Azure берет на себя всю основную работу. Обновление, исправление и мониторинг состояние управляющей плоскости, все это обеспечивается автоматически. Вам не нужна специальная команда экспертов по Кубернетес, чтобы поддерживать работу системы. А поскольку AKS является частью экосистемы Azure, он интегрируется с инструментами, которые вы, вероятно, уже используете. Azure Active Directory для аутентификации, Azure Monitor для ведения журналов и сбора метрик и Azure Policy для управления. Все они работают вместе из коробки. Никаких дополнительных компонентов не требуется.

Настройка конвейеров CI, CD с помощью Git Hub Actions или Azure DevOps занимает всего несколько минут. Отправьте изменения в свой репозиторий, и система автоматически создаст новый образ контейнера, загрузит его в Azure Container Registry и обновит ваше развертывание в AKS. Никаких ручных действий, никакого подключения по SSH к серверам. Все автоматизировано. Для начинающих есть автоматический режим AKS, разработанный для команд, которые не хотят принимать все решения по конфигурации кластера. Он предоставляет готовые к использованию настройки по умолчанию для масштабирования сети, безопасности и обновлений. Вам не нужно становиться экспертом по Кубернетес, чтобы начать. Просто опишите свое приложение, и AKS позаботится обо всем остальном. Одна команда создаст кластер, один файл манифеста запустит ваше приложение. Навыки, полученные в AKS, применимы к любой среде Кубернетес, потому что под капотом находится стандартный Кубернетес. Вы изучаете не проприетарную систему, а реальную систему, где Azure берет на себя операционную сложность. Итак, теперь у вас есть общее представление. Контейнеры упаковывают ваше приложение, обеспечивая их стабильную работу повсюду, а Кубернетес масштабирует эти контейнеры, автоматически обрабатывая развертывание, масштабирование и восстановление. AKS делает эту оркестровку управляемый, беря на себя управление и интегрируясь с уже известными вам инструментами Azure. Главное, Кубернетес подходит не только для крупных технологических компаний с огромными командами разработчиков. Благодаря управляемым сервисам, таким как AKS, он доступен любой команде.

Ваши домашние задания на этой неделе простое. Создайте бесплатную учетную запись Azure, разверните кластер AKS и разверните простое приложение. Это займет несколько минут, и вы увидите, насколько далеко продвинулась платформа. Готовы углубиться? В следующем эпизоде мы расскажем, как создать свой первый образ контейнера и загрузить его в Azure Container Registry. Подпишитесь на подкаст на вашей любимой платформе и поделитесь этим с тем, кто только начинает свой путь в Кубернетес.