A teaching-first, single-cluster GitOps setup: Talos Linux + Argo CD with an app-of-apps layout, MetalLB pre-installed for real LoadBalancer IPs on bare metal, a demo app, and a progressive docs/ walkthrough with a CLAUDE.md tutor persona and guided bootstrap checklist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
30 lines
1.5 KiB
YAML
30 lines
1.5 KiB
YAML
# Tells MetalLB which IP addresses it's allowed to hand out to Services.
|
||
# Pick a small range on your LAN that nothing else will ever assign —
|
||
# especially your router's DHCP server. MetalLB doesn't coordinate with
|
||
# your router or DHCP server at all; it just answers network requests for
|
||
# whatever address a Service claims from this range. If it overlaps your
|
||
# DHCP range, you'll eventually get two devices claiming the same IP.
|
||
#
|
||
# >> Ask Claude to help you pick this range before editing it — it needs
|
||
# to know your LAN's subnet and DHCP range, which it can't guess.
|
||
# A typical home LAN answer looks like "my router hands out
|
||
# 192.168.1.100–192.168.1.199, so let's use 192.168.1.240–192.168.1.250."
|
||
#
|
||
# This file lives under apps/metallb/templates/ alongside MetalLB's own
|
||
# Helm-installed resources, rather than as a separate app, because it
|
||
# depends on the CRD that chart installs — Kubernetes needs to know what
|
||
# an IPAddressPool *is* before it can accept one. The sync-wave annotation
|
||
# is what keeps that order correct: Argo CD applies wave "0" (this chart's
|
||
# own resources, including the CRDs) first, waits for it to be healthy,
|
||
# then applies wave "1" (this file and l2advertisement.yaml).
|
||
apiVersion: metallb.io/v1beta1
|
||
kind: IPAddressPool
|
||
metadata:
|
||
name: default-pool
|
||
namespace: metallb-system
|
||
annotations:
|
||
argocd.argoproj.io/sync-wave: "1"
|
||
spec:
|
||
addresses:
|
||
- 192.168.1.240-192.168.1.250 # EDIT ME — replace with your chosen range
|