Ну тут беда в том, что это пушка по воробьям в 99% кейсах :(
И имеет свои side эффекты.
В общем я понял, проблема в том, что мы видимо недостаточно четко обрисовали круг применения описанного способа...

»Чисел у меня нет, но если вы будете мерять было б интересно увидеть результат - десяток неймспейсов, два параллельных деплоя на 10 подов скажем, в фоне постоянно крешится ещё десяток подов в цикле там (можно имитировать просто вручную меняя список фиктивных endpoints скриптом)

Да! Звучит как интересная тема для статьи. Спасибо за мысль.

Есть вот такой конфиг. Как прописать правила rewrite path только для одного ендпойнта? Это вообще возможно?

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 annotations:
   kubernetes.io/ingress.class: nginx
   nginx.ingress.kubernetes.io/ssl-redirect: "true"
   nginx.ingress.kubernetes.io/rewrite-target: /$2
 name: ingress  
spec:
 tls:
   - hosts:
       - example.com
     secretName: example-tls
 rules:
   - host: example.com
     http:
       paths:
         - path: /
           backend:
             serviceName: example-site
             servicePort: 80
         - path: /app(/|$)(.*)
           backend:
             serviceName: example-app
             servicePort: 80
         - path: /api
           backend:
             serviceName: example-api
             servicePort: 80

А при чем тут kube-proxy?
Вы же знаете, что ингресс не использует сервисы и kube-proxy? А работает напрямую по л2.
Ингресс подписывается на события и получает обновленный список ep почти мгновенно

а это смотря какой ингресс. контроллер то он разный бывает. гугловый облачный например может через nodeport ходить или напрямую к подам...

Тут главное количество событий. На практике это значит чем больше команд работает с одним кластером тем больше будут задержки. kube-proxy переконфигурирует iptables, он висит на локе от calico и не может убрать правило. Пока он висит набегают изменения в других ендпоинтах, встают в очередь и ждут. Чисел у меня нет, но если вы будете мерять было б интересно увидеть результат - десяток неймспейсов, два параллельных деплоя на 10 подов скажем, в фоне постоянно крешится ещё десяток подов в цикле там (можно имитировать просто вручную меняя список фиктивных endpoints скриптом)

Заранее извиняюсь: поднимая кластр кубадмином, юзая cli - можно юзать табы и за тебя дописывает там нс или имя пода... подняв кластр юзая рке - табы мимо. Почему? Шо такэ?

А если нет ингресса, то еще более предпочтительно юзать преСтоп. Проверено на продакшен кластере, 150 подов. Запускаем апдейт деплоймента с 30 подами, поды убиваются мгновенно, но из сервисов эндпоинты уходят не сразу > получаем пятисотки.

Вы замеряли это "не сразу" ? У меня вот руки не дошли

А если нет ингресса, то еще более предпочтительно юзать преСтоп. Проверено на продакшен кластере, 150 подов. Запускаем апдейт деплоймента с 30 подами, поды убиваются мгновенно, но из сервисов эндпоинты уходят не сразу > получаем пятисотки.

А кто может подсказать - нет ли оператора, который бы помог обновлять конфиги.
Что я хочу решить: на виртуалке я правил конфиг, потом делал service reload и мой сервис без рестарта применял конфиг
В кубере - я деплою ConfigMap и по аннотации мой под рестартуется.
Вопрос - как бы "красиво" по обновлению CM обновлять файлы и релоадить приложение, а не пересоздавать под.
P.S> текущее приложение на java, но в идеале хотелось бы универсального решения.

первый как я понимаю дёргает веб-хук
второй - делает rolling update
а нужен именно релоад, например, kill -HUP 1

типа serverless штука. ты деплоишь деплоймент, он создает тебе поды в fargate (там микровиртуалка firecracker) с запрошенными ресурсами. Таким образом ты фактически избавляешься от понятия нод

это в общем тривиально делается - https://github.com/vrutkovs/re-currant/blob/master/reload.go - поду нужно только shareProcessNamespace: true

аргументы сторон:
за:
- так делает копс
- если мы объединимся с компанией, где используется 192.168.*, будут проблемы
против:
- непонятно, этот диапазон 100.64 роутится наружу или все-таки нет (по RFC не должен). Если роутится, то использовать его не хочется
- если что, сменить недолго
- зачем менять то, что уже работает