Comments 20
Читаю и у меня, что-то не сходится, вопросы возникают.
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
А с переездом в облако задача просто отпала?
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Плюс нам не нравилось то, во сколько нам обходится его содержание на bare metal
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
Например, одной из первых задач стало вписать Ingress-контроллеры Kubernetes в сетевую инфраструктуру нашей организации
А с переездом в облако задача просто отпала?
Читаю и у меня, что-то не сходится, вопросы возникают.
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Получилось дешевле за счет того, что это managed-решение, которое не требует с нашей стороны разработки low-level компонентов, например для интеграции с сетью компании или для PVC на своем оборудовании.
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
«Сколько» это в человеко-часах, два человека — DevOps на full-time + переодически привлекаемые разработчики под частные задачи, когда они накапливались.
Разрабатывали, например, компонент позволяющий в сервисах использовать IP'шники из корпоративной сети, интегрирующийся так же с DNS. В опенсорс он в итоге не пошел. Так же делали stage3 провижнинг нод с автодобавлением в кластер и апгрейдом кубернетеса, хотели перейти на stage4 с тестами конкретной сборки, но не успели :)
В настоящий момент у нас сырых пожатых данных всего ничего ~5GB в Kafka(~5M сообщений от конечных устройств), переливали мы их без нарушения работоспособности сервиса. Так что полчаса для такого объема даже очень долго :)
Суммарно используется 85 CPU, 322 GB RAM.
Общий объем CPU и памяти у нас обычно зависит от того, над чем мы эксперементируем в настоящий момент и какие стоят задачи, текущее значение достаточно скромное, потому что сейчас не проходит никаких экспериментов.
А с переездом в облако задача просто отпала?
А с переездом в облако все уже сделали за нас :)
Не, не понимаю.
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Не понимаю чем два человека на Full-time занимались.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Не понимаю чем два человека на Full-time занимались.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Не, не понимаю.
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Распределение ресурсов команд это вопрос продукт-, проджект- и релиз-менеджмента.
В самом начале у нас было именно так — 8 серверов и с ними вполне справлялись разработчики, но затем, как у любого развивающегося проекта у нас появились задачи:
— воспроизводимости окружения
— апгрейдов kubernetes
— интеграции kubernetes с корпоративными сервисами
— трейсинга ошибок наших собственных приложений
— мониторинга
— централизованного доступа к логам
— CI
— CD
— процедур и сервисов для Code Review
— песочницы для экспериментов
— SLA и отслеживание его соблюдения
… этот перечень можно еще продолжать, но важно одно: это все не задачи разработчиков продуктовой команды. Это инфраструктурные задачи.
Все это нужно для того, чтоб команда разработки могла эффективно выполнять свои функции, а именно:
— занималась разработкой
— делала это с максимальной эффективностью
— т.е. не отвлекаясь на задачи инфраструктуры
— имея при этом воспроизводимый результат
— и наиболее свежие технологии в стеке
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Продуктовые задачи это не только обсчет данных, это целый набор задач по архитектуре сервисов, UI/UX, непосредственно арифметике и, самое главное, применимости конкретных экологических методик к нашим реалиям и целям.
Не понимаю чем два человека на Full-time занимались.
Ровно всем этим — обеспечивали работу остальных команд, беря на себя инфраструктурные функции и организацию процессов.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Это самая интересная часть — еще переезжая в GCP(где, кстати есть возможность Interconnect'а с корпоративными сегментами) мы осознали что, это лишнее. У нас ушло понимание зачем нам держать сервис(даже его девелопмент часть) исключительно во внутренней сети. Так что в MCS мы приехали с полностью публично-доступными(в сетевом смысле этого слова) сервисами, а дальше — BeyondCorp model(хотя к полной ее имплементации мы еще только стремимся).
Из вашего списка задач MCS решает только две:
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Остальное это каждодневная рутинная работа команды разработки.
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
В MCS файлы наши уже теряли…
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Остальное это каждодневная рутинная работа команды разработки.
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
В MCS файлы наши уже теряли…
Из вашего списка задач MCS решает только две:
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Это сильно натянутое заключение.
Мы получаем on-demand сервис с API, который нам позволяет получить произвольное число нод/CPU в считанные минуты независимо от времени суток. Скейлиться точно так же. Это справедливо для любого Kubernetes-aaS на самом деле, не только для MCS.
И фактически уйдя с bare-metal мы решили проблемы:
Все связанные с физическим оборудованием и своей OS:
— провиженинг
— деплоймент
— мониторинг
— апдейты
— замена комплектующих
т.е. все, что до
kubectl apply.В MCS файлы наши уже теряли…
Как там в анекдоте было, «админы делятся на два типа...»
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
У нас уже есть позитивный опыт решения подобных проблем с MCS.
Подробно рассказать не могу, но суть сводится к тому, что наш менеджер в MCS готов такие вопросы обсуждать и договариваться.
Я тоже не понимаю.
Тон статьи — реклама mcs, ура-ура, мы умеем кубернетис
Честно говоря, я ожидал каких-то кровавых подробностей из серии "как организовать петабайтный dwh" на кубе. Это реально интересно. А у коллег всего 5ГБ в кафке. Ну, смешно. С таким объемом даже один жирный сервер справится
Касательно интеграции с Корп сетью — тоже неудомение. Действительно, с одной стороны это сложно. Но не с технической, а организационной стороны. А с другой — какие такие компоненты понадобились? Знаете, проблема решается вообще очень просто. Просто заводить в кубе coredns, и ему отдать зону *.kube-cluster-1.mycompany.com. Проблема решена. С айпишниками — посмотрите опыт букинга, когда они на каждую ноду просто выделяют подсесть из корпсети все коуто
Ещё добавлю, что в российских компаниях стандарт де-факто — vmware. И вмварь очень активно разрабатывает отличные интеграции с кубернетесом, как со стороны стореджа, так и со стороны сети, и даже прозрачной интеграции куба в панели управления (!!!)
Немного оффтоп, но какая виртуализация используется "у них"? (Имею в виду виртуальные машины с виндой для разработчиков, а не корпоративный сегмент)
Извините, пожалуйста, не совсем понял Вашего вопроса. Разверните, его, пожалуйста.
Если локально — вагрант. Можно в hyper-v. А вообще разрабы могут и на VDI пастись (есть компании с такими требованиями по ИБ).
Извините, что долго не отвечал — потерял свой коммент.
Имел ввиду: у нас программисты/исследователи которым требуется тестовая Windows в виртуальной машине используют vmware.
Очень хотелось бы знать что в таких случаях обычно используется «в мировой практике». Именно в качестве тестовой машины для отладки чего-то, а не как виртуалка для тонкого клиента.
Просто пишу продукт нацеленный именно на системных разработчиков и не хотелось бы промахнуться с совместимостью.
Заранее спасибо.
Имел ввиду: у нас программисты/исследователи которым требуется тестовая Windows в виртуальной машине используют vmware.
Очень хотелось бы знать что в таких случаях обычно используется «в мировой практике». Именно в качестве тестовой машины для отладки чего-то, а не как виртуалка для тонкого клиента.
Просто пишу продукт нацеленный именно на системных разработчиков и не хотелось бы промахнуться с совместимостью.
Заранее спасибо.
Непонятен момент с необходимостью хоститься в РФ — по описанию у вас там только абстрактные метрики воздуха, о каких тут ПСД идет речь?
Ещё в статье написано, что вы данные храните в Kubernetes, можно поконкретнее, где именно? Как вы решили задачу с контролем физического местонахождения данных?
Ещё в статье написано, что вы данные храните в Kubernetes, можно поконкретнее, где именно?
Да, конечно, для хранения данных экологического мониторинга мы используем Kafka и ScyllaDB, запущенные в виде StatefulSet'ов с PVC, преимущественно на SSD.
Попутно пробуем операторы для stateful-приложений, но для Kafka и ScyllaDB пока не нашли подходящего решения.
Как вы решили задачу с контролем физического местонахождения данных?
Не понял вопроса.
Важный момент.
Вы используете локальное хранилище на нодах с кубом?
Или распределенное?
Там много нюансов
За все время использования Kubernetes на bare-metal мы пробовали разные варианты(в хронологическом порядке):
— Внешний сторадж с дисковой полкой и LVM over FC
— Оно же over iSCSI
— Локальный Ceph на нодах
— hostPath + nodeSelector
В GCP и MCS мы используем предоставляемые вендором сервиса внешние вольюмы через PVC. Не локальное хранилище на нодах(hostPath) потому что это сильно повлияет на отказоустойчивость и потребует ручного управления StatefulSet'ами, что хочется оставить соответствующим операторам.
— Внешний сторадж с дисковой полкой и LVM over FC
— Оно же over iSCSI
— Локальный Ceph на нодах
— hostPath + nodeSelector
В GCP и MCS мы используем предоставляемые вендором сервиса внешние вольюмы через PVC. Не локальное хранилище на нодах(hostPath) потому что это сильно повлияет на отказоустойчивость и потребует ручного управления StatefulSet'ами, что хочется оставить соответствующим операторам.
в GCP оно, понятное дело, прибито к региону. И по сути — может ездить между виртуалками.
А как в MCS сделано? Я помню, что там была целая куча разных типов стораджа. И были странные функции вроде подмонтировать сторедж из одного региона в другой. Поэтому и уточняю.
Там вообще три типа именно дисков: HDD, SSD, High IOPS SSD
«георепликация» — bool флаг для диска(High IOPS SSD его не умеют)
Обычно мы делаем кластер в одном регионе, диски к нему с георепликацией, там где это не контролируется (PVC) и/или невозможно(High IOPS SSD) — не настаиваем, т.к. репликация есть внутри statefulset'а.
«георепликация» — bool флаг для диска(High IOPS SSD его не умеют)
Обычно мы делаем кластер в одном регионе, диски к нему с георепликацией, там где это не контролируется (PVC) и/или невозможно(High IOPS SSD) — не настаиваем, т.к. репликация есть внутри statefulset'а.
Sign up to leave a comment.
Как благодаря Kubernetes и автоматизации мигрировать в облако за два часа