Spring Cloud Kubernetes - Jorge-Dacal/devonfw-shop-floor GitHub Wiki

[Under construction]


The purpose of the present document is to provide a high level description (comparision vs. Kubernetes) of Spring Cloud Kubernetes, the solution implemented by Spring to integrate/deploy into a Kubernetes cluster a Spring Cloud Netflix microservices-based application/architecture.


Introduction

[TODO]

Additional documentation

High level technology mapping

Spring Cloud Netflix OSS vs. Kubernetes

 

CONCERN Spring Cloud & Netflix OSS Kubernetes

Confi. Management

Config. Server, Consul, Archaius

ConfigMap & Secrets

Service Discovery

Eureka, Consul

Service & Ingress

Load Balancing

Ribbon

Service

API Gateway

Zuul

Service & Ingress

Service Security

Spring Cloud Security

Centralized Logging

ELK Stack (Log Stash)

EFK Stack (Fluentd)

Centralized Metrics

Spectator & Atlas

Heapster, Prometheus, Grafana

Distributed Tracing

Spring Cloud Sleuth, Zipkin

OpenTracing, Zipkin

Resilience & Fault Tolerance

Hystrix, Turbine & Ribbon

Health Checks & resource isolation

Auto Scaling & Self Healing

Heal Checks, Self Healing, Autoscaling

Packaging, Dep., & Scheduling

Spring Boot

Docker/Rkt, Scheduler & Deployment

Job Management

Spring batch

Jobs & Scheduled Jobs

Singleton Application

Spring Cloud Cluster

Pods

Spring Cloud Kubernetes & Kubernetes

 

CONCERN Spring Cloud & Netflix OSS Kubernetes

Config. Management

ConfigMapPropertySource, SecretsPropertySource, Archaius

ConfigMap & Secrets

Service Discovery

DiscoveryClient

Service & Ingress

Resilience & Fault Tolerance

HealthIndicator

Health Checks & resource isolation

Config. Management

Properties

Secrets

Profiling

Service Discovery

From inside the cluster, Spring provides the DiscoveryClient implementation, which allows querying Kubernetes Services by name (Notice that a Kubernetes Service is a logical agrupation of pods under the same IP and is exposed as a collection of endpoints to the applications/containers running as pods)

Notice that, in order to allow this DiscoveryClient to work properly, the Kubernetes DNS service must be up & running in the Kubernetes cluster, so that every pods/container is able to resolve service names (see Kubernetes DNS).

The DicoveryClient can be easly used just by

  • 1st addin the maven dependency

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-kubernetes</artifactId>
    <version>${latest.version}</version>
</dependency>
  • 2nd autowiring the bean

@Autowire
private DiscoveryClient discoveryClient;
  • 3rd setting the appropriate service instance name in the property

    sprint.application.name
    The DiscoveryClient can be disable with the property
    spring.cloud.kubernetes.discovery.enabled=false
    in which case, the discovery of the services would be carried out through the default Kubernetes Service.

Having the endpoints of a service in the client application/container allows the capability of Client-side load balancing.

From outside the Kubernetes client, the service discovery is still responsibility of Ingress (see Kubernetes Ingress).

Doubts/open points:

  • Does the DiscoveryClient return list of services matching a name (or pattern)?

  • Does the DiscoveryClient return list of all endpoints of a particular service?

  • How the behavior is in case of discovering several different services? Does the DiscoveryClient maintain a common single list of endpoints of all the services?

  • In case of client-side load balancing, what should be the appropriate algorithm/method to determine which endpoint to target?

  • A/B testing?

Resilience & Fault Tolerance

Additional concerns

Calls between services

  • Adaptive routing / client side load balancing

  • Automatic retries

  • Timeout controls

  • back pressure

  • Rate limiting

  • Metrics/stats collection

  • Tracing

  • A/B testing / traffic shaping / request shadowing

  • Service refactoring / request shadowing

  • Service deadline/timeout enforcement across service calls

  • Security between services

  • Edge gateway/router

  • Surgical / fine / per-request routing

  • Forced service isolation / outlier detection

  • Fault injection (ie, injecting delays? dropping ingress/egress packets?)

  • Internal releases/dark launches

PROS & CONS

⚠️ **GitHub.com Fallback** ⚠️