Qual è la differenza tra un pod e una distribuzione?

Ho creato i pod con type:deploymentma vedo che alcuni documenti utilizzano type:pod, più specificamente la documentazione per i pod multi-container :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Ma per creare pod posso semplicemente usare un tipo di distribuzione :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Ho notato che la documentazione del pod dice:

Il comando create può essere utilizzato per creare direttamente un pod oppure può creare un pod o pod tramite una distribuzione. Si consiglia vivamente di utilizzare una distribuzione per creare i pod. Controlla i pod non funzionanti e avvia i nuovi pod come richiesto per mantenere il numero specificato. Se non si desidera che un Deployment controlli il proprio pod (ad es. Il pod sta scrivendo dati non persistenti che non sopravvivranno a un riavvio, o il pod deve essere di breve durata), è possibile creare un pod direttamente con il comando create.

Nota: si consiglia di utilizzare una distribuzione per creare pod. È necessario utilizzare le istruzioni seguenti solo se non si desidera creare una distribuzione.

Ma questo solleva la questione di ciò che kind:podè buono per? Puoi in qualche modo fare riferimento a pod in una distribuzione? Non ho visto un modo. Sembra che ciò che ottieni con i pod sia alcuni metadati extra ma nessuna delle opzioni di distribuzione come replicao una politica di riavvio. A che serve un pod che non persiste nei dati, sopravvive a un riavvio? Penso che sarei in grado di creare un pod multi-container anche con una distribuzione.

Sia Pod che Deployment sono oggetti a pieno titolo nell'API Kubernetes. La distribuzione gestisce la creazione di pod tramite ReplicaSet. Ciò che si riduce è che la Deployment creerà Pod con le specifiche prese dal modello. È piuttosto improbabile che tu abbia mai bisogno di creare Pod direttamente per un caso d'uso di produzione.

La risposta di Radek è molto buona, ma vorrei approfondire la mia esperienza, non userete quasi mai un oggetto con il baccello gentile , perché in pratica non ha alcun senso.

Perché hai bisogno di un oggetto di distribuzione - o di altri oggetti API di Kubernetes come un controller di replica o un set di repliche - che deve mantenere in vita le repliche (pod) (questo è il punto di usare kubernetes).

Quello che userete in pratica per un'applicazione tipica sono:

1. Oggetto di distribuzione (dove specificherai il contenitore / i contenitori di app) che ospiterà il contenitore dell'app con altre specifiche.

2. Oggetto di servizio (che è come un oggetto di raggruppamento e gli fornisce un cosiddetto IP virtuale (IP cluster) per quelli podsche hanno una determinata etichetta - e questi podssono fondamentalmente i contenitori di app che hai distribuito con il precedente oggetto di distribuzione ).

È necessario disporre dell'oggetto di servizio poiché l' podsoggetto di distribuzione può essere eliminato, ridimensionato su e giù e non è possibile fare affidamento sui loro indirizzi IP perché non saranno persistenti.

Quindi hai bisogno di un oggetto come un servizio , che dia a questi podsun IP stabile.

Volevo solo darti un po 'di contesto pods, quindi sai come funzionano le cose insieme.

Spero che ti chiarisca alcune cose, non molto tempo fa ero nei tuoi panni :)

Kubernetes ha tre tipi di oggetti che dovresti conoscere:

• Pod : esegue uno o più contenitori strettamente correlati
• Servizi : imposta la rete in un cluster Kubernetes
• Distribuzione : mantiene una serie di pod identici, assicurando che abbiano la configurazione corretta e che esista il numero giusto di essi.

baccelli:

• Esegue un singolo set di contenitori
• Buono per scopi di sviluppo unici
• Raramente usato direttamente in produzione

Distribuzione:

• Esegue un set di pod identici
• Monitora lo stato di ciascun pod, aggiornandolo se necessario
• Buono per gli sviluppatori
• Buono per la produzione

E sarei d'accordo con altre risposte, dimenticherei dei Pod e userei semplicemente Deployment. Perché? Guarda il secondo punto elenco, controlla lo stato di ciascun pod, aggiornandolo se necessario.

Quindi, invece di lottare con messaggi di errore come questo:

Proibito: gli aggiornamenti dei pod non possono cambiare campi diversi da spec.containers[*].image

Quindi, semplicemente refactoring o ricreare completamente il Pod in una distribuzione che crea un pod per fare ciò che è necessario. Con Deployment puoi modificare qualsiasi pezzo di configurazione tu voglia e non devi preoccuparti di vedere quel messaggio di errore.

Pod è un'istanza del contenitore.

Questo è il risultato di replicas: 3

Pensa a uno deploymentpuò avere molte istanze in esecuzione (replica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod è una collezione di contenitori e oggetto base di Kuberntes. Tutti i contenitori di pod si trovano nello stesso nodo.

• Non adatto alla produzione
• Nessun aggiornamento continuativo

La distribuzione è una sorta di controller in Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

La distribuzione crea un ReplicaSet che a sua volta garantisce che CurrentReplicas sia sempre lo stesso di desiderataReplicas.

Vantaggi:

• È possibile implementare e ripristinare le modifiche utilizzando la distribuzione
• Monitora lo stato di ciascun pod
• Ideale per la produzione
• Supporta aggiornamenti continui

Voglio aggiungere alcune informazioni dal libro di Kubernetes In Action , in modo da poter vedere tutte le immagini e collegare le relazioni tra le risorse di Kubernetes come Pod, Deployment e ReplicationController (ReplicaSet)

Pods

sono l'unità schierabile di base in Kubernetes. Ma nei casi d'uso reali, vuoi che le tue distribuzioni rimangano attive e funzionino automaticamente e rimangano in salute senza alcun intervento manuale. Per questo l'approccio raccomandato è di usare un Deployment , che sotto il cofano crea un ReplicaSet .

Un ReplicaSet , come suggerisce il nome, è un insieme di repliche (Pod) gestite con la cronologia delle revisioni .

(ReplicaSet estende un oggetto più vecchio chiamato ReplicationController - che è esattamente lo stesso ma senza la cronologia delle revisioni.)

Un ReplicaSet monitora costantemente l'elenco dei pod in esecuzione e si assicura che il numero corrente di pod corrispondenti a una determinata specifica corrisponda sempre al numero desiderato.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

Una distribuzione

è una risorsa di livello superiore pensata per distribuire applicazioni e aggiornarle in modo dichiarativo.

Quando si crea una distribuzione , viene creata una risorsa ReplicaSet sotto (eventualmente più di una). I ReplicaSet replicano e gestiscono anche i pod. Quando si utilizza una distribuzione, i baccelli reali sono creati e gestiti dal Deployment ‘s ReplicaSets , non dalla distribuzione diretta

Pensiamo a cosa è successo. Modificando il modello di pod nella risorsa di distribuzione, hai aggiornato l'app con una versione più recente, modificando un singolo campo!

Infine, eseguire il rollback di una distribuzione alla revisione precedente o a qualsiasi revisione precedente in modo semplice con la risorsa di distribuzione.

Queste immagini provengono anche dal libro di Kubernetes In Action .

Cerca di evitare i pod e implementa le distribuzioni invece per la gestione dei contenitori in quanto oggetti del tipo Pod non verranno riprogrammati (o auto-curati) in caso di guasto del nodo o di terminazione del pod.

Una distribuzione è generalmente preferibile perché definisce un ReplicaSet per garantire che il numero desiderato di pod sia sempre disponibile e specifica una strategia per sostituire i pod, come RollingUpdate.

In kubernetes i pod sono le unità dispiegabili più piccole. Ogni volta che creiamo un oggetto kubernetes come Deployments, set di repliche, statefulset, daemonset, crea un pod.

Come accennato in precedenza, le distribuzioni creano pod in base allo stato desiderato menzionato nell'oggetto di distribuzione. Quindi, ad esempio, vuoi 5 repliche di un'applicazione, che hai citato replicas: 5nel tuo manifest di distribuzione. Ora il controller di distribuzione è responsabile della creazione di 5 repliche identiche (non meno, non più) di una determinata applicazione con tutti i metadati come criteri RBAC, criteri di rete, etichette, annotazioni, controllo dello stato, quote di risorse, contaminazione / tolleranze e altri e associarsi a ciascun pod crea.

Ci sono alcuni casi in cui si desidera creare pod, ad esempio se si esegue un sidecar di prova in cui non è necessario eseguire l'applicazione per sempre, non sono necessarie più repliche e si esegue l'applicazione quando si desidera eseguirla la custodia è adatta. Ad esempio helm test, che è una definizione pod che specifica un contenitore con un determinato comando da eseguire.