Comments 11
С Kubernetes задачи DevOps значительно упрощаются:
И после этого простыня текста, кода/yaml, графиков как это "упростить"...
Вы уверены, что знаете значение слова "упрощение"?
Конечно знаю, по сравнению со всем остальным (ansible, bash, terraform) это точно упростить.
Непонятно, как кубер упрощает "по сравнению со всем остальным (ansible, bash, terraform)", если это два разных инструмента/-ов. Вы наверно хотели сравнить helm, но тут как в меме
А с каким инструментом задачи DevOps тогда упрощаются?
Меньше инструментов - проще
Меньше абстракций - проще
Построение таких платформ — это задача, которая в любом случае потребует большого количества абстракций и инструментов. И, кажется, тут вопрос в выборе самых удобных, безопасных и предсказуемых.
У каждого может свое мнение на этот счет, для наших задач был выбран инструмент, который закрывает наши потребности и не важно сколько в нем слоев абстракций. И это один инструмент, а не несколько.
Хотелось бы уточнить некоторые моменты.
Какие pv используете в kubernetes? Если сетевые, то как разруливаете iops. Если локальные, то как производите миграцию данных между нодами?
Оператор ставится на конкретный namespace и управляет только ресурсами одного namespace или ставится общий оператор на весь кластер и управляет кучей кафок.
Как решаете проблемы доступа и безопасности. Ведь при переводе баз данных в кубер, площадь атаки от этого не уменьшится, а скорее наоборот.
Как контроллируется автопереезд в случае необходимости обслуживания кубер ноды (а может все еще вручную) и как к этому подготовлены приложения?
На больших кластерах существуют проблемы и в какие объемы уперлись вы и как нагнули etcd - на каком уровне решили делать мультитенантные кластера и тп
Вы ведь крупная организация и знаете лучше меня про все тонкости и при этом не описали их в статье.
На данный момент это high-ops сетевые.
В общей namespace, но скорее всего придется этим управлять, потому что разные версии операторов обычно поддерживают разные версии приложений.
Безопасность достойна отдельной статьи и после review с стороны безопасников
Стараемся автоматически, но все индивидуально, если с кафкой можно заскалировать node group и перевести брокер, потом потушить старую ноду, то с тем же Postgres все так просто не получится.
На данный момент кластера не сильно большие и проблем нет, мультенант пока решается отсутствием коммуналки.
Конкретно эта статья не про тонкости, про них мы обязательно расскажем позднее.
С каких пор для интуитивно понятных инструментов - нужно целая огромная команда девопсов?
Интересно, если Вас наймут в компанию поменьше, сможете настроить интуитивно понятный инструмент, как куберенетес самостоятельно?)
Use case использования Kubernetes при построении Cloud-Native-платформы данных