Sobes.tech
Middle+

Агар мо application-ро бо истифода аз deployment паҳн кунем ва сипас нусхаи application-ро дар реплика set тағир диҳем, чӣ мешавад?

sobes.tech AI

Ҷавоб аз AI

Пасля змены версіі прыкладання ў Deployment звязаны рэпліка-сэт (ReplicaSet) абнаўляецца. 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

Прамыя змены ReplicaSet уручную вельмі не рэкамендуецца і могуць прывесці да непрадказальнага паводзінаў, бо Deployment будзе імкнуцца прывесці стан ReplicaSet у адпаведнасць са сваім жаданым станам, перазапісваючы вашы змены. Усе кіраваныя змены прыкладання павінны выконвацца праз рэсурс Deployment.