Informazioni sulla progettazione di una topologia di Kubernetes nel cloud

Le aziende sono sempre in grado di distribuire i carichi di lavoro cloud nativi in contenitori ridotti. In un ambiente di produzione è necessario un modo per gestire i contenitori e assicurarsi che non vi sia tempo di inattività. Kubernetes è un motore di orchestrazione open source per la gestione di applicazioni e servizi in container.

Oracle Cloud Infrastructure Container Engine for Kubernetes è un servizio gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le applicazioni container nei cluster Kubernetes nel cloud.

Architettura

L'architettura di una topologia basata su Kubernetes nel cloud dipende da fattori quali, ad esempio, se i carichi di lavoro in container devono essere accessibili dalla rete Internet pubblica, la dimensione e il numero di pool di nodi e i requisiti di tolleranza degli errori dei carichi di lavoro.

Nel diagramma riportato di seguito viene illustrata un'architettura di riferimento di un cluster Kubernetes in un'area Oracle Cloud Infrastructure che contiene più domini di disponibilità.

L'architettura contiene i componenti riportati di seguito.

• Rete cloud virtuale (VCN): tutte le risorse nella topologia si trovano in una singola VCN.
• Subnet:

  La VCN in questa architettura contiene quattro subnet, due pubblici e due privati. Una delle subnet pubbliche è per l'host di base, mentre l'altra per il load balancer su Internet. Di due subnet private, una per l'host di amministrazione che contiene gli strumenti necessari per gestire il cluster Kubernetes. L'altra subnet privata è per i nodi del cluster Kubernetes.

  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 le subnet 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:

  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 mostra due nodi del load balancer, ognuno in un dominio di disponibilità distinto.

• 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. Nell'architettura di riferimento, l'host di amministrazione si trova in una subnet privata e è possibile accedervi 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. Tutti i nodi operativi in questa architettura di riferimento si trovano in un singolo pool di nodi e sono collegati a una subnet privata. Se necessario, è possibile creare più pool di nodi.

  I nodi dei lavoratori nell'architettura di riferimento non sono accessibili direttamente dalla rete Internet pubblica. Gli utenti delle applicazioni containerizzate possono accedervi tramite il load balancer. Gli amministratori possono accedere 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. I nodi principali di Kubernetes eseguiti nella tenancy di Oracle e non vengono mostrati.

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à, come illustrato nella seguente architettura.

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.