Implementa Oracle Kubernetes Engine (OKE) per la produzione: best practice e linee guida

Introduzione

Questa è la terza esercitazione della nostra serie di automazione di Oracle Cloud Infrastructure Kubernetes Engine (OKE), sulla base dei concetti introdotti nella seconda esercitazione, Distribuire Oracle Cloud Infrastructure Kubernetes Engine (OKE) utilizzando i moduli Terraform avanzati. In questa guida, ci concentriamo sulle implementazioni OKE pronte per la produzione ed esploriamo le best practice chiave che migliorano l'affidabilità dei cluster, ottimizzano i costi e semplificano le operazioni. Dimostreremo alcune delle best practice che utilizzano Terraform, evidenziando al contempo le insidie comuni che gli utenti incontrano durante la creazione dei cluster.

Perché distribuire OKE in un elemento importante della VCN esistente

La creazione di un cluster OKE di livello produzione richiede un'attenta pianificazione tra processi di rete, posizionamento dei nodi e operativi. La distribuzione in una rete cloud virtuale (VCN) esistente consente al cluster di integrarsi perfettamente con subnet, tabelle di instradamento e regole di sicurezza preconfigurate. Ciò riduce il sovraccarico operativo, garantisce la coerenza con l'infrastruttura della tua organizzazione e consente a più carichi di lavoro o cluster di coesistere in modo efficiente all'interno della stessa rete.

I parametri chiave Terraform durante la distribuzione in una VCN esistente includono:

In alternativa, quando si distribuisce un ambiente completamente nuovo, impostare is_vcn_created = true per eseguire il provisioning di una nuova rete. Dopo un'operazione terraform apply riuscita, Terraform acquisisce gli OCID della VCN appena creata e delle relative subnet negli output. Questi valori possono essere riutilizzati nelle distribuzioni future impostando is_vcn_created = false e facendo riferimento agli OCID salvati nel file terraform.tfvars, consentendo a Terraform di utilizzare la rete esistente invece di crearne una nuova. L'esecuzione di terraform plan in questa fase conferma che la VCN e le subnet correnti vengono preservate, evitando modifiche non necessarie all'infrastruttura.

Con la fondazione della rete in atto, questo tutorial sposta l'attenzione su una serie di best practice orientate alla produzione volte a rendere i cluster OKE più resilienti, scalabili e più facili da gestire. Applicando queste pratiche, i clienti possono implementare cluster OKE ad alta disponibilità, a costi contenuti e in linea con le policy organizzative, gli standard di governance e i requisiti operativi pronti per la produzione. Scarica l'ultimo codice da qui oke_advanced_module.zip.

Best practice OKE: linee guida pronte per la produzione

1. Utilizzare il ciclo dei nodi per eseguire l'upgrade dei pool di nodi OKE.

Il ciclo dei nodi è una strategia di upgrade in sequenza sicura che aggiorna le immagini dei nodi, le versioni Kubernetes o le configurazioni di sistema senza interrompere i carichi di lavoro. Il ciclo dei nodi è importante perché consente ai cluster di evolversi in modo sicuro nel tempo, applicando patch o aggiornamenti senza influire sui carichi di lavoro di produzione. Per i clienti, questo riduce i rischi operativi, garantisce la disponibilità continua durante gli aggiornamenti e consente l'esecuzione affidabile dei carichi di lavoro mantenendo le versioni più recenti. OKE supporta i due tipi elencati di seguito.

Parametri come maximum_surge e maximum_unavailable controllano come gli aggiornamenti bilanciano la velocità con la disponibilità. Per gli aggiornamenti senza tempi di inattività, impostare maximum_surge = 1 e maximum_unavailable = 0, assicurando che un nuovo nodo venga connesso prima di sostituire quello precedente. Di seguito è riportato un esempio di ciclo dei nodi con Max sovratensione 1 e Max non disponibile 0.

OKENodepoolupgraded

Per attivare l'aggiornamento di un cluster OKE esistente che porta al ciclo dei nodi:

Nel file terraform.tfvars:

Quindi eseguire terraform plan

Dovresti vedere output come questo:

Quando si esegue terraform apply, OKE inizia a ciclicare i pool di nodi un nodo alla volta utilizzando la strategia BOOT_VOLUME_REPLACE. In questa modalità, solo il volume di avvio del nodo viene sostituito mentre l'istanza di computazione di base rimane invariata. Di conseguenza, l'aggiornamento del nodo viene eseguito in posizione e gli attributi di rete come l'indirizzo IP privato rimangono invariati come di seguito:

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

Per eseguire il ciclo dei nodi utilizzando l'opzione INSTANCE_REPLACE, impostare cycle_modes su INSTANCE_REPLACE in modo che OKE esegua il ciclo dei pool di nodi di un nodo alla volta. In questa modalità, ogni nodo viene eliminato e ricreato da zero, inclusa l'istanza di computazione e il relativo volume di avvio. Di conseguenza, l'upgrade del nodo applica tutti gli attributi aggiornati, ad esempio una nuova versione di Kubernetes o modifiche alla forma, ma gli attributi di rete come l'IP privato potrebbero cambiare. Questo approccio garantisce un nodo completamente aggiornato con le configurazioni più recenti, fornendo la massima copertura di aggiornamento mantenendo la disponibilità del cluster attraverso sostituzioni in sequenza, come mostrato di seguito:

OKEclusterUpgrading OKEclusterUpgrading

2. Usa l'applicazione di tag OCI sui nodi di lavoro OKE e sui load balancer per tenere traccia dei costi

Quando esegui i carichi di lavoro Kubernetes in Oracle Cloud Infrastructure (OCI), è essenziale capire da dove provengono i tuoi costi. L'applicazione di tag è la chiave. OCI ti consente di applicare tag definite e in formato libero a ogni risorsa, inclusi cluster OKE, nodi di lavoro, load balancer e volumi persistenti. Ciò è importante perché consente report dettagliati sui costi, audit più semplici e responsabilità per il consumo del cloud. Per i clienti, l'applicazione di tag fornisce insight su quali carichi di lavoro consumano la maggior parte delle risorse, migliora la trasparenza dei costi e supporta le decisioni di ottimizzazione per controllare la spesa del cloud.

Perché l'applicazione di tag è importante:

# 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 queste tag in atto, puoi generare report dettagliati sui costi in OCI Cost Analysis, identificare quali carichi di lavoro stanno utilizzando la maggior parte delle risorse e prendere decisioni informate sulla scalabilità o l'ottimizzazione.

3. Endpoint API, nodo, load balancer e subnet pod separati (se applicabile).

Una progettazione di rete corretta è una best practice in OKE perché migliora la sicurezza, le prestazioni e la scalabilità. La separazione di endpoint API, nodi di lavoro, pod, load balancer e host bastion in subnet separate isola il traffico critico, consente tabelle di instradamento personalizzate o gruppi di sicurezza di rete (NSG) e impedisce a un tipo di traffico di interferire con un altro. Questo approccio è essenziale per mantenere una comunicazione sicura, un instradamento prevedibile e un forte isolamento delle risorse negli ambienti di produzione.

I clienti traggono vantaggio dalla disponibilità di un cluster più sicuro, gestibile e resiliente in grado di ridimensionarsi in modo efficiente e gestire picchi di traffico o attacchi senza influire sui carichi di lavoro. Di seguito è riportato lo snippet di terrform.tfvars che consente di definire i blocchi CIDR per le subnet.

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

Seguendo questa procedura, puoi migliorare la sicurezza, semplificare la gestione della rete e rendere il tuo cluster più resiliente ai picchi di traffico o agli attacchi.

4. Utilizzare un pool di nodi per ogni architettura del dominio di disponibilità quando si utilizza Cluster Autoscaler

In OCI, ogni dominio di disponibilità (AD) ha una capacità indipendente. Sebbene i pool di nodi possano estendersi su più domini AD per migliorare l'alta disponibilità, questa operazione non è consigliata quando il ridimensionatore automatico del cluster è abilitato. Il ridimensionatore automatico richiede capacità in tutti i domini di disponibilità selezionati e potrebbe non riuscire a ridimensionarsi se qualsiasi dominio di disponibilità esaurisce le risorse.

Per evitare questo problema, i pool di nodi devono essere configurati in modo da utilizzare un singolo AD quando il ridimensionamento automatico è abilitato. Se la capacità non è disponibile in un dominio AD, il ridimensionatore automatico può ridimensionare un pool di nodi alternativo in un altro dominio AD.

Configurazione del pool di nodi di esempio:

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

Configurazione di esempio del ridimensionatore automatico del cluster:

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

5. Pool di nodi separati per diversi requisiti di carico di lavoro (x86, ARM, GPU)

Utilizza pool di nodi separati per carichi di lavoro che richiedono forme di computazione diverse, ad esempio x86, ARM o GPU. Questo approccio migliora l'utilizzo delle risorse, l'efficienza della pianificazione e il comportamento di ridimensionamento automatico garantendo che ogni carico di lavoro venga eseguito sull'infrastruttura più adatta.

I pod vengono pianificati nei pool di nodi corretti utilizzando etichette, selettori, affinità o attributi e tolleranze dei nodi, consentendo a Kubernetes di posizionare i carichi di lavoro sui nodi con l'architettura o le funzionalità necessarie.

Combinando pool di nodi dedicati con il posizionamento esplicito dei pod, i clienti ottengono prestazioni prevedibili, scalabilità efficiente e gestione semplificata dei cluster. In questo esempio, vengono creati pool di nodi separati per le forme Intel e AMD, garantendo un posizionamento ottimale dei carichi di lavoro e operazioni cluster resilienti.

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
  }

}

Dopo l'esecuzione di terraform apply, il cluster OKE mostrerà due pool di nodi separati:

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. Usa Cloud-Init per la personalizzazione dei nodi

Gli script di inizializzazione del cloud sono essenziali per automatizzare la configurazione dei nodi di lavoro in OKE, garantendo un'impostazione coerente del sistema operativo, l'installazione dei package e l'ottimizzazione del sistema in tutti i nodi. L'integrazione di cloud-init con Terraform consente di eseguire automaticamente il provisioning dei nodi al boot, rendendo le distribuzioni ripetibili, verificabili e pronte per la produzione. Per ulteriori informazioni sugli script di inizializzazione cloud-init, consultare questo documento Uso di script di inizializzazione cloud-init personalizzati per impostare nodi gestiti.

Nel codice Terraform fornito, ogni pool di nodi fa riferimento a uno script di inizializzazione cloud utilizzando il parametro cloud_init_path. I clienti possono modificare i contenuti di cloud-init-general.sh in base alle proprie esigenze, seguendo le indicazioni riportate nel documento precedente. In questa demo viene utilizzato lo script di avvio predefinito fornito nella documentazione di riferimento. I clienti possono anche modificare la posizione dello script di inizializzazione cloud aggiornando il parametro cloud_init_path, come mostrato di seguito:

cloud_init_path = "cloud-init-general.sh"

Ciò garantisce che durante il provisioning dei nodi o il ciclo dei nodi, ogni nodo nuovo o sostituito venga inizializzato in modo coerente con la configurazione di sistema richiesta. In combinazione con Terraform, l'inizializzazione del cloud consente di applicare automaticamente gli script controllati a livello di versione, eliminando i task manuali di post-provisioning.

Vantaggi principali per i nodi di lavoro:

7. Migliora funzionalità OKE mediante componenti aggiuntivi

I componenti aggiuntivi di OKE estendono le funzionalità del cluster per l'osservabilità, la scalabilità, la sicurezza e la gestione del traffico. Utilizzando Terraform, puoi abilitare o disabilitare in modo selettivo i componenti aggiuntivi in base ai requisiti del carico di lavoro e ridurre al minimo l'uso delle risorse:

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

Componenti aggiuntivi comuni e relativi vantaggi:

Le procedure consigliate per i componenti aggiuntivi:

8. Utilizzare l'autenticazione o la ricerca automatica OIDC se le risorse esterne richiedono l'accesso ai cluster k8s.

Integra la ricerca automatica OIDC con provider di identità esterni (ad esempio Okta o Azure AD) se gli sviluppatori o gli strumenti di automazione esterni a OCI devono eseguire l'autenticazione nel cluster Kubernetes. Ciò consente la gestione centralizzata delle identità e l'accesso federato senza dover gestire gli utenti Kubernetes locali o distribuire i file kubeconfig. Questo approccio è particolarmente utile quando strumenti CI/CD esterni come GitHub Actions richiedono l'accesso al cluster o quando i carichi di lavoro all'interno del cluster devono integrarsi in modo sicuro con servizi esterni come il vault HashiCorp. Facendo affidamento su OIDC, le organizzazioni possono applicare criteri di autenticazione coerenti, semplificare la gestione degli accessi e ridurre il sovraccarico operativo della rotazione delle credenziali, mantenendo al contempo forti limiti di sicurezza.

9. Utilizzare i gruppi di sicurezza di rete anziché le liste di sicurezza

I gruppi di sicurezza di rete (NSG) sono preferiti rispetto alle liste di sicurezza tradizionali quando si proteggono i cluster OKE. I gruppi di sicurezza di rete consentono regole di sicurezza più granulari, flessibili e riutilizzabili che possono essere collegate direttamente a risorse specifiche come nodi di lavoro, load balancer o pod. Ciò li rende più adatti per ambienti Kubernetes dinamici in cui le risorse si ridimensionano o cambiano di frequente. Al contrario, gli elenchi di sicurezza si applicano a livello di subnet e sono progettati per includere intere reti VCN o subnet, il che fornisce meno controllo quando si implementano requisiti di sicurezza delle applicazioni con filtro. L'uso dei gruppi NSG migliora l'igiene della sicurezza, semplifica la gestione delle regole e consente un isolamento più stretto tra i componenti del cluster.

10. Abilita osservabilità con OCI Logging Analytics e metriche OKE

Integra OKE con OCI Logging Analytics e Monitoring per ottenere una visibilità approfondita sulle prestazioni del cluster e del carico di lavoro. Logging Analytics fornisce l'aggregazione dei log avanzata, l'analisi e il rilevamento delle anomalie, mentre Monitoring raccoglie le metriche dal piano di controllo Kubernetes e dai nodi di lavoro. Insieme, questi servizi consentono ai team di visualizzare le tendenze, risolvere i problemi più velocemente e configurare gli avvisi per una gestione proattiva. Questa soluzione è particolarmente adatta per i clienti che cercano una piattaforma di osservabilità nativa OCI che astrae le complessità dell'inclusione dei log, dello storage e dell'analisi, integrando al contempo perfettamente con altri servizi OCI.

11. Utilizza l'identità del carico di lavoro se i pod hanno bisogno dell'accesso alle risorse OCI.

Quando si esegue l'autenticazione a OCI, le chiavi API vengono in genere utilizzate, ma queste credenziali sono di lunga durata e richiedono storage persistente, il che le rende difficili da gestire in modo sicuro su larga scala. Sebbene le istanze e i principal risorsa migliorino questo aspetto consentendo alle istanze o ai servizi di computazione di assumere la propria identità, OKE Workload Identity estende ulteriormente questo concetto consentendo ai singoli pod Kubernetes di assumere la propria identità OCI. Abilitando l'identità del carico di lavoro OCI, i pod possono accedere in modo sicuro ai servizi OCI come lo storage degli oggetti o il log utilizzando i criteri IAM, senza credenziali di codifica fissa o basandosi sulle autorizzazioni a livello di nodo. Ciò fornisce un controllo dell'accesso con filtro, verificabile e sicuro, essenziale per gli ambienti Kubernetes multi-tenant di livello produzione.

12. Utilizzare la dimensione subnet appropriata per i nodi e i pod OKE.

La pianificazione corretta dei blocchi CIDR della subnet è una best practice poiché ogni nodo richiede un IP primario e IP secondari aggiuntivi per i pod. Piccole sottoreti possono portare rapidamente all'esaurimento dell'IP, impedendo il ridimensionamento o gli aggiornamenti. Ciò è importante per mantenere la stabilità dei cluster e sostenere la crescita. I clienti traggono vantaggio assicurando che i cluster possano scalare in modo prevedibile, evitando interruzioni operative e supportando i carichi di lavoro futuri senza richiedere la riprogettazione della rete. Per gli ambienti di produzione, allocare blocchi CIDR di dimensioni maggiori e fare riferimento alla guida al dimensionamento della subnet OKE per assicurarsi che la VCN possa supportare le richieste correnti e future dei carichi di lavoro.

13. Utilizzare il servizio Full Stack Disaster Recovery per eseguire il backup del cluster k8s

L'utilizzo di OCI Full Stack Disaster Recovery per il cluster OKE è una best practice perché protegge la configurazione del cluster, le applicazioni e la rete con failover e failback coordinati in tutte le region. Ciò è importante per la continuità e la conformità del business in caso di interruzioni regionali o guasti del sistema. I clienti traggono vantaggio da tempi di inattività ridotti, ripristino rapido e sicurezza che i carichi di lavoro mission-critical rimangano operativi anche durante i disastri.

Per ulteriori informazioni, consulta la sezione relativa ai piani di switchover e failover automatici per OCI Kubernetes Engine (Stateful) con OCI Full Stack Disaster Recovery

Passi successivi

Terraform rende il provisioning OKE coerente, automatizzato e scalabile. Seguendo le best practice come l'applicazione di tag OCI, la separazione delle subnet e la configurazione dei nodi standardizzati, i cluster rimangono sicuri, organizzati e trasparenti in termini di costi. Nel prossimo blog, ci baseremo su queste basi per esplorare le operazioni basate sull'intelligenza artificiale, mostrando come integrare Oracle AIOps, abilitare l'osservabilità basata sull'intelligenza artificiale e creare un progetto OKE end-to-end per i carichi di lavoro AI. Rimani sintonizzato per la nostra prossima sessione LiveLabs, in cui potrai acquisire un'esperienza pratica con queste tecniche e sperimentare le implementazioni OKE in un ambiente live.

Conferme

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Oracle Learning Explorer.

Per la documentazione del prodotto, visitare Oracle Help Center.