Series: Zero to Kubernetes — Part 1 · Part 2 · Part 3 · Part 4 · Part 5
In Part 1 we built a Kubernetes cluster with Terraform and kubeadm. Three nodes ready but empty. Today we turn it into a usable platform: external traffic with automatic TLS, storage for databases, namespaces that separate environments, and permissions that prevent a staging deploy from destroying production.
All with Terraform. Zero manual kubectl apply.
Why Terraform for Bootstrap and Not ArgoCD?
This is a question we get a lot. The answer lies in the dependency order:
┌─────────────────────────────────────────┐
│ Terraform (infrastructure + bootstrap) │
│ VMs, networks, kubeadm, namespaces, │
│ ingress, cert-manager, storage, RBAC │
│ ↓ │
│ Terraform installs ArgoCD │
│ ↓ │
│ ArgoCD manages applications │
│ (backend, frontends, DB) │
└─────────────────────────────────────────┘
Terraform manages what ArgoCD needs to exist. Once ArgoCD is running, we hand off application control. If you try to use ArgoCD to bootstrap the ingress controller that ArgoCD needs to expose its own UI, you have a circular problem. Terraform breaks that cycle.
What We're Building Today
┌──────────────────────────────────────────────┐
│ INTERNET │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ nginx ingress │ │
│ │ (NodePort 30080) │ │
│ │ + cert-manager │ │
│ │ + Let's Encrypt │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌──────────┐ ┌──────────────┐ │
│ │production│ │ staging │ │infrastructure│ │
│ │namespace │ │namespace │ │ namespace │ │
│ └────────┘ └──────────┘ └──────────────┘ │
│ │
│ Storage: local-path-provisioner (PVC) │
│ RBAC: ServiceAccounts + Roles │
└──────────────────────────────────────────────┘
Step 1: Connect Terraform to the Cluster
We need the Kubernetes provider pointing to the cluster we created in Part 1:
provider "kubernetes" {
host = "https://${hcloud_server.control_plane.ipv4_address}:6443"
client_certificate = base64decode(var.k8s_client_cert)
client_key = base64decode(var.k8s_client_key)
cluster_ca_certificate = base64decode(var.k8s_ca_cert)
}
provider "helm" {
kubernetes {
host = "https://${hcloud_server.control_plane.ipv4_address}:6443"
client_certificate = base64decode(var.k8s_client_cert)
client_key = base64decode(var.k8s_client_key)
cluster_ca_certificate = base64decode(var.k8s_ca_cert)
}
}
Practical note: For this tutorial, we extract certificates from the kubeconfig. In production, use a secrets backend (Vault, AWS Secrets Manager) and inject them as environment variables.
Step 2: Namespaces — the Foundation of Everything
Namespaces are the logical isolation unit in Kubernetes. Without them, all resources live in default and chaos is guaranteed:
resource "kubernetes_namespace" "production" {
metadata {
name = "production"
labels = {
environment = "production"
managed-by = "terraform"
}
}
}
resource "kubernetes_namespace" "staging" {
metadata {
name = "staging"
labels = {
environment = "staging"
managed-by = "terraform"
}
}
}
resource "kubernetes_namespace" "infrastructure" {
metadata {
name = "infrastructure"
labels = {
environment = "infrastructure"
managed-by = "terraform"
}
}
}
resource "kubernetes_namespace" "argocd" {
metadata {
name = "argocd"
labels = {
environment = "infrastructure"
managed-by = "terraform"
}
}
}
The convention: production for real workloads, staging for pre-production testing, infrastructure for system components (ingress, cert-manager, storage), argocd for the GitOps tool.
Step 3: Storage — local-path-provisioner
Kubernetes needs a StorageClass that dynamically creates PersistentVolumes when a pod requests a PVC. On Hetzner we use local-path-provisioner (from Rancher), which creates volumes on the node's local disk:
resource "helm_release" "local_path_provisioner" {
name = "local-path-provisioner"
namespace = kubernetes_namespace.infrastructure.metadata[0].name
repository = "https://rancher.github.io/local-path-provisioner"
chart = "local-path-provisioner"
version = "0.0.28"
set {
name = "storageClass.defaultClass"
value = "true"
}
set {
name = "nodePathMap[0].node"
value = "DEFAULT_PATH_FOR_NON_LISTED_NODES"
}
set {
name = "nodePathMap[0].paths[0]"
value = "/var/local-path-provisioner"
}
}
Why not Rook/Ceph? For a modest 3-node cluster, Ceph is overengineering. local-path-provisioner is perfect: data lives in /var/local-path-provisioner on the node where the pod runs. The limitation is that if that node dies, the volume is lost. For serious production, you'd later migrate to Longhorn (replication) or use cloud volumes (Hetzner volumes).
Step 4: nginx Ingress Controller — the Front Door
The ingress controller is the reverse proxy that receives external traffic and routes it to the correct Services inside the cluster. We use nginx, the most battle-tested in the ecosystem:
resource "helm_release" "ingress_nginx" {
name = "ingress-nginx"
namespace = kubernetes_namespace.infrastructure.metadata[0].name
repository = "https://kubernetes.github.io/ingress-nginx"
chart = "ingress-nginx"
version = "4.11.2"
set {
name = "controller.service.type"
value = "NodePort"
}
set {
name = "controller.service.nodePorts.http"
value = "30080"
}
set {
name = "controller.service.nodePorts.https"
value = "30443"
}
set {
name = "controller.config.proxy-body-size"
value = "50m"
}
set {
name = "controller.config.proxy-read-timeout"
value = "60"
}
set {
name = "controller.config.proxy-send-timeout"
value = "60"
}
}
Important details:
- We use
NodePortbecause Hetzner doesn't have a native LoadBalancer. The ingress listens on port 30080 (HTTP) and 30443 (HTTPS) on every node -
proxy-body-size: 50mallows file uploads - Proxy timeouts at 60s prevent long requests (migrations, backups) from being cut off
Step 5: cert-manager — Automatic TLS with Let's Encrypt
Nobody should be managing TLS certificates manually in 2026. cert-manager creates them, renews 30 days before expiry, and injects them as Secrets:
resource "helm_release" "cert_manager" {
name = "cert-manager"
namespace = kubernetes_namespace.infrastructure.metadata[0].name
repository = "https://charts.jetstack.io"
chart = "cert-manager"
version = "1.16.1"
set {
name = "installCRDs"
value = "true"
}
set {
name = "prometheus.enabled"
value = "false"
}
}
After installing cert-manager, create the ClusterIssuers:
# Staging — for testing, no strong rate limits
resource "kubernetes_manifest" "cluster_issuer_staging" {
manifest = {
apiVersion = "cert-manager.io/v1"
kind = "ClusterIssuer"
metadata = {
name = "letsencrypt-staging"
}
spec = {
acme = {
server = "https://acme-staging-v02.api.letsencrypt.org/directory"
email = var.letsencrypt_email
privateKeySecretRef = {
name = "letsencrypt-staging-account-key"
}
solvers = [{
http01 = {
ingress = { class = "nginx" }
}
}]
}
}
}
}
# Production — real certificates
resource "kubernetes_manifest" "cluster_issuer_production" {
manifest = {
apiVersion = "cert-manager.io/v1"
kind = "ClusterIssuer"
metadata = {
name = "letsencrypt-production"
}
spec = {
acme = {
server = "https://acme-v02.api.letsencrypt.org/directory"
email = var.letsencrypt_email
privateKeySecretRef = {
name = "letsencrypt-production-account-key"
}
solvers = [{
http01 = {
ingress = { class = "nginx" }
}
}]
}
}
}
depends_on = [helm_release.cert_manager]
}
Step 6: Minimum Viable RBAC
For this tutorial we need a ServiceAccount that applications will use:
resource "kubernetes_service_account" "apps" {
metadata {
name = "apps-sa"
namespace = kubernetes_namespace.production.metadata[0].name
}
}
resource "kubernetes_role" "apps" {
metadata {
name = "apps-role"
namespace = kubernetes_namespace.production.metadata[0].name
}
rule {
api_groups = [""]
resources = ["pods", "services", "configmaps", "secrets"]
verbs = ["get", "list", "watch"]
}
rule {
api_groups = ["apps"]
resources = ["deployments"]
verbs = ["get", "list", "watch"]
}
}
resource "kubernetes_role_binding" "apps" {
metadata {
name = "apps-rolebinding"
namespace = kubernetes_namespace.production.metadata[0].name
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = kubernetes_role.apps.metadata[0].name
}
subject {
kind = "ServiceAccount"
name = kubernetes_service_account.apps.metadata[0].name
namespace = kubernetes_namespace.production.metadata[0].name
}
}
This is intentionally restrictive: apps can read resources but not modify or create them. In Part 4 we'll configure a specific ServiceAccount for the backend with Secret read permissions.
What You Learned in This Part
- Namespaces as an isolation layer between environments
- Why Terraform manages bootstrap and ArgoCD manages apps
- nginx ingress controller exposed via NodePort
- cert-manager + Let's Encrypt for automatic TLS with renewal
- local-path-provisioner as a dynamic StorageClass
- Minimum viable RBAC with ServiceAccounts, Roles and RoleBindings
- The
ClusterIssuer→Ingress annotation→Secret TLS→ ready certificate flow
In Part 3, we'll deploy ArgoCD, configure GitOps with the app-of-apps pattern, and have our first automated deployment from GitHub.
At Guayoyo Tech, we don't just write tutorials — we design and deploy architectures like this for real companies. Kubernetes, Terraform, ArgoCD, CI/CD pipelines, and the entire cloud-native ecosystem: we build it with you, no hype, no vendor lock-in. Want your infrastructure to look like what you just read? Talk to us free for 15 minutes. Your cluster, your cloud, your rules — we bring the engineering.
Top comments (0)