Калі вы падобныя на большасць людзей, то, хутчэй за ўсё выкарыстоўваеце рэсурсы, якія функцыянуюць за межамі вашага кластара. Магчыма, вы выкарыстоўваеце API Taleo для адпраўкі тэкставых паведамленняў або аналізуеце выявы з дапамогай API Google Cloud Vision.
Калі вы выкарыстоўваеце адну і тую ж канчатковую кропку endpoint — кропку прыёму запытаў на баку сервера ва ўсіх сваіх асяроддзях і не плануеце пераносіць свае серверы ў Kubernetes, то зусім нармальна мець endpoint сэрвісу прама ў вашым кодзе. Аднак існуе мноства іншых сцэнарыяў развіцця падзей. У гэтай серыі "Kubernetes Best Practices" вы даведаецеся, як выкарыстоўваць убудаваныя механізмы Kubernetes для выяўлення сэрвісаў як унутры, так і па-за кластарам.
У якасці прыкладу шырока распаўсюджанага знешняга сэрвісу можна прывесці базу дадзеных, якая працуе па-за кластарам Kubernetes. У адрозненне ад такіх хмарных баз дадзеных, як Google Cloud Data Store або Google Cloud Spanner, якія выкарыстоўваюць адну канчатковую кропку для ўсіх відаў доступу, большасць баз дадзеных маюць асобныя канчатковыя кропкі для розных абставін.
Перадавая практыка выкарыстання традыцыйных баз дадзеных, такіх як MySQL і MongoDB, звычайна прадугледжвае, што вы падлучаецеся да розных кампанентаў для рознага асяроддзя. У вас можа быць вялікая машына для прадакшн-дадзеных і машына паменш для тэставай асяроддзя. У кожнай з іх будзе свой IP адрас або даменнае імя, але вы напэўна не захочаце мяняць свой код пры пераходзе ад аднаго асяроддзя да іншага. Таму замест цвёрдага кадавання гэтых адрасоў вы можаце выкарыстоўваць убудаваны ў Kubernetes сэрвіс выяўленне вонкавых службаў на аснове DNS сапраўды гэтак жа, як і для натыўных сэрвісаў Kubernetes.
Выкажам здагадку, што вы запускаеце базу дадзеных MongoDB у Google Compute Engine. Вы затрымаецеся ў гэтым гібрыдным свеце да таго моманту, пакуль вам не ўдасца перанесці яе ў кластар.
На шчасце, вы можаце выкарыстоўваць статычныя сэрвісы Kubernetes, каб хоць крыху аблегчыць сабе жыццё. У гэтым прыкладзе я стварыў сервер MongoDB, выкарыстоўваючы Google Cloud Launcher. Бо ён створаны ў той жа сетцы (ці VPC кластара Kubernetes), то доступ да яго ажыццяўляецца з дапамогай высокапрадукцыйнага ўнутранага IP-адрасы.
У Google Cloud гэта настройка па змаўчанні, так што вам не трэба нічога наладжваць. Цяпер, калі ёсць IP-адрас, першы крок заключаецца ў стварэнні сэрвісу. Можна заўважыць, што для гэтага сэрвісу няма ніякіх селектараў подаў. Гэта значыць, мы стварылі службу, якая не будзе ведаць, куды пасылаць трафік. Гэта дазволіць уручную стварыць endpoint аб'ект, які і будзе атрымліваць трафік ад дадзенага сервісу.
Наступны прыклад кода паказвае, што канчатковыя кропкі вызначаюць IP-адрас для базы дадзеных, выкарыстоўваючы тое ж самае імя mongo, што і сэрвіс.
Kubernetes будзе выкарыстоўваць усе IP-адрасы, каб знайсці канчатковыя кропкі, як калі б яны былі звычайнымі падамі Kubernetes, так што зараз вы можаце атрымаць доступ да базы дадзеных з дапамогай простага радка падлучэння да вышэйпаказанага імя mongodb://mongo. Пры гэтым наогул няма неабходнасці выкарыстоўваць IP-адрасы ў вашым кодзе.
Калі ж у будучыні IP-адрасы зменяцца, можна проста абнавіць канчатковыя кропкі з дапамогай новага IP-адрасу, і вашы прыкладанні не трэба будзе змяняць нейкім дадатковым чынам.
Калі вы выкарыстоўваеце базу дадзеных, размешчаную на іншым хасце, то, хутчэй за ўсё, уладальнікі хаста падалі вам для падлучэння ўніфікаваны ідэнтыфікатар рэсурсу URI. Так што калі вам далечы IP-адрас, можна проста скарыстацца папярэднім метадам. Дадзены прыклад паказвае, што ў мяне маюцца дзве базы дадзеных MongoDB, размешчаныя на хасце mLab.
Адзін з іх - гэта база дадзеных распрацоўшчыкаў, а іншая - БД продакшена. Радкі падлучэння для гэтых баз дадзеных выглядаюць наступным чынам - mLab дае вам дынамічны URI і дынамічны порт. Як бачыце, яны розныя.
Каб абстрагавацца ад гэтага, выкарыстоўваем Kubernetes і падлучымся да базы дадзеных распрацоўнікаў. Вы можаце стварыць знешняе імя сэрвісу Kubernetes, што дасць вам статычны сэрвіс, які будзе перанакіроўваць трафік знешняму сэрвісу.
Гэты сэрвіс выканае простую CNAME пераадрасаванне на ўзроўні ядра, што акажа мінімальнае ўплыў на прадукцыйнасць. Дзякуючы гэтаму вы можаце выкарыстоўваць прасцейшы радок падлучэння.
Але паколькі вонкавае імя выкарыстоўвае перанакіраванне CNAME, яно не можа выканаць перапрызначэнне портаў. Таму дадзенае рашэнне дастасоўна толькі для статычных партоў і не можа выкарыстоўвацца з дынамічнымі партамі. Але бясплатны mLab Free Tier па змаўчанні дае карыстачу дынамічны нумар порта, і вы не можаце гэта змяніць. Гэта азначае, што для dev і prod вам патрэбны розныя камандныя радкі злучэння. Дрэнна тое, што пры гэтым спатрэбіцца цвёрда закадаваць нумар порта. Дык як жа прымусіць працаваць перапрызначэнне партоў?
Першы крок - гэта атрыманне IP-адрасы з URI. Калі выканаць каманду nslookup, hostname ці прапінгаваць URI, можна атрымаць IP-адрас базы дадзеных. Калі пры гэтым сэрвіс вяртае вам некалькі IP-адрасоў, то ўсе гэтыя адрасы можна выкарыстоўваць у канчатковых кропках аб'екта.
Трэба памятаць, што IP-адрасы URI могуць змяніцца без папярэдняга апавяшчэння, так іх даволі рызыкоўна выкарыстоўваць у prod. З дапамогай такога IP-адрасы можна падлучыцца да выдаленай базы дадзеных, не паказваючы пры гэтым порт. Такім чынам, сэрвіс Kubernetes даволі празрыста выконвае перапрызначэнне портаў.
Мапінг, або супастаўленне знешніх рэсурсаў з унутранымі, дае вам магчымасць гнутка выкарыстоўваць гэтыя службы ўнутры кластара ў будучыні пры мінімізацыі намаганняў па рэфактарынгу. Ён таксама палягчае кіраванне і дае разуменне таго, якімі вонкавымі сэрвісамі карыстаецца ваша кампанія.
Працяг будзе зусім хутка…
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com