Guide til Spring Cloud Kubernetes

1. Oversikt

Når vi bygger en mikroserviceløsning, er både Spring Cloud og Kubernetes optimale løsninger, da de gir komponenter for å løse de vanligste utfordringene. Men hvis vi bestemmer oss for å velge Kubernetes som den viktigste containeransvarlige og distribusjonsplattformen for løsningen vår, kan vi fortsatt bruke Spring Clouds interessante funksjoner hovedsakelig gjennom Spring Cloud Kubernetes-prosjektet.

Dette relativt nye prosjektet gir utvilsomt enkel integrasjon med Kubernetes for Spring Boot-applikasjoner. Før du starter, kan det være nyttig å se på hvordan du distribuerer en Spring Boot-applikasjon på Minikube, et lokalt Kubernetes-miljø.

I denne veiledningen vil vi:

  • Installer Minikube på vår lokale maskin
  • Utvikle et eksempel på mikrotjenestearkitektur med to uavhengige Spring Boot-applikasjoner som kommuniserer gjennom REST
  • Sett opp applikasjonen på en klyngeknute med Minikube
  • Distribuer applikasjonen ved hjelp av YAML konfigurasjonsfiler

2. Scenario

I vårt eksempel bruker vi scenariet med reisebyråer som tilbyr forskjellige tilbud til kunder som vil spørre om reisebyråtjenesten av og til. Vi bruker den til å demonstrere:

  • tjenesteoppdagelse gjennom Spring Cloud Kubernetes
  • konfigurasjonsstyring og injisere Kubernetes ConfigMaps og hemmeligheter til applikasjonsputer ved hjelp av Spring Cloud Kubernetes Config
  • lastbalansering ved hjelp av Spring Cloud Kubernetes Ribbon

3. Miljøoppsett

Først og fremst må vi installer Minikube på vår lokale maskin og helst en VM-driver som VirtualBox. Det anbefales også å se på Kubernetes og dets hovedfunksjoner før du følger dette miljøoppsettet.

La oss starte den lokale Kubernetes-klyngen med en enkelt node:

minikube start --vm-driver = virtualbox

Denne kommandoen oppretter en virtuell maskin som kjører en Minikube-klynge ved hjelp av VirtualBox-driveren. Standardkonteksten i kubectl vil nå være minikube. For å kunne veksle mellom sammenhenger bruker vi imidlertid:

kubectl config bruk-kontekst minikube

Etter å ha startet Minikube, kan vi koble til Kubernetes dashbord for å få tilgang til loggene og overvåke våre tjenester, pods, ConfigMaps og Secrets enkelt:

minikube dashbord 

3.1. Utplassering

For det første, la oss få eksemplet vårt fra GitHub.

På dette punktet kan vi enten kjøre "deployment-travel-client.sh" -skriptet fra den overordnede mappen, eller ellers utføre hver instruksjon en etter en for å få en god forståelse av prosedyren:

### bygg lageret mvn clean install ### set docker env eval $ (minikube docker-env) ### build the docker images on minikube cd reisebyrå-service docker build -t reisebyrå-service. cd ../client-service docker build -t client-service. cd .. ### hemmelig og mongodb kubectl slett -f reisebyrå-tjeneste / hemmelig.yaml kubectl slett -f reisebyrå-tjeneste / mongo-distribusjon.yaml kubectl opprett -f reisebyrå-tjeneste / hemmelig.yaml kubectl create -f reisebyrå-service / mongo-deployment.yaml ### reisebyrå-service kubectl delete -f reisebyrå-service / reisebyrå-deployment.yaml kubectl create -f reisebyrå-service / travel-agency-deployment.yaml ### client-service kubectl delete configmap client-service kubectl delete -f client-service / client-service-deployment.yaml kubectl create -f client-service / client-config.yaml kubectl create - f client-service / client-service-deployment.yaml # Kontroller at pods kjører kubectl get pods

4. Service Discovery

Dette prosjektet gir oss en implementering for ServiceDiscovery grensesnitt i Kubernetes. I et mikrotjenestemiljø er det vanligvis flere pods som kjører den samme tjenesten. Kubernetes avslører tjenesten som en samling sluttpunkter som kan hentes og nås fra en Spring Boot-applikasjon som kjører i en pod i samme Kubernetes-klynge.

For eksempel, i vårt eksempel, har vi flere kopier av reisebyråtjenesten, som er tilgjengelig fra vår klienttjeneste som // reisebyrå-tjeneste: 8080. Imidlertid vil dette internt oversettes til tilgang til forskjellige pods som reisebyrå-service-7c9cfff655-4hxnp.

Spring Cloud Kubernetes Ribbon bruker denne funksjonen til å laste balanse mellom de forskjellige endepunktene til en tjeneste.

Vi kan enkelt bruke Service Discovery ved å legge til vår-sky-starter-kubernetes avhengighet av klientapplikasjonen vår:

 org.springframework.cloud spring-cloud-starter-kubernetes 

Vi bør også legge til @EnableDiscoveryClient og injiser DiscoveryClient inn i det ClientController ved bruk av @Autowired i klassen vår:

@SpringBootApplication @EnableDiscoveryClient public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args); }}
@RestController offentlig klasse ClientController {@Autowired private DiscoveryClient discoveryClient; }

5. ConfigMaps

Typisk, mikrotjenester krever en slags konfigurasjonsadministrasjon. I Spring Cloud-applikasjoner vil vi for eksempel bruke en Spring Cloud Config Server.

Vi kan imidlertid oppnå dette ved å bruke ConfigMaps levert av Kubernetes - forutsatt at vi bare har tenkt å bruke den for ikke-sensitiv, ukryptert informasjon. Alternativt, hvis informasjonen vi vil dele er sensitiv, bør vi velge å bruke hemmeligheter i stedet.

I vårt eksempel bruker vi ConfigMaps på kundeservice Spring Boot-applikasjon. La oss lage en klientkonfigurasjon.yaml-fil for å definere ConfigMap for kundeservice:

apiVersion: v1 by d kind: ConfigMap metadata: name: client-service data: application.properties: | - bean.message = Testing reload! Melding fra backend er:% s

Tjenester:% s

Det er viktig at navnet på ConfigMap samsvarer med navnet på applikasjonen som spesifisert i filen "application.properties". I dette tilfellet er det kundeservice. Deretter bør vi lage ConfigMap for kundeservice på Kubernetes:

kubectl create -f client-config.yaml

La oss nå lage en konfigurasjonsklasse ClientConfig med @Konfigurasjon og @ConfigurationProperties og injiser i ClientController:

@Configuration @ConfigurationProperties (prefix = "bean") public class ClientConfig {private String message = "Melding fra backend er:% s

Tjenester:% s "; // getters and setters}

@RestController offentlig klasse ClientController {@Autowired private ClientConfig config; @GetMapping offentlig strengbelastning () {return String.format (config.getMessage (), "", ""); }}

Hvis vi ikke spesifiserer et ConfigMap, bør vi forvente å se standardmeldingen, som er angitt i klassen. Når vi oppretter ConfigMap, blir denne standardmeldingen imidlertid overstyrt av den egenskapen.

I tillegg endres meldingen på siden tilsvarende hver gang vi bestemmer oss for å oppdatere ConfigMap:

kubectl rediger configmap klienttjeneste

6. Hemmeligheter

La oss se på hvordan hemmeligheter fungerer ved å se på spesifikasjonen av MongoDB-tilkoblingsinnstillinger i vårt eksempel. Vi skal lage miljøvariabler på Kubernetes, som deretter blir injisert i Spring Boot-applikasjonen.

6.1. Lag en hemmelighet

Det første trinnet er å lage en hemmelig.yaml fil, koding av brukernavn og passord til Base 64:

apiVersion: v1 type: Secret metadata: name: db-secret data: brukernavn: dXNlcg == passord: cDQ1NXcwcmQ =

La oss bruke den hemmelige konfigurasjonen på Kubernetes-klyngen:

kubectl gjelder -f secret.yaml

6.2. Opprett en MongoDB-tjeneste

Vi bør nå opprette MongoDB-tjenesten og distribusjonen reisebyrå-distribusjon.yaml fil. Spesielt i distribusjonsdelen bruker vi hemmeligheten brukernavn og passord som vi definerte tidligere:

apiVersion: utvidelser / v1beta1 type: Implementering metadata: navn: mongo spec: replikaer: 1 mal: metadata: labels: service: mongo name: mongodb-service spec: containere: - args: - mongod - - smallfiles image: mongo: siste navn: mongo env: - navn: MONGO_INITDB_ROOT_USERNAME verdiFra: secretKeyRef: navn: db-hemmelig nøkkel: brukernavn - navn: MONGO_INITDB_ROOT_PASSWORD verdiFra: secretKeyRef: navn: db-hemmelig nøkkel: passord

Som standard er mongo: siste bilde vil opprette en bruker med brukernavn og passord på en database som heter admin.

6.3. Sett opp MongoDB på reisebyråtjenesten

Det er viktig å oppdatere applikasjonsegenskapene for å legge til databaserelatert informasjon. Mens vi fritt kan spesifisere databasenavnet admin, her skjuler vi den mest sensitive informasjonen som brukernavn og passord:

spring.cloud.kubernetes.reload.enabled = true spring.cloud.kubernetes.secrets.name = db-secret spring.data.mongodb.host = mongodb-service spring.data.mongodb.port = 27017 spring.data.mongodb. database = admin spring.data.mongodb.username = $ {MONGO_USERNAME} spring.data.mongodb.password = $ {MONGO_PASSWORD}

La oss ta en titt på vår reisebyråutplassering eiendomsfil for å oppdatere tjenestene og distribusjonene med brukernavnet og passordinformasjonen som kreves for å koble til Mongodb-service.

Her er den relevante delen av filen, med delen relatert til MongoDB-tilkoblingen:

env: - navn: MONGO_USERNAME verdiFra: secretKeyRef: navn: db-hemmelig nøkkel: brukernavn - navn: MONGO_PASSWORD verdiFra: secretKeyRef: navn: db-hemmelig nøkkel: passord

7. Kommunikasjon med Ribbon

I et mikrotjenestemiljø trenger vi vanligvis listen over belg der tjenesten vår replikeres for å kunne utføre belastningsbalansering. Dette oppnås ved å bruke en mekanisme levert av Spring Cloud Kubernetes Ribbon. Denne mekanismen kan automatisk oppdage og nå alle endepunktene til en bestemt tjeneste, og deretter fyller den et bånd Serverliste med informasjon om endepunktene.

La oss starte med å legge til vår-sky-start-kubernetes-bånd avhengighet til vår kundeservice pom.xml-fil:

 org.springframework.cloud spring-cloud-starter-kubernetes-bånd 

Neste trinn er å legge til kommentaren @RibbonClient til vår kundeservice applikasjon:

@RibbonClient (name = "reisebyrå-tjeneste")

Når listen over endepunktene er fylt ut, vil Kubernetes-klienten søke i de registrerte endepunktene som bor i det nåværende navnområdet / prosjektet som samsvarer med tjenestenavnet som er definert ved hjelp av @RibbonClient kommentar.

Vi må også aktivere båndklienten i applikasjonsegenskapene:

ribbon.http.client.enabled = true

8. Ytterligere funksjoner

8.1. Hystrix

Hystrix hjelper med å bygge en feiltolerant og elastisk applikasjon. Hovedmålene er å mislykkes raskt og raskt.

Spesielt i vårt eksempel bruker vi Hystrix til å implementere effektbrytermønsteret på klient server ved å kommentere Spring Boot-applikasjonsklassen med @EnableCircuitBreaker.

I tillegg bruker vi reservefunksjonaliteten ved å kommentere metoden TravelAgencyService.getDeals () med @HystrixCommand (). Dette betyr at i tilfelle tilbakeslag getFallBackName () vil bli kalt og "Fallback" -meldingen returneres:

@HystrixCommand (fallbackMethod = "getFallbackName", commandProperties = {@HystrixProperty (name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000")}) offentlig streng getDeals () {returner this.restTemplate.getForObject ("/ / reisebyrå-tjeneste: 8080 / deals ", String.class); } privat streng getFallbackName () {return "Fallback"; }

8.2. Pod Health Indicator

Vi kan dra nytte av Spring Boot HealthIndicator og Spring Boot Actuator for å eksponere helserelatert informasjon for brukeren.

Spesielt gir Kubernetes helseindikator:

  • pod-navn
  • IP adresse
  • navneområdet
  • tjenestekonto
  • nodenavn
  • et flagg som indikerer om Spring Boot-applikasjonen er intern eller ekstern for Kubernetes

9. Konklusjon

I denne artikkelen gir vi en grundig oversikt over Spring Cloud Kubernetes-prosjektet.

Så hvorfor skal vi bruke det? Hvis vi forankrer Kubernetes som en mikrotjenesteplattform, men likevel setter pris på funksjonene til Spring Cloud, så gir Spring Cloud Kubernetes oss det beste fra begge verdener.

Den fulle kildekoden til eksemplet er tilgjengelig på GitHub.