Как DevOps инженер я имею опыт установки и поддержки vanilla kubernetes(k8s) на bare metal, опыт построения private cloud вокруг такого k8s, а также опыт использования различных public cloud таких как EKS (Amazon Managed Kubernetes), GKE (Google Managed Kubernetes), AKS (Azure Kubernetes Service). На данном этапе карьеры я очень часто тыкаю k8s, который развернут с помощью kops внутри AWS инфраструктуры. 

Disclaimer. Статья основана на опыте эксплуатации различных k8s кластеров, как managed, предоставляемых различными облачными провайдерами, так и собственноручно развернутых на базе тех же провайдеров, а также на bare metal. Преимущественно материал основывается на опыте эксплуатации k8s кластера развернутого посредством kops. В статье не рассматриваются аналоги kops

Пара слов о наших k8s кластерах и используемой инфраструктуре

  • В качестве провайдера инфраструктуры используется AWS

  • Kubernetes разворачивается посредством kops. Kops это проект с открытым исходным кодом, позволяющий развернуть k8s в публичных и не только (функциональность OpenStack находится в бете) облаках. Чем же отличается kops от vanilla k8s? Kops, по сути, связывает vanilla k8s с провайдером инфраструктуры. Как пишут сами авторы проекта, kops можно воспринимать в виде kubectl для kubernetes кластера. Средствами kops вы описываете k8s кластер с помощью декларативного подхода в виде yaml манифестов, либо императивного - создаете кластер из командной строки, также существует вариант конфигурации через terraform. Таким образом, используя kops, вы конфигурируете как сам k8s кластер, так и облако в котором будет развернут данный кластер (создание необходимых сервис аккаунтов, ролей, VPC и т.д). На практике данный инструмент свою функцию выполняет, однако, таит в себе множество недоработок. Но о них чуть позже.

  • В поддержке находится около 11-12 k8s кластеров

  • Как используются k8s кластера?

    • Развертывание бизнес приложения на микросервисной архитектуре

    • CI/CD (Jenkins + Spinnaker)

    • On-Demand окружения для запуска рабочей dev версии всего продукта

    • На всех кластерах присутствуют некоторые виды stateful сервисов (в основном для мониторинга + несколько для бизнес сервисов)

Предисловие

Как в нашей компании выстроен процесс обновления k8s?

  1. Обновление всегда затрагивает 3 компонента:

    1. Обновлении версии kops

    2. Обновление версии k8s

    3. Обновление базового image для k8s nodes - в нашем случае flatcar

  2. Проверяем release notes, поднимаем версию всех компонентов, тестируем на dev кластере. Процесс тестирования не описываю (часть покрыта автоматическими тестами, что-то оценивается просто визуально)

  3. Если все ок, обновление поэтапно раскатывается  на дев кластера для разработчиков, потом - on-demand, cicd и prod

  4. Весь процесс автоматизирован через Jenkins + Spinnaker

История 1. Эксплуатация kops

Данная история - это агрегация некоторых недостатков kops, c которыми я столкнулся в ходе его эксплуатации.

Первая странность произошла при обновлении k8s (kops) на версию 1.23, когда неожиданно пропали все метрики по контейнерам. Оказалось, что дело в использовании read-only порта kubelet 10255 для сбора метрик агентами на наших кластерах (более подробно о метриках контейнеров). Да-да, это неправильно использовать kubelet для сбора метрик и нужно бы пользоваться metric-server, а не конфигурировать как попало. Однако вернемся к  Kops. В релизе 1.23 read-only-port просто отключили по умолчанию. Как же так получилось, что kops сделал такое важное изменение, которое никак не отразилось в Release Notes? Да все очень просто, это изменение прошло совершенно не под тем именем, поскольку было сделано в рамках рефакторинга в скоупе одной из задач. Kops перестал использовать deprecated способ объявления конфигурации kubelet. Все бы ничего, но значения некоторых настроек по умолчанию отличаются при использовании нового способа. Почему я заостряю на этом внимание? Было потрачено не мало времени, чтобы понять, какое изменение вызвало такую проблему и найти этому подтверждение в репозитории kops.

Вторая оказия случилась тогда, когда возникла необходимость откатить версию kops кластера при не успешном обновлении. По умолчанию kops  не позволяет сделать это, однако у него есть специальная опция “--allow-kops-downgrade”. Все бы ничего, но она не работает, если вы используете свои private registry для хранения ресурсов, необходимых для запуска k8s. Все потому, что у другой команды, которая необходима для  “kops get assets --copy” такой опции нет! А без ее вызова фактически невозможно запустить обновление kops на любую версию. Чудеса. В итоге кластера, использующие private registry для хранения имаджей core компонентов, нужно откатывать в ручном режиме.

Третья причуда - kops addons. Большинство core компонентов k8s в kops поставляются как аддоны.  Т.е. в kops есть стандартные yaml манифесты всех таких компонентов, которые шаблонизируются на основе главного yaml файла, где описывается весь k8s kops кластер. Помимо основных компонентов (kube-api, cni и т.п.), kops предоставляет аддоны, которые не требуются для работы кластера, но упрощают жизнь. Это различные csi драйвера для монтирования томов, cluster-autoscaler для автоматического запуска и остановки виртуальных машин и т.д. Отмечу, что не все дополнительные аддоны обладают гибкой конфигурацией и порой не остается другого выхода как выключать их и разворачивать свои версии. Здесь встает вопрос “а как это делать?”. Есть стандартный вариант - с помощью CICD разворачивать необходимые компоненты. Существует еще один вариант, который официально продвигается kops - custom addons. При ближайшем рассмотрении данного способа становится понятно, что это совсем не панацея. Мы уже упомянули шаблонизацию манифестов аддонов, но как потом эти манифесты разворачиваются на k8s кластере? У kops есть так называемый protokube.service - это systemd job, которая запускается при старте виртуальной машины. Эта job’a достает все манифесты из s3 bucket’a, куда они помещаются, когда kops создает/обновляет кластер. После этого происходит проверка был ли изменен манифест по сравнению с предыдущей версией (информация о предыдущей версии каждого аддона хранится в аннотации kube-system namespace k8s), после -  разворачивается. Таким образом, для того, чтобы развернуть custom addon, нужно поместить его манифест в s3 bucket. На этом моменте возникает куча проблем с проверкой корректности манифеста, проверкой был ли он успешно развернут и версионированием. Учитывая данные проблемы, становится понятно, что с этим вариантом нам явно не по пути. Сколько же времени было потрачено на то, чтобы понять как работают custom addons, постоянно выявляя недостатки данного способа (отмечу, что все это никак не задокументировано)? Стоило ли оно того? Моя точка зрения - нет. 

Какой же вывод можно сделать? Не используйте kops. Если нет необходимости собственноручно разворачивать k8s кластер, задумайтесь, а надо ли оно вам? Все таки процесс обновления у managed k8s намного проще, да и поставщиками он протестирован намного лучше (правда ведь?).

История 2. Обновление на cgroup2

А вы уже обновили свой kernel и начали использовать cgroup v2? Я - пробовал, и смело могу сказать, что данное обновление абсолютный рекордсмен по количеству возникших проблем. 

Все начиналось весьма стандартно - подходит срок обновления k8s до версии 1.23. Ничего необычного в release notes ни для k8s, ни для kops нет, по крайней мере, ничего критичного, что могло бы помешать обновлению, поэтому запланированное обновление получает зеленый свет. Проверяем flatcar. Тут имеется серьезное изменение - в новой версии cgroups v2 включены по умолчанию. Серьезно, однако, в k8s 1.22 данная функциональность присутствует, хоть и в версии alpha. 

Все-таки обновляем kops и k8s до версии 1.23, затем - flatcar image. Бам! На шаге обновления flatcar,  jvm приложения начинают падать по OOM. В целом, виновник понятен - cgroup v2 (проблема возникла на шаге с flatcar). Путем недолгих изысканий находится баг в JDK, согласно которому java-машина не видит лимиты по памяти установленные для контейнера работающего на cgroup v2. К тому времени OpenJDK выпустила релиз 16 версии с исправлением данной проблемы и обещала включить данное исправление в релиз 11.0.16, выходивший через 2 месяца. Провести major обновление OpenJDK не представлялось возможным, поэтому было решено ждать выпуска релиза OpenJDK 11.0.16.

Альтернативный способ решения данной проблемы

На самом деле, данную проблему можно решить без обновления OpenJDK путем явной установки лимитов для Java машины (в нашем случае для вычисления размера кучи используется параметр MaxRAMPercentage, который в случае c cgroup2 высчитывал размер кучи от доступной памяти машины)

Прошло немного времени и настало время второй попытки. JDK обновлен, k8s 1.23 задеплоен на dev, проведены базовые тесты - все работает. Продолжаем обновлять другие кластера, добираемся до CI/CD. И…, возникает новая проблема: ноды, работающие с повышенным loadavg (80-99%) начинают “тихо умирать”. Нужно отметить, что в условиях production такие нагрузки не есть хорошо, однако из CI/CD кластеров мы стараемся выжать максимум. 

Что же подразумевается под “тихой смертью” нод? В данном случае это ситуация, когда машина просто перестает отвечать на любой запрос - ни ICMP, ни SSH, вообще ничего не позволяет подключиться к ней.

Проанализировав все метрики, мы явно заметили превышенный loadavg (> 100%), который не стабилизируется, приводя к каскадным сбоям. Изучив репозиторий flatcar, мы наткнулись на проблему с деградацией производительности в новой версии. Данное предположение согласовывается еще с одной странностью, когда nodejs контейнеры с небольшими лимитами по памяти, после нашего обновления стали падать с OOM (небольшое увеличение лимитов помогло). 

Инвестировать больше времени в решение проблем, возникших при данном обновлении, не представлялось возможным и поэтому было принято решение отключить использование cgroup v2 на уровне flatcar (планируем вернуться к ее изучению при дальнейших обновлениях или же перейдем к использованию другого AMI вместо flatcar).

Какой вывод можно сделать из этой истории и причем здесь managed kubernetes? В случае использования его, вместо собственной инсталляции, возможность столкнуться с низкоуровневыми проблемами крайне мала, конечно, при условии следования рекомендациям облачного провайдера. Как правило, все облачные релизы содержат краткое описание breaking changes и вряд ли вы будете пытаться использовать не протестированные версии каких-либо компонентов.

История 3. Service accounts

Наверняка, многие сталкивались с проблемой разграничения доступа каждого отдельного сервиса в k8s к определенным компонентам инфраструктуры. В public clouds сложилась такая практика, что роли связываются с сервисами k8s через аннотации: то есть, если нужно, чтобы сервис обладал определенными доступами к конкретному сервису инфраструктуры (например операции чтения из определенного s3 bucket’a), внутри провайдера инфраструктуры необходимо создать роль с такими доступами, а потом просто добавить эту роль в аннотацию k8s service account’a, который будет связан с подом. На самом деле, для этих целей можно использовать стандартные подходы в виде access keys и secret keys (передавать их в качестве секрета в под), чтобы получать доступы к тем же ресурсам инфраструктуры, но, на мой взгляд, данный способ не такой удобный, как использование аннотаций. 

На этом месте хотелось бы привести пример какого-нибудь российского облачного провайдера, но, к сожалению, мне не удалось найти, чтобы хоть кто-то реализовал эту функциональность (может, просто плохо искал). 

На момент нашей начальной инсталляции k8s кластеров kops также не имел поддержки  сопоставления аннотаций service account’a и ролей, созданных в облачном провайдере.

Для того чтобы не терять эту возможность, мы воспользовались opensource альтернативой, чтобы связать наш k8s кластер с AWS инфраструктурой - KIAM. К нашему огорчению со временем этот проект перестали поддерживать, однако  к этому времени kops смог внедрить собственную поддержку Service Accounts интегрированную с AWS. После нескольких попыток мы так и не смогли начать использовать эту функциональность kops: как оказалось, мигрировать существующие кластера на нее без простоя невозможно. 

В итоге, продолжать использовать KIAM также не представляется возможным, т.к. в нем всплывают все новые и новые уязвимости, которые мы героически исправляем, а воспользоваться аналогичной функциональностью kops мы не можем, так как миграция требует простоя кластера.

Что из этого можно почерпнуть? Использование комбинации решений для установки своего кластера в конечном итоге может привести в тупик. Конечно, даже в таких ситуациях можно найти выход, но какова цена?

Итог и немного размышлений вслух

Протестую ли я против решений для упрощения разворачивания kubernetes кластеров? Ни в коем случае! Kops - это прекрасное решение, просто пока еще не зрелое. Помимо kops есть много аналогичных инструментов, которые также решают похожие задачи, но и они содержат большое количество недостатков.

Цена managed k8s cluster'a на AWS - 0.1$ в час, итого за месяц использования выходит - 0.1$ * 730 часов = 73$, то есть 12 k8s кластеров стоят 876$ в месяц. С моей точки зрения, цена времени devops инженеров, инвестируемого именно в поддержку, обновление и установку k8s кластеров, значительно превосходит стоимость услуги предоставления k8s кластера как сервиса.

UPD:

Спасибо vainkop за уточнение. И это еще без учета стоимости control-plane, которая включена в эти 73$.

Как правило SLA managed kubernetes сервисов достаточно высок. Цена managed k8s у остальных известных облачных провайдеров +- та же. Возможно, для IT рынка России это может быть не совсем актуальным, однако, в таком случае можно рассмотреть провайдеров предоставляющих k8s as a service. Пока мне не приходилось работать с такими кластерами, и беглый анализ сайтов таких провайдеров показывает, что цены отличаются в большую сторону и имеют ограниченную функциональность, но с другой стороны, всегда нужно оценивать количество сэкономленных девопсочасов при использовании готового решения.

Кто-то также может возразить, что использование своей инсталляции k8s это vendor agnostic решение, но на моей практике использование k8s это уже vendor agnostic, даже с учетом некоторых ограничений. Лично я предпочитаю направлять девопсочасы на эффективное использование имеющихся ресурсов и создание инфраструктуры без использования cloud specific сервисов (например DynamoDB, SQS и т.д.), путем размещения некоторые stateful сервисов внутри k8s кластера. Это позволяет быть независимым от облачных провайдеров и в случае чего без проблем переехать с одного на другой, если возникает такая необходимость. На мой взгляд, если вы небольшая компания, предоставляющая SaaS решение и имеющая возможность выбрать managed kubernetes - рассмотрите в первую очередь его. Решение не будет идеальным, но оно, я полагаю, поможет сэкономить достаточное количество человекочасов.

Комментарии (21)


  1. remendado
    04.01.2023 11:16
    +6

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


  1. Fitrager
    04.01.2023 11:56
    +4

    Такими размышлениями можно и свою квартиру никогда не покупать, а всегда снимать.


    1. arkashaErema Автор
      04.01.2023 12:13

      Мне кажется даже в вашем примере все зависит от обстоятельств, не говоря уж о k8s. Я не призываю всех поголовно отказываться от своего k8s, а просто рассказываю, что проблем у него хватает. С каждым новым релизом k8s становится все сложнее и сложнее, как по мне, а соответственно его поддержка все дороже и дороже. И с точки зрения оптимизации расходов важно найти ту самую грань, где выгоднее ставить свой k8s, а где воспользоваться готовым платным решением.


      1. Fitrager
        04.01.2023 15:20
        +1

        Мне кажется Kubernetes становится проще. Если раньше его развернуть было непросто, то сейчас есть kubeadm. Обновление через kubeadm upgrade или установка нового кластера. Плюс всегда можно почитать changelog. DevOps состоит не только из Kubernetes. Сопутствующие инструменты тоже изменяются и там тоже приходится разбираться. (тот же Gitlab).


        1. arkashaErema Автор
          04.01.2023 15:35

          То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service


    1. bayan79
      04.01.2023 13:15
      +1

      Аналогию понял, но тезис, в пользу которого Вы её используете, - нет. Мне правда интересно, что Вы имели ввиду, сможете поподробнее описать недостатки размышлений автора и чем плохо "всегда снимать" ?


      1. Fitrager
        04.01.2023 15:15

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

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


        1. romash
          05.01.2023 13:15
          +1

          Очень странная аналогия с квартирами, особенно в условиях перегретого рынка недвижимости РФ, покупать квартиру выглядит странной затей. Что касается пенсии или безработицы, то для таких ситуаций нужны накопления, надеяться прожить на одну пенсию – это вообще самоубийство.

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


          1. Fitrager
            05.01.2023 13:48

            Я не из РФ.


  1. onegreyonewhite
    04.01.2023 13:32
    +1

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

    Опять же, говорить что managed лучше, потому что у отдельно взятой команды с определённым коэффициентом прямоты рук что-то не получилось с отдельно взятым инструментом - ошибка выжившего наоборот. Долго юзали Rancher. Ни одной проблемы не возникло подобного рода. А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$. Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.

    Managed Kubernetes это про удобство и квалификацию команды, а не про стабильность и отсутствие багов.


    1. arkashaErema Автор
      04.01.2023 15:09

      Спасибо, что поделились своим опытом! Тоже юзали Rancher и выглядел он довольно неплохо на тот момент, однако с ним также возникало немало других проблем. Возможно, как Вы выразились, у нас был недостаточный коэффициент прямоты рук, но когда строили свой private cloud, мы много где отгребли.

      Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом

      Мне всегда было интересно почитать материалы на такие темы, особенно когда там описана миграция каких-нибудь сложных stateful сервисов. У меня как-то был опыт перетаскивания cassandra и postgres на другие k8s без простоя, но эти сервисы как бы подразумевают такую возможность. А вообще эта тема интересная, но как по мне это усложнение инфраструктуры. Кстати когда я описывал миграцию с KIAM, то да, это самый простой вариант обновления без простоя в нашей ситуации

      А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$

      Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?

      Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.

      Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?

      Managed Kubernetes это про удобство и квалификацию команды

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


      1. onegreyonewhite
        04.01.2023 16:29

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

        Наверное правильнее писать о том, что использовать нужно managed сервисы вместо stateful. Вот на такую статью надо сразу в карму плюсы кидать. Управляемый облаком кубер проблему миграции таких сервисов точно не решает точно, потому что шанс поломки ровно такой же, как и всех инструментов. За managed решением всегда один или несколько open source проектов или набор самостоятельных костылей, которые пишут ровно такие же специалисты (по квалификации, внимательности и качеству написания ченжлогов), что и у того же kops, rke, k3sup и прочих деплоеров.

        Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?

        Не хочется ребятам антирекламу делать, потому что объективно понимаю, что всего усмотреть просто невозможно в таких больших решениях. Да и так в двух словах не опишешь. Всё свелось к тому, что хотели до времени потушить кластер, чтоб деньги не кушал, а ноды остались бодрствовать. Техподдержка просто развела руками и сказала что баг и будут исправлять, а пока только убивать кластер. Благо в тестовом контуре всё было, так что и инсталляция небольшая была. К слову, остальные сервисы тушились хорошо.

        Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?

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

        Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры

        Мне скорее интересна мотивация пихать всё в куб. Может изначально облако подобрано не очень? Либо с архитектурой беда, раз на команду обслуживания нет денег. Тут больше вопросов только появляется.


        1. AirLight
          05.01.2023 07:29
          +1

          Stateful-сервисы - это не антипаттерн, а один из видов бизнес-сервисов. Некоторые сервисы просто невозможно сделать stateless, а другие нерационально. Речь идет о таких вещах как игровые сервера, потоковые сервисы, биржевые сервисы и так далее - везде, где важно иметь вычисления в большом объеме оперативной памяти и важно соблюдать порядок сигналов. Мне как разработчику и архитектору странно слышать от девопса призыв не делать stateful только потому что в кубере с ним проблемы. В некоторых бизнес-задачах такой опции просто нет. Специалист, который о своем удобстве думает больше, чем о задачах бизнеса у меня вызывает удивление.


          1. onegreyonewhite
            05.01.2023 10:19

            Чтобы у вас не подгорало с такой силой, уточню. Имелось в виду stateful в kubernetes. Этот механизм не так давно из альфы и беты вышел. Однако, его появление в кубе такой же костыль, как ansible-pull.

            Есть инструмент и спектр задач, который он предназначен покрывать. Многие stateful сервисы не рекомендует работу в контейнерах, потому что контейнер задуман эфимерным.


  1. vainkop
    05.01.2023 07:34

    Не нужно городить огород, в облаках с одним аккаунтом нужно использовать просто Terraform, с мультиаккаунтами Terragrunt, а не kops.

    Цена managed k8s cluster'a на AWS - 0.1$ в час, итого за месяц использования выходит - 0.1$ * 730 часов = 73$, то есть 12 k8s кластеров стоят 876$ в месяц.

    К чему эти подсчёты? Если ваш k8s не cloud provider managed, то вам вообще-то нужно 3 мастера и всякая обвязка, что не бесплатно. В итоге cloud managed k8s выйдет вам дешевле + не нужно обслуживать некоторые компоненты, а это время команды, т.е. $$$.

    использование k8s это уже vendor agnostic

    Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов? Не используя всё это, вы просто ограничиваете себя и свою команду в возможностях и тратите кучу $$$ на оплату лишних часов команды.

    в случае чего без проблем переехать с одного на другой, если возникает такая необходимость

    В случае чего?

    В случае необходимости резко сократить бюджет лучше изначально правильно планировать архитектуру именно с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc , хотя и это делают не все.

    Или нужно начать оказывать услуги клиентам там, где нет AWS (таких мест, помимо России, в мире всё меньше)? Такое, конечно, бывает, но часто (не всегда) можно обойтись proxy / cdn и т.д.

    В остальном, если у вас не какой-то серо чёрный бизнес и сам AWS вас не выгоняет, то смысла переезжать с него почти никогда нет.


    1. arkashaErema Автор
      05.01.2023 11:36

      Добрый день.

      К чему эти подсчёты?

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

      Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов?

      Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.

      с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc

      Spot instances можно как раз отнести к специфике использования облака, потому что не все облака это предоставляют


      1. vp7
        05.01.2023 22:01
        +1

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

        А потом иногда оказывается, что для получения бана в облаке достаточно иметь "неправильное" гражданство или проживать в "неправильной стране" или просто неверно высказаться про какое-то движение (хз, допустим вовремя не похвалить ЛГБТ, не встать на колено или не сделать какую-то ещё публичную трендовую штуку).

        p.s. Если что - это троллинг. В России довольно много компаний очень серьёзно попало с облачными сервисами только из-за того, что "потому, что санкции". И очень странно читать такую статью на русскоязычном ресурсе без упоминания того, что произошло совсем недавно (к примеру, я лишился своего AWS аккаунта из-за блокировки платежей моей карты Visa, но это же мои проблемы, верно?).


        1. vainkop
          06.01.2023 17:29

          Технически AWS самоё надёжное облако, которое по уровню доступности лучше, чем любое, что может запилить любая другая команда.

          Большинство software бизнеса никакого отношения к России не имеет.


      1. vainkop
        06.01.2023 17:34

        Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.

        Плохой пример и регионов всё больше и больше

        https://aws.amazon.com/blogs/aws/now-open-aws-region-in-the-united-arab-emirates-uae/

        Но чаще всего необходимости иметь инфру именно в том регионе реально нет.


        1. arkashaErema Автор
          06.01.2023 18:11

          Без упоминания про необходимость платить за мастеров, lb для них и т.д. в "своём" k8s это как-то странно.

          Да, согласен, упустил этот момент, спасибо. Добавил упоминание.

          Плохой пример и регионов всё больше и больше

          Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.


          1. vainkop
            06.01.2023 18:19

            Однако мой главный посыл был не только про AWS, а про любые облака в целом.

            2019 и 2023 это огромная разница и опубликовав статью в 2023 нужно понимать, что деплоить k8s в AWS не Terraform/Terragrunt, а kops'ом - это дичь. Также касается Azure и GCP.

            После нескольких попыток мы так и не смогли начать использовать эту функциональность kops: как оказалось, мигрировать существующие кластера на нее без простоя невозможно.

            Потому что не нужно использовать kops :) Хотя он не делает ничего магического и мигрировать существующие кластера с kiam на "IAM roles for service accounts" вам вероятно не удалось всё же не по вине kops или просто не докрутили.

            По-хорошему нужно просто написать Terraform/Terragrunt и воспользоваться import или создать новый EKS и мигрировать приложения в него.