How SegmentFault Scaled Its Architecture with Kubernetes and KubeSphere

SegmentFault Architecture Evolution

SegmentFault, a Chinese tech community, started in 2012 with a single‑instance VPS on Linode, later moved to self‑hosted servers, then to public cloud, and finally migrated its core services to KubeSphere in 2020 to adopt a cloud‑native architecture.

Why Choose Kubernetes?

The platform faces several challenges: a complex business line with a small engineering team, frequent configuration changes, lack of dedicated operations staff, and strict cost constraints. These pressures motivated a shift to Kubernetes.

Frontend‑Backend Separation

Before 2020 the site used traditional server‑side rendering with PHP. Growth forced a split into multiple services: a Node.js React server for server‑side rendering, a PHP API service for client‑side rendering, and an internal API using a proprietary protocol, all requiring load balancing.

What Kubernetes Brings

KubeSphere provides an out‑of‑the‑box, high‑availability Kubernetes cluster that can be provisioned with a few clicks, ideal for teams without dedicated ops. Deployment is managed as code: Dockerfiles, K8s manifests, and versioned in Git, enabling automated CI/CD pipelines.

Continuous integration with GitLab automates testing, image building, and deployment to the cluster, making releases fast and traceable.

Operational Lessons

Run log services (e.g., Elasticsearch) outside the cluster to avoid heavy resource consumption.

Deploy three or more master nodes for high availability.

Avoid running critical databases or caches on Kubernetes unless you are a service provider; prefer managed cloud services.

Scale replica counts to match cluster size to prevent scheduling overload.

Containerization reduced the number of physical servers needed, allowing finer‑grained resource planning and higher efficiency.