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.
[TODO]
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 |
CONCERN | Spring Cloud & Netflix OSS | Kubernetes |
---|---|---|
Config. Management |
|
ConfigMap & Secrets |
Service Discovery |
|
Service & Ingress |
Resilience & Fault Tolerance |
HealthIndicator |
Health Checks & resource isolation |
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
Thesprint.application.name
DiscoveryClient
can be disable with the propertyin which case, the discovery of the services would be carried out through the default Kubernetes Service.spring.cloud.kubernetes.discovery.enabled=false
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).
-
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?
-
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