Եթե դուք նման եք մարդկանց մեծամասնությանը, հավանաբար օգտագործում եք ռեսուրսներ, որոնք աշխատում են ձեր կլաստերից դուրս: Հավանաբար դուք օգտագործում եք Taleo API-ն տեքստային հաղորդագրություններ ուղարկելու կամ պատկերներ վերլուծելու համար՝ օգտագործելով Google Cloud Vision API-ն:
Եթե դուք օգտագործում եք նույն սերվերի կողմից հարցման վերջնակետը ձեր բոլոր միջավայրերում և չեք նախատեսում ձեր սերվերները տեղափոխել Kubernetes, ապա շատ լավ է ունենալ ծառայության վերջնակետ հենց ձեր կոդի մեջ: Սակայն իրադարձությունների զարգացման բազմաթիվ այլ սցենարներ կան։ Այս Kubernetes-ի լավագույն պրակտիկաների շարքում դուք կսովորեք, թե ինչպես օգտագործել Kubernetes-ի ներկառուցված մեխանիզմները՝ հայտնաբերելու ծառայություններ ինչպես կլաստերի ներսում, այնպես էլ դրսում:
Ընդհանուր արտաքին ծառայության օրինակ է տվյալների բազան, որն աշխատում է Kubernetes կլաստերից դուրս: Ի տարբերություն ամպային տվյալների շտեմարանների, ինչպիսիք են Google Cloud Data Store-ը կամ Google Cloud Spanner-ը, որոնք օգտագործում են մեկ վերջնական կետ բոլոր մուտքի համար, տվյալների բազաներից շատերն ունեն առանձին վերջնակետեր տարբեր հանգամանքների համար:
Ավանդական տվյալների բազաների օգտագործման լավագույն փորձը, ինչպիսիք են MySQL-ը և MongoDB-ը, սովորաբար նշանակում է, որ դուք միանում եք տարբեր բաղադրիչների տարբեր միջավայրերի համար: Դուք կարող եք ունենալ մեծ մեքենա՝ արտադրության տվյալների համար և ավելի փոքր մեքենա՝ թեստային միջավայրի համար: Նրանցից յուրաքանչյուրը կունենա իր սեփական IP հասցեն կամ դոմենի անունը, բայց դուք, հավանաբար, չեք ցանկանա փոխել ձեր կոդը մի միջավայրից մյուսը տեղափոխելիս: Այսպիսով, այս հասցեները կոշտ կոդավորելու փոխարեն, դուք կարող եք օգտագործել Kubernetes-ի ներկառուցված DNS-ի վրա հիմնված արտաքին ծառայությունների հայտնաբերումը նույն կերպ, ինչպես հայրենի Kubernetes ծառայությունները:
Ենթադրենք, դուք աշխատում եք MongoDB տվյալների բազա Google Compute Engine-ում: Դուք խրված կմնաք այս հիբրիդային աշխարհում, մինչև հասցնեք այն տեղափոխել կլաստեր:
Բարեբախտաբար, դուք կարող եք օգտագործել ստատիկ Kubernetes ծառայություններ՝ ձեր կյանքը մի փոքր հեշտացնելու համար: Այս օրինակում ես ստեղծեցի MongoDB սերվեր՝ օգտագործելով Google Cloud Launcher-ը: Քանի որ այն ստեղծվել է նույն ցանցում (կամ Kubernetes կլաստերի VPC), այն հասանելի է բարձր արդյունավետությամբ ներքին IP հասցեի միջոցով:
Սա Google Cloud-ի լռելյայն կարգավորումն է, այնպես որ ձեզ հարկավոր չէ որևէ բան կարգավորել: Այժմ, երբ դուք ունեք IP հասցե, առաջին քայլը ծառայություն ստեղծելն է: Դուք կարող եք նկատել, որ այս ծառայության համար պատիճ ընտրիչներ չկան: Այսինքն՝ մենք ստեղծեցինք մի ծառայություն, որը չի իմանա, թե ուր ուղարկել թրաֆիկը։ Սա թույլ կտա ձեռքով ստեղծել վերջնակետի օբյեկտ, որը կստանա տրաֆիկ այս ծառայությունից:
Հետևյալ կոդի օրինակը ցույց է տալիս, որ վերջնակետերը որոշում են տվյալների բազայի IP հասցեն՝ օգտագործելով ծառայության նույն մոնգո անունը:
Kubernetes-ը կօգտագործի բոլոր IP հասցեները՝ վերջնակետերը գտնելու համար, կարծես դրանք սովորական Kubernetes Pods լինեին, այնպես որ այժմ կարող եք մուտք գործել տվյալների բազա վերը նշված mongodb://mongo անվան հետ կապի պարզ տողով: Ձեր կոդը ընդհանրապես IP հասցեներ օգտագործելու կարիք չկա:
Եթե ապագայում IP հասցեները փոխվեն, դուք պարզապես կարող եք թարմացնել ձեր վերջնակետերը նոր IP հասցեով, և ձեր հավելվածները որևէ լրացուցիչ ձևափոխման կարիք չեն ունենա:
Եթե դուք օգտագործում եք տվյալների բազա, որը տեղակայված է երրորդ կողմի հոսթում, հավանական է, որ հոսթի սեփականատերերը ձեզ տրամադրել են Uniform Resource Identifier URI՝ միանալու համար: Այսպիսով, եթե ձեզ տրվել է IP հասցե, կարող եք պարզապես օգտագործել նախորդ մեթոդը: Այս օրինակը ցույց է տալիս, որ ես ունեմ երկու MongoDB տվյալների բազա, որոնք տեղակայված են mLab հոսթի վրա:
Մեկը մշակողների տվյալների բազան է, մյուսը՝ արտադրության տվյալների բազան։ Այս տվյալների շտեմարանների միացման տողերն այսպիսի տեսք ունեն. mLab-ը ձեզ տրամադրում է դինամիկ URI և դինամիկ միացք: Ինչպես տեսնում եք, դրանք տարբեր են:
Սա վերացարկելու համար եկեք օգտագործենք Kubernetes-ը և միանանք մշակողների տվյալների բազային: Դուք կարող եք ստեղծել արտաքին Kubernetes ծառայության անուն, որը ձեզ կտրամադրի ստատիկ ծառայություն, որը կփոխանցի երթևեկությունը դեպի արտաքին ծառայություն:
Այս ծառայությունը կկատարի պարզ CNAME վերահասցեավորում միջուկի մակարդակում՝ նվազագույն կատարողականի ազդեցությամբ: Դրա շնորհիվ դուք կարող եք օգտագործել ավելի պարզ կապի տող:
Բայց քանի որ արտաքին անվանումն օգտագործում է CNAME վերահասցեավորում, այն չի կարող կատարել պորտի վերահասցեավորում: Հետևաբար, այս լուծումը կիրառելի է միայն ստատիկ նավահանգիստների համար և չի կարող օգտագործվել դինամիկ պորտերի հետ: Բայց mLab Free Tier-ը օգտատիրոջը լռելյայն տալիս է դինամիկ պորտի համար, և դուք չեք կարող փոխել այն: Սա նշանակում է, որ ձեզ անհրաժեշտ են կապի տարբեր հրամանների տողեր dev-ի և prod-ի համար: Վատն այն է, որ դրա համար ձեզանից կպահանջվի կոշտ կոդավորել պորտի համարը: Այսպիսով, ինչպե՞ս եք կարողանում նավահանգստի վերահասցեավորումը գործի դնել:
Առաջին քայլը URI-ից IP հասցե ստանալն է: Եթե դուք գործարկում եք nslookup, hostname կամ Ping URI, կարող եք ստանալ տվյալների բազայի IP հասցեն: Եթե ծառայությունը ձեզ վերադարձնի մի քանի IP հասցե, ապա այս բոլոր հասցեները կարող են օգտագործվել օբյեկտի վերջնակետերում:
Մի բան, որ պետք է հիշել, այն է, որ IP URI-ները կարող են փոխվել առանց ծանուցման, ինչը նրանց բավականին ռիսկային է դարձնում արդ. Օգտագործելով այս IP հասցեն՝ դուք կարող եք միանալ հեռավոր տվյալների բազային՝ առանց նավահանգիստ նշելու: Այսպիսով, Kubernetes ծառայությունը բավականին թափանցիկ է կատարում նավահանգիստների վերահասցեավորում։
Քարտեզագրումը կամ արտաքին ռեսուրսների քարտեզագրումը ներքին ռեսուրսներին տալիս է ճկունություն՝ օգտագործելու այս ծառայությունները կլաստերի ներսում ապագայում՝ նվազագույնի հասցնելով վերամշակման ջանքերը: Այն նաև հեշտացնում է կառավարելը և պատկերացում կազմել այն մասին, թե ինչ արտաքին ծառայություններ է օգտագործում ձեր ընկերությունը:
Շարունակությունը շատ շուտով...
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com