Despliegue de Oracle Cloud Infrastructure Kubernetes Engine (OKE) mediante módulos avanzados de Terraform

Introducción

Este es el segundo tutorial de nuestra serie de automatización de Oracle Cloud Infrastructure Kubernetes Engine (OKE), que se basa en los conceptos fundamentales de la primera, Crear un cluster de Oracle Cloud Infrastructure Kubernetes Engine mediante Terraform. En este artículo, llevamos los despliegues de OKE al siguiente nivel introduciendo la automatización avanzada y el diseño modular para aprovisionar entornos escalables, resilientes y altamente personalizables en Oracle Cloud Infrastructure (OCI).

Esta guía, diseñada para ingenieros y clientes de Oracle, le permite transformar una configuración básica de Terraform en un módulo estructurado y reutilizable que se puede adaptar a cualquier tamaño de despliegue. Al aprovechar los principios de Infraestructura como código (IaC) con Terraform (versión de la comunidad), junto con Jenkins y la interfaz de línea de comandos (CLI) de Oracle, proporcionamos una solución de aprovisionamiento single-click para clusters de OKE, sus configuraciones y pruebas automatizadas.

Este tutorial se centra en cuatro áreas clave:

  1. Diseño y automatización modulares: cree módulos reutilizables para componentes principales como VCN, clusters de OKE y hosts bastión, con control de versiones para la compatibilidad a fin de simplificar la gestión y promover la reutilización del código.
  2. Configuración dinámica: gestione la configuración específica del entorno (dev, test, prod) desde una única base de código para despliegues consistentes y repetibles.
  3. Pools de nodos avanzados: optimice el uso y los costos de los recursos con unidades especializadas, imágenes de OKE compatibles y etiquetas para una colocación inteligente de las cargas de trabajo.
  4. Integración perfecta de integración y despliegue continuos: automatice el aprovisionamiento y las actualizaciones de OKE mediante pipelines que integren Terraform, Jenkins y la CLI de OCI para despliegues eficientes de one-click.

La arquitectura que se describe en esta guía utiliza una topología de red de niveles para crear una base segura y escalable. Separa el plano de control, los nodos de trabajador y el tráfico del equilibrador de carga, lo que garantiza la flexibilidad para las cargas de trabajo empresariales a cualquier escala. Demostraremos cómo automatizar por completo el aprovisionamiento de dicho entorno, incluidas las redes, los clusters y los pools de nodos, al tiempo que proporcionamos las herramientas para personalizar y ampliar la solución a sus necesidades.

En este tutorial se asume que comprende los principios de Kubernetes, redes y IaC, así como el conocimiento práctico de herramientas como Terraform, OCI CLI y Jenkins. Al final, tendrás las habilidades para desplegar un entorno de OKE resiliente, de alto rendimiento y escalable en OCI, con la flexibilidad de adaptarlo a tus requisitos específicos.

Visión general de Oracle Cloud Infrastructure Kubernetes Engine (OKE)

Aunque Oracle Cloud Infrastructure Kubernetes Engine (OKE) es un servicio gestionado, para ejecutar correctamente cargas de trabajo esenciales se necesita un enfoque arquitectónico deliberado y bien estructurado. La transición de una configuración básica a un entorno empresarial ampliable requiere una planificación cuidadosa y el uso de herramientas de infraestructura como código (IaC), como Terraform.

La modularización y la automatización son fundamentales para que OKE garantice la escalabilidad, la seguridad y la eficiencia operativa. Al aprovechar los módulos estructurados y las herramientas de automatización, las empresas pueden desplegar y gestionar cargas de trabajo esenciales con coherencia, reducir los errores manuales y acelerar el tiempo de comercialización.

El siguiente diagrama ilustra la arquitectura de OKE, destacando su topología de red por niveles, punto final de API privado y controles de acceso seguro:

Arquitectura de OKE

Para obtener un ejemplo detallado de la arquitectura, consulte la documentación de Oracle.

Consideraciones arquitectónicas
La creación de un entorno de OKE escalable implica abordar al menos los siguientes desafíos técnicos clave:

Elementos clave de diseño
Esta solución modular se basa en una arquitectura de red por niveles, que proporciona una base segura y escalable para las cargas de trabajo empresariales en OKE:

Creación de una automatización modular de Terraform para OKE

Al transformar una configuración de Terraform flat en structured, el diseño modular es esencial para crear entornos repetibles y escalables. Este enfoque garantiza una mejor organización, reutilización del código y capacidad de mantenimiento a escala empresarial, con el control de versiones para la compatibilidad y la colaboración entre equipos.

Proceso de transformación: Módulo plano a estructurado

A partir del módulo plano que se describe en el primer tutorial, transformamos el código en un diseño modular mediante:

  1. Reestructuración del Directorio: Creación de módulos secundarios (vcn, oke, bastion) y organización de recursos en sus respectivas carpetas.
  2. Aplicación de principios clave:
    • Estructura y lógica: encapsule los recursos en directorios independientes (por ejemplo, modules/vcn, modules/oke, modules/bastion) y divida el código monolítico en main.tf, variables.tf y outputs.tf para facilitar la lectura y el mantenimiento.
    • Entradas/Salidas y Control de Versiones: defina las entradas en variables.tf, exponga las salidas en outputs.tf y utilice el control de versiones del módulo de Terraform (restricción version en source) para que el flujo de datos y la compatibilidad sean uniformes.
    • Orquestación: maneja la lógica condicional, como count, en el nivel de módulo raíz, manteniendo los módulos secundarios centrados en sus recursos.

Estructura de Directorio: Plano vs. Modular

Módulo plano: un único directorio monolítico con todos los recursos en unos pocos archivos. Simple para las pruebas de concepto, pero se vuelve inmanejable a medida que la complejidad crece.

Estructura de módulo plano

Módulo estructurado: cada grupo de recursos (VCN, OKE, Bastion) está en su propio directorio de módulos. El módulo raíz organiza las dependencias y la configuración de nivel superior.

Estructura avanzada del módulo

Módulos de ejemplo

¿Por qué los módulos?

Orquestación de módulos: root main.tf

La raíz main.tf organiza el despliegue de tres módulos clave (modules/vcn, modules/oke y modules/bastion) de forma secuencial. Cada módulo se llama de forma condicional en función de los indicadores de configuración (is_vcn_created, is_oke_created, is_bastion_created), lo que proporciona flexibilidad en el despliegue. A continuación se muestra una versión simplificada del flujo de orquestación, resaltando la lógica del módulo de claves sin detallar el main.tf completo.

Flujo de orquestación:

  1. Módulo de VCN (modules/vcn):
    • Aprovisiona la red virtual en la nube (VCN) y las subredes relacionadas (por ejemplo, subredes privadas para nodos de trabajador y API de Kubernetes, subredes públicas para equilibradores de carga y bastión).
    • Controlado por is_vcn_created. Si está activada, crea la VCN; de lo contrario, asume una VCN existente (debe proporcionar su OCID de subred utilizado).
    • Ejemplo de fragmento:
         module "vcn" {
             count = var.is_vcn_created ? 1 : 0  
             source = "./modules/vcn?ref=v1.0.0"  # Specify the module version  
             # Key variables: compartment_id, vcn_cidr_block, subnet configs, ...  
         }
      
  2. Módulo OKE (modules/oke):
    • Despliega el cluster de OCI Kubernetes Engine (OKE), incluido el plano de control y los pools de nodos gestionados opcionales.
    • Depende del módulo de VCN para los ID de subred. Solo se llama si is_oke_created y is_vcn_created son verdaderos.
    • Ejemplo de fragmento:
         module "oke" {
             count = var.is_oke_created && var.is_vcn_created ? 1 : 0  
             source = "./modules/oke?ref=v1.0.0"  # Specify the module version   
             # Key variables: vcn_id, subnet IDs, k8 version, node pool config, ...  
         }
      
  3. Módulo de bastión (modules/bastion):
    • Crea un host bastión para un acceso SSH seguro a recursos privados.
    • Depende del módulo de VCN para el ID de subred pública. Solo se llama si is_bastion_created y is_vcn_created son verdaderos.
    • Ejemplo de fragmento:
         module "bastion" {
             count = var.is_bastion_created && var.is_vcn_created ? 1 : 0  
             source = "./modules/bastion?ref=v1.0.0"  # Specify the module version   
             # Key variables: bastion_subnet_id, SSH keys, parameters...  
         }
      

      Notas clave:

    • Dependencias del módulo: las salidas del módulo de VCN, como module.vcn[0].vcn_id, se transfieren como entradas a los módulos de OKE y Bastion, lo que garantiza una cadena de dependencias clara.
    • Lógica de configuración: las asignaciones de parámetros simplificadas (por ejemplo, node_pool_param, bastion_params) optimizan la configuración y la legibilidad.
    • Control de versiones: el uso de restricciones de versión en source garantiza que los módulos se desplieguen con las versiones correctas y probadas, lo que garantiza la compatibilidad

Después de establecer una estructura modular de Terraform para OKE, el siguiente paso es automatizar su despliegue. La automatización garantiza la consistencia, reduce los errores manuales, acelera el proceso de aprovisionamiento y mejora directamente el tiempo de comercialización (TTM) al permitir la entrega rápida de nuevas funciones y servicios.

Opciones de automatización

Varias herramientas pueden automatizar los despliegues de OKE, como la CLI de Terraform, OCI Resource Manager (ORM), la CLI de OCI, los módulos de OCI de Ansible y Helm. Sin embargo, esta guía se centra en los dos enfoques de infraestructura como código (IaC) más destacados de Oracle Cloud Infrastructure (OCI): CLI de Terraform y OCI Resource Manager (ORM).

Ambas herramientas aprovechan el mismo lenguaje de configuración declarativo HashiCorp (HCL), pero difieren en sus modelos operativos:

Vamos a explorar cada opción en detalle.

Opción 1: Despliegue de recursos de OKE con la CLI de Terraform

La CLI de Terraform es ideal cuando necesita un control completo sobre el entorno local. Es más adecuado para desarrolladores individuales o equipos pequeños que pueden gestionar el archivo de estado y colaborar de forma eficaz mediante un backend compartido. Su portabilidad le permite ejecutarlo desde cualquier máquina: local, máquina virtual, contenedor, OCI CloudShell o ejecutores de integración y despliegue continuos, como Jenkins. Sin embargo, esta flexibilidad incluye responsabilidades, como la gestión de archivos de estado y la garantía de configuraciones locales coherentes entre los miembros del equipo.

Para comenzar, descargue y descomprima el paquete de código fuente de la CLI de Terraform en el directorio de trabajo de Terraform. Este paquete incluye main.tf, un ejemplo de terraform.tfvars y configuraciones detalladas del módulo: descargue oke_advanced_module.zip.

El despliegue de OKE con la CLI de Terraform implica siete tareas clave, desde la configuración de variables y redes hasta la configuración del cluster, los pools de nodos y el host bastión de OKE. A continuación, se muestran los pasos detallados para aprovisionar y verificar el entorno de OKE mediante la CLI de Terraform.

Tarea 1.1: Configuración de variables de Terraform

Actualice el archivo terraform.tfvars con detalles específicos del entorno, como tenancy_ocid, región, compartment_ocid y network_compartment_ocid. Active los siguientes indicadores para controlar la creación de recursos:

Tarea 1.2: Configuración de red

Defina bloques CIDR para la VCN y sus subredes:

Tarea 1.3: Configuración del cluster de OKE

Tarea 1.4: Configuración del pool de nodos

Configuración de host de bastión de la tarea 1.5

Tarea 1.6: Ejecución de comandos de Terraform

Ejecute los siguientes comandos para desplegar la infraestructura:

	terraform init
	terraform plan
	terraform apply

Una vez que se complete terraform apply, el cluster de OKE se aprovisionará con:

Tarea 1.7: Verificación

  1. Navegue a la consola de OCI para verificar la configuración del cluster.
  2. Ejecute terraform destroy para limpiar los recursos cuando haya terminado.

Automatización del despliegue de OKE con el pipeline de integración y despliegue continuos de Jenkins
Para integrar el despliegue de OKE en pipelines DevOps, la CLI de Terraform es una excelente opción. Nuestro enfoque, que se detalla en Creación de un cluster de Oracle Cloud Infrastructure Kubernetes Engine mediante Terraform, utiliza scripts de bash para orquestar el proceso. Este flujo de trabajo se puede consolidar en un pipeline de Jenkins para la ejecución automatizada.

Opción 2: automatización de OKE con OCI Resource Manager

OCI Resource Manager (ORM) es la opción ideal cuando necesita una solución gestionada y nativa en la nube para despliegues de infraestructura. Es especialmente adecuado para entornos empresariales colaborativos en los que la seguridad, la gestión centralizada del estado y la gobernanza son fundamentales. La ventaja clave de ORM es que maneja todo el ciclo de vida de despliegue dentro de OCI, almacena de forma segura el archivo de estado y evita conflictos. Esto elimina la necesidad de la configuración local o la gestión de un backend compartido. Además, la profunda integración de ORM con Oracle Cloud le permite aprovechar funciones nativas de OCI como la gestión de identidad y acceso (IAM), mejorando la seguridad y el control.

En este tutorial, combinamos OCI Resource Manager (ORM) con la CLI de OCI, Bash y los integramos en pipelines de integración y despliegue continuos de Jenkins, lo que ofrece un flujo de automatización one-click completo con capacidades adicionales de DevOps, como detección de cambios, gestión de estado segura y colaboración en equipo con el control de versiones para garantizar la compatibilidad.

Flujo de OCI Resource Manager
El siguiente diagrama ilustra el flujo de trabajo de ORM, compuesto por siete pasos:
Flujo de trabajo de ORM

  1. Configuración de origen: define el origen de la configuración IaC (por ejemplo, OCI Object Storage, GitHub, archivo zip).
  2. Plantilla de Terraform: la infraestructura se define mediante Terraform.
  3. OCI Resource Manager: ORM toma la plantilla de Terraform y gestiona el proceso de aprovisionamiento.
  4. Crear una pila: ORM utiliza la plantilla para crear una pila de recursos de OCI.
  5. Plan: genera un plan que describe las acciones que se deben realizar.
  6. Aplicar: aprovisiona los recursos según el plan.
  7. Destruir: deprovisa los recursos cuando ya no son necesarios.

Para desplegar un cluster de OKE mediante el nuevo módulo desde OCI Resource Manager (ORM), comience por descargar el módulo avanzado para ORM: oke_advanced_module_orm.zip. Esta versión está preconfigurada para ORM, con variables definidas en marcadores de posición genéricos como REPLACE_WITH_YOUR_OWN_VARIABLE_VALUE.

Tarea 2.1: Configuración de origen

Actualice variables.tf con los detalles específicos del entorno, como la región, los CIDR de red y los indicadores para controlar la creación de recursos (VCN, cluster de OKE, pool de nodos, host bastión).

La siguiente secuencia de comandos bash crea el archivo zip de orígenes de recursos ORM.

Verifique el directorio de origen (~/oke_advanced_module_orm) para asegurarse de que un archivo denominado stackconfig.zip contiene todas las definiciones de recursos de terraform.

Tarea 2.2: Creación de la pila de OCI Resource Manager

Utilice la CLI de OCI para crear una pila de ORM. El siguiente script simplifica el proceso:

Script de Bash: create_new_oke_stack.sh.

	#!/bin/bash
	
	# Load environment variables (e.g., COMPARTMENT_ID, STACK_NAME, etc.)
	source "./env-vars"

	# Create the Oracle Resource Manager stack and capture the OCID
	stack_output=$(oci resource-manager stack create \
	--compartment-id "$COMPARTMENT_ID" --display-name "$STACK_NAME" \
	--description "$STACK_DESCRIPTION" --config-source "$CONFIG_SOURCE")

	# Extract the OCID of the newly created stack and display it
	STACK_OCID=$(echo "$stack_output" | jq -r '.data.id')

	echo "Stack OCID: $STACK_OCID"

Tarea 2.3: Ejecutar trabajo de plan de pila

Ejecute el trabajo Plan para verificar los cambios antes de aplicarlos. Esta ejecución en seco proporciona transparencia en los cambios de infraestructura.

Script de Bash: create_oke_stack_plan_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID)
	source "./env-vars"

	# Create a plan job for the specified stack
	plan_job_output=$(oci resource-manager job create-plan-job \
		--stack-id "$STACK_OCID")

	# Extract the OCID of the plan job and check for errors
	PLAN_JOB_OCID=$(echo "$plan_job_output" | jq -r '.data.id')
	if [[ -z "$PLAN_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve plan job OCID." >&2
		exit 1
	fi

	echo "Plan job OCID: $PLAN_JOB_OCID"

Tarea 2.4: Crear trabajo de aplicación

Aprovisione el cluster de OKE y los recursos asociados, como el pool de nodos, mediante el trabajo Apply.

Script de Bash: create_oke_stack_apply_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an apply job for the specified stack
	apply_job_output=$(oci resource-manager job create-apply-job \
		--stack-id "$STACK_OCID" \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the apply job and check for errors
	APPLY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$APPLY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve apply job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $APPLY_JOB_OCID"

Tarea 2.5: Ejecutar trabajo de destrucción

Limpie los recursos ejecutando el trabajo Destroy cuando el entorno ya no sea necesario.

Script de Bash: create_oke_stack_destroy_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an  jotroy for the specified stack
	apply_job_output=$(oci resource-manager job create-destroy-job \
		--stack-id "$STACK_OCID"  \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the destroy job and check for errors
	DESTROY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$DESTROY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve destroy job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $DESTROY_JOB_OCID"

Automatización de OKE con Jenkins y OCI Resource Manager

Hemos creado un pipeline de Jenkins para automatizar el proceso de aprovisionamiento integral (tareas 2.1–2.4). El pipeline ejecuta scripts bash mediante la CLI de OCI para interactuar con ORM.

En la siguiente imagen se muestra la automatización de one-click para las cuatro primeras tareas; el paso destroy no se incluye para simplificar.

OKEJenkinsPipeline

El pipeline incluye configuración de origen, creación de pila de ORM, generación de planes, aprovisionamiento de recursos y anulación de aprovisionamiento de recursos opcional.

Pasos Siguientes:

El uso de Terraform para el aprovisionamiento de OKE garantiza la consistencia, la automatización y la escalabilidad. Los diseños modulares, combinados con OCI Resource Manager y los pipelines de integración y despliegue continuos, simplifican y facilitan el mantenimiento de los despliegues. En el siguiente tutorial, trataremos las mejores prácticas para la supervisión, la seguridad y la preparación para la producción. Sobre la base de estos fundamentos, ampliaremos los módulos a Oracle AIOps, crearemos un proyecto integral de OKE para aplicaciones de IA y demostraremos cómo el análisis de registro con observabilidad basada en IA puede detectar anomalías y fortalecer la seguridad de la plataforma de contenedores.

Acuses de recibo

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.