前回に引き続き、今回はリージョンクラスタでのUpgradeを試します。
TL;DR
- リージョンクラスタではMasterが複数台あるので、Upgrade中でも操作は可能となる
- リージョンクラスタとゾーンクラスタでは料金にそこまで大きな差はないため、基本的にはリージョンクラスタを使うべき（レイテンシに関しては未考慮）
- （未検証）RWOのPVに関してはゾーン単位なので、ゾーンのNode数が少ないと、PVのついたPodは一時的に起動できなくなるので注意。
リージョンクラスタの作成
今回はGUIから作成します。
「Kubernetes Engine」より「クラスタの作成」を選択
テンプレートのロケーションタイプを「リージョン」に変更
ノードの数やCPUのコア数を変更し、「作成」を選択
GKEのCPU/MemoryはAWSなどと違って、フレキシブルに設定できるのがGood。
これだけでKubernetesクラスタが作成できます。
今までやっていたオンプレでの苦労はなんだったのだろうかというレベル。
クラスタのバージョン確認
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-region-cluster-default-pool-17ac502f-2ss2 Ready <none> 23m v1.11.7-gke.12
gke-region-cluster-default-pool-b4a867f4-q0kb Ready <none> 23m v1.11.7-gke.12
gke-region-cluster-default-pool-e21a0a31-h1rz Ready <none> 23m v1.11.7-gke.12
その後は昨日と同じ手順でPodを作成します。
リージョンクラスタのMasterのUpgrade中の挙動
MasterをUpgradeする
リージョンクラスタなので、ゾーンではなくリージョンで指定します。
$ gcloud container clusters upgrade region-cluster --master --cluster-version 1.12.5-gke.5 --region us-central1
Upgrade中でもMasterへのAPIアクセスは可能
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-region-cluster-default-pool-17ac502f-2ss2 Ready <none> 35m v1.11.7-gke.12
gke-region-cluster-default-pool-b4a867f4-q0kb Ready <none> 35m v1.11.7-gke.12
gke-region-cluster-default-pool-e21a0a31-h1rz Ready <none> 35m v1.11.7-gke.12
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-6f858d4d45-6lw7b 1/1 Running 0 15m
nginx-6f858d4d45-qpqsw 1/1 Running 0 15m
nginx-6f858d4d45-szw57 1/1 Running 0 15m
(venv) ➜ ~
LoadBalancerからのPodのアクセスは可能
画像は省略。
GUIから確認
Upgrade中のメッセージが確認できます。
Upgradeが完了すると、以下のようにノードがアップグレード可能な旨が表示されます。
その他
Masterが1→3となったため、Upgradeには時間が倍以上かかります。
またgcloudでの以下の表示中に「Cmd+C」でキャンセルしても、Upgradeは継続されます。tmuxとかも不要です。
$ Upgrading region-cluster...⠼
Upgrading region-cluster...aborted by ctrl-c.
ERROR: (gcloud.container.clusters.upgrade) Aborted by user.
$ gcloud container clusters upgrade region-cluster --master --cluster-version 1.12.5-gke.5 --region us-central1
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400, message=Operation operation-1554290612124-6b8fe0ac is currently upgrading cluster region-cluster. Please wait and try again once it is done.
クラスタのNodeのUpgrade中の挙動
NodeをUpgradeする
$ gcloud container clusters upgrade region-cluster --cluster-version 1.12.5-gke.5 --region us-central1
前回同様、Nodeが1つずつスケジュール対象から外れ、Upgrade対象のNode上のPodがEvictされ、別Podにスケジュールされます。
またNodeのCPUを2coreにしたため、問題なく別ノードでも動いています。
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-6f858d4d45-6lw7b 1/1 Running 0 24m 10.32.1.5 gke-region-cluster-default-pool-e21a0a31-h1rz <none>
nginx-6f858d4d45-dncsh 0/1 ContainerCreating 0 1s <none> gke-region-cluster-default-pool-e21a0a31-h1rz <none>
nginx-6f858d4d45-qpqsw 1/1 Running 0 24m 10.32.0.11 gke-region-cluster-default-pool-b4a867f4-q0kb <none>
nginx-6f858d4d45-szw57 0/1 Terminating 0 24m 10.32.2.4 gke-region-cluster-default-pool-17ac502f-2ss2 <none>
LoadBalancer経由でのNginXアクセスもOKでした。
Upgrade完了
バージョンが変更されているのがわかります。
$ NAME STATUS ROLES AGE VERSION
gke-region-cluster-default-pool-17ac502f-2ss2 Ready <none> 58m v1.12.5-gke.5
gke-region-cluster-default-pool-b4a867f4-q0kb Ready <none> 58m v1.12.5-gke.5
gke-region-cluster-default-pool-e21a0a31-h1rz Ready <none> 58m v1.12.5-gke.5
同じバージョンの混在が怖い場合は、「新規にpoolを作成し、そこでUpgrade試してから残りのpoolをUpgradeする」というフローが良さそうですね。
お金に関して
リージョンクラスタでも、クラスタ自体の料金はゾーンクラスタと同じです。
ただ、ネットワークトラフィックなどで追加のお金はかかる様子。
https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters?hl=ja#pricing
基本的にはリージョンクラスタが良さそうですね! 😆