You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ARCHITECTURE.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -70,15 +70,15 @@ Inside each container, a Fedora bootc VM runs via libvirt/QEMU. The VM boots fro
70
70
The VM runs:
71
71
-**CRI-O** as the container runtime
72
72
-**kubelet** managed by kubeadm
73
-
-**dnsmasq** (node1 only) for cluster DNS
73
+
-**dnsmasq** (in a dedicated container) for cluster DNS
74
74
75
75
Resources per VM default to 4 vCPUs and 8192 MB RAM, configurable via `--vcpus` and `--memory`.
76
76
77
77
### Local Registry
78
78
79
79
A shared container registry (`bink-registry`) runs alongside clusters on the Podman bridge network at a static IP (`10.88.0.2:5000`). It is auto-created on first cluster start and shared across all clusters.
80
80
81
-
VMs reach the registry through passt networking since passt translates VM traffic through the container's network stack, which sits on the Podman bridge. DNS entry `registry.cluster.local` points to `10.88.0.2` via dnsmasq on node1. CRI-O and containers/registries.conf are configured to trust the registry without TLS.
81
+
VMs reach the registry through passt networking since passt translates VM traffic through the container's network stack, which sits on the Podman bridge. DNS entry `registry.cluster.local` points to `10.88.0.2` via the cluster's dedicated DNS container. CRI-O and containers/registries.conf are configured to trust the registry without TLS.
82
82
83
83
The registry survives cluster stops and is only removed via `bink registry stop`. Data is persisted in the `bink-registry-data` volume.
84
84
@@ -128,9 +128,9 @@ Including the cluster name in the hash avoids IP and MAC collisions when multipl
128
128
129
129
### DNS
130
130
131
-
dnsmasq runs on node1 and provides name resolution for the cluster network. All other nodes are configured (via cloud-init) to use node1's cluster IP as their DNS server.
131
+
A dedicated DNS container (`k8s-<cluster>-dns`) runs dnsmasq on the Podman bridge network and provides name resolution for the cluster network. All nodes are configured (via cloud-init) to use this DNS container as their nameserver.
132
132
133
-
When a new node joins, its hostname and cluster IP are added to `/var/lib/dnsmasq/cluster-hosts`on node1, and dnsmasq is restarted. Entries follow the format: `<cluster-ip> <node-name> <node-name>.cluster.local`.
133
+
When a new node joins, its hostname and cluster IP are added to `/var/lib/dnsmasq/cluster-hosts`in the DNS container, and dnsmasq is reloaded. Entries follow the format: `<cluster-ip> <node-name> <node-name>.cluster.local`.
134
134
135
135
Upstream DNS servers (`8.8.8.8`, `8.8.4.4`) handle external resolution. The search domain is `cluster.local`.
136
136
@@ -147,6 +147,8 @@ Podman bridge (10.88.0.0/16)
147
147
│
148
148
├── k8s-dev-haproxy ──→ TCP LB across control-plane nodes:6443
149
149
│
150
+
├── k8s-dev-dns ──→ dnsmasq (cluster DNS, 53/udp)
151
+
│
150
152
├── k8s-dev-node1 ──→ VM NIC1 (passt): internet + port fwd
151
153
│ ──→ VM NIC2 (mcast): 10.0.0.x/24
152
154
│
@@ -219,7 +221,7 @@ A cluster starts with a single control-plane node (`node1`) and can grow by addi
219
221
### Adding Nodes
220
222
221
223
1. Create a new container and VM (same process as node1)
222
-
2. Register the new node's hostname and IP in dnsmasq on node1
224
+
2. Register the new node's hostname and IP in the cluster DNS container
223
225
3. Generate a join token on the control-plane: `kubeadm token create --print-join-command`
224
226
4. For control-plane nodes: upload certificates and join with `--control-plane`, then update HAProxy config
225
227
5. For worker nodes: join and label with `node-role.kubernetes.io/worker=worker`
0 commit comments