помимо OCP где еще это будет?

podman в OCP только в новом инсталлере используется, остальное - статик поды на rio

@StanislavKhalup создал StorageClass kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer Добавил класс в pvc для statefulSet volumeClaimTemplates: - metadata: name: datadir spec: storageClassName: local-storage accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi Но всё равно статус pending, не работает 😫

Кто-то менял время хранения ивентов, которое по умолчанию час? Похоже что в kube-apiserver надо устанавливать --event-ttl желаемое, но как это нормально можно сделать?

пробовал

Всем привет! Кто нибудь уже пользовался kong-ingress-controller ?

#prometheus подскажите, а в этом prometheus-operator, там никак нельзя в ServiceMonitor указать сервис по имени, а не через label selector? Service discovery конечно хорошо, но блин..

всем привет. кто-нибудь юзает gluster с k8s? как ощущения? выходит же сложная система с гластером и Heketi?

https://github.com/projectcalico/calico/issues/2334

а на 1.13 та же проблема?

отлаживать пробовали, там в чем загвоздка? маскарадинг из бриджа в dind не работает?

мне прост кажется что тут понять почему именно трафик не идет вполне в ваших силах

как таковой проблемы с прохождением траффика не было замечено. К примеру сборка затыкалась на Collecting pipenv==2018.7.1 Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='pypi.org', port=443). Но, если зайти в контейнер с раннером, и руками скачать этот пакет - все нормально. Хосты резолвятся, пакеты качаются

Очень похоже на неправильный MTU

Хотяяяя, я как до 3.3.1 обновил с тех пор dind поды не перезапускал :)

Вобщем, пока не уснул план такой, как посплю может пойму что хуйню сморозил: - на нодах для кублетов и kube-proxy сделать нормальный L7 балансер до аписервер - развешивать финалайзеры на всех endpoints, удалять их только когда нода выходит из NotReady или ее удаляют , это сохранит записи в ингресе. Сам ингресс хелсчекит поды и подвешенные записи не будут мешать, если под жив на самом деле - "зависшие" из-за финалайзера ендпоинты будут мешать общаться внутри кластера, надо L7 балансер внутри подов сайдкаром (но без istio, кажется были менее инвазивные штуковины на енвое)

Проблема вкратце: если все кублеты не могут говорить с аписервером то весь кластер накрывается жопой. Можете сами попробовать, остановите все кублеты :) контейнеры запущены, сеть работает, но куб контроллерам неймётся и они все разваливают из-за статуса NotReady ноды. Решение вкратце: publishNotReadyAddresses: true на всех-всех сервисах, тогда на ендпоинты останутся "здоровыми" и ни ingress контроллер ни kube-proxy их не выпилит. Побочные эффекты: по-настоящему "notReady" поды станут всем видны. Решение: хелсчеки ендпоинтов с клиентской стороны , это значит L3/L7 балансер сайдкаром во всех подах и скорее всего envoy на ingress

Ребята дилетантский вопрос про мониторинг (только осваиваю прометеус). Есть деплоймент, с ни же сервис. Есть ендпоинт до метрик куда ходит пром. Тут все ясно. Что делать прому когда подов больше одного? Метрики у каждого свои, значит он должен понимать количество подов? Или там иначе все?

аннотацию вещай не на сервис, а на поды

не понятно. аннотация в деплойменте?

для какой ситуации ты рассматривает эту тему с лежащими kubelet?

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

Всем привет. Подскажите, пожалуйста, где можно почитать о "бест-практис" разворачивания кубо-кластера? Сколько мастер-нод для скольких воркеров, какие тачки по конфигу лучше использовать и вот это вот всё.

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

Ты можешь выкрутить таймауты определения ноды недоступной в небеса, только если реально нода упадет то поды мертвые придется как то выпиливать

На ингресе это можно частично настроить проверкой живости апстримов. А вот внутрикластерное взаимодействие хрен знает как

Через envoy сайдкаром похоже

Кстати, а какой ingress-controller у вас?

Хочу что б кластер все равно старался самовылечиться , так что задирать нотреди таймауты не хочется

Говноnginx

А у nginx-ingress-controller есть параметр, сколько ждать если apiserver не доступен, прежде чем выпиливать endpoint-ы

Сделай авторизацию по статическим токенам и не парся про сертификаты

У меня проблема была в том, что аписервер как раз был доступен :) а вот если недоступен я б ожидал что б он не дёргался и ничего не делал, nginx правда после таймаута просто самовыпиливается?

Мощно повысим секьюрити вдобавок, ага

Да. Причём я натыкался на то, что выпиливался примерно сразу. Недоступен один из аписерверов -> ingress-controller ходит в него по внутреннему адресу (session affinity, да) -> ingress-controller обнуляет все endpoint-ы

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

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

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

Умершие приложения != умершая нода