How to Build a High‑Availability Microservices System on Kubernetes – A Complete Guide
This guide walks through designing a simple front‑end/back‑end microservices architecture, implementing it with Spring Boot and Eureka, deploying the services on a Kubernetes cluster using K8seasy, and adding high‑availability features such as multi‑instance registration, Prometheus‑Grafana monitoring, Zipkin tracing, and Sentinel flow‑control.
Overview
This guide demonstrates how to design, implement, and deploy a simple Java Spring Boot microservice system on a three‑node high‑availability Kubernetes cluster. It covers service decomposition, registration, monitoring, logging, tracing, flow‑control, Docker image creation, Kubernetes manifests, and validation of high availability.
Microservice Design
The architecture follows the microservice principle of small, single‑purpose services with independent deployment. Key design decisions include:
Run multiple instances of each service to avoid single‑point failures.
Use Eureka as a service registry so that instances can discover each other dynamically.
Collect metrics with Prometheus and visualize them in Grafana .
Send application logs to Kafka to decouple log storage from containers.
Integrate Zipkin for distributed tracing and Sentinel for rate limiting, circuit breaking, and degradation.
Each service exposes a health‑check endpoint /hs for Kubernetes liveness probes.
Implementation
The project is a multi‑module Maven build:
eureka-server : Eureka registration center.
base-lib : Shared utilities and common response structures.
service-a , service-b , service-c : Business services that call the next service in the chain.
Example Eureka client configuration (Java):
@EnableEurekaClient
@SpringBootApplication
public class ServiceApplication {
public static void main(String[] args) {
SpringApplication.run(ServiceApplication.class, args);
}
}The front‑end is a static page served by Nginx. Clicking a button triggers an AJAX request to the front‑end, which proxies to a.demo.com. Service A forwards to B, B forwards to C, and C returns the final result. The response includes instance IP, timestamp, and thread ID for verification.
Kubernetes Deployment
The cluster is provisioned with the K8seasy installer (binary, not container‑based). Installation steps (run on a Linux host with root privileges):
Download the installer binaries from the official GitHub repository: https://github.com/xiaojiaqi/K8seasy_release_page and the binary package http://dl.K8seasy.com/.
Generate SSH keys for the nodes: sudo ./installer --genkey -hostlist=192.168.2.1 Create a three‑node HA cluster (master IP 192.168.2.50, Kubernetes tarball version 1.18.2):
sudo ./installer -kubernetestarfile kubernetes-server-linux-amd64v1.18.2.tar.gz -masterip 192.168.2.50After installation the following services are reachable on the master node (IP 192.168.2.50):
Kubernetes Dashboard: http://192.168.2.50:10000 Alertmanager: http://192.168.2.50:8080 Grafana (admin/admin): http://192.168.2.50:8081 Prometheus: http://192.168.2.50:8082 All manifests (Dockerfiles, Kubernetes YAML files) are stored in the project repository: https://github.com/xiaojiaqi/deploy-microservices-to-a-Kubernetes-cluster.
High‑Availability Deployment and Validation
Docker images for the four components (eureka, service‑a, service‑b, service‑c) are built and pushed to Docker Hub. Applying the YAML manifests creates three replicas for each service, forming a HA Eureka cluster and three identical service pods.
Validation steps:
Open the front‑end URL http://www.demo.com and click the request button. The page shows changing instance IPs, confirming load‑balanced routing.
Inspect Zipkin at http://zipkin.demo.com to view the full trace of a request across a → b → c.
Open Sentinel UI (default credentials sentinel/sentinel) to verify that rate limiting, circuit breaking, and degradation rules are active.
Run a simple script that sends a request every three seconds; Prometheus metrics (JVM heap, GC time, HTTP error counts, QPS) are displayed in Grafana dashboards.
Grafana dashboards imported for JVM metrics provide real‑time visibility of memory usage, thread counts, and error rates for each service.
Key Takeaways
The example demonstrates a reproducible workflow:
Design microservices with independent instances and a service registry.
Instrument services for metrics ( micrometer‑prometheus), logging (Kafka), and tracing (Zipkin).
Package services as Docker images and deploy them with Kubernetes Deployment and Service resources, using replicas: 3 for HA.
Use Kubernetes health probes ( /hs) to ensure only ready pods receive traffic.
Validate the system end‑to‑end with load‑balanced front‑end requests, trace inspection, and monitoring dashboards.
All source code, Dockerfiles, and Kubernetes manifests are available at the GitHub repository mentioned above.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
