Infrastructure Overview
Narwhal is a Vagrant-based Kubernetes Internal Developer Platform (IDP) cluster that provides a production-grade platform stack in a single cluster. It utilizes a High Availability (HA) architecture consisting of 3 master nodes and 3 worker nodes.
Base Box
- Image:
dasomel/ubuntu-26.04-xfs(Based on Ubuntu 26.04 LTS, Kernel 7.0) - Features: Uses the XFS filesystem with project quota (prjquota) enabled to support
nfs-quota-agent. - Provider: Supports both VirtualBox and VMware Desktop environments.
Node Layout
All nodes operate on the 192.168.56.0/24 private network. Masters get 6 GiB for the control plane plus DaemonSet headroom; workers get 6 GiB to run platform apps.
| Node | IP Address | Role | CPU | Memory | Notes |
|---|---|---|---|---|---|
narwhal-master-1 | 192.168.56.10 | Control Plane | 2 | 6 GiB | NFS Server, dnsmasq |
narwhal-master-2 | 192.168.56.11 | Control Plane | 2 | 6 GiB | dnsmasq |
narwhal-master-3 | 192.168.56.12 | Control Plane | 2 | 6 GiB | dnsmasq |
narwhal-worker-1 | 192.168.56.21 | Worker | 2 | 6 GiB | Runs platform apps |
narwhal-worker-2 | 192.168.56.22 | Worker | 2 | 6 GiB | Runs platform apps |
narwhal-worker-3 | 192.168.56.23 | Worker | 2 | 6 GiB | Runs platform apps |
- Storage: A minimum of 30GB disk space per VM is recommended for a full IDP deployment.
HA Control Plane Design
Built on Kubernetes v1.35.5, it provides high availability and 1 fault tolerance through 3 master nodes.
- kube-vip (v1.1.2): Uses the address
192.168.56.100as the Control Plane VIP. It ensures stable API server access via ARP-based leader election. - etcd: Configured as a 3-node quorum (quorum=2/3), ensuring normal operation even if 1 master node fails.
Network CIDRs
| Purpose | Network CIDR |
|---|---|
| Node Network | 192.168.56.0/24 |
| Pod Network | 10.244.0.0/16 |
| Service Network | 10.96.0.0/12 |
| MetalLB LoadBalancer Pool | 192.168.56.200 ~ 192.168.56.220 |
Component Topology Summary
Cluster provisioning happens sequentially. Phase 2 platform services are deployed only after all master and worker node joins are fully completed. User requests flow through DNS resolution → MetalLB → the APISIX gateway before reaching workloads inside the mesh.