Paul Payne
21d89c2b79
- Updated the namespace for the internal wildcard certificate from 'internal' to 'cert-manager'. - Adjusted the DNS zone selectors in Let's Encrypt configurations to use CLOUDFLARE_DOMAIN consistently. - Changed the namespace for the wildcard certificate from 'default' to 'cert-manager'. - Modified ExternalDNS configuration to use OWNER_ID instead of CLUSTER_ID for TXT owner ID. - Cleaned up setup-cert-manager.sh by removing unnecessary internal namespace creation and secret duplication. - Updated certificate wait commands to reflect the new namespace structure. - Simplified the copying of certificates to the example-admin namespace. - Removed test service deployment from setup-externaldns.sh for a cleaner setup process.
Infrastructure setup scripts
Creates a fully functional personal cloud infrastructure on a bare metal Kubernetes (k3s) cluster that provides:
- External access to services via configured domain names (using ${DOMAIN})
- Internal-only access to admin interfaces (via internal.${DOMAIN} subdomains)
- Secure traffic routing with automatic TLS
- Reliable networking with proper load balancing
Architecture
Internet → External DNS → MetalLB LoadBalancer → Traefik → Kubernetes Services
↑
Internal DNS
↑
Internal Network
Key Components
- MetalLB - Provides load balancing for bare metal clusters
- Traefik - Handles ingress traffic, TLS termination, and routing
- cert-manager - Manages TLS certificates
- CoreDNS - Provides DNS resolution for services
- Kubernetes Dashboard - Web UI for cluster management (accessible via https://dashboard.internal.${DOMAIN})
Configuration Approach
All infrastructure components use a consistent configuration approach:
- Environment Variables - All configuration settings are managed using environment variables loaded by running
source load-env.sh - Template Files - Configuration files use templates with
${VARIABLE}syntax - Setup Scripts - Each component has a dedicated script in
infrastructure_setup/for installation and configuration
Idempotent Design
All setup scripts are designed to be idempotent:
- Scripts can be run multiple times without causing harm
- Each script checks for existing resources before creating new ones
- Configuration updates are applied cleanly without duplication
- Failed or interrupted setups can be safely retried
- Changes to configuration will be properly applied on subsequent runs
This idempotent approach ensures consistent, reliable infrastructure setup and allows for incremental changes without requiring a complete teardown and rebuild.