Parimad praktikud Kuberneteses. Välisteenuste kaardistamine

Kubernetesi parimad praktikad. Väikeste konteinerite loomine
Kubernetesi parimad praktikad. Kubernetesi korraldamine nimespetsiifiliste ruumide abil
Kubernetesi parimad praktikad. Kubernetesi elujõudluse kontrollimine Readiness ja Liveness testide abil
Kubernetesi parimad praktikad. Ressursside päringute ja piirangute seadistamine
Kubernetes parimad praktikad. Korralik lõpetamine Terminate

Kui olete nagu enamik inimesi, kasutate tõenäoliselt ressursse, mis asuvad väljaspool teie klastrit. Võib-olla kasutate API Taleo, et saata tekstisõnumeid või analüüsida pilte Google Cloud Vision API kaudu.

Kui kasutate sama lõpp-punkti — serveri poolt päringute vastuvõtmise punkti kõigis oma keskkondades ega kavatse oma servereid Kubernetesesse kolida, siis on täiesti normaalne, et teenuse lõpp-punkt asub otse teie koodis. Siiski on palju teisi stsenaariume. Selles sarjas "Kubernetes parimad praktikad" saate teada, kuidas kasutada Kubernetesesse sisseehitatud mehhanisme teenuste avastamiseks nii klastris kui ka väljaspool seda.

Näiteks laialdaselt kasutatavatest välistest teenustest võib tuua välja andmebaasi, mis töötab väljaspool Kubernetes klastrit. Erinevalt pilveandmebaasidest, nagu Google Cloud Data Store või Google Cloud Spanner, millele pääseb ligi ühe ja sama lõpp-punkti kaudu, on enamikul andmebaasidest erinevad lõpp-punktid erinevate olukordade jaoks.
Tavapärase andmebaasi, nagu MySQL ja MongoDB, kasutamise parim praktika hõlmab tavaliselt erinevate komponentide ühendamist erinevatesse keskkondadesse. Võib olla suur masin tootmisandmete jaoks ja väiksem masin testkeskkonna jaoks. Igal neist on oma IP-aadress või domeeninimi, kuid te kindlasti ei taha oma koodi muuta, kui liigute ühelt keskkonnalt teisele. Seetõttu võite nende aadresside kõva kodeerimise asemel kasutada Kubernetesi sisseehitatud teenuste avastamist, mis põhineb DNS-il, just nagu teeksite natiivsete Kubernetesi teenustega.

Oletame, et käitate andmebaasi MongoDB Google Compute Engine'is. Jäete kinni selle hübriidmaailma, kuni suudate selle klastrisse kolida.

Õnneks saate kasutusele võtta Kubernetes'i staatilised teenused, et endale elu veidi lihtsamaks teha. Selles näites olen loonud MongoDB serveri, kasutades Google Cloud Launcherit. Kuna see on loodud samasse võrku (või Kubernetes klastrisse VPC), toimub sellele juurdepääs suure jõudlusega sise-IP-aadressi kaudu.

Google Cloudis on vaikimisi seade, nii et te ei pea midagi seadistama. Nüüd, kui IP-aadress on olemas, on esimene samm teenuse loomine. Võib märgata, et selle teenuse jaoks ei ole ühtegi pod'i valijat. See tähendab, et oleme loonud teenuse, mis ei tea, kuhu liiklust suunata. See võimaldab käsitsi luua endpoint objekti, mis saab liiklust sellest teenusest.

Järgmine koodinäide näitab, et lõpp-punktid määravad andmebaasi IP-aadressi, kasutades sama nime mongo, mis on teenusel.

Kubernetes kasutab kõiki IP-aadresse, et leida lõpp-punkte, nagu oleks need tavalised Kubernetes pod'id, nii et nüüd saate andmebaasi juurde pääseda lihtsa ühendusteksti abil, mis on antud nimi mongodb://mongo. Sellega ei ole teie koodis üldse vaja IP-aadresse kasutada.

Kui tulevikus IP-aadressid muutuvad, saate lihtsalt lõpp-punkte värskendada uue IP-aadressiga, ja teie rakendusi ei pea mingil moel muutma.

Kui kasutate andmebaasi, mis asub kolmandal pool, on tõenäoliselt hosti omanikud andnud teile ühendamiseks ühtse ressursi identifikaatori URI. Nii et kui teile on antud IP-aadress, saate lihtsalt kasutada eelnevat meetodit. See näide näitab, et mul on kaks MongoDB andmebaasi, mis asuvad mLab hostis.

Üks neist on arendajate andmebaas ja teine — tootmisandmebaas. Nende andmebaaside ühendusread näevad välja järgmised — mLab pakub teile dünaamilist URI-d ja dünaamilist porti. Nagu näete, on need erinevad.

Kuna soovime sellest eristuda, kasutame Kubernetes't ja ühendame arendajate andmebaasiga. Saate luua Kubernetes'e välise teenuse nime, mis annab teile staatilise teenuse, mis suunab liikluse välist teenust.

See teenus rakendab lihtsat CNAME edastamist tasemel kernel, mis mõjutab tulemuslikkust minimaalselt. Tänu sellele saate kasutada lihtsamat ühendusreed.

Kuna väline nimi kasutab CNAME-i ümbersuunamist, ei saa seda portide uuenemist teha. Seetõttu on see lahendus rakendatav ainult staatilistele portidele ja ei saa kasutada dünaamiliste portide puhul. Kuid tasuta mLab Free Tier pakub vaikimisi kasutajale dünaamilist porti, ja te ei saa seda muuta. See tähendab, et dev ja prod jaoks vajate erinevaid ühenduste käsklusi. Halba on see, et porti numbrit tuleb tugevalt kodeerida. Kuidas siis portide ümbersuunamist tööle saada?

Esimene samm on saada IP-aadress URI-st. Kui käivitada nslookup käsk, hostname või pingida URI, saab andmebaasi IP-aadressi. Kui teenus tagastab mitu IP-aadressi, saab kõiki neid kasutada objekti lõpp-punktidena.

Pea meeles, et URI IP-aadressid võivad muutuda ette teatamata, seega on nende kasutamine prod-s üsna riskantne. Sellise IP-aadressiga on võimalik ühenduda kaugandmebaasiga, mitte porti näidates. Seega teostab Kubernetes teenus üsna transparentselt portide ümbersuunamist.

Kaartimine, ehk väliste ressursside seondamine sisemistega, annab teile võimaluse paindlikult neid teenuseid tulevikus klastris kasutada, vähendades refaktoreerimise vaeva. See hõlbustab ka haldamist ning annab arusaama, milliseid väliseid teenuseid teie ettevõte kasutab.

Peagi on see tulemas…

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com