Если уж такой вариант выбирать, то не лучше ли запускать отдельные поды с nginx-proxy , которые и будут проксировать на кубернетисовские сервисы, чтобы при изменении параметров/роутов в таких nignx-proxy-подах,которые мапятся как,например, ConfigMap, достаточно было сделать бесшовное обновление этих stateless-подов, а не передеплоивать поды с приложением, где сайдкаром установлены эти nginx-proxy?
client->cloudflare->ingress-nginx->nginx-proxy->service1|service2

Но это практически дублирование функцонала nginx-ingress, хотелось бы или на нем реализовать или на регулярках

coredns по умолчанию берет список вышестоящих ДНС серверов из файла /etc/resolv.conf с хостовой тачки, у тебя на хостовой тачке поднят systemd-resolver, который меняет днс-сервера на 127.0.0.1 и походу у тебя получается loop.
Вот здесь это хорошо расписано + написано как решить проблему.
https://github.com/coredns/coredns/blob/master/plugin/loop/README.md#troubleshooting-loops-in-kubernetes-clusters

livenessProbe можно чекать ping.path (настройка пула fpm)
redinessProbe - на стороне приложеньки

nginx-ingress controller имеет существенный плюс - он в апстримы добавляет ip адреса pod'ов.

Дима, ну через
pathType: Exact
pathType: Prefix

теоретически можно реализовать мой кейс?
Если да, то это будет выглядеть примерно по структуре и по количеству правил, как в классическом nginx по типу того,что я привел на pastebin?

я новым API ingress не пользовался 🤷🏻‍♂️

Я тоже

И воообще ингрес нафиг

У каждого продвинутого ингресс свои ресурсы - тот же контур обсуждали сегодня

Спасибо. Попробую

Складываем 2+2 в хелс.пхп и дрыкаем этот файл через

 SCRIPT_NAME=/app/healthz.php \
 SCRIPT_FILENAME=/app/healthz.php \
 QUERY_STRING= \
 REQUEST_METHOD=GET \
 cgi-fcgi -bind -connect /var/run/php-fpm.sock

Народ хотите тупой вопрос? Как удалить второй по счету под из стейтфулсета с десяткой реплик и чтобы он на эту ноду не приехал после рестарта? У меня в голове это кордон, скейл до 0, толерейшн с маркером и потом скейл до нужного количества

Есть варианты изящнее?

а есть ли тулза, которая может просканивать кластер на наличие ресурсов с устаревшими API https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/ ? О то хочется кластер обновить, и не хочется руками все ресурсы проверять

есть

оно! спасибо!

если объекты смотреть, то может оказаться, что создавал ты объект новее версии, а отображается через api в другой

почему просто не кордон + убить второй по счёту под руками?

не знал, буду иметь в виду. хорошо что хоть хелм умеет сканировать