はじめに
kubernetes上でアプリなどをPodとして運用していると、
アプリ等のバージョンアップに伴いPodをアップデートする機会があります。
kubernetesでは大きく２つのPodアップデート戦略をとることができます。
kubernetes公式ドキュメントではあまり詳しく扱われていないように見えたので
備忘も兼ねて記事にします。
参考にしたもの
O'Reilly 入門 Kubernetes
https://www.oreilly.co.jp/books/9784873118406/
kuberbnetesのアップデート戦略
kuberbnetesのアップデート戦略には以下２つが存在します。
- Recreate
- RollingUpdate
アップデート戦略は以下の例のようにkubernetesのマニフェストにて、
Deploymentのspec.strategy.typeで定義します。
Recreateの例
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
RollingUpdateの例
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 50%
maxUnavailable: 0%
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
以下では各アップデート戦略におけるPodアップデート方式を説明します。
Recreate
もっともシンプルなアップデート方式です。
現在起動しているPodを全て削除した後に最新のPodを起動します。
注意点としてはPod起動数がゼロになるタイミングが存在するため、
ダウンタイムが発生することです。
以下のRollingUpdateのところで触れますが、Recreate戦略はRollingUpdate戦略で
maxUnavailable=100%,maxSurge=0%とした時の動作と同じになります。
RollingUpdate
Recreateに対してRollingUpdateでは以下2つのパラメータを用いることで、
旧Podを一部起動させたまま少しずつ新Podへのアップデートを行います。
-
maxUnavailable:現在起動しているPod数に対してアップデート時にどの程度までの減少（スケールイン）を許すか
→例えば現在2台のPodが起動しており、maxUnavailable=50%(もしくは1)を設定した場合、アップデートに伴い2台中1台のPodは利用不可となることを許可します。 -
maxSurge:アップデート時に現在起動しているPod数に対してどの程度までの増加（スケールアウト）を許すか
→例えば現在2台のPodが起動しており、maxSurge=50%(もしくは1)を設定した場合、アップデートに伴いPod1台までのスケールアウトは許可します。つまりアップデート中は旧バージョン含め合計3台までであればPodの起動を許可することになります。
以下にmaxUnavailable=0%,maxSurge=50%の場合の例を示します。
また、maxUnavailable=0%,maxSurge=100%とした場合は以下のようにBlue-Green Deploymentが実現できます。
万一新バージョンのPod起動に失敗場合でも旧バージョンでサービス提供を継続することができます。
RollingUpdate戦略ではPodを停止させることなくアップデートを行うことができるため、
ダウンタイムを発生させずにPodのアップデートが可能です。
しかしながら、良くも悪くも新旧Podが同時に起動するタイミングが発生してしまいます。
クライアントとサーバサイドが密結合となっているアプリケーションの場合は注意が必要です。
例えば
・クライアントv1.0-サーバ1.0
・クライアントv2.0-サーバ2.0
という密結合があったとすると、RollingUpdateの方式では
クライアントv2.0-サーバ1.0
となるタイミングが発生してしまいます。※ユーザに既にクライアントv2.0を配布している場合
RollingUpdate戦略を用いる場合はこの点を考慮に入れる必要があります。
備考
アップデート戦略をマニフェスト上で特に指定しなかった場合は、
RollingUpdate戦略のmaxUnavailable=25%,maxSurge=25%が適用されるようです。
宣伝
弱小Twitterやってます。良かったら少し付き合ってください。
https://twitter.com/mochizuki875