თუ ჩვენ დავაყენებთ აპლიკაციას დიპლოით და შემდეგ შევცვლით აპლიკაციის ვერსიას რეპლიკასეტში, რა მოხდება?

მომხმარებლის ან CI/CD სისტემის მიერ Deployment-ის განახლების შემდეგ, დაკავშირებული ReplicaSet რესურსი, რომელიც ამ Deployment-სთან არის დაკავშირებული, განახლდება. Deployment შექმნის ახალ ReplicaSet-ს ახალი კონტეინერის სურათის ვერსიით. ძველი ReplicaSet-ი ეტაპობრივად მცირდება, ხოლო ახალი ReplicaSet-ი იზრდება. ამ პროცესს უწოდებენ rolling update (გადახრილი განახლება) და ის ავტომატურად ხორციელდება.

სხვადასხვა ნაბიჯები:

1. მომხმარებელი ან CI/CD სისტემა განაახლებს Deployment-ს.
2. Deployment ქმნის ახალ ReplicaSet-ს, რომელიც შეიცავს ახალ ვერსიას.
3. ახალი ReplicaSet იწყებს ახალი ვერსიის პოდების შექმნას.
4. როდესაც გარკვეული რაოდენობის ახალი პოდები გადადიან Ready მდგომარეობაში, Deployment იწყებს ძველი ReplicaSet-ის შემცირებას, ამოიღებს ძველი ვერსიის პოდებს.
5. პროცესი გრძელდება, სანამ ყველა პოდი ახალი ReplicaSet-ის მართვაში არ იქნება.
6. ძველი ReplicaSet რჩება, მაგრამ სასურველი რეპლიკების რაოდენობა 0-ია.

ეს პროცესი უზრუნველყოფს ნულოვან დროში გაჩერებას აპლიკაციის განახლებისას (მიუხედავად იმისა, რომ რესურსები საკმარისია და პოდების მზადყოფნა სწორია) და საშუალებას იძლევა ადვილად დაბრუნდეთ წინამორბედ ვერსიაზე, უბრალოდ განაახლეთ Deployment.

Deployment YAML-ის განახლების მაგალითი:

# განახლებული Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25% # მაქსიმალური რაოდენობა პოდების, რომლებიც შეიძლება იყოს დამატებული სასურველზე მეტი
      maxUnavailable: 25% # მაქსიმალური რაოდენობა პოდების, რომლებიც შეიძლება იყოს მიუწვდომელი განახლების დროს
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry/my-app:v1.1.0 # შეცვლილი ვერსია სურათის
        ports:
        - containerPort: 80

მხოლოდ მართვადი ცვლილებები Deployment-ის რესურსის მეშვეობით უნდა განხორციელდეს, ხელით შეცვლილი ReplicaSet-ი ძალიან არ არის რეკომენდებული და შეიძლება გამოიწვიოს გაუთვალისწინებელი ქცევა, რადგან Deployment-ი ცდილობს შეესაბამოს ReplicaSet-ის მდგომარეობა თავის სასურველ მდგომარეობას, თქვენი ცვლილებები გადაწერს. ყველა მართვადი ცვლილება უნდა განხორციელდეს Deployment რესურსის მეშვეობით.