ヤフーのIaaSを支えるKubernetes/Helm――新卒1、2年目エンジニアは2017年から塩漬けの400ノードをどうアップデートするか：特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理（4）

Kubernetesのクラスタ数は10以上あり、その配下にある400以上のノードが支えるヤフーのIaaS基盤。その規模故にコンポーネントの管理に使うKubernetesとHelmのバージョンアップは2017年から行っていなかった。そして今、止まった時を動かすべく、新卒1、2年目のエンジニアが大規模環境のアップデートに挑む――運用管理者に光を当てるオンラインイベント「Cloud Operator Days Tokyo 2021」の同社による講演から、大規模Kubernetes環境運用のヒントを学ぼう。

[谷崎朋子，＠IT]

2017年から時を止めたKubernetesとHelm

　Yahoo! JAPANのニュースやオークション、ファイナンスなど、多彩なユーザー向けサービスの他、PaaSやCaaS（Container as a Service）といった社内クラウドのバックエンドサービスを支える、ヤフーのIaaS基盤。その管理には「OpenStack」が使用されており、クラスタ数は200以上、ハイパーバイザー数は2万1000以上、VM（仮想マシン）数は17万以上稼働している。

　クラスタ数が200を超えるとなると、管理するコンポーネント数も膨大だ。そこで、同社はNova APIやKeystoneといったOpenStackのコントロールプレーンに当たるコンポーネントを「Helm」のChart（設定ファイル）にして、「Kubernetes」にデプロイすることでOpenStackクラスタの構築や運用のコストを削減している。IaaSを支えるKubernetesクラスタ数は現在10以上あり、その配下には400以上のノードが動いている。

　そんなヤフーのIaaSの“縁の下の力持ち”として活躍するKubernetesとHelmだが、数年前まではアップデートされることなく運用されてきた。理由は、オンプレミス環境かつクラスタ数が膨大なのでアップデート作業が相当な手間であること、「kubeadm」などのOSS（オープンソースソフトウェア）のデプロイツールを使っていなかったこと、導入期で安定稼働が求められていたことなどが挙げられる。結果、2017年からKubernetesはバージョン1.8のまま、Helmはバージョン2のまま運用されてきた。

　しかし、運用チーム内でKubernetesの利用が拡大し、より新しいバージョンに追従するモチベーションが高まった。こうして、KubernetesとHelmのアップデートプロジェクトが始動した――「Cloud Operator Days Tokyo 2021」の講演「Yahoo! JAPANのIaaSを支えるKubernetesクラスタのアップデート苦労話」から大規模Kubernetes環境のアップデートのヒントを学ぼう。

Kubernetesアップデート計画〜Pod監視ツールと自作タスクランナー

　Kubernetesのアップデートに携わることになったのは、2019年に新卒入社したIaaSエンジニア／ソフトウェアエンジニアの中村泰大氏^※だ。

※所属・肩書はイベント当時のものです。

　バージョンのアップデートは、マスターノードで稼働する「kube-apiserver」や、ワーカーノードにある「kubelet」などの各種パッケージに対して実施する。この他、バージョンに合わせて設定を更新する必要があり、これは構成管理ツールの「Chef」を使って行う。

アップデートの構成や実施方法（ヤフーの講演資料から引用）

　アップデート前には、各種パッケージをノードから参照できる場所に準備し、Chefに記述した構成情報を新しいバージョンに合わせて書き換えた。そして、マスターノードから順に対象ノードをドレインしてクラスタから切り離し、Chefで新しいバージョンの構成を適用。「kubectl uncordon」でノードを復帰させる作業を繰り返す。アップデートは、v1.8からv1.10、v1.12、と順番に実施することにした。

　課題は、アップデートの方法だ。当初は手動で適用していたが、作業量の多さから自動化できないかどうかを模索。完全自動化を目標に、一歩ずつステップアップすることにした。

　まず手始めに取り組んだのは、Podの状態を監視するための可視化ツールの作成だ。

　「構成を更新するだけでは、作業中にPodが異常な状態に陥っているかどうか、Kubernetesクラスタが不健全な状態にあるかどうかを認識できず、そのまま更新してしまうリスクがある。そこで、クラスタ内のPodを自動収集し、定期的にpingを送信して状態を可視化するCLIツールを作成した。これにより、Podのクラッシュループや通信到達性をすぐに認識できるようになった」（中村氏）

　幸先良いスタートを切った中村氏たちは、続いて「タスクの自動化で何を実現したいのか」についてチームで洗い出した。議論の末、KubernetesのJobを活用したタスクランナーを自作することにした。

　ただ、残念なことに同ツールはお蔵入りになった。

　同ツールは、実行したいJobやPythonの関数、デプロイの順番などを記述し、それを基にAPIでJobを実行する。JobでChefを実行するには、ノードのrootディレクトリをPodにマウントし、「change root」コマンドを実行してからChefを実行する流れだ。一見うまくいきそうに思えたが、試したところ、Chefで行っていた一部プロセスのリスタートがJob経由で行えず、プロセスが終了したままになってしまった。

　「コンテナの利用方法の王道から外れるような使い方をしたのが敗因。プロセスの重要性が低ければ問題なかったが、ノードを監視するプロセスだったので見過ごすことができなかった。解決する見込みも立てられないことから利用を断念した」（中村氏）

Fabricを用いたアップデート自動化で試行錯誤

　続いて中村氏が取り組んだのは、「Fabric」を用いたアップデート自動化だ。FabricはコマンドをSSH経由でリモート実行するタスクランナー。「チーム内でよく使われていることから採用を決めた」と中村氏。