Esposizione delle app con i Service

In Kubernetes, i Pod sono le più piccole unità distribuibili. Sono progettati per essere temporanei e Kubernetes può crearli, distruggerli o spostarli in qualsiasi momento.

Questa flessibilità è ottima per la resilienza, ma crea una difficoltà: come fanno le altre applicazioni a trovare e comunicare in modo affidabile con questi Pod in continua evoluzione?

Ogni Pod riceve un proprio indirizzo IP. Quando un Pod viene riavviato o la sua scala viene modificata, spesso riceve un nuovo indirizzo IP. Collegarsi direttamente all'IP di un Pod è come cercare di colpire un bersaglio mobile!

Immagini un'applicazione web con più Pod. Se un Pod viene riavviato, il suo IP cambia e le connessioni degli altri servizi o degli utenti si interrompono.

È qui che entrano in gioco i Service Kubernetes! Un Service fornisce un endpoint di rete stabile e fisso per un insieme di Pod.

Lo si può considerare un indirizzo permanente per l'applicazione, anche se i Pod sottostanti cambiano continuamente i propri indirizzi.

Un Service funge da livello di astrazione sopra un gruppo di Pod. Fornisce loro un unico indirizzo IP e un nome DNS coerenti.

• Le altre applicazioni usano l'IP o il nome stabile del Service.
• Il Service instrada quindi il traffico verso i Pod integri che gestisce.
• In questo modo i client non dipendono dagli IP dei singoli Pod.

Come fa un Service a sapere verso quali Pod instradare il traffico? Usa label e selettori!

Quando si definisce un Service, si specifica un selector. Qualsiasi Pod che corrisponde a queste label entra automaticamente a far parte del gruppo del Service.

Questa associazione dinamica consente di aggiungere automaticamente i nuovi Pod e rimuovere quelli non integri.

I Service gestiscono il flusso del traffico di rete. Definiscono le porte per mappare le richieste in ingresso sulle porte corrette dei Pod.

Concetti fondamentali relativi alle porte:

• port: la porta sulla quale è in ascolto il Service.
• targetPort: la porta del Pod verso la quale il Service inoltra il traffico.

Come la maggior parte delle risorse Kubernetes, i Service vengono definiti usando file YAML. Vediamo la struttura di base:

• apiVersion: v1
• kind: Service
• metadata: nome, label
• spec: contiene la definizione principale, inclusi selector e ports.

Il tipo di Service più comune per la comunicazione interna è ClusterIP. Espone il Service su un indirizzo IP interno al cluster.

Ecco un esempio per una semplice applicazione web:

Una volta disponibile il file YAML del Service, è possibile distribuirlo nel cluster usando kubectl, proprio come si fa con i Pod o i Deployment.

Questo comando indica a Kubernetes di creare il Service in base alla definizione fornita:

Dopo la distribuzione, il Service riceve un IP stabile e un nome DNS all'interno del cluster. Gli altri Pod possono ora raggiungere l'applicazione usando questo nome.

Ad esempio, un altro Pod potrebbe connettersi a my-web-service:80 e il Service gestirebbe l'instradamento verso i Pod my-webapp corretti.

Ha imparato che i Service Kubernetes forniscono un accesso di rete stabile a Pod dinamici.

Quale delle seguenti descrizioni esprime meglio il ruolo principale di un Service Kubernetes?

Ottimo lavoro! In questa lezione abbiamo esplorato i Service Kubernetes.

• I Pod sono effimeri e hanno IP dinamici.
• I Service forniscono endpoint di rete stabili per i Pod.
• Usano i selettori per individuare i Pod di destinazione.
• I Service mappano port esterne su targetPort interne.
• ClusterIP è un tipo comune per la comunicazione interna.

Nel prossimo argomento approfondiremo i diversi tipi di Service e i relativi utilizzi!