Τι θα συμβεί αν αναπτύξουμε την εφαρμογή με μια ανάπτυξη και στη συνέχεια αλλάξουμε την έκδοση της εφαρμογής στο σύνολο αντιγράφων;

Μετά την αλλαγή της έκδοσης της εφαρμογής στον πόρο Deployment, το σχετικό ReplicaSet θα ενημερωθεί. Το Deployment θα δημιουργήσει ένα νέο ReplicaSet με τη νέα έκδοση της εικόνας κοντέινερ. Το παλιό ReplicaSet θα μειωθεί σταδιακά, ενώ το νέο ReplicaSet θα αυξηθεί. Αυτή η διαδικασία ονομάζεται rolling update (διαδοχική ενημέρωση) και πραγματοποιείται αυτόματα από προεπιλογή.

Συγκεκριμένα βήματα:

1. Ο χρήστης ή το σύστημα CI/CD ενημερώνει το Deployment.
2. Το Deployment δημιουργεί ένα νέο ReplicaSet με ένα spec που περιέχει τη νέα έκδοση της εικόνας.
3. Το νέο ReplicaSet αρχίζει να δημιουργεί pods με τη νέα έκδοση.
4. Μόλις μερικά από τα νέα pods φτάσουν στην κατάσταση Ready, το Deployment αρχίζει να μειώνει το παλιό ReplicaSet, διαγράφοντας τα pods με την παλιά έκδοση.
5. Η διαδικασία συνεχίζεται μέχρι όλα τα pods να βρίσκονται υπό τον έλεγχο του νέου ReplicaSet με τη νέα έκδοση.
6. Το παλιό ReplicaSet παραμένει, αλλά με τον επιθυμητό αριθμό replikas ίσο με 0.

Αυτό διασφαλίζει μηδενικό χρόνο διακοπής κατά την ενημέρωση της εφαρμογής (υπό την προϋπόθεση ότι υπάρχουν επαρκείς πόροι και τα pods είναι σωστά έτοιμα) και επιτρέπει την εύκολη επιστροφή στην προηγούμενη έκδοση απλώς ενημερώνοντας ξανά το Deployment.

Παράδειγμα ενημέρωσης YAML Deployment:

# Ενημερωμένο YAML Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25% # Μέγιστος αριθμός pods που μπορούν να δημιουργηθούν πάνω από τον επιθυμητό αριθμό
      maxUnavailable: 25% # Μέγιστος αριθμός pods που μπορούν να μην είναι διαθέσιμα κατά τη διάρκεια της ενημέρωσης
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v1.1.0 # Τελευταία έκδοση εικόνας
        ports:
        - containerPort: 80

Η χειροκίνητη αλλαγή του ReplicaSet συνιστάται έντονα να αποφεύγεται και μπορεί να οδηγήσει σε απρόβλεπτη συμπεριφορά, καθώς το Deployment θα προσπαθήσει να ευθυγραμμίσει την κατάσταση του ReplicaSet με την επιθυμητή κατάσταση, overwriting τις αλλαγές σας. Όλες οι διαχειριζόμενες αλλαγές στην εφαρμογή πρέπει να πραγματοποιούνται μέσω του πόρου Deployment.