Rolling update: wymiana po kawałku
- data
- kategoria
- CI/CD
- także w
- Reliability Engineering
- czytanie
- 1 min / 210 słów
Najpierw deployment oznaczał przerwę.
stop old
start new
Kiedy aplikacje zaczęły działać w kilku instancjach za load balancerem, pojawiła się prostsza możliwość:
zabierz jedną starą instancję
dodaj jedną nową
powtarzaj
To jest rolling update.
Nie przełączamy całego systemu naraz.
Wymieniamy go po kawałku.
Minimalny przykład
W Kubernetes Deployment domyślnie używa RollingUpdate.
Warto jednak zapisać parametry jawnie:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: ghcr.io/example/api:2.0.0
ports:
- containerPort: 3000
readinessProbe:
httpGet:
path: /ready
port: 3000
Przy replicas: 4, maxSurge: 1 i maxUnavailable: 0 Kubernetes może na chwilę uruchomić piątą instancję, ale nie powinien zejść poniżej czterech gotowych Podów.
readinessProbe jest tutaj bramką ruchu.
Nowy Pod nie powinien dostać requestów tylko dlatego, że proces wystartował.
Powinien dostać ruch dopiero wtedy, gdy umie go obsłużyć.
Do czego to realnie służy
Rolling update jest dobry, gdy nowa wersja jest kompatybilna ze starą.
Przez chwilę w systemie żyją razem:
api:1.9.0
api:2.0.0
To musi być bezpieczne dla:
HTTP API
eventów
schematu bazy
cache
background workers
Jeżeli nowa wersja zapisuje dane, których stara nie umie czytać, rolling update robi się ryzykowny.
Nie dlatego, że Kubernetes źle wdraża.
Dlatego, że aplikacja nie toleruje mieszania wersji.
Gdzie nazwa kłamie
Rolling update brzmi jak strategia bezpieczeństwa.
Często jest tylko strategią dostępności.
Chroni przed prostym downtime:
wszystkie instancje zniknęły naraz
Nie chroni przed błędem logicznym, który trafia stopniowo do kolejnych Podów.
Rollback też nie cofa świata.
Można wrócić do poprzedniego obrazu kontenera, ale nie cofniemy automatycznie migracji danych, wysłanych maili albo opublikowanych eventów.
Rolling update jest dobrym domyślnym mechanizmem.
Nie jest zgodą na brak kompatybilności.