minikube-ը չի հասնում մասնավոր API-ին? Նախ ստուգեք դրայվերը
Հոսթը, հանգույցը և Pod-ը յուրաքանչյուրն ունի իր երթուղիները և իր resolver-ը։ Անվանեք դրայվերը, ստուգեք նույն endpoint-ը բոլոր երեքից, ապա ուղղեք այն կոնտեքստը, որը ձախողվել է։
Մասնավոր API-ն պատասխանում է ձեր նոութբուքից, և minikube-ում գտնվող Pod-ը չի կարող հասնել դրան։ Հոսթի վրա որևէ բան փոխելուց առաջ անվանեք ակտիվ պրոֆիլի հետևում գտնվող դրայվերը, որովհետև այդ մեկ փաստը որոշում է, թե որ ցանցից է իրականում դուրս գալիս հարցումը։ Այնուհետև ստուգեք նույն endpoint-ը հոսթից, հանգույցից և Pod-ից։ Այդ երեքից միայն մեկն է այն, ինչը ձախողվել է, և սխալ ենթադրությունը արժենում է կես օր։
Քայլ 0՝ անվանեք դրայվերը և աղբյուրը
Հարցրեք minikube-ին, թե որ պրոֆիլն է ակտիվ և ինչպես է աշխատում։ Կոնտեյների դրայվերը հանգույցը տեղադրում է ձեր մեքենայի կոնտեյների մեջ, VM դրայվերը տեղադրում է այն վիրտուալ մեքենայում, իսկ հեռավոր դրայվերը տեղադրում է այն բոլորովին այլ տեղ։
minikube profile list
minikube status
kubectl config current-contextԴրանից գրի առեք, թե որտեղից է սկիզբ առնում հարցումը։ Պատասխանը որոշում է, թե ում resolver-ը և որ երթուղիներն են կարևոր, և դա միշտ չէ, որ հոսթինն է։ Նույն նոութբուքի երկու պրոֆիլ կարող են բոլորովին տարբեր կերպ վարվել նույն URL-ի համար։
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
Քայլ 1՝ ստուգեք նույն endpoint-ը երեք անգամ
Օգտագործեք մեկ անվտանգ endpoint և բոլոր երեք թեստերում պահեք հոսթի անունը, պորտը և հասցեների ընտանիքը նույնական։ Եթե դրանցից որևէ մեկը փոխեք գործարկումների միջև, արդյունքները համադրելի չեն լինի։
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthՀանգույցի կողմից image-ի հաջող ներբեռնումը ոչինչ չի ապացուցում մասնավոր հոսթի համար անունների լուծման մասին։ Հաջող հանրային հարցումն ավելի քիչ բան է ապացուցում։ Արդյունքները պահեք առանձին՝ ըստ կոնտեքստի, որովհետև երեք տողով ձևավորված օրինաչափությունը ախտորոշում է, իսկ մեկուսի ձախողումը՝ հուշում։
Եթե հոսթի տողը նույնպես ձախողվում է, կանգ առեք։ Դուք ունեք հոսթի ցանցի խնդիր, և կլաստերը շեղում է։
Քայլ 2՝ պահպանեք հոսթի ուղին դեպի կլաստեր
Կա երկրորդ ուղղություն, որը մարդիկ մոռանում են՝ հոսթը պետք է շարունակի հասնել կլաստերի սեփական API-ին և ծառայություններին։ VPN հաճախորդը կարող է տեղադրել երթուղիներ, որոնք մրցակցում են այն նախածանցերի հետ, որոնք minikube-ը օգտագործում է իր հանգույցների ցանցի, ծառայությունների տիրույթի և pod-երի տիրույթի համար։
Երբ դա տեղի է ունենում, ախտանիշը շփոթեցնող է, որովհետև թունելը աշխատում է, և kubectl-ը դադարում է պատասխանել կամ NodePort-ը մերժում է միացումները։ Դա նման է կլաստերի խափանման, բայց իրականում նոութբուքի երթուղավորման խափանում է։
Ստուգեք հոսթի երթուղավորման աղյուսակը minikube-ի տիրույթների համեմատ, նախքան թունելին որևէ այլ բանում մեղադրելը։ Համընկնումը սովորաբար երևում է որպես ավելի կոնկրետ երթուղի, որը ցույց է տալիս թունելի ինտերֆեյսին այն նախածանցի համար, որը կլաստերը համարում է իրենը։
Քայլ 3՝ լուծեք համընկնումը առանց VPN-ն անջատելու
minikube-ի սեփական VPN և proxy ձեռնարկը քննարկում է այս կոնֆլիկտները և իր օրինակային տիրույթները դիտարկում է որպես ստուգման ենթակա բաներ, ոչ որպես համընդհանուր ցանկ։ Կարդացեք այն ձեր իրականում ունեցած պրոֆիլի հետ միասին։
Այնտեղ, որտեղ իրական համընկնում կա, աջակցվող պատասխանը չհամընկնող տիրույթն է կամ VPN-ի սեփականատիրոջ կողմից հաստատված դիտավորյալ լոկալ մուտքի քաղաքականությունը։ Ծառայությունների տիրույթը փոխելը նույնը չէ, ինչ pod-երի տիրույթը փոխելը, և ոչ մեկը նույնը չէ, ինչ հանգույցների ցանցը փոխելը։
Կորպորատիվ թունելն անջատելը, որպեսզի լոկալ կլաստերը աշխատի, շրջանցում չէ. դա քաղաքականության որոշում է, որը պետք է կայացնի մեկ ուրիշը։ Տարեք այն այդ մարդուն, փոխարենը այն լուռ անելու բոլորի տուն գնալուց հետո։ Եթե արդեն արել եք, վերադարձրեք նախքան հարցնելը։
Քայլ 4՝ առանձնացրեք proxy-ն, DNS-ը և ձախողման չորս ձևերը
Եթե proxy է պահանջվում, որոշեք, թե որ կոնտեքստին է այն պետք։ Հոսթի վրա բրաուզերի կարգավորումը չի կարգավորում հանգույցի ներսում գտնվող գործընթացը, և Pod-ին անհրաժեշտ են միջավայրի փոփոխականները կամ կլաստերի մակարդակի proxy կարգավորում։
Ապա դասակարգեք ձախողումը՝ այն նկարագրելու փոխարեն։ Անունը, որը չի լուծվում, DNS է։ Անունը, որը լուծվում է և մերժում միացումը, երթուղավորում է կամ listener։ Միացումը, որը հաստատվում է և ձախողվում ինքնության վրա, TLS է։ Հաջող միացումը սխալի մարմնով հավելվածն է։
Այդ չորսից յուրաքանչյուրը պատկանում է տարբեր ուղղման, և դրանցից միայն մեկն է VPN-ի մասին։ Գրի առեք, թե որն եք դիտարկել յուրաքանչյուր կոնտեքստում, և հաջորդ մարդը ժառանգում է ապացույցներ, այլ ոչ թե պատմություն։