1. Но все же Kubernetes может управлять Windows-контейнерами на Windows-нодах и поддерживает при этом интеграцию с фичами AD. Что из себя при этом представляют мастера, не принципиально для данной задачи.
2. Теоретически да, но задача весьма не тривиальная. А в Nomad эта возможность встроена по умолчанию.
Нет, в этом случае использование NFS не будет ошибкой. В любом случае нужно исходить из требований бизнеса. Другой вопрос: бизнес может устраивать недоступность файлов в течение суток, но устроит ли его потеря файлов?
Тогда все равно нужно делать бэкапы файлов, выделять под это дополнительные серверы, писать проверки консистентности данных.
И хранение файлов не единственный кейс для СХД в Kubernetes. Например, вам нужно будет развернуть систему мониторинга. Ей нужно хранить данные.
Что делают в маленьких проектах на self-hosted Kubernetes? Прибивают Prometheus к одной ноде, на которой он и хранит данные. Если нода выйдет из строя, кластер останется без мониторинга. Prometheus не сможет переехать на другую ноду, так как его данные никак не шарятся по кластеру. Или сможет, но с потерей данных.
Можно, конечно, вынести мониторинг из кластера на отдельные серверы, но, во-первых, это как раз ведет к увеличению необходимых затрат на инфраструктуру, во-вторых, все также ведет к недоступности мониторинга в случае выхода из строя сервера.
Критично ли это? Если не принципиально наличие мониторинга 100% времени, то нет, можно действительно жить так. Но для большинства крупных проектов это будет недопустимо
Так же как и утилита kompose: kompose.io. Но, скорее всего, их можно использовать только как временное решение или способ быстро перегнать манифесты из одного формата в другой. В последствии все равно придется допиливать кубовые манифесты руками, так как docker-compose все-таки имеет сильно отличающуюся логику работы от Kubernetes.
Придется доделать метки, аннотации, указать дополнительные параметры безопасности на подах, создать дополнительные абстракции (Network Policies, PDB и тд).
Безопасность Kubernetes — это не только секреты. Это еще и управление правами (RBAC), системы авторизации и аутентификации в кластере, политики контроля возможностей подов (PSP), сетевые политики и так далее.
Если говорить про секреты, то — да, они хранятся в закодированном виде, но разграничение прав на секреты решается с помощью прав доступа, а не шифрования.
Kubernetes сложно установить и настроить по сравнению с другими оркестраторами, это отражено в статье.
По поводу необходимости обращаться к облачным провайдерам для разворачивания Kubernetes — это нельзя назвать необходимостью, Kubernetes многие используют как самостоятельный продукт. По поводу несовместимости при миграции — например, наш KaaS сертифицирован CNCF и полностью совместим со всеми другими CNCF-сертифицированными облаками или установщиками, такими как kubeadm, kubespray и kops.
Что касается Nomad — да, действительно Vault, так же, как Consul, Consul Template и ряд других продуктов, фактически являются компонентами одного стека компании Hashicorp. Но если говорить конкретно о секретах, то у Kubernetes это реализовано из коробки и не требует дополнительных настроек или компонентов. То что секреты хранятся в закодированном, а не зашифрованном виде, в Kubernetes решается через разграничение прав. И также не требует дополнительных компонентов.
Отсутствием привязки к AWS, большим опенсорсным комьюнити и, как следствие, большим количеством всевозможных дополнительных компонентов. Кроме того, K8s реализует паттерн замкнутого контура управления (ЗКУ). Это позволяет приводить ваше приложение к целевому состоянию, пускай даже на это уйдет несколько дней. В случае с Terraform вы ограничены клиент-серверным взаимодействием и небольшим количеством попыток установить целевое состояние для ресурса
Остался за рамками этой статьи, все рассмотреть невозможно. И все-таки инженеры, склоняющиеся в пользу использования Rancher, чаще используют >2.0 версии.
Согласен. И все же я бы сказал, что в среднем при работе с Javа чаще приходится обращаться к настройкам самой Java-машины, лучше понимать внутреннюю структуру работы языка. С Golang в этом плане проще. Хотя, несомненно, и у него есть свои нюансы. И так уж случилось, что в современном мире инженеры эксплуатации чаще знакомы и работают с Golang, чем с Java.
В рамках статьи я говорю об ошибках уровня Pro, то есть на проектах, где для выполнения SLA надо выстраивать отказоустойчивые кластерные системы на всех уровнях: начиная от гипервизоров и оркестраторов, заканчивая СХД, системами мониторинга и логирования. И простые решения там просто перестают работать.
Ceph — кластерная система хранения данных, использование ее в рамках одного хоста вряд ли принесёт какой то профит. Вся суть достижения отказоустойчивости — использование нескольких независимых серверов для резервирования данных.
В рамках одного хоста NFS, вероятно, будет лучшим решением по соотношению сложности развертывания / поддержки и работоспособности.
Например, CephFS, так как это распределенная система хранения и хранить (и отдавать) данные она может распределенно на нескольких хостах, что повышает скорость доступа к данным.
Т.к. мы делаем высокотехнологичный продукт, целевой аудиторией которого являются разработчики, DevOps и SRE, то они сами могут генерировать много идей на тему того какие функции будут востребованы, а какие нет. Кроме того, ребята проводят самостоятельные исследования о типовых паттернах приготовления новых технологий во всем Mail.ru Group, а не только MCS.
Конечно, невозможно оставить разработчиков наедине с продуктом, т.к. здесь может возникнуть перекос в техническую сторону. Поэтому происходит работа в паре с продуктовым менеджером. Достаточно часто доля вклада разработчиков в продукт превышает 40% — 50%.
Мы измеряем степень вовлечения по тому насколько активно конкретный человек участвует в развитии продукта, предлагая новые идеи и решения проактивно, а также насколько он готов нести ответственность за результат, особенно когда возникают проблемы.
Т.к. мы делаем высокотехнологичный продукт, целевой аудиторией которого являются разработчики, DevOps и SRE, то они сами могут генерировать много идей на тему того какие функции будут востребованы, а какие нет. Кроме того, ребята проводят самостоятельные исследования о типовых паттернах приготовления новых технологий во всем Mail.ru Group, а не только MCS.
Конечно, невозможно оставить разработчиков наедине с продуктом, т.к. здесь может возникнуть перекос в техническую сторону. Поэтому происходит работа в паре с продуктовым менеджером. Достаточно часто доля вклада разработчиков в продукт превышает 40% — 50%.
Мы измеряем степень вовлечения по тому насколько активно конкретный человек участвует в развитии продукта, предлагая новые идеи и решения проактивно, а также насколько он готов нести ответственность за результат, особенно когда возникают проблемы.
У нас собственный оркестратор, прототип которого взяли в OpenStack Magnum, но уже полностью переделали. Выбор пал на собственное решение, т.к. нам необходим полный контроль на каждом этапе работы с кластером.
Мы движемся в сторону полностью Managed-решения, а это накладывает определенные ограничения на возможности пользователей в обмен на 100% доступность сервиса. Кастомизация будет за счет механизма сертифицированных аддонов (тех, которые мы тестируем и гарантируем работу). Наиболее типовые кейсы кастомизации (мониторинг, логирование, cert manager) будут запакованы в аддоны.
2. Теоретически да, но задача весьма не тривиальная. А в Nomad эта возможность встроена по умолчанию.
Тогда все равно нужно делать бэкапы файлов, выделять под это дополнительные серверы, писать проверки консистентности данных.
И хранение файлов не единственный кейс для СХД в Kubernetes. Например, вам нужно будет развернуть систему мониторинга. Ей нужно хранить данные.
Что делают в маленьких проектах на self-hosted Kubernetes? Прибивают Prometheus к одной ноде, на которой он и хранит данные. Если нода выйдет из строя, кластер останется без мониторинга. Prometheus не сможет переехать на другую ноду, так как его данные никак не шарятся по кластеру. Или сможет, но с потерей данных.
Можно, конечно, вынести мониторинг из кластера на отдельные серверы, но, во-первых, это как раз ведет к увеличению необходимых затрат на инфраструктуру, во-вторых, все также ведет к недоступности мониторинга в случае выхода из строя сервера.
Критично ли это? Если не принципиально наличие мониторинга 100% времени, то нет, можно действительно жить так. Но для большинства крупных проектов это будет недопустимо
Придется доделать метки, аннотации, указать дополнительные параметры безопасности на подах, создать дополнительные абстракции (Network Policies, PDB и тд).
Если говорить про секреты, то — да, они хранятся в закодированном виде, но разграничение прав на секреты решается с помощью прав доступа, а не шифрования.
Kubernetes сложно установить и настроить по сравнению с другими оркестраторами, это отражено в статье.
Что касается Nomad — да, действительно Vault, так же, как Consul, Consul Template и ряд других продуктов, фактически являются компонентами одного стека компании Hashicorp. Но если говорить конкретно о секретах, то у Kubernetes это реализовано из коробки и не требует дополнительных настроек или компонентов. То что секреты хранятся в закодированном, а не зашифрованном виде, в Kubernetes решается через разграничение прав. И также не требует дополнительных компонентов.
В рамках одного хоста NFS, вероятно, будет лучшим решением по соотношению сложности развертывания / поддержки и работоспособности.
Конечно, невозможно оставить разработчиков наедине с продуктом, т.к. здесь может возникнуть перекос в техническую сторону. Поэтому происходит работа в паре с продуктовым менеджером. Достаточно часто доля вклада разработчиков в продукт превышает 40% — 50%.
Мы измеряем степень вовлечения по тому насколько активно конкретный человек участвует в развитии продукта, предлагая новые идеи и решения проактивно, а также насколько он готов нести ответственность за результат, особенно когда возникают проблемы.
Конечно, невозможно оставить разработчиков наедине с продуктом, т.к. здесь может возникнуть перекос в техническую сторону. Поэтому происходит работа в паре с продуктовым менеджером. Достаточно часто доля вклада разработчиков в продукт превышает 40% — 50%.
Мы измеряем степень вовлечения по тому насколько активно конкретный человек участвует в развитии продукта, предлагая новые идеи и решения проактивно, а также насколько он готов нести ответственность за результат, особенно когда возникают проблемы.