Replication Controller VS-Bereitstellung in Kubernetes

Question

Ich wollte wissen, was der Unterschied zwischen einem Replikationscontroller und einer Bereitstellung innerhalb von Kubernetes (1.2) ist. Ich gehe durch das Erste-Schritte-Dokument (http://kubernetes.io/docs/hellonode/) Ich habe eine Bereitstellung erstellt - aber sie wird nicht auf der Web-Benutzeroberfläche angezeigt.

Wenn ich Apps über die Web-Benutzeroberfläche erstellen, werden sie als Replikations-Controller erstellt. Funktional jedoch scheinen sie sich sehr ähnlich zu sein (sie verwalten beide Pods und haben Services).

Also - was ist der Unterschied und wann sollte ich jedes verwenden?

Answer 1

Bereitstellungen sind ein neueres und höheres Konzept als Replikationscontroller. Sie verwalten die Bereitstellung von Replikatsätzen (ebenfalls ein neueres Konzept, entsprechen jedoch weitgehend den Replikationscontrollern) und ermöglichen die einfache Aktualisierung eines Replikatsatzes sowie die Möglichkeit, zu einer früheren Bereitstellung zurückzukehren.

Bisher musste dies mit kubectl rolling-update gemacht werden, was nicht deklarativ war und die Rollback-Funktionen nicht zur Verfügung stellte.

Kubernetes Dashboard wurde noch nicht für die Unterstützung von Bereitstellungen aktualisiert und unterstützt derzeit nur Replikations-Controller (siehe Deployments not visible in Kubernetes Dashboard).

EDIT: Das Dashboard unterstützt jetzt Bereitstellungen.

Answer 2

Deployments sind immer noch in der Beta (ihre API ist unter extensions/v1beta1), was wahrscheinlich ist, warum sie nicht in der Benutzeroberfläche angezeigt werden. Sie automatisieren Zustandsübergänge, indem sie Pods nur am Leben erhalten. Von der gelinkten Seite:

Ein Deployment bietet deklaratives Updates für Pods und Replica Sets (die nächste Generation Replication Controller). Sie müssen nur den gewünschten Status in einem Deployment-Objekt beschreiben, und der Deployment Controller wird den aktuellen Zustand in den gewünschten Zustand bei einer gesteuerten Rate von für Sie ändern. Sie können Bereitstellungen definieren, um neue Ressourcen zu erstellen oder vorhandene durch neue zu ersetzen.

Sie bieten auch Rollout-Verlauf und andere nützliche Funktionen.

$ 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 

Es behält auch die Änderungen im Auge.

$ 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

Das Dashboard (Web-UI) wurde enorm umgestaltet, um die Verwaltung von mehr Ressourcen zu unterstützen (wie Deployments und DaemonSets, usw.) und das aktuelle Dashboard erlaubt nicht viel in Bezug auf Deployments.

Verwalten von Bereitstellungen im Dashboard wird bald in kubernetes 1.3 unterstützt (siehe Ausgabe Feature request: handle Deployments).

Answer 4

Jetzt mit release 1.1 Dashboard unterstützt Bereitstellungen. Sie können Ihr Dashboard bereitstellen oder aktualisieren, ohne auf die Version 1.3 von k8s warten zu müssen. Sie können zum Beispiel die official YAML verwenden, die wir gerade geändert haben, um heute Bereitstellungen zu verwenden.

Im Allgemeinen würde ich empfehlen (und Leute von Google und Kubernetes Mitwirkenden auch tun) mit Bereitstellungen über RCs, da sie eine viel leistungsfähigere primitive sind (rollierende Updates, Versionierung/Auditing, canaray/grün-blau Bereitstellungen, Rollbacks , etc.).

Answer 5

Aus meiner Erfahrung bieten Bereitstellungen nicht alle Funktionen, die ich brauche. Oder vielleicht benutze ich sie falsch.

Wenn der Knotenserver neu gestartet werden muss - alle Pods, die auf diesem Server mit der Bereitstellung gestartet wurden - müssen fehlschlagen. Und ich kann keinen Weg finden, dies zu vermeiden.

Aber,

Think-Lösung ist ein Replikationscontroller. Zumindest in der Beschreibung wird geschrieben, dass es solche Fälle behandelt.

Haupteinsatzvorteil, wie ich es sehe, ist, wenn Sie die Version Ihrer App ständig ändern müssen.

Also beide Wege sind gut, aber aus verschiedenen Gründen.