Controller di replica VS Deployment in Kubernetes

Question

Volevo sapere qual è la differenza tra un controller di replica e una distribuzione all'interno di Kubernetes (1.2). Passare al documento introduttivo (http://kubernetes.io/docs/hellonode/) Ho creato una distribuzione, ma non viene visualizzata nell'interfaccia utente web.

Quando creo app dall'interfaccia utente Web, vengono create come controller di replica. Funzionalmente però, sembrano molto simili (entrambi gestiscono i pod e hanno servizi).

Quindi, qual è la differenza e quando dovrei usare ciascuna?

Answer 1

Le distribuzioni sono un concetto più nuovo e di livello superiore rispetto ai controller di replica. Gestiscono la distribuzione dei set di replica (anche un concetto più recente, ma praticamente equivalente ai controller di replica) e consentono un facile aggiornamento di un set di repliche e la possibilità di eseguire il rollback a una distribuzione precedente.

In precedenza ciò avrebbe dovuto essere eseguito con kubectl rolling-update che non era dichiarativo e non ha fornito le funzionalità di rollback.

Kubernetes Dashboard non è stato ancora aggiornato per supportare le distribuzioni e al momento supporta solo i controller di replica (vedere Deployments not visible in Kubernetes Dashboard).

MODIFICA: la dashboard ora supporta le distribuzioni.

Answer 2

Deployments sono ancora in versione beta (la loro API è inferiore a extensions/v1beta1), che è probabilmente il motivo per cui non vengono visualizzati nell'interfaccia utente. Automatizzano le transizioni di stato oltre a mantenere in vita i pod. Dalla pagina collegata:

una distribuzione fornisce aggiornamenti dichiarativi per cialde e replica Imposta (replica controller di prossima generazione). È sufficiente che descriva lo stato desiderato in un oggetto di distribuzione e il controller di distribuzione cambierà lo stato effettivo allo stato desiderato a una tariffa controllata . È possibile definire Distribuzioni per creare nuove risorse o sostituire quelle esistenti con nuove.

Forniscono anche la cronologia di distribuzione e altre funzioni utili.

$ kubectl rollout history deployment/nginx-deployment 
deployments "nginx-deployment": 
REVISION CHANGE-CAUSE 
1   kubectl create -f docs/user-guide/nginx-deployment.yaml --record 
2   kubectl apply -f docs/user-guide/new-nginx-deployment.yaml 
3   kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml 

Tiene traccia delle modifiche anche.

$ kubectl rollout history deployment/nginx-deployment --revision=2 
deployments "nginx-deployment" revision 2 
Labels:  app=nginx,pod-template-hash=1564180365 
Annotations: kubernetes.io/change-cause=kubectl apply -f docs/user-guide/new-nginx-deployment.yaml 
Image(s): nginx:1.9.1 
No volumes. 

Answer 3

Il cruscotto (web UI) è stato enormemente riprogettato per supportano la gestione di più risorse (come Deployments e DaemonSets, etc.) e il cruscotto attuale non consente molto per quanto riguarda Deployments.

La gestione delle distribuzioni nella dashboard sarà presto supportata in Kubernetes 1.3 (fare riferimento al numero Feature request: handle Deployments).

Answer 4

Ora con release 1.1 Dashboard supporta le distribuzioni. È possibile distribuire o aggiornare la dashboard senza dover attendere la versione 1.3 di k8. Ad esempio, è possibile utilizzare lo official YAML, che abbiamo appena modificato per utilizzare le distribuzioni oggi.

In genere, consiglierei (e anche i collaboratori di Google e Kubernetes) utilizzare le distribuzioni su RC in quanto sono una primitiva molto più potente (inclusi aggiornamenti continui, versioning/auditing, distribuzioni canaray/green-blue, rollbacks , eccetera.).

Answer 5

Dalla mia esperienza, le implementazioni forniscono non tutte le funzionalità di cui ho bisogno. O, forse, li sto usando in modo sbagliato.

Quando è necessario riavviare il server nodo: tutti i pod in esecuzione su quel server avviati dalla distribuzione non funzionano. E non riesco a trovare un modo per evitarlo.

Ma,

soluzione secondo me è un controller di replica. Almeno nella descrizione è scritto che gestisce tali casi.

Il vantaggio di implementazione principale, come si vede, è quando è necessario modificare costantemente la versione dell'app.

Quindi entrambi i modi sono buoni ma per ragioni diverse.