Kubernetesのつらいところ

はじめに

本記事はKubernetesの嬉しいところではなくてつらいところについて書きます。Kubernetesを少しは触ったことがあって基礎的な用語がわかるくらいの人であれば読めると思います。

Kubernetesのよく言われる売り文句は「Kubernetesを使うと自分でぽちぽちコマンドを叩かなくても、あるべき状態を宣言しておけば後はKubernetesが勝手にその状態になるように保ってくれるのですごく運用が楽」でしょう。これはその通りで自分もKubernetesのおかげで楽をしているなあと感じることがかなりあります。

しかし、何年も実際に使い込んできた経験からいうと、前述の売り文句には「大体の場合は」という但し書きが付きます。では「大体は」じゃないときにどうなるかというと、つらくなります。ここからはどんなときにどんなふうにつらいのかを簡単な例を使って説明します。

冗長度を自動回復してくれる…が、しかし

たとえばdeploymentを使ってwebサーバを3多重で動かしている(つまりreplicas=3)とします。3つのpodのうちの1つが突然死をした場合、Kubernetesは足りなくなった冗長度を回復させるべく、かわりのpodを再起動してくれます。ただし突然死の原因によっては再起動したpodがまた同じ原因で死ぬこともあります。最悪の場合は全てのpodが同じ原因で同時に死ぬということも考えられます。この場合はいくら冗長度を上げても無意味です。Kubernetesはpodの再起動はしてくれますが、再起動したpodが正常動作することは保証してくれないのです^[1]。

このような場合は"kubectl logs"コマンドでログを見たりしながら頑張って原因究明をする必要があります。これはKubernetesを使わない場合と同様です。ここは楽ができません。

コンテナに乗り込んで調査したい…が、しかし

前節において述べたように単なるpod再起動で解決しないような問題はpod(正確にはコンテナ)の中に乗り込んで調査することがあります。このとき調査に必要なツールがコンテナの中に入っていないということがよくあります。「gdbが無い！」「sarが無い！」「lessすら無い！」「コマンドを持ってきたけど依存する共有ライブラリが無い！」なんてのはザラで、最悪の場合は「bashが無いからログインすらできない！」ということもあります。

ただこの状況はKubernetesではある程度改善していて、既存podにデバッグ用のコンテナをアタッチするephemeral containerという機能が最近追加されました。便利なので使える人はぜひ使ってみてください。

ここまで書いておいてなんですが、この問題はKubernetes固有の問題ではなく、コンテナをカリカリに軽量化しているから起きるものなので、Kubernetes以外からコンテナアプリを実行する場合も同じような問題が発生します。

おわりに

本記事では主にKubernetesクラスタを使う側の話をしました。作る側としてのつらいところは過去にオペレータの実装はつらいという記事を書きましたので、ご興味があるかたはこちらも参照してください。また何か思いついたら追記するかもしれません。以上

脚注

1. 短期間に再起動を繰り返す状態がいわゆるCrash Loop Backoff(CLBO)です