24.10.2021 12:36
sundmoon 90 13000 Источник
Архитектура Kubernetes хорошо подходит для организаций типа FAANG, но может оказаться избыточной и чрезмерно сложной для прочих.

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

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

1. Kubernetes разработан для компаний типа FAANG


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

Если вы Google (чей оркестратор Borg лег в основу проекта Kubernetes с открытым исходным кодом), Kubernetes для вас отличный инструмент. Также это верно, если вы Netflix, Facebook, Amazon или другая веб-компания с десятками ЦОД и сотнями распределенных по ним приложений и сервисов.

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

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

2. Рынок Kubernetes раздроблен


Еще одна проблема с архитектурой Kubernetes заключается в том, что существует слишком много дистрибутивов Kubernetes — и слишком много различных инструментов, философий и связанных с ними подходов — так, что экосистема Kubernetes получилась слишком раздробленной.

Конечно, фрагментация это удел любой экосистемы с открытым исходным кодом, до некоторой степени. Например, в Red Hat Enterprise Linux другой менеджер пакетов, другие инструменты управления и так далее, чем в Ubuntu. Однако в Red Hat и Ubuntu больше сходства, чем различий. Если вы системный администратор и сегодня работаете с Red Hat, вам не нужно тратить шесть месяцев на изучение новых инструментов, если вы вдруг захотите перейти на Ubuntu.

Я не думаю, что то же самое верно применительно к Kubernetes. Если вы сегодня используете, скажем, OpenShift, но захотели перейти на VMware Tanzu, вам предстоит весьма крутая кривая обучения. Хотя оба этих дистрибутива Kubernetes используют одну и ту же базовую платформу, добавленные ими методологии и инструменты сильно различаются.

Подобная фрагментация наблюдается и в облачных сервисах Kubernetes. У Google Kubernetes Engine, или GKE, совсем другой пользовательский интерфейс и набор инструментов управления, чем у такой платформы, как Amazon EKS (аналога GKE в облаке AWS).

Конечно, тут не вина самой архитектуры Kubernetes, а результат стремления вендоров к дифференциации своих продуктов. Но это болезненная проблема с точки зрения пользователей Kubernetes.

3. В Kubernetes слишком много частей


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

Конечно, Kubernetes — сложная платформа, и для ее работы реально требуется множество частей. Но, сравнительно с другими сложными платформами, Kubernetes выделяется низким качеством интеграции своих различных частей в легко управляемое целое. Хотя ваш типичный дистрибутив Linux также состоит из множества различных программ, вам доступна установка и управление всеми ими централизованным и оптимизированным способом. С архитектурой Kubernetes так не получится.

4. Kubernetes не гарантирует высокую доступность автоматически


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

Это верно, что архитектура Kubernetes автоматически принимает разумные решения о том, где разместить рабочие нагрузки в кластере. Однако Kubernetes далеко не палочка-выручалочка для обеспечения высокой доступности. Например, он будет успешно работать в производственной среде с одним мастер-узлом — а это дорога к падению всего кластера. (Ведь рабочие нагрузки недолго протянут, если упадёт управляющий кластер из мастер узлов.)

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

5. Управлять Kubernetes вручную сложно.


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

Безусловно, есть способы изменить тайминги, используемые Kubernetes чтобы определить, правильно ли работает контейнер, или чтобы отправить рабочую нагрузку запускаться на определенном сервере в кластере. Но архитектура Kubernetes, на самом деле, не рассчитана на то, что администраторы будут вносить эти изменения вручную. Предполагается, что вы всегда будете довольны настройками по умолчанию.

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

6. У Kubernetes есть проблемы с мониторингом и оптимизацией производительности


Kubernetes пытается поддерживать ваши рабочие нагрузки в рабочем состоянии (хотя, как выше отмечалось, его способность делать это зависит от таких факторов, как количество установленных вами мастеров и ваша структура распределения ресурсов).

Но архитектура Kubernetes не очень-то помогает вам отслеживать рабочие нагрузки и обеспечивать их оптимальную производительность. Он не предупреждает вас о проблемах и не упрощает сбор данных мониторинга из кластера. Большинство поставляемых с дистрибутивами Kubernetes панелей мониторинга также не предлагают всестороннего обзора вашей среды. Существуют сторонние инструменты, которые дают вам такую ​​видимость — но это еще одна сущность, которую вам предстоит настроить, изучить её и управлять ею, если вы хотите запустить Kubernetes.

Точно так же, Kubernetes не очень-то хорош в том, чтобы помочь вам оптимизировать ваши расходы. Он не уведомляет вас, если серверы в кластере используются только на 20% мощности, что вероятно значит, что вы тратите деньги на избыточно выделенную инфраструктуру. И здесь сторонние инструменты могут помочь вам справиться с подобными проблемами, но сами они добавляют ещё больше сложности.

7. Kubernetes всё сводит к коду


В Kubernetes требуется писать код для выполнения практически любой задачи, обычно в виде файлов YAML, которые затем необходимо применить в командной строке Kubernetes.

Многие люди видят не баг, а фичу в архитектурном принципе Kubernetes «всё есть код». Однако, хотя я, безусловно, понимаю ценность возможности управлять всей платформой с использованием единых методологии и инструментария (то есть файлов YAML), я также хотел бы, чтобы Kubernetes предлагал и другие варианты для тех людей, которые в них нуждаются.

Бывают случаи, когда я для развертывания простой рабочей нагрузки не хочу писать длинный файл YAML — или тащить его с гитхаба, а затем вручную настраивать по частям в соответствии с моей средой. Когда мне нужно сделать что-нибудь простое в Kubernetes, мне действительно хотелось бы просто нажать кнопку или запустить простую команду (я имею в виду команду kubectl, не требующую дюжины аргументов, многие из которых настроены с помощью загадочной копипасты) — но так сделать редко удаётся.

8. Kubernetes хочет всё полностью контролировать


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

Это хорошо, если все ваши рабочие нагрузки контейнеризированы и могут оркестрироваться Kubernetes. Но что, если у вас есть устаревшие приложения, которые не могут работать в контейнерах? Или что, если вы хотите запустить часть рабочей нагрузки в кластере Kubernetes, а другую часть выполнять где-то снаружи? Kubernetes не предлагает встроенных функций для подобных задач. Он разработан в предположении, что все хотят запускать всё внутри контейнеров, и это навсегда.

Заключение


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

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

— От переводчика: —

Напоминаю более вкусные ссылки для ценителей кондитерских изделий:


K8s в проде и в разработке: четыре мифа

10 антипаттернов деплоя в Kubernetes: распространенные практики, для которых есть другие решения

11 факапов PRO-уровня при внедрении Kubernetes и как их избежать

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


  1. dimuska139
    24.10.2021 12:45
    #23624600
    +2

    А что вместо? Вот, допустим, у меня есть небольшая (в плане ресурсов) VPS, на которой мне нужно запустить 5 приложений (например): API сайта, SSR сайта, обработчики очередей, сервис email-рассылок и сервис с грабберами какими-нибудь. Как это правильно развернуть на VPS? Сейчас сам сервер настраиваю через Ansible (установка PostgreSQL, Docker, Docker-compose, конфиги и т.п.), а мои приложения в контейнерах запускаются через docker-compose. Деплой сделан через GitlabCI: сборка образа, доставка его на сервер и рестарт docker-compose. Но выглядит, если честно, костыльненько, и есть мысль k3s попробовать.


    1. kalombo
      24.10.2021 13:06
      #23624662

      Но выглядит, если честно, костыльненько

      https://www.youtube.com/watch?v=LeVULLqWwcg

      Не существует "правильного" способа, об этом и есть первый пункт. Если у вас всё работает, не возникает никаких проблем, то какая разница как это выглядит?


      1. dimuska139
        24.10.2021 13:14
        #23624682

        Ну примерно так, как на видео, да)

        лучше бы мне было использовать решение попроще

        Я вот про это решение попроще и спрашиваю. В статье про него не написано.


        1. kotomyava
          02.11.2021 21:42
          #23660958

          Зато в статье предостерегают от решения посложнее. И k8s это точно оно на таком масштабе. =)


    1. Tiendil
      24.10.2021 13:06
      #23624664
      -1

      Выглядит нормально. В чём костыли?


      1. dimuska139
        24.10.2021 13:17
        #23624694

        Ну, например, если я захочу сделать какой-нибудь rollingUpdate, то эта схема уже становится не особо рабочей, т.к. для этого нужен хотя бы Docker Swarm. Если заказчик захочет, например, SSR-сервис вынести на более производительный отдельный VPS, то это опять-таки боль. Понятное дело, что глупо пытаться всё заранее предусмотреть, но с задачей вынести что-то на отдельный VPS сталкивался не раз.


        1. ggo
          25.10.2021 10:32
          #23627256

          rollingUpdate и множество хостов - вполне дружат с docker-compose и ansible.

          эмпирически вывел для себя формулу когда надо переезжать на кубер: приложений >=5, нод больше >=15.


          1. dimuska139
            25.10.2021 10:39
            #23627294

            Подскажите, пожалуйста, а как сделать в таком случае rollingUpdate? Поднимать все сервисы на других портах, переписывать конфиг Nginx (чтобы новый порт использовал), а потом гасить старый docker-compose?


            1. ggo
              25.10.2021 10:54
              #23627362

              очевидно, только двумя (или больше) экземплярами приложения и прокси перед ними


    1. emashev
      24.10.2021 14:03
      #23624832
      +3

      Я пробовал поднимать microk8s для подобного проекта на маленькой vps, 2cpu, 2gb ram. В итоге, почти все ресурсы съедал k8s. Перевел обратно на compose. Для непрерывной интеграции можно настроить green blue deploy или swarm поднять одной командой.


      1. dimuska139
        24.10.2021 15:07
        #23625020

        Спасибо за информацию! Кстати, да, Кубер много оперативной памяти требует.


      1. shred_dev_sda
        24.10.2021 16:21
        #23625214
        +2

        k3s just 70mb of RAM


        1. dimuska139
          24.10.2021 21:09
          #23625964
          +1

          Прямо реально настолько мало?


          1. Tihon_V
            25.10.2021 10:02
            #23627090

            Дома запущен на RPI4. Но у него и HA по умолчанию отключен, при включении фич - растет использование ОЗУ.


      1. Evengard
        24.10.2021 19:32
        #23625704

        k3s жрёт хоть и поменьше, но вообще для кубера 2 cpu и 2 gb ram откровенно маловато.


    1. Akuma
      24.10.2021 15:51
      #23625126
      +1

      Swarm не советую. Слишком…простой для нескольких серверов.

      Используйте rke + rancher. Настраивается просто, можно даже на одной машине. Работает стабильно. Умеет обновлять версию k8s. Даже если сломаете все, восстановить с нуля - пара команд и пол часа времени.


      1. Frankenstine
        25.10.2021 13:49
        #23628220

        Чёт я попробовал ранчер на арм машине и оно не завелось. В веб интерфейсе не появились данные для подключения узлов. Видимо оно нормально работает только на х64 железе.


        1. Akuma
          25.10.2021 14:47
          #23628492

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

          т.е. чтобы там что-то было, у вас уже должен быть кластер, в идеале.


          1. Frankenstine
            25.10.2021 15:04
            #23628584

            Дык в том-то и дело, что кластер я создал, а подключить в него рабочий узел не вышло. Через морду. Лезть руками тикеты извлекать - а зачем тогда ранчер... Сразу уж тогда его нахрен и делать всё руками.


            1. Akuma
              25.10.2021 16:07
              #23628852

              Стоп. Что значит "подключить рабочий узел"? Добавить ноду? Так это не забота ранчера, он не для этого.

              Если создавали кластер через rke, то добавьте ноду в конфиг и сделайте rke up

              Если создавали чем-то другим, то уже в этом "чем-то другом"


              1. Frankenstine
                25.10.2021 16:24
                #23628914

                Я смотрел на ранчер по этой статье: https://habr.com/ru/post/418691/

                И вот на шаге "Чтобы добавить воркер, перейдите в редактирование кластера в web интерфейсе Rancher, увидите то же меню, которое генерирует команду подключения", я увидел фигу, пустой веб интерфейс.


                1. Akuma
                  25.10.2021 16:44
                  #23628980

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

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

                  Ранчер лучше использовать просто как веб-интерфейс к кластеру. Лучше него пока не нашел.


    1. hippoage
      24.10.2021 16:38
      #23625252
      +2

      Лучше отдельный systemd-сервис на каждое приложение. Podman (из RH операционок) умеет командой такие делать. Для Docker нужно будет самому написать. Пример из Podman:

      $ cat container-sites.service
# container-sites.service
# autogenerated by Podman 2.0.5
# Fri Feb 19 05:50:30 UTC 2021

[Unit]
Description=Podman container-sites.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStartPre=/bin/rm -f %t/container-sites.pid %t/container-sites.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-sites.pid --cidfile %t/container-sites.ctr-id --cgroups=no-conmon --replace -d --name sites --network=cni-podman1 -p 80:80 -p 443:443 -p 127.0.0.1:2019:2019 -v /data/Caddyfile:/etc/caddy/Caddyfile -v /data/sites:/sites -v /data/sites-data:/data -v /data/sites-config:/config myaccount/site:v1.0.0s-dev
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-sites.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-sites.ctr-id
PIDFile=%t/container-sites.pid
KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target default.target


      1. baldr
        25.10.2021 10:02
        #23627088

        Для одного сервера systemd - самое простое решение, сам так делаю (для Docker). Но если вдруг захочется масштабироваться - уже надо что-то придумывать.


        1. hippoage
          26.10.2021 08:11
          #23630730

          Да, возвращаться к Kubernetes ;).


    1. Zada
      24.10.2021 18:57
      #23625598
      +1

      Для вашего случая подойдёт nomad.


    1. jidckii
      26.10.2021 07:41
      #23630674

      Костыльненько конечно.
      Nomad полегче, но его тоже курить надо, да и тулинга меньше к нему.
      Хотя ресурсы он и правда почти не ест.
      Берите k3s или microk8s (второй вообще из коробки с собой всё имеет) и не парьтесь. Чарты для куба есть уже для постгреса, кролика и прочего, есть ингрес, серт-менеджер...
      в номаде ничего этого нет.
      Придётся использовать traefik, то ещё удовольствие.
      Хотя у меня есть пет проджект на номаде, год работает, есть пить не просит.
      Но там специфика проекта, в контейнерах не запустить.
      Так то с удовольствием бы уехал в куб )


      1. dimuska139
        26.10.2021 10:10
        #23631034
        -1

        Говорят, кубер много ресурсов требует. k3s и microk8s - в том числе. Ну то есть 2 Гб оперативки и 2 ядра CPU - это мало.


        1. jidckii
          26.10.2021 11:28
          #23631322

          Врут)  k3s и microk8s жрут на много меньше. Просто если вы доставите все операторы, ингрес, дашборд и так далее, то они тоже будут какое то кол-во ресурсов требовать...


          1. dimuska139
            26.10.2021 11:35
            #23631352

            Ну 2 Гб оперативки и 2 ядра CPU хватит для мастер-ноды и нескольких (не особо требовательных к ресурсам) подов там же? "не особо требовательных к ресурсам" - это в районе 128 Мб оперативки каждый требует, а их 3 штуки.


  1. Semenych
    24.10.2021 13:31
    #23624740
    +3

    у меня такой же вопрос про альтернативы. Да k8s имеет много недостатков. Но вот у меня есть docker-compose с вязанкой сервисов созданный разработчиками. Мне надо его переместить в рабочее окружение. Т.е. сделать чтобы у меня было несколько экземпляров нужных мне сервисов, правильно сконфигурированных.

    Что использовать? K8S это конечно кошмар. Но какие альтернативы? Какой-то конвертер в ansible? Swarm?

    Я без ехидства, мне реально нужно.


    1. easyman
      24.10.2021 13:43
      #23624780
      +12

      Nomad https://www.nomadproject.io/


      1. chemtech
        24.10.2021 13:56
        #23624810
        +1

        Почему минусуют за nomad? Вопрос же у человека: какая может быть замена docker-compose.


      1. Semenych
        24.10.2021 14:06
        #23624848
        +1

        Выглядит интересно. Вопрос в том не является ли это заменой одного зла на другое?

        K8S хотя бы используется широко и его много кто знает.


        1. chemtech
          24.10.2021 14:39
          #23624946

          nomad делает так же компания что и terraform, packer, consul, vault.

          У nomad есть rolling update https://learn.hashicorp.com/tutorials/nomad/job-rolling-update - а у docker-compose rolling update нет.


          1. Semenych
            24.10.2021 14:42
            #23624954

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


            1. chemtech
              24.10.2021 14:45
              #23624966

              К сожалению nomad не использую. Спросите в чате https://t.me/ru_hashicorp


        1. iroln
          24.10.2021 15:17
          #23625038

          Есть ещё такая статья: Возможно, вам не нужен Kubernetes
          Они там как раз для своего случая используют Nomad.


        1. jidckii
          26.10.2021 07:45
          #23630682

          Nomad как и k8s имеет деклатаривное описание и стремится к состоянию, тот же swarm это задеплоил, а как раздеплоить при удалении сервиса из yaml файла хз...

          Попробуйте, там всё настраивается за 5 минут. И документация хорошая)


  1. chemtech
    24.10.2021 14:13
    #23624872
    +3

    Kubernetes разработан для компаний типа FAANG

    возможно, десяток приложений для развертывания, 

    для развертывания всего одного или двух приложений 

    На счет FAANG - неправда. Куча других компаний использует kubernetes. Если 10 приложений - то использование оправдано.

    Это не значит, что Kubernetes никогда не будет полезен для небольших развертываний

    Небольших развертываний это примерно сколько там приложений?

    Но архитектура Kubernetes не очень-то помогает вам отслеживать рабочие нагрузки и обеспечивать их оптимальную производительность.

    При увеличении нагрузки HPA или KEDA увеличивают кол-во реплик, а при уменьшении нагрузки уменьшают кол-во реплик.

    Многие люди видят не баг, а фичу в архитектурном принципе Kubernetes «всё есть код»

    Сейчас это называется GitOps.


    1. sundmoon Автор
      24.10.2021 14:31
      #23624924
      -2

      На счет FAANG — неправда. Куча других компаний использует kubernetes.

      В оригинале web-scale companies. Netflix (который не FAANG) автор ниже прямо упоминает.


      Если 10 приложений — то использование оправдано.
      Небольших развертываний это примерно сколько там приложений?

      Автор предлагает усомниться в этом массовом предрассудке.
      Не все приложения stateless и вообще бесплатно контейнеризуемы.
      (Кстати, я в курсе про StatefulSet)


      При увеличении нагрузки HPA или KEDA увеличивают кол-во реплик, а при уменьшении нагрузки уменьшают кол-во реплик.

      Это ещё одна пара сущностей, которым нужен менеджмент.
      И кстати когда они появились? Статье больше года… и только с менеджментом в экосистеме куба в целом не полегчало.
      OpenShift vs. Tanzu vs. 100500…


      Сейчас это называется GitOps.

      Мне лично тоже по вкусу этот свиной хрящик. Но я бы воздержался от хайпа и тотального навязывания своего вкуса..


      1. chemtech
        24.10.2021 14:42
        #23624962
        +1

        OpenShift используют компании с обычной инфраструктурой, потому что OpenShift интегрируется с Active Directory из коробки. Но OpenShift и стоит денег.

        Tanzu не видел чтобы кто то использовал.

        Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler. You can add custom metrics for the Horizontal Pod Autoscaler to use in the autoscaling/v2beta2 API. Kubernetes then queries the new custom metrics API to fetch the values of the appropriate custom metrics.

        https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics


        1. sundmoon Автор
          24.10.2021 15:11
          #23625024
          -1

          OpenShift используют компании с обычной инфраструктурой, потому что OpenShift интегрируется с Active Directory из коробки. Но OpenShift и стоит денег.
          Tanzu не видел чтобы кто то использовал.

          Второе, очевидно, используют компании c инфраструктурой vSphere 7+.
          Кстати, инфра Vmware интегрирована с AD целую вечность (с тех пор как они лицензировали Likewise.)


          И то, и другое — opinionated управлялки. "Соборы", вместо экосистематичного "базара".


          Автор толкует о том в частности, что "базар" кубера злокачественней линуксового "базара".


          Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler

          Угу, принято. И про Netflix тоже.


        1. hippoage
          24.10.2021 16:09
          #23625178

          OpenShift без поддержки называется OKD (и он бесплатен).

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


          1. chemtech
            24.10.2021 16:19
            #23625204

            Про OKD знаем. У заказчика стоит Openshift 3.11 - возможно это OKD. Мы там права юзера имеем. Почему не обновляет до новых версий - не знаю.


            1. Renatk
              25.10.2021 17:31
              #23629134

              Новые версии OKD очень требовательны по ресурсам:

              One host is required with at least 8 CPU cores, 32.00 GiB of RAM, and 120 GB of filesystem storage.

              Или для dev/локального запуска:

              • 4 physical CPU cores

              • 9 GB of free memory

              • 35 GB of storage space

              https://access.redhat.com/documentation/en-us/red_hat_codeready_containers/1.34/html/getting_started_guide/installation_gsg#minimum-system-requirements-hardware_gsg


              1. hippoage
                26.10.2021 08:30
                #23630750

                Непонятно откуда требования, выделенные жирным. Вот документация (там 4/16/100 для мастера и 2/8/100 для worker): https://docs.openshift.com/container-platform/4.9/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal . При этом на практике я бы не делал ноды меньше 8/32. И, понятно, число нод должно быть таким, чтобы ресурсы на 3 мастера на их фоне выглядели как ничто.

                Про dev (CodeReady Containers) -- это именно OpenShift (с ui и прочим). Если достаточно чистого Kubernetes, то его в Docker можно включить.


          1. sundmoon Автор
            24.10.2021 22:07
            #23626088

            Tanzu тожу недавно обзавелись "коммунальной" редакцией.


      1. storoj
        24.10.2021 14:48
        #23624978
        +1

        А что такое N в FAANG?


        1. chemtech
          24.10.2021 14:52
          #23624992
          +2

          @sundmoon

          Facebook, Amazon, Apple, Netflix и Google (FAANG) https://ru.wikipedia.org/wiki/Facebook,_Apple,_Amazon,_Netflix_и_Google


      1. pankraty
        24.10.2021 14:51
        #23624980
        +5

        В оригинале web-scale companies. Netflix (который не FAANG) автор ниже прямо упоминает.

        Я извиняюсь, но Netflix это N в FAANG.


  1. Akuma
    24.10.2021 15:57
    #23625136
    +1

    Ну не знаю. Использую k8s (rke, rancher, helm) в собственном проекте на VDS + железный сервер. Начинали с двух машин. Сейчас их десяток где-то.

    Очень удобно, никаких претензий. Лишь один раз helm заклинило и он мне снес весь чарт проекта. Ну восстановил за пол часа где-то, бывает.

    По мне так k8s можно использовать и на маленьких проектах. Разве что минимальные требования к серверам не такие уж и маленькие: мастер сжирает ресурсы довольно прилично даже для пары воркеров.


    1. dimuska139
      24.10.2021 21:11
      #23625972

      Скажите, пожалуйста, а сколько нужно, если совсем по-минимальному? И второй вопрос: правильно ли я понял, что VDS должно быть минимум 2 штуки: 1- мастер-нода, 2 - воркер?


      1. Akuma
        24.10.2021 21:25
        #23626004
        +1

        Совсем по минимальному хватит одной VDS на 2-4 ядра и 8-12 ОЗУ. Этого хватит чтобы запустить мастер и на нем же что-то рабочее. Фактически k8s без разницы где и что запускать, можно все фигачить на одной машине.

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

        Россказни про "нужно минимум три мастера" - просто россказни. Если вы не гугл, то одного мастера вполне хватит. Даже если упадет - все продолжить работать, просто без контроля запуска, этого хватит на "переподнять мастер". Но фактически падать там нечему.

        Rancher тоже можно запустить на этой же ноде, правда это не удобно (потребуется переносить 443 на другой порт, а браузеры этого не любят, особенно на самоподписанном сертификате-IP). У меня под него тоже отдельная чуть ли не сама дешевая VDS.


        1. dimuska139
          24.10.2021 22:10
          #23626102

          Понял, спасибо Вам большое - ценная информация.


        1. hippoage
          26.10.2021 08:42
          #23630764

          Непонятно как вы собираетесь переподнимать 1 мастер. Если 1 мастер и он упал, то нужно переставлять весь кластер (при этом да, приложения продолжают работать, если не используют k8s api -- cron, скейлинг и тп). Переставить кластер вполне может быть приемлемым, не каждый год оно падает, а простой может быть дешевым.

          При этом, если есть хотя бы 3 ноды, то нет особых причин не запустить 3 мастера. На мастерах можно запускать обычные поды (настройка). Оверхед 2х дополнительных etcd не такой уж большой, зато кластер не нужно будет переставлять.

          Был опыт работы с K8s на мелких виртуалках в Digital Ocean. И сам с нуля поднимал, и подключал воркер в их сервис. В итоге, оно нестабильно работает -- через пару месяцев само ломается. А вот с docker из systemd проблем нет. Для ультрамелких деплоев пока что так делаю.


          1. Akuma
            26.10.2021 09:40
            #23630922

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

            Если мастер просто перезагрузился (например VDS дернули) - он просто запустится и кластер продолжит работу как ни в чем ни бывало. У меня такое было пару раз - все хорошо закончилось.

            Оверхед от мастера довольно чувствительный. Возможно причина в запуске через rke, не знаю. Но учитывая стоимость VDS мне проще выделить для него отдельные ядра и память и не заморачиваться. К тому же рабочие ноды я иногда перезапускаю/обновляю. Сломать ноду "лучше", чем сломать мастер-ноду.

            Не знаю на счет DO. Возможно причина в их реализации. Я работал с GKE - это вообще идеал. Работал с Selectel на старте - это прям беда, у них все слетало. Потом плюнул и запустил кластер на обычных железках: работает уже третий год.


      1. hippoage
        26.10.2021 08:49
        #23630778

        Мастеров может быть 1, 3+. Мастер может быть и воркером (т.е. запускать обычную нагрузку). OpenShift 4 поддерживает только 2 сценария: 1 (при этом нельзя добавить воркеров) или 3 мастера.

        Воркеров может быть 0+.

        Важно дать памяти достаточно, т.к. swap в K8s отключен. Для стабильной работы должен быть запас по свободной памяти.

        Если совсем по минимальному, то я бы не использовал K8s, т.к. будут все связанные сложности, а развернуть кучу удобных сервисов ресурсов не будет.


  1. Volakrab
    24.10.2021 15:58
    #23625144
    +2

    Классика же.


  1. hippoage
    24.10.2021 16:28
    #23625228
    +3

    Kubernetes -- это основа Private Cloud. Из этого 2 следствия:

    • Cloud, хоть и Private, сложно масштабировать вниз.

    • Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов. И да, их нужно ставить, настраивать и обслуживать. И далеко не все из них есть в готовых дистрибьютивах типа OpenShift. Тут Kubernetes можно рассматривать как Linux (ядро), по отношению к дистрибьютивам.

    Есть варианты малых кластеров, но они для удаленных офисов (Edge) или разработки/тестирования.

    Исходя из этого, все претензии изначальной статьи выглядят странно. Кроме разве проблем масштабирования вниз. Об этом нужно знать и использовать другие решения: K8s в публичном облаке или более классические решения (Anisble).


    1. PositiveAlex
      24.10.2021 21:37
      #23626024

      Его ещё называют кластерной операционной системой


      1. chemtech
        25.10.2021 07:06
        #23626708

        Кого?


        1. PositiveAlex
          25.10.2021 08:24
          #23626832

          Слышал такое определение Kubernetes на slurm.io


      1. hippoage
        25.10.2021 08:30
        #23626842
        +1

        Да, публичные облака тоже называют новым видом операционной системы.


        1. sundmoon Автор
          25.10.2021 11:46
          #23627652
          +2

          Правдоподобнее публичные облака сравнивать с мейнфреймами.
          Дико дорогой компьютер, тебе продают доступ попользоваться крошечной долей его ресурсов.


          Именно что допускают, не только к софту, но и к железу чужого дяди.


    1. sundmoon Автор
      25.10.2021 11:59
      #23627722
      +1

      Cloud, хоть и Private, сложно масштабировать вниз.
      Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов.

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


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


      Сейчас актуален всё тот же FUD, что и раньше — "увольте админа, купите чудо-продукт" — но уже в виде дериватива: "админ не справится скейлить 100500 сервисов, используйте оркестратор" (вариант "откажитесь от своего железа, покупайте немножечко нашего мейнфрейма облака").


      Плохо вестись на такое — и подписываться на внедрение и обслуживание очередной чудо-автоматизации или чудо-оркестрации. Ну или покупать вместо этого managed кубер время гиперквалифицированных чудо-SRE.


  1. PositiveAlex
    24.10.2021 21:35
    #23626018
    +4

    Статья размытая, не несущая конкретики толком.

    Альтернативы никакой нет. При этом говорятся очевидные вещи, вроде того, что это не палочка выручалочка.

    Ну да, нет ничего идеального в этом мире.

    Но кубер очевидно лучше чем docker compose. Его легко поднять локально через minikube (супер удобная штука, single click run k8s). Конфигурации на нем писать одно удовольствие - он поддерживает не через жо пятую точку все что нужно приложениям и их интеграции.

    Наверное, если у вас статический сайт-визитка, вам кубер не нужен, так это вроде очевидно ????????‍♂️


    1. sundmoon Автор
      24.10.2021 22:22
      #23626140
      +1

      Но кубер очевидно лучше чем docker compose.

      Вовсе неочевидна необходимость в том, чтобы всё подряд контейнеризовать. Тем более, что это занятие далеко не бесплатно.


      Мне кажется, что автор за "собор" и против "базара"; однако последний он готов признать неизбежным злом. Конкретно недоволен он фрагментацией экосистемы кубера, более злокачественной по его мнению, чем фрагментация дистрибутивов Линукса.


      1. PositiveAlex
        24.10.2021 23:18
        #23626272

        Все подряд и не нужно, использование кубера не подразумевает, что надо все запихнуть в контейнеры же. Его крутость в том, что это кластерная о/с, ты же свои деплойменты можешь синтегрировать с любым сервисом из bare metal. Особенно используя helm + ansible.

        Естественно, бд в контейнере нет, естественно не все проекты сразу перейдут в кубер, а кто-то и не перейдет вовсе, и это будет работать какие-то годы возможно параллельно.

        Конкретно недоволен он фрагментацией экосистемы кубера

        Ну, в этом, конечно есть правда. Но и время жизни линукса не сравнить с к8с. Время покажет, как обычно, кто вымрет, кто выживет.

        Может быть, его архитектура ещё упростится.


  1. celebrate
    24.10.2021 21:54
    #23626060
    +1

    Это вы еще Опенстек не видели. Кубер просто мана небесная по сравнению с ним.


  1. Color
    25.10.2021 12:06
    #23627746
    +2

    Я понимаю, что отвечаю в пустоту, но

    Kubernetes разработан для компаний типа FAANG

    Это архитектурная проблема? Кмк, это большой плюс - компании типа FAANG могут дизайнить платформенные продукты вроде k8s с хорошим пониманием разного рода нагрузок и сценарием. Когда этим занимается небольшой стартап, получаем инструмент навроде swarm - слабо расширяемый и ограниченно масштабируемый.

    Рынок Kubernetes раздроблен

    Ровно наоборот. Любой вендор может сколь угодно перепиливать ванильный k8s и обмазывать его своими плагинами, clusterapi и прочими свистоперделками, но покуда он совместим с требованиями CNCF - кто угодно может запускать на нем что угодно.

    В Kubernetes слишком много частей

    "Kubernetes - это всего 5 бинарей!" (с). На самом деле частей много, потому что уровней абстракции много - и большинство порождены не k8s, а инфраструктурой. Да, это сложно, но сложно не потому, что k8s, а потому, что виртуализация и оркестрация - в целом сложная тема. K8s упрощает ее достаточно сильно не настолько, чтобы она стала простой.

    Управлять Kubernetes вручную сложно

    Здесь возразить нечего, это действительно так. Как и управлять кластером БД, или кластером Kafka сложно. Поэтому имеет смысл использовать managed k8s, покуда вам не станет выгоднее держать свой штат девопсов, чем платить облаку. (здесь могла быть нативочка, но ее не будет)

    У Kubernetes есть проблемы с мониторингом и оптимизацией производительности

    И снова все ровно наоборот. K8s (точнее, Metrics API) предоставляет единый и единообразный мониторинг всего и вся в k8s. Мониторинг же бизнесовых показателей ничем не меняется по сравнению с запуском в другом окружении.

    Что касается производительности - и снова нет. K8s наоборот позволяет более полно утилизировать ресурсы за счет шедулера + гибких правил (taints, affinity, вот это все). В итоге простоя ресурсов меньше, чек меньше (если нагрузки вообще есть, конечно. Сам кластер тоже что-то ест).

    Kubernetes всё сводит к коду

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

    Kubernetes хочет всё полностью контролировать

    Кмк, так говорить - некорректно. K8s хочет контролировать все, что внутри кластера - это логично. При этом интеграция с ресурсами вне кластера очень даже работает - посмотрите у любого облачного провайдера. Для особых энтузиастов есть инструменты вроде Cilium, с которыми эти интеграции еще сильнее упрощаются (ценой дополнительных уровней абстракции, конечно).


    1. sundmoon Автор
      25.10.2021 12:29
      #23627844

      Тем, кто не FAANG и не собирается в их клуб — зачем "облачная ОС" именно того чужого надчеловеческого масштаба?


      Зачем например хаять rancher, как это делают слёрмовцы?


      1. Color
        25.10.2021 12:44
        #23627912
        +2

        Да нет там никакого надчеловеческого масштаба. K8s - это не облачная ОС, а платформа виртуализации, по сути, только с человеческим лицом в виде манифестов вместо каких-то сложных api и инструментов вроде vmomi.

        Зачем хаять k3s - я не знаю, но k3s - это проект для "игрушечного" запуска куба - локально, в dev окружении или еще где. Он не прод-реди, его задача другая, вот и все, в остальном ничего плохого то нет.

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


        1. sundmoon Автор
          25.10.2021 12:59
          #23627998
          -1

          "не прод-реди" это такой FUD.


          Аналогичным образом продавцы железных рейдов когда-то хаяли ZFS. Которыя, будучи по сути SDS, работала и на их железках — но предпочитала чтобы ненужные надмозги контроллеров были "отшиблены" перепрошивкой, ради прямого доступа к носителям.


          https://habr.com/ru/post/585164/#comment_23627722


          1. Color
            25.10.2021 13:12
            #23628062
            +1

            У всех свои запросы. Знаю компании, у которых прод. нагрузка бежит на виртуалке с компоузом, знаю компании, где аналогичные нагрузки бегут просто на докере, а им управляет самописное cli приложение.

            Вопрос в том, какие требования к инфраструктуре. Если требования "запустить один контейнер", то k8s тут явно лишний, да и k3s - тоже.

            У k3s есть четкое и понятное назначение - это локальные окружения и "тесные" условия - эдж, всякие малинки и прочее. Кроме того, k3s идет на большое количество упрощений (как то использование однонодовой неотказоустойчивой ДБ вместо распределенной etcd и вообще минимальная отказоустойчивость. В "отказоустойчивом" варианте k3s мало чем отличается от k8s).

            Подходит ли это для ваших нужд - вопрос только к вам. В плане долгосрочного использования k3s сильно проигрывает k8s как по возможностям обслуживания, так по масштабированию, отказоустойчивасти и прочим характеристикам прод. среды. Но возможно, время это исправит, тем более, что появляются интересные проекты вроде Talos - нацеленные на простоту и "изкоробочность".


            1. sundmoon Автор
              25.10.2021 13:26
              #23628122
              -1

              У всех свои запросы.

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


              локальные окружения и "тесные" условия

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


              (Утрирую.) Моя позиция в том, что у 88% организаций условия "тесные" — настолько, что им не по карману перераспределять бюджеты ради приобретения облачных подписок.


              Мы могли бы уже "заключить перемирие", на том, чтобы вы окучивали оставшиеся 12% "небомжей".


              Но вы зачем-то продолжаете продавать доступ к мейнфреймам облакам всем остальным. Предлагая им принять участие в финансировании ненужных им чужого железа и чужого управляльного софта.


              1. Color
                25.10.2021 15:12
                #23628612
                +1

                 Моя позиция в том, что у 88% организаций условия "тесные" — настолько, что им не по карману перераспределять бюджеты ради приобретения облачных подписок.

                У меня нет такой статистики. Если у вас есть - поделитесь.

                То есть, вы уже согласились с автором в первом пункте

                Нет, не согласился. Для компаний уровня FAANG k8s как раз не очень подходит из-за одной особенности - он слишком "общий". Именно поэтому гугл использует borg, а не k8s - borg умеет работать только с одной OC, только с одним набором библиотек и только с определенным железом. За счет этого достигается большая эффективность.

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

                Под это подходят средние и крупные компании, не подходят мелкие (стартапы) и очень крупные (мегакорпорации).

                Но вы зачем-то продолжаете продавать доступ

                Кто «вы-то»?! (с)

                Я ничего не продаю. А если говорить про публичные облака, то обычно предлагают разные варианты с различным количеством operations - обычно это VM, K8s, какие-нибудь контейнеры, и какие-нибудь функции. Например, у GCP это Compute Engine, GKE, App Runner и Cloud Functions соответственно. При этом уровень operations снижается, а цена повышается (потому что цена operations входит в цену услуги).

                Наверное понятно, что если бы k8s подходил для всех, то других услуг не было бы. Вопрос в том, чтобы понять, кому что подходит.


                1. sundmoon Автор
                  25.10.2021 17:50
                  #23629170
                  -1

                  У меня нет такой статистики. Если у вас есть — поделитесь.

                  Ни у кого нет и не может быть статистики, когда речь идёт о самоощущении организации. "Да, мы бомжи и у нас условия тесные". (И да, я полагаю что 88 процентов таких оценка ещё заниженная).


                  И тут к ним приходите вы с рекламой аутсорса отказа от собственной наземной инфраструктуры и регулярной ренты в карманы хозяевам мейнфреймов облаков. То есть — с рекламой такого потребления, которое им "не по сеньке шапка".


                  Если вам удастся разбудить в принимающем решения лице статусного потребителя — вы выиграли, и своё на той организации заработали.


                  Попробуйте теперь статистикой или как-то иначе доказать, что это ситуация win-win, а не наоборот.


                  1. Color
                    25.10.2021 19:09
                    #23629444
                    +1

                    Да кто "вы" то? Я никому ничего не продаю. И убеждать никого ни в чем не собираюсь. Пожалуйста поберегите подмену тезисов для другого случая.

                    Аргументы мои выше. Серьезных контраргументов (кроме необъяснимых "88%") я не увидел.

                    Что же касается облаков - то тут я тоже не понимаю, в чем вопрос. Облака - это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s - есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.


                    1. sundmoon Автор
                      25.10.2021 20:37
                      #23629770
                      -1

                      К большому сожалению, я не увидел у вас аргументов, а увидел коврово-бомбометательную рекламу.


                      Убей мамку и отдай квартиру вон тому дяде откажись от своей наземной инфраструктуры и регулярно заноси облачным провайдерам.


                      Но в принципе мы с КО согласны, что богатым и здоровым быть лучше, чем бедным и больным.


                      Облака — это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s — есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.

                      Ну то есть, вы именно фрагментацию экосистемы продаёте как её примущество. Отлично понимая, что офигевшим клиентам на этом "базаре" прямая дорога под крыло управляемых сервисов.


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


          1. Color
            25.10.2021 13:15
            #23628070
            +1

            Ну и надо понимать, что "k8s не для бомжей" - это однозначно инструмент для тех, кто выигрывает что-то от его использования, потому что и сам кластер потребляет немало ресурсов, и его обслуживание и настройка чего-то стоят.

            Если нагрузки вида "три контейнера, Postgres и API Gateway" - лучше посмотреть в сторону Heroku или GCP App Runner вкупе с managed DB.


  1. amarkevich
    25.10.2021 21:47
    #23630006
    +1

    Kubernetes разработан для компаний типа FAANG

    удобно пользоваться и в небольших проектах, даже как "песочницей" для запуска POC контейнеров, а не судорожно метаться в поисках подходящего функционала в облаке.

    Рынок Kubernetes раздроблен

    как минимум kubectl apply доступен у всех облачных провайдеров

    В Kubernetes слишком много частей

    из коробки идет минимум необходимого функционала. в результате отпадает необходимость постоянно тянуть в кластер базовые фичи.

    Kubernetes не гарантирует высокую доступность автоматически

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

    Управлять Kubernetes вручную сложно.

    прямая дорога к косякам в виде человеческого фактора. инфраструктура-как-код отлично подходит для автоматизации

    У Kubernetes есть проблемы с мониторингом и оптимизацией производительности

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

    Kubernetes всё сводит к коду

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

    Kubernetes хочет всё полностью контролировать

    странное утверждение. контейнеры кастомные, как настроишь - так и будут работать


    1. sundmoon Автор
      25.10.2021 21:51
      #23630014

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

      А разве скедулер куба сейчас этого не умеет? Не знал…
      Vmware DRS успешен полтора десятилетия.


      1. amarkevich
        03.11.2021 23:03
        #23665366

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


    1. sundmoon Автор
      25.10.2021 22:43
      #23630166

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


      Как вообще можно опровергнуть чьи-то оценочные суждения, при ценностном расхождении (т.е. разнице в аксиоматике) с их автором?
      Я старался предотвратить этот сценарий изначально, дав внизу ссылки на три "хардкорные" статьи.
      Не вышло...


      1. Casus
        27.10.2021 10:50
        #23635206
        +1

        Вам в недочеты указывают, при том бесплатно, а вы "фанбой-феномен" -ом оправдываете.

        У мнения - к8с сложно/дорого, есть право на жизнь в ограниченом количестве случаев, но вы же позиционируете мнение как общее утверждение.. а это не так.

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


        1. sundmoon Автор
          27.10.2021 19:28
          #23637362

          Вам в недочеты указывают

          Зачем мне — переводчику статьи — указывать её недочёты? Странная инициатива.
          Но раз уж вы взялись их указывать, и именно мне, почему удивляетесь "ответочке" — тому, что и я взялся оценивать вашу собственную позицию?


          Компьютерная наука относиться к естественным наукам

          Наука, может, и относится, фанбойство нет.
          Но я понимаю, что лично вы все свои "яйца" сложили в определённую "корзину"… к которой автор статьи отнёсся недостаточно бережно.
          Оттого не смогли пройти мимо столь болезненной для вас чьей-то в интернете неправоты.


          1. amarkevich
            03.11.2021 11:32
            #23662536

            переводчику статьи

            про перевод нигде не сказано

            фанбойство

            я делился личным опытом, полученым за весьма продолжительное время на различных реальных проектах.


            1. dimuska139
              03.11.2021 18:07
              #23664418

              Ну вообще сказано:


  1. lasc
    26.10.2021 05:46
    #23630600

    Сидим на ранчере уже как года 3, в целом очень даже неплохо, почти все можно делать через UI