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

Почему OVH Managed Kubernetes?

Использование 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.