> For the complete documentation index, see [llms.txt](https://academy.pentaho.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-es/instalacion/containers/k3s.md). # K3s {% hint style="info" %} #### K3s K3s es una distribución de Kubernetes ligera y certificada, diseñada para entornos con recursos محدودados, computación en el borde, dispositivos IoT y escenarios de desarrollo. Creado 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, al tiempo que mantiene compatibilidad total con las API y funciones de Kubernetes. Requiere muy poca memoria (512 MB mínimo) y ofrece operaciones simplificadas con menos dependencias. K3s incluye componentes integrados como el controlador de ingreso Traefik, el aprovisionador de almacenamiento local y el equilibrador de carga de servicios. Es perfecto para desarrollo, CI/CD, implementaciones en el borde y dispositivos ARM, y aun así está listo para producción con capacidades de alta disponibilidad. {% endhint %}

Arquitectura del servidor K3s y Pentaho

{% tabs %} {% tab title="Componentes principales de K3s" %} {% hint style="info" %} #### Componentes principales de K3s **Componentes del plano de control** El plano de control incluye el Servidor API (punto final de la API de Kubernetes para la administración del clúster), el Gestor de Controladores (administra los bucles de control principales para replicación, puntos finales y espacios de nombres) y el Programador (asigna pods a nodos según la disponibilidad de recursos). K3s puede usar etcd o SQLite ligero como almacén de datos para el estado del clúster, lo que lo hace más flexible que Kubernetes estándar. **Componentes del nodo** Cada nodo ejecuta el agente Kubelet, que gestiona el ciclo de vida de los pods. Containerd está integrado como runtime de contenedores para ejecutar contenedores. Kube-proxy gestiona el proxy de red y la red de servicios en todo el clúster. **Complementos integrados** K3s incluye el controlador de ingreso Traefik para enrutar el tráfico HTTP/HTTPS externo a los servicios. El aprovisionador Local Path permite el aprovisionamiento dinámico de volúmenes persistentes usando almacenamiento local. CoreDNS proporciona DNS del clúster para el descubrimiento de servicios. El equilibrador de carga de servicios gestiona servicios de tipo LoadBalancer sin requerir integraciones externas con proveedores de nube. **Redes** Flannel sirve como complemento CNI (Interfaz de Red de Contenedores) predeterminado para la red de pods. Las políticas de red controlan el flujo de tráfico entre pods y servicios para mejorar la 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 * Construcción Docker multietapa para optimizar el tamaño de la imagen * Expuesto internamente en el puerto 8080 * Incluye sondas de readiness y liveness para monitorización del estado * 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 un 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, paneles, fuentes de datos, transformaciones, trabajos) * **Quartz** (pentaho\_user): Programador que gestiona trabajos, disparadores, 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 ETL con registros de trabajos, métricas de transformaciones y datos de rendimiento de pasos * **pentaho\_operations\_mart**: Almacén de datos dimensional para analíticas de la plataforma con tablas de dimensión y hechos * Datos persistidos mediante PersistentVolumeClaim para sobrevivir a los 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_userJava Content Repository (JCR) - Almacena todo el contenido de Pentaho, incluidos informes, paneles, fuentes de datos, esquemas de análisis y archivos de usuario. Este es el almacenamiento principal de contenido para el repositorio de Pentaho.
quartzpentaho_userQuartz Scheduler - Gestiona todos los trabajos programados, desencadenadores y calendarios. Contiene tablas para definiciones de trabajos (QRTZ6_JOB_DETAILS), desencadenadores (QRTZ6_TRIGGERS), historial de ejecución y bloqueos de coordinación de clúster.
hibernatehibuserHibernate Repository - Aloja la configuración de seguridad, el registro de auditoría, los datos de sesión de usuario y contiene dos esquemas adicionales: pentaho_dilogs (registro de ejecución ETL) y pentaho_operations_mart (marter de datos analíticos).
{% hint style="info" %} La base de datos hibernate contiene esquemas especializados para el monitoreo operativo: **pentaho\_dilogs**: Captura información detallada de ejecución ETL, incluidos registros de trabajos, registros de transformaciones, métricas de rendimiento de pasos y registros de errores. Esencial para depurar flujos de trabajo de integración de datos y supervisar el estado de la canalización. **pentaho\_operations\_mart**: Un mart de datos dimensional para analítica sobre el uso de Pentaho. Contiene 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, las tendencias de rendimiento y la actividad de los usuarios. Para los despliegues en producción, implementa copias de seguridad periódicas del volumen Docker repository-data. La base de datos jackrabbit es la más crítica, ya que contiene todo el contenido del usuario. Considera usar pg\_dump para copias de seguridad lógicas o instantáneas del 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` espacio de nombres * 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 al Pentaho Server * Nombre de host configurable y enrutamiento basado en rutas * Soporte opcional para terminación TLS/SSL {% endhint %} Tomcat gestiona grupos de conexiones definidos en context.xml. Cada grupo cumple un propósito específico:
Nombre del grupoDestino de la conexiónUsado para
jdbc/Hibernaterepository:5432/hibernateSeguridad, usuarios, roles
jdbc/Quartzrepository:5432/quartzProgramación de trabajos
jdbc/jackrabbitrepository:5432/jackrabbitRepositorio de contenido
jdbc/Auditrepository:5432/hibernateRegistro de auditoría
jdbc/live_logging_inforepository:5432/hibernateRegistros 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:** * Utiliza el `local-path` aprovisionador de almacenamiento * Aprovisiona volúmenes en el sistema de archivos local del nodo * Creación y vinculación automáticas de volúmenes **ConfigMaps:** * Scripts de inicialización de bases de datos (5 archivos SQL) * Ajustes de configuración de Pentaho (parámetros JVM, configuración de Tomcat) **Secrets:** * Credenciales de PostgreSQL (postgres\_password, pentaho\_user, pentaho\_password) * Cadenas de conexión JDBC * Codificado en Base64 por seguridad {% endhint %} {% endtab %} {% endtabs %} {% hint style="danger" %} Antes de comenzar el despliegue de K3s, asegúrese de haber completado la configuración: [Contenedores Pentaho](/pentaho-11-installation-en/pentaho-11-installation-es/configuracion/pentaho-containers.md) {% endhint %} Siga los pasos siguientes para desplegar Pentaho Server en un K3s de un solo nodo con el repositorio PostgreSQL 15. {% tabs %} {% tab title="1. Preparar el entorno " %} {% hint style="info" %} #### Preparar el entorno La sección "Preparar entorno" describe los pasos iniciales de configuración requeridos antes de desplegar Pentaho Server 11 en K3s: * copiar los recursos de despliegue a su directorio de inicio, * preparar el archivo ZIP de Pentaho Server Enterprise Edition, verificar que el archivo esté en su lugar, * confirmar que K3s está correctamente instalado y en ejecución {% endhint %} {% hint style="danger" %} Asegúrate de haber descargado: `pentaho-server-ee-11.0.0.0-237.zip` {% endhint %} 1. Crear el directorio y copiar los recursos. ```bash cd cd ~/Workshop--Installation/Pentaho-Containers/K3s/Pentaho-K3s-PostgreSQL/scripts chmod +x ./install-to-home.sh ``` 2. Copia el directorio /docker/stagedArtefacts con pentaho-server-ee-11.0.0.0-237.zip. {% hint style="info" %} Si has desplegado un Pentaho Server archivado, entonces copia desde: `/opt/pentaho/software/pentaho-server-ee-version` De lo contrario, descarga el paquete desde el [Portal del cliente 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. Verifica que el archivo. ```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ías 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 una LICENSE\_URL que apunta al servidor de licencias de Flexera. Asegúrate de que tus 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. Verifica el estado de tu licencia antes de continuar con los despliegues de producción. {% endhint %} **Diferencias clave**
AspectoDespliegue con DockerDespliegue con K3s
OrquestaciónDocker ComposeKubernetes (K3s)
Configuración.env archivo + docker-compose.ymlmanifiestos de Kubernetes (YAML)
SecretsSecrets de Docker o VaultSecrets de Kubernetes
Redesred de puente Dockerred del clúster K3s + Traefik Ingress
Almacenamientovolúmenes DockerPersistentVolumeClaims (PVCs)
EscaladoManual (docker compose up --scale)Declarativo (réplicas en el despliegue)
Comprobaciones de estadoDocker HEALTHCHECKsondas 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 al despliegue 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** Editar el `.env.example` archivo dentro del `docker-build/` directorio con la configuración específica de su 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 (4 GB por defecto) y heap máximo (8 GB por defecto). Añada la URL de su servidor de licencia de Enterprise Edition si corresponde. Configure las opciones de compilación, incluyendo la edición de la imagen (EE/CE), la detección de complementos y los ajustes de envío al registro. Una vez configurado, copie esta plantilla a `.env` para que la utilice el proceso de compilación. **directorio softwareOverride** La `softwareOverride/` directorio dentro de `docker-build/` proporciona un mecanismo para personalizar las configuraciones de Pentaho. Estas personalizaciones se incorporan en la imagen Docker durante el proceso de compilación. Los archivos se organizan en directorios numerados y se procesan en orden alfabético. La **1\_drivers/** El directorio contiene el controlador JDBC de PostgreSQL (incluido por defecto), y puede colocar aquí controladores JDBC adicionales. La **2\_repository/** El directorio contiene configuraciones de conexión a bases de datos para Jackrabbit (JCR), Quartz (programador) y repositorios Hibernate. El **3\_security/** directorio está vacío en este despliegue de K3s, ya que no hay integración con Vault. La **4\_others/** El directorio contiene scripts de Tomcat modificados (startup.sh, setenv.sh), server.xml y otras configuraciones a nivel de aplicación. Opcionalmente, puede actualizar el controlador JDBC de PostgreSQL descargándolo desde Maven Central o copiándolo de la colección de controladores de base de datos del taller. Coloque el controlador actualizado en `softwareOverride/1_drivers/tomcat/lib/`. {% endhint %} *** **Configurar .env** 1. Editar el archivo .env.template ```bash cd cd ~/Pentaho-Server-PostgreSQL nano .env.template ``` 2. Introduce los siguientes detalles:
VariablePredeterminadoDescripció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 de la JVM
PENTAHO_MAX_MEMORY8192mTamaño máximo del heap de la 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 REGISTRYfalseEnvía directamente al registro de K3s
LOAD_INTO_K3StrueCarga directamente en K3s
EJECUTAR PRUEBAStrue
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" %} La `softwareOverride/` directorio proporciona un poderoso mecanismo para personalizar Pentaho Server sin modificar la instalación principal. Los archivos se copian en la instalación de Pentaho durante el inicio del contenedor y se procesan en orden alfabético por nombre de directorio. {% endhint %} ```` ``` softwareOverride/ ├── 1_drivers/ # Controladores JDBC y conectores de datos │ ├── tomcat/lib/ │ │ └── postgresql-42.x.x.jar # Controlador JDBC de PostgreSQL (incluido) │ └── pentaho-solutions/drivers/ # Controladores de big data (archivos .kar) ├── 2_repository/ # Configuración del repositorio de la 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 predeterminados 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 se procesa automáticamente) ``` ```` El controlador JDBC de PostgreSQL está incluido en la distribución de Pentaho. Si necesitas actualizarlo: 1. Descárgalo desde [Maven Central](https://repo1.maven.org/maven2/org/postgresql/postgresql/) 2. Colócalo en `softwareOverride/1_drivers/tomcat/lib/` O Copia 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. Compilar y enviar la imagen" %} {% hint style="info" %} #### Compilar y enviar la imagen de Pentaho El script build.sh es un envoltorio de compilación automatizado que: * Valida los requisitos previos - Comprueba que Docker esté instalado * Comprueba los archivos requeridos - Verifica que el ZIP de Pentaho exista en stagedArtifacts/ * Detecta complementos automáticamente - Encuentra los complementos PAZ, PIR y PDD * Confirma la compilación - Muestra qué se compilará y pide confirmación * Ejecuta docker build - Realiza la compilación con los argumentos adecuados * Muestra información de la imagen - Presenta el tamaño y los detalles de la imagen después de la compilación * Opcional: prueba la imagen - Ejecuta una prueba básica del contenedor (puede omitirla) * Opcional: envía al registro - Sube al registro de Docker (solo con la bandera -p) Este es el **enfoque recomendado** para compilar imágenes Docker de Pentaho. Utiliza un solo `.env` archivo para configurar todo, similar al despliegue con Docker Compose. {% endhint %} Puede modificar la compilación con las siguientes opciones:
Opción (corta)Opción (larga)Descripción
-v--version VERSIONVersión de Pentaho (predeterminado: 11.0.0.0-237)
-t--tag TAGEtiqueta de la imagen Docker (predeterminado: pentaho/pentaho-server:VERSION)
-e--edition EDITIONee o ce (predeterminado: ee)
-d--demoIncluir contenido de demostración (predeterminado: no)
-p--pushEnviar al registro después de la compilación
-h--helpEnviar al registro después de la compilación
1. Compile y envíe la imagen del Pentaho Server directamente al registro de K3s. ```bash # Compilar con los valores predeterminados basados en .env cd cd ~/Pentaho-K3s-PostgreSQL/docker-build ./build.sh ```

Compilar y enviar la imagen de Pentaho Server

{% hint style="info" %} **1. Compilación de la imagen Docker:** El despliegue utiliza una imagen de contenedor Pentaho Server compilada a medida: ``` docker-build/ ├── Dockerfile (compilación multietapa) ├── build.sh (script de compilación automatizado) ├── stagedArtifacts/ (ZIP de Pentaho Server) └── softwareOverride/ (sobres de configuración) ├── 1_drivers/ (controlador JDBC de PostgreSQL) ├── 2_repository/ (configuraciones de base de datos) ├── 3_security/ (autenticación) └── 4_others/ (personalizaciones de Tomcat) ``` La `build.sh` script: * Valida los requisitos previos y los archivos necesarios * Detecta complementos automáticamente (PAZ, PIR, PDD) * Ejecuta una compilación Docker multietapa * Opcionalmente envía al almacén de imágenes de K3s **2. Gestión de la configuración:** * `.env` el archivo contiene ajustes específicos del despliegue (versiones, credenciales, memoria JVM) * `softwareOverride/` el directorio proporciona superposiciones de configuración procesadas en orden numerado * Controlador JDBC de PostgreSQL incluido por defecto, con opción de actualizarlo * Scripts personalizados de Tomcat para optimizar el 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 denominado "apt/yum para Kubernetes". Simplifica el despliegue y la gestión de aplicaciones de Kubernetes mediante: **Empaquetado**: Agrupar recursos relacionados de Kubernetes **Plantillas**: Parametrizar manifiestos para su reutilización entre entornos **Versionado**: Gestionar versiones y actualizaciones de aplicaciones **Gestión de lanzamientos**: Seguir despliegues y permitir reversiones {% endhint %}

Charts de Helm

{% tabs %} {% tab title="1. Directorios" %} {% hint style="info" %} #### Estructura del directorio A continuación se muestra una explicación del directorio pentaho responsable de un despliegue de Helm. {% endhint %} ``` pentaho/ # Directorio raíz del chart ├── Chart.yaml # Metadatos del chart (nombre, versión, descripción) ├── values.yaml # Valores de configuración predeterminados ├── templates/ # Plantillas de manifiestos de Kubernetes │ ├── _helpers.tpl # Funciones auxiliares de plantilla (no se renderizan) │ ├── NOTES.txt # Instrucciones posteriores a la instalación │ ├── namespace.yaml # Creación del espacio de nombres │ ├── secret.yaml # Datos sensibles (contraseñas, claves) │ ├── configmap-*.yaml # Datos de configuración │ ├── pvc.yaml # Reclamaciones de volúmenes persistentes │ ├── *-deployment.yaml # Despliegues de pods │ ├── *-service.yaml # Definiciones de servicios │ └── ingress.yaml # Reglas de enrutamiento Ingress └── files/ # Archivos sin plantilla (scripts SQL, configuraciones) └── db_init/ # Scripts de inicialización de PostgreSQL ``` **Chart.yaml** {% hint style="info" %} Este archivo define la identidad, versión y metadatos del chart utilizados por Helm. Sirve como la "definición del paquete" del chart de Helm, similar a package.json (npm) o Chart.lock (dependencias de Helm). Función: Chart.yaml le dice a Helm qué es este chart, qué versión tiene, qué aplicación despliega y proporciona metadatos buscables para los repositorios de charts. Helm utiliza este archivo para seguir las 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 de K3s (Kubernetes ligero), el `values.yaml` archivo sirve como archivo central de configuración para charts de Helm. Define parámetros y ajustes predeterminados que personalizan cómo se despliega una aplicación o servicio en el clúster: cosas como recuentos de réplicas, versiones de imagen, límites de recursos, tipos de servicio, reglas de ingreso, 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. Puede sobrescribir valores específicos en el momento del despliegue usando `--set` banderas o proporcionando un archivo de valores personalizado con `-f`, lo que lo convierte en un mecanismo flexible para gestionar configuraciones específicas del entorno (por ejemplo, desarrollo frente a producción) sin modificar las plantillas subyacentes del chart. {% endhint %} *** **templates**
YAMLDescripción
namespace.yamlCrea un espacio de nombres aislado de Kubernetes para contener todos los recursos de Pentaho
secret.yamlAlmacena de forma cifrada en Kubernetes las credenciales sensibles de la base de datos (contraseñas)
config-*.yamlConfigura las variables de entorno de Pentaho (memoria JVM, ajustes de base de datos, rutas, zona horaria) Contiene scripts SQL para inicializar las bases de datos de PostgreSQL (jackrabbit, quartz, hibernate) en el primer arranque
pvc.yamlSolicita volúmenes de almacenamiento persistente para los datos de PostgreSQL y, opcionalmente, para los datos/soluciones de Pentaho
*-deployment.yamlDespliega Pentaho Business Analytics Server con contenedor de inicialización, 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.yamlEnruta el tráfico HTTP/HTTPS externo al Pentaho Server mediante el controlador de ingreso Traefik. Expone el puerto 5432 de PostgreSQL como un punto final DNS estable para que Pentaho se conecte.
ingress.yamlEnruta el tráfico HTTP/HTTPS externo al Pentaho Server mediante el 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 espacio de nombres Pentaho dedicado: un pod de Pentaho Server (Tomcat en Debian con OpenJDK 21) y un pod de PostgreSQL que aloja tres bases de datos esenciales: Jackrabbit para 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úrese de haber completado los pasos 1 - 3. Debe tener una imagen de Pentaho Server + imágenes del repositorio PostgreSQL 15 enviadas al repositorio de K3s. {% endhint %} 1. Comprobación rápida. ```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. Compruebe que la imagen de Pentaho está disponible. ```bash # Verificar sudo k3s ctr images ls | grep pentaho ```

Imagen de Pentaho Server en el repositorio de K3s

*** {% hint style="info" %} #### Despliegue predeterminado El flujo de despliegue avanza a través de cuatro etapas: * preparar el entorno preparando el paquete de Pentaho Enterprise Edition y verificando K3s. * configurar variables de entorno y sobres de software durante las tareas previas. * compilar y enviar una imagen Docker personalizada al runtime de contenedores de K3s. * finalmente desplegar toda la pila usando charts de Helm o un `deploy.sh` script automatizado que orquesta la creación de namespaces, secrets, ConfigMaps, almacenamiento persistente y enrutamiento Ingress de Traefik. También cubre la estructura del chart de Helm, un conjunto de scripts auxiliares para copias de seguridad, 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 nombre de host e 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 - Chart de Helm

{% endtab %} {% endtabs %} {% endtab %} {% tab title="Scripts auxiliares" %} {% hint style="info" %} #### Scripts auxiliares El despliegue de Pentaho en K3s incluye una colección de scripts auxiliares en el `scripts/` directorio para operaciones y mantenimiento diarios: * **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 a partir de archivos de copia de seguridad, ú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 del estado en tiempo de ejecución que cubre la preparación del pod, la disponibilidad del servicio, la conectividad con 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: espacio de nombres, pods, servicios, PersistentVolumeClaims, ConfigMaps y configuración de ingress. * **monitor-resources.sh:** Realiza un seguimiento del 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:** Supervisa métricas específicas de PostgreSQL, incluidos los recuentos de conexiones, las consultas activas, los tamaños de las tablas y el estado general de la base de datos. * **verify-k3s.sh:** Valida la infraestructura subyacente de K3s (estado de los nodos, clases de almacenamiento, Traefik ingress y componentes principales) 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 del directorio Esta configuración de despliegue en K3s proporciona varias capacidades importantes: * Despliegue de Kubernetes completamente autónomo sobre el ligero K3s * Inicialización automatizada de la base de datos con scripts SQL de PostgreSQL * Comprobaciones de estado y orden de arranque nativos de Kubernetes * Persistent volume claims para la base de datos y el contenido de Pentaho * Proceso de construcción de imágenes Docker con optimización multietapa * Límites de recursos (CPU/memoria) para la estabilidad * Plantillas de manifiestos de Kubernetes listas para producción * Controlador JDBC de PostgreSQL incluido * Procedimientos fáciles de copia de seguridad y restauración mediante scripts de utilidad * Configuración de ingress para el enrutamiento de 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** - La documentación principal de entrada que proporciona una visión general del proyecto, instrucciones de inicio rápido, requisitos previos e información general de uso para el taller de despliegue de K3s. **DEPLOYMENT.md** - Guía detallada de despliegue que cubre el flujo de trabajo completo de despliegue en K3s, incluidos los requisitos previos, 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 cubren la preparación del sistema, la instalación de K3s, la configuración de red y la configuración de la clase de almacenamiento necesaria antes de desplegar Pentaho. **Orquestación y despliegue:** **deploy.sh** - Script de despliegue automatizado que orquesta el flujo de trabajo completo de despliegue en K3s, incluida la creación del namespace, la generación de secretos, la aplicación de manifiestos y las comprobaciones de disponibilidad del servicio. **destroy.sh** - Script de limpieza que elimina de forma segura todos los recursos de K3s, incluidos despliegues, servicios, persistent volume claims y namespaces, útil para escenarios de redepliegue o desmantelamiento. **Makefile** - Contiene objetivos de comandos de conveniencia para operaciones comunes de K3s como desplegar, destruir, comprobar el estado y ver logs. Los usuarios pueden ejecutar `make help` para ver todos los comandos disponibles. {% endhint %} *** **docker-build** ``` ├── docker-build/ # Construcción de imágenes Docker │ ├── build.sh # Script de construcción │ ├── Dockerfile # Definición de la imagen │ ├── README.md # Documentación completa de construcción │ ├── QUICK-START.md # Guía rápida de construcción │ ├── ENV-CONFIGURATION.md # Guía de configuración de .env │ ├── .env.example # Plantilla de configuración │ ├── test-compose.yml # Pruebas locales de Docker │ ├── entrypoint/ # Scripts de inicio 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/ # Configuraciones de base de datos │ │ │ └── README.md │ │ ├── 3_security/ # (vacío - sin Vault) │ │ └── 4_others/ # Scripts de Tomcat modificados │ │ └── README.md │ └── stagedArtifacts/ # Coloca aquí el ZIP de Pentaho │ └── README.md ``` {% hint style="info" %} La **docker-build/** directorio contiene todos los componentes necesarios para construir la imagen del contenedor Pentaho Server que se desplegará en K3s: **Archivos de documentación:** **README.md** - Documentación completa de construcción que cubre el proceso de construcción de imágenes Docker, la arquitectura de construcción multietapa, las opciones de configuración, la resolución de problemas y las mejores 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 los usuarios que quieren construir y probar rápidamente la imagen de Pentaho sin leer la documentación completa. Incluye comandos de construcción comunes y flujos de trabajo típicos. **ENV-CONFIGURATION.md** - Guía de referencia de configuración completa para el `.env.example` archivo, que detalla todas las variables de entorno disponibles, sus propósitos, valores predeterminados y cómo afectan al proceso de construcción de Docker y a la imagen resultante. **Archivos de construcción y configuración:** **build.sh** - Script envoltorio de construcción automatizada que valida los requisitos previos, verifica los archivos necesarios (ZIP de Pentaho en `stagedArtifacts/`), detecta complementos automáticamente (PAZ, PIR, PDD), confirma la construcción con el usuario, ejecuta `docker build`, muestra la información de la imagen después de la construcción y opcionalmente la envía a un registro con la bandera `-p` . **.env.example** - Archivo plantilla de configuración que contiene todas las variables de entorno disponibles para el proceso de construcción de Docker. Los usuarios lo copian a `.env` y personalizan los valores según sus necesidades específicas de despliegue, incluidas la versión de Pentaho, las etiquetas de imagen y las opciones de construcción. **Dockerfile** - Definición de construcción multietapa que usa `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 multietapa minimiza las vulnerabilidades de seguridad y mejora la eficiencia de la construcción. **test-compose.yml** - Entorno local de pruebas con Docker Compose que te permite probar localmente la imagen Docker construida antes de desplegarla en K3s. Esto es útil para validar cambios de configuración, probar complementos personalizados o depurar problemas de inicio sin la sobrecarga de un despliegue completo de K3s. **Scripts de inicio del contenedor:** **entrypoint/** - Directorio que contiene scripts de inicialización e inicio del contenedor: * **docker-entrypoint.sh** - Script principal de inicio del contenedor que se ejecuta cuando el contenedor arranca. Gestiona el procesamiento de variables de entorno, la personalización de archivos de configuración desde `softwareOverride/`, la validación de la conexión a la base de datos, las comprobaciones de estado y orquesta la secuencia de inicio de Pentaho Server. * **start-pentaho-docker.sh** - Script de inicio específico de Pentaho que gestiona la inicialización de Tomcat, la configuración de JVM, los ajustes de memoria e inicia los servicios de Pentaho Server. Este script es llamado por `docker-entrypoint.sh` después de completar 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 se organizan en directorios numerados y se procesan en orden alfabético para garantizar una secuencia de aplicación adecuada: * **1\_drivers/** - Controlador JDBC de PostgreSQL (incluido por defecto) para la conectividad con la base de datos. Aquí se pueden colocar controladores JDBC adicionales o conectores de datos. * **2\_repository/** - Configuraciones de conexión a la base de datos para todos los repositorios de Pentaho, incluidos Jackrabbit (JCR), Quartz (programador) y Hibernate (seguridad/auditoría). Contiene un **README.md** que explica los archivos de configuración del repositorio y sus propósitos. * **3\_security/** - Vacío en este despliegue en K3s ya que no se utiliza la integración con HashiCorp Vault. 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** que documenta las modificaciones personalizadas de Tomcat y sus propósitos. **Artefactos preparados:** **stagedArtifacts/** - Directorio de preparación 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 prepararlo 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" %} La **db\_init\_postgres/** directorio contiene scripts de inicialización de PostgreSQL que crean todas las bases de datos de repositorio de Pentaho necesarias. Estos scripts se montan en el contenedor de PostgreSQL y se ejecutan automáticamente en el primer inicio: **1\_create\_jcr\_postgresql.sql** - Crea el **Repositorio de contenido Jackrabbit (JCR)** base de datos. El JCR almacena todo el contenido de Pentaho, incluidos informes, paneles, 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** - Configura el **Programador Quartz** base de datos. Quartz gestiona todos los trabajos programados, desencadenadores y calendarios dentro de Pentaho Server, incluidas las programaciones de generación de informes, las ejecuciones de trabajos ETL y otros procesos automatizados. Contiene tablas críticas como `QRTZ6_JOB_DETAILS`, `QRTZ6_TRIGGERS`y el historial de ejecución. **3\_create\_repository\_postgresql.sql** - Crea el **Repositorio Hibernate** base de datos. Esto almacena los datos de autenticación de usuarios, la información de autorización, los roles, los 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, incluidos registros de trabajos, registros de transformaciones, métricas de rendimiento de pasos y registros de errores. Es esencial para depurar flujos de trabajo de integración de datos y supervisar el estado de los pipelines. **5\_pentaho\_mart\_postgresql.sql** - Crea el **pentaho\_operations\_mart** esquema dentro de la base de datos Hibernate. Este data mart dimensional almacena análisis operativos sobre el uso de Pentaho Server, incluidas 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, las tendencias de rendimiento y los patrones de actividad de los usuarios. {% endhint %} *** **manifiestos** ``` ├── 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 # (ignorado por git) │ ├── storage/ │ │ └── pvc.yaml │ └── ingress/ │ └── ingress.yaml ``` {% hint style="info" %} La **manifiestos/** 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 de 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 `db_init_postgres/` directorio, montado en el pod de PostgreSQL **pentaho/** - Recursos de Kubernetes del Pentaho Server: * **deployment.yaml** - Define el despliegue de Pentaho Server, incluidas las especificaciones del contenedor, las solicitudes/límites de recursos, las variables de entorno, los montajes de volúmenes, las sondas de readiness/liveness y el recuento 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 de la base de datos PostgreSQL: * **deployment.yaml** - Define el despliegue de PostgreSQL 15 con especificaciones del contenedor, persistent volume claims para el 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 las conexiones a la base de datos del Pentaho Server **secrets/** - Almacenamiento de credenciales sensibles: * **secrets.yaml** - Recurso Kubernetes Secret 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 para los datos de PostgreSQL (`postgres-pvc`) y las soluciones/datos de Pentaho (`pentaho-pvc`), usando la clase de almacenamiento local-path de K3s para datos persistentes entre reinicios de pods **ingress/** - Configuración de acceso externo: * **ingress.yaml** - Recurso Ingress de Traefik que define reglas externas de enrutamiento HTTP/HTTPS para exponer Pentaho Server fuera del clúster K3s, incluyendo nombre de host, enrutamiento por ruta y configuración TLS si aplica {% endhint %} *** **scripts** ``` └── scripts/ # Scripts de utilidad ├── backup-postgres.sh # Copia de seguridad de la base de datos ├── restore-postgres.sh # Restauración de la base de datos ├── health-check.sh # Comprobación de estado ├── monitor-resources.sh # Supervisión de recursos ├── monitor-postgres.sh # Supervisión de PostgreSQL ├── validate-deployment.sh # Validación del despliegue └── verify-k3s.sh # Verificación de K3s ``` {% hint style="info" %} La **scripts/** directorio contiene utilidades operativas y de mantenimiento para gestionar el despliegue de Pentaho en K3s: **Gestión de bases de datos:** **backup-postgres.sh** - Utilidad automatizada de copia de seguridad 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. Las copias de seguridad se sellan con marca de tiempo y se comprimen con gzip para un almacenamiento eficiente. **restore-postgres.sh** - Utilidad de restauración de base de datos para recuperar las bases de datos de Pentaho desde archivos de copia de seguridad. Útil para recuperación ante desastres, clonación de entornos o migración de datos entre clústeres de K3s. Gestiona la descompresión y la restauración mediante `kubectl exec` y `psql`. **Supervisión y validación:** **health-check.sh** - Script de comprobación de estado que verifica que tanto PostgreSQL como Pentaho Server se estén ejecutando y respondiendo correctamente. Comprueba el estado de los pods, las sondas de readiness y realiza pruebas básicas de conectividad. **monitor-resources.sh** - Utilidad de supervisión de recursos que realiza un seguimiento del uso de CPU, memoria y almacenamiento en todos los pods de Pentaho usando `kubectl top` y métricas de recursos, ayudando a identificar restricciones de recursos u oportunidades de optimización. **monitor-postgres.sh** - Script de supervisión específico de PostgreSQL que comprueba los recuentos de conexiones a la base de datos, las consultas activas, los tamaños de las tablas y las 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, que los pods se están ejecutando, que los servicios son accesibles, que los volúmenes persistentes están vinculados y que todo el despliegue está operativo. **verify-k3s.sh** - Script de verificación de la infraestructura de K3s que comprueba la instalación de K3s, el estado de los nodos, las clases de almacenamiento, el controlador Traefik ingress y los componentes principales de K3s antes de intentar el despliegue de Pentaho. {% endhint %} *** **Diferencias clave: K3s vs Docker**
AspectoDespliegue con DockerDespliegue con K3s
OrquestaciónDocker ComposeKubernetes (K3s)
Configuración.env archivo + docker-compose.ymlmanifiestos de Kubernetes (YAML)
SecretsSecrets de Docker o VaultSecrets de Kubernetes
Redesred de puente Dockerred del clúster K3s + Traefik Ingress
Almacenamientovolúmenes DockerPersistentVolumeClaims (PVCs)
EscaladoManual (docker compose up --scale)Declarativo (réplicas en el despliegue)
Comprobaciones de estadoDocker HEALTHCHECKsondas 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 La `deploy.sh` script automatiza todo el flujo de trabajo: * Verifica que K3s esté en ejecución * Crea namespace * Aplica todos los manifiestos en el orden correcto * Supervisa el inicio de los pods * Valida la disponibilidad del servicio * Proporciona un resumen del despliegue con las URL 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 las credenciales de PostgreSQL y las cadenas de conexión JDBC como Kubernetes Secrets. **3. Aprovisionamiento 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 de inicialización montados (creación automática de la base de datos en el primer inicio) * Volumen persistente para los datos * Comprobaciones de estado 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 volumen para soluciones/datos * Sondas de readiness/liveness * Servicio ClusterIP **7. Configuración de Ingress:** ```bash kubectl apply -f manifests/ingress/ingress.yaml ``` Configura el enrutamiento de Traefik para 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 maneja todo el proceso de despliegue de Pentaho Server en K3s, incluyendo: * Importación de la imagen Docker al runtime de contenedores de K3s * Creación de recursos de Kubernetes (namespace, secretos, configmaps, almacenamiento) * Despliegue de la base de datos PostgreSQL * Despliegue de Pentaho Server * Configuración de ingress * Comprobaciones de estado 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 ``` Requisitos previos: * 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 las 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 de trabajo completo) make health # Ejecutar comprobación de estado make status # Mostrar el estado del despliegue make logs # Ver los logs de Pentaho make port-forward # Acceder a Pentaho en localhost:8080 make destroy # Eliminar el despliegue ``` *** También hay un grupo 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 de 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 ejecución * El pod de Pentaho Server está en ejecución * 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 la base de datos** * Se conecta al pod de PostgreSQL * Prueba las 3 bases de datos de Pentaho: \* jackrabbit - repositorio de contenido JCR \* quartz - programador de tareas \* 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 el despliegue

{% endtab %} {% tab title="Comprobación de salud" %} {% hint style="info" %} #### Comprobación de salud Script rápido de comprobación de salud para una implementación de Pentaho en ejecución: más rápido y ligero que una validación completa, centrado 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 de Pentaho Server está listo * Comprobaciones `estado de containerStatuses[0].ready` Servicios * El servicio de PostgreSQL existe * El servicio de Pentaho Server existe Conectividad con la base de datos * PostgreSQL responde a las consultas Existen las 3 bases de datos: \* jackrabbit \* quartz \* hibernate * Usa `psql -lqt` para listar las bases de datos Estado de la aplicación web * Prueba HTTP en vivo de 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 el uso de CPU/memoria mediante `kubectl top pods` * Gestiona correctamente la ausencia de metrics-server {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./health-check.sh ```

Comprobación de salud

{% endtab %} {% tab title="Monitorizar recursos" %} {% hint style="info" %} #### Monitorizar recursos x {% endhint %} ```sh cd cd ~/Pentaho-K3s-PostgreSQL/scripts ./validate-deployment.sh ```
{% endtab %} {% tab title="Servidor Pentaho" %} {% hint style="info" %} #### Acceso al Pentaho Server {% endhint %} **Reenvío de puertos (recomendado para pruebas/desarrollo)** El método más sencillo usando kubectl para reenviar un puerto local al servicio de 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 a: http://localhost:9080/pentaho ``` *** **Ingress con nombre de host (pentaho.local)** Usa el controlador de ingress Traefik integrado de K3s con acceso estilo DNS: **Configuración:** ```bash echo "10.0.0.1 pentaho.local" | sudo tee -a /etc/hosts ``` *(Sustituye 10.0.0.1 por la IP real de tu nodo)* **URL de acceso:** `http://pentaho.local/pentaho` *** **Ingress mediante IP directa del nodo (no 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 la ruta que no requiere un nombre de host. *** **Comando de conveniencia de Makefile** El proyecto incluye un acceso directo en el Makefile: ```bash make port-forward ``` Esto configura automáticamente el reenvío de puerto a localhost:8080. *** **Credenciales predeterminadas** | Nombre de usuario | Contraseña | | ----------------- | ---------- | | admin | password | ⚠️ ¡Cámbialas para despliegues en producción! *** **Referencia rápida** | Método | Ideal 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 This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://academy.pentaho.com/pentaho-11-installation-en/pentaho-11-installation-es/instalacion/containers/k3s.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.