Cos'è il networking dei container?

Il networking dei container è un meccanismo emergente di sandboxing per le applicazioni utilizzato nei desktop domestici e nelle soluzioni di networking aziendale di livello web che sono concettualmente simili a una macchina virtuale. Un ambiente Linux completo è isolato dall'host e da tutti gli altri container, con utenti, file system, processi e stack di rete specifici. A tutte le applicazioni all'interno del container è consentito accedere o modificare i file o le risorse disponibili solo all'interno del container.

È possibile eseguire più container simultaneamente, ognuno con le proprie installazioni e dipendenze. Ciò è particolarmente utile nei casi in cui le versioni più recenti di un'applicazione possono richiedere l'upgrade di una dipendenza che può causare conflitti con altre dipendenze dell'applicazione in esecuzione sul server. A differenza delle macchine virtuali, i container condividono le risorse dell'host anziché simulare completamente tutto l'hardware sul computer. Di conseguenza, i container sono più piccoli e più rapidi delle macchine virtuali e riducono le spese generali. In particolare, nell'ambito delle applicazioni su scala web, i container sono stati progettati per sostituire le VM come piattaforma di deployment per le architetture di microservizi.

I container si caratterizzano inoltre per la portabilità, come Docker ad esempio, un motore di container che consente agli sviluppatori di pacchettizzare un container e tutte le sue dipendenze. Il pacchetto di container può quindi essere reso disponibile per il download. Una volta scaricato, il container può essere eseguito immediatamente su un host.

Scarica la scheda tecnica di VMware Container Networking with Antrea

Annuncio di VMware Container Networking with Antrea for Kubernetes

Come funziona il networking dei container?

Una rete di container è una forma di virtualizzazione concettualmente simile alle macchine virtuali (VM), ma con differenze specifiche. Innanzitutto, il metodo dei container è una forma di virtualizzazione del sistema operativo, mentre le VM sono una forma di virtualizzazione dell'hardware.

Ogni macchina virtuale in esecuzione su un hypervisor ha il proprio sistema operativo, le proprie applicazioni e le proprie librerie ed è in grado di incapsulare dati persistenti, installare un nuovo sistema operativo, utilizzare un file system diverso da quello dell'host o una versione del kernel diversa.

Per contro, i container sono "istanze in esecuzione" di un'immagine, una virtualizzazione effimera del sistema operativo attivata per eseguire alcune attività e che viene poi eliminata e dimenticata. A causa della natura effimera dei container, gli utenti del sistema eseguono molte più istanze di container rispetto a quelle di macchine virtuali, che richiedono uno spazio di indirizzamento più ampio.

Per creare l'isolamento, un container si basa su due funzionalità del kernel Linux: spazio dei nomi e cgroup. Per dare al container la propria vista del sistema isolandolo dalle altre risorse, viene creato uno spazio dei nomi per ciascuna delle risorse che non è condivisa dal sistema rimanente. Vengono quindi utilizzati i gruppi di controllo (cgroup) per monitorare e limitare risorse di sistema quali CPU, memoria, I/O del disco, rete, ecc.

I vantaggi del networking dei container

La rapida adozione dei container sta sostituendo le VM come piattaforma per i microservizi.

I container offrono diversi vantaggi chiave:

  • Esegui le app containerizzate in parallelo con i carichi di lavoro esistenti: le macchine possono eseguire app containerizzate insieme alle VM tradizionali sulla stessa infrastruttura, garantendo flessibilità e velocità.
  • Coniuga portabilità, sicurezza, visibilità e gestione: la progettazione intrinseca dei container assicura una maggiore sicurezza attraverso sandboxing, trasparenza delle risorse con l'host, gestione delle attività e portabilità dell'ambiente di esecuzione.
  • Utilizza al meglio l'infrastruttura esistente con scalabilità senza problemi: usa l'SDDC esistente per evitare la riprogettazione dell'infrastruttura che richiede tempo e costi elevati e porta alla creazione di silos. I silos si verificano quando reparti diversi gestiscono la propria infrastruttura IT all'interno della stessa organizzazione. Questo "effetto silos" crea problemi durante l'implementazione di policy e upgrade IT a livello di organizzazione a causa delle differenze nelle configurazioni tecniche adottate da ciascun reparto. La reintegrazione dei silos è un processo dispendioso in termini di tempo e costi e può essere evitato attraverso il networking dei container.
  • Offri agli sviluppatori un'interfaccia compatibile con Docker: gli sviluppatori che già conoscono Docker possono sviluppare le applicazioni in container mediante un'interfaccia compatibile con Docker ed effettuarne il provisioning tramite la UI o il portale di gestione self-service.

Utilizzo del networking dei container nei deployment di applicazioni su scala web

I container vengono distribuiti come parte dell'architettura dei microservizi negli ambienti aziendali per aiutare a incapsulare singole attività comuni per applicazioni web di grandi dimensioni. Ogni attività può avere il proprio container: i container rivolti all'esterno (come API e GUI) sono aperti alla rete Internet pubblica, mentre gli altri risiedono sulla rete privata.

Il modello dei microservizi offre diversi vantaggi:

  • Facilità di deployment: le configurazioni degli host possono essere integrate nei container affinché siano pronte all'uso dopo il deployment.
  • Monouso: i container sono progettati per l'avvio e l'eliminazione rapidi. Se l'host non funziona, riportare le applicazioni online è semplice come attivare un server di riserva.
  • Tolleranza agli errori: i container creano una ridondanza semplice per database e server web. Copiare lo stesso container su più nodi assicura disponibilità elevata e tolleranza agli errori.

Tipi di networking dei container

Oggi si ricorre a cinque tipi di networking dei container, le cui caratteristiche sono incentrate su modelli IP per container e IP per pod e sul requisito della Network Address Translation (NAT) rispetto alla mancata necessità di conversione.

  • Nessuna: il container riceve uno stack di rete, che però è privo di connessione esterna. Questa modalità è utile per testare i container, predisporre un container per una successiva connessione di rete e per l'assegnazione ai container che non richiedono comunicazioni esterne.
  • Bridge: container collegati a un bridge su una rete host interna e autorizzati a comunicare con altri container sullo stesso host. Non è possibile accedere ai container dall'esterno dell'host. La rete bridge è quella predefinita per i container Docker.
  • Host: questa configurazione consente a un container creato di condividere lo spazio dei nomi di rete dell'host, concedendo al container l'accesso a tutte le interfacce di rete dell'host. È la meno complessa tra le configurazioni di rete esterna, ma è soggetta a conflitti tra le porte dovuti all'uso condiviso delle interfacce di rete.
  • Underlay: gli underlay aprono le interfacce host direttamente ai container in esecuzione sull'host ed eliminano la necessità di mappatura delle porte, rendendoli più efficienti dei bridge.
  • Overlay: gli overlay utilizzano i tunnel di rete per la comunicazione tra gli host, consentendo ai container di agire come se si trovassero sulla stessa macchina quando sono ospitati su host diversi.

Soluzioni e prodotti correlati

Antrea

Immagini e file binari firmati con supporto aziendale completo per Project Antrea

Connetti container e Kubernetes

Connetti e proteggi le applicazioni e i microservizi containerizzati.

Virtual Cloud Network

Porta l'esperienza del public cloud nel data center con Virtual Cloud Network