Cloud Native 20 min read

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.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
How to Build a High‑Availability Microservices System on Kubernetes – A Complete Guide

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.50

After 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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

monitoringCloud NativeMicroservicesBackend DevelopmentKubernetesPrometheussentineleurekaGrafanazipkin
IT Architects Alliance
Written by

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.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.