Build a High‑Availability Microservices System on Kubernetes: Step‑by‑Step Guide

Chapter 1: Microservice Design

Microservices split functionality into independent modules, achieving high cohesion and low coupling. The article references Martin Fowler’s definition and includes diagrams illustrating service and database decomposition.

Further diagrams show how databases are also split into smaller, dedicated instances.

1.1 Design Philosophy

The article emphasizes that microservices are not limited to any language; Java Spring Boot is used for the example, and RESTful APIs are chosen for inter‑service communication.

1.2 Practical Design and Improvements

A simple three‑node call chain (www.demo.com → a.demo.com → b.demo.com → c.demo.com) is used to illustrate request flow. The design later adds multiple instances, a registration center, monitoring, logging, tracing, and flow control to achieve high availability.

1.3 Adding Multiple Instances and a Registration Center

To avoid single‑point failures, each service runs several instances. Service discovery is handled by a registration center (Eureka is used in the example).

Code snippet for enabling Eureka: @EnableEurekaServer Configuration files are adjusted for a three‑node Eureka cluster in Kubernetes.

1.4 Monitoring System (Metrics)

Prometheus and Grafana are selected as the monitoring stack. Each service exports metrics such as memory usage, HTTP error counts, JVM thread count, and GC time, which Prometheus scrapes automatically.

1.5 Logging System

Logs are sent directly to Kafka to avoid disk I/O on containers. The logback configuration can switch between local files and Kafka.

1.6 Tracing System

Zipkin is used for distributed tracing. It adds a unique identifier to each request and propagates it across services, enabling end‑to‑end request visualization.

1.7 Flow Control

Sentinel provides rate limiting, circuit breaking, and degradation. It ensures the system can reject excess traffic when capacity is exceeded.

Chapter 2: Implementation

2.1 Front‑end Site

The front‑end displays a button that triggers an AJAX call to the back‑end via Nginx, which forwards the request through a.demo.com, b.demo.com, and c.demo.com, finally returning the result to the browser.

2.2 Registration Center

A minimal Spring Boot application with @EnableEurekaServer serves as the registration center. Configuration files are provided for high‑availability deployment.

2.3 Base Library

The base library aggregates common dependencies and utilities, allowing individual microservices to stay lightweight.

2.4 Service Implementations (a.demo.com, b.demo.com, c.demo.com)

Each service implements a health‑check endpoint (/hs) for Kubernetes readiness probes and forwards requests to the next service in the chain.

Chapter 3: Kubernetes Deployment

K8seasy is used to install a production‑grade Kubernetes cluster with built‑in images, supporting multi‑node HA setups.

One‑click installation without prior knowledge.

All required images are bundled.

Supports various Kubernetes versions.

Installs binary (non‑container) components for stability.

Can create a three‑node HA cluster.

3.1 Installation Process

Download the installer and binary package, generate keys, and run two commands to create the cluster.

sudo ./installer --genkey -hostlist=192.168.2.1

sudo ./installer -kubernetestarfile kubernetes-server-linux-amd64v1.18.2.tar.gz -masterip 192.168.2.50

After a short wait, the cluster is ready and all monitoring components are installed.

3.2 Accessing Dashboards

The Kubernetes dashboard, Alertmanager, Grafana (admin/admin), and Prometheus are reachable via the master node’s IP and respective ports.

3.3 Multi‑Cluster Management

K8seasy generates a lens.kubeconfig file. Import it into Lens (https://kuberneteslens.dev) to manage multiple clusters from a single UI.

Chapter 4: High‑Availability Deployment and Validation

After building Docker images from the Java sources, the services are deployed with provided YAML files. No manual steps are required beyond applying the manifests.

4.1 Service Deployment

Apply each YAML file sequentially; the images are pulled from Docker Hub.

4.2 Dashboard Verification

The Kubernetes dashboard shows all services running, and the Eureka cluster displays three healthy instances.

4.3 Front‑end Validation

Visiting http://www.demo.com and clicking the request button shows live updates from different service instances, confirming load‑balancing and fault tolerance.

4.4 Tracing Verification

Opening zipkin.demo.com displays detailed traces for each request, showing the path through a, b, and c services.

4.5 Flow‑Control and Circuit‑Breaking

Sentinel’s UI (sentinel.demo.com, credentials: sentinel) automatically discovers all services and allows rate limiting, circuit breaking, and degradation testing.

4.6 Metrics Dashboard

Grafana visualizes JVM metrics (heap size, uptime, error counts) for each microservice, providing a complete health overview.

By following this guide, readers obtain a practical, production‑ready microservice architecture running on Kubernetes with full observability and resilience.