はじめに
弊社では GCP（Google Cloud Platform）上の GKE（Google Container Engine）を使用して幾つかのサービスを提供しています。docker を使う理由というのは以前にも何度か（Appendix参照）書いたので、そちらを参照していただければと思います。
付け加えるとすれば、環境の差異を吸収してくれるし、pod が落ちたら勝手に生き返らせてくれるし、デプロイするのにダウンタイムとかエラーとか気にしなくて良いし（これは後述します）、控えめに言って後戻りはしたくないです。
とは言うものの、まだ日の浅い技術なので運用していくと色々と問題が出てきます。
そこで、わりとクリティカルな表題の問題に当たったので、自身への備忘の意味も込めて書いておきます。
想定読者
- docker に関する基礎的な知識を有している人
- kubernetes を触り始めた人
- GCP（GKE）を使用している人
rolling-update とは
Kubernetes を用いると、コンテナをアップデートする際にダウンタイムを無くすことができます。
内部的には、既存のコンテナが稼働しているのを検知すると、新しいコンテナを稼働状態（ただしサービスインはしない）にし、新しいコンテナでエラーがないかどうか確認します。
もしエラーが発生していた場合、新しいコンテナと入れ替える作業を停止します。これにより、エラーが発生しているコンテナをサービス前面に出してしまうのを防ぐことができます。
もしエラーが無ければ、新しいコンテナと古いコンテナとを並行稼動状態にし、その後古いコンテナを削除して通常状態に戻ります。
以上の流れによって、Kubernetes はコンテナのアップデートによってサービスにダウンタイムが生じるのを防いでいます。
※ この issue のコメントを読むと勉強になります
rolling-update の失敗例 on GKE
ここから GKE に特化した話になります。
GKE で docker を使用して rollling-update する場合、イメージをプッシュして
$ kubectl rolling-update ${SERVICE_NAME} --image=asia.gcr.io/${PROJECT_ID}/${CONTAINER_TAG_NAME}:${CONTAINER_TAG_VERSION}
とすればアップデートできます（v1.2.3現在）。
ここで、幾つかのエラーによって、アップデート自体が失敗することがあります。
今まで私が観測した中で、最も多かったのは次のエラーです。
error: timed out waiting for any update progress to be made
求めているのはこの情報ではないと言いたくなるメッセージです。
そこで、ここから調査をするために、以下のコマンドを使用します。
$ kubectl get pods
# => 現在 GKE で稼働している pods を一覧する
$ kubectl describe pod ${POD_NAME}
# => pod の状態を詳細に見る
2つ目のコマンドでアップデートしようとしている pod を見ると、Events という項目がありエラーの詳細が書いてあります。
私が直近ハマったエラーは、以下のようになっていました。
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
6m 4s 27 {default-scheduler } Warning FailedScheduling pod (ポッド名) failed to fit in any node
fit failure on node (ノード名): Node didn't have enough resource: CPU, requested: 100, used: 970, capacity: 1000
つまり、リソース（CPU）足りないからアップデートできないよ！と裏で訴えられていたのですが、気づかずに timeout のエラーをググッていました。
実は、このノードは幾つかのサービスを相乗りさせており、リソースもそれほど確保していなかったために、このようなエラーが発生していました。普段は 20% くらいしか CPU を使っていなかったので、気づくのが遅れました。
そこで、ノードの数を増やし、再度 rolling-update を行うことで、無事にダウンタイム無しでアップデートを行うことができました。
余談
これは余談ですが、ノード台数の上げ下げは、
gcloud compute instance-groups managed set-autoscaling ${INSTANCE_GROUP_NAME} --max-num-replicas=2
とかすると変更できます。詳しくは、 set-autoscaling 参照。
まとめ
GKE上で docker + kubernetes運用をする際に現れるエラーの１つとその解決策、それから調査方法を書きました。