Kubernetes: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Aggiunte into su risorse e pod
Correzione definizione services
Riga 53:
 
L'utilizzo un modello a risorse permette di descrivere con un [[Programmazione dichiarativa|linguaggio dichiarativo]] lo stato che in sistema deve assumere, senza la necessità di conoscere la tecnologia sottostante. Questo aspetto è particolarmente importante nei contesti cloud in cui Kubernetes viene offerto come servizio avendo la flessibilità di scelta sulla tecnologia sottostante.
 
Kubernetes permette di aggiungere informazionietichette di tipo keychiave-valuevalore chiamate "labels" a qualunque elemento all'interno del sistemarisorsa, come ad esempio a pod e [[Kubernetes#Kubernetes node|nodi]]. Questo permette di creare riferimenti tra le varie risorse per implementare molteplici funzionalità.
 
=== Pods ===
Riga 58 ⟶ 60:
 
I pod possono essere gestiti manualmente tramite le [[Application programming interface|API]] di Kubernetes o più di frequente tramite i controller che assicurano il mantenimento della loro esecuzione.
 
=== Label ===
Kubernetes permette di aggiungere informazioni di tipo key-value chiamate "labels" a qualunque elemento all'interno del sistema, come ad esempio pod e [[Kubernetes#Kubernetes node|nodi]].
 
=== Services ===
UnIl ''service'' Kubernetesdefinisce ècome unesporre insieme didei pod su una rete interna o esterna. Il service definisce un nome che lavoranoviene assieme,risolto comedal unoDNS stratointerno dial unacluster applicazionecon [[Architetturauno dei pod ad esso multi-tier|multi-tier]]associati. Il setpod diassociati podal cheservice costituisconosono unquelli servizioche sonohanno definitiin mediantecomune la label edefinita selectordal service. Di default un service è esposto all'interno di un cluster, ma può essere esposto anche all'esterno del cluster.<ref name="kubernetes-101-external-access">{{Cita web|url=http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/}}</ref>
 
== Vedi anche ==