Kubernetes Provider · Cluster como Código

La configuración es mínima: el bloque terraform declara el provider requerido y el bloque provider apunta al kubeconfig de k3s. Sin credenciales hardcodeadas, sin configuración de cluster — todo se deriva del kubeconfig.

terraform {
  required_version = ">= 1.7"
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.30"
    }
  }
}

provider "kubernetes" {
  config_path = var.kubeconfig_path
}

Tres recursos en main.tf. Cada uno declara el estado deseado del objeto en Kubernetes. OpenTofu se encarga de crearlo, actualizarlo o recrearlo si se modifica o elimina manualmente.

resource "kubernetes_namespace" "aiops" {
  metadata {
    name = "aiops"
    labels = {
      "app.kubernetes.io/part-of" = "aiops-lab"
      "managed-by"                = "opentofu"
    }
  }
}

resource "kubernetes_config_map" "prometheus" {
  metadata {
    name      = "prometheus-config"
    namespace = kubernetes_namespace.aiops.metadata[0].name
  }
  data = {
    "prometheus.yml"  = <<-YAML
      global:
        scrape_interval: 15s
      scrape_configs:
        - job_name: "prometheus"
        - job_name: "node-exporter"
        - job_name: "k3s-metrics"
    YAML
    "alert_rules.yml" = <<-YAML
      groups:
        - name: aiops-alerts
          rules:
            - alert: HighCPU
            - alert: DiskSpaceLow
            - alert: ServiceDown
    YAML
  }
}

resource "kubernetes_config_map" "grafana" {
  metadata {
    name      = "grafana-datasources"
    namespace = kubernetes_namespace.aiops.metadata[0].name
  }
  data = {
    "datasources.yml" = <<-YAML
      apiVersion: 1
      datasources:
        - name: Prometheus
          type: prometheus
          url: http://prometheus:9090
        - name: Loki
          type: loki
          url: http://loki:3100
    YAML
  }
}

OpenTofu resuelve automáticamente el orden de creación basándose en las referencias entre recursos. Los ConfigMaps referencian kubernetes_namespace.aiops.metadata[0].name, lo que crea una dependencia implícita: el namespace se crea antes que los ConfigMaps.

OpenTofu construye un grafo dirigido acíclico (DAG) a partir de estas referencias. Orden de creación: namespace → ambos ConfigMaps en paralelo. Orden de destrucción: inverso (ConfigMaps → namespace). Esto evita intentar crear un ConfigMap en un namespace que todavía no existe.

Cuatro variables parametrizan el comportamiento del stack local. Todas tienen defaults razonables para el lab — solo hace falta modificarlas para cambiar el namespace o la ruta del kubeconfig.

Los outputs del stack local exponen el nombre del namespace y de los ConfigMaps creados. Útiles para scripts que necesitan saber dónde se desplegó el stack.

output "namespace_name" {
  description = "Nombre del namespace creado"
  value       = kubernetes_namespace.aiops.metadata[0].name
}

output "prometheus_configmap_name" {
  description = "Nombre del ConfigMap de Prometheus"
  value       = kubernetes_config_map.prometheus.metadata[0].name
}

output "grafana_configmap_name" {
  description = "Nombre del ConfigMap de Grafana"
  value       = kubernetes_config_map.grafana.metadata[0].name
}

Todos los recursos gestionados por OpenTofu llevan labels que identifican su origen y pertenencia. Esto es práctica de producción: cuando hay decenas de recursos en un cluster, saber cuál herramienta los creó evita conflictos.