Празднование присоединения Harbour к ограниченному списку проектов CNCF Graduated



Пару месяцев назад, через год после того, как наша служба Managed Kubernetes стала общедоступной, мы запустили службу Managed Private Registry. В предыдущем сообщении в блоге мы рассказали, почему решили основать его на проекте CNCF Harbour. Два сотрудника OVHcloud стали сопровождающими проекта. Теперь у нас есть новое событие, которое нужно отпраздновать: Фонд облачных вычислений только что объявил, что Харбор присоединился к очень ограниченному списку «завершенных» проектов.

Выпуск CNCF: высший уровень зрелости

CNCF размещает несколько десятков проектов с открытым исходным кодом и отлично справляется со своей работой, предлагая этим проектам поддержку роста как с точки зрения инфраструктуры и инструментов, так и с точки зрения сообщества и осведомленности. Однако большинство этих проектов находятся в «песочнице CNCF» или на стадии «инкубации». В настоящее время «завершили» только 11 проектов, включая Kubernetes, Prometheus и Helm. Харбор стал последним, кто получил этот большой знак признания.



Каждый уровень отражает выполнение очень специфических характеристик зрелости, которые соблюдаются и проверяются Комитетом технического надзора CNCF. Например, для выпуска Харбор продемонстрировал, что у него есть активные коммиттеры из нескольких организаций. Он прошел исчерпывающий и независимый аудит безопасности и имеет полностью прозрачное управление. Харбор также получил значок CII за лучшие практики.

OVHcloud с гордостью демократизирует гавань

Многие организации корпоративного уровня уже приняли Harbour как часть коммерческих платформ для контейнеризации. Обычно они развертывают и используют его локально или в облаке. Если скептики и хотели получить последний знак для принятия Harbour, он пришел… и OVHcloud очень гордится тем, что помогает сделать Harbour еще проще!

Благодаря нашей полностью управляемой службе любой пользователь OVHcloud может воспользоваться выделенной, высокодоступной и полнофункциональной гаванью. Мы предлагаем полностью предсказуемые затраты и функции корпоративного уровня, которых нет во многих облачных реестрах на рынке. Те, кто еще не готовы к использованию облака, также получат выгоду от нашего пожертвования того, что стало официальным оператором Harbour Kubernetes, чтобы облегчить самостоятельное развертывание и жизненный цикл в определенных средах.



Больше для наших нынешних и будущих пользователей управляемого реестра!

Поскольку мы хотим, чтобы вы праздновали вместе с нами, мы объявляем сегодня о еще более щедрых планах для нашего управляемого частного реестра:

  • план «M», идеальный для средних компаний-разработчиков программного обеспечения или бизнес-единиц в крупных организациях; теперь включает сканирование уязвимостей
  • план «L» теперь может содержать до 5 ТБ ваших артефактов (слои контейнера, диаграммы Helm и т. д.)

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

В настоящее время демонстрируя очень стабильную версию Harbour 1.10, наша контейнерная команда уже планирует перейти на Harbour 2.0.

До встречи на саммите Kubecon Europe и OVHcloud в конце этого года!

OVHcloud Managed Kubernetes сертифицированный Kubernetes 1.18

Наш продукт OVH Managed Kubernetes уже более года доступен в общедоступном режиме. Отныне Kubernetes версии 1.18 сертифицирован CNCF на нашей платформе.



Kubernetes находится в постоянном развитии и улучшении, каждая новая версия приносит много новых функций и исправлений. И эта версия 1.18 не исключение:

Kubernetes 1.18 состоит из 38 улучшений: 15 улучшений переходят в стабильную версию, 11 улучшений — в бета-версии и 12 — в альфа-версии.

Мы очень гордимся тем, что помогаем нашим клиентам перейти на этот очень гибкий и удивительный продукт: Kubernetes!

Давайте вместе проверим некоторые особенности этого нового выпуска.

Перед обновлением Kubernetes мы рекомендуем выполнить обновление kubectlдля оркестровки Kubernetes.
kubectlможно обновлять независимо от версии кластера Kubernetes, постоянно обновляйте, kubectlчтобы пользоваться всеми новыми функциями

Для установки или обновления kubectl: kubernetes.io/docs/tasks/tools/install-kubectl/.

Создание эфемерных контейнеров с помощью Kubectl для отладки (альфа)

Kubernetes 1.18 добавляет новые расширенные возможности отладки kubectl, так как теперь он может создавать эфемерные модули для отладки других модулей в том же пространстве имен.

Для получения дополнительной информации: kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container

Применить на стороне сервера — бета 2

Применить на стороне сервера  — это новый алгоритм слияния, поэтому система знает, когда два участника пытаются редактировать одно и то же поле.

Эта функция может использоваться со следующим флагом при применении манифеста:
kubectl apply --server-side

Если вам нужно форсировать конфликты, вы можете использовать флаги « 
--force-conflicts
» и все.
Для получения дополнительной информации:  https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/

Улучшения Ingress API

В этот API есть 3 важных дополнения:

  • Новое  
    pathType
     поле, в котором можно указать, как должны быть сопоставлены входящие пути.
  • Новый  
    IngressClass
     ресурс, который может указать, как контроллеры должны реализовывать Ingress.
  • Поддержка подстановочных знаков в именах хостов.

Для получения дополнительной информации: kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/

Обновление кластера до Kubernetes 1.18

В дополнение к автоматическим обновлениям исправлений в соответствии с политикой безопасности, которую вы выбираете на панели клиента, OVHcloud предлагает вам легко обновить кластер до Kubernetes 1.18. Давайте вместе посмотрим!

Перед обновлением кластера

Поймите свои потребности. Kubernetes следует политике поддержки N-2, что означает, что 3 последних минорных версии (в настоящее время 1.16, 1.17 и 1.18) продолжают получать исправления безопасности и ошибки, поэтому любая из этих версий с последним патчем считается «стабильной».

Если вам требуются новейшие функции, вам следует подумать об обновлении до последней минорной версии, в противном случае вам следует просто позаботиться о применении последних исправлений.

Убедитесь, что вы можете обновить



Мы рекомендуем вам иметь как минимум 2 узла в вашем кластере и правильно настроить, ReplicaSets чтобы минимизировать время простоя. Также позаботьтесь о вычислительных возможностях вашего кластера, чтобы обеспечить плавное последовательное обновление ваших рабочих узлов.

Например, если у вас есть 2 узла с загрузкой ЦП 50%, когда первый узел будет обновлен, второй узел возьмет на себя нагрузку первого узла, поэтому вам необходимо убедиться, что вы готовы к запуску. ваши приложения с одним узлом меньше.

Убедитесь, что у вас есть все манифесты Kubernetes в актуальном состоянии и они применимы. Непосредственное редактирование развертываний на стороне сервера — не лучшая практика.

Вы можете использовать инструмент KubePug, чтобы помочь вам обнаружить критические изменения и устаревшие способы использования, не забывайте, что Kubernetes находится в непрерывном развитии.

Обновление вашего кластера


Перейдите в свой кластер на панели управления OVHcloud и нажмите «Обновить до следующей младшей версии Kubernetes».





Последний, но тем не менее важный

Команда также оттачивает ряд новых функций, таких как контроль над вашими узлами и пулами узлов напрямую через Kubernetes CRD. Будьте на связи!

Управление Harbour в облачном масштабе: история Harbour Kubernetes Operator

Недавно наша команда контейнерных платформ сделала нашу услугу «Частный управляемый реестр» общедоступной. В этом сообщении блога мы объясним, почему OVHcloud выбрал основу для этой службы на проекте Harbour, построил для него оператор Kubernetes и открыл его исходный код в рамках проекта CNCF goharbor.



Необходимость частного реестра S.MART

После выпуска нашей управляемой службы Kubernetes мы получили много запросов на полностью управляемый частный реестр контейнеров.

Хотя реестр контейнеров для размещения образов может показаться довольно тривиальным для развертывания, наши пользователи упомянули, что решение для реестра производственного уровня является важной частью цепочки поставки программного обеспечения и на самом деле его довольно сложно поддерживать.

Наши клиенты просили решение корпоративного уровня, предлагающее расширенный контроль доступа на основе ролей и безопасность, поскольку опасения по поводу уязвимостей в общедоступных образах возросли, а требования к доверию к контенту стали необходимостью.

Пользователи регулярно хвалили пользовательский интерфейс таких сервисов, как Docker Hub, но в то же время запрашивали сервис с высокой доступностью и поддерживаемый SLA.

Идеальное сочетание набора функций с открытым исходным кодом и корпоративного уровня

Изучив перспективы точной настройки нашего набора функций и модели ценообразования, мы искали лучшие существующие технологии, чтобы поддержать его, и остановились на инкубационном проекте CNCF Harbor (подаренном CNCF компанией VMWare). Помимо того, что Harbour является одним из немногих проектов, достигших инкубационного состояния CNCF, что подтверждает твердую приверженность сообщества, он также стал ключевой частью нескольких коммерческих решений для контейнеризации предприятий. Мы также высоко оценили подход, принятый Харбором: не изобретать колесо заново, а использовать лучшие в своем классе технологии для таких компонентов, как сканирование уязвимостей, доверие к контенту и многие другие. Он использует мощную сеть проектов с открытым исходным кодом CNCF и обеспечивает высокий уровень качества UX.



Пришло время использовать эту технологию 10k-GitHub-stars и адаптировать ее к нашему конкретному случаю: управление десятками тысяч реестров для наших пользователей, каждый из которых имеет определенный объем образов контейнеров и шаблонов использования.

Конечно, высокая доступность (интеграция и развертывание программного обеспечения клиентов зависит от этой услуги), но и надежность данных не обсуждались для нас.

Кроме того, Kubernetes для обеспечения высокой доступности сервисов без сохранения состояния и хранилища объектов (на основе Openstack Swift и совместимость с S3 API ) был очевидным выбором для проверки этих требований.

Решение операционных проблем в масштабе облачного провайдера

В течение нескольких недель мы открыли сервис в публичной бета-версии, быстро привлекая сотни активных пользователей. Но с этим всплеском трафика мы, естественно, столкнулись с первыми узкими местами и проблемами производительности.

Мы обратились к группе пользователей и команде Harbour, которые любезно указали нам на возможные решения, и после некоторых небольших, но важных изменений в том, как Harbor обрабатывает соединения с базой данных, наши проблемы были решены. Это укрепило нашу веру в то, что сообщество Harbour твердо и привержено здоровью проекта и требованиям его пользователей.

Поскольку наш сервис процветал, не было реальных инструментов, позволяющих легко приспособить жизненный цикл экземпляров Harbour. Наша приверженность экосистеме Kubernetes сделала концепцию оператора Harbour для Kubernetes интересным подходом.

Мы обсудили с сопровождающими Harbour, и они тепло приветствовали нашу идею разработать его и открыть исходный код в качестве официального оператора Harbour Kubernetes. OVHcloud очень гордится тем, что проект теперь доступен в проекте goharbor GitHub под лицензией Apache 2. Этот проект — еще один пример нашей твердой приверженности открытому исходному коду и нашей готовности внести свой вклад в проекты, которые нам нравятся.

Универсальный оператор, разработанный для любого развертывания в гавани

Читатели, знакомые с проектом Harbour, могут задаться вопросом, какое значение этот оператор привносит в текущий каталог развертываний, включая версию Helm Chart, поддерживаемую проектом.

Шаблон проектирования оператора быстро становится популярным и имитирует ориентированный на приложения контроллер, который расширяет Kubernetes для управления более сложными приложениями с отслеживанием состояния. Проще говоря, он предназначен для разных сценариев использования, чем Helm. В то время как диаграмма Helm предлагает универсальный установщик, который также будет развертывать различные зависимости Harbor (база данных, кеш и т. Д.) Из образов Docker с открытым исходным кодом, другие предприятия, операторы услуг и облачные провайдеры, такие как мы, захотят выбрать и -выбрать услугу или технологию, лежащую в основе этих компонентов.

Мы также стремимся расширить возможности текущего оператора v0.5 для управления полным жизненным циклом Harbour, от развертывания до удаления, включая масштабирование, обновления, обновления и управление резервным копированием.

Это поможет производственным пользователям достичь целевого SLO, получить выгоду от управляемых решений или существующих кластеров баз данных, которые они уже обслуживают.

Мы разработали оператор (используя платформу OperatorSDK), чтобы как дополнительные модули Harbor (хранилище Helm Chart, сканер уязвимостей и т. Д.), Ни зависимости (серверная часть хранилища реестра, относительные и нереляционные базы данных и т. Д.) Могли легко соответствовать вашему конкретному варианту использования.

Упрощенная архитектура службы управляемого частного реестра OVHcloud'd

Вклад в проект Harbor и оператора

У нас уже есть план действий с сопровождающими Harbour для дальнейшего обогащения оператора, чтобы он мог включать не только фазы развертывания и уничтожения (например, сделать обновления версии Harbour более элегантными). Мы надеемся стать неотъемлемой частью проекта и продолжим инвестировать в Harbour.

С этой целью Жереми Монсинжон и Пьер Перонне также были приглашены в качестве сопровождающих в проекте Harbour с упором на goharbor / оператора.

В дополнение к регулярному участию в нескольких проектах, которые мы используем в OVHcloud, команда контейнерных платформ также работает над другими крупными выпусками с открытым исходным кодом, такими как официальный облачный контроллер OVHcloud для самоуправляемого Kubernetes, который мы планируем выпустить в конце 2020 года.

Скачать Harbour or the Harbour Operator: официальное репозиторий Harbour Github — www.github.com/goharbor

Узнайте больше о гавани: Официальный сайт гавани — goharbor.io/

Развертывание платформы FaaS на OVH Managed Kubernetes с использованием OpenFaaS

Несколько недель назад я участвовал в митапе, посвященном Kubernetes, когда один из участников сделал замечание, которое глубоко меня нашло…

Привет, Горацио, эта штука с Kubernetes довольно крутая, но я бы хотел увидеть платформу «Функции как услуга». Большинство моих приложений можно легко сделать с помощью базы данных и нескольких бессерверных функций!

Это был не первый раз, когда я задавал этот вопрос…

Поскольку я, прежде всего, веб-разработчик, я определенно понимаю. Kubernetes — замечательный продукт — вы можете устанавливать сложные веб-архитектуры одним щелчком мыши — но как насчет базы данных + модель некоторых функций?

Что ж, вы также можете сделать это с Kubernetes!

В этом прелесть богатой экосистемы Kubernetes: вы можете найти проекты для множества различных вариантов использования, от игровых серверов с Agones до платформ FaaS…

Для этого есть таблица Helm!

Сказать: «Вы можете сделать это с Kubernetes!» почти новый " Для этого есть приложение!", но это не помогает многим людям, которые ищут решения. Поскольку этот вопрос возникал несколько раз, мы решили подготовить небольшой учебник о том, как развернуть и использовать платформу FaaS на OVH Managed Kubernetes.

Мы начали с тестирования нескольких платформ FaaS на нашем Kubernetes. Нашей целью было найти следующее решение:

  • Простота развертывания (в идеале с простой диаграммой Helm)
  • Управляется как с помощью пользовательского интерфейса, так и с помощью интерфейса командной строки, поскольку у разных клиентов разные потребности
  • Автоматическое масштабирование как в смысле увеличения, так и уменьшения
  • Поддерживается исчерпывающей документацией

Мы протестировали множество платформ, таких как Kubeless, OpenWhisk, OpenFaaS и Fission, и я должен сказать, что все они работали достаточно хорошо. В конце концов, лучший результат с точки зрения наших целей получил OpenFaaS, поэтому мы решили использовать его в качестве справочника для этого сообщения в блоге.

OpenFaaS — платформа FaaS для Kubernetes



OpenFaaS — это платформа с открытым исходным кодом для создания бессерверных функций с помощью Docker и Kubernetes. Проект уже зрелый, популярный и активный, с более чем 14 тысячами звезд на GitHub, сотнями участников и множеством пользователей (как корпоративных, так и частных).

OpenFaaS очень просто развернуть с помощью диаграммы Helm (включая оператор для CRD, т kubectl get functions. Е. ). Он имеет как интерфейс командной строки, так и пользовательский интерфейс, эффективно управляет автоматическим масштабированием, а его документация действительно исчерпывающая (с каналом Slack для ее обсуждения в качестве приятного бонуса!).

Технически OpenFaaS состоит из нескольких функциональных блоков:

  • Функция Watchdog.  Крошечный HTTP-сервер golang, который преобразует любой образ Docker в бессерверную функцию
  • API шлюз , который обеспечивает внешний маршрут в функции и собирает метрику
  • UI портал , который создает и вызывает функцию
  • Интерфейс командной строки (по сути, клиент REST для шлюза API ), который может развернуть любой контейнер как функцию

Функции можно писать на многих языках (хотя я в основном использовал для тестирования JavaScript, Go и Python), используя удобные шаблоны или простой файл Dockerfile.



Развертывание OpenFaaS на управляемом OVH Kubernetes

Есть несколько способов установить OpenFaaS в кластере Kubernetes. В этом посте мы рассмотрим самый простой: установка с помощью Helm.

Если вам нужна информация о том, как установить и использовать Helm в кластере OVH Managed Kubernetes, вы можете следовать нашему руководству .

Официальная диаграмма Helm для OpenFaas доступна в репозитории faas-netes.

Добавление диаграммы OpenFaaS Helm

Диаграмма OpenFaaS Helm недоступна в стандартном stableрепозитории Helm, поэтому вам нужно добавить их репозиторий в вашу установку Helm:

helm repo add openfaas https://openfaas.github.io/faas-netes/
helm repo update


Создание пространств имен

Руководства OpenFaaS рекомендуют создать два пространства имен: одно для основных служб OpenFaaS, а другое — для функций:

kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml


Создание секретов

Платформа FaaS, открытая для Интернета, кажется плохой идеей. Вот почему мы генерируем секреты, чтобы включить аутентификацию на шлюзе:

# generate a random password
PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1)

kubectl -n openfaas create secret generic basic-auth \
    --from-literal=basic-auth-user=admin \
    --from-literal=basic-auth-password="$PASSWORD"


Примечание: этот пароль понадобится вам позже в руководстве (например, для доступа к порталу пользовательского интерфейса). Вы можете просмотреть его в любой момент сеанса терминала с помощью echo $PASSWORD.

Развертывание диаграммы Helm

Helm диаграмма может быть развернута в трех режимах: LoadBalancer, NodePortи Ingress. Для наших целей самый простой способ — просто использовать наш внешний балансировщик нагрузки, поэтому мы развернем его LoadBalancerс --set serviceType=LoadBalancer опцией

Если вы хотите лучше понять разницу между этими тремя режимами, вы можете прочитать нашу статью в блоге «Получение внешнего трафика в Kubernetes — ClusterIp, NodePort, LoadBalancer и Ingress» .

Разверните диаграмму Helm следующим образом:

helm upgrade openfaas --install openfaas/openfaas \
    --namespace openfaas  \
    --set basic_auth=true \
    --set functionNamespace=openfaas-fn \
    --set serviceType=LoadBalancer


Как предлагается в сообщении об установке, вы можете проверить, что OpenFaaS запущен, запустив:

kubectl --namespace=openfaas get deployments -l "release=openfaas, app=openfaas"


Если он работает, вы должны увидеть список доступных deploymentобъектов OpenFaaS:

$ kubectl --namespace=openfaas get deployments -l "release=openfaas, app=openfaas"
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
alertmanager   1         1         1            1           33s
faas-idler     1         1         1            1           33s
gateway        1         1         1            1           33s
nats           1         1         1            1           33s
prometheus     1         1         1            1           33s
queue-worker   1         1         1            1           33s


Установите интерфейс командной строки FaaS и войдите в API-шлюз

Самый простой способ взаимодействия с вашей новой платформой OpenFaaS — это установка faas-cliклиента командной строки для OpenFaaS на Linux или Mac (или в терминале WSL linux в Windows):

curl -sL https://cli.openfaas.com | sh


Теперь вы можете использовать интерфейс командной строки для входа в шлюз. Для интерфейса командной строки потребуется общедоступный URL-адрес OpenFaaS LoadBalancer, который вы можете получить через kubectl:

kubectl get svc -n openfaas gateway-external -o wide


Экспортируйте URL-адрес в OPENFAAS_URL переменную:

export OPENFAAS_URL=[THE_URL_OF_YOUR_LOADBALANCER]:[THE_EXTERNAL_PORT]


Примечание. Этот URL-адрес понадобится вам позже в руководстве, например, для доступа к порталу пользовательского интерфейса. Вы можете увидеть это в любой момент в терминальной сессии, выполнив echo $OPENFAAS_URL.

И подключаемся к шлюзу:

echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin


Теперь вы подключены к шлюзу и можете отправлять команды на платформу OpenFaaS.

По умолчанию на вашей платформе OpenFaaS не установлено никаких функций, что вы можете проверить с помощью faas-cli listкоманды.

В моем собственном развертывании (URL-адреса и IP-адреса изменены для этого примера) предыдущие операции дали:

$ kubectl get svc -n openfaas gateway-external -o wide
 NAME               TYPE           CLUSTER-IP    EXTERNAL-IP                        PORT(S)          AGE     SELECTOR
 gateway-external   LoadBalancer   10.3.xxx.yyy   xxxrt657xx.lb.c1.gra.k8s.ovh.net   8080:30012/TCP   9m10s   app=gateway

 $ export OPENFAAS_URL=xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080

 $ echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin
 Calling the OpenFaaS server to validate the credentials...
 WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
 credentials saved for admin http://xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080

$ ./faas-cli version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|
CLI:
 commit:  b42d0703b6136cac7b0d06fa2b212c468b0cff92
 version: 0.8.11
Gateway
 uri:     http://xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080
 version: 0.13.0
 sha:     fa93655d90d1518b04e7cfca7d7548d7d133a34e
 commit:  Update test for metrics server
Provider
 name:          faas-netes
 orchestration: kubernetes
 version:       0.7.5 
 sha:           4d3671bae8993cf3fde2da9845818a668a009617

$ ./faas-cli list Function Invocations Replicas 


Развертывание и вызов функций

Вы можете легко развернуть функции на вашей платформе OpenFaaS с помощью интерфейса командной строки, с помощью этой команды: faas-cli up.

Давайте попробуем несколько примеров функций из репозитория OpenFaaS:

./faas-cli deploy -f https://raw.githubusercontent.com/openfaas/faas/master/stack.yml


Выполнение faas-cli listкоманды сейчас покажет развернутые функции:

$ ./faas-cli list
Function                          Invocations     Replicas
base64                            0               1    
echoit                            0               1    
hubstats                          0               1    
markdown                          0               1    
nodeinfo                          0               1    
wordcount                         0               1    


В качестве примера вызовем wordcount(функцию, которая принимает синтаксис команды unix wcи дает нам количество строк, слов и символов входных данных):

echo 'I love when a plan comes together' | ./faas-cli invoke wordcount


$ echo 'I love when a plan comes together' | ./faas-cli invoke wordcount
       1         7        34


Вызов функции без CLI

Вы можете использовать faas-cli describeкоманду, чтобы получить общедоступный URL-адрес вашей функции, а затем вызвать его напрямую из вашей любимой HTTP-библиотеки (или старой доброй curl):

$ ./faas-cli describe wordcount
Name:                wordcount
Status:              Ready
Replicas:            1
Available replicas:  1
Invocations:         1
Image:               functions/alpine:latest
Function process:    
URL:                 http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/function/wordcount
Async URL:           http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/async-function/wordcount
Labels:              faas_function : wordcount
Annotations:         prometheus.io.scrape : false

$ curl -X POST --data-binary "I love when a plan comes together" "http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/function/wordcount"
       0         7        33


Везде контейнеры ...

Самая привлекательная часть платформы FaaS — это возможность развертывать свои собственные функции.

В OpenFaaS вы можете написать эти функции на многих языках, а не только на обычных подозреваемых (JavaScript, Python, Go и т. Д.). Это связано с тем, что в OpenFaaS вы можете развернуть практически любой контейнер как функцию, хотя это означает, что вам нужно упаковать свои функции как контейнеры, чтобы развернуть их.

Это также означает, что для создания ваших собственных функций на вашей рабочей станции должен быть установлен Docker, и вам нужно будет поместить образы в реестр Docker (официальный или частный).

Если вам нужен частный реестр, вы можете установить его в кластере OVH Managed Kubernetes. В этом руководстве мы решили развернуть наш образ в официальном реестре Docker.

Написание нашей первой функции

В нашем первом примере мы собираемся создать и развернуть функцию приветственного слова в JavaScript, используя NodeJS. Начнем с создания и формирования папки функции:

mkdir hello-js-project
cd hello-js-project
../faas-cli new hello-js --lang node


Интерфейс командной строки загрузит шаблон функции JS из репозитория OpenFaaS, сгенерирует файл описания функции ( hello-js.ymlв данном случае) и папку для исходного кода функции ( hello-js). Для NodeJS вы найдете в этой папке package.json(например, для объявления возможных зависимостей вашей функции) и handler.js(основной код функции).

Отредактируйте, hello-js.yml чтобы задать имя изображения, которое вы хотите загрузить в реестр Docker:

version: 1.0
provider:
  name: openfaas
  gateway: http://6d6rt657vc.lb.c1.gra.k8s.ovh.net:8080
functions:
  hello-js:
    lang: node
    handler: ./hello-js
    image: ovhplatform/openfaas-hello-js:latest


Функция, описанная в handler.jsфайле, действительно проста. Он экспортирует функцию с двумя параметрами: a, contextкуда вы получите данные запроса, и a, callbackкоторый вы вызовете в конце своей функции, и куда вы передадите данные ответа.

handler.js
"use strict"

module.exports = (context, callback) => {
    callback(undefined, {status: "done"});
}


Давайте отредактируем его, чтобы отправить обратно наше приветственное сообщение:

"use strict"

module.exports = (context, callback) => {
    callback(undefined, {message: 'Hello world'});
}


Теперь вы можете создать образ Docker и отправить его в общедоступный реестр Docker:

# Build the image
../faas-cli build -f hello-js.yml
# Login at Docker Registry, needed to push the image
docker login     
# Push the image to the registry
../faas-cli push -f hello-js.yml


Поздравляю! Вы только что написали и развернули свою первую функцию OpenFaaS.

Использование портала пользовательского интерфейса OpenFaaS

Вы можете протестировать портал пользовательского интерфейса, указав в браузере URL-адрес шлюза OpenFaaS (тот, который вы указали для $OPENFAAS_URLпеременной) и при появлении запроса введите admin пользователя и пароль, который вы установили для $PASSWORD переменной.



В портале пользовательского интерфейса вы найдете список развернутых функций. Для каждой функции вы можете найти ее описание, вызвать ее и увидеть результат.







Куда мы отправимся отсюда?

Итак, теперь у вас есть рабочая платформа OpenFaaS в кластере OVH Managed Kubernetes.

Чтобы узнать больше об OpenFaaS и о том, как получить от него максимальную отдачу, обратитесь к официальной документации OpenFaaS. Вы также можете следить за семинарами по OpenFaaS, чтобы получить больше практических советов и советов.

Развертывание игровых серверов с Agones на OVH Managed Kubernetes

Одним из ключевых преимуществ использования Kubernetes является огромная экосистема вокруг него. От Rancher к Istio , от Грача до ДЕЛЕНИЯ , от gVisor к KubeDB , экосистема Kubernetes богата, живая и постоянно растет. Мы подходим к тому моменту, когда для большинства потребностей развертывания мы можем сказать, что для этого существует проект с открытым исходным кодом на основе K8s .

Одним из latests дополнений в этой экосистеме является Agones проект с открытым исходным кодом, мультиплеер, посвященный игровой сервер хостинг построен на Kubernetes, разработанный Google в сотрудничестве с Ubisoft . О проекте было объявлено в марте , и он уже наделал много шума…

В OVH Platform Team мы фанаты как онлайн-игр, так и Kubernetes, поэтому мы сказали себе, что нам нужно протестировать Agones. И что может быть лучше для его тестирования, чем развертывание в нашей службе OVH Managed Kubernetes , установка кластера игровых серверов Xonotic и участие в некоторых олдскульных смертельных матчах с коллегами?



И, конечно же, нам нужно было написать об этом, чтобы поделиться опытом…

Почему Агоны?

Agones ( происходящее от греческого слова ag, n, соревнования, проводимые во время публичных фестивалей или, в более общем смысле, «соревнование» или «соревнование в играх») призвано заменить обычные проприетарные решения для развертывания, масштабирования и управления игровыми серверами.

Agones обогащает Kubernetes настраиваемым контроллером и настраиваемым определением ресурса. С их помощью вы можете стандартизировать инструменты и API Kubernetes для создания, масштабирования и управления кластерами игровых серверов.

Постой, о каких игровых серверах ты говоришь?

Что ж, основное внимание Agones уделяется многопользовательским онлайн-играм, таким как FPS и MOBA, динамичным играм, требующим выделенных игровых серверов с малой задержкой, которые синхронизируют состояние игры между игроками и служат источником правды для игровых ситуаций.

Для таких игр требуются относительно недолговечные выделенные игровые серверы, где каждый матч выполняется на экземпляре сервера. Серверы должны иметь состояние (они должны сохранять состояние игры), при этом состояние обычно сохраняется в памяти на время матча.

Задержка — это ключевая проблема, поскольку соревновательные аспекты игр в реальном времени требуют быстрых ответов от сервера. Это означает, что подключение устройства игрока к игровому серверу должно быть максимально прямым, в идеале в обход любого промежуточного сервера, такого как балансировщик нагрузки.

А как подключить игроков к нужному серверу?

У каждого издателя игр были свои собственные проприетарные решения, но большинство из них следуют аналогичной схеме: со службой подбора игроков, которая группирует игроков в матч, взаимодействует с диспетчером кластера для предоставления выделенного экземпляра игрового сервера и отправки игрокам IP-адрес и порт, чтобы они могли напрямую подключаться к серверу и играть в игру.



Agones, его настраиваемый контроллер и настраиваемое определение ресурса заменяют сложную инфраструктуру управления кластером на стандартизированные инструменты и API на основе Kubernetes. Сервисы подбора игроков взаимодействуют с этими API для создания новых модулей игровых серверов и передачи их IP-адресов и портов заинтересованным игрокам.



Вишенка на торте

Использование Kubernetes для этих задач также дает приятный дополнительный бонус, например, возможность развернуть полную игровую инфраструктуру в среде разработчика (или даже в мини-кубе ) или легко клонировать ее для развертывания в новом центре обработки данных или облачном регионе, но также предлагая целую платформу для размещения всех дополнительных услуг, необходимых для создания игры: управление учетными записями, списки лидеров, инвентарь…

И, конечно же, простота использования платформ на базе Kubernetes, особенно когда они динамические, разнородные и распределенные, как большинство игровых онлайн-платформ.

Развертывание Agones в управляемом OVH Kubernetes

Есть несколько способов установить Agones в кластер Kubernetes. Для нашего теста мы выбрали самый простой: установку с помощью Helm.

Включение создания ресурсов RBAC

Первым шагом к установке Agones является настройка учетной записи службы с достаточными разрешениями для создания некоторых специальных типов ресурсов RBAC.

kubectl cre

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin --serviceaccount=kube-system:default


Теперь у нас есть привязка роли кластера, необходимая для установки.

Установка диаграммы Agones

Теперь продолжим, добавив репозиторий Agones в список репозиториев Helm.

helm repo add agones https://agones.dev/chart/stable


А затем установите стабильную диаграмму Agones:

helm install --name my-agones --namespace agones-system agones/agones


Только что выполненная установка не подходит для производства, поскольку официальные инструкции по установке рекомендуют запускать Agones и игровые серверы в отдельных выделенных пулах узлов. Но для нужд нашего теста достаточно базовой настройки.

Подтверждение успешного запуска Agones

Чтобы убедиться, что Agones работает в нашем кластере Kubernetes, мы можем взглянуть на поды в agones-systemпространстве имен:

kubectl get --namespace agones-system pods


Если все в порядке, вы должны увидеть agones-controllerмодуль со статусом " Работает":

$ kubectl get --namespace agones-system pods
NAME                                 READY   STATUS    RESTARTS   AGE
agones-controller-5f766fc567-xf4vv   1/1     Running   0          5d15h
agones-ping-889c5954d-6kfj4          1/1     Running   0          5d15h
agones-ping-889c5954d-mtp4g          1/1     Running   0          5d15h


Вы также можете увидеть более подробную информацию, используя:

kubectl describe --namespace agones-system pods


Посмотрев на agones-controllerописание, вы должны увидеть что-то вроде:

$ kubectl describe --namespace agones-system pods
Name:               agones-controller-5f766fc567-xf4vv
Namespace:          agones-system
[...]
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 


Где все Conditionsдолжно иметь статус True.

Развертывание игрового сервера

Мир Agones Hello довольно скучный, простой эхо-сервер UDP, поэтому мы решили пропустить его и перейти непосредственно к чему-то более интересному: игровому серверу Xonotic.

Xonotic — это многопользовательский шутер от первого лица с открытым исходным кодом, и довольно хороший, с множеством интересных игровых режимов, карт, оружия и параметров настройки.

Развернуть игровой сервер Xonotic поверх Agones довольно просто:

kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/agones/release-0.9.0/examples/xonotic/gameserver.yaml


Развертывание игрового сервера может занять некоторое время, поэтому нам нужно дождаться его статуса, Readyпрежде чем его использовать. Мы можем получить статус с помощью:


kubectl get gameserver


Мы ждем, пока выборка не выдаст Readyстатус на нашем игровом сервере:

$ kubectl get gameserver
NAME      STATE   ADDRESS         PORT   NODE       AGE
xonotic   Ready   51.83.xxx.yyy   7094   node-zzz   5d


Когда игровой сервер готов, мы также получаем адрес и порт, который мы должны использовать для подключения к нашей игре deathmatch (в моем примере 51.83.xxx.yyy:7094).

Время фрага

Итак, теперь, когда у нас есть сервер, давайте протестируем его!

Мы загрузили клиент Xonotic для наших компьютеров (он работает в Windows, Linux и MacOS, поэтому нет оправдания) и запустили его:



Затем заходим в меню многопользовательской игры и вводим адрес и порт нашего игрового сервера:



И мы готовы играть!



А на стороне сервера?

На стороне сервера мы можем следить за тем, как идут дела на нашем игровом сервере, используя kubectl logs. Начнем с поиска модуля, в котором запущена игра:

kubectl get pods


Мы видим, что наш игровой сервер работает в модуле под названием xonotic:

$ kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
xonotic   2/2     Running   0          5d15h


Затем мы можем использовать kubectl logsего. В модуле есть два контейнера, основной xonoticи вспомогательный Agones, поэтому мы должны указать, что нам нужны журналы xonoticконтейнера:

$ kubectl logs xonotic
Error from server (BadRequest): a container name must be specified for pod xonotic, choose one of: [xonotic agones-gameserver-sidecar]
$ kubectl logs xonotic xonotic
>>> Connecting to Agones with the SDK
>>> Starting health checking
>>> Starting wrapper for Xonotic!
>>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh 
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:03:50 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
execing quake.rc
[...]
Authenticated connection to 109.190.xxx.yyy:42475 has been established: client is v6xt9/GlzxBH+xViJCiSf4E/SCn3Kx47aY3EJ+HOmZo=@Xon//Ks, I am /EpGZ8F@~Xon//Ks
LostInBrittany is connecting...
url_fclose: failure in crypto_uri_postbuf
Receiving player stats failed: -1
LostInBrittany connected
LostInBrittany connected
LostInBrittany is now spectating
[BOT]Eureka connected
[BOT]Hellfire connected
[BOT]Lion connected
[BOT]Scorcher connected
unconnected changed name to [BOT]Eureka
unconnected changed name to [BOT]Hellfire
unconnected changed name to [BOT]Lion
unconnected changed name to [BOT]Scorcher
[BOT]Scorcher picked up Strength
[BOT]Scorcher drew first blood! 
[BOT]Hellfire was gunned down by [BOT]Scorcher's Shotgun
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was gunned down by [BOT]Eureka's Shotgun, ending their 2 frag spree
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was shot to death by [BOT]Eureka's Blaster
[BOT]Hellfire slapped [BOT]Eureka around a bit with a large Shotgun, ending their 2 frag spree
[BOT]Eureka slapped [BOT]Scorcher around a bit with a large Shotgun
[BOT]Eureka was gunned down by [BOT]Hellfire's Shotgun
[BOT]Hellfire was shot to death by [BOT]Lion's Blaster, ending their 2 frag spree
[BOT]Scorcher was cooked by [BOT]Lion
[BOT]Eureka turned into hot slag
[...]


Добавить друзей…

Следующий шаг в основном доставляет удовольствие: попросить коллег подключиться к серверу и провести настоящий смертельный бой, как в Quake 2 раза.

И сейчас?

У нас есть рабочий игровой сервер, но мы едва раскрыли возможности Agones: развертывание флота (набор теплых игровых серверов, которые доступны для распределения), тестирование FleetAutoscaler (для автоматического увеличения и уменьшения флота в ответ на спроса), создавая некую фиктивную службу распределения. В следующих статьях блога мы углубимся в это и исследуем эти возможности.

И в более широком контексте мы продолжим наше исследовательское путешествие на Agones. Проект еще очень молодой, на ранней стадии альфа, но он показывает некоторые впечатляющие перспективы.

Как отслеживать свой кластер Kubernetes с помощью OVH Observability

Наши коллеги из команды K8S на прошлой неделе запустили решение OVH Managed Kubernetes, в котором они управляют главными компонентами Kubernetes и создают ваши узлы поверх нашего решения Public Cloud. Я не буду описывать здесь детали того, как это работает, но в блогах уже есть много сообщений об этом ( здесь и здесь, чтобы вы начали).

В команде Prescience мы используем Kubernetes уже больше года. Наш кластер включает 40 узлов, работающих поверх PCI. Мы постоянно запускаем около 800 модулей и в результате генерируем множество показателей.

Сегодня мы рассмотрим, как мы обрабатываем эти метрики для мониторинга нашего кластера Kubernetes, и (что не менее важно!) Как это сделать с вашим собственным кластером.

Показатели OVH

Как и в любой другой инфраструктуре, вам необходимо отслеживать свой кластер Kubernetes. Вам необходимо точно знать, как ведут себя ваши узлы, кластер и приложения после их развертывания, чтобы предоставлять надежные услуги вашим клиентам. Чтобы сделать это с нашим собственным кластером, мы используем OVH Observability.

OVH Observability не зависит от серверной части, поэтому мы можем передавать метрики в одном формате и запрашивать в другом. Он может обрабатывать:

  • Graphite
  • InfluxDB
  • Metrics2.0
  • OpentTSDB
  • Prometheus
  • Warp10

Он также включает управляемую Grafana для отображения показателей и создания панелей мониторинга.

Узлы мониторинга

Первое, что нужно контролировать, — это состояние узлов. Все остальное начинается с этого.

Чтобы контролировать ваши узлы, мы будем использовать Noderig и Beamium, как описано здесь. Мы также будем использовать Kubernetes DaemonSets для запуска процесса на всех наших узлах.



Итак, приступим к созданию пространства имен…

kubectl create namespace metrics


Затем создайте секрет с метриками токена записи, которые вы можете найти в панели управления OVH.

kubectl create secret generic w10-credentials --from-literal=METRICS_TOKEN=your-token -n metrics


Скопируйте metrics.ymlв файл и примените конфигурацию с помощью kubectl

metrics.yml
# This will configure Beamium to scrap noderig
# And push metrics to warp 10
# We also add the HOSTNAME to the labels of the metrics pushed
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: beamium-config
  namespace: metrics
data:
  config.yaml: |
    scrapers:
      nodering:
        url: http://0.0.0.0:9100/metrics
        period: 30000
        format: sensision
        labels:
          app: nodering

    sinks:
      warp:
        url: https://warp10.gra1.metrics.ovh.net/api/v0/update
        token: $METRICS_TOKEN

    labels:
      host: $HOSTNAME

    parameters:
      log-file: /dev/stdout
---
# This is a custom collector that report the uptime of the node
apiVersion: v1
kind: ConfigMap
metadata:
  name: noderig-collector
  namespace: metrics
data:
  uptime.sh: |
    #!/bin/sh
    echo 'os.uptime' `date +%s%N | cut -b1-10` `awk '{print $1}' /proc/uptime`
---
kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: metrics-daemon
  namespace: metrics
spec:
  selector:
    matchLabels:
      name: metrics-daemon
  template:
    metadata:
      labels:
        name: metrics-daemon
    spec:
      terminationGracePeriodSeconds: 10
      hostNetwork: true
      volumes:
      - name: config
        configMap:
          name: beamium-config
      - name: noderig-collector
        configMap:
          name: noderig-collector
          defaultMode: 0777
      - name: beamium-persistence
        emptyDir:{}
      containers:
      - image: ovhcom/beamium:latest
        imagePullPolicy: Always
        name: beamium
        env:
        - name: HOSTNAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: TEMPLATE_CONFIG
          value: /config/config.yaml
        envFrom:
        - secretRef:
            name: w10-credentials
            optional: false
        resources:
          limits:
            cpu: "0.05"
            memory: 128Mi
          requests:
            cpu: "0.01"
            memory: 128Mi
        workingDir: /beamium
        volumeMounts:
        - mountPath: /config
          name: config
        - mountPath: /beamium
          name: beamium-persistence
      - image: ovhcom/noderig:latest
        imagePullPolicy: Always
        name: noderig
        args: ["-c", "/collectors", "--net", "3"]
        volumeMounts:
        - mountPath: /collectors/60/uptime.sh
          name: noderig-collector
          subPath: uptime.sh
        resources:
          limits:
            cpu: "0.05"
            memory: 128Mi
          requests:
            cpu: "0.01"
            memory: 128Mi

Не стесняйтесь менять уровни коллектора, если вам нужна дополнительная информация.

Затем примените конфигурацию с помощью kubectl…

$ kubectl apply -f metrics.yml
# Then, just wait a minutes for the pods to start
$ kubectl get all -n metrics
NAME                       READY   STATUS    RESTARTS   AGE
pod/metrics-daemon-2j6jh   2/2     Running   0          5m15s
pod/metrics-daemon-t6frh   2/2     Running   0          5m14s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE AGE
daemonset.apps/metrics-daemon 40        40        40      40           40          122d


Вы можете импортировать нашу панель управления в свою Grafana отсюда и сразу же просматривать некоторые показатели о ваших узлах.



OVH Метрики

Поскольку OVH Kube — это управляемая служба, вам не нужно контролировать apiserver, etcd или панель управления. Об этом позаботится команда OVH Kubernetes. Поэтому мы сосредоточимся на показателях cAdvisor и показателях состояния Kube.

Самым зрелым решением для динамического считывания метрик внутри Kube (на данный момент) является Prometheus.


В следующем выпуске Beamium мы сможем воспроизвести функции скребка Prometheus.


Чтобы установить сервер Prometheus, вам необходимо установить Helm в кластере…

kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller \
    --clusterrole cluster-admin \
    --serviceaccount=kube-system:tiller
helm init --service-account tiller


Затем вам нужно создать следующие два файла: prometheus.yml и values.yml.

# Based on https://github.com/prometheus/prometheus/blob/release-2.2/documentation/examples/prometheus-kubernetes.yml
serverFiles:
  prometheus.yml:
    remote_write:
    - url: "https://prometheus.gra1.metrics.ovh.net/remote_write"
      remote_timeout: 120s
      bearer_token: $TOKEN
      write_relabel_configs:
      # Filter metrics to keep
      - action: keep
        source_labels: [__name__]
        regex: "eagle.*|\
            kube_node_info.*|\
            kube_node_spec_taint.*|\
            container_start_time_seconds|\
            container_last_seen|\
            container_cpu_usage_seconds_total|\
            container_fs_io_time_seconds_total|\
            container_fs_write_seconds_total|\
            container_fs_usage_bytes|\
            container_fs_limit_bytes|\
            container_memory_working_set_bytes|\
            container_memory_rss|\
            container_memory_usage_bytes|\
            container_network_receive_bytes_total|\
            container_network_transmit_bytes_total|\
            machine_memory_bytes|\
            machine_cpu_cores"

    scrape_configs:
    # Scrape config for Kubelet cAdvisor.
    - job_name: 'kubernetes-cadvisor'
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: node
      
      relabel_configs:
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
        
      metric_relabel_configs:
      # Only keep systemd important services like docker|containerd|kubelet and kubepods,
      # We also want machine_cpu_cores that don't have id, so we need to add the name of the metric in order to be matched
      # The string will concat id with name and the separator is a ;
      # `/;container_cpu_usage_seconds_total` OK
      # `/system.slice;container_cpu_usage_seconds_total` OK
      # `/system.slice/minion.service;container_cpu_usage_seconds_total` NOK, Useless
      # `/kubepods/besteffort/e2514ad43202;container_cpu_usage_seconds_total` Best Effort POD OK
      # `/kubepods/burstable/e2514ad43202;container_cpu_usage_seconds_total` Burstable POD OK
      # `/kubepods/e2514ad43202;container_cpu_usage_seconds_total` Guaranteed POD OK
      # `/docker/pod104329ff;container_cpu_usage_seconds_total` OK, Container that run on docker but not managed by kube
      # `;machine_cpu_cores` OK, there is no id on these metrics, but we want to keep them also
      - source_labels: [id,__name__]
        regex: "^((/(system.slice(/(docker|containerd|kubelet).service)?|(kubepods|docker).*)?);.*|;(machine_cpu_cores|machine_memory_bytes))$"
        action: keep
      # Remove Useless parents keys like `/kubepods/burstable` or `/docker`
      - source_labels: [id]
        regex: "(/kubepods/burstable|/kubepods/besteffort|/kubepods|/docker)"
        action: drop
        # cAdvisor give metrics per container and sometimes it sum up per pod
        # As we already have the child, we will sum up ourselves, so we drop metrics for the POD and keep containers metrics
        # Metrics for the POD don't have container_name, so we drop if we have just the pod_name
      - source_labels: [container_name,pod_name]
        regex: ";(.+)"
        action: drop
    
    # Scrape config for service endpoints.
    - job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name

    # Example scrape config for pods
    #
    # The relabeling allows the actual pod scrape endpoint to be configured via the
    # following annotations:
    #
    # * `prometheus.io/scrape`: Only scrape pods that have a value of `true`
    # * `prometheus.io/path`: If the metrics path is not `/metrics` override this.
    # * `prometheus.io/port`: Scrape the pod on the indicated port instead of the
    # pod's declared ports (default is a port-free target if none are declared).
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod

      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: pod_name
      - source_labels: [__meta_kubernetes_pod_node_name]
        action: replace
        target_label: host
      - action: labeldrop
        regex: (pod_template_generation|job|release|controller_revision_hash|workload_user_cattle_io_workloadselector|pod_template_hash)


values.yml
alertmanager:
  enabled: false
pushgateway:
  enabled: false
nodeExporter:
  enabled: false
server:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: traefik
      ingress.kubernetes.io/auth-type: basic
      ingress.kubernetes.io/auth-secret: basic-auth
    hosts:
    - prometheus.domain.com
  image:
    tag: v2.7.1
  persistentVolume:
    enabled: false


Не забудьте заменить свой токен!

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

Установите его с помощью Helm…

helm install stable/prometheus \
    --namespace=metrics \
    --name=metrics \
    --values=values/values.yaml \
    --values=values/prometheus.yaml


Добавить добавить секрет базовой аутентификации…

$ htpasswd -c auth foo
New password: <bar>
New password:
Re-type new password:
Adding password for user foo
$ kubectl create secret generic basic-auth --from-file=auth -n metrics
secret "basic-auth" created


Вы можете получить доступ к интерфейсу сервера Prometheus через prometheus.domain.com.



Вы увидите все показатели для своего кластера, хотя только тот, который вы отфильтровали, будет перенесен в метрики OVH.

Интерфейсы Prometheus — хороший способ изучить ваши метрики, поскольку довольно просто отображать и контролировать вашу инфраструктуру. Вы можете найти нашу панель управления здесь.



Метрики ресурсов

Как сказал @ Martin Schneppenheim в этом посте, для правильного управления кластером Kubernetes вам также необходимо отслеживать ресурсы пода.

Мы установим Kube Eagle, который будет извлекать и предоставлять некоторые метрики о запросах и ограничениях ЦП и ОЗУ, чтобы они могли быть получены только что установленным сервером Prometheus.



Создайте файл с именем eagle.yml.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  labels:
    app: kube-eagle
  name: kube-eagle
  namespace: kube-eagle
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  labels:
    app: kube-eagle
  name: kube-eagle
  namespace: kube-eagle
subjects:
- kind: ServiceAccount
  name: kube-eagle
  namespace: kube-eagle
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-eagle
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: kube-eagle
  labels:
    app: kube-eagle
  name: kube-eagle
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: kube-eagle
  name: kube-eagle
  labels:
    app: kube-eagle
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-eagle
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/metrics"
      labels:
        app: kube-eagle
    spec:
      serviceAccountName: kube-eagle
      containers:
      - name: kube-eagle
        image: "quay.io/google-cloud-tools/kube-eagle:1.0.0"
        imagePullPolicy: IfNotPresent
        env:
        - name: PORT
          value: "8080"
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /health
            port: http
        readinessProbe:
          httpGet:
            path: /health
            port: http


$ kubectl create namespace kube-eagle
$ kubectl apply -f eagle.yml


Затем добавьте импорт этой панели управления Grafana (это та же панель, что и Kube Eagle, но перенесена на Warp10).



Теперь у вас есть простой способ контролировать ресурсы вашего модуля в кластере!

Пользовательские показатели

Как Прометей узнает, что ему нужно соскрести куба-орла? Если вы посмотрите на метаданные eagle.yml, вы увидите, что:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "8080" # The port where to find the metrics
  prometheus.io/path: "/metrics" # The path where to find the metrics


Эти аннотации запустят процесс автоматического обнаружения Prometheus (описанный в prometheus.ymlстроке 114).

Это означает, что вы можете легко добавить эти аннотации к модулям или службам, которые содержат экспортер Prometheus, а затем пересылать эти метрики в OVH Observability. Вы можете найти неполный список экспортеров Прометея здесь.



Объемный анализ

Как вы видели на странице prometheus.yml, мы попытались отфильтровать множество бесполезных показателей. Например, cAdvisor в новом кластере, всего с тремя настоящими производственными модулями, а также со всей системой kube и пространством имен Prometheus, имеет около 2600 метрик на узел. Используя интеллектуальный подход к очистке, вы можете сократить это количество до 126 серий.

Вот таблица, показывающая приблизительное количество метрик, которые вы создадите, в зависимости от количества узлов (N) и количества производственных модулей (P), которые у вас есть:



Например, если вы запустите три узла с 60 подами, вы сгенерируете 264 * 3 + 32 * 60 ~ = 2700 метрик.

NB: модуль имеет уникальное имя, поэтому при повторном развертывании развертывания вы будете каждый раз создавать 32 новых метрики.

(1) Метрики Noderig: os.mem / os.cpu / os.disk.fs / os.load1 / os.net.dropped (in/out) / os.net.errs (in/out) / os.net.packets (in/out) / os.net.bytes (in/out)/ os.uptime

(2) метрики узлов cAdvisor: machine_memory_bytes / machine_cpu_cores

(3) Метрики узлов состояния Kube: kube_node_info

(4) Показатели узлов Kube Eagle: eagle_node_resource_allocatable_cpu_cores / eagle_node_resource_allocatable_memory_bytes / eagle_node_resource_limits_cpu_cores / eagle_node_resource_limits_memory_bytes / eagle_node_resource_requests_cpu_cores / eagle_node_resource_requests_memory_bytes / eagle_node_resource_usage_cpu_cores / eagle_node_resource_usage_memory_bytes

(5) С помощью наших фильтров мы будем отслеживать около пяти system.slices.

(6) Показатели указываются для каждого контейнера. Pod — это набор контейнеров (минимум два): ваш контейнер + контейнер паузы для сети. Таким образом, мы можем рассматривать (2 * 10 + 6) для количества метрик в пакете. 10 показателей из cAdvisor и шесть для сети (см. Ниже) и для system.slice у нас будет 10 + 6, потому что он рассматривается как один контейнер.

(7) cAdvisor предоставит следующие показатели для каждого контейнера :container_start_time_seconds / container_last_seen / container_cpu_usage_seconds_total / container_fs_io_time_seconds_total / container_fs_write_seconds_total / container_fs_usage_bytes / container_fs_limit_bytes / container_memory_working_set_bytes / container_memory_rss / container_memory_usage_bytes

(8) cAdvisor предоставит следующие показатели для каждого интерфейса: container_network_receive_bytes_total * per interface / container_network_transmit_bytes_total * per interface

(9) kube-dns / beamium-noderig-metrics / kube-proxy / canal / metrics-server

(10) Показатели модулей Kube Eagle: eagle_pod_container_resource_limits_cpu_cores / eagle_pod_container_resource_limits_memory_bytes / eagle_pod_container_resource_requests_cpu_cores / eagle_pod_container_resource_requests_memory_bytes / eagle_pod_container_resource_usage_cpu_cores / eagle_pod_container_resource_usage_memory_bytes

Вывод

Как видите, отслеживать кластер Kubernetes с помощью OVH Observability очень просто. Вам не нужно беспокоиться о том, как и где хранить свои метрики, и вы можете сосредоточиться на использовании кластера Kubernetes для эффективной обработки бизнес-нагрузок, как это делаем мы в группе обслуживания машинного обучения.

Следующим шагом будет добавление системы предупреждений, чтобы уведомить вас, когда ваши узлы не работают (например). Для этого вы можете использовать бесплатный инструмент OVH Alert Monitoring.

Получение внешнего трафика в Kubernetes - ClusterIp, NodePort, LoadBalancer и Ingress

За последние несколько месяцев, я действовал в качестве  Защитника Developer для  OVH Managed Kubernetes беты , следуя наши бета - тестеры, получать обратную связь, писать документы и учебники, и в целом помогаю убедиться , продукт соответствует потребностям наших пользователей настолько близко , насколько это возможно.

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



Сегодня мы начнем с одного из самых частых вопросов, которые я задавал  в первые дни бета-тестирования:  как направить внешний трафик в мою службу Kubernetes? Этот вопрос возник часто, когда наши клиенты начали изучать Kubernetes, и когда я попытался ответить на него, я понял, что часть проблемы заключается в огромном количестве  возможных ответов и концепциях, необходимых для их понимания.

С этим вопросом был связан запрос функции : большинству пользователей нужен инструмент балансировки нагрузки Поскольку бета-версия предназначена для подтверждения стабильности продукта и проверки приоритетов набора функций, мы смогли быстро подтвердить 
LoadBalancer
ключевую функцию нашего первого коммерческого выпуска.

Чтобы попытаться лучше ответить на вопрос о внешнем трафике и упростить внедрение 
LoadBalancer
, мы написали руководство и добавили несколько рисунков, которые получили хорошие отзывы. Это помогло людям понять концепцию, лежащую в основе маршрутизации внешнего трафика в Kubernetes.

Это сообщение в блоге представляет собой расширенную версию этого руководства. Надеемся, оно вам пригодится!

Некоторые понятия: ClusterIP, NodePort, Ingress и LoadBalancer

Когда вы начинаете использовать Kubernetes для реальных приложений, один из первых вопросов, который нужно задать, — как получить внешний трафик в вашем кластере. В официальной документации предлагает полное (но довольно сухое) объяснение этой темы, но здесь мы будем объяснять его в более практических, служебной необходимости знать пути.

Есть несколько способов перенаправить внешний трафик в ваш кластер:

1. Использование Kubernetes прокси и ClusterIP: По умолчанию значения Kubernetes ServiceType является ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ к ClusterIp из внешнего источника, вы можете открыть прокси Kubernetes между внешним источником и кластером. Обычно это используется только для разработки.

2. Предоставление сервисов как NodePort: объявление Service as открывает NodePortего на IP-адресе каждого узла на статическом порте (называемом NodePort). Затем вы можете получить доступ к Service извне кластера, запросив :. Это также можно использовать для производства, хотя и с некоторыми ограничениями.

3. Предоставление услуг как LoadBalancer: объявление Service as LoadBalancer предоставляет его внешнему виду с помощью решения балансировки нагрузки поставщика облачных услуг. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Это наиболее широко используемый метод в производственной среде.

Использование прокси Kubernetes и ClusterIP

По умолчанию Kubernetes ServiceType это ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ ClusterIp с внешнего компьютера, вы можете открыть прокси Kubernetes между внешним компьютером и кластером.

Вы можете использовать kubectl для создания такого прокси. Когда прокси включен, вы напрямую подключены к кластеру и можете использовать для этого внутренний IP-адрес (ClusterIp) Service.



Этот метод не подходит для производственной среды, но он полезен для разработки, отладки и других быстрых и грязных операций.

Предоставление услуг как NodePort

Объявление службы как NodePort раскрывает Service IP-адрес каждого узла в NodePort (фиксированный порт для этого Serviceв диапазоне по умолчанию 30000-32767). Затем вы можете получить доступ к Service извне кластера, запросив :. Каждая служба, которую вы развертываете, NodePort будет отображаться в своем собственном порту на каждом узле.



Это довольно громоздким, чтобы использовать NodePortдля, Servicesкоторые находятся в производстве. Поскольку вы используете нестандартные порты, вам часто нужно настроить внешний балансировщик нагрузки, который прослушивает стандартные порты и перенаправляет трафик на :.

Предоставление услуг как LoadBalancer

Объявление службы типа LoadBalancer предоставляет ее внешнему виду с помощью балансировщика нагрузки облачного провайдера. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Как трафик от этого внешнего балансировщика нагрузки направляется в Service модули, зависит от поставщика кластера.



Это LoadBalancer лучший вариант для производственной среды, но с двумя оговорками:

  • Все, Service что вы развернете LoadBalancer, получит собственный IP.
  • LoadBalancer Обычно выставлен счет на основании количества выставляемых услуг, которые могут быть дорогими.


В настоящее время мы предлагаем услугу OVH Managed Kubernetes LoadBalancer в качестве бесплатной предварительной версии до конца лета 2019 года.

О чем Ingress?

Согласно официальной документации, Ingress это объект API, который управляет внешним доступом к службам в кластере (обычно HTTP). Так в чем разница между этим и LoadBalancer или NodePort?

Ingress это не тип Service, а объект, который действует как обратный прокси-сервер и единственная точка входа в ваш кластер, который направляет запрос различным службам. Самый простой из них Ingress — это NGINX Ingress Controller, где NGINX берет на себя роль обратного прокси, а также работает как SSL.



Ingress ClusterIP доступен за пределами кластера через прокси Kubernetes NodePort, или LoadBalancer, и направляет входящий трафик в соответствии с настроенными правилами.



Основное преимущество использования Ingress за одним LoadBalancer — это стоимость: вы можете иметь множество услуг за одним LoadBalancer.

Какой мне использовать?

Что ж, это вопрос на миллион долларов, и он, вероятно, вызовет разный ответ в зависимости от того, кого вы спросите!

Вы можете пойти на все 100% LoadBalancer, получив индивидуальную LoadBalancer услугу. Концептуально это просто: каждая служба независима и не требует дополнительной настройки. Обратной стороной является цена (вы будете платить за одну LoadBalancer услугу), а также сложность управления множеством разных IP-адресов.

Вы также можете использовать только один LoadBalancer и Ingress позади него. Все ваши службы будут находиться под одним и тем же IP-адресом, каждая по своему пути. Это более дешевый подход, поскольку вы платите только за одну LoadBalancer, но если ваши услуги не имеют логической взаимосвязи, это может быстро стать хаотичным.

Если вы хотите узнать мое личное мнение, я бы попытался использовать комбинацию из двух…

Подход мне нравится, имеющий LoadBalancer для каждого соответствующего набора услуг, а затем маршрутизации этих услуг используя Ingressпозади LoadBalancer. Например, предположим, что у вас есть два разных API на основе микросервисов, каждый из которых содержит около 10 сервисов. Я бы поставил один LoadBalancerперед другим Ingressдля каждого API, LoadBalancerпоскольку это единственная общедоступная точка входа и Ingressмаршрутизация трафика к различным службам API.

Но если ваша архитектура достаточно сложна (особенно если вы используете микросервисы), вы скоро обнаружите, что управлять всем вручную с помощью LoadBalancer и Ingress довольно громоздко. Если это так, ответом может быть делегирование этих задач сервисной сети…

Что такое сервисная сетка?

Возможно, вы слышали об Istio или Linkerd и о том, как они упрощают создание микросервисных архитектур на Kubernetes, добавляя изящные льготы, такие как A / B-тестирование, канареечные выпуски, ограничение скорости, контроль доступа и сквозную аутентификацию.

Istio, Linkerd и аналогичные инструменты представляют собой сети служб, которые позволяют создавать сети микросервисов и определять их взаимодействия, одновременно добавляя некоторые важные функции, которые упрощают настройку и работу архитектур на основе микросервисов.

Когда дело доходит до использования сервисных мешей в Kubernetes, есть о чем поговорить, но, как говорится, это уже история для другого раза…

Понимание CI / CD для больших данных и машинного обучения

На этой неделе команда OVH Integration and Continuous Deployment была приглашена на подкаст DataBuzzWord .



Вместе мы исследовали тему непрерывного развертывания в контексте машинного обучения и больших данных. Мы также обсудили непрерывное развертывание для таких сред , как Kubernetes , Docker, OpenStack и VMware VSphere .

Если вы его пропустили или хотите пересмотреть все, что обсуждалось, вы можете прослушать его еще раз здесь . Мы надеемся скоро вернуться, чтобы продолжить разделять нашу страсть к тестированию, интеграции и непрерывному развертыванию.

Хотя подкаст был записан на французском языке, начиная с завтрашнего дня мы углубимся в ключевые моменты нашего обсуждения в серии статей в этом блоге.

Найдите CDS на GitHub:


…. и подписывайтесь на нас в Twitter:


Обсудите эти темы с нами на нашем канале Gitter: https://gitter.im/ovh-cds/

Kubinception и etcd

Запуск Kubernetes поверх Kubernetes был хорошей идеей для компонентов уровня управления без сохранения состояния… но как насчет etcd?



В нашем предыдущем посте мы описали архитектуру Kubinception, как мы запускаем Kubernetes поверх Kubernetes для компонентов без сохранения состояния на плоскостях управления клиентских кластеров. Но как насчет компонента с отслеживанием состояния, etcd?

Необходимость очевидна: каждый кластер клиентов должен иметь доступ к etcd, чтобы иметь возможность хранить и извлекать данные. Весь вопрос в том, где и как развернуть etcd, чтобы сделать его доступным каждому клиентскому кластеру.

Самая простая идея не всегда бывает удачной

Первый подход заключается в простом следовании логике Kubinception : для каждого кластера клиентов развертывание кластера etcd в качестве модулей, работающих в кластере администрирования.



Этот полный подход Kubinception имеет то преимущество, что он прост , он кажется расширением того, что мы делаем с компонентами без сохранения состояния. Но при детальном рассмотрении обнаруживаются его недостатки . Развертывание кластера etcd не так просто и просто, как развертывание без сохранения состояния, и, будучи критически важным для работы кластера, мы не могли просто справиться с этим вручную , нам нужен был автоматизированный подход для управления им на более высоком уровне.

Использование оператора

Не только мы думали, что сложность развертывания и эксплуатации кластера etcd в Kubernetes была чрезмерной, разработчики CoreOS заметили это и в 2016 году выпустили элегантное решение проблемы: etcd оператор .

Оператор — это особый контроллер, который расширяет Kubernetes API, чтобы легко создавать, настраивать и управлять экземплярами сложных (часто распределенных) приложений с отслеживанием состояния в Kubernetes. Для справки, понятие оператора было введено в CoreOS оператором etcd .



Оператор etcd управляет кластерами etcd, развернутыми в Kubernetes, и автоматизирует рабочие задачи: создание, уничтожение, изменение размера, восстановление после сбоя, последовательное обновление, резервное копирование…

Как и в предыдущем решении, кластер etcd для каждого клиентского кластера развертывается в виде модулей в административном кластере. По умолчанию оператор etcd развертывает кластер etcd, используя локальное непостоянное хранилище для каждого модуля etcd. Это означает, что если все поды умрут (что маловероятно) или будут перенесены и будут созданы на другом узле (что гораздо более вероятно), мы можем потерять данные etcd . А без него клиентские Kubernetes замурованы.

Оператор etcd можно настроить на использование постоянных томов (PV) для хранения данных, поэтому теоретически проблема была решена. Теоретически, потому что управление томами не было достаточно зрелым, когда мы его тестировали, и если модуль etcd был убит и перепланирован, новый модуль не смог получить свои данные на PV. Таким образом, риск полной потери кворума и блокировки клиентского кластера все еще оставался у оператора etcd.
Короче говоря, мы немного поработали с оператором etcd и сочли его недостаточно зрелым для нашего использования.

StatefulSet

Помимо оператора, еще одним решением было использование StatefulSet , разновидность распределенного развертывания, хорошо подходящего для управления распределенными приложениями с отслеживанием состояния.

Существует официальная диаграмма ETCD Helm, которая позволяет развертывать кластеры ETCD как StafefulSets, в которой некоторая гибкость оператора и удобство использования сводятся к более надежному управлению PV, которое гарантирует, что перенесенный модуль etcd получит свои данные.



Etcd StatefulSet менее удобен , чем оператор etcd, поскольку он не предлагает простой API для таких операций, как масштабирование, переключение при отказе, последовательное обновление или резервное копирование. Взамен вы получите реальные улучшения в управлении фотоэлектрической системой . StatefulSet поддерживает закрепленную идентичность для каждого сообщения etcd, и этот постоянный идентификатор сохраняется при любом изменении расписания , что позволяет просто связать его с его PV.

Система настолько устойчива, что, даже если мы потеряем все поды etcd, когда Kubernetes изменит их расписание, они найдут свои данные, и кластер продолжит работать без проблем.

Постоянные тома, задержка и простой расчет затрат

Etcd StatefulSet казался хорошим решением … пока мы не начали интенсивно его использовать. Etcd StatefulSet использует PV, то есть тома сетевого хранилища . И etcd довольно чувствителен к задержкам в сети , их производительность сильно падает, когда они сталкиваются с задержками.

Даже если бы задержку можно было контролировать (и это большое « если» ), чем больше мы думали об этой идее, тем больше она казалась дорогим решением. Для каждого клиентского кластера нам потребуется развернуть три модуля (фактически удваивая количество модулей ) и три связанных PV, это плохо масштабируется для управляемой услуги.

В сервисе OVH Managed Kubernetes мы выставляем счет нашим клиентам в соответствии с количеством используемых ими рабочих узлов, т.е. плоскость управления бесплатна. Это означает, что для того, чтобы сервис был конкурентоспособным, важно держать под контролем ресурсы, потребляемые плоскостями управления, чтобы не удваивать количество модулей с помощью etcd.

С Kubinception мы пытались мыслить нестандартно , казалось, что для etcd нам нужно снова выйти из этой коробки.

Многопользовательский кластер etcd

Если мы не хотели развертывать etcd внутри Kubernetes, альтернативой было развертывание снаружи. Мы решили развернуть мультитенантный кластер etcd на выделенных серверах . Все клиентские кластеры будут использовать один и тот же ETCD, каждый сервер API получит свое собственное пространство в этом мультитенантном кластере etcd.



Благодаря этому решению надежность гарантируется обычными механизмами etcd, нет проблем с задержкой, поскольку данные находятся на локальном диске каждого узла etcd, а количество модулей остается под контролем, поэтому оно решает основные проблемы, которые у нас были с другое решение. Компромисс здесь является то , что нам нужно установить и эксплуатировать этот внешний etcd кластер и управление контролем доступа , чтобы убедиться , что каждый сервер доступ API только для своих собственных данных.

Что дальше?

В следующих статьях серии Kubernetes мы погрузимся в другие аспекты построения OVH Managed Kubernetes и дадим клавиатуру некоторым из наших бета-клиентов, чтобы они рассказали о своем опыте использования сервиса.

На следующей неделе давайте сосредоточимся на другой теме, мы займемся языком запросов TSL , и почему мы создали и открыли исходный код…

Kubinception: использование Kubernetes для запуска Kubernetes

Столкнувшись с проблемой создания управляемого сервиса Kubernetes в OVH, полностью основанного на инструментах с открытым исходным кодом, нам пришлось принять несколько жестких проектных решений. Сегодня мы рассмотрим один из них…



Одним из наиболее структурных решений, которые мы сделали при создании сервиса OVH Managed Kubernetes, было развертывание кластеров наших клиентов над нашими собственными. Kubinception действительно…

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

Как работает кластер Kubernetes?


Чтобы полностью понять, почему мы запускаем Kubernetes на Kubernetes, нам нужно хотя бы базовое понимание того, как работает кластер Kubernetes. Полное объяснение по этому вопросу находится вне контекста этого поста, но давайте сделаем краткий обзор:
Рабочий кластер Kubernetes состоит из:
  • Плоскость управления, что делает глобальные решения о кластере, а также обнаруживают и реагирует на кассетные события. Эта плоскость управления состоит из нескольких главных компонентов .
  • Набор узлов, рабочих экземпляров, содержащих службы, необходимые для запуска модулей, с некоторыми компонентами узла, работающими на каждом узле, поддерживающими запущенные модули и предоставляющими среду выполнения Kubernetes.




Основные компоненты
В этой категории компонентов у нас есть:

  • Сервер API: предоставляет API Kubernetes. Это точка входа в плоскость управления Kubernetes.
  • Планировщик: наблюдает за вновь созданными модулями и выбирает узел для их запуска, управляя распределением ресурсов.
  • Контроллер-менеджер: запускайте контроллеры, контуры управления, которые следят за состоянием кластера и перемещают его в желаемое состояние.
  • ETCD: согласованное и высокодоступное хранилище значений ключей, используемое в качестве резервного хранилища Kubernetes для всех данных кластера. Эта тема заслуживает отдельного поста в блоге, поэтому мы поговорим об этом в ближайшие недели.


Компоненты узла
В каждом узле у нас есть:
  • Kubelet: агент, который следит за тем, чтобы контейнеры, описанные в PodSpecs, работали и работали. Это связь между узлом и плоскостью управления.
  • Kube-proxy: сетевой прокси, работающий на каждом узле, позволяющий абстрагировать сервис Kubernetes, поддерживая сетевые правила и выполняя переадресацию соединений.


Наша цель: быстрое и безболезненное развертывание кластера


Как мы пришли от этой простой архитектуры Kubernetes к Kubernetes вместо Kubernetes? Ответ кроется в одной из наших основных целей при создании сервиса OVH Managed Kubernetes: иметь возможность развертывать кластеры самым простым и автоматизированным способом.

И мы хотели не только развертывать кластеры, мы хотели, чтобы развернутые кластеры были:

  • Эластичный
  • Изолированные
  • Оптимизированный по стоимости


Kubinception: запуск Kubernetes поверх Kubernetes


Идея состоит в том, чтобы использовать кластер Kubernetes, который мы называем административным кластером, для развертывания клиентских кластеров.
Как и каждый кластер Kubernetes, клиентские кластеры имеют набор узлов и плоскость управления, состоящую из нескольких главных компонентов (сервер API, планировщик…).
Что мы делаем, так это развертываем эти главные компоненты клиентского кластера в качестве модулей на узлах административного кластера.

Упрощенная архитектура Kubinception


Итак, теперь у нас есть компоненты без сохранения состояния плоскости управления клиентского кластера, работающие как модули на узлах административного кластера. Мы не говорили о ETCD, так как поговорим об этом в следующем посте, а пока скажем только, что это выделенный компонент, живущий вне Kubernetes.

А рабочие узлы клиентского кластера? Это обычные узлы Kubernetes: экземпляры общедоступного облака OVH, подключающиеся к серверу API клиентского кластера, работающему в модуле кластера администрирования.

Клиентский кластер с узлами и ETCD

Наша цель — управлять большим количеством кластеров, а не одним, так как же добавить еще один кластер клиентов? Как и следовало ожидать, мы развертываем новую плоскость управления клиентским кластером на узлах административного кластера.

Два клиентских кластера на Kubinception

С точки зрения административного кластера, мы просто развернули три новых модуля. Затем мы создаем несколько новых экземпляров узлов и подключаем ETCD, и кластер готов.

Если что-то может выйти из строя, оно сделает это

Теперь у нас есть архитектура, которая позволяет нам быстро развертывать новые кластеры, но если мы вернемся к нашей цели, быстрое развертывание было только половиной, мы хотели, чтобы кластер был устойчивым . Начнем с отказоустойчивости.
Узлы клиентского кластера уже устойчивы, так как они являются обычными узлами Kubernetes , а устойчивость ETCD будет подробно описана в отдельном сообщении в блоге, поэтому давайте посмотрим на устойчивость плоскости управления, поскольку это особая часть нашей архитектуры.
И в этом прелесть архитектуры Kubinception, мы развертываем плоскость управления клиентскими кластерами в виде простых стандартных модулей в нашем административном кластере. А это означает, что они столь же устойчивы, как и любой другой модуль Kubernetes: если один из основных компонентов клиентского кластера выйдет из строя, диспетчер-контроллер административного кластера обнаружит его, и модуль будет перепланирован и повторно развернут без каких-либо ручных действий в нашем сторона.

Какой лучший способ убедиться, что наши Kubernetes достаточно надежны ...

Основание нашего сервиса Managed Kubernetes на Kubernetes заставило нас наткнуться на аспекты Kubernetes, которые мы не видели раньше, чтобы узнать много нового об установке, развертывании и эксплуатации Kubernetes. И все эти знания и инструменты были напрямую применены к нашим кластерам клиентов, что сделало их опыт удобнее для всех.

А как насчет масштабирования

Вся система была разработана с нуля с идеей масштабирования. Kubernetes вместо архитектуры Kubernetes обеспечивает легкое горизонтальное масштабирование . Когда административный кластер начинает становиться слишком большим, мы можем просто создать новый и развернуть там следующие плоскости управления клиентами.

Что дальше?

Поскольку этот пост уже достаточно длинный, я оставляю объяснение на ETCD для следующего поста в серии, через две недели. На следующей неделе давайте сосредоточимся на другой теме, мы займемся Apache Flink и тем, как его использовать для обработки предупреждений в масштабе OVH…