Это небольшая компиляция с комментариями, достаточно любопытного для технических специалистов, ролика выступления инженеров NCSoft https://www.youtube.com/watch?v=o-KJNWyHmQE

TL;DL NCSoft внедряют контейнеризацию на основе Kubernetes для части игровых сервисов.

Во вступлении к сожалению мало деталей.

«Наша инфраструктура в основном построена на физических серверах и виртуальных машинах. Всё это было оптимизировано годами, включая настройку сетей и серверов под наши игры. Мы даже знаем недельные, суточные и почасовые паттерны трафика — система была стабильна».

Дальше есть интересная деталь про разницу поддержки привычных для NC ПК игр и мобильных:

«Несколько лет назад перед нами встала новая задача: поддержка мобильных игр. Их рынок стремительно растёт, и NCSoft начала развивать мобильное направление. Но они сильно отличаются от ПК-игр:

• Жизненный цикл короче

• Игровая нагрузка более динамична

• Частые релизы и обновления

• Нужно быстро масштабироваться»

Для решения такого ряда задач он разделяют нагрузку на два типа: динамичная и статичная.
«Статичную нагрузку мы размещаем в частном облаке (OpenStack) — так дешевле в долгосрочной перспективе. Динамичную нагрузку — в публичных облаках (AWS, GCP).»

Причины, по которым перешли на Kubernetes:

«Универсальное управление сервисами на разных инфраструктурах. Простой и гибкий способ описания сервисов. Kubernetes + OpenStack = идеальная комбинация (OpenStack управляет железом, Kubernetes — сервисами).»

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

Планировщик Kubernetes этого не учитывает. И для решения пришлось настроить авто-масштабирование нод через OpenStack API или закрепить физические ядра за каждой виртуалкой.

По сетевому стеку используют следующее:

• Пробовали Flannel + VXLAN — но bandwidth был слабый

• Перешли на Host Gateway mode — и всё заработало лучше

• Также улучшили производительность VXLAN, изменив MTU (как именно без деталей)

Про миграцию сервисов

У NC 16 сервисов (тут не очень понятно каких) работающих под Linux. Пытались адаптировать их с разработчиками для Kubernetes: настройка билдов, деплой, логика масштабирования и т.д.

Старые виртуальные машины не отключали — они продолжали работать параллельно с Kubernetes-нодами. Затем постепенно выводили из эксплуатации, убедившись в стабильности работы нод.

По словам инженера NCSoft в результате потребление ресурсов снизилось — не из-за технологии, а из-за смены подхода: раньше каждый сервис запрашивал свои виртуалки. Теперь — просто поды. Нет избыточных запросов, масштабирование стало проще.

Так же в видео пара слов о логировании и мониторинге.

• Используют Fluentd, размещая агент в каждом поде. Это позволяет настраивать индивидуальный парсинг логов.

• Логи читаются из общего volume (emptyDir), доступного всем контейнерам в поде

• Отправляем их в Elasticsearch

• Zabbix для мониторинга железа

• Prometheus + Grafana для мониторинга Kubernetes и общих дашбордов

Немного деталей про собственные «костыли».

«Из-за сложности гибридной архитектуры мы строим свою систему для управления всей инфраструктурой:

1. API и UI для управления IaaS

2. Поддержка Kubernetes-кластеров

3. Возможность развёртывания приложений и контейнеров»

В ответах на вопросы выяснилось ещё немного информации:

Используют дистрибутив на базе Ubuntu

Нагрузка. ~30 сервисов на 13 нодах, загрузка невысокая — основные игровые сервера ещё не перенесены

Почему не Fluentd как DaemonSet, а в каждом поде? Потому что у каждого сервиса свои логи, и им нужны свои парсеры.

Почему не используете Magnum? Нужно независимое решение, т.к. используют разные инфраструктуры.