Ik wilde weten wat het verschil is tussen een replicatiecontroller en een implementatie binnen Kubernetes (1.2). Ik ga door het document Aan de slag (http://kubernetes.io/docs/hellonode/) Ik heb een implementatie gemaakt – maar het wordt niet weergegeven in de web-UI.
Als ik apps maak vanuit de web-UI, worden ze gemaakt als replicatiecontrollers. Functioneel lijken ze echter erg op elkaar (ze beheren beide pods en hebben services).
Dus – wat is het verschil en wanneer moet ik ze gebruiken?
Antwoord 1, autoriteit 100%
Implementaties zijn een nieuwer en hoger concept dan replicatiecontrollers. Ze beheren de implementatie van replicasets (ook een nieuwer concept, maar vrijwel gelijk aan replicatiecontrollers), en zorgen voor een gemakkelijke update van een replicaset en de mogelijkheid om terug te gaan naar een eerdere implementatie.
Voorheen moest dit worden gedaan met kubectl rolling-updatedie niet declaratief was en niet de rollback-functies bood.
Kubernetes Dashboard is nog niet bijgewerkt om implementaties te ondersteunen en ondersteunt momenteel alleen replicatiecontrollers (zie Implementaties niet zichtbaar in Kubernetes Dashboard).
BEWERK: het dashboard ondersteunt nu implementaties.
Antwoord 2, autoriteit 23%
Hier is het laatste antwoord 2020op de vraag die in 2016, 4 jaar geleden, begon
Een goed antwoord is gegeven in 2017
https://www. mirantis.com/blog/kubernetes-replication-controller-replica-set-and-deployments-understanding-replication-options/
Nu zijn we in Kubernetes-versie – 1.17, we hebben 3 typen
Implementatie (aanbevolen)
Deployment is een API-object op een hoger niveau dat de onderliggende replicasets en hun pods op dezelfde manier bijwerkt als kubectl rolling-update. Implementaties worden aanbevolen als u deze rolling update-functionaliteit wilt, omdat ze, in tegenstelling tot kubectl rolling-update, declaratief zijn, aan de serverzijde en extra functies hebben.
ReplicaSet
ReplicaSet is de volgende generatie ReplicationController die de nieuwe set-gebaseerde labelselector ondersteunt. Het wordt voornamelijk gebruikt door Deployment als een mechanisme om het maken, verwijderen en bijwerken van pods te orkestreren. Houd er rekening mee dat we aanbevelen implementaties te gebruiken in plaats van rechtstreeks replicasets te gebruiken, tenzij u aangepaste update-orkestratie nodig hebt of helemaal geen updates nodig hebt.
ReplicationController (niet aanbevolen)
Zorgt ervoor dat een opgegeven aantal pod-replica’s tegelijkertijd wordt uitgevoerd. Met andere woorden, een ReplicationController zorgt ervoor dat een pod of een homogene set pods altijd beschikbaar en beschikbaar is.
Antwoord 3, autoriteit 12%
Deploymentszijn nog in bèta (hun API bevindt zich onder extensions/v1beta1), wat waarschijnlijk de reden is waarom ze niet in de gebruikersinterface verschijnen. Ze automatiseren statusovergangen en houden de pods gewoon in leven. Van de gelinkte pagina:
Een implementatie biedt declaratieve updates voor pods en replicasets
(de volgende generatie replicatiecontroller). U hoeft alleen
beschrijf de gewenste status in een Deployment-object, en de Deployment
controller zal de actuele status veranderen in de gewenste status op a
gecontroleerd tarief voor u. U kunt implementaties definiëren om nieuwe
bronnen, of vervang bestaande door nieuwe.
Ze bieden ook uitrolgeschiedenis en andere handige functies.
$ 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
Het houdt ook de wijzigingen bij.
$ 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.
Antwoord 4, autoriteit 11%
Nu met release 1.1ondersteunt Dashboard implementaties. U kunt uw dashboard implementeren of bijwerken zonder te hoeven wachten op de 1.3-release van k8s. U kunt bijvoorbeeld de officiële YAMLgebruiken, die we zojuist hebben gewijzigd om implementaties te gebruiken.
Over het algemeen raad ik aan (en mensen van Google en Kubernetes-bijdragers doen dat ook) om implementaties via RC’s te gebruiken, omdat deze een veel krachtiger primitief zijn (inclusief rollende updates, versiebeheer/controle, canaray/groen-blauwe implementaties, rollbacks, enz.).
Antwoord 5, autoriteit 3%
Het dashboard (web-UI) is enorm opnieuw ontworpen om het beheer van meer bronnen te ondersteunen (zoals Deploymentsen DaemonSets, enz.) en het huidige dashboard laat niet veel toe met betrekking tot Deployments.
Het beheren van implementaties in het dashboard wordt binnenkort ondersteund in kubernetes 1.3 (zie uitgave Functieverzoek: implementaties afhandelen ).
Antwoord 6, autoriteit 3%
Mijn ervaring is dat implementaties niet alle functionaliteit bieden die ik nodig heb. Of misschien gebruik ik ze op een verkeerde manier.
Als het nodig is om de node-server opnieuw op te starten – alle pods die op die server draaien, zijn gestart door implementatie – mislukken. En ik kan geen manier vinden om dit te vermijden.
Maar,
Denk dat de oplossing een replicatiecontroller is. In de beschrijving staat tenminste dat het dergelijke gevallen behandelt.
Het belangrijkste voordeel van implementatie, zoals ik het zie, is dat je constant van versie van je app moet veranderen.
Dus beide manieren zijn goed, maar om verschillende redenen.