Sådan oprettes en sikker Kubernetes-klynge som standard med en grundlæggende CI / CD-rørledning på AWS

Skrevet af Matthew Sheppard & Donald Carnegie

Kuber-hvad-es?

Kubernetes (udtalt “koo-burr-NET-eez”) er en open source platform til at automatisere distribution, skalering og drift af applikationscontainere. De seje børn refererer ofte til det ved den (IOHO) ikke særlig gode forkortelse “k8s”. Kubernetes 'job er at gøre den mest effektive brug af din infrastruktur, samtidig med at du sikrer, at dine containervirkninger er tilgængelige og kan skaleres efter behov. Nogle virksomheder har rapporteret, at de kunne reducere deres cloud-infrastrukturomkostninger med mellem 50% og 70% sammenlignet med at køre på traditionel VM-baseret arkitektur.

Indeholder (erise) din succes

Kubernetes er en massiv succeshistorie for Cloud Native Computing Foundation og open source-samfundet bag det. Først annonceret i midten af ​​2014 som et lille projekt ledet af et team af Google-ingeniører, er det vokset til at være de facto containerorkestreringsplatform og en vare på tværs af det offentlige skyøkosystem. Microsoft, Google, Amazon og IBM har alle et administreret Kubernetes-tilbud af en eller anden form. Med hensyn til bidragydere og hastighed er Kubernetes kun nummer to i open source-projekter til Linux Kernel. Det bruges i skala til mange seje arbejdsbelastninger, fra at tænke Pokemon Go til at sikre, at HBO GO-abonnenter glat kan strømme af Game of Thrones sæson 7.

Kontinuerlig Kubernetes

Som brugere og ingeniører af moderne webapplikationer forventer vi, at de er tilgængelige 24 timer i døgnet, 7 dage om ugen, og at de kan implementere nye versioner af dem mange gange om dagen. Kubernetes i sig selv er ikke nok til at nå dette mål. Det sikrer, at vores containeret applikationer kører, når og hvor vi ønsker, og kan finde de værktøjer og ressourcer, de har brug for. For fuldt ud at styrke vores ingeniører er vi imidlertid nødt til at bygge en CI / CD-rørledning omkring Kubernetes.

GitOps er et udtryk, som Weaveworks har opfundet for at beskrive anvendelse af Git som den erklærende sandhedskilde for Kubernetes-klyngestaten. Git bliver vores middel til at spore systemtilstand, og vi bruger konstruktioner inden for git, såsom pull-anmodninger, som et middel til at flette staten, der holdes i git, med state of cloud-infrastruktur. I en nøddeskal resulterer godkendte pull-anmodninger i live ændringer i produktionen. Dette er en virkelig kraftig tilgang, da en velprøvet kildekode-arbejdsgang kan anvendes til at administrere infrastruktur - at gribe den fuldt ud kan befri os for gamle skolers bureaukratiske ændringskontrolprocesser, der er komplicerede, tager for lang tid og mangler ansvarlighed. De ændringer, der er vedtaget på din infrastruktur, er altid 100% synlige, sporbare og ansvarlige. Historien opbevares evigt i git-depotet, og rullende tilbage til ethvert punkt i historien er et stykke kage.

Hvorfor skal jeg bruge Kubernetes?

Containere er allerede en enorm succeshistorie inden for cloud computing. På trods af den relativt korte periode, de har været i vores værktøjskasse, er de blevet en hæfteklamme i moderne cloud computing og er gearet af mange husholdningsapps. Imidlertid kan byrden ved orkestrering, styring og vedligeholdelse af containeret systemer være enorme - det er her Kubernetes kommer ind. Kubernetes tager alle de store styrker bag containerisering og giver en platform til at implementere og styre dem med større lethed.

Kubernetes er en aktiveringsenhed til DevOps; det hjælper med at implementere nøgle DevOps-praksis og baner vejen for organisationer at implementere DevOps. Uanset hvor du installerer det, uanset om det er på din bærbare computer, en skyudbyder eller et on-site-datacenter, giver det automatiserede implementeringer af dine containerbaserede applikationer med fuldt konsistente miljøer. Med Kubernetes er væk dage med at bygge og med succes test lokalt, kun for at finde din applikation opfører sig forskelligt i test- eller produktionsmiljøer!

YATR? (Endnu en selvstudie, virkelig?)

Der er masser af Kubernetes-tutorials derude, så hvorfor skrive en anden? Godt spørgsmål! Når vi bygger Kubernetes-klynger til vores egen sjov og for klienter, har vi ikke fundet en tutorial, der samler alle de brikker, der er nødvendige for at opsætte en klynge på AWS, der kan gøres klar til produktion. Dokumentationen er for det meste der, men det er en skattejagt at spore den op og finde ud af, hvordan man får den til at fungere i hver enkelt situation. Dette gør det særligt udfordrende for alle, der går i gang med deres første Kubernetes-pilot eller træder op fra en lokal minikube-klynge.

Formålet med denne tutorial er at lukke dette hul og gå gennem opsætningen af ​​Kubernetes-klyngen, der:

  • Er meget tilgængelig: Vi vil sikre, at vores miljøer kan håndtere fiasko, og at vores applikationer med containere fortsætter med at køre, hvis nogle af vores knudepunkter mislykkes, eller en AWS-tilgængelighedszone oplever et driftsfald. For at opnå dette, kører vi Kubernetes mestre og noder på tværs af 3 AWS tilgængelighedszoner.
  • Håndhæver "princip om mindst privilegium": Som standard skal alle pods køre i en restriktiv sikkerhedskontekst; de skal ikke have evnen til at foretage ændringer i Kubernetes-klyngen eller det underliggende AWS-miljø. Enhver pod, der skal foretage ændringer i Kubernetes-klyngen, skal bruge en navngivet servicekonto med den relevante rolle og politikker knyttet. Hvis en pod har brug for at foretage opkald til AWS API, skal opkaldene være mæglet for at sikre, at pod har tilstrækkelig tilladelse til at foretage dem og kun bruge midlertidige IAM-legitimationsoplysninger. Vi opnår dette ved at bruge Kubernetes rollebaseret adgangskontrol (RBAC) for at sikre, at pods som standard kører uden mulighed for at ændre klyngekonfigurationen. Hvor specifikke klyngtjenester har brug for tilladelser, opretter vi en bestemt servicekonto og binder den til et krævet tilladelsesomfang (dvs. klynge bredt eller i kun et navneområde) og giver de nødvendige tilladelser til den servicekonto. Adgang til AWS API vil blive mæglet gennem kube2iam; al trafik fra pods bestemt til AWS API omdirigeres til kube2iam. Baseret på annotationer i podkonfigurationer foretager kube2iam et opkald til AWS API for at hente midlertidige legitimationsoplysninger, der matcher den specificerede rolle i annotationen og returnere disse til den, der ringer. Alle andre AWS API-opkald vil blive proxyeret gennem kube2iam for at sikre, at princippet om mindsteprivilegium håndhæves, og at politik ikke kan omgås.
  • Integrerer med Route53 og Classic Load Balancers: Når vi implementerer en applikation, ønsker vi evnen til at erklære i konfigurationen, hvordan det gøres tilgængeligt for verden, og hvor det kan findes, og have dette automatiseret til os. Kubernetes leverer automatisk en Classic Load Balancer til en applikation, og ekstern-dns giver os mulighed for at tildele det et venligt fuldt kvalificeret domænenavn (FQDN), alt gennem infrastruktur som kode.
  • Har en grundlæggende CI / CD-rørledning pakket rundt om det: Vi vil automatisere den måde, hvorpå vi foretager ændringer i klyngen, og hvordan vi implementerer / opdaterer applikationer. Konfigurationsfilerne, der specificerer vores klyngekonfiguration, forpligtes til et Git-arkiv, og CI / CD-rørledningen anvender dem på klyngen. For at opnå dette bruger vi Travis-CI til at anvende den konfiguration, der bliver forpligtet i vores hovedgren, til Kubernetes-klyngen. Dette er et første skridt i retning af GitOps, men det giver os ikke en fuld GitOps-funktion.

I slutningen af ​​selvstudiet ender vi med en Kubernetes-klynge, der ser sådan ud:

Vores slutstat Kubernetes-klynge

Før du kommer i gang

Vi antager, at du allerede har en vis fortrolighed med Kubernetes. Hvis du er helt ny med Kubernetes, anbefales det, at du gennemgår Kubernetes Basics-tutorial og lære dig at kende dens nøglekoncepter.

For at opbygge vores klynge skal vi sørge for, at vi har følgende værktøjer installeret:

  • kubectl
    kubectl (Kubernetes Control) er et kommandolinjeværktøj til at interagere med en Kubernetes-klynge, der enten kører lokalt på din maskine (ved hjælp af minikube) eller i skyen.
  • Kops
    Kubernetes Operations (kops) -projektet giver værktøj til bygning og drift af Kubernetes-klynger i skyen. Det understøtter i øjeblikket Google Cloud & AWS (med andre udbydere i beta). Vi bruger kops til at oprette og administrere vores klynge i denne tutorial.
  • terraform
    Terraform er et infrastruktur som kode (IAC) værktøj, der giver brugerne mulighed for at definere infrastruktur på et højt niveau konfigurationssprog, som derefter kan bruges til at opbygge infrastruktur i en tjenesteudbyder som AWS eller Google Cloud Platform. Vi bruger Terraform til at oprette vores forudsætninger for kops og til at ændre IAM-politikkerne oprettet af kops.
  • AWS CLI
    AWS CLI er et kommandolinjeværktøj til interaktion med AWS. Dette kræves af kops & Terraform for at udføre operationer på AWS.

Installationsinstruktioner findes på de medfølgende links.

Denne tutorial blev oprettet ved hjælp af Kubernetes v1.8 og kops v1.8.1.

Vi kører Mac OS X med Homebrew, så alt, hvad vi skal gøre, er at køre følgende kommandoer for at få disse installeret:

$ bryggeopdatering
$ bryg install kubectl
$ bryg installationskops
$ bryg installere python3
$ easy_install pip
$ pip installere awscli - opgradering - bruger
$ eksport PATH = ~ / .lokal / bin: $ PATH
$ bryg installer terraform

Opret klyngen

Trin 1: Klon vores lager

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

Trin 2: Indstil en FQDN, der vil blive brugt til klyngen i Rute53

Kubernetes-klyngen, som vi opretter, bruger en FQDN, der er vært i Rute53, til at afsløre servicens endepunkter og API-kontrolplanet. Du kan registrere en ny FQDN eller overføre en eksisterende FQDN. AWS har et komplet skridt igennem for hver af disse muligheder:

Trin 3: Opret de nødvendige forudsætninger for kops

For kops til at opbygge klyngen, har den brug for en S3-butik for at have klyngekonfigurationen og en IAM-brugerkonto, der har følgende politikker knyttet til den:

AmazonEC2FullAccess
AmazonRoute53FullAccess
AmazonS3FullAccess
IAMFullAccess
AmazonVPCFullAccess

prereqs / kops_pre_reqs.tf opretter dette til dig. Det vil også oprette en S3-spand, der vil blive brugt som en fjernlager til vores Terraform-tilstand. Dette giver flere brugere mulighed for at arbejde med et sæt infrastruktur som kode uden at forårsage konflikter. Du skal opdatere filen for at erstatte {my_bucket_name} og {my_tf_bucket_name} med dit valgte spandnavn.

Kør derefter følgende kommandoer:

Forudsætninger for $ cd
$ terraform init
$ terraform plan
$ terraform gælder

Hvis du logger ind på din AWS-konto, vil du nu se en nyligt oprettet kops IAM-bruger, en S3-spand til kops-statuslageret og en anden S3-spand til Terraform-statuslageret

Trin 4: Brug kops til at stå klyngen op

I det forrige trin oprettede vi en IAM-konto for kops. Nu skal vi konfigurere vores AWS CLI-klient til at bruge denne konto. Vi kan få fat i kops IAM ID og hemmelig nøgle fra filen Terraform bruger til at gemme tilstanden for, hvad den har oprettet i det forrige trin. Åbn terraform.tfstate i din teksteditor og kig efter det afsnit, der ligner nedenstående:

Skriv en værdi i felterne {iam_id} og {aws_secret_key}, og kør følgende kommando:

$ aws konfigurering - profil kops
AWS Access Key ID [Ingen]: {iam_id}
AWS Secret Access Key [None]: {aws_secret_key}
Standardregionnavn [Ingen]: {your_chosen_aws_region}
Standard outputformat [Ingen]: tekst

Derefter skal vi indstille et par miljøvariabler, så kops ved, hvilken AWS IAM-konto, der skal bruges, og hvor den skal placere sin statslager:

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

Nu til hovedbegivenheden - lad os bruge kops til at opbygge vores klynge. Kør følgende kommando ved at erstatte din AWS-region, din DNS-zone og dit valgte klyngenavn:

$ kops opretter klynge --cloud aws \
 - bastion \
 - nodetælling 3 \
 - nodestørrelse t2.medium \
 - master-størrelse t2.medium \
 - zoner {your_chosen_aws_region} a, {your_chosen_aws_region} b, {your_chosen_aws_region} c \
 - master-zoner {your_chosen_aws_region} a, {your_chosen_aws_region} b, {your_chosen_aws_region} c \
 --dns-zone {din_dns_zone} \
 - topologi privat \
 - netværk calico \
 - autorisation RBAC \
 - navn {your_cluster_name} \
 --out = k8s \
 - mål = terraform - ja

Denne kommando fortæller kops, at vi ønsker at opbygge en klynge, der:

  • Vil bruge AWS
  • Har en hovednode i størrelse t2.medium i hver af de specificerede tilgængelighedszoner
  • Har 3 arbejderknudepunkter i størrelse t2.medium. kops spreder arbejderknudene jævnt over hver tilgængelighedszone
  • Bruger en privat netværkstopologi, hvilket betyder, at alle noder har private IP-adresser og ikke er direkte tilgængelige fra det offentlige internet
  • Bruger Calico som en Container Network Interface til at erstatte kubenet som et resultat af kravene til den private netværkstopologi
  • Bruger RBAC til Kubernetes adgangstilladelser
  • Er beskrevet i en Terraform-konfigurationsfil, der skal skrives til det bibliotek, der er specificeret af --out

kops genererer et sæt Terraform-konfigurationsfiler i et nyoprettet k8s-bibliotek, der kan anvendes til at oprette klyngen. Inden vi bygger vores klynge, ønsker vi at tilføje en konfigurationsfil for at fortælle Terraform at beholde sin statuslager på S3-spanden, vi lige har oprettet.

$ cd k8s
$ terraform init
$ terraform plan
$ terraform gælder

Det tager mellem 10 og 15 minutter, før din klynge bliver tilgængelig. Du kan kontrollere klyngens status ved at køre følgende kommando:

$ kops validerer klynge

Når klyngen er færdig med at opbygge, skal du se et output som dette:

Brug af klynge fra kubectl-sammenhæng: cluster.zigzag-london.com
Validerer klyngeklynge.zigzag-london.com
INSTANSGRUPPER
NAVN ROLE MASKINETYPE MIN MAX SUBNETER
bastions Bastion t2.micro 1 1 utility-eu-west-1a, utility-eu-west-1b, utility-eu-west-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
knudepunkter Knude t2.medium 3 3 eu-west-1a, eu-west-1b, eu-west-1c
NODE STATUS
NAVN ROLE KLAR
ip-172-20-107-234.eu-west-1.compute.intern master True
ip-172-20-124-39.eu-west-1.compute.intern knude True
ip-172-20-44-152.eu-west-1.compute.intern master True
ip-172-20-60-188.eu-west-1.compute.intern knude True
ip-172-20-79-79.eu-west-1.compute.intern master True
ip-172-20-87-125.eu-west-1.compute.intern knude True
Din klyngeklynge.zigzag-london.com er klar

At stå op i et CI / CD-miljø

For at implementere GitOps har vi brug for et CI / CD-miljø til overvågning af vores lager og udførelse af opdateringer. Til denne tutorial vil vi konfigurere vores CI / CD-miljø til at udføre implementeringstrin på hvert skub til mastergrenen af ​​vores depot. Vi gør dette med henblik på at gøre det lettere at demonstrere; at lade udviklere gøre dette er bestemt dårlig praksis. I et ægte projekt vil vi anbefale en funktionsforgreningsstrategi med en kodegennemgang og et udviklingsledningsgodkendelsestrin.

Til denne tutorial bruger vi TravisCI, en skybaseret CI-service. TravisCI er gratis, så længe:

  • Du er vært for dit lager i Github
  • Depotet er offentligt tilgængeligt

Trin 1: Opsætning af konti og klonelager

  • Naviger til GitHub og tilmeld dig \ log ind
  • Opret et nyt, tomt arkiv, og navngiv det "k8s-ci"
  • Klon dette depot til din lokale maskine:
$ git klon 
  • Naviger til TravisCI, og tilmeld dig ved hjælp af din GitHub-konto. Naviger til din brugerprofil ved at klikke på dit navn øverst til højre.
  • Klik på skyderen mod GitHub-repo for at aktivere TravisCI til dette arkiv.

Trin 2: Setup Triggers

Da vi øver på GitOps, ønsker vi kun at implementere på en godkendt pull-anmodning. Vi kan konfigurere dette i Travis ved at klikke på Flere indstillinger → Indstillinger.

  • Sørg for, at "bygge skubede grene" er aktiveret
  • Sørg for, at "build push pull-anmodninger" er aktiveret

Travis får langt de fleste af sine instruktioner fra en yaml-fil, der er gemt i dit arkiv. Opret en tom fil med navnet .travis.yml i roden til dit arkiv, og vi kan begynde at konfigurere den baseret på .travis.yml i vores depot:

  • Linie 1: Angiver, at vi kun ønsker, at en build skal køre på mastergrenen. I et ægte miljø vil vi sandsynligvis også implementere på skubning af en gren, men til et testmiljø i modsætning til et produktionsmiljø. En måde dette kan gøres er ved at bruge miljøvariabler til at anvende betinget logik på implementeringsscriptet, men det er uden for anvendelsesområdet for dette indlæg.
  • Linie 4: Angiver, at vi kræver rodtilladelser ved hjælp af sudo for at installere vores afhængigheder
  • Linie 5: Dette er starten på blokken, hvor vi indstiller tilladelserne på hvert af vores scripts, så de er eksekverbare.
  • Linie 10: Dette er starten på blokken, hvor vi specificerer de scripts, der skal køres først for at opsætte CI-miljøet, før vi kan udføre de scripts, der udfører den aktuelle implementering.
  • Linie 13: Dette er starten på blokken, hvor vi specificerer de scripts, der vil køre for at udføre implementeringsopgaver.

Trin 3: Administrer hemmeligheder

Vi ønsker ikke at opbevare vores AWS-hemmeligheder i en offentlig oplagring i klar tekst; dette ville være ekstremt dårlig informationssikkerhedspraksis. Travis leverer Travis et CLI-værktøj, der kan bruges til at opbevare dine hemmeligheder, der skal injiceres på bygningstidspunktet. Travis genererer et nyt offentligt \ privat nøglepar for hver nye konto, og disse hemmeligheder bliver krypteret ved hjælp af dette tastatur og indsprøjtet som miljøvariabler hver gang bygningen kører. For at konfigurere dette skal du køre følgende kommandoer i roden til dit arkiv og logge ind ved hjælp af de anmodede detaljer:

$ sudo perle installere travis
$ travis login --org

Der er to forudindlæste scripts i biblioteket med build-scripts i vores depot, der er klar til at indtaste dine hemmeligheder. Kopier build_scripts-biblioteket fra din lokale kopi af vores k8s-tutorial-arkiv til dit eget k8s-ci-arkiv, og opdater dem som følger:

  • large-secrets.txt: Tilføj dine Kubernetes adgangstaster. Disse kan findes i ~ / .kube / config
  • setup-secrets.sh: Tilføj din Kubernetes adgangskode (igen fundet i ~ / .kube / config) og AWS adgangstaster fra ~ / .aws / legitimationsoplysninger

Kør derefter script-secrets.sh-scriptet fra roden til dit depot ved hjælp af følgende kommando:

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

Skriv en note af openssl-kommandoen, som scriptet setup-secrets.sh returnerer til senere, da vi har brug for dette for at dekryptere hemmelighederne.

Dette script vil kryptere dine hemmeligheder ved hjælp af Travis og opdatere din .travis.yml-fil. Forpligt de krypterede hemmeligheder til dit arkiv:

$ git tilføje build-scripts / large-secrets.txt.enc .travis.yml
$ git commit -m "Begå krypterede hemmeligheder"

Nu er dine hemmeligheder sikret i Travis, vi anbefaler på det kraftigste at fjerne dem fra alle filer og scripts. Det kan være super let at fejle hemmeligheder til kildekontrol, og dine forfattere er begge skyldige i denne synd! For at fange enhver utilsigtet forpligtelse af hemmeligheder bruger vi git-hemmeligheder. Du kan konfigurere det ved hjælp af følgende trin:

$ bryg installere git-hemmeligheder
$ git-hemmeligheder - installer

Trin 4: Installer afhængigheder

Når TravisCI kører hver bygning i en ren Docker-container, er vi nødt til at installere vores afhængigheder hver gang. Disse afhængigheder er de samme, som vi angav i afsnittet "Før du kommer i gang" i dette indlæg. Opret en fil kaldet install-dependences.sh i mappen build-scripts og indsæt følgende konfiguration i den:

Forbind nu denne fil til dit arkiv:

$ git tilføj install-afhængigheder.sh
$ git commit -m "Tilføjelse af script til installation af afhængigheder"

Trin 5: Injicér vores hemmeligheder

Nu har vi brug for et script til opsætning af vores hemmeligheder i Docker-containeren, som vi vil udføre vores build-trin i. Opret en fil med navnet inject-secrets.sh i mappen build-scripts. Indsæt scriptet herunder, og opdater det som følger:

  • Erstat {Din klynge-url her} med URL'en til din Kubernetes-klynge
  • Erstat OpenSSL-kommandoen, som vi noterede os i trin 3 i dette afsnit, med {Din openssl-kommando fra krypteringshemmelighedsfasen her} vedhæftning ./build-scripts/ før large-secrets.txt.enc
  • Erstat {your-aws-region} med den AWS-region, du bruger

Dette script trækker vores hemmeligheder fra Travis-miljøet, dekrypterer dem og injicerer dem i de relevante konfigurationsfiler.

Du vil bemærke i scriptet ovenfor, at det refererer til en fil i biblioteket med build-scripts med navnet kubeconfig - vi bliver også nødt til at oprette dette. Indsæt indholdet herunder og udskift variablen {Din klynge-url her} med URL'en til din Kubernetes-klynge.

Forbind begge disse filer til dit arkiv:

$ git tilføje inject-secrets.sh kubeconfig
$ git commit -m "Tilføjelse af script for at injicere hemmeligheder og kubeconfig-fil"

Trin 6: Miljøopsætning

Inden vi er klar til at implementere applikationer, er vi nødt til at forberede klyngen ved at implementere konfigurationen til kube2iam og eksterne-dns. Konfigurationen til hvert af disse værktøjer skal anvendes i en bestemt rækkefølge:

  • Anvend Terraform-konfiguration for at oprette en ny AWS IAM-rolle (og de krævede politiktilskud til den rolle) og en tillidsforhold tilbage til AWS IAM-rollen, som noder kører under. Tillidsforholdet giver en knude mulighed for at påtage sig den nye IAM-rolle.
  • Anvend Kubernetes RBAC-konfiguration for at oprette en servicekonto, binde den til et krævet tilladelsesomfang og give de krævede tilladelser til den servicekonto. Denne servicekonto specificeres derefter som en del af konfigurationen af ​​de pods, der leverer hver af de specifikke tjenester.
  • Anvend Kubernetes-konfigurationer til at implementere tjenesterne. Afhængig af den service, der bliver implementeret, kan dette være en Kubernetes-implementering eller DaemonSet.

Vi opbygger vores implementeringsscript, så klyngen altid konfigureres først.

Kopier over mapperne, der indeholder skabeloner til eksterne-dns og kube2iam fra vores depot til dit depot.

Først opretter vi et script, der bruger vores Terraform-konfiguration. Opret en fil kaldet deploy-terraform.sh i biblioteket med build-scripts og tilføj følgende kode til den:

Dette script gennemgår biblioteksstrukturen i vores lager og anvender alle Terraform-konfigurationsfiler, det finder.

(NB: I et ægte produktionsmiljø vil vi tilføje kontroller i vores CI-pipeline for at sikre, at Terraform ikke bruges ondsindet)

Overfør dette til dit arkiv:

$ git add deploy-terraform.sh
$ git commit -m "Tilføjelse af Terraform-implementeringsscript"

Nu er vi klar til at opdatere og forpligte Terraform-konfigurationen for hver af vores 3 tjenester til depotet:

  • Opdater eksterne_dns / pod-role-trust-policy.json og udskift {your-node-iam-role-arn} med IAM ARN for Kubernetes-noder i din klynge. Dette kan findes ved at køre følgende kommando:
$ aws iam liste-roller | grep-knude
  • Opdater eksterne_dns / main.tf for at erstatte {your-aws-region} med den AWS-region, du arbejder i, og {your-tf-bucket} med navnet på den spand, du valgte at have Terraform-statuslageret.

Forbind servicekonfigurationen til dit lager:

$ git tilføje eksterne_dns / pod-role-trust-policy.json eksterne_dns / eksterne-dns-iam-setup.tf eksterne_dns / eksterne-dns-rolle-rettigheder.json eksterne_dns / main.tf
$ git commit -m "Tilføjelse af klynge Terraform-servicekonfiguration"

Travis er konfigureret til at anvende konfiguration på hvert push-til-master, så hvis vi udfører et push nu:

$ git push

Vi skulle være i stand til at se al vores Terraform-konfiguration, der anvendes til vores AWS-konto i Jobloggen.

Vi har nu oprettet alle IAM-roller og tillidsforhold, som vores Kubernetes-miljø har brug for.

Dernæst har vi brug for et script til at anvende vores Kubernetes-konfigurationer til vores miljøforudsætninger. For at gennemføre dette trin skal du kopiere og opdatere følgende filer fra vores depot til dit depot:

  • eksterne_dns / eksterne_dns.yaml: Erstat {din-dns-zone} med den DNS-zone, du bruger, {din-identifikator} med noget, der adskiller de DNS-poster, som eksterne-dns vil producere (f.eks. dit navn), og {din -external-dns-iam-role-arn} med IAM ARN for den rolle, der blev oprettet, da Terraform-konfigurationen blev anvendt. Dette kan findes ved at køre følgende kommando:
$ aws iam get-role - rollenavn eksterne_dns_pod_role
  • kube2iam og rbac /: Ingen opdateringer kræves

Disse opdateringer specificerer, hvilken IAM-rolle hver af podene skal påtage sig, når de har brug for adgang til AWS API.

Forbind nu disse filer i depotet:

$ git tilføje eksterne_dns / eksterne_dns.yaml rbac / kube2iam /
$ git commit -m "Tilføjelse af eksterne-dns k8s config"

Nu skal vi begynde at opbygge vores implementeringsskript til vores Kubernetes-tjenester. Opret en fil med navnet deploy-k8s.sh i mappen build-scripts. Start filen med en overskrift som denne:

Derefter tilføjes nedenstående trin, der distribuerer Kubernetes RBAC-konfiguration til klyngen:

Disse trin er nødvendige, fordi ekstern-dns-tjenesten kræver Kubernetes API-rettigheder for at køre og levere sin service til klyngen. Som en påmindelse sikrer RBAC, at pods ikke har adgang til Kubernetes API som standard. Dette er i tråd med “princippet om mindst privilegium” og forhindrer, at bælg kan ændre klyngeindstillingerne, hvis de bliver kompromitteret af en eller anden grund.

For at få TravisCI til at anvende disse ændringer, er vi nødt til at tilføje et ekstra trin til vores .travis.yml for at udføre deploy-k8s.sh. Føj følgende til afsnittet before_install::

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

Og følgende i scriptet: sektion:

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

Foretag nu distribution-k8s.sh, .travis.yml og skub dit depot til at mestre og sikre, at der ikke er nogen fejl i Travis build-loggen:

$ git tilføje build-scripts / deploy-k8s.sh .travis.yml
$ git commit -m "Tilføjelse af Travis config til implementering af k8s config"
$ git push

Nu, hvor vi har tilføjet Terraform og RBAC-konfigurationen til vores CI / CD-pipeline, lad os tilføje trin til at distribuere kube2iam til vores deploy-k8s.sh-script:

kube2iam implementeres først, da eksterne-dns foretager opkald til AWS API ved hjælp af kube2iam som mægler.

Skub nu dit lager til at mestre og sikre dig, at der ikke er nogen fejl i buildloggen:

$ git tilføje build-scripts / deploy-k8s.sh
$ git commit -m "Opdatering af Travis config til implementering af k8s config"
$ git push

Lad os nu tjekke vores klynge for at sikre dig, at alle tjenester er implementeret korrekt. eksterne-dns er en Deployment, så vi kan udføre følgende kommando for at få dens status:

$ kubectl få implementeringer - navnspace = kube-system

Hvis alt er blevet implementeret korrekt, skal vi se noget som:

NAVN ØNSKET AKTUELT OP-TIL DATO TILGÆNGELIG Alder
calico-kube-controllere 1 1 1 1 1h
calico-policy-controller 0 0 0 0 1h
dns-controller 1 1 1 1 1h
ekstern-dns 1 1 1 1 1m
kube-dns 2 2 2 2 1h
kube-dns-autoscaler 1 1 1 1 1h

kube2iam er implementeret som DaemonSet, da det skal køres på alle noder for at mæglere opkald til AWS API. Vi kører følgende kommando for at få dens status:

$ kubectl få ds - namespace = kube-system

Hvis alt er i orden, skal vi se noget som:

NAVN ØNSKET AKTUELT KLAR OP-TIL DATO TILGÆNGELIG NODE-SELECTOR ALDER
calico-node 6 6 6 6 6  1 t
kube2iam 3 3 3 3 3  7m

Trin 7: Distribuer en testapplikation

Nu er det tid til at høste fordelene ved det hårde arbejde med at opsætte vores klynge og se kraften i vores arbejdsgang og infrastruktur som kode til let at implementere en testapplikation!

Først skal vi tilføje et implementeringstrin til vores deploy-k8s.sh script, der distribuerer vores applikationer:

Dette trin anvender alle Kubernetes-konfigurationsfiler i apps-biblioteket i vores depot på klyngen. Foretag denne ændring og tryk på for at mestre:

$ git tilføje build-scripts / deploy-k8s.sh
$ git commit -m "Opdatering af Travis-konfiguration til implementering af k8s-konfiguration til apps"
$ git push

Når vi begynder vores rejse mod GitOps, lad os følge en GitOps-processtrøm til implementering af en testapplikation:

  • Opret en lokal gren ved at køre følgende kommando:
$ git checkout -b testapp
  • Opret en mappe under kaldte apps i dit arkiv
  • Opret en fil kaldet hello_app_deployment.yaml i apps-mappen og tilføj følgende til den:

Denne konfiguration har 2 sektioner:

  1. Deployering: Dette specificerer detaljerne om den container, vi skal køre, mængden af ​​ressourcer, der skal gives den, hvilken port applikationen inde i containeren kan fås på og antallet af kopier af den applikation, vi vil køre. I dette tilfælde vil vi køre en simpel container, der udskriver "hilsener, kloden!" Og derefter værtsnavnet på beholderen til port 8080. Vi specificerer, at vi vil køre 3 replikker - en for hver af vores klynknoder.
  2. Service: Dette specificerer, hvordan implementeringen skal udsættes, enten internt eller eksternt. I tilfælde af vores testansøgning udsætter vi den internt på klyngen IP på port 80. Vi specificerer også det venlige FQDN (f.eks. Noget som saluations.yourdomain.com), som vores applikation kan få adgang til her. Du bliver nødt til at erstatte {din FQDN her} med din venlige FQDN.

Forbind nu denne fil til din lokale filial og skub filialen til fjernlageret:

$ git tilføj hello_app_deployment.yaml
$ git commit -m "Tilføjelse af testapp"
$ git push -u oprindelses testapp

Hvis vi logger ind på GitHub, skal vi nu se, at vi har en ny gren kaldet "testapp":

Vi ønsker at hæve en pull-anmodning og fusionere til master, så klik på “Sammenlign & pull-anmodning” og følg processen for at afslutte denne aktivitet.

Når installationen er afsluttet, kan vi bekræfte, at vores testapplikation er implementeret korrekt ved at køre nedenstående kommandoer og kontrollere for lignende output:

$ kubectl får distribution hilsningsdistribution
NAVN ØNSKET AKTUELT OP-TIL DATO TILGÆNGELIG Alder
hilsener-indsættelse 3 3 3 3 24d
$ kubectl få tjenester hilsener-service
NAVN CLUSTER-IP EXTERNAL-IP PORT (S) AGE
hilsen-service 100.65.66.9 a78b874f74ed0 ... 80: 32439 / TCP 6d

Det virkelige bevis er imidlertid at forbinde til vores applikation ved hjælp af vores venlige FQDN! Hvis alt er installeret korrekt, skal du se noget lignende:

Succes! Hvis du nu opdaterer denne side, skal du se, at værtsnavnet ændres, når din browser får adgang til appen, der kører på en anden Kubernetes-knude gennem Classic Load Balancer.

Resumé

Ved hjælp af denne tutorial har vi bygget en Kubernetes-klynge med et godt sæt sikkerhedsstandarder og derefter viklet en simpel CI / CD-rørledning omkring den. Derefter specificerede vi via Infrastructure som kode, hvordan vi ønskede, at en simpel containereret applikation skulle blive implementeret og brugt vores CI / CD-rørledning og Kubernetes-klynge til at implementere den som defineret - automatisk.

Dette er bare en simpel illustration af de rige fordele, Kubernetes kan give dine udviklere og dine DevOps-muligheder, når de er inkluderet som en del af din værktøjskæde!