Какие есть нормальные экспортеры для куба?

господа, кто юзал nats-operator? сделал по доке, задеплоился успешно порт по дефолту по доке 8080 дополнительно создал для него сертификат от LE + ingress + service почему когда я перехожу по домену, то получаю 404 ошибку? техлид пробовал подключиться через тестовый скрипт из офиса, пишет что не может подключиться удаленно(connection refused) что я упускаю?(

драсте) нужен совет от мудрецов чата есть задача на кластере развернуть: 1) namespace+ set of CRD's 2) wait until all created 3) run shellscript using above metadata 4)catch any error 5) finally delete all CRD --------------- возможно ли это провернуть через kubernetes jobs? или нужна какая то дополнительная обертка, чтобы потом протащить это в jobs? или вообще нет смысла такое пилить ? если так, то какие kube-native средства могут подойти? p.s. jenkins и тд не предлагать, это и сами умеем)

bash, kubectl apply и kubectl delete?

Мучаюсь тутс с node-exporter поставил его и prom в кластер. Вроде б все ок. Но, пром не собирает данные когда прописываю анотации Annotations: prometheus.io/port: 9100 prometheus.io/scrape: true А когда в prom config руками добавляю вот такое: scrape_configs: - job_name: nodes static_configs: - targets: - prometheus-node-exporter:9100` начинает собирать, но смешивает в кучу с трех экспортеров данные как жить

Да там один инстанс кажется когда через сервис

Похоже вот тут вся магия https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/prometheus/prometheus-configmap.yaml

Но у меня она тоже есть

Скорее я аннтоации как то не так пишу чем чарт сломанный

он в том же namespace что и всё остальное

А кто как решает задачу автоматического удаления ресурсов кубера после удаления ветки в репе? Настроил так, чтобы для каждого бранча просиходил деплой ресурсов в кубер, где в имя ресурса добавляется имя втеки. Оно вроде как удобно, но со временем в кубере очень много деплойментов, сервисов, инргесов и т.д. И вот думаю что с ними делать, и интересно кто как решает такую проблему. Думал банально ловить хуки с репозитория и запускать задачу на удаление. Сейчас это сделано у меня через Jenkins (multi branch pipeline), может он умеет понимать когда бранч удалился и запускать в соответствии с этим действие?

привет! вопрос к пользователям EKS: если деплоить кластер через CF стек, то только юзер, через которого производился деплой будет иметь доступ в кластер через kubectl? можно ли это изменить? деплоить кластер через IAM роль и все равно иметь доступ в кластер?

Всем привет! Поднимаю ElasticSearch внутри кластеров, софтина требует поднять ulimit'ы. Как это правильно сделать: увеличить лимиты в хост-системе или внутри контейнера?

на нодах подними sysctl -w vm.max_map_count=262144

на нодах подними sysctl -w vm.max_map_count=262144

А не правильнее ли делать это через init контейнеры?

А не правильнее ли делать это через init контейнеры?

Добрый день! Может быть может кто поделиться своим опытом в развертке сложного кластера K8S в корпоративном сегменте без облаков. Кейс состоит в том, что уже есть 3 изолированных сети (ищолированы они логически) Dev, Test, Prod. Внутри каждого необходимо развернуть отказоустойчивый кластер с 3 мастер нодами и условно не ограниченным колличеством slave нод. При этом хотелось бы иметь одну точку входа и в ней развернуть Pipeline. При этом каждый отказоустойчивой кластер должен восприниматься как единое облак с логичеким дроблением на те же stage для развертки (Dev, Test, Prod) и соответсвовать уже имеющейся изолированной сети

Три сети, три кластера. В четвёртой pipeline, в нем переключай контексты . Не вижу проблемы

Всем привет! Поднимаю ElasticSearch внутри кластеров, софтина требует поднять ulimit'ы. Как это правильно сделать: увеличить лимиты в хост-системе или внутри контейнера?

вообще-вообще правильно поставить на ноды tuned оператор и рулить ими через CRD

Это религиозно-правильный путь Kubernetes?

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

Pipeline будет выступать клиентом для кластеров в этом случае. Установи kubectl смерджи три конфига и переключай контексты kubectl —context=prod

То есть я правильно понимаю, я ставлю на кластер Pipeline Kubectl и через него добавляю остальные 3 кластера. У меня есть небольше сомнения по поводу того, что внутри каждого кластера будет по 3 мастера и также в кластере pipeline, правильно-ли это?

Пайплайн не обезательно ставить в кластер, просто на виктуалках в четвертой сети. Если нужен HA кластера, то минимум по 3 мастера. Вопрос нужно ли тебе это в dev и тест

Необходимо спроектировать сразу с учетом HA каждый отдельный кластер. Спасибо большое за ваш ответ, попробую сделать в 2 этапа с HA только в Prod, остальные с одним, а после уже все на HA перевести. Может ещё подскажите что лучше использовать из сетей для данного кейса, до этого в Kubernetes использовал только Calico, и по поводу распределенного файлового хранилища, активно использую GlusterFS, но с ним пару раз были серьёзные проблемы

Вам не нужен кубернетес

Ребят, кто-нибудь уже научился жить с одним мастером (+1etcd) на бареметал в проде? Хочется кластер подешевле, и есть мысль - остальные 2 Etcd инстанса крутить на воркер нодах, мастер же держать в виртуалке и её бэкапить/снапшотить. Отвалился контрол плейн - заресторили. Такое облако для бедных)

снапшотить всю VM наверное лишнее, достаточно etcd снапшота

Гайс, такая таска. Нужно сделать mount директории определённого размера. (Просто mount внутри контейнера), однако напрямую из контейнера "mount /dir_file /dir" сделать нельзя. Пытаюсь средствами yaml реализовать это на уровне кубера volumeMounts: - mountPath: /opt/little_storage name: test-volume volumes: - name: test-volume emptyDir: {} Директория по итогу создается, но она не подхватывается как mount и не имеет ограничения на размер, есть идеи?

Если выставить medium в Memory

type medium стоит. sizeLimit это синтаксис Pod'а или самого Volume ?

emptyDir: medium: "Memory" sizeLimit: 1Gi

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

Вроде обновятся