Пока поделиться особо нечем. Прода с istio в данный момент нет.
Мы планируем катнуть возможность использования Istio в 70+ кластеров до конца месяца и где-то в апреле/мае у нас будет первый реальный продакшен опыт на реальных кейсах.
Мы обязательно поделимся полученным опытом, так как будет большое количество различных кейсов на различных нагрузках и конфигурациях.
Общие пулы могут быть под конкретные задачи и это нормально. Общий пул не значит, что он под абсолютно все задачи. Нам не имеет смысла гонять простые приложения, на GPU нодах — верно?
С одной стороны да, маленькие отдельные кластера под задачи — это удобно. с полной изоляцией, но с другой стороны приводит к лишней работе. Тут нужно иметь некий баланс адекватности и необходимости.
У нас есть и те и другие варианты в обслуживании.
И пары аннотаций: ingress.kubernetes.io/auth-signin: https://$host/oauth2/sign_in
ingress.kubernetes.io/auth-url: http://dashboard-oauth2-proxy.kube-system.svc.cluster.local:4180/oauth2/auth
Если интересно, то можем рассказать в следующей статье более подробно о данном кейсе.
Чаще всего хватает доступов к Kubernetes Dashboard с авторизацией в gitlab.
Иногда даем доступ с помощью kubectl (конфиг подключения) с юзером, которому доступны только те действия, что определили с помощью RBAC.
Нод в кластере может быть и более 50, такое количество подов rabbitmq никому не нужен, а с daemonset придется городить лейблы, селекторы. Поэтому statefulset хорошо подходит под данный кейс.
Практика показала, что эти readiness/liveness Probe очень плохие, так как всегда возвращают exit code = 0 и может таймаутить без причины.
Пока пришли к таким пробам:
На самом деле ничего не мешает :) Как ничего не мешает, и обойтись без инит контейнеров.
Просто тут каждый контейнер выполняет свою отдельную функцию, мы можем смотреть логи отдельных контейнеров, выделять ресурсы на отдельные стадии (CPU, RAM).
Как таковых «минимальных» требований нет. Те лимиты, которые мы считаем минимальными (requests) описаны в value, но это не значит, что оно будет потреблять именно столько ресурсов, все зависит от количества логов.
Добрый день…
Спасибо большое за интерес к нашему проекту и мы очень рады, что есть люди, которые испытывают те же потребности, что и мы.
Это все баги, связанные с тем, что это PoC. Мы будем очень рады, если вы пришлете PR или создадите Issue по любым улучшениям или вопросам.
В данный момент loghouse не обработает миллион строчек логов в секунду.
В таком случае мы получим дикую нагрузку на диск, так как лог пишется в логи, а после чего fluentd их пишет в clickhouse. Сколько эти логи занимают места — столько они и будут занимать.
Зависит от того, сколько эти логи занимают пространства.
Мы протестировали несколько вариантов, но они оказалось либо очень ресурсоемкими (как CPU, RAM так и дисковое пространство), либо крайне не удобными и не соответствовали нашим требованиям.
Elasticsearch оказался слишком «толстым».
Пока нет, но думаем об этом.
Там нужны минимальные правки для того чтобы оно стало рабочим (поменять datasource, исправить interval_rv на interval, возможно что-то еще)
Пока поделиться особо нечем. Прода с istio в данный момент нет.
Мы планируем катнуть возможность использования Istio в 70+ кластеров до конца месяца и где-то в апреле/мае у нас будет первый реальный продакшен опыт на реальных кейсах.
Мы обязательно поделимся полученным опытом, так как будет большое количество различных кейсов на различных нагрузках и конфигурациях.
С одной стороны да, маленькие отдельные кластера под задачи — это удобно. с полной изоляцией, но с другой стороны приводит к лишней работе. Тут нужно иметь некий баланс адекватности и необходимости.
У нас есть и те и другие варианты в обслуживании.
И пары аннотаций:
ingress.kubernetes.io/auth-signin: https://$host/oauth2/sign_in
ingress.kubernetes.io/auth-url: http://dashboard-oauth2-proxy.kube-system.svc.cluster.local:4180/oauth2/auth
Если интересно, то можем рассказать в следующей статье более подробно о данном кейсе.
Иногда даем доступ с помощью kubectl (конфиг подключения) с юзером, которому доступны только те действия, что определили с помощью RBAC.
Нод в кластере может быть и более 50, такое количество подов rabbitmq никому не нужен, а с daemonset придется городить лейблы, селекторы. Поэтому statefulset хорошо подходит под данный кейс.
Пока пришли к таким пробам:
Конечно, стоит не забывать и про rabbitmq exporter.
Просто тут каждый контейнер выполняет свою отдельную функцию, мы можем смотреть логи отдельных контейнеров, выделять ресурсы на отдельные стадии (CPU, RAM).
Спасибо большое за интерес к нашему проекту и мы очень рады, что есть люди, которые испытывают те же потребности, что и мы.
Это все баги, связанные с тем, что это PoC. Мы будем очень рады, если вы пришлете PR или создадите Issue по любым улучшениям или вопросам.
В таком случае мы получим дикую нагрузку на диск, так как лог пишется в логи, а после чего fluentd их пишет в clickhouse. Сколько эти логи занимают места — столько они и будут занимать.
Зависит от того, сколько эти логи занимают пространства.
Elasticsearch оказался слишком «толстым».