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:
- 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.
- 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.
- 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.
- 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:
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:
- Seguridad: implante una estrategia de seguridad sólida mediante la identidad de la carga de trabajo, los grupos de seguridad de red, los puntos finales de API privados y un firewall de aplicaciones web (WAF) para un aislamiento seguro y un control de tráfico estricto.
- Escalabilidad: optimice la alta disponibilidad mediante la distribución de nodos entre dominios de disponibilidad y, a continuación, entre dominios de errores, y mediante la escala automática del cluster de Kubernetes para la escala dinámica.
- Supervisión y observación: integra OCI Logging y OCI Logging Analytics para una supervisión completa del comportamiento a nivel de cluster y pod.
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:
- Segmentación de red: separe el entorno con subredes públicas y privadas dedicadas para la API de Kubernetes, los nodos de trabajador y los equilibradores de carga.
- Acceso controlado: utilice un punto final de API privado para el acceso seguro al plano de control y los hosts bastión para el acceso SSH gestionado.
- Automatización completa: automatice el aprovisionamiento de todo el entorno, incluidas las redes, los clusters y los pools de nodos, mediante Terraform, la CLI de OCI, Bash y Jenkins para realizar despliegues
single-click
eficientes. - Operaciones avanzadas: implemente volúmenes persistentes y ciclos automatizados de nodos para actualizaciones sin tiempo de inactividad.
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:
- Reestructuración del Directorio: Creación de módulos secundarios (
vcn
,oke
,bastion
) y organización de recursos en sus respectivas carpetas. - 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 enmain.tf
,variables.tf
youtputs.tf
para facilitar la lectura y el mantenimiento. - Entradas/Salidas y Control de Versiones: defina las entradas en
variables.tf
, exponga las salidas enoutputs.tf
y utilice el control de versiones del módulo de Terraform (restricciónversion
ensource
) 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 y lógica: encapsule los recursos en directorios independientes (por ejemplo,
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.
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.
Módulos de ejemplo
- Módulo de VCN (
modules/vcn
):- Propósito: gestiona la red (VCN, subredes, gateways, rutas, listas de seguridad, etc.).
- Archivos de Claves:
variables.tf
: define entradas comovcn_cidr_block
.main.tf
: contiene definiciones de recursos.outputs.tf
: expone los ID de subred y VCN para otros módulos.
- Módulo OKE (
modules/oke
):- Propósito: despliega el cluster y los pools de nodos de OKE.
- Archivos de Claves:
variables.tf
: incluyevcn_id
e ID de subred del módulo de VCN.main.tf
: definiciones de cluster y pool de nodos reflejadas.outputs.tf
: expone los ID de cluster y pool de nodos de OKE.
- Módulo de bastión (
modules/bastion
):- Propósito: crea un host bastión para un acceso seguro.
- Archivos de Claves:
variables.tf
: define entradas comobastion_subnet_id
.main.tf
: recursos de host bastión reflejados.outputs.tf
: expone el ID de host bastión y la IP pública.
¿Por qué los módulos?
- Reusabilidad y colaboración: los módulos se pueden compartir entre proyectos, lo que facilita el trabajo en equipo.
- Mantenimiento y control de versiones: las actualizaciones se aplican de forma coherente, lo que reduce la deriva y garantiza la compatibilidad.
- Escalabilidad y consistencia: los diseños modulares manejan la complejidad de manera eficiente, estandarizan los despliegues y eliminan la duplicación.
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:
- 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, ... }
- 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
yis_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, ... }
- 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
yis_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:
- CLI de Terraform: una herramienta de interfaz de línea de comandos que ofrece control directo sobre la infraestructura y los archivos de estado, ideal para desarrolladores individuales o equipos pequeños.
- OCI Resource Manager (ORM): un servicio basado en la consola, totalmente gestionado y nativo de OCI que centraliza la gestión de estados y proporciona un entorno seguro y colaborativo, lo que lo convierte en la opción preferida para despliegues a escala empresarial.
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:
is_vcn_created
: cree una VCN nueva o reutilice una existente.is_okecluster_created
: aprovisione un cluster de OKE.is_nodepool_created
: cree uno o más pools de nodos.is_bastion_created
: despliegue un host bastión.
Tarea 1.2: Configuración de red
Defina bloques CIDR para la VCN y sus subredes:
vcn_cidr_block
: bloque de CIDR de la VCN.k8apiendpoint_private_subnet_cidr_block
: subred de punto final de API de de Kubernetes.workernodes_private_subnet_cidr_block
: subred de nodos de trabajador.serviceloadbalancers_public_subnet_cidr_block
: subred del equilibrador de carga.bastion_public_subnet_cidr_block
: subred de host de bastión.
Tarea 1.3: Configuración del cluster de OKE
- Especifique
control_plane_kubernetes_version
ycluster_type
(BASIC_CLUSTER
oENHANCED_CLUSTER
). - Elija un tipo de CNI:
OCI_VCN_IP_NATIVE
: los pods obtienen IP de OCI nativas.FLANNEL_OVERLAY
: los pods obtienen IP de Flannel.
- Defina
control_plane_is_public
entrue
ofalse
.
Tarea 1.4: Configuración del pool de nodos
- Defina los pools de nodos en
node_pools
con:- Unidad, versión, tamaño del volumen de inicio y colocación del dominio de disponibilidad (establezca 3 dominios de disponibilidad si corresponde)
- Claves SSH para acceder a los nodos de trabajador del pool
- Active
node_cycle_config
para actualizaciones de nodos seguras:node_cycling_enabled
: active la sustitución del nodo sucesivo.maximum_surge
ymaximum_unavailable
: control de la escala durante las actualizaciones (por ejemplo, 1:0).cycle_modes
: seleccioneBOOT_VOLUME_REPLACE
oINSTANCE_REPLACE
.
Configuración de host de bastión de la tarea 1.5
- Si
is_bastion_created
estrue
, Terraform aprovisiona un bastión de Linux en la subred pública. - Proporcione:
shape
,hostname
,boot_volume_size
, OCID de imagen de Linux y rutas de acceso de clave SSH.
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:
- Una VCN con componentes de red asociados (tablas de rutas, listas de seguridad, gateways), subredes privadas para nodos de trabajador y el punto final de API, y una subred pública para equilibradores de carga.
- Un
ENHANCED_CLUSTER
con el tipo de CNI especificado y la versión de Kubernetes, un pool de nodos gestionado y un host bastión (si está configurado) para un acceso SSH seguro.
Tarea 1.7: Verificación
- Navegue a la consola de OCI para verificar la configuración del cluster.
- 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:
- Configuración de origen: define el origen de la configuración IaC (por ejemplo, OCI Object Storage, GitHub, archivo zip).
- Plantilla de Terraform: la infraestructura se define mediante Terraform.
- OCI Resource Manager: ORM toma la plantilla de Terraform y gestiona el proceso de aprovisionamiento.
- Crear una pila: ORM utiliza la plantilla para crear una pila de recursos de OCI.
- Plan: genera un plan que describe las acciones que se deben realizar.
- Aplicar: aprovisiona los recursos según el plan.
- 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.
- Script de Bash:
create_new_oke_stack_source.sh
.#!/bin/bash # Define the source directory for the stack src_dir="~/oke_advanced_module_orm/oke_app_src" # Create the zip archive from the source code with overwrite rm -f "$src_dir/stackconfig.zip" cd $src_dir zip -r "../stackconfig.zip" * modules/ # List the contents of the zip file for verification /usr/bin/unzip -l "$src_dir/stackconfig.zip"
Verifique el directorio de origen (
~/oke_advanced_module_orm
) para asegurarse de que un archivo denominadostackconfig.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.
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.
Enlaces relacionados
- Creación de un cluster de Oracle Cloud Infrastructure Kubernetes Engine mediante Terraform
- OKE de OCI de Terraform en GitHub
- Gestor de recursos de OCI
Acuses de recibo
- Autores: Mahamat Guiagoussou (arquitecto principal principal de la nube), Payal Sharma (arquitecto superior de la nube), Matthew McDaniel (ingeniero de la nube de personal)
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.
Deploy Oracle Cloud Infrastructure Kubernetes Engine (OKE) using Advanced Terraform Modules
G44439-01