В прошлом месяце команда OVH и Binder объединилась, чтобы поддержать рост экосистемы BinderHub по всему миру.



Приблизительно 100 000 еженедельных пользователей общедоступного развертывания mybinder.org и 3 000 уникальных репозиториев git, в которых размещены значки Binder, ощущали потребность в дополнительных ресурсах и вычислительном времени.

Сегодня мы рады объявить, что OVH теперь является частью всемирной федерации BinderHubs, поддерживающих mybinder.org. Весь трафик на mybinder.org теперь распределяется между двумя BinderHub: один находится в ведении группы Binder, а другой — в инфраструктуре OVH.

Итак, для тех, кто еще не знает mybinder.org, вот краткое изложение.

Что такое Юпитер?

Jupyter — потрясающий проект с открытым исходным кодом, который позволяет пользователям создавать, визуализировать и редактировать интерактивные записные книжки. Он поддерживает множество популярных языков программирования, таких как Python, R и Scala, а также некоторые стандарты представления, такие как разметка, фрагменты кода, визуализация диаграмм…



Пример локальной записной книжки Jupyter, читающей записную книжку внутри клиента предвидения репозитория OVH GitHub.

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

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

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

Что такое JupyterHub?

JupyterHub — еще более потрясающий проект с открытым исходным кодом, предлагающий многопользовательскую функцию для ноутбуков Jupyter. Благодаря нескольким подключаемым механизмам аутентификации (например, PAM, OAuth), он позволяет создавать записные книжки Jupyter на лету из централизованной инфраструктуры. Затем пользователи могут легко делиться своими записными книжками и правами доступа друг с другом. Это делает JupyterHub идеальным для компаний, учебных аудиторий и исследовательских лабораторий.

Что такое BinderHub?

Наконец, BinderHub — это вишенка на торте: он позволяет пользователям превращать любой репозиторий Git (например, GitHub) в коллекцию интерактивных записных книжек Jupyter одним щелчком мыши.



Binder экземпляр развернутого OVH можно ознакомиться здесь .

• Просто выберите общедоступный репозиторий git (лучше, если он уже содержит записные книжки Jupyter ).
• Скопируйте URL-адрес выбранного репозитория в правильное поле привязки.
• Щелкните кнопку запуска.
• Если связыватель впервые видит предоставленный вами репозиторий, вы увидите журналы компиляции. Ваш репозиторий анализируется и готовится к запуску связанной записной книжки Jupyter .
• После завершения компиляции вы будете автоматически перенаправлены на выделенный экземпляр.
• Затем вы можете начать взаимодействовать и взламывать ноутбук.
• На начальной странице подшивки вы увидите ссылку, по которой можно поделиться своим репозиторием с другими.

Как это работает?

Инструменты, используемые BinderHub

BinderHub соединяет несколько сервисов вместе, чтобы обеспечить создание и реестр образов Docker на лету. Он использует следующие инструменты:

• Облачный провайдер, такой как OVH.
• Kubernetes для управления ресурсами в облаке
• Helm для настройки и управления Kubernetes.
• Docker для использования контейнеров, которые стандартизируют вычислительные среды.
• Пользовательский интерфейс BinderHub, к которому пользователи могут получить доступ, чтобы указать репозитории Git, которые они хотят создать.
• BinderHub для создания образов Docker с использованием URL-адреса репозитория Git.
• Реестр Docker, в котором размещаются образы контейнеров.
• JupyterHub для развертывания временных контейнеров для пользователей.

Что происходит, когда пользователь щелкает ссылку Binder?

После того, как пользователь щелкает ссылку Binder, происходит следующая цепочка событий:

1. BinderHub разрешает ссылку на репозиторий.
2. BinderHub определяет, существует ли уже образ Docker для репозитория по последней ссылке (хэш, ветка или тег git commit).
3. Если изображение не существует, BinderHub создает модуль сборки, который использует repo2docker для:
   
   • Получите репозиторий, связанный со ссылкой.
   • Создайте образ контейнера Docker, содержащий среду, указанную в файлах конфигурации в репозитории.
   
   
   • Отправьте этот образ в реестр Docker и отправьте информацию реестра в BinderHub для дальнейшего использования.
4. BinderHub отправляет реестр образов Docker в JupyterHub.
5. JupyterHub создает для пользователя модуль Kubernetes, который обслуживает созданный образ Docker для репозитория.
6. JupyterHub отслеживает активность модуля пользователя и уничтожает его после короткого периода бездействия.

Схема архитектуры BinderHub

Как мы это развернули?

На платформе OVH Kubernetes

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

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

Для этого мы использовали 2 сервиса в OVH Public Cloud:

• Kubernetes кластер сегодня потребляет 6 узлов 

  C2-15

  экземпляров виртуальных машин (она будет расти в будущем)
• Docker реестра

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

Установка HELM на наш новый кластер

После завершения автоматической установки нашего кластера Kubernetes мы загрузили административный YAML-файл, позволяющий управлять нашим кластером и запускать 

kubectl

на нем команды.

kubectl

это официальный и самый популярный инструмент, используемый для администрирования кластера Kubernetes. Более подробную информацию о том, как его установить, можно найти здесь .
Автоматическое развертывание полного стека Binder уже подготовлено в виде пакета Helm. Helm — это менеджер пакетов для кубернетов, и для работы ему нужны клиентская часть ( 

helm

) и серверная часть ( 

tiller

).
Всю информацию об установке 

helm

и 

tille

можно найти здесь .

Конфигурация нашего развертывания Helm

После 

tiller

установки в нашем кластере все было готово для автоматизации развертывания связующего в нашей инфраструктуре OVH.
Конфигурация 

helm

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

Интеграция в процесс CD / CI binderhub

У них binder team уже был рабочий процесс travis для автоматизации процессов тестирования и развертывания. Все прозрачно, и они раскрывают все свои конфигурации (кроме секретов) в своем проекте GitHub. Нам просто нужно было интегрироваться с их текущим рабочим процессом и разместить нашу конкретную конфигурацию в их репозитории.

Затем мы подождали их следующего запуска рабочего процесса Travis, и он сработал.

С этого момента стек ovh для binder был запущен и доступен всем отовсюду по этому адресу: ovh.mybinder.org/

Что будет дальше?

OVH продолжит взаимодействовать с сообществом разработчиков данных с открытым исходным кодом и будет поддерживать прочные отношения с фондом Jupyter и, в более общем плане, сообществом Python.

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

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

Специальная благодарность

Мы благодарны командам Binder, Jupyter и QuantStack за их помощь, команде OVH K8s для OVH Managed Kubernetes и OVH Managed Private Registry, а также команде OVH MLS за поддержку. Вы молодцы!

Несколько недель назад я участвовал в митапе, посвященном 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, чтобы получить больше практических советов и советов.

Одним из ключевых преимуществ использования 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. Проект еще очень молодой, на ранней стадии альфа, но он показывает некоторые впечатляющие перспективы.

Наши коллеги из команды 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.

За последние несколько месяцев, я действовал в качестве  Защитника 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, есть о чем поговорить, но, как говорится, это уже история для другого раза…

Запуск 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 , и почему мы создали и открыли исходный код…

Столкнувшись с проблемой создания управляемого сервиса 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, планировщик…).
Что мы делаем, так это развертываем эти главные компоненты клиентского кластера в качестве модулей на узлах административного кластера.




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

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



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



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

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

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

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

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

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

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

Что дальше?

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

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

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



Поскольку бета-версия сейчас работает, а последние проблемы решаются для окончательной версии, мы потратим некоторое время, чтобы поделиться некоторыми уроками, которые мы извлекли, технологическим выбором, который мы приняли, и инструментами, которые мы создали в процессе…

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

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

Путешествие Kubernetes

Первый раз, когда вы играете с Minikube, это часто удивительно. Больше не нужно беспокоиться об управлении экземплярами, нет необходимости отслеживать, работают ли контейнеры, вы останавливаете экземпляр, и Kubernetes повторно создает контейнеры в другом экземпляре… Это своего рода волшебство!

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

Запускаете Kubernetes в производство?

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

Развертывание кластера Kubernetes — это только начало, чтобы его продукт был готов, вам также необходимо убедиться, что:

• Процесс установки автоматизируется и повторяется.
• Процесс обновления / отката безопасен
• Процедура восстановления существует, задокументирована и протестирована
• Производительность предсказуема и стабильна, особенно при использовании постоянных томов
• Кластер работоспособен, с достаточным количеством трассировок, метрик и журналов для обнаружения и отладки сбоев и проблем.
• Сервис безопасный и высокодоступный

Наш ответ на эту сложность эксплуатации

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

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

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

На плечах гигантов ...

Итак, мы хотели создать управляемое решение Kubernetes, но как это сделать? Первый шаг был прост: нам нужно было убедиться, что базовая инфраструктура надежна, поэтому мы решили основать ее на нашем собственном предложении Public Cloud на основе OpenStack.

Сертифицированный хостинг Kubernetes
Построение нашей платформы на основе зрелого, высокодоступного и основанного на стандартах продукта, такого как OVH Public Cloud, позволило нам сосредоточить наши усилия на решении реальной проблемы, с которой мы столкнулись: создании хорошо масштабируемой, простой в эксплуатации, сертифицированной CNCF управляемой службы Kubernetes.

Что дальше?

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

Мы начнем с одного из наших самых смелых решений: запустить Kubernetes поверх Kubernetes или, как мы любим его называть, Kubinception.