WEBVTT

00:00:00.100 --> 00:00:04.240
Сегодня мы поговорим о том, о чем слышал почти каждый, но не может объяснить о Кубернетес.

00:00:04.380 --> 00:00:07.480
Это сбивает с толку, потому что решает проблему, которую большинство людей не замечают,

00:00:07.560 --> 00:00:10.620
пока не столкнутся с ней. Все знают, что это важно, но спросите, что он делает,

00:00:10.760 --> 00:00:14.120
и вы получите в ответ пустой взгляд. Это не замена докер или облачная операционная система,

00:00:14.340 --> 00:00:17.740
хотя люди часто предполагают именно это. Путаница вполне объяснима, потому что Кубернетес

00:00:17.740 --> 00:00:20.460
решает проблему, о существовании которой вы не знаете, пока не столкнетесь с ней.

00:00:20.600 --> 00:00:23.280
Это инструмент, который становится незаменимым, когда у вас появляется больше,

00:00:23.460 --> 00:00:26.400
чем просто несколько контейнеров для управления. К концу этого эпизода вы поймете,

00:00:26.400 --> 00:00:30.240
что такое Кубернетес на самом деле, как он взаимодействует с контейнерами и почему

00:00:30.240 --> 00:00:34.440
Azure Кубернетес сервис делает его практичным для команд, которые не хотят создавать все с нуля.

00:00:34.620 --> 00:00:38.200
Заварите кофе и давайте начнем. Проблема до появления контейнеров.

00:00:38.380 --> 00:00:41.940
Вернемся к проблеме. Представьте себе компанию разработчика программного обеспечения 10 лет назад.

00:00:42.100 --> 00:00:44.620
У вас есть несколько приложений, которые нужно запустить, поэтому вы покупаете серверы,

00:00:44.680 --> 00:00:47.800
устанавливаете операционные системы и развертываете все вручную. Каждое приложение получает свой

00:00:47.800 --> 00:00:51.080
собственный сервер, и ресурсы между ними нельзя совместно использовать. Если одному приложению

00:00:51.080 --> 00:00:54.400
требуется много памяти, а другому почти ничего, то каждому из них все равно нужен свой собственный

00:00:54.400 --> 00:00:59.140
сервер. Это приводило к огромным потерям ресурсов. Серверы работали, возможно, на 20% мощности,

00:00:59.260 --> 00:01:02.520
но их нельзя было объединить, потому что приложения конкурировали бы из-за зависимости.

00:01:02.680 --> 00:01:05.940
В итоге получалась комната, полная серверов, каждый из которых почти ничего не делал,

00:01:06.060 --> 00:01:09.220
потреблял электроэнергию и охлаждал, и все они требовали постоянного обслуживания.

00:01:09.400 --> 00:01:13.980
Одному приложению нужен Python 3.7, другому — Python 3.8. Одному нужна более старая библиотека,

00:01:14.180 --> 00:01:17.160
другому — самая новая. Запустить их на одном компьютере без поломки чего-либо было невозможно,

00:01:17.280 --> 00:01:19.840
поэтому приходилось покупать больше серверов и платить за оборудование, которое большую часть

00:01:19.840 --> 00:01:23.220
времени простаивает. Виртуальные машины немного помогли, позволив разделить физический сервер на

00:01:23.220 --> 00:01:26.380
более мелкие части, каждая из которых работала под управлением своей ОС, но каждая виртуальная

00:01:26.380 --> 00:01:29.920
машина была тяжелой, с полноценной ОС, которая занимала дисковое пространство и память и запускалась

00:01:29.920 --> 00:01:33.720
за считанные минуты. И каждую из них нужно было настраивать отдельно, что отнимало много времени.

00:01:33.880 --> 00:01:36.980
При этом приходилось управлять всеми этими операционными системами, устанавливать патчи,

00:01:37.120 --> 00:01:41.000
обновления и обеспечивать их безопасность. Командам требовалось что-то более легкое и портативное,

00:01:41.160 --> 00:01:45.100
способ упаковать приложение, совсем необходимым для его работы без дополнительных затрат на полноценную

00:01:45.100 --> 00:01:49.120
виртуальную машину, и чтобы его можно было легко перемещать между машинами. Вот тут-то и пригодились

00:01:49.120 --> 00:01:53.780
контейнеры. Что же такое контейнеры на самом деле? Контейнер — это небольшой пакет, который включает

00:01:53.780 --> 00:01:58.020
в себя ваше приложение и все необходимое для его работы. Это означает, что код, среда выполнения,

00:01:58.180 --> 00:02:02.080
библиотеки и файлы конфигурации — все это объединено в одном блоке. Представьте это как транспортный

00:02:02.080 --> 00:02:05.780
контейнер для программного обеспечения. Транспортный контейнер может быть отправлен на грузовике,

00:02:05.980 --> 00:02:10.700
поезде или корабле, а сам контейнер остается неизменным. Ваш программный контейнер работает точно так же.

00:02:10.700 --> 00:02:14.860
Вы создаете его один раз, и он работает одинаково на вашем ноутбуке, тестовом сервере и в

00:02:14.860 --> 00:02:18.600
производственной среде. Ключевое различие между контейнерами и виртуальными машинами заключается

00:02:18.600 --> 00:02:21.840
в их эффективности. Виртуальная машина работает со своей собственной полноценной операционной

00:02:21.840 --> 00:02:25.700
системой, поэтому каждая ВМ имеет свое ядро, системные файлы и все остальное. Контейнер использует

00:02:25.700 --> 00:02:29.440
ту же операционную систему, что и хост. Это просто процесс со своим собственным изолированным

00:02:29.440 --> 00:02:33.540
представлением о мире. Это означает, что контейнеры запускаются за секунды, а не за минуты. Они

00:02:33.540 --> 00:02:38.120
используют меньше памяти, и вы можете разместить больше контейнеров на одной машине. Докер сделал контейнеры

00:02:38.120 --> 00:02:42.120
популярными, предоставив разработчикам простой способ создавать и запускать их одной командой.

00:02:42.280 --> 00:02:47.040
Внезапно проблема «работает на моей машине» начала исчезать. Если ваше приложение работает в

00:02:47.040 --> 00:02:51.360
контейнере на вашем ноутбуке, оно будет работать так же и на сервере. Среда везде одинакова,

00:02:51.480 --> 00:02:55.700
но контейнеры решают одну проблему и создают другую. С небольшим количеством контейнеров

00:02:55.700 --> 00:02:59.440
ручное управление вполне подходит. Вы можете запускать их, останавливать и отслеживать

00:02:59.440 --> 00:03:03.600
самостоятельно. Но что происходит, когда у вас сотни контейнеров? Вам нужно решить, на каком сервере

00:03:03.600 --> 00:03:07.080
работает какой контейнер, перезапустить вышедшие из строя, соединить их друг с другом и масштабировать

00:03:07.080 --> 00:03:11.340
при резком увеличении трафика. Это новая задача, и именно здесь на помощь приходит Кубернетес.

00:03:11.480 --> 00:03:15.300
Проблема оркестровки. Итак, у вас работают контейнеры, вы упаковали свое приложение,

00:03:15.500 --> 00:03:20.140
оно работает стабильно везде, и все хорошо. Но только некоторое время. С 10 или 20 контейнерами

00:03:20.140 --> 00:03:23.960
вы можете управлять всем вручную. Вы знаете, на каком сервере работает какой контейнер,

00:03:24.100 --> 00:03:28.120
можете перезапустить что-либо в случае сбоя и обновить кое-что. Это управляемо. Но затем

00:03:28.120 --> 00:03:32.680
ваше приложение разрастается. Вы переходите на микросервисы. Таким образом, вместо одного большого

00:03:32.680 --> 00:03:36.300
приложения у вас появляется 20 меньших. Каждому из них требуется несколько работающих копий

00:03:36.300 --> 00:03:39.120
для обеспечения надежности. И теперь вы имеете дело с двумя стами контейнерами.

00:03:39.220 --> 00:03:43.700
Ручное управление больше не работает. Вам нужно решить, на каком сервере работает каждый контейнер,

00:03:43.820 --> 00:03:47.980
перезапускать контейнеры при сбоях и соединять их для обмена данными. Вам также нужно масштабироваться

00:03:47.980 --> 00:03:52.080
при пиковых нагрузках, например, во время распродажи или запуска продукта, и уменьшать масштаб,

00:03:52.200 --> 00:03:57.080
когда ситуация успокаивается. И вам нужно развертывать обновления без простоев, что означает замену

00:03:57.080 --> 00:04:01.860
старых контейнеров новыми по одному, осторожно, не нарушая ничего. Это проблемы оркестровки,

00:04:01.860 --> 00:04:06.200
и именно для их решения был создан Кубернетес. Кубернетес — это платформа с открытым исходным

00:04:06.200 --> 00:04:09.480
кодом, который автоматизирует развертывание, масштабирование и управление контейнеризированными

00:04:09.480 --> 00:04:13.020
приложениями. Представьте себе это как операционную систему для вашего центра обработки данных.

00:04:13.160 --> 00:04:17.340
Подобно тому, как Windows или Linux управляют ресурсами на одном компьютере, такими как процессор,

00:04:17.440 --> 00:04:21.540
память и диск, Кубернетес управляет ресурсами на всех ваших серверах. Он рассматривает все ваши

00:04:21.540 --> 00:04:25.460
машины как один большой пул вычислительной мощности. Вы указываете, что хотите запустить,

00:04:25.640 --> 00:04:28.780
а он определяет, где это разместить, как поддерживать его работу и как подключить

00:04:28.780 --> 00:04:32.000
ко всему остальному. Основные понятия — поды, узлы и кластеры.

00:04:32.200 --> 00:04:34.560
Давайте посмотрим, как Кубернетес работает на самом деле.

00:04:34.760 --> 00:04:38.340
Самая маленькая единица в Кубернетес называется подом. Под — это оболочка одного или

00:04:38.340 --> 00:04:41.520
нескольких контейнеров. Контейнеры внутри одного пода совместно используют хранилище и сеть,

00:04:41.680 --> 00:04:45.040
поэтому они могут общаться друг с другом через Localhost. Вы можете рассматривать под как единую

00:04:45.040 --> 00:04:49.300
единицу развертывания. Вы не развертываете контейнеры напрямую в Кубернетес. Вы развертываете

00:04:49.300 --> 00:04:54.100
поды. Поды не работают сами по себе, они работают на узлах. Узел — это сервер, физический или виртуальный,

00:04:54.100 --> 00:04:57.300
который является частью вашего кластера Кубернетес. На каждом узле работает программное

00:04:57.300 --> 00:05:00.340
обеспечение, необходимое для запуска подов, а также несколько других вещей, о которых мы поговорим

00:05:00.340 --> 00:05:04.780
чуть позже. Кластер — это совокупность всех узлов, управляемых как единая система. Проще говоря,

00:05:04.960 --> 00:05:09.420
под — это ваше приложение. Узел — это место, где оно работает, а кластер — это вся среда.

00:05:09.560 --> 00:05:13.440
Поды эфемерны. Их можно создавать, уничтожать или перемещать в любое время. Это предусмотрено

00:05:13.440 --> 00:05:17.260
разработчиками. Если узел выходит из строя, Кубернетес перемещает поды на другой. Для масштабирования

00:05:17.260 --> 00:05:22.140
он создает новые поды. А когда под выходит из строя, он автоматически заменяется. Вся система рассматривает

00:05:22.140 --> 00:05:25.740
поды как временные. Но если поды появляются и исчезают, вам нужен способ взаимодействовать с ними.

00:05:25.920 --> 00:05:28.780
Вместо того, чтобы напрямую взаимодействовать с подом, вы взаимодействуете с сервисом.

00:05:28.940 --> 00:05:32.120
Сервис предоставляет стабильный сетевой адрес, который направляет трафик к нужным подам,

00:05:32.280 --> 00:05:36.100
даже когда поды меняются. Представьте себе отель. Номер телефона отеля — это сервис.

00:05:36.280 --> 00:05:40.200
Номера постоянно меняют гостей, но номер телефона остается неизменным. Вы звоните на ресепшн,

00:05:40.200 --> 00:05:44.800
и ваш звонок перенаправляется в нужный кабинет. Именно это и делает сервис в Кубернетес. Он предоставляет

00:05:44.800 --> 00:05:48.340
вам фиксированный адрес, который всегда указывает на те поды, которые в данный момент запускают

00:05:48.340 --> 00:05:53.660
ваше приложение. Это плоскость управления, мозг кластера. Итак, у вас есть поды, узлы и кластер.

00:05:53.660 --> 00:05:58.420
Вопрос в том, кто решает, что где работает. Это задача плоскости управления. В каждом кластере

00:05:58.420 --> 00:06:03.000
Kubernetes она есть, и это мозг всей системы. Все решения принимаются здесь. Плоскость управления

00:06:03.000 --> 00:06:06.700
состоит из нескольких компонентов. Первый — это API-сервер, который выступает в качестве входной

00:06:06.700 --> 00:06:10.260
двери в ваш кластер. Каждая команда, которую вы отправляете в Kubernetes, будь то из командной

00:06:10.260 --> 00:06:13.800
строки, панели мониторинга или автоматизированного скрипта, проходит через API-сервер. Он

00:06:13.800 --> 00:06:17.300
аутентифицирует ваш запрос, проверяет, разрешено ли вам делать-то, что вы запрашиваете,

00:06:17.300 --> 00:06:21.200
а затем передает его в нужное место. В Kubernetes ничего не происходит без предварительного

00:06:21.200 --> 00:06:25.720
прохождения через API-сервер. Далее идет планировщик, который решает, на каком узле запускается

00:06:25.720 --> 00:06:29.560
каждый под. Когда вы говорите «я хочу, чтобы это приложение работало», планировщик проверяет все

00:06:29.560 --> 00:06:33.300
доступные узлы, оценивает имеющиеся ресурсы, такие как ЦП, память и дисковое пространство,

00:06:33.420 --> 00:06:37.140
и выбирает наиболее подходящие для этой задачи. Это похоже на то, как менеджер отеля распределяет

00:06:37.140 --> 00:06:40.800
номера в зависимости от потребностей каждого гостя. Гость с большим количеством багажа получает

00:06:40.800 --> 00:06:44.060
номер побольше, а легковесное приложение – меньший узел с запасом мощности.

00:06:44.260 --> 00:06:47.660
Затем есть контроллер-менеджер. Этот компонент следит за кластером и гарантирует,

00:06:47.860 --> 00:06:51.320
что фактическое состояние соответствует заявленному. Вы сказали, что хотите запустить

00:06:51.320 --> 00:06:55.320
три копии вашего веб-приложения. Контроллер-менеджер проверяет, действительно ли работают три

00:06:55.320 --> 00:06:59.900
копии. Если одна из них выходит из строя, он это замечает и запускает замену. Если кто-то случайно

00:06:59.900 --> 00:07:04.340
удаляет под, он создает новый. Это компонент, который обеспечивает корректную работу кластера.

00:07:04.460 --> 00:07:09.040
И, наконец, есть ETCD – база данных кластера. Она хранит все, что запущено,

00:07:09.040 --> 00:07:13.720
где оно запущено и как оно настроено. Это источник достоверной информации для всего кластера.

00:07:13.920 --> 00:07:18.640
Если API-сервер – это входная дверь, то ETCD – это картотека в бэк-офисе, где хранятся все

00:07:18.640 --> 00:07:22.460
записи. Прелесть такой архитектуры в том, что вы описываете свои желания, а Кубернетес сам

00:07:22.460 --> 00:07:26.400
определяет, как их реализовать. Вы не указываете, как что-то делать, вы указываете, как должен

00:07:26.400 --> 00:07:30.860
выглядеть конечный результат. Это декларативная модель, и это основная идея всего, что делает Кубернетес

00:07:30.860 --> 00:07:35.200
рабочие нагрузки, развертывание, сервисы и масштабирование. Итак, давайте поговорим о том,

00:07:35.200 --> 00:07:38.380
как на самом деле запускаются приложения в Кубернетес. Вы не будете создавать

00:07:38.380 --> 00:07:41.360
поды напрямую. Вместо этого вы будете использовать объект более высокого уровня,

00:07:41.480 --> 00:07:44.680
называемый развертыванием. Представьте себе развертывание как менеджер, который сообщает

00:07:44.680 --> 00:07:48.360
Кубернетес, сколько копий вашего пода должно работать, какой образ контейнера использовать и

00:07:48.360 --> 00:07:51.980
как обновлять их при выходе новой версии. Это стандартный способ запуска приложения без

00:07:51.980 --> 00:07:55.400
состояния. Когда вы обновляете развертывание, например, отправляете новую версию своего

00:07:55.400 --> 00:07:58.920
приложения, Кубернетес выполняет скользящее обновление. Он заменяет поды один за другим,

00:07:59.060 --> 00:08:03.140
гарантируя, что как минимум одна копия всегда работает. Это означает отсутствие простоев и внезапных

00:08:03.140 --> 00:08:07.200
прерываний для ваших пользователей. А если что-то пойдет не так с новой версией, вы можете откатиться

00:08:07.200 --> 00:08:11.820
к предыдущей версии одной командой. Это мощная система безопасности. Но ваши поды все еще должны

00:08:11.820 --> 00:08:16.060
быть доступны. Вот тут-то и вступают в игру сервисы. Сервис предоставляет стабильный сетевой адрес,

00:08:16.220 --> 00:08:20.020
который направляет трафик к нужным подам. Он также может предоставлять доступ к этим подам

00:08:20.020 --> 00:08:24.420
другим частям вашего приложения или внешнему миру. Сервис может быть внутренним, доступным только

00:08:24.420 --> 00:08:28.960
внутри кластера или внешним, с публичным IP-адресом, которому пользователи могут получить доступ

00:08:28.960 --> 00:08:33.080
из интернета. Теперь о масштабировании. Кубернетес может автоматически увеличивать и уменьшать

00:08:33.080 --> 00:08:36.380
размер вашего приложения в зависимости от спроса. Вы устанавливаете целевой показатель,

00:08:36.520 --> 00:08:40.560
скажем, 70% использования ЦП, и Кубернетес добавляет больше подов, когда использование превышает

00:08:40.560 --> 00:08:44.200
этот порог и удаляет их, когда оно падает. Ваше приложение масштабируется вверх во время пика

00:08:44.200 --> 00:08:48.240
трафика и обратно вниз, когда все успокаивается. Никакого ручного вмешательства не требуется,

00:08:48.400 --> 00:08:52.060
но вся эта мощь сопряжена со сложностью. Управление собственным кластером Кубернетес означает,

00:08:52.200 --> 00:08:55.740
что вы отвечаете за плоскость управления, обновление, исправление безопасности и резервное копирование.

00:08:55.740 --> 00:08:59.760
Вам необходимы глубокие знания для обработки сбоев узлов, настройки сети и масштабирования

00:08:59.760 --> 00:09:03.320
кластера. Многие команды тратят больше времени на управление кластером, чем на разработку

00:09:03.320 --> 00:09:07.160
приложений. И вот тут на помощь приходит управляемый Кубернетес. Самостоятельное управление

00:09:07.160 --> 00:09:11.000
против управляемого Кубернетес. Итак, давайте поговорим о реальности самостоятельного управления

00:09:11.000 --> 00:09:14.660
Кубернетес. Когда вы настраиваете собственный кластер, вы отвечаете за все, плоскость управления,

00:09:14.820 --> 00:09:19.320
обновление, исправление безопасности и резервное копирование ETCD. Если API-сервер выходит из строя,

00:09:19.420 --> 00:09:23.060
это ваша проблема. Если в используемой вами версии обнаружена уязвимость безопасности,

00:09:23.060 --> 00:09:27.500
вам необходимо ее исправить. Если ETCD поврежден, вам необходимо восстановить данные из резервной

00:09:27.500 --> 00:09:31.440
копии. Все это требует глубоких знаний. Вам необходимо понимать, как выходит из строя узлы,

00:09:31.560 --> 00:09:34.880
как работает сеть на уровне кластера и как масштабировать систему, не нарушая ее работу.

00:09:35.040 --> 00:09:38.900
Вот что удивляет многие команды. Многие организации тратят больше времени на управление

00:09:38.900 --> 00:09:42.740
кластером Кубернетес, чем на разработку приложений, работающих на немецком. Они постоянно

00:09:42.740 --> 00:09:47.200
борются с обновлениями, устраняют неполадки в сети и сталкиваются со сбоями узлов. Кластер становится

00:09:47.200 --> 00:09:51.620
работой на полный рабочий день. Но Кубернетес используется не для этого. Вот тут-то и пригодятся

00:09:51.620 --> 00:09:56.460
управляемые сервисы Кубернетес. Такие сервисы, как Azure Kubernetes Service, AKS, берут на себя

00:09:56.460 --> 00:10:01.180
управление плоскостью управления. Azure управляет API-сервером, ETCD, планировщиком и диспетчером

00:10:01.180 --> 00:10:04.600
контролеров. Вам не нужно беспокоиться об их обновлении или поддержании работоспособности.

00:10:04.740 --> 00:10:08.100
Вы платите только за рабочие узлы, виртуальные машины, которые фактически запускают ваши рабочие

00:10:08.100 --> 00:10:12.360
нагрузки. Сама плоскость управления бесплатна. Это кардинально меняет ситуацию. Вместо того,

00:10:12.360 --> 00:10:15.560
чтобы тратить время на обслуживание кластера, ваша команда может сосредоточиться на действительно

00:10:15.560 --> 00:10:19.920
важных вещах, приложениях, которые вы разрабатываете. Для большинства команд, особенно начинающих,

00:10:21.620 --> 00:10:27.140
выбор. Вы получаете всю мощь Кубернетес без операционных издержек. AKS, Кубернетес, упрощенный

00:10:27.140 --> 00:10:31.780
на Azure. Итак, что же такое AKS? Это управляемая служба Кубернетес от Azure, предоставляющая

00:10:31.780 --> 00:10:35.040
полнофункциональный кластер без необходимости его создания с нуля. Как мы уже упоминали,

00:10:35.140 --> 00:10:38.120
управляющая плоскость бесплатна, поэтому вы платите только за виртуальные машины, на которых

00:10:38.120 --> 00:10:42.340
работают ваши рабочие нагрузки. Это означает, что вы можете начать с малого, платить очень мало и масштабироваться

00:10:42.340 --> 00:10:47.160
по мере роста ваших потребностей. Azure берет на себя всю основную работу. Обновление, исправление и мониторинг

00:10:47.160 --> 00:10:51.000
состояние управляющей плоскости, все это обеспечивается автоматически. Вам не нужна специальная

00:10:51.000 --> 00:10:55.560
команда экспертов по Кубернетес, чтобы поддерживать работу системы. А поскольку AKS является частью

00:10:55.560 --> 00:11:00.100
экосистемы Azure, он интегрируется с инструментами, которые вы, вероятно, уже используете. Azure Active

00:11:00.100 --> 00:11:04.960
Directory для аутентификации, Azure Monitor для ведения журналов и сбора метрик и Azure Policy для

00:11:04.960 --> 00:11:09.640
управления. Все они работают вместе из коробки. Никаких дополнительных компонентов не требуется.

00:11:09.860 --> 00:11:13.700
Настройка конвейеров CI, CD с помощью Git Hub Actions или Azure DevOps занимает всего

00:11:13.700 --> 00:11:17.440
несколько минут. Отправьте изменения в свой репозиторий, и система автоматически создаст новый

00:11:17.440 --> 00:11:21.320
образ контейнера, загрузит его в Azure Container Registry и обновит ваше развертывание в AKS.

00:11:21.460 --> 00:11:25.640
Никаких ручных действий, никакого подключения по SSH к серверам. Все автоматизировано.

00:11:25.820 --> 00:11:29.560
Для начинающих есть автоматический режим AKS, разработанный для команд, которые не хотят

00:11:29.560 --> 00:11:32.700
принимать все решения по конфигурации кластера. Он предоставляет готовые к использованию

00:11:32.700 --> 00:11:36.100
настройки по умолчанию для масштабирования сети, безопасности и обновлений. Вам не нужно

00:11:36.100 --> 00:11:40.540
становиться экспертом по Кубернетес, чтобы начать. Просто опишите свое приложение, и AKS позаботится

00:11:40.540 --> 00:11:44.880
обо всем остальном. Одна команда создаст кластер, один файл манифеста запустит ваше приложение.

00:11:45.060 --> 00:11:49.060
Навыки, полученные в AKS, применимы к любой среде Кубернетес, потому что под капотом находится

00:11:49.060 --> 00:11:54.200
стандартный Кубернетес. Вы изучаете не проприетарную систему, а реальную систему, где Azure берет

00:11:54.200 --> 00:11:59.060
на себя операционную сложность. Итак, теперь у вас есть общее представление. Контейнеры упаковывают

00:11:59.060 --> 00:12:03.700
ваше приложение, обеспечивая их стабильную работу повсюду, а Кубернетес масштабирует эти контейнеры,

00:12:03.920 --> 00:12:08.400
автоматически обрабатывая развертывание, масштабирование и восстановление. AKS делает эту

00:12:08.400 --> 00:12:13.020
оркестровку управляемый, беря на себя управление и интегрируясь с уже известными вам инструментами

00:12:13.020 --> 00:12:17.060
Azure. Главное, Кубернетес подходит не только для крупных технологических компаний с огромными

00:12:17.060 --> 00:12:21.500
командами разработчиков. Благодаря управляемым сервисам, таким как AKS, он доступен любой команде.

00:12:21.700 --> 00:12:25.660
Ваши домашние задания на этой неделе простое. Создайте бесплатную учетную запись Azure,

00:12:25.900 --> 00:12:30.340
разверните кластер AKS и разверните простое приложение. Это займет несколько минут, и вы увидите,

00:12:30.520 --> 00:12:34.740
насколько далеко продвинулась платформа. Готовы углубиться? В следующем эпизоде мы расскажем,

00:12:34.740 --> 00:12:38.480
как создать свой первый образ контейнера и загрузить его в Azure Container Registry.

00:12:38.660 --> 00:12:41.960
Подпишитесь на подкаст на вашей любимой платформе и поделитесь этим с тем,

00:12:42.140 --> 00:12:43.960
кто только начинает свой путь в Кубернетес.