service kubernetes что это
Kubernetes или с чего начать, чтобы понять что это и зачем он нужен
Данная статья рассчитана на новичков. Если вы опытный ниндзя, просто вспомните о том, как когда-то подобная информация могла быть полезной и для вас.
Kubernetes был создан Google на основе собственного опыта работы с контейнерами в производственной среде, и своим успехом он во многом обязан именно Google.
Так что же такое Kubernetes и для чего мы в принципе хотим использовать именно его, а не обычные контейнеры, например Docker.
Давайте вспомним что такое контейнеры.
Контейнеры упаковывают сервисы, составляющие приложение, и делают их переносимыми в различные вычислительные среды как для разработки и тестирования, так и для производственного использования. С помощью контейнеров легко быстро наращивать количество экземпляров приложений, чтобы соответствовать пиковому спросу. А поскольку контейнеры используют ресурсы ОС хоста, они намного легче виртуальных машин. Это означает, что контейнеры очень эффективно используют базовую серверную инфраструктуру.
Контейнерам надо подключаться к внешнему миру и быть управляемыми для балансировки нагрузки, распределения и планирования.
Вот для такого и нужен Kubernetes.
Kubernetes по сути является не просто системой оркестрации. Технически оркестрация это про выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C.
Kubernetes же устраняет прямую необходимость в этом. В нем есть процессы управления, что по факту независимы и компонуемы. Главная задача процессов управления перевести текущее состояние к нужному состоянию. Теперь нам неважно какой будет маршрут от А до С, что исключает централизованный контроль.
Благодаря этому система теперь более проста в использовании, мощная, надежная, а также устойчивая и расширяемая.
Контейнеры позволяют поделить чтобы приложения были поделены на более мелкие части с четким разделением задач. Уровень абстракции, предоставляемый для отдельного образа контейнера, позволяет нам понять как строятся распределенные приложения. Такой модульный подход дает возможность более быстро осуществлять разработку с помощью небольших и более целенаправленных групп, каждая из которых отвечает за определенные контейнеры. Это также позволяет нам изолировать зависимости и более широко использовать компоненты меньшего размера.
Сделать это только с помощью контейнеров не получится. А вот в Kubernetes это можно достичь с помощью Pods (подов).
Концепция Service (Сервисы) в Kubernetes используется для группирования нескольких подов, которые выполняют те же функции. Сервисы легко настраиваются для таких целей как обнаружение, горизонтальное масштабирование и балансировка нагрузки.
Kubernetes, согласно официальной документации, так же сможет предоставить вам:
Используя имя DNS или собственный IP-адрес мониторинг сервисов и распределение нагрузки Kubernetes может обнаружить контейнер. При высоком трафике в нем Kubernetes сбалансирует нагрузку и распределить сетевой трафик так, что развертывание будет стабильным.
Система хранения по вашему выбору (например, локальное хранилище, провайдеры общедоступного облака и многое другое) может быть автоматически смонтирована с помощью оркестрации хранилища Kubernetes.
Автоматическое развертывание и откаты.
Kubernetes через описание желаемого состояния развернутых контейнеров (манифесты, пишутся на yaml) может изменить фактическое состояние на желаемое. То есть создание новых контейнеров для развертывания, удаления существующих контейнеров и распределения всех их ресурсов в новый контейнер в Kubernetes можно автоматизировать.
Автоматическое распределение нагрузки.
Kubernetes сам размещает контейнеры на ваших узлах так, чтобы наиболее эффективно использовать ресурсы. Вам остается только указать сколько ЦП, ОЗУ требуется каждому контейнеру и предоставить кластер узлов, где будут запущены контейнеры.
Самоконтроль.
Если в работе контейнеров что-то пошло не так, то Kubernetes сам перезапускает, заменяет и завершает работу контейнеров, которые не проходят проверку работоспособности.
Управление конфиденциальной информацией и конфигурацией.
Пароли, OAuth-токены и ключи SSH могут храниться и управляться Kubernetes без изменений образов контейнеров и не раскрывая конфиденциальную информацию в конфигурации стека.
Как видим на рисунке, это наглядная демонстрация того что есть внутри Kubernetes на примере одной мастер ноды (Master node) и одной воркер ноды (Worker node).
На Master node находится Kubernetes Control Plane (kube-scheduler, kube-controller-manager, kube-apiserver, etcd), с помощью которой происходит управление всем кластером Kubernetes.
На Worker node находятся container runtime (среда запуска контейнера), kubelet и kube-proxy.
Сontainer runtime это то на чем будет запущен ваш Под (например Docker, Container D, Rocket и т.д.).
Kubelet это основной «агент узла», который работает на каждой ноде. Гарантирует, что контейнеры в Pod(поде)работают и исправны. Не управляет контейнерами, которые не были созданы Kubernetes.
Kube-proxy это демон на каждой ноде, управляет правилами iptable на хосте для достижения балансировки нагрузки службы (одна из реализаций) и следит за изменениями Service и Endpoint.
Более детальное рассмотрение архитектуры, основных концепций Kubernetes в теории и главное на практике, наравне с такими интересными темами как кластеризация, highload web, администрирование СУБД, виртуализация и контейнеризация, оркестрация вы сможете изучить на курсе Administrator Linux. Advanced.
Также вы сможете получить ответы на такие вопросы как организовано сетевое взаимодействие в Kubernetes, как опубликовать приложение и как работает DNS в Kubernetes.
Ну и как же без такого важного вопроса как хранение данных, мониторинг и Kubernetes secrets Hashicorp Vault.
А тех, кто давно знаком с тем, что рассказано в этой статье и хочет чего-то похардкорнее, приглашаем на бесплатный демо-урок по теме ««Кластерная файловая система Lustre»». В рамках урока рассмотрим архитектуру и компоненты файловой системы Lustre. Разберем области применения файловой системы и ее особенности. Ответим на вопросы как используется file striping и что такое сетевой транспортный уровень LNET. На практической части установим и сконфигурируем файловую систему вручную. Посмотрим пример работы графической пользовательского интерфейса Integrated Manager for Lustre (IML)
Работа с кластером Kubernetes
Цели статьи
Введение
Она формирует конфиг для настройки автодополнения команд в bash. Вывод этой команды нужно добавить в ваш
/.bashrc Можно это сделать автоматически.
Чтобы автодополнение работало, нужен пакет bash-completion.
Запуск контейнера nginx в kubernetes
Создаем файл pod-nginx.yaml следующего содержания:
Внимательно следите за пробелами в начале строк. Нужны именно пробелы, а не табуляция. В Yaml файлах очень важна структура. Запускаем получившийся pod.
Сразу сделаю пояснение насчет команды create. Вместо нее можно, а чаще всего и нужно, так как удобнее, использовать команду apply. Create создает новую абстракцию. Если вы ее измените и снова создадите с тем же именем, то получите ошибку. Вам придется сначала ее удалить, а потом создать заново. Команда apply сначала проверяет наличие абстракции, в данном случае pod-nginx и если ее нет, то создает. А если она уже есть, то просто перезапускает существующую с новыми параметрами.
Проверяем, что получилось.
В настоящий момент мы запустили в кластере kubernetes один контейнер с nginx. Существует команда edit, которая позволяет редактировать сущности кластера kubernetes в режиме реального времени. Применение изменений произойдет сразу же после сохранения изменений. Пример:
Вы увидите полный конфиг пода, который использует кластер. В нем намного больше информации, нежели в вашем yaml файле.
Удалить созданный pod можно следующей командой:
Или сразу все поды:
Отказоустойчивость подов с помощью ReplicaSet
Проверяем, что получилось.
Нам нужно было 2 реплики и мы их получили. С помощью edit мы можем на ходу редактировать replicaset, к примеру, добавляя количество реплик.
Репликасет сама следит за количеством запущенных подов. Если один из них по какой-то причине упадет или будет удален, она поднимет его заново. Можете проверить это сами, вручную удалив один из подов. Спустя некоторое время он появится снова.
Replicaset запускает поды на разных нодах. Проверить это можно, посмотрев расширенную информацию о подах.
Таким образом, если у вас одна нода выйдет из строя, кластер автоматически запустит умершие поды на новых нодах. При этом, если нода вернется обратно с запущенными подами на ней, kubernetes автоматически прибьет лишние поды, чтобы их максимальное количество соответствовало информации из шаблона replicaset.
Удаляются replicaset так же как и поды.
Вместо длинного replicaset я использовал сокращение rs. Это бывает удобно для абстракций с длинными названиями. Для всех них кубернетис поддерживает сокращения.
Deployment как раз и нужен для управления репликасетами, задавая им стратегию обновления. У вас вышла новая версия контейнера, вы заменяете в текущем deployment версию контейнера и он по заранее настроенным правилам начинает перезапуск репликасетов и соответственно подов в них. Покажу на примере nginx, который мы откатим на предыдущую версию. Создаем yaml файл с deployment.
Смотрим список подов и репликасетов.
Проверяем версию nginx в одном из подов.
Теперь откатимся на предыдущую версию nginx 1.15. Для этого вносим изменения в Deployment.
Проверяем список подов и репликасетов.
Название подов и репликасета изменились. Появился новый replicaset, а старый остался с погашенными подами, у него параметр replicas стал 0. Проверяем версию nginx в поде.
Версия nginx изменилась во всех подах. Стратегия обновления описана в шаблоне деплоймента в разделе strategy. В данном случае используется тип RollingUpdate, когда deployment постепенно уменьшает количество реплик старой версии и увеличивает реплики новой версии, пока они все не заменят старые. При этом replicaset с предыдущей версией контейнера осталась. Она не удаляется для того, чтобы можно было потом оперативно вернуться на предыдущую версию, если с новой будет что-то не так. Для этого достаточно будет по очереди погасить поды новой replicaset и запустить старые. Делается это следующим образом.
Проверяем наши replicaset.
Видим, что был снова запущен предыдущий replicaset с прошлой версией контейнера. По-умолчанию хранятся 10 версий прошлых replicaset.
Проверки доступности Probes
С деплоем и перезапуском подов не все так просто. Есть тяжелые приложения, которые стартуют очень долго, либо зависят от других приложений. Прежде чем погасить старую версию, нужно убедиться, что новая уже запущена и готова к работе. Для этого существует liveness и readiness проверки. Покажу на примере. Берем предыдущий deployment и добавляем туда проверки.
В данном примере используется проверка httpGet по корневому урлу на порт 80.
Вот еще один пример liveness проверки, но уже по наличию файла. Проверяется файл /tmp/healthy, если он существует, проверка удачна, если его нет, то ошибка.
Создавать этот файл может само приложение во время работы.
Важно понимать, что реквесты никак не следят за реальным использованием ресурсов. То есть это просто пожелание к ресурсам ноды, где будет размещаться под. При этом после размещения он сможет занять ресурсов больше, чем указано в Requests. Кластер kubernetes за этим не следит. Если реквесты вообще не указать, то под может приехать на ноду, где свободно очень мало ресурсов, а ему для работы надо больше. В итоге он будет падать. Таким образом, requests используются для планирования ресурсов кластера.
Далее пример деплоймента с указанными параметрами ресурсов. Дополняем предыдущие примеры.
Память выделяется в мегабайтах, а вот CPU в милли cpu, что равно 1/1000 от процессоронго ядра. То есть 1000 миллицпу это одно ядро процессора ноды. Запустим наш deployment и посмотрим на один из подов.
Вот они, наши проверки и лимиты с реквестами.
Монтирование конфигов через ConfigMap
В данном случае это простейший конфиг для nginx, который при обращении к серверу будет отдавать 200-й код ответа и имя сервера. Теперь подключаем его к нашему deployment из предыдущих примеров.
Мы создаем монтирование с именем config по пути /etc/nginx/conf.d/ и связываем это монтирование с configmap, который ранее создали. Теперь применяем сначала configmap, а затем deployment.
Проверяем, что получилось. Я подключусь к одному из подов и прочитаю там конфигурацию nginx.
Видим, что применился наш configmap. На втором поде будет то же самое.
Проброс порта в pod
А сейчас пробросим 80-й порт мастера в конкретный под и проверим, что nginx действительно работает в соответствии с установленным конфигом. Делается это следующим обарзом.
Перемещаемся в сосeднюю консоль мастера и там проверяем через curl.
Если сделать проброс в другой под и проверить подключение, вы получите в ответ на запрос curl на 80-й порт мастера имя второго пода. На практике, я не знаю, как можно использовать данную возможность. А вот для тестов в самый раз.
Service в Kubernetes по своей сути это некий балансировщик на уровне L3. С помощью сервисов мы можем попасть в нужные нам поды, обратившись к ним по имени или по ip адресу. Перераспределение запросов идет по алгоритму round-robin. Давайте сделаем сервис к нашему deployment из предыдущих примеров.
И смотрим, что получилось.
Нажимайте enter и попадете в контейнер. А дальше пробуйте пинговать.
После выхода из контейнера, он удалится.
Настройка Ingress
Загружаем конфиг в кластер кубернетиса.
Смотрим, что получилось.
Я просто в локальный hosts машины добавил и проверил.
Если обновлять страничку, имя пода будет меняться в соответствии с настройкой балансировки. Она выполняется по алгоритму least_conn.
Более подробно настройку ingress контроллера я рассмотрел в отдельной статье.
На этом я прерываюсь и заканчиваю текущее повествование по работе с кластером kubernetes. В таком виде в нем уже можно осмысленно что-то запускать и эксплуатировать. Надеюсь, вам было хоть немного понятно и вы сможете начать экспериментировать с кластером и пытаться на нем запускать какую-то полезную нагрузку. В таком виде он уже пригоден к ограниченной эксплуатации.
Deploy реального приложения в кластер
Запускаем деплой всего проекта одной командой.
Наблюдать за поднятием подов можно командой в реальном времени.
После того, как они все станут Running можно проверять работу. В этом проекте не используется ingress, поэтому чтобы понять, как подключиться к магазину, надо провести небольшое расследование. Для начала посмотрим запущенные service.
Этот pod запущен на kub-node-2. Посмотрим ее ip.
Вот он, наш магазин. Для удобства, можем сами доделать доступ через ingress по доменному имени. Настраиваем конфиг ingress.
Не забывайте указывать нужный namespace и правильное имя сервиса, для которого настраиваем ingress. Применяем конфиг.
Смотрим, что получилось.
Редактируем файл hosts и идем в браузер проверять.
Поздравляю, ваш кластер работает, а вы теперь администратор кластера Kubernetes и инженер yaml файлов 🙂 У вас теперь будет большая дружба с лапшеподобным синтаксисом. Идите к руководству и требуйе прибавки к зарплате минимум на 30%.
Заключение
Напоминаю, что подробно, с примерами и практическими заданиями изучить кластер kubernetes можно на обучении Слёрм, которое я прошел лично и могу рекомендовать, как хороший и эффективный курс.
Онлайн курс «SRE практики и инструменты»
Помогла статья? Подписывайся на telegram канал автора
Автор Zerox
17 комментариев
Про пробы описаны не правильно
Один момент. Readiness проба исполняется всё время работы пода, а не завершается.
Коллеги, в статье не нашел информации. А как дать доступ для Jenkins? В Yutube вижу подключают secret file, беря в качестве него config. А как обстоит дело в случае kubespray?
Если не ошибаюсь, все необходимое для подключения к кластеру есть в директории /etc/kubernetes/ мастера, с которого была установка. С именем директории могу ошибаться, но она точно в /etc. Там и конфиги и сертификаты для подключения. Точно проверить нет кластера под рукой. Это что касается доступу к кластеру. Как именно jenkins к нему подключать, не знаю. Да и что значит дать доступ для Jenkins? Он что должен в кластере делать? Деплоить приложения?
Спасибо.
>Да и что значит дать доступ для Jenkins? Он что должен в кластере делать? Деплоить приложения?
Именно.
Спасибо за цикл статей про k8s. Пользовался ими при настройке кластера. Есть один вопрос, который пока не удается решить. Может здесь кто подскажет.
Каким образом передать свой домен в контейнер кубера, при деплое пода чтобы в файле /etc/hosts была запись типа такой:
1.2.3.4 test.domain.com test
Сейчас домен автоматом дописывает сам кубер, /etc/hosts:
Спасибо автору за проделанную работу.
Только у меня ingress-nginx почему-то с пустым IP адресом?
и сервис не обслуживается:
# curl kub-ingress-1.cluster.local
curl: (7) Failed connect to kub-ingress-1.cluster.local:80; Connection refused
Оказывается у меня почему-то отсутствует ingress-nginx-controller-xxxx как и сам ingress-nginx namespace.
kube-system coredns-85578f88b8-6rmcm 1/1 Running 0 95s
kube-system coredns-85578f88b8-h9mjr 1/1 Running 0 105s
kube-system dns-autoscaler-7d4cfd5f55-cf2hs 1/1 Running 1 27h
kube-system kube-apiserver-kub-master-1 1/1 Running 224 2d1h
kube-system kube-apiserver-kub-master-2 1/1 Running 3 47h
kube-system kube-apiserver-kub-master-3 1/1 Running 3 47h
kube-system kube-controller-manager-kub-master-1 1/1 Running 0 2d1h
kube-system kube-controller-manager-kub-master-2 1/1 Running 0 47h
kube-system kube-controller-manager-kub-master-3 1/1 Running 0 47h
kube-system kube-flannel-8vr5f 2/2 Running 3 27h
kube-system kube-flannel-b6ktv 2/2 Running 3 27h
kube-system kube-flannel-bnm7s 2/2 Running 3 27h
kube-system kube-flannel-kstqb 2/2 Running 3 27h
kube-system kube-flannel-r57jz 2/2 Running 2 27h
kube-system kube-flannel-wfjrn 2/2 Running 10 27h
kube-system kube-proxy-ch5kc 1/1 Running 0 3m50s
kube-system kube-proxy-ct9b6 1/1 Running 0 3m50s
kube-system kube-proxy-dz7ck 1/1 Running 0 3m50s
kube-system kube-proxy-kkdnd 1/1 Running 0 3m50s
kube-system kube-proxy-rtnth 1/1 Running 0 3m50s
kube-system kube-proxy-zs8cd 1/1 Running 0 3m50s
kube-system kube-scheduler-kub-master-1 1/1 Running 0 2d1h
kube-system kube-scheduler-kub-master-2 1/1 Running 0 47h
kube-system kube-scheduler-kub-master-3 1/1 Running 0 47h
kube-system kubernetes-dashboard-556b9ff8f8-4dtt9 1/1 Running 1 27h
kube-system nginx-proxy-kub-ingress-1 1/1 Running 3 27h
kube-system nginx-proxy-kub-node-1 1/1 Running 1 27h
kube-system nginx-proxy-kub-node-2 1/1 Running 1 27h
kube-system nodelocaldns-26fws 1/1 Running 1 27h
kube-system nodelocaldns-44n9h 1/1 Running 1 27h
kube-system nodelocaldns-5pjst 1/1 Running 3 27h
kube-system nodelocaldns-7k6nq 1/1 Running 1 27h
kube-system nodelocaldns-9xj9k 1/1 Running 1 27h
kube-system nodelocaldns-dw2ll 1/1 Running 1 27h
Странно то, что деплой прошел без ошибок даже после повторного запуска.
kub-ingress-1 : ok=322 changed=10 unreachable=0 failed=0 skipped=531 rescued=0 ignored=0
kub-master-1 : ok=494 changed=29 unreachable=0 failed=0 skipped=976 rescued=0 ignored=0
kub-master-2 : ok=428 changed=26 unreachable=0 failed=0 skipped=847 rescued=0 ignored=0
kub-master-3 : ok=430 changed=26 unreachable=0 failed=0 skipped=845 rescued=0 ignored=0
kub-node-1 : ok=320 changed=10 unreachable=0 failed=0 skipped=535 rescued=0 ignored=0
kub-node-2 : ok=320 changed=10 unreachable=0 failed=0 skipped=533 rescued=0 ignored=0
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Friday 10 April 2020 13:32:12 +0000 (0:00:00.388) 0:17:06.491 **********
Kubernetes как сервис — изучение рынка
Привет, Хабр! Как и многие другие, в прошлом году мне пришлось внезапно мигрировать из тесного привычного офиса к себе домой. Я и раньше работал из дома, когда была такая нужда. Но чтобы несколько месяцев подряд — такое со мной случилось впервые. Появилось свободное время, которое я сначала не знал, куда девать. Но потом приспособился, начав изучать вещи, до которых раньше не доходили руки.
Я поковырялся в инвестиционных играх на бирже, познакомился с облачным геймингом, а ещё успел почитать о том, что за зверь такой появился, про который из каждого умного утюга говорят — Kubernetes. Начав с блога Фланта, я убедился, что конкретно мне и конкретно сейчас эта штука не нужна, но выглядит она интересно.
Почитал, одобрил и забыл, да вот только буржуйский Facebook про меня забывать не хотел. И где-то с неделю показывал мне рекламу с самыми наивыгодными предложениями этого самого кубернетиса. В результате я в очередной раз продемонстрировал моральную слабость и решил лично познакомиться с этим зверем.
Главное, что я понял, так это что если вы не слышали про Kubernetes и не понимаете, как его использовать в вашей работе, то в 99% случаев он вам и не нужен. Но сама идея сокращения цикла разработки за счёт быстрой доставки пользователю и возможности тестировать версии приложений на узких сегментах аудитории прекрасна. Посмотрел, что получилось, после чего можно распространить версию приложения на всех пользователей или немедленно её откатить.
Но продолжу тему знакомства с этой модной платформой управления контейнерами. Я решил не ограничивать себя одной компанией, наиболее часто мозолившей глаз в Facebook. А выбрать несколько более-менее крупных фирм, у которых есть толковое предложение.
Как выбирал
Вы удивитесь, но поиском. Погуглил «Kubernetes в облаке», пролистал пару страниц. Так и нашёл семь компаний, которые наиболее активно продвигают эту услугу: Mail.ru Cloud Solutions, Cloud4Y, CloudMTS, Yandex.Cloud, КРОК, DataLine, Selectel.
Было бы круто воспользоваться сервисом подбора провайдеров, где можно указать фильтры по ценам, возможностям и прочему. Но увы, я такого сервиса не нашёл, так что делал всё ручками. И если кого шибко важного и крупного не указал, так это не по причине моей зловредности, а потому что реклама у них слабенькая. Ну, и или страницы в поиске глубоко находятся. В общем, кого нет в списке, того я не нашёл. Прошу понять, простить и не гнобить.
Про субъективность
Это абсолютно необъективная статья. Было просто интересно, что это за зверь, какой сервис выглядит удобнее и надёжнее остальных, какой проще и понятнее именно для меня. Так что учитывайте, что мой опыт — это всего лишь мой опыт. У вас могут быть другие предпочтения и знания. Рассматривайте данный текст просто как информацию, абстрактное общее сравнение, а не прямое руководство к действию.
Ещё момент: я собирал информацию, которая есть в открытом доступе, стараясь не задалбывать менеджеров глупыми частыми вопросами по почте и телефону. Мне было неловко звонить и расспрашивать, если покупать всё равно не планирую. Тратить чужое время из-за неуёмного моего любопытства было как-то стыдно. Ну захотелось мне проверить, будет ли работать их сервис, нравится ли он мне как пользователю. Были некоторые моменты, которые я узнавал по телефону и почте, но в основном все данные брал из документации и маркетинговых материалов.
Здесь возникли первые сложности. Я старался звонить по-минимуму, но тот же Яндекс без звонка хоть что-то сообщать отказывался. Остальные без проблем написали о том, что они предлагают и как всё это работает. Ну и ладно, подумал я. Информации в свободном доступе тоже хватает. Вернусь позднее и пообщаюсь, раз они такие буки. Или не пообщаюсь, если к тому времени уже натестируюсь по самый докер. Это была зима 2020, и у меня было много свободного времени.
Знакомство
Звонить и писать сразу всем компаниям — гиблое дело, особенно если не готов покупать, а хочешь лишь проверить, как оно работает. Поэтому я потихоньку запрашивал тестовый доступ у каждой компании по очереди. Быстрее всех ответили Selectel, Cloud4Y и MCS, а вот Крок и DataLine оказались не столь быстрыми. Мне даже пришлось несколько раз ментально их пнуть напоминать о себе, чтобы получить какой-то ответ.
И уже на этом этапе круг подопытных кроликов провайдеров сузился. DataLine вообще никак не захотел со мной общаться. Письма ушли в молоко. «Ну и ладно», — подумал я. «И нечего нас дёргать со всякими глупостями», — подумал неизвестный мне менеджер DataLine. КРОК вежливо извинился и сообщил, что мелочь вроде меня им не интересна. Неприятно, но честно. Спасибо за это. Лучше честный отказ, чем игнор или затягивание времени.
Отмечу, что прямо-таки агрессивных продаж не наблюдалось. Понятно, что я не самая крупная рыбка, которая водится в облачном море. Но всё же. Порадовало, что мне не впаривают, а предлагают. Убеждают. Правда, почти все компании сочли своим долгом сделать меня подписчиком полезных корпоративных рассылок. Но к этому я был готов.
Чуть забегая вперёд скажу, что поскольку компаний стало меньше, а я вошёл во вкус, то в процессе тестирования сервисов Kubernetes вспомнил и про Яндекс. «А не позвонить ли мне им?», подумалось мне. Как оказалось, не зря — у этих ребят оказалось не самое плохое решение из тех, что мне удалось посмотреть.
Тестирование
Теперь давайте посмотрим, чего я натестировал.