# K3s {% hint style="info" %} #### K3s K3s es una distribución de Kubernetes certificada y ligera diseñada para entornos con recursos limitados, computación en el borde, dispositivos IoT y escenarios de desarrollo. Creada por Rancher Labs (ahora parte de SUSE), empaqueta todo lo necesario para ejecutar Kubernetes en un único binario de menos de 100 MB. Esto hace que K3s sea significativamente más ligero que Kubernetes estándar, manteniendo la completa compatibilidad con las API y características de Kubernetes. Requiere memoria mínima (512 MB como mínimo) y ofrece operaciones simplificadas con dependencias reducidas. K3s incluye componentes integrados como el controlador de ingreso Traefik, el aprovisionador de almacenamiento local y un balanceador de carga de servicios. Es perfecto para desarrollo, CI/CD, despliegues en el borde y dispositivos ARM, y aun así está listo para producción con capacidades de alta disponibilidad. {% endhint %}

Arquitectura de K3s y Pentaho Server

{% tabs %} {% tab title="Componentes centrales de K3s" %} {% hint style="info" %} #### Componentes centrales de K3s **Componentes del plano de control** El plano de control incluye el API Server (punto de entrada de la API de Kubernetes para la gestión del clúster), el Controller Manager (gestiona los bucles de control principales para replicación, endpoints y namespaces) y el Scheduler (asigna pods a nodos según la disponibilidad de recursos). K3s puede usar etcd o SQLite liviano como almacén de datos para el estado del clúster, lo que lo hace más flexible que Kubernetes estándar. **Componentes de nodo** Cada nodo ejecuta el agente Kubelet que gestiona el ciclo de vida de los pods. Containerd está integrado como el runtime de contenedores para ejecutar contenedores. Kube-proxy gestiona el proxy de red y el enrutamiento de servicios a lo largo del clúster. **Complementos integrados** K3s incluye el controlador de ingreso Traefik para enrutar tráfico HTTP/HTTPS externo hacia los servicios. El Local Path Provisioner permite el aprovisionamiento dinámico de volúmenes persistentes usando almacenamiento local. CoreDNS proporciona DNS de clúster para el descubrimiento de servicios. El Service Load Balancer gestiona servicios de tipo LoadBalancer sin requerir integraciones con proveedores de nube externos. **Redes** Flannel sirve como el plugin CNI (Container Network Interface) predeterminado para la red de pods. Las Network Policies controlan el flujo de tráfico entre pods y servicios para mayor seguridad. {% endhint %}

Componentes de K3s

{% endtab %} {% tab title="Pod del servidor Pentaho" %} {% hint style="info" %} #### Pod del servidor Pentaho * Ejecuta el servidor de aplicaciones Tomcat con Pentaho Server 11 * Basado en Debian Trixie Slim con OpenJDK 21 JRE * Build Docker multinivel para optimizar el tamaño de la imagen * Expuesto internamente en el puerto 8080 * Incluye probes de readiness y liveness para monitoreo de salud * Límites de recursos configurados para estabilidad de CPU y memoria {% endhint %}

Pod de Pentaho

{% endtab %} {% tab title="Pod de PostgreSQL" %} {% hint style="info" %} Proporciona backend de base de datos relacional para tres bases de datos críticas: * **Jackrabbit** (jcr\_user): Repositorio de Contenido Java que almacena todo el contenido de Pentaho (informes, dashboards, fuentes de datos, transformaciones, jobs) * **Quartz** (pentaho\_user): Scheduler que gestiona jobs, triggers, calendarios e historial de ejecución * **Hibernate** (hibuser): Configuración de seguridad, registro de auditoría, sesiones de usuario, además de dos esquemas especializados: * **pentaho\_dilogs**: Registro de ejecución de ETL con logs de jobs, métricas de transformaciones y datos de rendimiento de pasos * **pentaho\_operations\_mart**: Data mart dimensional para análisis de la plataforma con tablas de dimensión y de hechos * Los datos se persisten mediante PersistentVolumeClaim para sobrevivir a reinicios * Inicialización automatizada mediante scripts SQL montados desde ConfigMap {% endhint %}

Pod de PostgreSQL

Arquitectura de la base de datos PostgreSQL

Pentaho Server requiere tres bases de datos separadas, cada una con un propósito distinto:
Base de datosPropietarioPropósito y Contenido
jackrabbitjcr_userRepositorio de Contenido Java (JCR) - Almacena todo el contenido de Pentaho incluyendo informes, dashboards, fuentes de datos, esquemas de análisis y archivos de usuario. Este es el almacenamiento primario de contenido del repositorio de Pentaho.
quartzpentaho_userQuartz Scheduler - Gestiona todos los jobs programados, triggers y calendarios. Contiene tablas para definiciones de jobs (QRTZ6_JOB_DETAILS), triggers (QRTZ6_TRIGGERS), historial de ejecución y locks de coordinación de clúster.
hibernatehibuserRepositorio Hibernate - Aloja la configuración de seguridad, registro de auditoría, datos de sesiones de usuario, y contiene dos esquemas adicionales: pentaho_dilogs (registro de ejecución de ETL) y pentaho_operations_mart (data mart de análisis).
{% hint style="info" %} La base de datos hibernate contiene esquemas especializados para monitoreo operacional: **pentaho\_dilogs**: Captura información detallada de ejecución de ETL incluyendo logs de jobs, logs de transformaciones, métricas de rendimiento de pasos y registros de errores. Es esencial para depurar flujos de integración de datos y monitorear la salud de las canalizaciones. **pentaho\_operations\_mart**: Un data mart dimensional para análisis del uso de Pentaho. Contiene tablas de dimensión (DIM\_DATE, DIM\_TIME, DIM\_EXECUTOR) y tablas de hechos (FACT\_EXECUTION, FACT\_STEP\_EXECUTION) para analizar la utilización de la plataforma, tendencias de rendimiento y actividad de los usuarios. Para despliegues en producción, implemente copias de seguridad regulares del volumen Docker repository-data. La base de datos jackrabbit es la más crítica ya que contiene todo el contenido de los usuarios. Considere usar pg\_dump para copias lógicas o snapshots de volumen para opciones de recuperación completas. {% endhint %} {% endtab %} {% tab title="Red" %} {% hint style="info" %} #### Redes **Comunicación interna:** * Ambos pods se ejecutan dentro del `pentaho` namespace * Los servicios ClusterIP proporcionan nombres DNS internos estables * PostgreSQL accesible en `postgresql.pentaho.svc.cluster.local:5432` * Pentaho Server accesible en `pentaho-server.pentaho.svc.cluster.local:8080` **Acceso externo:** * El controlador de ingreso Traefik enruta el tráfico externo hacia Pentaho Server * Enrutamiento configurable por hostname y por ruta * Soporte opcional de terminación TLS/SSL {% endhint %} Tomcat gestiona los pools de conexiones definidos en context.xml. Cada pool sirve un propósito específico:
Nombre del poolObjetivo de conexiónUso
jdbc/Hibernaterepository:5432/hibernateSeguridad, Usuarios, Roles
jdbc/Quartzrepository:5432/quartzProgramación de jobs
jdbc/jackrabbitrepository:5432/jackrabbitRepositorio de contenido
jdbc/Auditrepository:5432/hibernateRegistro de auditoría
jdbc/live_logging_inforepository:5432/hibernateLogs de ejecución ETL
jdbc/PDI_Operations_Martrepository:5432/hibernateAnalítica de operaciones
{% endtab %} {% tab title="ConfigMaps de almacenamiento" %} {% hint style="info" %} #### Almacenamiento **PersistentVolumeClaims (PVCs):** * `postgres-pvc`: Directorio de datos de PostgreSQL (`/var/lib/postgresql/data`) * `pentaho-pvc`: Directorios de soluciones y datos de Pentaho **Clase de almacenamiento:** * Usa el `local-path` aprovisionador de almacenamiento * Aprovisiona volúmenes en el sistema de archivos local del nodo * Creación y vinculación automática de volúmenes **ConfigMaps:** * Scripts de inicialización de la base de datos (5 archivos SQL) * Configuraciones de Pentaho (parámetros JVM, ajustes de Tomcat) **Secrets:** * Credenciales de PostgreSQL (postgres\_password, pentaho\_user, pentaho\_password) * Cadenas de conexión JDBC * Codificadas en Base64 por seguridad {% endhint %} {% endtab %} {% endtabs %} {% hint style="danger" %} Antes de comenzar el despliegue en K3s, asegúrese de haber completado la Configuración: [Contenedores Pentaho](/pentaho-11-installation-en/pentaho-11-installation-es/configuracion/contenedores-pentaho.md) {% endhint %} Siga los siguientes pasos para desplegar Pentaho Server en un K3s de nodo único con repositorio PostgreSQL 15. {% tabs %} {% tab title="1. Preparar el entorno " %} {% hint style="info" %} #### Preparar el entorno La sección "Preparar el entorno" describe los pasos de configuración inicial requeridos antes de desplegar Pentaho Server 11 en K3s: * copiar los activos de despliegue a su directorio home, * preparar el archivo ZIP de Pentaho Server Enterprise Edition, verificando que el archivo esté en su lugar, * confirmar que K3s esté correctamente instalado y en ejecución {% endhint %} {% hint style="danger" %} Asegúrese de haber descargado: `pentaho-server-ee-11.0.0.0-237.zip` {% endhint %} 1. Crear directorio y copiar los assets. ```bash cd cd ~/Workshop--Installation/Pentaho-Containers/K3s/Pentaho-K3s-PostgreSQL/scripts chmod +x ./install-to-home.sh ``` 2. Copie pentaho-server-ee-11.0.0.0-237.zip al directorio /docker/stagedArtefacts. {% hint style="info" %} Si ha desplegado un Pentaho Server de archivo, copie desde: `/opt/pentaho/software/pentaho-server-ee-version` De lo contrario descargue el paquete desde el [Portal de clientes de Pentaho](https://support.pentaho.com/hc/en-us). {% endhint %} ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts cp /opt/pentaho/software/server/pentaho-server-ee-11.0.0.0-237.zip . ``` 3. Verifique que el archivo exista. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/docker-build/stagedArtifacts ls -al ``` 4. Verifique la instalación de K3s. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./verify-k3s.sh ``` ```sh # Verificación normal (lo que ejecutaría la mayor parte del tiempo) ./scripts/verify-k3s.sh # Salida detallada para depuración ./scripts/verify-k3s.sh --verbose # Modo silencioso para scripts/automatización ./scripts/verify-k3s.sh --quiet # Obtener ayuda ./scripts/verify-k3s.sh --help ```

verify-k3s.sh

5. Pentaho Server requiere una licencia válida. El `.env` archivo contiene un LICENSE\_URL que apunta al servidor de licencias de Flexera. Asegúrese de que sus derechos de licencia estén activos antes del despliegue. {% hint style="warning" %} Sin una licencia válida, Pentaho Server se iniciará pero muchas funciones estarán deshabilitadas. Verifique el estado de su licencia antes de proceder con despliegues en producción. {% endhint %} **Diferencias clave**
AspectoDespliegue DockerDespliegue K3s
OrquestaciónDocker ComposeKubernetes (K3s)
Configuración.env archivo + docker-compose.ymlManifiestos de Kubernetes (YAML)
SecretsSecrets de Docker o VaultSecrets de Kubernetes
RedesRed puente de DockerRed del clúster K3s + Ingress Traefik
AlmacenamientoVolúmenes de DockerPersistentVolumeClaims (PVCs)
EscaladoManual (docker compose up --scale)Declarativo (réplicas en deployment)
Checks de saludDocker HEALTHCHECKProbes de readiness/liveness de Kubernetes
Scripts de inicializaciónMontaje de volumen en /docker-entrypoint-initdb.dConfigMap montado en el pod de PostgreSQL
{% endtab %} {% tab title="2. Tareas previas" %} {% hint style="info" %} #### Tareas previas La sección de Tareas previas describe los pasos esenciales de preparación necesarios antes de desplegar Pentaho Server 11 en contenedores K3s. **Configurar variables de entorno** Edite el `.env.example` archivo dentro del `docker-build/` directorio con sus ajustes específicos de despliegue. Esto incluye el identificador de versión de Pentaho y el nombre/etiqueta de la imagen Docker. Configure las credenciales de la base de datos PostgreSQL y los parámetros de conexión. Establezca la asignación de memoria JVM con heap mínimo (por defecto 4GB) y heap máximo (por defecto 8GB). Agregue la URL de su servidor de licencias de Enterprise Edition si corresponde. Configure opciones de build incluyendo edición de la imagen (EE/CE), detección de plugins y ajustes de push al registro. Una vez configurado, copie esta plantilla a `.env` para uso del proceso de build. **Directorio softwareOverride** El `softwareOverride/` directorio dentro de `docker-build/` proporciona un mecanismo para personalizar las configuraciones de Pentaho. Estas personalizaciones se incorporan a la imagen Docker durante el proceso de build. Los archivos están organizados en directorios numerados y se procesan en orden alfabético. El **1\_drivers/** el directorio contiene el driver JDBC de PostgreSQL (incluido por defecto), y puede colocar controladores JDBC adicionales aquí. El **2\_repository/** el directorio contiene las configuraciones de conexión a la base de datos para Jackrabbit (JCR), Quartz (scheduler) y los repositorios Hibernate. El **3\_security/** directorio está vacío en este despliegue K3s ya que no hay integración con Vault. El **4\_others/** el directorio contiene scripts modificados de Tomcat (startup.sh, setenv.sh), server.xml y otras configuraciones a nivel de aplicación. Opcionalmente puede actualizar el driver JDBC de PostgreSQL descargándolo de Maven Central o copiándolo desde la colección de drivers de base de datos del workshop. Coloque el driver actualizado en `softwareOverride/1_drivers/tomcat/lib/`. {% endhint %} *** **Configurar .env** 1. Edite la .env.template ```bash cd cd ~/Pentaho-Server-PostgreSQL nano .env.template ``` 2. Ingrese los siguientes detalles:
VariableValor por defectoDescripción
PENTAHO_VERSION11.0.0.0-237Versión de Pentaho Server
EDITIONeeVersión Enterprise
INCLUDE_DEMO1Incluir datos de demostración
IMAGE_TAGpentaho/pentaho-server:11.0.0.0-237Etiqueta de la imagen Docker
PENTAHO_MIN_MEMORY4096mTamaño mínimo del heap JVM
PENTAHO_MAX_MEMORY8192mTamaño máximo del heap JVM
PENTAHO_DI_JAVA_OPTIONS"-Dfile.encoding=utf8 -Djava.awt.headless=true"
PENTAHO_IMAGE_NAMEpentaho/pentaho-serverNombre de la imagen Docker
TZAmerica/NYZona horaria del servidor
DB_TYPEpostgres
DB_HOSTpostgres
DB_PORT5432Puerto HTTP de PostgreSQL
PUSH_TO REGISTRYfalsePublica directamente al registro de K3s
LOAD_INTO_K3StrueCarga directamente en K3s
RUN TESTStrue
LICENSE_URL(vacío)URL del servidor de licencias EE
3. Guardar: ``` CTRL + o Enter CTRL + x ``` 4. Crear .env ```bash cd cd ~/Pentaho-Server-PostgreSQL cp .env.template .env ``` *** **softwareOverride** {% hint style="info" %} El `softwareOverride/` el directorio proporciona un mecanismo potente para personalizar Pentaho Server sin modificar la instalación base. Los archivos se copian en la instalación de Pentaho durante el arranque del contenedor, procesados en orden alfabético por nombre de directorio. {% endhint %} ```` ``` softwareOverride/ ├── 1_drivers/ # Drivers JDBC y conectores de datos │ ├── tomcat/lib/ │ │ └── postgresql-42.x.x.jar # Driver JDBC de PostgreSQL (incluido) │ └── pentaho-solutions/drivers/ # Drivers de big data (.kar files) ├── 2_repository/ # Configuración del repositorio de base de datos │ ├── pentaho-solutions/system/ │ │ ├── hibernate/hibernate-settings.xml │ │ ├── jackrabbit/repository.xml │ │ └── scheduler-plugin/quartz/quartz.properties │ └── tomcat/webapps/pentaho/META-INF/context.xml ├── 3_security/ # Autenticación y autorización │ └── pentaho-solutions/system/ │ ├── applicationContext-spring-security-hibernate.properties │ └── applicationContext-spring-security-memory.xml ├── 4_others/ # Tomcat, valores por defecto y varios │ ├── pentaho-solutions/system/ │ │ ├── defaultUser.spring.properties │ │ ├── pentaho.xml │ │ └── security.properties │ └── tomcat/ │ ├── bin/startup.sh │ └── webapps/pentaho/WEB-INF/web.xml └── 99_exchange/ # Intercambio de datos de usuario (no procesado automáticamente) ``` ```` El driver JDBC de PostgreSQL está incluido en la distribución de Pentaho. Si necesita actualizarlo: 1. Descargar desde [Maven Central](https://repo1.maven.org/maven2/org/postgresql/postgresql/) 2. Colocar en `softwareOverride/1_drivers/tomcat/lib/` O Copiar desde Workshop--Installation/'Database Drivers'/ ```bash cd cd ~/Workshop--Installation/'Database Drivers' cp postgresql-42.7.8.jar ~/Pentaho-Server-PostgreSQL/softwareOverride/1_drivers/tomcat/lib ``` {% endtab %} {% tab title="3. Construir y enviar la imagen" %} {% hint style="info" %} #### Construir y enviar la imagen de Pentaho El script build.sh es un envoltorio de build automatizado que: * Valida prerrequisitos - Verifica que Docker esté instalado * Verifica archivos requeridos - Comprueba que el ZIP de Pentaho exista en stagedArtifacts/ * Detecta plugins automáticamente - Encuentra plugins PAZ, PIR, PDD * Confirma el build - Muestra lo que se va a construir y solicita confirmación * Ejecuta docker build - Ejecuta la build con los argumentos apropiados * Muestra información de la imagen - Muestra tamaño y detalles de la imagen después del build * Opcional: Prueba la imagen - Ejecuta una prueba básica del contenedor (puede omitirse) * Opcional: Envía al registro - Envía al registro Docker (solo con la bandera -p) Este es el **enfoque recomendado** para construir imágenes Docker de Pentaho. Usa un único `.env` archivo para configurar todo - similar al despliegue con Docker Compose. {% endhint %} Puede modificar el build con las siguientes opciones:
Opción (corta)Opción (larga)Descripción
-v--version VERSIONVersión de Pentaho (por defecto: 11.0.0.0-237)
-t--tag TAGEtiqueta de la imagen Docker (por defecto: pentaho/pentaho-server:VERSION)
-e--edition EDITIONee o ce (por defecto: ee)
-d--demoIncluir contenido de demostración (por defecto: no)
-p--pushEnviar al registro después del build
-h--helpEnviar al registro después del build
1. Construir y enviar la imagen del Pentaho Server directamente al registro de K3s. ```bash # Construir con valores predeterminados basados en .env cd cd ~/Pentaho-K3s-PostgreSQL/docker-build ./build.sh ```

Construir y enviar la imagen del Pentaho Server

{% hint style="info" %} **1. Construcción de la imagen Docker:** El despliegue usa una imagen de contenedor de Pentaho Server construida a medida: ``` docker-build/ ├── Dockerfile (build multinivel) ├── build.sh (script de build automatizado) ├── stagedArtifacts/ (ZIP de Pentaho Server) └── softwareOverride/ (sobrescrituras de configuración) ├── 1_drivers/ (driver JDBC de PostgreSQL) ├── 2_repository/ (configs de base de datos) ├── 3_security/ (autenticación) └── 4_others/ (personalizaciones de Tomcat) ``` El `build.sh` script: * Valida prerrequisitos y archivos requeridos * Detecta plugins automáticamente (PAZ, PIR, PDD) * Ejecuta build Docker multinivel * Opcionalmente envía al almacén de imágenes de K3s **2. Gestión de configuración:** * `.env` El archivo contiene ajustes específicos del despliegue (versiones, credenciales, memoria JVM) * `softwareOverride/` El directorio proporciona sobrescrituras de configuración procesadas en orden numerado * Driver JDBC de PostgreSQL incluido por defecto, con opción de actualizar * Scripts Tomcat personalizados para optimización del arranque del contenedor {% endhint %} {% endtab %} {% tab title="4. Charts de Helm" %} {% hint style="info" %} #### Charts de Helm Helm es el gestor de paquetes para Kubernetes, a menudo referido como "apt/yum para Kubernetes." Simplifica el despliegue y la gestión de aplicaciones Kubernetes al: **Empaquetar**: Agrupar recursos relacionados de Kubernetes **Templar**: Parametrizar manifiestos para reutilización entre entornos **Versionar**: Gestionar versiones de aplicaciones y actualizaciones **Gestión de releases**: Rastrear despliegues y permitir retrocesos {% endhint %}

Charts de Helm

{% tabs %} {% tab title="1. Directorios" %} {% hint style="info" %} #### Estructura de directorios A continuación se explica el directorio pentaho responsable de un despliegue con Helm. {% endhint %} ``` pentaho/ # Directorio raíz del chart ├── Chart.yaml # Metadatos del chart (nombre, versión, descripción) ├── values.yaml # Valores de configuración por defecto ├── templates/ # Plantillas de manifiestos de Kubernetes │ ├── _helpers.tpl # Funciones helper de plantillas (no renderizado) │ ├── NOTES.txt # Instrucciones post-instalación │ ├── namespace.yaml # Creación del namespace │ ├── secret.yaml # Datos sensibles (contraseñas, claves) │ ├── configmap-*.yaml # Datos de configuración │ ├── pvc.yaml # Persistent volume claims │ ├── *-deployment.yaml # Deployments de pods │ ├── *-service.yaml # Definiciones de servicios │ └── ingress.yaml # Reglas de enrutamiento de Ingress └── files/ # Archivos no plantillados (scripts SQL, configuraciones) └── db_init/ # Scripts de inicialización de PostgreSQL ``` **Chart.yaml** {% hint style="info" %} Este archivo define la identidad del chart, la versión y los metadatos usados por Helm. Sirve como la "definición de paquete" para el chart de Helm, similar a package.json (npm) o Chart.lock (dependencias de Helm). Rol: Chart.yaml le dice a Helm qué es este chart, qué versión tiene, qué aplicación despliega y proporciona metadatos buscables para repositorios de charts. Helm usa este archivo para rastrear versiones del chart, gestionar dependencias y mostrar información cuando los usuarios buscan o instalan charts. {% endhint %} **values.yaml** {% hint style="info" %} En un despliegue K3s (Kubernetes ligero), el `values.yaml` archivo sirve como el archivo central de configuración para los charts de Helm. Define parámetros y ajustes por defecto que personalizan cómo se despliega una aplicación o servicio en el clúster: cosas como conteo de réplicas, versiones de imágenes, límites de recursos, tipos de servicio, reglas de ingress, variables de entorno y configuraciones de almacenamiento persistente. Cuando ejecuta `helm install` o `helm upgrade`, Helm combina los valores de este archivo con las plantillas del chart para generar los manifiestos finales de Kubernetes. Puedes sobrescribir valores específicos en tiempo de despliegue usando `--set` flags o suministrando un archivo de valores personalizado con `-f`, convirtiéndolo en un mecanismo flexible para gestionar configuraciones específicas del entorno (p. ej., desarrollo vs. producción) sin modificar las plantillas subyacentes del chart. {% endhint %} *** **templates**
YAMLDescripción
namespace.yamlCrea un namespace de Kubernetes aislado para contener todos los recursos de Pentaho
secret.yamlAlmacena credenciales sensibles de la base de datos (contraseñas) cifradas en Kubernetes
config-*.yamlConfigura variables de entorno de Pentaho (memoria JVM, ajustes de base de datos, rutas, zona horaria) Contiene scripts SQL para inicializar las bases de datos PostgreSQL (jackrabbit, quartz, hibernate) en el primer arranque
pvc.yamlSolicita volúmenes de almacenamiento persistente para los datos de PostgreSQL y, opcionalmente, datos/soluciones de Pentaho
*-deployment.yamlDespliega el Pentaho Business Analytics Server con contenedor init, sondas de salud y límites de recursos. Despliega el servidor de base de datos PostgreSQL 15 con inicialización automática y almacenamiento persistente
*-service.yamlEncamina el tráfico HTTP/HTTPS externo al Pentaho Server a través del controlador de ingreso Traefik. Expone el puerto 5432 de PostgreSQL como un endpoint DNS estable para que Pentaho se conecte.
ingress.yamlEncamina el tráfico HTTP/HTTPS externo al Pentaho Server a través del controlador de ingreso Traefik
{% endtab %} {% tab title="2. Desplegar" %} {% hint style="info" %} #### Desplegar La arquitectura consta de dos pods principales que se ejecutan dentro de un namespace dedicado a Pentaho: un pod de Pentaho Server (Tomcat sobre Debian con OpenJDK 21) y un pod de PostgreSQL que aloja tres bases de datos esenciales: Jackrabbit para el almacenamiento de contenido, Quartz para la programación de trabajos y Hibernate para seguridad y registro de auditoría. {% endhint %} {% hint style="danger" %} Antes de continuar, asegúrate de haber completado los pasos 1 - 3. Debes tener una imagen de Pentaho Server + imágenes del repositorio PostgreSQL 15 subidas al repositorio de K3s. {% endhint %} 1. Chequeo rápido. ```bash # Comprobar la versión de Helm (requiere 3.0+) helm version # Comprobar el clúster de Kubernetes kubectl cluster-info kubectl get nodes # Comprobar las clases de almacenamiento disponibles kubectl get storageclass ``` 2. Comprobar que la imagen de Pentaho está disponible. ```bash # Verificar sudo k3s ctr images ls | grep pentaho ```

Imagen de Pentaho Server en el repositorio K3s

*** {% hint style="info" %} #### Despliegue por defecto El flujo de trabajo de despliegue progresa a través de cuatro etapas: * preparar el entorno colocando el paquete de Pentaho Enterprise Edition y verificando K3s. * configurar variables de entorno y sobreescrituras de software durante las tareas previas al vuelo. * construir y empujar una imagen Docker personalizada en el runtime de contenedores de K3s. * finalmente desplegar la pila completa usando ya sea charts de Helm o un `deploy.sh` script que orquesta la creación del namespace, secretos, ConfigMaps, almacenamiento persistente y el enrutamiento de ingreso de Traefik. También cubre la estructura del chart de Helm, una suite de scripts auxiliares para respaldo, comprobaciones de salud, monitorización de recursos y validación del despliegue, junto con múltiples métodos de acceso incluyendo port-forwarding, ingreso basado en hostname y IP directa del nodo. {% endhint %} 1. Instalar usando charts de Helm. ```bash cd cd ~/Pentaho-K3s-PostgreSQL/helm-chart helm install pentaho ./pentaho ```

Desplegar Pentaho Server - Helm Chart

{% endtab %} {% endtabs %} {% endtab %} {% tab title="Scripts auxiliares" %} {% hint style="info" %} #### Scripts auxiliares El despliegue K3s de Pentaho incluye una colección de scripts auxiliares en el `scripts/` directorio para operaciones y mantenimiento del día a día: * **backup-postgres.sh:** Crea volcados comprimidos con marca de tiempo de todas las bases de datos de Pentaho (Jackrabbit, Quartz, Hibernate) usando `pg_dump` ejecutado dentro del pod de PostgreSQL. * **restore-postgres.sh:** Restaura las bases de datos de Pentaho desde archivos de respaldo, útil para recuperación ante desastres, clonación de entornos o migración de datos entre clústeres. * **health-check.sh:** Realiza una comprobación rápida de salud en tiempo de ejecución que cubre la disponibilidad de pods, disponibilidad de servicios, conectividad a la base de datos y una prueba HTTP en vivo contra la página de inicio de sesión de Pentaho. * **validate-deployment.sh:** Ejecuta una auditoría completa en seis categorías: namespace, pods, servicios, PersistentVolumeClaims, ConfigMaps y configuración de ingreso. * **monitor-resources.sh:** Rastrea el uso de CPU y memoria en todos los pods de Pentaho usando `kubectl top` para ayudar a identificar restricciones de recursos u oportunidades de optimización. * **monitor-postgres.sh:** Monitorea métricas específicas de PostgreSQL incluyendo conteos de conexiones, consultas activas, tamaños de tablas y salud general de la base de datos. * **verify-k3s.sh:** Valida la infraestructura subyacente de K3s (estado de nodos, clases de almacenamiento, ingreso Traefik y componentes centrales) antes de intentar un despliegue de Pentaho. * **Makefile:** Proporciona comandos de conveniencia como `make health`, `make status`, `make logs`, `make port-forward`, y `make destroy` para una gestión simplificada del clúster. {% endhint %} {% tabs %} {% tab title="1. Directorios" %} {% hint style="info" %} #### Estructura de directorios Esta configuración de despliegue en K3s ofrece varias capacidades importantes: * Despliegue de Kubernetes completamente autocontenido en K3s ligero * Inicialización automática de la base de datos con scripts SQL de PostgreSQL * Comprobaciones de salud y orden de inicio nativas de Kubernetes * PersistentVolumeClaims para la base de datos y el contenido de Pentaho * Proceso de construcción de imagen Docker con optimización en múltiples etapas * Límites de recursos (CPU/memoria) para estabilidad * Plantillas de manifiestos de Kubernetes listas para producción * Controlador JDBC de PostgreSQL incluido * Procedimientos fáciles de respaldo y restauración mediante scripts utilitarios * Configuración de ingreso para enrutamiento con Traefik {% endhint %} *** **Archivos del directorio raíz** ``` Pentaho-K3s-PostgreSQL/ ├── deploy.sh # Script principal de despliegue ├── destroy.sh # Script de limpieza ├── Makefile # Comandos rápidos (make help) ├── README.md # Este archivo ├── DEPLOYMENT.md # Guía detallada de despliegue ├── K3s-INSTALLATION.md # Instrucciones de instalación de K3s ``` {% hint style="info" %} **Archivos de documentación:** **README.md** - El punto de entrada principal de la documentación que proporciona una visión general del proyecto, instrucciones de inicio rápido, prerequisitos e información general de uso para el taller de despliegue en K3s. **DEPLOYMENT.md** - Guía de despliegue detallada que cubre el flujo completo de despliegue en K3s, incluyendo prerequisitos, instrucciones paso a paso y procedimientos de verificación posteriores al despliegue. **K3s-INSTALLATION.md** - Instrucciones de configuración e instalación de K3s que abarcan la preparación del sistema, la instalación de K3s, la configuración de red y el ajuste de clases de almacenamiento requeridos antes de desplegar Pentaho. **Orquestación y despliegue:** **deploy.sh** - Script de despliegue automatizado que orquesta el flujo completo de despliegue en K3s incluyendo creación de namespace, generación de secretos, aplicación de manifiestos y comprobaciones de disponibilidad de servicios. **destroy.sh** - Script de limpieza que elimina de forma segura todos los recursos de K3s incluyendo despliegues, servicios, persistent volume claims y namespaces, útil para escenarios de redeploy o desmontaje. **Makefile** - Contiene objetivos de comandos de conveniencia para operaciones comunes de K3s como desplegar, destruir, comprobar estado y ver logs. Los usuarios pueden ejecutar `make help` para ver todos los comandos disponibles. {% endhint %} *** **docker-build** ``` ├── docker-build/ # Construcción de imagen Docker │ ├── build.sh # Script de construcción │ ├── Dockerfile # Definición de la imagen │ ├── README.md # Documentación completa de la construcción │ ├── QUICK-START.md # Guía rápida de construcción │ ├── ENV-CONFIGURATION.md # Guía de configuración .env │ ├── .env.example # Plantilla de configuración │ ├── test-compose.yml # Pruebas locales con Docker │ ├── entrypoint/ # Scripts de arranque del contenedor │ │ ├── docker-entrypoint.sh │ │ └── start-pentaho-docker.sh │ ├── softwareOverride/ # Superposiciones de configuración (incluidas en la imagen) │ │ ├── 1_drivers/ # Controlador JDBC de PostgreSQL │ │ ├── 2_repository/ # Configs de base de datos │ │ │ └── README.md │ │ ├── 3_security/ # (vacío - sin Vault) │ │ └── 4_others/ # Scripts de Tomcat modificados │ │ └── README.md │ └── stagedArtifacts/ # Colocar el ZIP de Pentaho aquí │ └── README.md ``` {% hint style="info" %} El **docker-build/** el directorio contiene todos los componentes necesarios para construir la imagen del contenedor de Pentaho Server que se desplegará en K3s: **Archivos de documentación:** **README.md** - Documentación completa de la construcción que cubre el proceso de construcción de la imagen Docker, la arquitectura de construcción en múltiples etapas, opciones de configuración, solución de problemas y buenas prácticas para construir imágenes de Pentaho Server para despliegue en K3s. **QUICK-START.md** - Guía rápida de construcción que proporciona instrucciones paso a paso para usuarios que desean construir y probar rápidamente la imagen de Pentaho sin leer la documentación completa. Incluye comandos comunes de construcción y flujos de trabajo típicos. **ENV-CONFIGURATION.md** - Guía de referencia de configuración exhaustiva para el `.env.example` archivo, detallando todas las variables de entorno disponibles, sus propósitos, valores por defecto y cómo afectan el proceso de construcción Docker y la imagen resultante. **Archivos de construcción y configuración:** **build.sh** - Script envoltorio de construcción automatizada que valida prerrequisitos, comprueba la existencia de archivos requeridos (ZIP de Pentaho en `stagedArtifacts/`), detecta plugins automáticamente (PAZ, PIR, PDD), confirma la construcción con el usuario, ejecuta `docker build`, muestra información de la imagen tras la construcción y opcionalmente empuja a un registro con la `-p` flag. **.env.example** - Plantilla de archivo de configuración que contiene todas las variables de entorno disponibles para el proceso de construcción Docker. Los usuarios copian esto a `.env` y personalizan valores para sus necesidades específicas de despliegue incluyendo versión de Pentaho, etiquetas de imagen y opciones de construcción. **Dockerfile** - Definición de construcción multi-etapa usando `debian:trixie-slim` como imagen base con OpenJDK 21 JRE. Crea imágenes optimizadas separando el entorno de construcción del entorno de ejecución, reduciendo el tamaño final de la imagen mientras mantiene todos los componentes necesarios de Pentaho. El enfoque multi-etapa minimiza vulnerabilidades de seguridad y mejora la eficiencia de la construcción. **test-compose.yml** - Entorno de pruebas local con Docker Compose que permite probar la imagen Docker construida localmente antes de desplegar en K3s. Esto es útil para validar cambios de configuración, probar plugins personalizados o depurar problemas de arranque sin la sobrecarga de un despliegue completo en K3s. **Scripts de inicio del contenedor:** **entrypoint/** - Directorio que contiene scripts de inicialización y arranque del contenedor: * **docker-entrypoint.sh** - Script principal de arranque del contenedor que se ejecuta cuando el contenedor inicia. Maneja el procesamiento de variables de entorno, personalización de archivos de configuración desde `softwareOverride/`, validación de la conexión a la base de datos, comprobaciones de salud y orquesta la secuencia de arranque del Pentaho Server. * **start-pentaho-docker.sh** - Script de arranque específico de Pentaho que gestiona la inicialización de Tomcat, configuración de la JVM, ajustes de memoria y arranca los servicios del Pentaho Server. Este script es llamado por `docker-entrypoint.sh` tras completarse la preparación del entorno. **Superposiciones de configuración:** **softwareOverride/** - Directorio de superposiciones de configuración que se incorpora en la imagen Docker durante el proceso de construcción. Los archivos están organizados en directorios numerados y se procesan en orden alfabético para asegurar la secuencia correcta de aplicación: * **1\_drivers/** - Controlador JDBC de PostgreSQL (incluido por defecto) para la conectividad a la base de datos. Controladores JDBC adicionales o conectores de datos pueden colocarse aquí. * **2\_repository/** - Configuraciones de conexión a la base de datos para todos los repositorios de Pentaho incluyendo Jackrabbit (JCR), Quartz (scheduler) y Hibernate (seguridad/auditoría). Contiene un **README.md** explicando los archivos de configuración del repositorio y sus propósitos. * **3\_security/** - Vacío en este despliegue K3s ya que la integración con HashiCorp Vault no se utiliza. En entornos de producción, esto contendría archivos de configuración de autenticación, autorización y seguridad. * **4\_others/** - Scripts de Tomcat modificados (startup.sh, setenv.sh), server.xml, web.xml y otras configuraciones a nivel de aplicación. Contiene un **README.md** documentando las modificaciones personalizadas de Tomcat y sus propósitos. **Artefactos en staging:** **stagedArtifacts/** - Directorio de staging donde los usuarios colocan el paquete de instalación de Pentaho Server (`pentaho-server-ee-11.0.0.0-237.zip`) antes de construir la imagen Docker. Contiene un **README.md** con instrucciones sobre dónde obtener el paquete de Pentaho y cómo colocarlo correctamente. {% endhint %} *** **db\_init\_postgres** ``` ├── db_init_postgres/ # Scripts SQL de inicialización de PostgreSQL │ ├── 1_create_jcr_postgresql.sql │ ├── 2_create_quartz_postgresql.sql │ ├── 3_create_repository_postgresql.sql │ ├── 4_pentaho_logging_postgresql.sql │ └── 5_pentaho_mart_postgresql.sql ``` {% hint style="info" %} El **db\_init\_postgres/** el directorio contiene scripts de inicialización de PostgreSQL que crean todas las bases de datos de repositorio requeridas por Pentaho. Estos scripts se montan en el contenedor de PostgreSQL y se ejecutan automáticamente en el primer arranque: **1\_create\_jcr\_postgresql.sql** - Crea la **base de datos del Repositorio de Contenido Jackrabbit (JCR)** . El JCR almacena todo el contenido de Pentaho incluyendo informes, cuadros de mando, fuentes de datos, esquemas de análisis, transformaciones, trabajos y archivos de usuario. Este es el sistema principal de gestión de contenido para el repositorio de Pentaho. **2\_create\_quartz\_postgresql.sql** - Prepara la **base de datos del Scheduler Quartz** . Quartz gestiona todos los trabajos programados, triggers y calendarios dentro de Pentaho Server, incluyendo horarios de generación de informes, ejecuciones de trabajos ETL y otros procesos automatizados. Contiene tablas críticas como `QRTZ6_JOB_DETAILS`, `QRTZ6_TRIGGERS`, y el historial de ejecuciones. **3\_create\_repository\_postgresql.sql** - Crea la **Base de datos del Repositorio Hibernate** . Esta almacena datos de autenticación de usuarios, información de autorización, roles, permisos y otra información relacionada con la seguridad gestionada por el subsistema de seguridad de Pentaho. **4\_pentaho\_logging\_postgresql.sql** - Establece el **pentaho\_dilogs** esquema dentro de la base de datos Hibernate para auditoría y registro de Data Integration (DI). Captura información detallada de ejecución ETL incluyendo logs de trabajos, logs de transformaciones, métricas de rendimiento de pasos y registros de errores. Esencial para depurar flujos de integración de datos y monitorizar la salud de las canalizaciones. **5\_pentaho\_mart\_postgresql.sql** - Crea la **pentaho\_operations\_mart** esquema dentro de la base de datos Hibernate. Este data mart dimensional almacena análisis operacionales sobre el uso de Pentaho Server, incluyendo tablas de dimensiones (`DIM_DATE`, `DIM_TIME`, `DIM_EXECUTOR`) y tablas de hechos (`FACT_EXECUTION`, `FACT_STEP_EXECUTION`) para analizar la utilización de la plataforma, tendencias de rendimiento y patrones de actividad de usuarios. {% endhint %} *** **manifests** ``` ├── manifests/ # Manifiestos de Kubernetes │ ├── namespace.yaml # Namespace de Pentaho │ ├── configmaps/ │ │ ├── pentaho-config.yaml │ │ └── postgres-init-scripts.yaml │ ├── pentaho/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── postgres/ │ │ ├── deployment.yaml │ │ └── service.yaml │ ├── secrets/ │ │ └── secrets.yaml # (ignorados por git) │ ├── storage/ │ │ └── pvc.yaml │ └── ingress/ │ └── ingress.yaml ``` {% hint style="info" %} El **manifests/** el directorio contiene todas las definiciones de recursos de Kubernetes organizadas por área funcional. Estos archivos YAML definen el estado declarativo de tu despliegue en K3s: **namespace.yaml** - Crea el `pentaho` namespace dedicado para aislar todos los recursos relacionados con Pentaho de otras cargas de trabajo de K3s, proporcionando separación lógica y organización de recursos. **configmaps/** - Recursos ConfigMap para datos de configuración no sensibles: * **pentaho-config.yaml** - Ajustes de configuración del Pentaho Server como parámetros JVM, ajustes de Tomcat y propiedades de la aplicación * **postgres-init-scripts.yaml** - ConfigMap que contiene los cinco scripts de inicialización de PostgreSQL desde el directorio `db_init_postgres/` , montado en el pod de PostgreSQL **pentaho/** - Recursos de Kubernetes para Pentaho Server: * **deployment.yaml** - Define el despliegue de Pentaho Server incluyendo especificaciones del contenedor, requests/limits de recursos, variables de entorno, montajes de volúmenes, probes de readiness/liveness y el conteo de réplicas * **service.yaml** - Servicio ClusterIP que expone Pentaho Server en el puerto 8080 dentro del clúster, proporcionando DNS interno estable y balanceo de carga **postgres/** - Recursos de Kubernetes para la base de datos PostgreSQL: * **deployment.yaml** - Define el despliegue de PostgreSQL 15 con especificaciones del contenedor, PersistentVolumeClaims para almacenamiento de datos, montaje de scripts de inicialización y configuración de la base de datos * **service.yaml** - Servicio ClusterIP que expone PostgreSQL en el puerto 5432 dentro del clúster para conexiones de la base de datos de Pentaho Server **secrets/** - Almacenamiento de credenciales sensibles: * **secrets.yaml** - Recurso Secret de Kubernetes que contiene credenciales codificadas en base64 para PostgreSQL (`postgres_password`, `pentaho_user`, `pentaho_password`) y cadenas de conexión JDBC. **Este archivo está ignorado por git por seguridad.** **storage/** - Definiciones de almacenamiento persistente: * **pvc.yaml** - Definiciones de PersistentVolumeClaim tanto para los datos de PostgreSQL (`postgres-pvc`) como para soluciones/datos de Pentaho (`pentaho-pvc`), usando la clase de almacenamiento local-path de K3s para datos persistentes a través de reinicios de pods **ingress/** - Configuración de acceso externo: * **ingress.yaml** - Recurso Ingress de Traefik que define reglas de enrutamiento HTTP/HTTPS externas para exponer Pentaho Server fuera del clúster K3s, incluyendo hostname, enrutamiento por ruta y configuración TLS si aplica {% endhint %} *** **scripts** ``` └── scripts/ # Scripts utilitarios ├── backup-postgres.sh # Respaldo de base de datos ├── restore-postgres.sh # Restauración de base de datos ├── health-check.sh # Comprobación de salud ├── monitor-resources.sh # Monitorización de recursos ├── monitor-postgres.sh # Monitorización de PostgreSQL ├── validate-deployment.sh # Validación del despliegue └── verify-k3s.sh # Verificación de K3s ``` {% hint style="info" %} El **scripts/** el directorio contiene utilidades operativas y de mantenimiento para gestionar el despliegue K3s de Pentaho: **Gestión de bases de datos:** **backup-postgres.sh** - Utilidad automatizada de respaldo de PostgreSQL que crea volcados comprimidos de todas las bases de datos de Pentaho (jackrabbit, quartz, hibernate) usando `kubectl exec` para ejecutar `pg_dump` dentro del pod de PostgreSQL. Los respaldos tienen marca de tiempo y se comprimen con gzip para almacenamiento eficiente. **restore-postgres.sh** - Utilidad de restauración de bases de datos para recuperar las bases de datos de Pentaho desde archivos de respaldo. Útil para recuperación ante desastres, clonación de entornos o migración de datos entre clústeres K3s. Maneja la descompresión y restauración vía `kubectl exec` y `psql`. **Monitorización y validación:** **health-check.sh** - Script de comprobación de salud que verifica que tanto PostgreSQL como Pentaho Server estén funcionando y respondiendo correctamente. Comprueba el estado de los pods, las probes de readiness y realiza pruebas básicas de conectividad. **monitor-resources.sh** - Utilidad de monitorización de recursos que rastrea CPU, memoria y uso de almacenamiento en todos los pods de Pentaho usando `kubectl top` y métricas de recursos, ayudando a identificar limitaciones de recursos u oportunidades de optimización. **monitor-postgres.sh** - Script de monitorización específico de PostgreSQL que comprueba conteos de conexiones a la base de datos, consultas activas, tamaños de tablas y métricas de salud de la base de datos mediante consultas SQL ejecutadas en el pod de PostgreSQL. **validate-deployment.sh** - Script integral de validación del despliegue que confirma que todos los recursos de K3s se han creado correctamente, los pods están en ejecución, los servicios son accesibles, los volúmenes persistentes están enlazados y todo el despliegue está operativo. **verify-k3s.sh** - Script de verificación de la infraestructura K3s que comprueba la instalación de K3s, el estado de los nodos, las clases de almacenamiento, el controlador de ingreso Traefik y los componentes centrales de K3s antes de intentar el despliegue de Pentaho. {% endhint %} *** **Diferencias clave: K3s vs Docker**
AspectoDespliegue DockerDespliegue K3s
OrquestaciónDocker ComposeKubernetes (K3s)
Configuración.env archivo + docker-compose.ymlManifiestos de Kubernetes (YAML)
SecretsSecrets de Docker o VaultSecrets de Kubernetes
RedesRed puente de DockerRed del clúster K3s + Ingress Traefik
AlmacenamientoVolúmenes de DockerPersistentVolumeClaims (PVCs)
EscaladoManual (docker compose up --scale)Declarativo (réplicas en deployment)
Checks de saludDocker HEALTHCHECKProbes de readiness/liveness de Kubernetes
Scripts de inicializaciónMontaje de volumen en /docker-entrypoint-initdb.dConfigMap montado en el pod de PostgreSQL
{% endtab %} {% tab title="2. Desplegar" %} {% hint style="info" %} #### Ejecución del despliegue El `deploy.sh` el script automatiza todo el flujo de trabajo: * Verifica que K3s esté en ejecución * Crea el namespace * Aplica todos los manifiestos en el orden correcto * Monitorea el arranque de los pods * Valida la disponibilidad de los servicios * Proporciona un resumen del despliegue con URLs de acceso **1. Creación del Namespace:** ```bash kubectl create namespace pentaho ``` Crea un entorno lógico aislado para todos los recursos de Pentaho. **2. Generación de secretos:** ```bash kubectl apply -f manifests/secrets/secrets.yaml ``` Almacena credenciales de PostgreSQL y cadenas de conexión JDBC como Secrets de Kubernetes. **3. Provisionamiento de almacenamiento:** ```bash kubectl apply -f manifests/storage/pvc.yaml ``` Crea PersistentVolumeClaims para los datos de PostgreSQL y el contenido de Pentaho. **4. Creación de ConfigMap:** ```bash kubectl apply -f manifests/configmaps/ ``` Monta los scripts de inicialización de PostgreSQL y la configuración de Pentaho. **5. Despliegue de PostgreSQL:** ```bash kubectl apply -f manifests/postgres/ ``` Despliega el pod de PostgreSQL con: * Scripts init montados (creación automática de la base de datos en el primer arranque) * Volumen persistente para datos * Comprobaciones de salud y límites de recursos * Servicio ClusterIP para conectividad interna **6. Despliegue de Pentaho Server:** ```bash kubectl apply -f manifests/pentaho/ ``` Despliega el pod de Pentaho con: * Imagen Docker personalizada * Variables de entorno desde ConfigMap y Secrets * Montajes de volúmenes para soluciones/datos * Probes de readiness/liveness * Servicio ClusterIP **7. Configuración de Ingress:** ```bash kubectl apply -f manifests/ingress/ingress.yaml ``` Configura el enrutamiento de Traefik para el acceso externo. {% endhint %} 1. Ejecuta el deploy.sh ```sh cd cd ~/Pentaho-K3s-PostgreSQL ./deploy.sh ```

Desplegar Pentaho Server

{% hint style="info" %} Este script unificado gestiona el proceso completo de despliegue de Pentaho Server en K3s, incluyendo: * Importación de la imagen Docker en el runtime de contenedores de K3s * Creación de recursos de Kubernetes (namespace, secrets, configmaps, storage) * Despliegue de la base de datos PostgreSQL * Despliegue de Pentaho Server * Configuración de Ingress * Comprobaciones de salud e informes de estado ``` Uso: ./deploy.sh # Despliegue nuevo con importación de imagen ./deploy.sh --skip-import # Desplegar sin importar la imagen ./deploy.sh --update-only # Solo actualizar el despliegue existente ./deploy.sh --clean # Eliminar imágenes antiguas antes de desplegar ``` Prerequisitos: * K3s instalado y en ejecución * Imagen Docker construida: pentaho/pentaho-server:11.0.0.0-237 * kubectl configurado para acceder al clúster K3s * Acceso sudo para operaciones de containerd de K3s {% endhint %} *** **Comandos rápidos con Makefile** ```bash make help # Mostrar todos los comandos disponibles make full-deploy # Construir, importar y desplegar (flujo completo) make health # Ejecutar comprobación de salud make status # Mostrar estado del despliegue make logs # Ver logs de Pentaho make port-forward # Acceder a Pentaho en localhost:8080 make destroy # Eliminar despliegue ``` *** También hay un conjunto de scripts que ayudarán a validar el despliegue: {% tabs %} {% tab title="Validar despliegue" %} {% hint style="info" %} Script integral de validación posterior al despliegue que verifica que todos los componentes del despliegue Pentaho en K3s estén correctamente configurados y funcionando. Qué comprueba (6 categorías) **Namespace** * Verifica que exista el namespace pentaho **Pods** * El pod de PostgreSQL está en Running * El pod de Pentaho Server está en Running * Muestra el estado actual si no está en ejecución **Servicios** * El servicio de PostgreSQL existe * El servicio de Pentaho Server existe **PersistentVolumeClaims (3 PVCs)** * postgres-data-pvc (10Gi) - Archivos de la base de datos * pentaho-data-pvc (10Gi) - Pentaho * data pentaho-solutions-pvc (5Gi) - Repositorio de soluciones * Todos deben estar en estado "Bound" **ConfigMaps** * pentaho-config - Variables de entorno * postgres-init - Scripts de inicialización de la base de datos **Ingress** * pentaho-ingress - Configuración de enrutamiento de Traefik **Pruebas de conectividad de base de datos** * Se conecta al pod de PostgreSQL * Prueba las 3 bases de datos de Pentaho: \* jackrabbit - Repositorio de contenido JCR \* quartz - Scheduler de trabajos \* hibernate - Repositorio de configuración * Ejecuta la consulta SELECT 1 en cada una {% endhint %} 1. Ejecuta el siguiente `validate-deployment.sh` script. ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```

Validar implementación

{% endtab %} {% tab title="Comprobación de salud" %} {% hint style="info" %} #### Comprobación de salud Script de comprobación rápida de salud para ejecutar la implementación de Pentaho: más rápido y ligero que la validación completa, enfocado en el estado de salud en tiempo de ejecución. Namespace * Verifica que exista el namespace pentaho * Sale inmediatamente si falta el namespace (crítico) Disponibilidad del Pod * El pod de PostgreSQL está listo (no solo en ejecución) * El pod del servidor Pentaho está listo * Comprobaciones `estado containerStatuses[0].ready` Servicios * El servicio de PostgreSQL existe * El servicio de Pentaho Server existe Conectividad de la base de datos * PostgreSQL responde a consultas Las 3 bases de datos existen: \* jackrabbit \* quartz \* hibernate * Usa `psql -lqt` para listar bases de datos Salud de la aplicación web * Prueba HTTP en vivo a la página de inicio de sesión de Pentaho * Usa port-forward para acceder al servicio * Espera una respuesta HTTP 200 * Prueba: ; Uso de recursos * Muestra uso de CPU/memoria mediante `kubectl top pods` * Maneja de forma elegante la ausencia de metrics-server {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./health-check.sh ```

Comprobación de salud

{% endtab %} {% tab title="Monitorear recursos" %} {% hint style="info" %} #### Monitorear recursos x {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```
{% endtab %} {% tab title="Servidor Pentaho" %} {% hint style="info" %} #### Accediendo al servidor Pentaho {% endhint %} **Reenvío de puertos (recomendado para pruebas/desarrollo)** El método más sencillo usando kubectl para reenviar un puerto local al servicio Pentaho: ```bash kubectl port-forward -n pentaho svc/pentaho-server 8080:8080 ``` **URL de acceso:** `http://localhost:8080/pentaho` También puedes usar un puerto alternativo si 8080 está ocupado: ```bash kubectl port-forward -n pentaho svc/pentaho-server 9080:8080 # Luego accede: http://localhost:9080/pentaho ``` *** **Ingress con nombre de host (pentaho.local)** Usa el controlador ingress Traefik incorporado de K3s con acceso estilo DNS: **Configuración:** ```bash echo "10.0.0.1 pentaho.local" | sudo tee -a /etc/hosts ``` *(Reemplaza 10.0.0.1 con la IP real de tu nodo)* **URL de acceso:** `http://pentaho.local/pentaho` *** **Ingress vía IP directa del nodo (no se requiere DNS)** Accede directamente a través de la IP de cualquier nodo del clúster sin configurar /etc/hosts: **URL de acceso:** `http:///pentaho` Esto funciona porque el ingress incluye una regla basada en ruta que no requiere un nombre de host. *** **Comando de conveniencia en Makefile** El proyecto incluye un atajo en el Makefile: ```bash make port-forward ``` Esto configura automáticamente el reenvío de puertos a localhost:8080. *** **Credenciales predeterminadas** | Nombre de usuario | Contraseña | | ----------------- | ---------- | | admin | password | ⚠️ ¡Cambia estos para implementaciones en producción! *** **Referencia rápida** | Método | Mejor para | URL | | ------------------------ | ------------------ | ------------------------------- | | Reenvío de puertos | Desarrollo/Pruebas | `http://localhost:8080/pentaho` | | Ingress (nombre de host) | Producción con DNS | `http://pentaho.local/pentaho` | | Ingress (IP directa) | Pruebas sin DNS | `http:///pentaho` | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | | {% endtab %} | | | | {% endtabs %} | | | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-es/instalacion/contenedores/k3s.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.