Нахождение в реестре российского ПО не требует прохождения сертификации, поэтому никаких сертификатов на текущий момент нет. Есть 118 приказ ФСТЭК. Мы находимся в процессе прохождения сертификации по требованиям по безопасности информации к средствам контейнеризации. Как только получим сертификат, то обязательно опубликуем об этом новость.
Я полностью согласен, что в облаке небольшого провайдера отказоустойчивость на порядок ниже, чем у Google или AWS. К сожалению, в данном публичном облаке Colocall у нас нет возможности управления распределением вм по гипервизорам. Таким образом, мы даже не можем гарантировать, что ноды control-plane находятся на разных гипервизорах или тем более на гипервизорах в разных стойках. Этот тот риск, который надо обязательно брать в расчёт. Если говорить в целом про небольших провайдеров, то у многих помимо публичного облака есть услуга приватного облака. Тут ситуация лучше, так как они обычно выделяют гипервизоры в разных стойках. Таким образом, мы закрываем часть проблем. Но если уж отказало СХД, то, скорее всего, это будет фатально. Опять же такие приватные облака обходятся дороже, чем публичные. Решение и принятие рисков здесь полностью на стороне бизнеса.
Я бы добавил, что GKE - это самый логичный и быстрый способ попробовать Kubernetes. Многие компании, особенно стартапы, делают такой первый шаг, чтобы понять, на сколько Kubernetes подходит им и решает их проблемы. А дальше уже начинают возникать вопросы с урезанием стоимости инфраструктуры.
Все эти риски естественно присутствуют. Также если говорить, например, про РФ, есть риски, что будут блокировки иностранных облаков со стороны Роскомнадзор. Или есть разные федеральные законы, которые могут создать проблемы с использованием облачных услуг у иностранных поставщиков. В статье мы постарались дать понимание, что "стоимость вм" - это один из факторов, который стоит учитывать. Скейлинг и отказоустойчивость - это сильные преимущества Google Cloud.
Важная оговорка. Понятно, что GKE — это лишь часть огромной экосистемы Google Cloud. Она дает широкие возможности, решает большой объем задач, у нее высокая отказоустойчивость. Разные проекты используют эти возможности по-разному. В случае robota.ua команде нужен был только «голый» GKE, без дополнительных managed-сервисов — например, БД или мониторинга от Google. Поэтому миграция на другое решение managed Kubernetes оказалась целесообразной и простой. Однако в других случаях при оценке экономической эффективности переезда стоит учитывать все нюансы.
Одним из преимуществ Deckhouse и услуги, которую мы предоставляем на базе этой платформы, является одинаковый для пользователя Kubernetes. Таким образом, если возникнут проблемы с текущим провайдером, то мы достаточно легко перевезём кластера клиента к другому. Это частично защищает от указанных рисков.
Спот инстансы подходят не всем клиентским приложениям, но это действительно один из лучших способов сэкономить. Также можно рассмотреть "1 year commitment" или "3 year commitment" планы. Перед компанией Флант не ставилась задача уменьшения стоимости эксплуатации GKE, поэтому тут, к сожалению, не можем привести точного расчёта экономической составляющей, которая привела к переезду.
Мы проводили обновление без дрейнов и ребутов. Я чуть выше ответил почему. Мы не пробовали в продах, но можно было обновиться по более простой схеме, перепрыгнув через пару версий, но итоговую схему посчитали более безопасной, тем более написанная «автоматика» заточена на обновление по одной версии вверх.
Drain был необходим при обновлении до 1.16, я писал про это.
Обновление с 1.15 на 1.16 приводило к рестарту контейнеров на узле, поэтому приходилось выполнять drain узла, что в случае большого количества stateful-приложений приводило к необходимости выполнять работы в согласованные окна и требовало особого внимания инженеров.
При обнолвении на 1.17 и выше рестарта контейнеров нет, поэтому мы не выполняли drain. Либо в доке просто прилипла информация о необходимости drain'a, либо действительно излишняя предосторожность. У нас проблема действительно возникла только на одной ноде. Следует отметить только один момент. В момент обновления kubelet'а нода на короткое время переходит в NotReady, если у вас в кластерах какие-то кастомные настройки эвикта подов в случае, если нода недоступна, то могут начаться активные перекаты подов.
Потому что у flannel 6.2К звёздочек на github, а у calico 2.4K. Это, конечно же, шутка. Flannel является очень простой и понятной штукой, мы отлично понимаем её возможности, плюсы и минусы, с самых первых инсталляций сделали свой выбор в пользу flannel. В режиме host-gw flannel обладает хорошей производительностью. В Deckhouse есть модуль network-policy-engine, который предоставляет управление сетевыми политиками, под капотом используется kube-router, всё это работает вместе с flannel.
Это не значит, что flannel — идеальный cni, который лучше, например, calico. Условно, flannel — это отличный молоток, нам надо забивать гвозди, мы берём flannel. Надо будет заворачивать саморезы, нужен будет шуруповёрт, будем использовать другой инструмент.
Я уверен, что есть много фреймворков, в которых данная проблема решена. Также я уверен в том, что данная проблема встречается в каком-то числе фреймворков, особенно в старых. Вот, например, обсуждение для laravel github.com/laravel/ideas/issues/1645
Если есть уверенность в том, что на уровне фреймворка и в конкретно взятом приложении не возникнет проблем из-за паралелльного запуска миграций, то, конечно, можно запускать миграции в рамках пода приложения. Здесь как всегда нет единственно верного решения, я больше писал про универсальное решение, которое точно работает и не создаёт проблем.
По поводу вынесения миграций отдельно есть простой пример. Допустим Deployment приложения запущен с достаточно большим количеством реплик, таком что при стандартных настройках RollingUpdate при релизе одновременно запускается больше одного пода приложения. Получается, что паралелльно запустится выполнение нескольких процессов наката миграций. И тут могут возникнуть проблемы.
С данным оператором в работе пока не сталкивался, но на вскидку для большинства случаев он видится несколько избыточным и усложняющим процесс.
Git submodule, является частью git, что делает его инструментом для управления исходным кодом. Если есть необходимость работать с исходниками нескольких репозиториев в рамках одного, то git submodule — это отличный выбор. В таком формате, конечно же, удобнее вести разработку.
Git submodule однозначно начинают проигрывать, когда исходники не нужны, а нужно просто стянуть все необходимые пакеты. Например, нужны не только helm шаблоны описанные в собственных репозиториях, но и чарты с hub.helm.sh. Да, можно использовать git submodule, так как большинство чартов имеют открытые исходники, но гораздо проще, используя менеджер пакетов, сказать, что нужен пакет следующей версии.
С сабмодулями есть ещё одна небольшая проблема, многие разработчики используют их в своих проектах. Поэтому периодический вызов git submodule update --init --recursive --remote --merge приводит к тому, что в репозитории проекта вместе с библиотеками проекта обновляется ещё и инфраструктура. Но это скорее человеческий фактор.
Были также вариации с использованием git submodules, но всё это больше похоже на обходной путь…
Я писал про вариант с git submodules, не стал прикреплять пример, как его реализовать. Сабмодули также подходят для подключения исходников из других репозиториев. Но и git submodules, и вариант с checkout тега уступают использованию функционала пакетного менеджера.
Нахождение в реестре российского ПО не требует прохождения сертификации, поэтому никаких сертификатов на текущий момент нет. Есть 118 приказ ФСТЭК. Мы находимся в процессе прохождения сертификации по требованиям по безопасности информации к средствам контейнеризации. Как только получим сертификат, то обязательно опубликуем об этом новость.
https://wiki.astralinux.ru/pages/viewpage.action?pageId=147162407
Я полностью согласен, что в облаке небольшого провайдера отказоустойчивость на порядок ниже, чем у Google или AWS. К сожалению, в данном публичном облаке Colocall у нас нет возможности управления распределением вм по гипервизорам. Таким образом, мы даже не можем гарантировать, что ноды control-plane находятся на разных гипервизорах или тем более на гипервизорах в разных стойках. Этот тот риск, который надо обязательно брать в расчёт.
Если говорить в целом про небольших провайдеров, то у многих помимо публичного облака есть услуга приватного облака. Тут ситуация лучше, так как они обычно выделяют гипервизоры в разных стойках. Таким образом, мы закрываем часть проблем. Но если уж отказало СХД, то, скорее всего, это будет фатально. Опять же такие приватные облака обходятся дороже, чем публичные. Решение и принятие рисков здесь полностью на стороне бизнеса.
Я бы добавил, что GKE - это самый логичный и быстрый способ попробовать Kubernetes. Многие компании, особенно стартапы, делают такой первый шаг, чтобы понять, на сколько Kubernetes подходит им и решает их проблемы. А дальше уже начинают возникать вопросы с урезанием стоимости инфраструктуры.
Все эти риски естественно присутствуют. Также если говорить, например, про РФ, есть риски, что будут блокировки иностранных облаков со стороны Роскомнадзор. Или есть разные федеральные законы, которые могут создать проблемы с использованием облачных услуг у иностранных поставщиков.
В статье мы постарались дать понимание, что "стоимость вм" - это один из факторов, который стоит учитывать. Скейлинг и отказоустойчивость - это сильные преимущества Google Cloud.
Одним из преимуществ Deckhouse и услуги, которую мы предоставляем на базе этой платформы, является одинаковый для пользователя Kubernetes. Таким образом, если возникнут проблемы с текущим провайдером, то мы достаточно легко перевезём кластера клиента к другому. Это частично защищает от указанных рисков.
Спот инстансы подходят не всем клиентским приложениям, но это действительно один из лучших способов сэкономить. Также можно рассмотреть "1 year commitment" или "3 year commitment" планы. Перед компанией Флант не ставилась задача уменьшения стоимости эксплуатации GKE, поэтому тут, к сожалению, не можем привести точного расчёта экономической составляющей, которая привела к переезду.
При обнолвении на 1.17 и выше рестарта контейнеров нет, поэтому мы не выполняли drain. Либо в доке просто прилипла информация о необходимости drain'a, либо действительно излишняя предосторожность. У нас проблема действительно возникла только на одной ноде. Следует отметить только один момент. В момент обновления kubelet'а нода на короткое время переходит в NotReady, если у вас в кластерах какие-то кастомные настройки эвикта подов в случае, если нода недоступна, то могут начаться активные перекаты подов.
Это не значит, что flannel — идеальный cni, который лучше, например, calico. Условно, flannel — это отличный молоток, нам надо забивать гвозди, мы берём flannel. Надо будет заворачивать саморезы, нужен будет шуруповёрт, будем использовать другой инструмент.
Если есть уверенность в том, что на уровне фреймворка и в конкретно взятом приложении не возникнет проблем из-за паралелльного запуска миграций, то, конечно, можно запускать миграции в рамках пода приложения. Здесь как всегда нет единственно верного решения, я больше писал про универсальное решение, которое точно работает и не создаёт проблем.
С данным оператором в работе пока не сталкивался, но на вскидку для большинства случаев он видится несколько избыточным и усложняющим процесс.
Git submodule однозначно начинают проигрывать, когда исходники не нужны, а нужно просто стянуть все необходимые пакеты. Например, нужны не только helm шаблоны описанные в собственных репозиториях, но и чарты с hub.helm.sh. Да, можно использовать git submodule, так как большинство чартов имеют открытые исходники, но гораздо проще, используя менеджер пакетов, сказать, что нужен пакет следующей версии.
С сабмодулями есть ещё одна небольшая проблема, многие разработчики используют их в своих проектах. Поэтому периодический вызов
git submodule update --init --recursive --remote --mergeприводит к тому, что в репозитории проекта вместе с библиотеками проекта обновляется ещё и инфраструктура. Но это скорее человеческий фактор.