Qual è la differenza tra ReplicaSet e ReplicationController?

Question

Da quello che posso dire nella documentazione, un ReplicaSet viene creato quando si esegue un Deployment. Sembra supportare alcune delle stesse funzionalità di uno ReplicationController - scala su/giù e riavvio automatico, ma non è chiaro se supporta gli aggiornamenti rolling o la scala automatica.

La guida utente v1.1.8 mostra come creare una distribuzione in Deploying Applications (che crea automaticamente un ReplicaSet), tuttavia il comando kubectl get replicasets non è disponibile fino alla v1.2.0. Non riesco a trovare altre informazioni su ReplicaSet nella documentazione.

ReplicaSet sostituirà eventualmente ReplicationController? Perché dovrei utilizzare Deployment e ReplicaSet anziché ReplicationController?

Answer 1

Replica Set è la nuova generazione di controller di replica. Il controller di replica è un po 'imperativo, ma i set di repliche cercano di essere il più dichiarativi possibile.

1. La differenza principale tra un set di replica e un controller di replica al momento è il supporto del selettore.

+--------------------------------------------------+-----------------------------------------------------+ 
|     Replica Set     |    Replication Controller    | 
+--------------------------------------------------+-----------------------------------------------------+ 
| Replica Set supports the new set-based selector. | Replication Controller only supports equality-based | 
| This gives more flexibility. for eg:    | selector. for eg:         | 
|   environment in (production, qa)   |    environment = production    | 
| This selects all resources with key equal to | This selects all resources with key equal to  | 
| environment and value equal to production or qa | environment and value equal to production   | 
+--------------------------------------------------+-----------------------------------------------------+ 

2. La seconda cosa è l'aggiornamento dei pod.

+-------------------------------------------------------+-----------------------------------------------+ 
|      Replica Set      |   Replication Controller    | 
+-------------------------------------------------------+-----------------------------------------------+ 
| rollout command is used for updating the replica set. | rolling-update command is used for updating | 
| Even though replica set can be used independently, | the replication controller. This replaces the | 
| it is best used along with deployments which   | specified replication controller with a new | 
| makes them declarative.        | replication controller by updating one pod | 
|              | at a time to use the new PodTemplate.   | 
+-------------------------------------------------------+-----------------------------------------------+ 

Queste sono le due cose che differenzia RS e RC. Le distribuzioni con RS sono ampiamente utilizzate in quanto più dichiarative.

Answer 2

Per ora, la differenza dovrebbe essere insignificante nella maggior parte dei casi. ReplicaSet ha un selettore di etichette generalizzato: https://github.com/kubernetes/kubernetes/issues/341#issuecomment-140809259. Dovrebbe supportare tutte le funzionalità supportate dal controller di replica.

ReplicaSet sostituirà eventualmente ReplicationController? Perché dovrei usare Deployment e ReplicaSet invece di ReplicationController?

Questo si riduce all'aggiornamento continuo o alla distribuzione. Leggere i documenti sulla distribuzione per comprendere la differenza: http://kubernetes.io/docs/user-guide/deployments/. In breve, se si avvia un aggiornamento continuo e si chiude il laptop, le repliche presentano alcune combinazioni di versioni di immagini intermedie. Se si crea un deployement e si chiude il laptop, la distribuzione ottiene POST correttamente su apiserver, nel qual caso funziona sul lato server, oppure no, nel qual caso tutte le repliche sono ancora nella versione precedente.

La cosa brutta è che quasi tutta la documentazione attuale riguarda ReplicationControllers.

D'accordo, la maggior parte dei documenti viene aggiornata. Sfortunatamente i documenti su internet sono più difficili da aggiornare rispetto a quelli su github.