Despliegue de Oracle Kubernetes Engine (OKE) para la producción: mejores prácticas y directrices

Introducción

Este es el tercer tutorial de nuestra serie de automatización de Oracle Cloud Infrastructure Kubernetes Engine (OKE), que se basa en los conceptos presentados en el segundo tutorial, Despliegue de Oracle Cloud Infrastructure Kubernetes Engine (OKE) mediante módulos de Terraform avanzados. En esta guía, nos centramos en las implementaciones de OKE listas para producción y exploramos las mejores prácticas clave que mejoran la fiabilidad del cluster, optimizan los costos y simplifican las operaciones. Demostraremos algunas de las mejores prácticas con Terraform y, al mismo tiempo, resaltaremos los escollos comunes que los usuarios encuentran al crear clusters.

Por qué es importante desplegar OKE en una VCN existente

La creación de un cluster de OKE de producción requiere una planificación cuidadosa en las redes, la colocación de nodos y los procesos operativos. El despliegue en una red virtual en la nube (VCN) existente permite que el cluster se integre sin problemas con subredes, tablas de rutas y reglas de seguridad preconfiguradas. Esto reduce la sobrecarga operativa, garantiza la coherencia con la infraestructura de su organización y permite que varias cargas de trabajo o clusters coexistan de manera eficiente en la misma red.

Los parámetros clave de Terraform al realizar el despliegue en una VCN existente incluyen:

De manera alternativa, al desplegar un entorno nuevo desde cero, defina is_vcn_created = true para aprovisionar una nueva red. Después de que terraform apply se realice correctamente, Terraform captura los OCID de la VCN recién creada y sus subredes en las salidas. Estos valores se pueden volver a utilizar en futuros despliegues definiendo is_vcn_created = false y haciendo referencia a los OCID guardados en el archivo terraform.tfvars, lo que permite a Terraform utilizar la red existente en lugar de crear una nueva. La ejecución de terraform plan en esta etapa confirma que la VCN y las subredes actuales se conservan, evitando cualquier cambio innecesario en la infraestructura.

Con la base de la red en su lugar, este tutorial cambia el enfoque a un conjunto de mejores prácticas orientadas a la producción destinadas a hacer que los clusters de OKE sean más resistentes, escalables y fáciles de operar. Al aplicar estas prácticas, los clientes pueden implementar clústeres de OKE que sean altamente disponibles, rentables y estén alineados con las políticas organizativas, los estándares de gobernanza y los requisitos operativos listos para la producción. Descargue el código más reciente desde aquí oke_advanced_module.zip.

Mejores prácticas de OKE: directrices para la producción

1. Utilice la sincronización de nodos para actualizar los pools de nodos de OKE.

El ciclo de nodos es una estrategia de actualización segura y sucesiva que actualiza las imágenes de los nodos, las versiones de Kubernetes o las configuraciones del sistema sin interrumpir las cargas de trabajo. El ciclo de nodos es importante porque permite que los clusters evolucionen de forma segura a lo largo del tiempo, aplicando parches o actualizaciones sin afectar a las cargas de trabajo de producción. Para los clientes, esto reduce el riesgo operativo, garantiza una disponibilidad continua durante las actualizaciones y permite que las cargas de trabajo se ejecuten de forma fiable mientras se mantienen las últimas versiones. OKE admite dos tipos:

Parámetros como maximum_surge y maximum_unavailable controlan cómo las actualizaciones equilibran la velocidad con la disponibilidad. Para las actualizaciones sin tiempo de inactividad, defina maximum_surge = 1 y maximum_unavailable = 0, asegurándose de que un nodo nuevo se ponga en línea antes de sustituir el anterior. A continuación, se muestra un ejemplo de sincronización de nodos con la sobrecarga máxima 1 y el máximo 0 no disponibles.

OKENodepoolupgraded

Para activar la actualización de un cluster de OKE existente que lleva al ciclo de nodos:

En el archivo terraform.tfvars:

A continuación, ejecute terraform plan

Debe ver una salida como esta:

Cuando ejecuta terraform apply, OKE comienza a sincronizar los pools de nodos de un nodo a la vez mediante la estrategia BOOT_VOLUME_REPLACE. En este modo, solo se sustituye el volumen de inicio del nodo, mientras que la instancia informática subyacente permanece igual. Como resultado, la actualización del nodo se realiza en su lugar y los atributos de red, como la dirección IP privada, permanecen sin cambios como se indica a continuación:

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

Para sincronizar nodos mediante la opción INSTANCE_REPLACE, defina cycle_modes en INSTANCE_REPLACE para que OKE sincronice los pools de nodos de un nodo a la vez. En este modo, cada nodo se suprime y se vuelve a crear desde cero, incluida la instancia informática y su volumen de inicio. Como resultado, el cambio de versión del nodo aplica todos los atributos actualizados, como una nueva versión de Kubernetes o cambios de unidad, pero los atributos de red como la IP privada pueden cambiar. Este enfoque garantiza un nodo totalmente actualizado con las últimas configuraciones, lo que proporciona la máxima cobertura de actualización al tiempo que mantiene la disponibilidad del cluster mediante sustituciones sucesivas, como se muestra a continuación:

OKEclusterUpgrading OKEclusterUpgrading

2. Utilizar el etiquetado de OCI en los nodos de trabajador y equilibradores de carga de OKE para realizar un seguimiento de los costos

Al ejecutar cargas de trabajo de Kubernetes en Oracle Cloud Infrastructure (OCI), es esencial comprender de dónde provienen sus costos. El etiquetado es la clave. OCI permite aplicar etiquetas definidas y de formato libre a cada recurso, incluidos los clusters de OKE, los nodos de trabajador, los equilibradores de carga y los volúmenes persistentes. Esto es importante porque permite generar informes de costos detallados, facilitar la auditoría y la responsabilidad por el consumo de la nube. Para los clientes, el etiquetado proporciona estadísticas sobre qué cargas de trabajo consumen más recursos, mejora la transparencia de costos y respalda las decisiones de optimización para controlar el gasto en la nube.

Por qué es importante el etiquetado:

# Cluster-level tagging
cluster_freeform_tag_key   = "Environment"
cluster_freeform_tag_value = "Development"

# Node pool-level tagging
node_pool_freeform_tag_key   = "LOB"
node_pool_freeform_tag_value = "DevOps Tech"

# Bastion host tagging
freeform_tags = {
  project     = "devops"
  environment = "production"}

# Defined tagging
defined_tags = { 
  “Corporate_Standard.CostCenter”  = “Finance-123"
  “Corporate_Standard.Environment” = “Production” }

Con estas etiquetas en su lugar, puedes generar informes de costos detallados en OCI Cost Analysis, identificar qué cargas de trabajo consumen más recursos y tomar decisiones informadas sobre la ampliación o la optimización.

3. Punto final de API, nodo, equilibrador de carga y subredes de pod independientes (si corresponde).

Un diseño de red adecuado es una mejor práctica en OKE porque mejora la seguridad, el rendimiento y la escalabilidad. La separación de puntos finales de API, nodos de trabajador, pods, equilibradores de carga y hosts bastión en subredes independientes aísla el tráfico crítico, permite tablas de rutas personalizadas o grupos de seguridad de red (NSG) e impide que un tipo de tráfico interfiera con otro. Este enfoque es esencial para mantener una comunicación segura, un enrutamiento predecible y un fuerte aislamiento de recursos en los entornos de producción.

Los clientes se benefician de contar con un cluster más seguro, manejable y resistente que se puede ampliar de forma eficiente y gestionar picos de tráfico o ataques sin que esto afecte a las cargas de trabajo. A continuación se muestra el fragmento de terrform.tfvars que permite definir bloques CIDR para subredes.

k8apiendpoint_private_subnet_cidr_block       = "REPLACE_WITH_YOUR_CIDR"   # API endpoint subnet
workernodes_private_subnet_cidr_block         = "REPLACE_WITH_YOUR_CIDR"   # Worker nodes subnet
pods_private_subnet_cidr_block                = "REPLACE_WITH_YOUR_CIDR"   # Pod subnet (CNI)
serviceloadbalancers_public_subnet_cidr_block = "REPLACE_WITH_YOUR_CIDR"   # Load balancer subnet
bastion_public_subnet_cidr_block              = "REPLACE_WITH_YOUR_CIDR"   # Bastion host subnet

Al seguir esta práctica, mejorará la seguridad, simplificará la gestión de red y hará que el cluster sea más resistente a los picos de tráfico o los ataques.

4. Uso de un pool de nodos por arquitectura de dominio de disponibilidad al utilizar la escala automática del cluster

En OCI, cada dominio de disponibilidad (AD) tiene capacidad independiente. Aunque los pools de nodos pueden abarcar varios dominios de disponibilidad para mejorar la alta disponibilidad, esto no se recomienda cuando la escala automática del cluster está activada. La escala automática requiere capacidad en todos los dominios de disponibilidad seleccionados y puede no ampliarse si algún dominio de disponibilidad se queda sin recursos.

Para evitarlo, los pools de nodos se deben configurar para utilizar un único dominio de disponibilidad cuando la ampliación automática está activada. Si la capacidad no está disponible en un AD, la escala automática puede escalar un pool de nodos alternativo en otro AD.

Ejemplo de configuración de pool de nodos:

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

Ejemplo de configuración de escala automática del cluster:

cluster_autoscaler_config = {
  node_mapping = {
    key = "nodes"
    value = "1:5:ocid1.nodepool....."
  }
}

5. Pools de nodos independientes para diferentes requisitos de carga de trabajo (x86, ARM, GPU)

Utilice pools de nodos independientes para cargas de trabajo que requieren diferentes unidades de computación, como x86, ARM o GPU. Este enfoque mejora la utilización de recursos, la eficiencia de programación y el comportamiento de ampliación automática al garantizar que cada carga de trabajo se ejecute en la infraestructura más adecuada.

Los pods se programan para los pools de nodos correctos mediante etiquetas de nodos, selectores, afinidades o contaminantes y tolerancias, lo que permite a Kubernetes colocar cargas de trabajo en nodos con la arquitectura o las capacidades necesarias.

Al combinar pools de nodos dedicados con la colocación explícita de pod, los clientes logran un rendimiento predecible, una ampliación eficaz y una gestión de clusters simplificada. En este ejemplo, se crean pools de nodos independientes para unidades Intel y AMD, lo que garantiza una ubicación óptima de la carga de trabajo y operaciones de cluster resilientes.

worker_node_pools = {
  AMD_node_pool = {
    name               = "node_pool_one"                # Node pool name
    shape              = "VM.Standard.E5.Flex"          # Compute shape
    shape_config = {
      memory = 16                                       # Memory (GB)
      ocpus  = 1                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }
  Intel_node_pool = {
    name               = "node_pool_two"                # Node pool name
    shape              = "VM.Standard2.8"      	        # Compute shape
    shape_config = {
      memory = 120                                      # Memory (GB)
      ocpus  = 8                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"  
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }

}

Después de ejecutar terraform apply, el cluster de OKE mostrará dos pools de nodos independientes:

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. Uso de Cloud-Init para la personalización de nodos

Los scripts de cloud-init son esenciales para automatizar la configuración de nodos de trabajador en OKE, lo que garantiza una configuración coherente del sistema operativo, la instalación de paquetes y el ajuste del sistema en todos los nodos. La integración de cloud-init con Terraform permite aprovisionar nodos automáticamente en el inicio, haciendo que los despliegues sean repetibles, auditables y estén listos para producción. Consulte este documento Uso de scripts de inicialización de cloud-init personalizados para configurar nodos gestionados para obtener más información sobre los scripts cloud-init.

En el código de Terraform proporcionado, cada pool de nodos hace referencia a un script cloud-init mediante el parámetro cloud_init_path. Los clientes pueden modificar el contenido de cloud-init-general.sh según sus requisitos, siguiendo las directrices del documento anterior. En esta demostración, se utiliza el script de inicio por defecto proporcionado en la documentación a la que se hace referencia. Los clientes también pueden cambiar la ubicación del script cloud-init actualizando el parámetro cloud_init_path, como se muestra a continuación:

cloud_init_path = "cloud-init-general.sh"

Esto garantiza que durante el aprovisionamiento o el ciclo de nodos, todos los nodos nuevos o reemplazados se inicializen de manera coherente con la configuración del sistema necesaria. Combinado con Terraform, cloud-init permite la aplicación automática de scripts controlados por versión, lo que elimina las tareas manuales posteriores al aprovisionamiento.

Ventajas clave para los nodos de trabajador:

7. Mejora de la funcionalidad de OKE con complementos

Los complementos de OKE amplían las capacidades del cluster para la observación, el escalado, la seguridad y la gestión del tráfico. Con Terraform, puede activar o desactivar complementos de forma selectiva en función de los requisitos de carga de trabajo y minimizar el uso de recursos:

kubernetes_dashboard_enabled       = false
metrics_server_enabled             = false
cluster_autoscaler_enabled         = false
certificate_manager_enabled        = false
istio_enabled                      = false
native_ingress_controller_enabled  = false

Complementos comunes y sus ventajas:

Mejores prácticas para complementos:

8. Utilice la autenticación/detección de OIDC si los recursos externos necesitan acceso a los clusters k8s.

Integre la detección de OIDC con proveedores de identidad externos (como Okta o Azure AD) si los desarrolladores o las herramientas de automatización externas a OCI necesitan autenticarse en el cluster de Kubernetes. Esto permite la gestión de identidades centralizada y el acceso federado sin la necesidad de gestionar usuarios locales de Kubernetes ni distribuir archivos kubeconfig. Este enfoque es especialmente útil cuando las herramientas de integración y despliegue continuos externas como GitHub Las acciones necesitan acceso al cluster o cuando las cargas de trabajo dentro del cluster se deben integrar de forma segura con servicios externos como HashiCorp Vault. Al confiar en OIDC, las organizaciones pueden aplicar políticas de autenticación coherentes, simplificar la gestión de acceso y reducir la sobrecarga operativa de la rotación de credenciales al tiempo que mantienen fuertes límites de seguridad.

9. Uso de grupos de seguridad de red en lugar de listas de seguridad

Los grupos de seguridad de red (NSG) se prefieren a las listas de seguridad tradicionales al proteger los clusters de OKE. Los NSG permiten reglas de seguridad más granulares, flexibles y reutilizables que se pueden asociar directamente a recursos específicos, como nodos de trabajador, equilibradores de carga o pods. Esto los hace más adecuados para entornos dinámicos de Kubernetes en los que los recursos se escalan o cambian con frecuencia. Por el contrario, las listas de seguridad se aplican en el nivel de subred y están diseñadas para abarcar redes virtuales en la nube o subredes completas, lo que proporciona menos control al implementar requisitos de seguridad de aplicaciones detallados. El uso de NSG mejora la higiene de la seguridad, simplifica la gestión de reglas y permite un aislamiento más estrecho entre los componentes del cluster.

10. Activar la observabilidad con las métricas de OCI Logging Analytics y OKE

Integre OKE con OCI Logging Analytics and Monitoring para obtener una visibilidad profunda del rendimiento del cluster y la carga de trabajo. Logging Analytics proporciona agregación de logs avanzada, análisis y detección de anomalías, mientras que Monitoring recopila métricas del plano de control de Kubernetes y los nodos de trabajador. Juntos, estos servicios permiten a los equipos visualizar tendencias, solucionar problemas más rápido y configurar alertas para una gestión proactiva. Esta solución es especialmente adecuada para los clientes que buscan una plataforma de observación nativa de OCI que resuma las complejidades de la ingestión de logs, el almacenamiento y el análisis, al tiempo que se integra a la perfección con otros servicios de OCI.

11. Utilice la identidad de carga de trabajo si los pods necesitan acceso a los recursos de OCI.

Al autenticarse en OCI, las claves de API se suelen utilizar, pero estas credenciales tienen una larga vida útil y requieren almacenamiento persistente, lo que dificulta su gestión segura a escala. Mientras que los principales de instancia y recursos mejoran esto al permitir que las instancias o los servicios informáticos asuman su propia identidad, OKE Workload Identity amplía este concepto aún más al permitir que los pods individuales de Kubernetes asuman su propia identidad de OCI. Al activar OCI Workload Identity, los pods pueden acceder de forma segura a servicios de OCI como Object Storage o Logging mediante políticas de IAM, sin credenciales de codificación fija ni depender de permisos de nivel de nodo. Esto proporciona un control de acceso detallado, auditable y seguro, que es esencial para entornos de Kubernetes multiinquilino de nivel de producción.

12. Utilice el tamaño de subred adecuado para los nodos y pods de OKE.

La planificación correcta de los bloques CIDR de la subred es una buena práctica porque cada nodo requiere una IP primaria y IP secundarias adicionales para los pods. Las subredes pequeñas pueden provocar rápidamente agotamiento de IP, lo que evita la ampliación o las actualizaciones. Esto es importante para mantener la estabilidad del cluster y apoyar el crecimiento. Los clientes se benefician al garantizar que los clusters se puedan escalar de forma predecible, evitar interrupciones operativas y admitir cargas de trabajo futuras sin necesidad de rediseñar la red. Para entornos de producción, asigne bloques CIDR más grandes y consulte la guía de tamaño de subred de OKE para garantizar que la VCN pueda satisfacer las demandas de carga de trabajo actuales y futuras.

13. Utilizar el servicio Full Stack Disaster Recovery para realizar una copia de seguridad del cluster k8s

Aprovechar OCI Full Stack Disaster Recovery para el cluster de OKE es una práctica recomendada porque protege la configuración del cluster, las aplicaciones y las redes con failover y failback coordinados entre regiones. Esto es importante para la continuidad del negocio y el cumplimiento en caso de interrupciones regionales o fallos del sistema. Los clientes se benefician de la reducción del tiempo de inactividad, la recuperación rápida y la confianza en que las cargas de trabajo esenciales permanecen operativas incluso durante los desastres.

Para obtener más información, consulte Automatización de planes de switchover y failover para OCI Kubernetes Engine (con estado) con OCI Full Stack Disaster Recovery

Pasos Siguientes:

Terraform hace que el aprovisionamiento de OKE sea consistente, automatizado y escalable. Siguiendo las mejores prácticas, como el etiquetado de OCI, la separación de subredes y la configuración estandarizada de nodos, sus clusters permanecen seguros, organizados y rentables. En el siguiente blog, nos basaremos en estas bases para explorar las operaciones basadas en IA, mostrar cómo integrar Oracle AIOps, habilitar la observabilidad basada en IA y crear un plan de OKE integral para las cargas de trabajo de IA. Permanezca atento a nuestra próxima sesión de LiveLabs, donde podrá obtener experiencia práctica con estas técnicas y experimentar con los despliegues de OKE en un entorno activo.

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.