Skip to content

3.0 Infrastructure

The Infrastructure section explains the "behind-the-scenes" setup that keeps the MBI platform running smoothly. It covers how we manage the systems and environments that ensure the platform is always secure, reliable, and ready to support users and applications.

3.1 Server Architecture Diagram

This section provides an overview of how the MBI platform is deployed and managed within a cloud-native environment. It illustrates the underlying infrastructure components, their interconnections, and how they collectively ensure high availability, scalability, and operational resilience. This architecture is based on Kubernetes container orchestration, enabling automated deployment, workload balancing, and fault tolerance across multiple nodes. The following sections describe the major components, including the control plane, worker nodes, networking, and storage, that together form the backbone of MBI's infrastructure.

i. High Availability Architecture 🌐

High Availability Architecture
Figure 3: Architecture Diagram Overview

The diagram represents the high availability (HA) design of a Kubernetes cluster. High availability ensures that the system continues functioning even in the event of hardware or software failures.

Virtual IP
  • Acts as a single entry point for external requests to the cluster.
  • Provides abstraction so users do not need to track individual load balancer addresses.
Load Balancers (LB1 and LB2)
  • Distribute incoming requests across multiple control plane nodes.
  • Operate in a redundant configuration so that if one load balancer fails, the other continues handling traffic.
  • Prevents a single point of failure in request routing.
Control Plane Nodes (Control Plane 1, 2, and 3)
  • Multiple control plane nodes are deployed to provide resiliency and quorum for ETCD.
  • Each control plane node hosts critical services:
    • API Server: Central communication hub for cluster operations.
    • ETCD: Stores cluster state and configuration in a consistent, distributed key-value store.
    • Scheduler: Assigns Pods to suitable worker nodes.
    • Controller Manager: Continuously reconciles cluster state with the desired state.
  • Running three or more nodes ensures high availability, as cluster management can continue even if one node becomes unavailable.
Worker Nodes (Worker 1, 2, and 3)
  • Execute actual application workloads.
  • Maintain connections with all control plane nodes to ensure they can receive instructions even if one control plane instance fails.
  • Provide scalability by allowing additional workers to be added as demand grows.
Networking
  • Load balancers connect to all control plane nodes.
  • Control plane nodes connect to all worker nodes.
  • This full-mesh setup ensures continuous communication paths and avoids bottlenecks.

ii. Control Plane and Worker Node Components ⚙️

Control Plane and Worker Node Components
Figure 3.1: Details Architecture Diagram

The second diagram provides a more detailed look into the internal components of the control plane and worker nodes, as well as their interaction with developers and end users.

Control Plane Components
  • API Server: Acts as the primary communication interface for the cluster. All commands and queries (for example, kubectl requests from developers) are processed here.
  • ETCD: Stores persistent cluster state, including resource definitions and configurations.
  • Controller Manager: Runs controllers that ensure the actual state of the cluster matches the desired state.
  • Scheduler: Decides which worker node will host a Pod based on resource constraints and policies.
Worker Node Components
  • Kubelet: An agent that ensures Pods are running as expected on the worker node. It communicates with the API Server and interacts with the container runtime.
  • Container Runtime: Executes and manages containers. Examples include Docker, containerd, or CRI-O.
  • Kube-proxy: Manages networking and load balancing to ensure seamless communication between services and Pods, as well as with external clients.
External Interactions
  • Developer Interaction: Developers use the kubectl command-line tool to submit instructions (for example, deploy applications, scale services). These requests are sent to the API Server.
  • End User Interaction: End users access deployed applications through services exposed on worker nodes. Requests are routed via Kube-proxy to the appropriate Pods.

iii. Workflow Summary 🔄

The complete flow of a request in the Kubernetes cluster can be summarized as follows:

Step 1: Developer Request

A developer submits a request using kubectl, which is received by the API Server through the virtual IP and load balancer.

Step 2: API Server Processing

The API Server validates the request, updates ETCD, and forwards scheduling decisions to the Scheduler.

Step 3: Workload Assignment

The Scheduler assigns the workload to an appropriate worker node.

Step 4: Container Execution

The Kubelet on the worker node interacts with the container runtime to start the necessary containers.

Step 5: Networking Configuration

Kube-proxy ensures that networking rules are in place so that the application can be accessed.

Step 6: End User Access

End users access the running application via service endpoints exposed by the worker nodes.