«журналы kubectl» не работают после добавления шлюзов NAT в GCE

Question

Я следовал инструкциям в разделе «Создание шлюзов NAT с высокой пропускной способностью и высокой пропускной способностью» в https://cloud.google.com/vpc/docs/special-configurations,, и после того, как я пометил все экземпляры «no-ip», я больше не могполучить доступ к журналам pod, используя "kubectl logs".

Это потому что kubectl logs под капотом с помощью ssh?Есть ли обходной путь, чтобы увидеть журнал стручка?

Answer 1

Как отметил Патрик, вам нужно новое правило маршрутизации, которое поможет всему трафику на главный узел через шлюз по умолчанию, а не NAT.Пожалуйста, следуйте этой конфигурации NAT специально для GKE , в которой упоминается дополнительный маршрут.

Журналы kubectl взаимодействуют с api-сервером k8s на вашем главном компьютере, мастер затем извлекает журналы из контейнера (эффективно запускает журналы докера на узле) и отправляет информацию обратно вам.Каждый раз, когда вы запускаете команду kubectl, она взаимодействует с сервером API на главном сервере.Затем мастер подключается к узлу с использованием SSH.Вы также можете найти IP-адрес мастера, запустив kubectl get endpoint.Конечная точка «kubernetes» - это IP-адрес конечной точки вашего мастера.

Answer 2

Он использует kube-proxy для подключения к узлам и оттуда просматривает журналы в контейнерах, как, скажем, docker logs <container-name> сделает это. Затем он перенаправляет вывод обратно туда, куда вы запускаете kubectl.

Kubernetes использует много iptables и маршрутизации во всех его узлах, поэтому любое изменение, которое вы внесете в экземпляры, где он работает, повлияет на то, как компоненты взаимодействуют друг с другом. Убедитесь, что этот тег «no-ip» позволил изменить / добавить / удалить правила брандмауэра, где работают ваши узлы Kubernetes.

Надеюсь, это поможет!