Gids voor Spring Cloud Kubernetes

1. Overzicht

Wanneer we een microservices-oplossing bouwen, zijn zowel Spring Cloud als Kubernetes optimale oplossingen, omdat ze componenten bieden voor het oplossen van de meest voorkomende uitdagingen. Als we echter besluiten Kubernetes te kiezen als de belangrijkste containerbeheerder en het implementatieplatform voor onze oplossing, kunnen we nog steeds de interessante functies van Spring Cloud gebruiken, voornamelijk via het Spring Cloud Kubernetes-project.

Dit relatief nieuwe project biedt ongetwijfeld eenvoudige integratie met Kubernetes voor Spring Boot-applicaties. Voordat u begint, kan het handig zijn om te kijken hoe u een Spring Boot-applicatie implementeert op Minikube, een lokale Kubernetes-omgeving.

In deze tutorial zullen we:

  • Installeer Minikube op onze lokale computer
  • Ontwikkel een voorbeeld van een microservices-architectuur met twee onafhankelijke Spring Boot-applicaties die communiceren via REST
  • Stel de applicatie in op een cluster met één knooppunt met behulp van Minikube
  • Implementeer de applicatie met YAML config-bestanden

2. Scenario

In ons voorbeeld gebruiken we het scenario van reisagenten die verschillende deals aanbieden aan klanten die de service van reisagenten van tijd tot tijd zullen opvragen. We zullen het gebruiken om te demonstreren:

  • service-ontdekking via Spring Cloud Kubernetes
  • configuratiebeheer en het injecteren van Kubernetes ConfigMaps en geheimen in applicatiepods met behulp van Spring Cloud Kubernetes Config
  • taakverdeling met behulp van Spring Cloud Kubernetes Ribbon

3. Omgeving instellen

Eerst en vooral moeten we dat doen installeer Minikube op onze lokale computer en bij voorkeur een VM-stuurprogramma zoals VirtualBox. Het wordt ook aanbevolen om Kubernetes en de belangrijkste functies ervan te bekijken voordat u deze omgeving instelt.

Laten we beginnen met het lokale Kubernetes-cluster met één knooppunt:

minikube start --vm-driver = virtualbox

Met deze opdracht wordt een virtuele machine gemaakt waarop een Minikube-cluster wordt uitgevoerd met behulp van de VirtualBox-driver. De standaardcontext in kubectl zal nu zijn minikube. Om echter tussen contexten te kunnen schakelen, gebruiken we:

kubectl config use-context minikube

Nadat we Minikube hebben gestart, kunnen we maak verbinding met het Kubernetes-dashboard om eenvoudig toegang te krijgen tot de logboeken en onze services, pods, ConfigMaps en Secrets eenvoudig te volgen:

minikube-dashboard 

3.1. Inzet

Laten we eerst ons voorbeeld van GitHub halen.

Op dit punt kunnen we ofwel het "deployment-travel-client.sh" -script uitvoeren vanuit de bovenliggende map, of anders elke instructie een voor een uitvoeren om de procedure goed te begrijpen:

### bouw de repository mvn schone installatie ### set docker env eval $ (minikube docker-env) ### bouw de docker-afbeeldingen op minikube cd reisbureau-dienst havenarbeider build -t reisbureau-service. cd ../client-service docker build -t client-service. cd .. ### secret en mongodb kubectl delete -f reisbureau-service / secret.yaml kubectl delete -f reisbureau-service / mongo-deployment.yaml kubectl create -f reisbureau-service / secret.yaml kubectl create -f reisbureau-service / mongo-deployment.yaml ### reisbureau-dienst kubectl delete -f reisbureau-service / reisbureau-implementatie.yaml kubectl create -f reisbureau-dienst / reisbureau-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 # Controleer of de pods kubectl get pods uitvoeren

4. Dienstopsporing

Dit project levert ons een implementatie op voor het ServiceDiscovery interface in Kubernetes. In een microservices-omgeving zijn er meestal meerdere pods die dezelfde service uitvoeren. Kubernetes geeft de service weer als een verzameling eindpunten die kunnen worden opgehaald en bereikt vanuit een Spring Boot-applicatie die wordt uitgevoerd in een pod in hetzelfde Kubernetes-cluster.

In ons voorbeeld hebben we bijvoorbeeld meerdere replica's van de reisagentenservice, die toegankelijk is via onze klantenservice als // reisbureau-service: 8080. Dit zou zich intern echter vertalen in toegang tot verschillende pods, zoals reisbureau-service-7c9cfff655-4hxnp.

Spring Cloud Kubernetes Ribbon gebruikt deze functie om de balans tussen de verschillende eindpunten van een service te laden.

We kunnen Service Discovery eenvoudig gebruiken door de spring-cloud-starter-kubernetes-afhankelijkheid toe te voegen aan onze clienttoepassing:

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

We moeten ook toevoegen @EnableDiscoveryClient en injecteer de DiscoveryClient in de ClientController door het gebruiken van @Autowired in onze klas:

@SpringBootApplication @EnableDiscoveryClient openbare klasse Toepassing {openbare statische leegte hoofd (String [] args) {SpringApplication.run (Application.class, args); }}
@RestController openbare klasse ClientController {@Autowired privé DiscoveryClient discoveryClient; }

5. ConfigMaps

Typisch, microservices vereisen een soort configuratiebeheer. In Spring Cloud-applicaties zouden we bijvoorbeeld een Spring Cloud Config Server gebruiken.

We kunnen dit echter bereiken door ConfigMaps van Kubernetes te gebruiken - op voorwaarde dat we het alleen voor niet-gevoelige, niet-versleutelde informatie willen gebruiken. Als de informatie die we willen delen ook gevoelig is, moeten we ervoor kiezen om in plaats daarvan Secrets te gebruiken.

In ons voorbeeld gebruiken we ConfigMaps op het klantenservice Spring Boot-applicatie. Laten we een client-config.yaml-bestand om de ConfigMap van het klantenservice:

apiVersion: v1 door d soort: ConfigMap metadata: name: client-service data: application.properties: | - bean.message = Bezig met testen van herladen! Bericht van backend is:% s

Diensten:% s

Het is belangrijk dat de naam van de ConfigMap overeenkomt met de naam van de applicatie zoals gespecificeerd in ons "application.properties" -bestand. In dit geval is het klantenservice. Vervolgens moeten we de ConfigMap maken voor klantenservice op Kubernetes:

kubectl create -f client-config.yaml

Laten we nu een configuratieklasse maken Clientconfiguratie met de @Configuratie en @ConfigurationProperties en injecteer in de ClientController:

@Configuration @ConfigurationProperties (prefix = "bean") openbare klasse ClientConfig {private String message = "Bericht van backend is:% s

Services:% s "; // getters en setters}

@RestController openbare klasse ClientController {@Autowired private ClientConfig-configuratie; @GetMapping public String load () {return String.format (config.getMessage (), "", ""); }}

Als we geen ConfigMap specificeren, zouden we verwachten het standaardbericht te zien, dat is ingesteld in de klasse. Wanneer we echter de ConfigMap maken, wordt dit standaardbericht overschreven door die eigenschap.

Bovendien, elke keer dat we besluiten om de ConfigMap bij te werken, verandert het bericht op de pagina dienovereenkomstig:

kubectl bewerk configmap client-service

6. Geheimen

Laten we eens kijken hoe Secrets werken door te kijken naar de specificatie van MongoDB-verbindingsinstellingen in ons voorbeeld. We gaan omgevingsvariabelen maken op Kubernetes, die vervolgens in de Spring Boot-applicatie worden geïnjecteerd.

6.1. Creëer een geheim

De eerste stap is het maken van een secret.yaml bestand, waarbij het gebruikersnaam en wachtwoord naar Basis 64:

apiVersion: v1 soort: Geheime metadata: naam: db-geheime data: gebruikersnaam: dXNlcg == wachtwoord: cDQ1NXcwcmQ =

Laten we de geheime configuratie toepassen op het Kubernetes-cluster:

kubectl toepassen -f secret.yaml

6.2. Maak een MongoDB-service

We zouden nu de MongoDB-service en de implementatie moeten maken reisbureau-deployment.yaml het dossier. In het bijzonder zullen we in het implementatiegedeelte het geheim gebruiken gebruikersnaam en wachtwoord die we eerder hebben gedefinieerd:

apiVersion: extensions / v1beta1 soort: implementatie metadata: naam: mongo specificatie: replica's: 1 sjabloon: metadata: labels: service: mongo naam: mongodb-service spec: containers: - args: - mongod - --smallfiles afbeelding: mongo: nieuwste naam: mongo env: - naam: MONGO_INITDB_ROOT_USERNAME waardeVan: secretKeyRef: naam: db-geheime sleutel: gebruikersnaam - naam: MONGO_INITDB_ROOT_PASSWORD waardeVan: secretKeyRef: naam: db-geheime sleutel: wachtwoord

Standaard is het mongo: laatste image zal een gebruiker aanmaken met gebruikersnaam en wachtwoord op een database met de naam beheerder.

6.3. MongoDB instellen op Travel Agency Service

Het is belangrijk om de applicatie-eigenschappen bij te werken om de databasegerelateerde informatie toe te voegen. Hoewel we de databasenaam vrijelijk kunnen specificeren beheerder, verbergen we hier de meest gevoelige informatie, zoals de gebruikersnaam en de wachtwoord:

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

Laten we nu eens kijken naar onze inzet van reisbureaus property-bestand om de services en implementaties bij te werken met de gebruikersnaam en het wachtwoord die nodig zijn om verbinding te maken met het mongodb-service.

Hier is het relevante gedeelte van het bestand, met het gedeelte gerelateerd aan de MongoDB-verbinding:

env: - naam: MONGO_USERNAME waardeFrom: secretKeyRef: naam: db-geheime sleutel: gebruikersnaam - naam: MONGO_PASSWORD waardeFrom: secretKeyRef: naam: db-geheime sleutel: wachtwoord

7. Communicatie met lint

In een microservices-omgeving hebben we over het algemeen de lijst met pods nodig waar onze service wordt gerepliceerd om taakverdeling uit te voeren. Dit wordt bereikt door een mechanisme te gebruiken dat wordt geleverd door Spring Cloud Kubernetes Ribbon. Dit mechanisme kan automatisch alle eindpunten van een specifieke service ontdekken en bereiken, en vervolgens vult het een lint Server lijst met informatie over de eindpunten.

Laten we beginnen met het toevoegen van de spring-cloud-starter-kubernetes-lint afhankelijkheid van onze klantenservice pom.xml-bestand:

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

De volgende stap is om de annotatie toe te voegen @BuienRadarNL naar onze klantenservice toepassing:

@RibbonClient (name = "reisbureau-service")

Wanneer de lijst met eindpunten is gevuld, zal de Kubernetes-client de geregistreerde eindpunten doorzoeken die in de huidige naamruimte / het huidige project leven en overeenkomen met de servicenaam die is gedefinieerd met de @BuienRadarNL annotatie.

We moeten ook de lintclient inschakelen in de applicatie-eigenschappen:

ribbon.http.client.enabled = true

8. Extra functies

8.1. Hystrix

Hystrix helpt bij het bouwen van een fouttolerante en veerkrachtige applicatie. De belangrijkste doelstellingen zijn: snel falen en snel herstel.

In ons voorbeeld gebruiken we met name Hystrix om het stroomonderbrekerpatroon op de client server door de Spring Boot-toepassingsklasse te annoteren met @EnableCircuitBreaker.

Bovendien gebruiken we de fallback-functionaliteit door de methode te annoteren TravelAgencyService.getDeals () met @HystrixCommand (). Dit betekent dat in geval van fallback de getFallBackName () wordt gebeld en het bericht "Terugval" wordt geretourneerd:

@HystrixCommand (fallbackMethod = "getFallbackName", commandProperties = {@HystrixProperty (name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000")}) public String getDeals () {retourneer this.restTemplate.getForObject ("/ / reisbureau-service: 8080 / deals ", String.class); } private String getFallbackName () {retourneer "Fallback"; }

8.2. Pod gezondheidsindicator

We kunnen profiteren van Spring Boot Gezondheidsindicator en Spring Boot Actuator om gezondheidsgerelateerde informatie aan de gebruiker te tonen.

In het bijzonder biedt de gezondheidsindicator van Kubernetes:

  • pod naam
  • IP adres
  • naamruimte
  • serviceaccount
  • knooppunt naam
  • een vlag die aangeeft of de Spring Boot-applicatie intern of extern is voor Kubernetes

9. Conclusie

In dit artikel geven we een uitgebreid overzicht van het Spring Cloud Kubernetes-project.

Dus waarom zouden we het gebruiken? Als we voor Kubernetes kiezen als een microservicesplatform, maar de functies van Spring Cloud nog steeds waarderen, dan biedt Spring Cloud Kubernetes ons het beste van twee werelden.

De volledige broncode van het voorbeeld is beschikbaar op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found