Приватните 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 рута да биде обвинета за барање што таа никогаш не го пренела.

Следниот инженер ќе праша дали тунелот е расипан. Вашата белешка веќе треба да одговори на тоа.