Мб я криво описал задачу.. Допустим, у вас есть API на Cloud Endpoints/Gateway. Допустим, помимо основного сайта и админки, у вас есть какие-нибудь Wordpress плагины или cli утилиты типа той же gcloud (например, на сервере/VPS у вашего клиента) или что-то ещё, что должно взаимодействовать с этим API.

Гугловские аккаунты обычно есть у пользователей YouTube и GMail, но для своих рабочих задач эти люди могут не захотеть их подключать. Требовать регистрировать и подключать новый аккаунт Google для корректной работы API - это плохо выглядит с точки зрения PR/маркетинга, ещё это ужасно неэргономично. Кроме того, есть сложности с регистрацией нескольких аккаунтов Google на 1 номер телефона.

Теперь понял! Мы саас, но oauth у нас свой, так что не задумывался над этим

А что у вас? Keyclock/ory/gluu?..

Или прямо совсем свой типа такого https://docs.authlib.org/en/latest/django/2/openid-connect.html

https://docs.commercetools.com/api/authorization
Прям совсем свой, на scala

Народ, тыкните конкретной ссылкой как в GKE через meta.annotations для kind: Service , type: LoadBalancer задать чтобы healthcheck был HTTP ? а не TCP ?
для AWS это делается через

service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http

а как для GKE?

Там на балансере выбиралось раньше

я не понимаю что вы сказали что значит "выбиралось"?

у меня есть kubernetes  манифест  для GKE
как мне там прописать чтобы healthcheck пробы в сервисе делались правильно?

Хотя это для l7

это Kind: Ingress и это для L7

А для самого пода хелсчек http прописан?

нет в pods вообще healthcheck не прописан никакой ни readyness ни liveness

прописать можно. а это ТОЧНО поможет?

Вообще идея что эти хелсчеки связаны. Проще проверить

то есть какую проблему  я хочу решить
у меня в логах срется "client connection reset by peer"
я TCP dump проверил
это приходит коннект и рвется
ну и есть подозрение что это TCP пробы от loadbalancer
похожую проблему в AWS решили через

 apiVersion: v1
 kind: Service
 metadata:
   annotations:
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
     service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"
     service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "10"
     service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "2"
f385-4289-bd64-dab23ccf34bb
     service.beta.kubernetes.io/aws-load-balancer-type: nlb

но вот теперь надо такой же фокус повторить в GKE

ну проверить то проверю, но я надеялся тут люди с этим сталкивались

Всем привет, прошлой ночью ряд GKE кластеров с версии 1.15 сами проапгрейдились на 1.16 (только контролплейн). Релизным каналом не пользуемся, апгрейдим всегда вручную, поэтому автоапгрейд не должен был происходить. Пулы нод не апгрейдились. Кто-нибудь знает почему такое могло произойти?

Гугл ещё в октябре говорил, что все гке будут обновлены до 1.16, могу ссылку поискать

Ссылку можно не искать, достаточно того, что это ожидаемо, спасибо!