streamalism.org

1. Oversigt

Når vi bygger en mikroserviceløsning, er både Spring Cloud og Kubernetes optimale løsninger, da de leverer komponenter til løsning af de mest almindelige udfordringer. Men hvis vi beslutter at vælge Kubernetes som den vigtigste containeradministrator og implementeringsplatform til vores løsning, kan vi stadig bruge Spring Clouds interessante funktioner hovedsageligt gennem Spring Cloud Kubernetes-projektet.

Dette relativt nye projekt giver utvivlsomt nem integration med Kubernetes til Spring Boot-applikationer. Før du starter, kan det være nyttigt at se på, hvordan du installerer en Spring Boot-applikation på Minikube, et lokalt Kubernetes-miljø.

I denne vejledning vil vi:

• Installer Minikube på vores lokale maskine
• Udvikle et mikroservicearkitektureksempel med to uafhængige Spring Boot-applikationer, der kommunikerer via REST
• Konfigurer applikationen i en klynge med en node ved hjælp af Minikube
• Implementer applikationen ved hjælp af YAML konfigurationsfiler

2. Scenarie

I vores eksempel bruger vi scenariet med rejsebureauer, der tilbyder forskellige tilbud til kunder, der fra tid til anden vil spørge om rejsebureaustjenesten. Vi bruger det til at demonstrere:

• service opdagelse gennem Spring Cloud Kubernetes
• Konfigurationsstyring og indsprøjtning af Kubernetes ConfigMaps og hemmeligheder til applikationsbælg ved hjælp af Spring Cloud Kubernetes Config
• belastningsafbalancering ved hjælp af Spring Cloud Kubernetes Ribbon

3. Opsætning af miljø

Først og fremmest skal vi installer Minikube på vores lokale maskine og helst en VM-driver såsom VirtualBox. Det anbefales også at se på Kubernetes og dets hovedfunktioner, før du følger denne miljøopsætning.

Lad os starte den lokale Kubernetes-klynge med en enkelt node:

minikube start --vm-driver = virtualbox

Denne kommando opretter en virtuel maskine, der kører en Minikube-klynge ved hjælp af VirtualBox-driveren. Standardkonteksten i kubectl bliver nu minikube. For at kunne skifte mellem sammenhænge bruger vi dog:

kubectl config brug-kontekst minikube

Efter at have startet Minikube kan vi Opret forbindelse til Kubernetes-instrumentbrættet for let at få adgang til logfilerne og overvåge vores tjenester, bælg, ConfigMaps og Secrets:

minikube dashboard 

3.1. Implementering

Lad os først få vores eksempel fra GitHub.

På dette tidspunkt kan vi enten køre scriptet “deployment-travel-client.sh” fra den overordnede mappe eller ellers udføre hver instruktion en efter en for at få en god forståelse af proceduren:

### opbyg lageret mvn ren installation ### sæt docker env eval $ (minikube docker-env) ### opbyg dockerbillederne på minikube cd rejsebureau-service docker build -t rejsebureau-service. cd ../client-service docker build -t client-service. cd .. ### hemmelig og mongodb kubectl slet -f rejsebureau-service / hemmelig.yaml kubectl slet -f rejsebureau-service / mongo-implementering.yaml kubectl opret -f rejsebureau-service / hemmelig.yaml kubectl oprette -f rejsebureau-service / mongo-implementering.yaml ### rejsebureau-service kubectl slette -f rejsebureau-service / rejsebureau-distribution.yaml kubectl oprette -f rejsebureau-service / rejsebureau-implementering.yaml ### klient-service kubectl slet configmap klient-service kubectl slet -f klient-service / klient-service-implementering.yaml kubectl opret -f klient-service / klient-config.yaml kubectl oprette - f client-service / client-service-deployment.yaml # Kontroller at pods kører kubectl get pods

4. Opdagelse af service

Dette projekt giver os en implementering af Serviceopdagelse interface i Kubernetes. I et mikroservicemiljø er der normalt flere bælg, der kører den samme service. Kubernetes afslører tjenesten som en samling af slutpunkter der kan hentes og nås fra en Spring Boot-applikation, der kører i en pod i samme Kubernetes-klynge.

For eksempel har vi i vores eksempel flere replikaer af rejseburantjenesten, som er tilgængelig fra vores klienttjeneste som // rejsebureau-service: 8080. Imidlertid vil dette internt oversætte til adgang til forskellige bælg som f.eks rejsebureau-service-7c9cfff655-4hxnp.

Spring Cloud Kubernetes Ribbon bruger denne funktion til at indlæse balance mellem de forskellige slutpunkter for en tjeneste.

Vi kan nemt bruge Service Discovery ved at tilføje afhængighed af spring-cloud-starter-kubernetes på vores klientapplikation:

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

Vi skal også tilføje @EnableDiscoveryClient og indsprøjt DiscoveryClient ind i ClientController ved hjælp af @Autowired i vores klasse:

@SpringBootApplication @EnableDiscoveryClient public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args); }}

@RestController offentlig klasse ClientController {@Autowired privat DiscoveryClient discoveryClient; }

5. ConfigMaps

Typisk, mikrotjenester kræver en form for konfigurationsstyring. For eksempel i Spring Cloud-applikationer bruger vi en Spring Cloud Config Server.

Vi kan dog opnå dette ved at bruge ConfigMaps leveret af Kubernetes - forudsat at vi kun agter at bruge det til ikke-følsomme, ukrypterede oplysninger. Alternativt, hvis de oplysninger, vi vil dele, er følsomme, skal vi vælge at bruge hemmeligheder i stedet.

I vores eksempel bruger vi ConfigMaps på klientservice Spring Boot ansøgning. Lad os oprette en klientkonfiguration.yaml-fil for at definere ConfigMap for klientservice:

apiVersion: v1 by d kind: ConfigMap metadata: navn: klient-service data: application.properties: | - bean.message = Test genindlæsning! Besked fra backend er:% s
Tjenester:% s

Det er vigtigt, at navnet på ConfigMap matcher navnet på applikationen som angivet i vores "application.properties" -fil. I dette tilfælde er det klientservice. Dernæst skal vi oprette ConfigMap til klientservice på Kubernetes:

kubectl oprette -f klient-config.yaml

Lad os nu oprette en konfigurationsklasse ClientConfig med @Konfiguration og @ConfigurationProperties og injiceres i ClientController:

@Configuration @ConfigurationProperties (prefix = "bean") offentlig klasse ClientConfig {private String message = "Besked fra backend er:% s
Tjenester:% s "; // getters and setters}

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

Hvis vi ikke angiver et ConfigMap, bør vi forvente at se standardmeddelelsen, der er angivet i klassen. Når vi opretter ConfigMap, bliver denne standardmeddelelse imidlertid tilsidesat af den egenskab.

Derudover ændres meddelelsen på siden hver gang vi beslutter at opdatere ConfigMap:

kubectl rediger configmap klient-service

6. Hemmeligheder

Lad os se på, hvordan hemmeligheder fungerer ved at se på specifikationen af ​​MongoDB-forbindelsesindstillinger i vores eksempel. Vi opretter miljøvariabler på Kubernetes, som derefter injiceres i Spring Boot-applikationen.

6.1. Opret en hemmelighed

Det første trin er at oprette en hemmelighed.yaml fil, der koder for brugernavn og adgangskode til Basis 64:

apiVersion: v1 kind: Secret metadata: name: db-secret data: brugernavn: dXNlcg == password: cDQ1NXcwcmQ =

Lad os anvende den hemmelige konfiguration på Kubernetes-klyngen:

kubectl anvende -f secret.yaml

6.2. Opret en MongoDB-tjeneste

Vi skal nu oprette MongoDB-tjenesten og implementeringen rejsebureau-deployering.yaml fil. Især i implementeringsdelen bruger vi hemmeligheden brugernavn og adgangskode som vi definerede tidligere:

apiVersion: extensions / v1beta1 kind: Implementering metadata: navn: mongo spec: replikaer: 1 skabelon: metadata: labels: service: mongo name: mongodb-service spec: containere: - args: - mongod - - smallfiles billede: mongo: seneste navn: mongo env: - navn: MONGO_INITDB_ROOT_USERNAME værdi Fra: secretKeyRef: navn: db-hemmelig nøgle: brugernavn - navn: MONGO_INITDB_ROOT_PASSWORD værdi Fra: secretKeyRef: navn: db-hemmelig nøgle: adgangskode

Som standard er mongo: seneste billede opretter en bruger med brugernavn og adgangskode på en navngivet database admin.

6.3. Opsæt MongoDB på rejsebureauets service

Det er vigtigt at opdatere applikationsegenskaberne for at tilføje de databaserelaterede oplysninger. Mens vi frit kan angive databasens navn admin, her skjuler vi de mest følsomme oplysninger som f.eks brugernavn og adgangskode:

spring.cloud.kubernetes.reload.enabled = sand spring.cloud.kubernetes.secrets.name = db-hemmelig 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}

Lad os nu se på vores rejsebureau-implementering ejendomsfil for at opdatere tjenester og implementeringer med de brugernavne og adgangskodeoplysninger, der kræves for at oprette forbindelse til Mongodb-service.

Her er det relevante afsnit af filen med den del, der er relateret til MongoDB-forbindelsen:

env: - navn: MONGO_USERNAME værdiFra: secretKeyRef: navn: db-hemmelig nøgle: brugernavn - navn: MONGO_PASSWORD værdiFra: secretKeyRef: navn: db-hemmelig nøgle: adgangskode

7. Kommunikation med bånd

I et mikroservicemiljø har vi generelt brug for listen over bælg, hvor vores service replikeres for at udføre belastningsbalancering. Dette opnås ved hjælp af en mekanisme leveret af Spring Cloud Kubernetes Ribbon. Denne mekanisme kan automatisk finde og nå alle slutpunkterne for en bestemt tjenesteog derefter udfylder det et bånd Serverliste med information om slutpunkterne.

Lad os starte med at tilføje spring-cloud-starter-kubernetes-bånd afhængighed af vores klientservice pom.xml-fil:

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

Det næste trin er at tilføje kommentaren @RibbonClient til vores klientservice Ansøgning:

@RibbonClient (name = "rejsebureau-service")

Når listen over slutpunkter er udfyldt, vil Kubernetes-klienten søge i de registrerede slutpunkter, der lever i det aktuelle navneområde / projekt, der matcher det servicenavn, der er defineret ved hjælp af @RibbonClient kommentar.

Vi har også brug for at aktivere båndklienten i applikationsegenskaberne:

ribbon.http.client.enabled = sand

8. Yderligere funktioner

8.1. Hystrix

Hystrix hjælper med at opbygge en fejltolerant og elastisk applikation. Dets vigtigste mål er at fejle hurtigt og hurtigt genoprette.

Især i vores eksempel bruger vi Hystrix til at implementere afbrydermønsteret på klientserver ved at kommentere Spring Boot-applikationsklassen med @EnableCircuitBreaker.

Derudover bruger vi tilbagefaldsfunktionaliteten ved at kommentere metoden TravelAgencyService.getDeals () med @HystrixCommand (). Dette betyder, at i tilfælde af tilbageførsel getFallBackName () kaldes og meddelelsen "Fallback" returneres:

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

8.2. Pod Health Indicator

Vi kan drage fordel af Spring Boot HealthIndicator og Spring Boot Actuator for at udsætte sundhedsrelaterede oplysninger for brugeren.

Især Kubernetes sundhedsindikator giver:

• pod-navn
• IP-adresse
• navneområde
• servicekonto
• nodenavn
• et flag, der angiver, om Spring Boot-applikationen er intern eller ekstern for Kubernetes

9. Konklusion

I denne artikel giver vi en grundig oversigt over Spring Cloud Kubernetes-projektet.

Så hvorfor skal vi bruge det? Hvis vi rodfæste Kubernetes som en mikroserviceplatform, men stadig værdsætter funktionerne i Spring Cloud, så giver Spring Cloud Kubernetes os det bedste fra begge verdener.

Den fulde kildekode for eksemplet er tilgængelig på GitHub.