Частните възли на GKE не решават кой API използва kubectl

Възлите са частни, VPN-ът ги достига, а kubectl все още не може да говори с клъстера. Тези два факта са несвързани. Адресът, който kubectl използва, идва от URL адреса на сървъра, записан в kubeconfig при изтеглянето на идентификационните данни, и никой добавен от вас маршрут не го променя. Междувременно възлите не са това, към което kubectl изобщо се опитва да достигне.

Пет проверки, като започваме с единствената стойност, която има значение.

Проверка 1: прочетете URL адреса на сървъра в kubeconfig

Отпечатайте крайната точка, без да изливате идентификационните данни: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Този единствен низ ви казва дали клиентът сочи към IP адрес, DNS име или външен адрес, който не сте имали предвид. Всичко останало в това разследване произтича от него.

Ако URL адресът не е крайната точка, която сте мислили, че сте конфигурирали, останалата част от диагностиката е разсейване.

Проверка 2: съпоставете URL адреса с типа крайна точка

Настоящият GKE поддържа както IP-базиран, така и DNS-базиран достъп до контролната плоскост, а изтеглените идентификационни данни избират един от тях. gcloud container clusters get-credentials NAME --location REGION --internal-ip записва крайната точка с вътрешен IP адрес, докато --dns-endpoint избира DNS-базиран достъп. Нито един от флаговете не осигурява мрежов път, което изненадва хората, очакващи изтеглянето да поправи свързаността. Изтеглете отново умишлено и след това прочетете URL адреса пак.

Смяната на флагове без повторно четене на URL адреса е начинът, по който един лаптоп остава с идентификационни данни за два клъстера и една объркваща грешка.

Записът в разрешената мрежа определя кой може да достигне външна крайна точка и не се прилага към вътрешната. Разширяването му, за да тествате частен път, променя излагането ви, а не диагностиката ви.

Проверка 3: докажете пътя до тази крайна точка

Ако URL адресът е вътрешен IP, проверете маршрута от мрежата, в която клиентът реално се намира, разрешения диапазон на източниците и регионалната или глобалната настройка за достъп на клъстера. Диапазонът на контролната плоскост и подмрежата на възлите не са една и съща дестинация, така че работещ маршрут до възлите не доказва нищо за крайната точка. За DNS-базиран достъп пътят е свързаност с Google API с документирания режим Private Google Access, а не маршрут до подмрежата на работните възли. Тествайте крайната точка с обикновена TCP връзка, преди да обвинявате kubectl.

Изтичането на време е проблем с пътя. 403 е проблем с политика. Те не споделят поправка.

Проверка 4: отделете логовете и exec от API заявките

Ако обикновените API заявки успяват, а kubectl logs или kubectl exec се проваля, вие вече сте преминали избора на крайна точка. Тези операции изискват съответните права в Kubernetes и зависят от комуникацията между контролната плоскост и възлите, а неуспехът може да е отговор Forbidden, а не изтичане на време. SSH достъпът до възел тества съвсем друга услуга и не ги установява.

Прочетете класа на грешката, преди да отворите отново тикета за VPN, защото двата класа живеят на различни места.

Проверка 5: запазете три наблюдения за следващия човек

Запишете избрания API URL, дали една оторизирана API заявка работи, и точно коя следваща операция се проваля, заедно с текста на грешката. Тези три реда разделят избора на крайна точка от достъпа до възлите и спират напълно добър VPN маршрут да бъде обвинен за заявка, която никога не е носил.

Следващият инженер ще попита дали тунелът е счупен. Бележката ви трябва вече да отговаря на това.