Informazioni sull'impostazione di un cluster Kubernetes nel cloud

Una topologia basata su Kubernetes nel cloud contiene numerosi componenti, tra cui le risorse di rete, le istanze di computazione e i nodi Kubernetes. Per distribuire e gestire tale topologia in modo efficiente, definire l'infrastruttura cloud come codice (IaC) nei file di configurazione Terraform.

Per modificare la topologia, creare una versione per i moduli Terraform appropriati, aggiornare le definizioni delle risorse e applicare la configurazione rivista. Se necessario, è possibile eseguire il rollback a una versione precedente dell'infrastruttura con facilità.

Usare le basi di sviluppo Terraform fornite in questa soluzione per distribuire l'infrastruttura necessaria per un ambiente Kubernetes basato su cloud.

Operazioni preliminari

Prima di iniziare a creare la topologia di Kubernetes in Oracle Cloud, è necessario conoscere le opzioni architetturali e comprendere i componenti dell'architettura.

Vedere Informazioni sulla progettazione di una topologia Kubernetes per le applicazioni in container nel cloud.

Architettura

La topologia di esempio che questa soluzione fornisce un codice Terraform per contenere una singola rete cloud virtuale (VCN) con le risorse di rete e Kubernetes richieste, in una singola area Oracle Cloud Infrastructure.

L'architettura è costituita dai componenti riportati di seguito.

Nota:

Il codice Terraform include variabili di input che è possibile utilizzare per ottimizzare l'architettura in base ai requisiti di rete dei carichi di lavoro in container, alla dimensione e al numero di pool di nodi richiesti, ai vincoli di tolleranza degli errori e così via.

• Rete cloud virtuale (VCN)

  Tutte le risorse nella topologia si trovano in una singola rete. Viene definito il prefisso CIDR per la rete (impostazione predefinita: 10.0.0.0/16).

• Subnet
  La VCN nella topologia di esempio contiene quattro subnet. Le dimensioni delle subnet vengono definite.

  Subnet	Prefisso CIDR predefinito	Descrizione
  Subnet di base	10.0.1.0/29	Una subnet pubblica per l'host di base opzionale.
  Subnet del load balancer	10.0.2.32/27 se pubblica (10.0.2.0/27 se privata)	Una subnet per i nodi del load balancer. Si sceglie se la subnet è pubblica o privata.
  Subnet di amministrazione	10.0.1.8/29	Una subnet privata per l'host di amministrazione opzionale che contiene gli strumenti necessari per gestire il cluster Kubernetes, ad esempio kubectl, helm e l'interfaccia CLI di Oracle Cloud Infrastructure.
  Subnet di nodi di lavoro	10.0.64.0/18	Una subnet per i nodi di lavoro di Kubernetes. Si sceglie se la subnet è pubblica o privata.

  Tutte le subnet sono regionali, ovvero estende tutti i domini di disponibilità nell'area, abbreviato come AD1, AD2 e AD3 nel diagramma dell'architettura. Pertanto sono protette da errori di disponibilità del dominio. È possibile utilizzare una subnet regionale per le risorse distribuite in qualsiasi dominio di disponibilità nell'area.

• Gateway di rete
  • Gateway del servizio (facoltativo)

    Il gateway di servizi consente alle risorse nella rete VCN di accedere ai servizi Oracle, ad esempio lo storage degli oggetti Oracle Cloud Infrastructure, Oracle Cloud Infrastructure File Storage e Oracle Cloud Infrastructure Database privatamente, ovvero senza esporre il traffico a Internet pubblico. Le connessioni con il gateway di servizi possono essere avviate dalle risorse all'interno della rete VCN e non dai servizi con i quali le risorse comunicano.

  • Gateway NAT (facoltativo)

    Il gateway NAT consente alle istanze di computazione collegate a subnet private nella rete VCN di accedere alla rete Internet pubblica. Le connessioni attraverso il gateway NAT possono essere avviate dalle risorse all'interno della rete VCN e non dalla rete Internet pubblica.

  • Gateway Internet

    Il gateway Internet consente la connettività tra la rete Internet pubblica e qualsiasi risorsa nelle subnet pubbliche all'interno della rete VCN.

• Host Bastion (facoltativo)

  L'host di base è un'istanza di calcolo che funge da punto di accesso alla topologia dall'esterno del cloud.

  Il provisioning dell'host bastion viene eseguito in genere in un DMZ. Consente di proteggere le risorse riservate collocandole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. È possibile esporre un singolo punto di accesso noto che è possibile sottoporre a audit a intervalli regolari. Pertanto, si evitano di esporre i componenti più sensibili della topologia, senza compromettere l'accesso.

  L'host di base nella topologia di esempio è collegato a una subnet pubblica e dispone di un indirizzo IP pubblico. Una regola di sicurezza in entrata è configurata per consentire le connessioni SSH all'host di base da Internet pubblico. Per fornire un livello di sicurezza aggiuntivo, è possibile limitare l'accesso SSH all'host di base solo da un blocco specifico di indirizzi IP.

  È possibile accedere alle istanze di Oracle Cloud Infrastructure nelle subnet private tramite l'host di base. A tale scopo, abilitare l'inoltro ssh-agent, che consente di connettersi all'host di base, quindi accedere al server successivo inoltrando le credenziali dal computer. È inoltre possibile accedere alle istanze nella subnet privata utilizzando il tunneling SSH dinamico. Il tunnel dinamico fornisce un proxy SOCKS sulla porta locale, ma le connessioni provengono dall'host remoto.

• Nodi load balancer (non inclusi nel codice di esempio)

  I nodi del load balancer intercettano e distribuiscono il traffico ai nodi Kubernetes disponibili su cui sono in esecuzione le applicazioni in container. Se le applicazioni devono essere accessibili da Internet pubblico, utilizzare load balancer pubblici, altrimenti utilizzare load balancer privati, che non dispongono di un indirizzo IP pubblico. L'architettura non mostra alcun nodo del load balancer.

• Host di amministrazione (facoltativo)

  Utilizzando un host di amministrazione, è possibile evitare di installare ed eseguire strumenti di gestione dell'infrastruttura, ad esempio kubectl, helm e l'interfaccia CLI di Oracle Cloud Infrastructure all'esterno del cloud. L'host di amministrazione nella topologia di esempio si trova in una subnet privata e è accessibile tramite l'host di base. Per poter eseguire l'interfaccia CLI di Oracle Cloud Infrastructure sull'host di amministrazione, è necessario designarla come principal dell'istanza.

• Nodi lavoratori Kubernetes

  I nodi di lavoro di Kubernetes sono le istanze di computazione in cui puoi distribuire le tue applicazioni in container. Nella topologia di esempio tutti i nodi operativi si trovano in un singolo pool di nodi e sono collegati a una subnet privata. È possibile personalizzare il numero di pool di nodi, la dimensione di ciascun pool e se utilizzare una subnet pubblica in base alle proprie esigenze.

  Se i nodi dei lavoratori sono collegati a una subnet privata, non è possibile accedervi direttamente da Internet pubblico. Gli utenti possono accedere alle applicazioni containerizzate tramite il load balancer.

  Se si abilita l'accesso SSH ai nodi dei lavoratori, gli amministratori possono creare connessioni SSH ai nodi dei lavoratori tramite l'host di base.

  L'architettura mostra tre nodi operativi, ciascuno in un dominio di disponibilità distinto all'interno dell'area: AD1, AD2 e AD3.

  Nota:

  Se l'area in cui si desidera distribuire le applicazioni in container contiene un singolo dominio di disponibilità, i nodi dei lavoratori vengono distribuiti nei domini di errore (FD) all'interno del dominio di disponibilità.

Informazioni su Servizi e autorizzazioni richiesti

Questa soluzione richiede i seguenti servizi e autorizzazioni:

Servizio	Autorizzazioni richieste
Oracle Cloud Infrastructure Identity and Access Management	Gestire gruppi e criteri dinamici.
Oracle Cloud Infrastructure Networking	Gestire le VCN, le subnet, i gateway Internet, i gateway NAT, i gateway di servizio, le tabelle di instradamento e le liste di sicurezza.
Oracle Cloud Infrastructure Compute	Gestisce le istanze di calcolo.
Oracle Cloud Infrastructure Container Engine for Kubernetes	Gestire cluster e pool di nodi. Vedere Configurazione dei criteri per la creazione e la distribuzione dei cluster.