Коллеги, а ни у кого не было проблем с admission

webhook-ами в managed Kubernetes?

Разворачиваю новый кластер через terraform, до этого (последний где-то в ноябре-декабре 2021) уже разворачивал по тем же манифестам пару штук, все работало.

А сейчас сначала падало на "установке" ACME issuer-а через cert-manager (Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-mgr-cert-manager-webhook.gb-prod-balancer-cert-mgr.svc:443/mutate?timeout=10s": read tcp 198.18.0.59:44706->10.50.0.173:10250: read: connection reset by peer), погуглил, оказалось, что это у API-сервера (т.е. мастер-нод) нет доступа к webhook-сервису cert-manager-a...
Конкретно эту ошибку "обошел", включив hostNetwork для подов webhook (еще пробовал поды на мастеры "засунуть", но т.к. не знаю, какие там taint-ы и label-ы, то не получилось узнать - сработало бы или нет).

Теперь столкнулся с почти той же ошибкой (failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-infra-controller-admission.gb-prod-balancer-infra.svc:443/networking/v1/ingresses?timeout=10s": context deadline exceeded), только уже у nginx-ingress 😞 Пытаюсь и его в hostNetwork перевести... но вдруг кто-то уже сталкивался и знает, как решить 😊
Может каких-то правил не хватает в группе безопасности кубера. Группы настроил по этой инструкции

kube-apiserver находится в НЕ кластера. Соотвесвтенно он должен иметь возможность обращаться в под ingress-controller'а для хука валидации. Вам нужно разрешить из подсети для мастеров разрешить ходить в подсети ворклоада куба. Тоже самое в network policy куба (если они есть)

например у меня мастера работают в подсетях 10.128.0.0/24, 10.129.0.0/24, 10.130.0.0/24 соотвественно у меня в netpol куба для ingress-controller есть политика разрешающая ходить в под ingress-controller'а из этиъ подсетей - ipBlock: cidr: 10.128.0.0/24 - ipBlock: cidr: 10.129.0.0/24 - ipBlock: cidr: 10.130.0.0/24

Ivan 😸
кажется, я нашел нужную подсеть мастеров... 198.18...

А у вас не Cilium случаем? Похоже на его внутренние адреса.

он, да + Kubernetes 1.21

механика вебхука у куба такая Ты аплаешь какой-то объект (например kubectl apply -f yamlFile) Если для такого объекта есть вебхук, (mutatingwebhookconfigurations, validatingwebhookconfigurations) То kube-apiserver должен пойти в сервис указанный в mutatingwebhookconfigurations/validatingwebhookconfigurations) в зависимости от того какой это тип вебхука, будут выполнены некоторые вещи kube-apiserver'ом. Но важно то, что kube-apiserver должен нормально дотучаться до сервиса, по TLS (то есть сертифкаты тоже должгы быть в норме)

Ivan 😸
кажется, я нашел нужную подсеть мастеров... 198.18...

в доку принимаются PR. Милости прошу. Мне вот лень было это сделать, а вообще о таком полезко написать. Согласен Вот если бы я в свое время написал, вы бы это нашли в доках

это да, я добавлю решение, когда "доковыряю" проблему 😊

Ivan 😸
кажется, я нашел нужную подсеть мастеров... 198.18...

подсети мастеров указываются при их настройке бутстрапе. Там можно выбрать VPC нужную вам

Ivan 😸
кажется, я нашел нужную подсеть мастеров... 198.18...

Вообще странно что вы юзаете подсеть 198.18.0.0/24 По RFC эта подсеть - Used for benchmark testing of inter-network communications between two separate subnets То есть для обычных нужд это лучше не юзать. Есть же 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, как раз для целей локальной коммуникации

подсети cilium'у настраиваешь сам. Или в яндексе такие дефолты? Я cilium в managed кластере не пробовал. Но очень странный дефолт

хм... это где именно? я указываю только CIDRы для pod-ов и сервисов... ну и назначаю подсети для кластера примерно так: master { dynamic "regional" { for_each = var.k8s_region != "" ? [var.k8s_region] : [] content { region = regional.value dynamic "location" { for_each = var.k8s_master_subnets content { zone = location.value.zone subnet_id = location.value.id } } } } network_implementation { cilium {} } cluster_ipv4_range = var.k8s_cluster_ipv4_range service_ipv4_range = var.k8s_service_ipv4_range node_ipv4_cidr_mask_size = var.k8s_node_ipv4_cidr_mask_size

видимо какие-то особенности настройки cilium'а в managed кубе яндекса. Понял. Извините

эту сеть не я указываю... я вообще сам не в курсе, откуда она 🤷‍♂️ у меня для подов и сервисов "дефолтные" 10.112.0.0 и 10.96.0.0

я вас понял

вы же знаете что cilium в яндексе overlay использует? Тобишь geneve/vxlan? То есть в яндексе получается cilium overlay поверх overlay сети яндекса У них почему-то в managed кубе нельзя cilium с native routing поднять

это есть в планах, но не все сразу) туннельный цилиум был сделан первым потому что он позволяет обойти ограничение на макс. число подов в кластере которое мы получаем от макс. размера подсетей в облачном vpc (/16)