Skip to content

Wetopi Platform — Memoria técnica y ejecutiva de decisiones recientes

RKE2, networking, GitOps, Vault y bootstrap para Codex

Fecha: 28 de agosto de 2026
Estado: Decisiones consolidadas para implementación
Organización GitHub: wetopi-platform
Audiencia principal: Codex / agentes de implementación / operadores SRE
Objetivo: preservar el contexto técnico y ejecutivo de las últimas decisiones para continuar el proyecto sin reabrir debates ya cerrados.

Índice

  1. Resumen ejecutivo
  2. Contexto del proyecto
  3. Decisiones consolidadas
  4. RKE2 y topología inicial
  5. Bootstrap externo y wetopi-ops01
  6. Organización GitHub y repos
  7. OpenTofu + Ansible
  8. Networking de las VMs
  9. Ceph existente
  10. CIDRs propuestos
  11. Cilium + Hubble
  12. Ingress WAN: IPVS + VRRP + DSR
  13. Edge nodes
  14. Traefik + Gateway API
  15. Sustitución de Consul/Registrator/consul-template
  16. Egress simple con NATGW Ubuntu
  17. Selección de egress por site/customer
  18. Argo CD
  19. Infisical como Wetopi Vault
  20. SOPS + age como bootstrap
  21. Kubernetes Secrets como materialización runtime
  22. Modelo de acceso de agentes a secrets
  23. Tool runtimes y aislamiento de credenciales
  24. Hermes personales y coding agents
  25. ServiceAccounts, RBAC y namespaces
  26. Secrets encryption at rest
  27. Orden de bootstrap actualizado
  28. Primeras tareas para Codex
  29. Decisiones aún abiertas
  30. Criterios de aceptación
  31. Resumen final para implementación
  32. PLATFORM-018 — CNI Cilium desde el día uno (sin Canal provisional)

1. Resumen ejecutivo

Wetopi está reconstruyendo su plataforma de Managed WordPress Hosting desde Docker Swarm hacia una nueva base RKE2 sobre su cloud privado Proxmox + Ceph.

La nueva plataforma debe ser AI-first y operable tanto por humanos como por agentes.

Las decisiones ya cerradas son:

Kubernetes distribution:
RKE2

CNI:
Cilium

Network observability:
Hubble

GitOps:
Argo CD

Vault / secrets manager:
Infisical self-hosted

Bootstrap secret encryption:
SOPS + age

Infrastructure as Code:
OpenTofu + Ansible

Ingress WAN:
mantener IPVS + VRRP + DSR inicialmente

Proxy edge inicial:
Traefik

HTTP routing:
Gateway API

Egress:
NATGW Ubuntu simples con gateway interno estable y WAN IP cambiable

El cluster inicial se construirá greenfield, en paralelo al Docker Swarm actual. No habrá big-bang.

La plataforma se levantará primero, se validará, y después se migrarán edge nodes, hosting workers y sites de forma progresiva.

2. Contexto del proyecto

Wetopi es un Managed WordPress Hosting ejecutado actualmente sobre:

OVH
 ↓
vRack
 ↓
Proxmox
 ↓
Ceph
 ↓
Docker Swarm

El workload principal son wepod, aproximadamente un contenedor por website, con:

s6
nginx
php-fpm
mysql

El tráfico WAN actual utiliza:

VIP
 ↓
VRRP / Keepalived
 ↓
IPVS
 ↓
DSR
 ↓
WAN nginx proxies
 ↓
Swarm workloads

El descubrimiento de backends se realiza mediante:

Registrator
 ↓
Consul
 ↓
consul-template
 ↓
nginx.conf

La nueva plataforma debe preservar las propiedades valiosas de esta arquitectura, especialmente DSR y la distribución del ancho de banda de salida entre distintos hosts físicos de OVH.

3. Decisiones consolidadas

PLATFORM-001 — RKE2

RKE2 será la distribución Kubernetes de producción.

PLATFORM-002 — Greenfield

El cluster nuevo se construirá en paralelo a Swarm.

PLATFORM-003 — 3 control planes

El control plane inicial tendrá tres nodos RKE2 server con embedded etcd.

PLATFORM-004 — 3 platform workers

Inicialmente habrá tres workers dedicados a servicios de plataforma.

PLATFORM-005 — Bootstrap externo

Kubernetes se construye desde fuera del cluster.

PLATFORM-006 — wetopi-ops01

Existirá una VM externa de operaciones, bootstrap y recovery.

PLATFORM-007 — Cilium

Cilium será el CNI.

PLATFORM-008 — Hubble

Hubble será la base de network observability.

PLATFORM-009 — Argo CD

Argo CD será el sistema GitOps.

PLATFORM-010 — Infisical

Infisical self-hosted será el Vault operativo de Wetopi.

PLATFORM-011 — SOPS + age

SOPS + age se utilizará para bootstrap secrets, no como Vault principal.

PLATFORM-012 — IPVS/DSR

Se preserva IPVS + VRRP + DSR inicialmente.

PLATFORM-013 — Traefik

Traefik será el proxy edge inicial.

PLATFORM-014 — Gateway API

El routing HTTP se expresará con Gateway API.

PLATFORM-015 — Egress simple

Se usarán NATGW Ubuntu simples con gateway interno estable y WAN IP cambiable.

PLATFORM-016 — No Istio inicialmente

No se desplegará service mesh sin necesidad concreta.

PLATFORM-017 — No BGP como requisito inicial

La plataforma no dependerá de BGP para arrancar.

4. RKE2 y topología inicial

Se crearán inicialmente:

1 x wetopi-ops01
3 x RKE2 control plane
3 x platform workers

Total inicial:

7 VMs

Nombres previstos:

wetopi-ops01

rke-cp01
rke-cp02
rke-cp03

rke-platform01
rke-platform02
rke-platform03

Los control planes y workers deben distribuirse entre distintos hosts Proxmox.

Ejemplo:

pve01 -> rke-cp01 + rke-platform01
pve02 -> rke-cp02 + rke-platform02
pve03 -> rke-cp03 + rke-platform03

La distribución real deberá validarse con el inventario.

5. Bootstrap externo y wetopi-ops01

La regla es:

Kubernetes no debe depender de servicios internos de Kubernetes para poder crearse o repararse.

Modelo:

Laptop
  │
Codex
  │
GitHub
  │
wetopi-ops01
  │
OpenTofu + Ansible
  │
Proxmox
  │
RKE2

Codex trabajará inicialmente desde el laptop del operador.

wetopi-ops01 será la máquina durable de bootstrap y disaster recovery.

Debe tener, como mínimo:

git
ssh
ansible
opentofu
kubectl
helm
jq
yq

No alojará workloads productivos.

6. Organización GitHub y repos

Organización:

wetopi-platform

Repos iniciales:

wetopi-platform/infrastructure
wetopi-platform/agent-services
wetopi-platform/ai-hub
wetopi-platform/agents
wetopi-platform/docs

No crear repos adicionales sin necesidad real.

7. OpenTofu + Ansible

Se selecciona:

OpenTofu
+
Ansible

OpenTofu:

  • crea VMs;
  • configura recursos Proxmox;
  • modela infraestructura declarativa.

Ansible:

  • baseline Ubuntu;
  • sysctl;
  • paquetes;
  • RKE2;
  • configuración de hosts;
  • operaciones bootstrap.

Git es source of truth.

No se considera válido dejar cambios permanentes solo en shell history.

8. Networking de las VMs

Cada VM tendrá inicialmente:

1 NIC LAN

Modelo:

VM
 └── eth0
      └── LAN / vRack

No se introducirán múltiples interfaces salvo necesidad demostrada.

9. Ceph existente

La red Ceph actual es:

192.168.96.0/20

Es parte de la infraestructura hiperconvergida Proxmox + Ceph.

Decisión:

NO modificar, renumerar ni rediseñar esta red.

Ceph se consumirá desde Kubernetes mediante CSI.

La conectividad exacta entre RKE2 nodes y Ceph debe comprobarse, no asumirse.

10. CIDRs propuestos

Propuesta actual:

Node LAN:
pendiente de inventario real

Pod CIDR:
10.64.0.0/14

Service CIDR:
10.68.0.0/16

Ceph:
192.168.96.0/20
EXISTENTE / NO TOCAR

Los CIDRs definitivos deben validarse contra todas las redes Wetopi existentes.

11. Cilium + Hubble

Cilium será el CNI base.

Primera versión:

Cilium
+
VXLAN encapsulation
+
Hubble

Razón de VXLAN inicial:

  • mínima dependencia de underlay;
  • no requiere que la red física conozca PodCIDRs;
  • simplifica bootstrap;
  • una sola NIC por VM.

No activar inicialmente:

  • BGP WAN;
  • service mesh;
  • egress avanzado;
  • features experimentales innecesarias.

Hubble se utilizará para flows y correlación de tráfico con pods/namespaces/sites.

12. Ingress WAN: IPVS + VRRP + DSR

El frontend actual se conserva inicialmente.

Internet
 ↓
VIP
 ↓
VRRP
 ↓
IPVS
 ↓
DSR
 ↓
RKE2 Edge

Motivo principal:

DSR permite que cada edge node responda directamente a Internet usando el uplink/bandwidth domain del host físico Proxmox/OVH donde corre.

Esto permite agregar capacidad de salida entre varios hosts físicos.

Esta propiedad no debe perderse durante la migración.

13. Edge nodes

Los antiguos WAN proxies evolucionarán a RKE2 edge workers.

Ejemplo:

rke-edge-a01
rke-edge-a02
rke-edge-b01
rke-edge-b02

Labels:

wetopi.io/role=edge
wetopi.io/wan-zone=a
wetopi.io/proxmox-host=pve01
wetopi.io/bandwidth-domain=pve01

Taint:

wetopi.io/edge=true:NoSchedule

El proxy se desplegará como DaemonSet cuando tenga sentido mantener una instancia por edge node.

14. Traefik + Gateway API

Se elige Traefik inicialmente.

Razones:

  • sencillo;
  • Kubernetes-native;
  • soporte de Gateway API;
  • TLS;
  • routing dinámico;
  • métricas;
  • separación clara respecto a Cilium.

Modelo:

hostname
 ↓
HTTPRoute
 ↓
Service
 ↓
EndpointSlice
 ↓
Pod

Envoy podrá reevaluarse más adelante si aparecen necesidades L7 más avanzadas.

15. Sustitución de Consul/Registrator/consul-template

Antes:

Docker
 ↓
Registrator
 ↓
Consul
 ↓
consul-template
 ↓
nginx.conf
 ↓
reload

Después:

Pod
 ↓
Service
 ↓
EndpointSlice
 ↓
Gateway controller
 ↓
dynamic routing

Kubernetes será el service registry del hosting.

16. Egress simple con NATGW Ubuntu

No se construirá inicialmente un egress control plane complejo.

Modelo base:

gw100
LAN: 192.168.88.100
WAN: PUBLIC_IP_A

gw101
LAN: 192.168.88.101
WAN: PUBLIC_IP_B

gw102
LAN: 192.168.88.102
WAN: PUBLIC_IP_C

Cada gateway:

Ubuntu
+
routing
+
nftables/iptables
+
SNAT

Objetivo:

  • fácil de operar;
  • fácil de cambiar;
  • fácil de observar;
  • fácil de separar reputación.

17. Selección de egress por site/customer

Modelo lógico:

site/customer
 ↓
egress_gateway
 ↓
gw100 / gw101 / gw102

Ejemplo:

wetopi.io/egress-gateway: gw101

La implementación inicial puede usar:

  • policy routing;
  • automatización ligera;
  • helper/DaemonSet que observe labels y mantenga reglas.

No construir todavía un controlador complejo.

Futuro:

CiliumEgressGatewayPolicy

puede sustituir el mecanismo sin cambiar el modelo lógico.

Separar desde el inicio:

hosting-general
hosting-premium
platform
agents/crawlers

Los crawlers/agentes no deben compartir IP de salida con customers.

18. Argo CD

Se ha decidido usar:

Argo CD

Razones principales:

  • excelente Web UI;
  • estado Synced/OutOfSync;
  • health;
  • diffs;
  • historial;
  • visibilidad para operadores humanos;
  • modelo declarativo;
  • API/CLI;
  • RBAC/SSO/OIDC futuro.

Modelo:

Git
 ↓
Argo CD
 ↓
Kubernetes

No se utilizará un pipeline CI basado en kubectl apply como mecanismo normal de producción.

Pendiente decidir el layout exacto:

  • App of Apps;
  • ApplicationSet;
  • AppProjects;
  • estructura por cluster/environment.

19. Infisical como Wetopi Vault

El Vault operativo de Wetopi será:

Infisical self-hosted

El requisito real no es solamente almacenar secrets declarativos.

Se necesita un servicio vivo donde humanos y agentes puedan:

  • crear credentials;
  • guardar username/password;
  • guardar API tokens;
  • guardar SSH keys;
  • recuperar secrets;
  • rotarlos;
  • listarlos;
  • actualizarlos;
  • auditarlos;
  • compartirlos con servicios.

Ejemplo conceptual:

vault.put(
  path="/platform/proxmox/api",
  username="automation",
  password="..."
)

Infisical será el source of truth operativo de credentials.

20. SOPS + age como bootstrap

SOPS NO será el Vault principal.

Se utilizará únicamente para bootstrap.

Modelo:

Git
 ↓
SOPS + age
 ↓
bootstrap secrets
 ↓
Infisical starts

SOPS protege los secretos necesarios para levantar:

  • Infisical;
  • integración inicial de Argo CD;
  • bootstrap identities;
  • recovery material mínimo.

Una vez Infisical funciona, los nuevos credentials se guardan en Infisical, no en Git.

Debe existir al menos una recovery key age fuera del cluster y fuera de Git.

21. Kubernetes Secrets como materialización runtime

Modelo:

Infisical
    │
    │ sync/operator
    ▼
Kubernetes Secret
    │
    ▼
Deployment / Pod

Infisical es source of truth.

Kubernetes Secret es materialización runtime.

Esto permite:

  • cambiar un secret centralmente;
  • sincronizarlo al cluster;
  • consumirlo con mecanismos nativos de Kubernetes.

22. Modelo de acceso de agentes a secrets

La regla principal es:

el agente debe poder USAR un secret sin necesidad de VER su valor cuando sea posible.

Ejemplo:

Hermes
  │
  │ tool call
  ▼
platform-tools
  │
  │ reads secret from Infisical/K8s Secret
  ▼
Proxmox / Cloudflare / OVH

El LLM no necesita recibir el token.

23. Tool runtimes y aislamiento de credenciales

No montar todos los secrets directamente en el proceso LLM.

Agrupar tools por security domain.

Ejemplo:

platform-tools
├── kubernetes
├── proxmox
├── ceph
└── networking

wordpress-tools
├── wordpress
├── mysql
└── backups

marketing-tools
├── intercom
├── analytics
└── ...

Cada runtime recibe únicamente los secrets necesarios.

No crear un sidecar por tool individual.

En ai-hub, las tools deberían declarar sus requirements.

Ejemplo:

tool: proxmox.vm_restart
runtime: platform-tools
secrets:
  - proxmox-api-token

Los agentes deben consumir un contrato propio Wetopi, no acoplarse directamente a Infisical.

API conceptual:

vault.get()
vault.put()
vault.update()
vault.delete()
vault.list()
vault.exists()

24. Hermes personales y coding agents

Hermes personales/coding agents necesitarán operar la plataforma.

Podrán:

  • llamar tools privilegiadas;
  • usar credentials;
  • escribir secrets en Vault;
  • recuperar credentials autorizados;
  • operar GitHub;
  • operar Proxmox;
  • operar Kubernetes.

Pero:

  • no recibir todas las credenciales en env;
  • no montar un vault global;
  • no dar acceso indiscriminado a todos los paths.

El permiso debe seguir el rol.

Ejemplo conceptual:

Hermes SRE
  /platform/*
  /infrastructure/*
  /agents/hermes-sre/*

Hermes Developer
  /development/*
  /github/*
  /agents/hermes-developer/*

Hermes Marketing
  /marketing/*
  /agents/hermes-marketing/*

25. ServiceAccounts, RBAC y namespaces

Para operar Kubernetes, los agentes dentro del cluster usarán:

ServiceAccount
+
RBAC

No kubeconfig estático ni password.

Ejemplo:

Hermes SRE
 -> permisos operacionales amplios

Hermes Developer
 -> namespaces dev + deployments

ADK observer
 -> readonly

ADK specialist
 -> permissions específicas

Namespaces orientativos:

wetopi-platform
wetopi-edge
wetopi-hosting
wetopi-agents-sre
wetopi-agents-development
wetopi-agents-marketing
wetopi-observability
wetopi-security

Los namespaces forman parte de la frontera de secrets y RBAC.

Importante:

quien puede crear Pods en un namespace puede potencialmente montar Secrets de ese namespace.

Por tanto, permisos de workload creation y secret access deben diseñarse conjuntamente.

26. Secrets encryption at rest

SOPS protege Git.

Infisical protege el Vault.

Kubernetes Secrets materializados deben protegerse en etcd.

RKE2 deberá tener:

Secrets Encryption at Rest

habilitado.

Modelo:

Infisical
 ↓
Kubernetes Secret
 ↓
RKE2 API server
 ↓
encrypted etcd storage

27. Orden de bootstrap actualizado

Orden actual recomendado:

1. GitHub organization + repos
2. Inventario Proxmox/redes
3. OpenTofu + Ansible
4. wetopi-ops01
5. 3 x RKE2 control plane
6. 3 x platform workers
7. RKE2 HA + etcd
8. Cilium
9. Hubble
10. Ceph CSI
11. Argo CD
12. SOPS + age bootstrap
13. Infisical
14. Kubernetes Secrets integration/operator
15. Docs
16. Memory Plane
17. Work Ledger
18. AI Hub
19. Hermes
20. ADK Fleet
21. Edge nodes
22. Gateway API + Traefik
23. NATGW
24. first hosting workers
25. first websites
26. progressive migration from Swarm

28. Primeras tareas para Codex

Task 1 — Crear repos

Crear:

infrastructure
agent-services
ai-hub
agents
docs

Aplicar:

  • README;
  • CODEOWNERS;
  • branch protection;
  • CI mínima;
  • convenciones.

Task 2 — Inventario Proxmox

Recoger:

  • nodos;
  • CPU;
  • RAM;
  • storage;
  • bridges;
  • VLANs;
  • redes;
  • IP ranges;
  • failure domains;
  • bandwidth domains.

No crear aún direccionamiento inventado.

Task 3 — Validar redes

Confirmar que:

Pod CIDR 10.64.0.0/14
Service CIDR 10.68.0.0/16

no colisionan.

Confirmar conectividad RKE2 node -> Ceph 192.168.96.0/20.

Task 4 — Ubuntu template

Crear template reproducible Ubuntu 24.04 + cloud-init.

Task 5 — wetopi-ops01

Crear/provisionar wetopi-ops01.

Task 6 — Control plane

Crear:

rke-cp01
rke-cp02
rke-cp03

Task 7 — Platform workers

Crear:

rke-platform01
rke-platform02
rke-platform03

Task 8 — RKE2

Configurar:

  • embedded etcd;
  • HA;
  • API endpoint estable;
  • secrets encryption;
  • snapshots.

Task 9 — Cilium/Hubble

Desplegar:

  • Cilium VXLAN;
  • Hubble;
  • networking tests.

Task 10 — Ceph CSI

Validar:

  • PVC create;
  • mount;
  • pod restart;
  • persistence.

Task 11 — Argo CD

Desplegar declarativamente.

Task 12 — SOPS bootstrap

Generar:

  • age production key;
  • age recovery key;
  • .sops.yaml.

Guardar recovery key fuera del cluster y fuera de Git.

Task 13 — Infisical

Desplegar self-hosted.

Configurar:

  • persistence;
  • backups;
  • admin bootstrap;
  • projects/environments;
  • machine identities mínimas;
  • Kubernetes integration.

Task 14 — Vault contract

Crear en ai-hub una capa estable:

vault.get()
vault.put()
vault.update()
vault.delete()
vault.list()
vault.exists()

Los agentes no deben quedar acoplados a la API concreta de Infisical.

29. Decisiones aún abiertas

29.1 Node LAN CIDR

Pendiente de inventario.

29.2 Endpoint HA de RKE2

Propuesta previa:

2 x HAProxy + Keepalived
+
private VIP

Debe cerrarse antes del deploy final.

29.3 DSR validation

Debe hacerse PoC real con capture.

29.4 Traefik deployment exacto

Definir:

  • hostNetwork;
  • DaemonSet;
  • VIP handling;
  • health endpoint.

29.5 Egress enforcement exacto

Definir implementación inicial de:

site label
 ↓
gateway selection
 ↓
policy routing

29.6 Infisical OSS/licensing

Validar exactamente:

  • features necesarias en self-hosted;
  • machine identities;
  • Kubernetes integration;
  • audit;
  • versioning;
  • posibles límites comerciales.

29.7 GitOps layout

Definir estructura exacta Argo CD:

  • Application;
  • AppProject;
  • App of Apps o ApplicationSet.

29.8 OIDC

Pendiente.

29.9 Backup externo

Pendiente destino definitivo de:

  • etcd snapshots;
  • Infisical DB;
  • SOPS recovery material;
  • Git.

29.10 Observabilidad central

Pendiente arquitectura final.

30. Criterios de aceptación

Antes de desplegar Hermes o workloads reales:

Cluster

  • [ ] pérdida de 1 control plane no interrumpe API;
  • [ ] etcd mantiene quorum;
  • [ ] snapshot etcd funcional;
  • [ ] restore documentado y probado;
  • [ ] workers pueden drain/uncordon.

Networking

  • [ ] pod-to-pod;
  • [ ] pod-to-service;
  • [ ] DNS;
  • [ ] Hubble flows visibles;
  • [ ] no collision CIDRs;
  • [ ] nodes alcanzan Ceph.

Storage

  • [ ] PVC;
  • [ ] delete/recreate pod;
  • [ ] persistencia;
  • [ ] failure test básico.

GitOps

  • [ ] Argo CD reconciles desde Git;
  • [ ] manual drift detectable;
  • [ ] rollback verificable.

Vault

  • [ ] agente/tool puede crear secret;
  • [ ] servicio puede consumir secret;
  • [ ] secret no queda plaintext en Git;
  • [ ] access control validado;
  • [ ] backup de Infisical probado;
  • [ ] recovery bootstrap documentado.

Secrets

  • [ ] SOPS bootstrap funciona;
  • [ ] recovery age key offline;
  • [ ] Kubernetes secrets cifrados at rest;
  • [ ] namespaces/RBAC limitan acceso.

Agentes

  • [ ] Hermes puede usar tool privilegiada sin recibir raw token;
  • [ ] ADK readonly no puede leer secrets ajenos;
  • [ ] coding agent solo accede a vault paths autorizados.

31. Resumen final para implementación

La platform foundation actual queda así:

                      GitHub
               wetopi-platform
                       │
               infrastructure
                       │
                    Codex
                       │
                  wetopi-ops01
                       │
              OpenTofu + Ansible
                       │
                       ▼
                ┌─────────────┐
                │   RKE2 HA   │
                └─────────────┘
                       │
              Cilium + Hubble
                       │
                    Ceph CSI
                       │
                    Argo CD
                       │
                 SOPS bootstrap
                       │
                    Infisical
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   Kubernetes       Tool runtimes    Humans
    Secrets             │           Web UI
        │               │
        └───────────────┼──────────────┐
                        │              │
                      Hermes          ADK

Networking:

INGRESS

Internet
 ↓
VRRP
 ↓
IPVS
 ↓
DSR
 ↓
RKE2 Edge
 ↓
Traefik
 ↓
Gateway API
 ↓
Service
 ↓
Website

EGRESS

Site / Customer
 ↓
egress label/profile
 ↓
gw100 / gw101 / gw102
 ↓
WAN IP
 ↓
Internet

La intención global es mantener la primera versión simple:

  • no Istio;
  • no BGP obligatorio;
  • no controller avanzado de egress;
  • no OpenBao;
  • no service mesh complejo;
  • no rediseño simultáneo de Ceph.

La plataforma se estabiliza primero.

Después se despliegan:

Docs
Memory Plane
Work Ledger
AI Hub
Hermes
ADK
Edge
Hosting

y finalmente se inicia la migración progresiva de Swarm a RKE2.

32. PLATFORM-018 — CNI Cilium desde el día uno (sin Canal provisional)

Fecha: 29 de agosto de 2026 Estado: Decidido (operador). Refina PLATFORM-007 (Cilium será el CNI) y PLATFORM-008 (Hubble). Se graba como PLATFORM-018 — el siguiente identificador libre — porque PLATFORM-008 ya estaba asignado a Hubble en el registro original.

Decisión operativa para el primer addon del cluster RKE2:

  • No habrá CNI provisional Canal. Cilium es el CNI desde el primer nodo y sustituye al Canal que RKE2 instala por defecto: la configuración de rke2-server debe fijar cni: none, y el rol de RKE2 debe mantener deshabilitado el Canal incluido de serie.
  • Chart oficial Cilium fijado a la versión 1.20.1 (oci://quay.io/cilium/charts/cilium, namespace kube-system). Las versiones de chart no llevan prefijo v.
  • Encapsulación VXLAN (routingMode: tunnel, tunnelProtocol: vxlan); sin BGP y sin native routing inicialmente, según el plan maestro (14.4) y PLATFORM-017.
  • IPAM cluster-pool con clusterPoolIPv4PodCIDRList: [10.64.0.0/14] y clusterPoolIPv4MaskSize: 24, coincidiendo exactamente con el pod CIDR de RKE2. RKE2 es quien posee el pod CIDR y el service CIDR (10.68.0.0/16); Cilium no los re-deriva y no toca el CIDR de servicios.
  • kubeProxyReplacement: false en v1: kube-proxy estándar convive con Cilium VXLAN. La sustitución de kube-proxy queda documentada como opción futura.
  • Hubble habilitado con Hubble Relay (hubble.enabled: true, hubble.relay.enabled: true); hubble.ui.enabled: false por defecto, activación opcional documentada.
  • La MTU queda por defecto (auto ~1450 sobre el LAN de nodos MTU 1500).
  • Puertos obligatorios entre nodos: UDP 8472 (VXLAN) y TCP 4244 (Hubble Relay).

Método de instalación: Argo CD no existe todavía en el primer bootstrap, así que el addon se instala desde wetopi-ops01 con Helm durante la fase de apply (playbook ansible/playbooks/cilium.yml en el repo infrastructure). Es una instalación solo de bootstrap: cuando Argo CD exista, la gestión del addon pasa a él y el playbook se retira. Los valores pinneados viven en kubernetes/cilium/values.yaml; la lista de verificación de post-instalación en kubernetes/cilium/VALIDATION.md.

CIDRs: el ownership es de RKE2 (pod CIDR 10.64.0.0/14 y service CIDR 10.68.0.0/16); el pool de Cilium se limita a consumir el rango de pods y nunca debe diverger de la configuración de rke2-server.