Kuidas luua vaikimisi turvaline Kubernetes'i klaster põhilise CI / CD torujuhtmega AWS-is

Kirjutanud Matthew Sheppard ja Donald Carnegie

Kuber-mis-es?

Kubernetes (hääldatakse “koo-burr-NET-eez”) on avatud lähtekoodiga platvorm rakendusekonteinerite juurutamise, mõõtmete muutmise ja käitamise automatiseerimiseks. Lahedad lapsed viitavad sellele sageli (IOHO) mitte eriti hea lühendiga “k8s”. Kubernetesi ülesanne on kasutada oma infrastruktuuri kõige tõhusamalt, tagades samal ajal, et teie koondatud töömahud on saadaval ja saavad vastavalt vajadusele mastaabid. Mõned ettevõtted on teatanud, et suudavad vähendada pilveinfrastruktuuri kulusid 50–70% võrreldes tavapärasel VM-põhise arhitektuuriga töötamisega.

Sisaldage (viige) oma edu

Kubernetes on Cloud Native Computing Foundationi ja selle taga asuva avatud lähtekoodiga kogukonna jaoks tohutu edulugu. Esmakordselt 2014. aasta keskel kuulutatud Google'i inseneride meeskonna juhitud väikese projektina on sellest kasvanud de facto konteinerorkestriplatvorm ja kaup kogu avalikus pilve ökosüsteemis. Microsoftil, Google'il, Amazonil ja IBMil on kõigil hallatud Kubernetes'i pakkumine. Kaasautorite ja kiiruse osas on Kubernetes Linuxi kerneli avatud lähtekoodiga projektides teisel kohal. Seda kasutatakse ulatuslikult paljude lahedate töökoormuste jaoks, alates Pokemon Go toite sisselülitamisest kuni selleni, et HBO GO tellijad saavad mängu Game of Thrones 7. hooaega sujuvalt voogesitada.

Pidev Kubernetes

Kaasaegsete veebirakenduste kasutajate ja inseneridena eeldame, et need on saadaval 24 tundi ööpäevas, 7 päeva nädalas ja et me saaksime neist uusi versioone mitu korda päevas juurutada. Kubernetesest iseenesest selle eesmärgi saavutamiseks ei piisa. See tagab, et meie konteineripõhised rakendused töötaksid seal, kus ja kuhu tahame, ning suudab leida neile vajalikud tööriistad ja ressursid. Meie inseneride täielikuks volitamiseks peame Kubernetesi ümber ehitama CI / CD torujuhtme.

GitOps on Weaveworksi poolt välja töötatud termin, mis kirjeldab Giti kasutamist Kubernetesi klastri oleku deklaratiivse tõeallikana. Gitist saab meie süsteemi oleku jälgimise vahend ja me kasutame git-siseseid konstruktsioone, näiteks tõmbetaotlusi, et ühendada git-is olev olek pilveinfrastruktuuri olekuga. Lühidalt - heakskiidetud tõmmistaotluste tulemuseks on reaalsete muudatuste tegemine tootmises. See on tõesti võimas lähenemisviis, kuna tõestatud lähtekoodi töövoogu saab kasutada infrastruktuuri haldamiseks - selle täielikuks mõistmiseks võib vabaneda vana kooli bürokraatlikest muudatuste juhtimise protsessidest, mis on keerulised, võtavad liiga kaua aega ja millel puudub vastutus. Teie infrastruktuuris tehtud muudatused on alati 100% nähtavad, jälgitavad ja vastutustundlikud. Ajalugu hoitakse igavesti git-hoidlas ja ajaloo mis tahes punkti tagasi tagasi veeretamine on käkitegu.

Miks ma peaksin kasutama Kubernetesit?

Konteinerid on pilvandmetöötluses juba tohutu edulugu. Vaatamata suhteliselt lühikesele ajale, kui nad on olnud meie tööriistakastis, on neist saanud moodsa pilvandmetöötluse põhialused ja neid võimendavad paljud leibkonna nimerakendused. Konteinerisüsteemide korraldamise, haldamise ja hooldamise koormus võib aga olla tohutu - just sinna tuleb Kubernetes sisse. Kubernetes võtab kõik mahutid konteineerimise taga ette ja pakub platvormi nende hõlpsamaks juurutamiseks ja haldamiseks.

Kubernetes on DevOps võimaldaja; see aitab rakendada olulisi DevOps-tavasid ja sillutab organisatsioone teedele DevOps. Ükskõik kuhu installite, olgu see siis sülearvutisse, pilveteenuse pakkujasse või kohapealsesse andmekeskusesse, pakub see teie konteineripõhiste rakenduste automatiseeritud juurutamist täiesti ühtlastes keskkondades. Kubernetes'iga on möödunud päevad, mil ehitatakse ja testitakse edukalt kohapeal, ainult selleks, et leida teie rakendus, käitub katse- või tootmiskeskkonnas teisiti!

YATR? (Veel üks juhendaja, kas tõesti?)

Seal on palju Kubernetese õpetusi, nii et miks kirjutada veel üks? Hea küsimus! Kubernetesi klastrite loomisel enda huvides ja klientide huvides ei ole me kohanud õpetust, mis koondaks kõik tükid, mis on vajalikud AWS-i klastri seadistamiseks, mille saaks tootmiseks valmis teha. Dokumentatsioon on enamasti olemas, kuid see on aardejaht, et seda leida ja välja töötada, kuidas see igas konkreetses olukorras toimima panna. See muudab selle eriti väljakutseks kõigile, kes astuvad oma esimesse Kubernetes'i pilooti või astuvad sammu kohalikult minikube klastrist üles astudes.

Selle õpetuse eesmärk on see tühimik täita ja astuda läbi Kubernetes'i klastri seadistus, mis:

  • On väga kättesaadav: tahame tagada, et meie keskkonnad saavad riketega hakkama ja meie konteineripõhised rakendused töötavad ka siis, kui mõni meie sõlmedest ebaõnnestub või kui AWS-i saadavuse tsoonis ilmneb tõrge. Selle saavutamiseks juhime Kubernetes'i meistrid ja sõlmed üle kolme AWS-i saadavustsooni.
  • Jõustab „vähima privileegi põhimõtte”: vaikimisi peaksid kõik poodid töötama piiravas turvalisuse kontekstis; neil ei tohiks olla võimalust teha muudatusi Kubernetes'i klastris või selle aluseks olevas AWS-keskkonnas. Kõik puldid, mis peavad muutma Kubernetesi klastrit, peaksid kasutama nimetatud teenuse kontot, millele on lisatud sobiv roll ja reeglid. Kui poodiumil on vaja helistada AWS API-le, tuleks kõned vahendada, et tagada poodil piisav volitus nende tegemiseks ja ainult ajutiste IAM-mandaatide kasutamiseks. Selle saavutame kasutades Kubernetes Role-based Access Controli (RBAC), et tagada vaikimisi kaustade töö ilma klastri konfiguratsiooni muutmata. Kui konkreetsed klastriteenused vajavad õigusi, loome konkreetse teenusekonto ja seome selle vajaliku lubade ulatusega (st klastri ulatuses või ainult ühes nimeruumis) ja anname sellele teenusekontole vajalikud õigused. Juurdepääs AWS API-le vahendatakse kube2iam kaudu; kogu liiklus AWS API-le mõeldud poodiumidelt suunatakse ümber kube2iam. Tasku konfiguratsioonide märkuste põhjal helistab kube2iam AWS API-le, et hankida märkuses määratud rollile vastavad ajutised mandaadid ja tagastada need helistajale. Kõiki muid AWS API-kõnesid proksitakse kube2iam kaudu, et tagada väikseimate privileegide põhimõtte järgimine ja poliitikast ei saa mööda minna.
  • Integreerub Route53 ja klassikaliste koormuse tasakaalustajatega: rakenduse juurutamisel soovime, et meil oleks võimalus konfiguratsioonis deklareerida, kuidas see maailmale kättesaadavaks tehakse ja kust seda leida saab, ning lasta see meie jaoks automatiseerida. Kubernetes varustab rakenduse automaatselt klassikalise koormuse tasakaalustajaga ja väline dns võimaldab meil määrata selle sõbralikuks täielikuks domeeninimeks (FQDN), seda kogu infrastruktuuri koodina.
  • Sellele on mähitud põhiline CI / CD torujuhe: tahame automatiseerida seda, kuidas klastris muudatusi teeme ja kuidas rakendusi juurutada / värskendada. Meie klastri konfiguratsiooni täpsustavad konfiguratsioonifailid suunatakse Giti hoidlasse ja CI / CD torujuhe rakendab need klastrisse. Selle saavutamiseks kasutame Travis-CI abil meie peamises harule pühendunud konfiguratsiooni Kubernetes'i klastrisse. See on esimene samm GitOpsi suunas, kuid see ei anna meile täielikku GitOps'i võimalust.

Õpiku lõpus jõuame Kubernetes'i klastrini, mis näeb välja järgmine:

Meie lõppriigi Kubernetese klaster

Enne alustamist

Eeldame, et teil on Kubernetesega juba mõni tuttav. Kui olete Kuberneteses täiesti uus, on soovitatav tutvuda Kubernetesi põhitõdede juhendajaga ja tutvuda selle peamiste mõistetega.

Klastri ülesehitamiseks peame veenduma, et meil on installitud järgmised tööriistad:

  • kubectl
    kubectl (Kubernetes'i juhtimine) on käsuridade tööriist Kubernetesi klastriga suhtlemiseks, kas lokaalselt teie arvutis (minikube kasutades) või pilves.
  • kops
    Kubernetes Operations (kops) projekt pakub tööriistu Kubernetes'i klastrite loomiseks ja kasutamiseks pilves. Praegu toetab see Google Cloud & AWS-i (koos teiste beetaversiooni pakkujatega). Selles õpetuses kasutame klastri loomiseks ja haldamiseks kopsut.
  • Terraform
    Terraform on infrastruktuuri kui koodi (IAC) tööriist, mis võimaldab kasutajatel määratleda infrastruktuuri kõrgetasemelises konfiguratsioonikeeles, mida saab seejärel kasutada infrastruktuuri loomiseks teenusepakkujas, näiteks AWS või Google Cloud Platform. Kasutame Terraformi oma eelduste loomiseks kopsu jaoks ja kopsu loodud IAM-i poliitika muutmiseks.
  • AWS CLI
    AWS CLI on käsuridade tööriist AWS-iga suhtlemiseks. Seda nõuab kops & Terraform AWS-iga toimingute tegemiseks.

Paigaldusjuhised leiate esitatud linkidelt.

See õpetus loodi kasutades Kubernetes v1.8 ja kops v1.8.1.

Me töötame Mac OS X-iga koos Homebrew'ga, nii et nende installimiseks peame tegema vaid järgmised käsud:

$ brew värskendus
$ brew install kubectl
$ pruulima installida kops
$ brew install python3
$ easy_install pip
$ pip install awscli - upgrade - user
$ export PATH = ~ / .local / bin: $ PATH
$ brew paigalda terraform

Loo klaster

1. samm: kloonige meie hoidla

$ git kloon https://github.com/slalom-london/k8s-tutorial

2. samm: häälestage FQDN, mida kasutatakse Route53 klastris

Kubernetesi klaster, mille me seadistame, kasutab teenuse lõpp-punktide ja API juhtimistasandi paljastamiseks Route53 hostitud FQDN-i. Võite registreerida uue FQDN-i või olemasoleva FQDN-i üle kanda. AWS-il on kõigi nende võimaluste jaoks täielik samm läbi:

3. samm: looge eeldused kopsu jaoks

Selleks, et kops klastri üles ehitada, vajab klastri konfiguratsiooni hoidmiseks S3-kauplust ja IAM-i kasutajakontot, millele on lisatud järgmised põhimõtted:

AmazonEC2FullAccess
AmazonRoute53FullAccess
AmazonS3FullAccess
IAMFullAccess
AmazonVPCFullAccess

prereqs / kops_pre_reqs.tf loob selle teile. See loob ka S3-ämbri, mida kasutatakse meie Terraformi oleku kaugkauplusena. See võimaldab mitmel kasutajal töötada koos ühe infrastruktuurikomplektiga koodina, tekitamata konflikte. Peate faili värskendama, et asendada {my_bucket_name} ja {my_tf_bucket_name} teie valitud ämbri nimega.

Seejärel käivitage järgmised käsud:

$ cd eeltingimused
$ terraform init
$ terraformi plaan
$ terraform kehtib

Kui logite sisse oma AWS-i kontole, näete nüüd vastloodud kops IAM-i kasutajat, S3-kopp kopsuosariigi jaoks ja veel üks S3-kopp Terraformi kaubamaja jaoks

4. samm: klastri püstitamiseks kasutage kopsut

Eelmises etapis lõime kopsu jaoks IAM-konto. Nüüd peame selle konto kasutamiseks seadistama oma AWS CLI kliendi. Saame haarata kopsust IAM ID ja salajase võtme failist, mida Terraform kasutab eelmises etapis loodud oleku talletamiseks. Avage oma tekstiredaktoris terraform.tfstate ja otsige allolevat jaotist:

Väljadele {iam_id} ja {aws_secret_key} tehke väärtusmärge ja käivitage järgmine käsk:

$ aws seadistab - profiili profiili
AWS-i juurdepääsuvõtme ID [puudub]: {iam_id}
AWS salajane juurdepääsuvõti [puudub]: {aws_secret_key}
Piirkonna vaikenimi [puudub]: {your_chosen_aws_region}
Vaikimisi väljundvorming [puudub]: tekst

Järgmisena peame määrama paar keskkonnamuutujat, et kops teaks, millist AWS IAM-i kontot kasutada ja kuhu ta peaks oma riikliku poe paigutama:

$ eksport AWS_PROFILE = kops
$ export KOPS_STATE_STORE = s3: // {my_bucket_name}

Nüüd põhisündmuse jaoks - kasutagem meie klastri ehitamiseks kopsut. Käivitage järgmine käsk, asendades oma AWS-i piirkonna, oma DNS-tsooni ja valitud klastri nime:

$ kops loob klastri --cloud aws \
 - bassioon \
 - sõlmede arv 3 \
 - sõlme suurus t2.medium \
 - suurima suurusega t2.medium \
 --tsoonid {your_chosen_aws_region} a, {your_chosen_aws_region} b, {your_chosen_aws_region} c \
 --meistritsoonid {your_chosen_aws_region} a, {your_chosen_aws_region} b, {your_chosen_aws_region} c \
 --dns-zone {your_dns_zone} \
 --topoloogia privaatne \
 --võrgu loomine
 - autoriseerimine RBAC \
 - nimi {oma_klassi_nimi} \
 - out = k8s \
 - sihtmärk = terraform - silmad

See käsk ütleb kopsule, et tahame luua klastri, mis:

  • Kasutab AWS-i
  • Omab peasõlme t2.medium suurusega igas määratletud tsoonis
  • Tal on 3 töötaja sõlme suurusega t2.medium. kops jaotab töötajate sõlmed ühtlaselt kõigis saadavustsoonides
  • Kasutab privaatvõrgu topoloogiat, mis tähendab, et kõigil sõlmedel on privaatsed IP-aadressid ja neile pole avalikust Internetist otse juurde pääseda
  • Kasutab Calico konteinervõrgu liidesena, mis asendab privaatvõrgu topoloogia nõuete kohaselt kubenetti
  • Kasutab Kubernetes'i juurdepääsuõiguste jaoks RBAC-i
  • Kirjeldatakse Terraformi konfiguratsioonifailis, mis kirjutatakse kataloogi, mille määrab --out

kops genereerib vastloodud k8s kataloogis Terraformi konfiguratsioonifailide komplekti, mida saab klastri loomiseks rakendada. Enne klastri loomist tahame lisada konfiguratsioonifaili, mis ütleks Terraformile, et ta hoiaks oma olekuvara äsja loodud S3-ämbris.

$ cd k8s
$ terraform init
$ terraformi plaan
$ terraform kehtib

Teie klastri ilmumine võtab aega 10–15 minutit. Klastri olekut saate kontrollida järgmise käsuga:

$ kops valideerib klastri

Kui klastri loomine on lõpetatud, peaksite nägema sellist väljundit:

Kubectli kontekstis oleva klastri kasutamine: cluster.zigzag-london.com
Klassi klastri valideerimine.zigzag-london.com
INSTANCE RÜHMAD
NIMI ROLLI MASINATÜÜP MIN MAX SUBNETID
bastionid Bastion t2.micro 1 1 utiliit-eu-lääs-1a, utiliit-eu-lääs-1b, utiliit-eu-lääs-1c
master-eu-west-1a master t2.medium 1 1 eu-west-1a
master-eu-west-1b master t2.medium 1 1 eu-west-1b
master-eu-west-1c master t2.medium 1 1 eu-west-1c
sõlmed Sõlm t2.medium 3 3 eu-lääs-1a, eu-lääs-1b, eu-lääs-1c
NUDE STAATUS
NIMI ROLL VALMIS
ip-172-20-107-234.eu-west-1.compute.internal master True
ip-172-20-124-39.eu-west-1.compute.intern node Tõene
ip-172-20-44-152.eu-west-1.compute.intern master True
ip-172-20-60-188.eu-west-1.compute.intern node Tõene
ip-172-20-79-79.eu-west-1.compute.internal master True
ip-172-20-87-125.eu-west-1.compute.intern node Tõene
Teie klaster cluster.zigzag-london.com on valmis

CI / CD keskkonna püsimine

GitOps'i rakendamiseks vajame oma hoidla jälgimiseks ja värskenduste teostamiseks CI / CD-keskkonda. Selle õpetuse jaoks konfigureerime oma CI / CD-keskkonna nii, et see käivitaks juurutamisetapid igal meie hoidla peaharule jõudmisel. Me teeme seda meeleavalduse mugavuse huvides; arendajatel selle lubamine on kindlasti halb tava. Päriselu projektis soovitaksime funktsioonide hargnemisstrateegiat koos koodülevaate ja arendusjuhiste kinnitamise sammuga.

Selle õpetuse jaoks kavatseme kasutada pilvepõhist CI-teenust TravisCI. TravisCI on tasuta, kui:

  • Te hostite oma hoidlat Githubis
  • Hoidla on avalikult juurdepääsetav

1. samm: kontode ja klooni hoidla seadistamine

  • Liikuge GitHubi ja registreeruge \ logige sisse
  • Looge uus tühi hoidla ja pange sellele nimi „k8s-ci”
  • Kloonige see hoidla oma kohalikku masinasse:
$ git kloon 
  • Liikuge TravisCI-i ja registreeruge oma GitHubi kontoga. Liikuge oma kasutajaprofiilile, klõpsates paremas ülanurgas oma nimele.
  • Selle hoidla jaoks TravisCI lubamiseks klõpsake liugurit GitHubi repo vastu.

2. samm: seadistamise käivitajad

Kuna me harjutame GitOpsit, tahame juurutada ainult kinnitatud tõmbetaotluse korral. Saame seda Travises konfigureerida, klõpsates Veel suvandeid → Seaded.

  • Veenduge, et funktsioon „Lükka oksad üles” on sisse lülitatud
  • Veenduge, et funktsioon „Lükatud tõmbamistaotlused” on sisse lülitatud

Travis saab valdava enamuse oma juhistest teie hoidlasse talletatud yaml-failist. Looge oma hoidla juure tühi fail nimega .travis.yml ja saame hakata seda konfigureerima meie hoidlas oleva .travis.yml põhjal:

  • 1. rida: täpsustab, et me soovime, et ehitamine töötaks ainult peaharul. Reaalses keskkonnas kasutaksime tõenäoliselt ka haru lükkamist, kuid mitte tootmiskeskkonda, vaid testimiskeskkonda. Üks võimalus selleks on keskkonnamuutujate kasutamine tingimusliku loogika rakendamiseks juurutusskriptile, kuid see pole selle postituse jaoks ulatuslik.
  • 4. rida: täpsustab, et sõltuvuste installimiseks vajame juurilube sudo abil
  • 5. rida: see on ploki algus, kus me määrame oma skriptide õigused nii, et need oleksid käivitatavad.
  • 10. rida: see on ploki algus, kus me täpsustame skriptid, mida tuleb esmalt käivitada CI keskkonna seadistamiseks, enne kui saame käivitada skripte, mis teevad tegelikku juurutamist.
  • 13. rida: see on ploki algus, kus määratleme skriptid, mis käivitatakse juurutamisülesannete täitmiseks.

3. samm: saladuste haldamine

Me ei soovi oma AWS-i saladusi avalikus hoidlas selge tekstina hoida; see oleks äärmiselt halb infoturbe tava. Travis pakub hõlpsalt CLI-tööriista, mida saab kasutada teie saladuste hoidmiseks. Travis genereerib iga uue konto jaoks uue avaliku \ privaatvõtmepaari ja need saladused krüpteeritakse seda võtmepaari kasutades ning süstitakse keskkonnamuutujatena iga kord, kui ehitamine käivitatakse. Selle seadistamiseks käivitage hoidla juurtes järgmised käsud ja logige sisse soovitud andmeid kasutades:

$ sudo gem install travis
$ travis sisselogimine --org

Meie hoidla ehitamiskriptide kataloogis on kaks eellaaditud skripti, mis on valmis teie saladuste sisestamiseks. Kopeerige kataloog build_scripts meie k8s-juhendaja hoidla kohalikust koopiast omaenda k8s-ci hoidlasse ja värskendage neid järgmiselt:

  • large-secrets.txt: lisage oma Kubernetes'i pääsuklahvid. Need leiate kataloogist ~ / .kube / config
  • setup-secrets.sh: lisage oma Kubernetes'i parool (taas leidub kataloogis ~ / .kube / config) ja AWS-i pääsuklahvid kataloogist ~ / .aws / mandaat

Seejärel käivitage oma hoidla juurest skript setup-secrets.sh, kasutades järgmist käsku:

$ chmod 755 build-scripts / setup-secrets.sh
$ ./build-scripts/setup-secrets.sh

Pange tähele käsku openssl, mille skript setup-secrets.sh naaseb hilisemaks, kuna me vajame seda saladuste dekrüpteerimiseks.

See skript krüpteerib teie saladused Travise abil ja värskendab teie .travis.yml faili. Andke krüptitud saladused oma hoidlasse:

$ git add build-scripts / large-secrets.txt.enc .travis.yml
$ git activ -m "Krüptitud saladuste sisestamine"

Nüüd on teie saladused Travises turvatud, soovitame tungivalt eemaldada need kõigist failidest ja skriptidest. See võib olla ülilihtne, kui juhib saladusi juhuslikult allikakontrollile. Selles patus on süüdi ka teie autorid! Juhuslike saladuste toimepanemiseks püüame kasutada saladusi. Selle seadistamiseks tehke järgmist.

$ brew installib git-saladused
$ git-secrets - install

4. samm: installige sõltuvused

Kuna TravisCI juhib iga ehitust puhtasse Dockeri konteinerisse, peame oma sõltuvused iga kord installima. Need sõltuvused on samad, mille kirjeldasime selle postituse jaotises „Enne alustamist”. Looge kaustas build-scripts fail install-dependencies.sh ja kleepige sinna järgmine konfiguratsioon:

Nüüd pange see fail oma hoidlasse:

$ git add install-dependencies.sh
$ git activ -m "Skripti lisamine sõltuvuste installimiseks"

5. samm: sisestage meie saladused

Nüüd vajame Dockeri konteineris oma saladuste seadistamiseks skripti, milles teeme ka oma ehitusetapid. Looge kaustas build-scripts fail, mille nimi on inject-secrets.sh. Kleepige allolev skript ja värskendage seda järgmiselt:

  • Asendage {Teie klastri URL siin} oma Kubernetes'i klastri URL-iga
  • Asendage see käsu OpenSSL käsk, mille me selle jaotise 3. etapis tegime, märkusega {Teie käsk openssl krüptimissaladuste etapist siin}, lisades ./build-scripts/ enne suurt-secrets.txt.enc
  • Asendage {your-aws-region} kasutatava AWS-i piirkonnaga

See skript eemaldab meie saladused Travise keskkonnast, dekrüpteerib need ja süstib nad vastavatesse konfiguratsioonifailidesse.

Ülaltoodud skriptis märkad, et see viitab failile build-scripts kataloogis nimega kubeconfig - ka meie peame selle looma. Kleepige allolev sisu, vahetades muutuja {Teie klastri URL siin} välja oma Kubernetes'i klastri URL-iga.

Pange mõlemad failid oma hoidlasse:

$ git add inject-secrets.sh kubeconfig
$ git activ -m "Skripti lisamine saladuste ja kubeconfig-faili sisestamiseks"

6. samm: keskkonna seadistamine

Enne kui oleme rakenduste kasutuselevõtmiseks valmis, peame klastri ette valmistama, juurutades kube2iam ja external-dns konfiguratsiooni. Kõigi nende tööriistade konfiguratsiooni tuleb rakendada kindlas järjekorras:

  • Rakendage Terraformi konfiguratsioon, et luua uus AWS IAM-roll (ja sellele rollile nõutavad poliitikatoetused) ning usalduslik seos AWS IAM-i rolliga, mida sõlmed haldavad. Usaldussuhe võimaldab sõlmel võtta endale uus IAM-i roll.
  • Teenusekonto loomiseks rakendage Kubernetes RBAC-i konfiguratsiooni, segage see nõutavate lubade ulatusega ja andke sellele teenuskontole vajalikud õigused. Seejärel täpsustatakse see teenusekonto osana nende konfiguratsiooni osadest, mis pakuvad kõiki konkreetseid teenuseid.
  • Teenuste juurutamiseks rakendage Kubernetes'i konfiguratsioone. Sõltuvalt kasutatavast teenusest võib see olla Kubernetesi juurutamine või DaemonSet.

Ehitame oma juurutusskripti nii, et klaster konfigureeritakse alati kõigepealt.

Kopeerige kaustad, mis sisaldavad välinete-dns ja kube2iam malle, meie hoidlast teie hoidlasse.

Esiteks loome skripti, mis rakendab meie Terraformi konfiguratsiooni. Looge kataloogis build-scripts fail nimega deploy-terraform.sh ja lisage sellele järgmine kood:

See skript läbib meie hoidla kataloogistruktuuri ja rakendab kõik leitavad Terraformi konfiguratsioonifailid.

(NB! Reaalses tootmiskeskkonnas lisaksime oma CI torustikku kontrollid, et Terraformi ei kasutataks pahatahtlikult)

Pange see oma hoidlasse:

$ git add deploy-terraform.sh
$ gititte -m "Terraformi juurutusskripti lisamine"

Nüüd oleme valmis värskendama ja andma hoidlale meie kõigi 3 teenuse Terraformi konfiguratsiooni:

  • Värskendage external_dns / pod-role-trust-policy.json ja asendage {your-node-iam-role-arn} oma klastri Kubernetes-sõlmede IAM ARN-iga. Selle leiate järgmise käsu käivitamisel:
$ aws iam list-rolle | grepi sõlm
  • Värskendage external_dns / main.tf, et asendada {your-aws-region} AWS-i piirkonnaga, milles töötate, ja {your-tf-bucket} selle ämbri nimega, mille valisite Terraformi osariigi poe pidamiseks.

Pange teenuse konfiguratsioon oma hoidlasse:

$ git add external_dns / pod-role-trust-policy.json external_dns / external-dns-iam-setup.tf external_dns / external-dns-role-rights.json external_dns / main.tf
$ git activ -m "Klastri Terraformi teenuse konfiguratsiooni lisamine"

Travis on konfigureeritud nii, et see rakendaks konfigureerimist igal tõukimisel kaptenil, nii et kui teostame tõuke kohe:

$ git push

Peaksime nägema, et kogu meie Terraformi konfiguratsioon rakendub meie AWS-i kontole töölogis.

Oleme nüüd loonud kõik IAM-i rollid ja usalduslikud suhted, mida meie Kubernetese keskkond vajab.

Järgmisena vajame skripti, et rakendada meie Kubernetes'i konfiguratsioone meie keskkonna eeltingimuste jaoks. Selle sammu lõpuleviimiseks peate oma hoidlasse kopeerima ja värskendama järgmised failid meie hoidlast:

  • external_dns / external_dns.yaml: asendage {teie-dns-tsoon} kasutatava DNS-tsooniga, {teie-identifikaator} millegagi, mis eristab DNS-kirjeid, mida väline dns loob (nt teie nimi), ja {teie -external-dns-iam-role-arn} koos IAM ARN-iga rolli jaoks, mis loodi Terraformi konfiguratsiooni rakendamisel. Selle leiate järgmise käsu käivitamisel:
$ aws iam get-role --role-name external_dns_pod_role
  • kube2iam ja rbac /: värskendusi pole vaja

Need värskendused täpsustavad, millist IAM-i rolli peaksid kõik podid võtma, kui nad peavad AWS-i API-le juurde pääsema.

Nüüd pange need failid hoidlasse:

$ git add external_dns / external_dns.yaml rbac / kube2iam /
$ gititte -m "Väliste-dns k8s-seadistuste lisamine"

Nüüd hakkame oma Kubernetesi teenuste jaoks kasutuselevõtu skripti ehitama. Looge kaustas build-scripts fail nimega deploy-k8s.sh. Alustage faili sellise päisega:

Järgmisena lisage klastrisse järgmised Kubernetes RBAC-i konfiguratsiooni juurutavad sammud:

Neid samme on vaja, kuna väline dns-teenus vajab klastri käitamiseks ja teenuse osutamiseks Kubernetes API õigusi. Meeldetuletuseks: RBAC tagab, et poodidel pole vaikimisi juurdepääsu Kubernetes API-le. See on kooskõlas „vähima privileegi põhimõttega” ja hoiab ära kaustade võimaluse klastri sätteid muuta, kui neid mingil põhjusel kahjustatakse.

Et TravisCI saaks neid muudatusi rakendada, peame oma .travis.yml lisama täiendava sammu deploy-k8s.sh käivitamiseks. Lisage enne jaotist_installi järgmine teave:

- chmod + x ./build-scripts/deploy-k8s.sh

Ja skripti järgmine: jaotis:

- “./build-scripts/deploy-k8s.sh”

Nüüd looge deploy-k8s.sh, .travis.yml ja lükake oma hoidla kaptenile ja veenduge, et Travise ehitamise logis pole vigu:

$ git add build-scripts / deploy-k8s.sh .travis.yml
$ gititte -m "Travise konfiguratsiooni lisamine K8 konfiguratsiooni juurutamiseks"
$ git push

Nüüd, kui meie CI / CD torustikku on lisatud Terraformi ja RBAC-i konfiguratsioon, lisageme samme kube2iami juurutamiseks meie skripti deploy-k8s.sh:

Kube2iam võetakse kasutusele kõigepealt, kuna väline dns helistab AWS API-le, kasutades maaklerina kube2iam.

Nüüd lükake oma hoidla kaptenile ja veenduge, et ehitamislogis pole vigu:

$ git add build-scripts / deploy-k8s.sh
$ git activ -m "Travise konfiguratsiooni värskendamine k8s configi juurutamiseks"
$ git push

Vaatame nüüd meie klastrit, et veenduda, kas kõik teenused on õigesti juurutatud. external-dns on juurutamine, nii et selle oleku saamiseks saame käivitada järgmise käsu:

$ kubectl hangib juurutusi --namespace = kube-system

Kui kõik on õigesti kasutusele võetud, peaksime nägema järgmist:

NIMI SOOVITAB KÄESOLEVAT AJAKOHAST SAADAVAT VANUST
calico-kube-kontrollerid 1 1 1 1 1h
kalikopoliitika-kontroller 0 0 0 0 1h
dns-kontroller 1 1 1 1 1h
väline-dns 1 1 1 1 1m
kube-dns 2 2 2 2 1h
kube-dns-autoscaler 1 1 1 1 1h

kube2iam võetakse kasutusele kui DaemonSet, kuna AWS API kõnede vahendamiseks peab see töötama kõigis sõlmedes. Selle oleku saamiseks käivitame järgmise käsu:

$ kubectl saada ds --namespace = kube-system

Kui kõik on hästi, peaksime nägema midagi sellist:

NIMI SOOVITAB KÄESOLEVA VALMIS AJAKOHASELT SAADAVAL NUDE-VALIKU VANUS
kaliosõlm 6 6 6 6 6  1h
kube2iam 3 3 3 3 3  7m

7. samm: juurutage testrakendus

Nüüd on aeg kasutada ära meie klastri seadistamise raske töö eelised ja vaadata meie töövoo ja infrastruktuuri kui koodi võimsust testirakenduse hõlpsaks juurutamiseks!

Esiteks peame oma skriptidele deploy-k8s.sh lisama juurutamisetapi, mis juurutab meie rakendused:

See samm rakendab klastrisse kõik meie hoidla rakenduste kataloogis olevad Kubernetes'i konfiguratsioonifailid. Kinnitage see muudatus ja püüdke juhtida:

$ git add build-scripts / deploy-k8s.sh
$ git activ -m "Travise konfiguratsiooni värskendamine rakenduste jaoks k8s-i konfiguratsiooni juurutamiseks"
$ git push

Kui alustame oma teekonda GitOpsi poole, siis jälgigem GitOps-i protsessivoogu testrakenduse juurutamiseks:

  • Kohaliku haru loomiseks käivitage järgmine käsk:
$ git kassasse -b testapp
  • Loo oma hoidlas kaust nimega apps
  • Looge rakenduste kaustas fail, mille nimi on hello_app_deployment.yaml, ja lisage sellele järgmine teave:

Sellel konfiguratsioonil on 2 sektsiooni:

  1. Juurutamine: see täpsustab selle konteineri üksikasjad, mida me käivitame, ressursid selle eraldamiseks, millisesse pordi rakendusse konteineri sees pääseb, ja selle rakenduse koopiate arv, mida me tahame käivitada. Sel juhul hakkame käivitama lihtsa konteineri, millele prinditakse “Tervitused, maailm!” Ja seejärel konteineri hostinimi pordile 8080. Täpsustame, et käitame 3 koopiat - üks iga meie klastri sõlme kohta.
  2. Teenus: see täpsustab, kuidas juurutamine peaks olema nähtav kas sisemiselt või väljastpoolt. Meie testrakenduse puhul paljastame selle sisemiselt klastri IP-l pordil 80. Täpsustame ka sõbraliku FQDN-i (nt midagi sellist nagu saluations.yourdomain.com), millele meie rakendusele pääseb siin. Peate asendama {teie FQDN siin} sõbraliku FQDN-iga.

Nüüd pange see fail oma kohaliku haru juurde ja lükake haru serverihoidlasse:

$ git lisada hello_app_deployment.yaml
$ git activ -m "Testirakenduse lisamine"
$ git push -u päritolu testapp

Kui logime sisse GitHubisse, peaksime nüüd nägema, et meil on uus haru nimega “testapp”:

Soovime tõsta päringutaotlust ja ühendada kapteniks, nii et klõpsake nuppu „Võrdle ja tõmba taotlust” ja järgige toimingut selle toimingu lõpuleviimiseks.

Kui juurutamine on lõpule jõudnud, saame kontrollida, kas meie testrakendus on õigesti juurutatud, käivitades alltoodud käsud ja kontrollides sarnaseid väljundeid:

$ kubectl saab kasutuselevõtu tervitused-kasutuselevõtu
NIMI SOOVITAB KÄESOLEVA KÄPSEVA AVALIKU VANUSE
tervitus-kasutuselevõtt 3 3 3 3 24d
$ kubectl saavad teenused tervitusteenused
NIMETUS KLASTER-IP VÄLIS-IP-SADAMA (V) VANUS
tervitusteenus 100.65.66.9 a78b874f74ed0 ... 80: 32439 / TCP 6d

Tõeline tõestus on siiski ühenduse loomine meie rakendusega, kasutades meie sõbralikku FQDN-i! Kui kõik on õigesti juurutatud, peaksite nägema midagi sellist:

Edu! Kui värskendate seda lehte nüüd, peaksite hostinime muutust nägema, kui teie brauser pääseb klassikalise koormuse tasakaalustaja kaudu rakendusele, mis töötab teises Kubernetes'i sõlmes.

Kokkuvõte

Seda õpetust kasutades oleme ehitanud Kubernetes'i klastri, millel on palju turbevaikeid, ja mässinud selle ümber lihtsa CI / CD torujuhtme. Seejärel täpsustasime koodina Infrastruktuuri kaudu, kuidas soovisime lihtsa konteineris oleva rakenduse juurutamist ning kasutasime CI / CD torujuhet ja Kubernetes'i klastrit selle määratlemiseks - automaatselt.

See on vaid lihtne näide rikkalike eeliste kohta, mida Kubernetes teie arendajatele ja teie DevOps võimetele võib tuua, kui need on lisatud teie tööriistaketile!