ヤフーの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経由でリモート実行するタスクランナー。「チーム内でよく使われていることから採用を決めた」と中村氏。

　アップデートは、各ノードで行っている作業をFabricのタスクとして定義し、対象ノードに順番に適用する。Podの状態は、最初に自作した監視ツールで目視することにした。実行したところ、Kubernetesのアップデートはうまくいっており、順調に思えた。

　だが、とある問い合わせによって、問題が判明。OpenStack上でVMの新規作成ができない状態だったのだ。

　「メッセージキューのサーバとなっていたPodがドレインされて移動したとき、メッセージキューへの再接続にバグがあったことから、クライアントとして接続していた他コンポーネントからメッセージキューに再接続できなくなってしまった。再接続されていなくてもPodは維持されているので、目視で監視していても気付かなかった」（中村氏）

　問題を解決するために中村氏たちはバグを修正した後、Podのドレイン後にVMが新規作成できるかどうかチェックするE2E（End to End）テストを組み込んだ。テスト結果はSlackに通知され、すぐに異常に気付ける仕組みを構築した。

Fabricを用いた半自動化の実現（ヤフーの講演資料から引用）

　現在は、作業実行中は人目による監視が必要なので「まだ半自動化レベル」と中村氏は説明。今後はPodの状態を定常的に監視し、これらPodの状態やVM新規作成テストの結果に基づき必要に応じて自動中断、通知する仕組みを目指して取り組んでいるという。

　「Kubernetesのアップデート作業では、基本的ともいえるさまざまな問題にぶつかり、地道な改善の積み重ねが解決の近道と実感した」と明かす中村氏。「最初から壮大な構想を描いてしまうと、前提に問題があったときに思わぬ転び方をしてしまう。段階的に作業を積み重ね、改善点を整理して埋めていけば、自然と完成していくのだと思う」

Helmのバージョンアップを簡単にできなかった理由

　Kubernetesのアップデートと並行したのは、Helmのアップデートだ。

　同社のIaaS基盤では、Kubernetesリソースをyaml形式のテンプレートにして、HelmのChart（設定ファイル）として管理している。

　管理自体は、デプロイ用コンポーネントの「Tiller」を使用。流れとしては、「Jenkins」から関連するOpenStackクラスタの更新があると、Kubernetesの各ネームスペース（OpenStackクラスタの単位）を作成し、そのネームスペース内に「deploy-manager」（各ネームスペース内のコンポーネントの初期化や前処理の実行、Chartをネームスペース内に展開するために内製したツール）をデプロイ。更新が完了したら、Gitで管理しているOpenStackコンポーネントのバージョンやパラメーターなどをdeploy-manager経由で更新する。

Helmを使ったOpenStackクラスタの管理概要（ヤフーの講演資料から引用）

　Helmのバージョンを2から3にアップデートする上で課題だったのは、変更点の多さだ。バージョン3ではTillerが削除されており、Helmのリソース情報を保持するデータ形式も変更されていた。バイナリを置き換えるだけでは対応できない。

　「データ形式の変更については、公式からコンバートツールが公開されているので、通常はそれを利用すればいい。だが、弊社環境ではdeploy-managerを通じて各リソースを管理するという入れ子構造になっており、無停止でアップデートをかける場合、必要なリソースの依存関係といった内部構造をしっかり理解した上で手順を練る必要があった」。そう説明する2020年に新卒入社のインフラエンジニア、高橋陽太氏は、「管理プロセスで相当な修正が必要になるといった事情から、アップデート作業は後回しになっていた」と話す。

　しかし、Kubernetesのバージョンを上げた結果、Helmもバージョン3に上げなければならないことが判明。すぐに作業に取り掛かることとなる。

APIのバージョン違いでアップデートに失敗

　アップデートの手順は、まず各リソースを管理するdeploy-managerを一時停止させて、その間にバージョン2のリソース情報をバージョン3に移行。Helm v3の対応が完了したdeploy-managerをデプロイして完了させる方法で決定した。

　だが、アップデート作業を実行したところ、問題が発生した。一部のクラスタでdeploy-managerの「helm install」が失敗し、対象クラスタのリソース更新が全て停止したのだ。

　「詳細を調査したところ、既存リソースのAPIとdeploy-managerがインストールしようとしているAPIのバージョンが違ったことで、管理対象と認識されなかったことが原因だった。実は、Kubernetesのアップデートを裏で並行しており、APIのバージョンをアップデートしていたが、一部環境では変更が反映されず、古いバージョンのままAPIが動作していた。Helm v3では既存リソースに対する競合検知の仕組みが変わっており、それに引っ掛かったようだ」（高橋氏）

APIのバージョンの問題でアップデートが失敗する問題が発生（ヤフーの講演資料から引用）

　さらなる調査で深掘りしていくと、どうもエラーの直接的な引き金となったのは、HelmでもChartで使用するバージョンを選択できるように切り替え、ChartのバージョンをHelmのバージョンアップと同時に更新したことにあることが分かった。結果、Helm v3に切り替えた際にKubernetesリソースのAPIバージョンも同時に更新されてしまい、アップデートが失敗したということだった。

　もっとも、アップデート作業中はこうしたエラーの原因は把握できていなかった。しかし、Helm v3の管理用アノテーションをデプロイ済みリソースに挿入すればHelm v3の管理下であることを認識させられるのは分かっていたので、これをエラーが起きた環境で実施することで対処した。

　「結果的に、想定外の作業が大幅に発生してしまった。アップデート作業では対象を明確にし、手順もなるべくシンプルに設計すること。また、大きな変更を含むアップデートの場合は検証にしっかり時間をかけて、心の余裕を持って段階的に、堅実に進めることが重要と実感した」（高橋氏）

　現在も最新バージョンへのアップデートに向けて取り組んでいる両氏。失敗を経験や知見に変えながら、次なる試練に挑んでいる。

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理

ITがビジネスを加速させる昨今、多くの新規サービスが開発、リリースされ、運用管理者には安定したサービスの供給や、利用動向のログの解析などが求められている。だが、これに伴い解析すべきログや拾うべきアラートも増す一方となり、多大な負担が運用管理者の身に振り掛かっている。また、新規サービス開発でのクラウド活用、基幹システムのクラウド移行が進み、可用性や柔軟性といったクラウドならではの特性を生かす、いわゆるクラウドネイティブなアプリケーションの運用が増え、コンテナやマイクロサービスといった複雑な運用管理も求められている。しかも、オンプレミスに残さざるを得ないサーバとのハイブリッドな運用も並行しなければならない。このような中、従来の手法や技術では、とうてい運用管理業務が回らず、ビジネスに貢献することができないのが実情だ。現状を打破するためには、従来の慣習を疑い、新しい技術や自動化、AI（人工知能）などを取り入れ、現状に合った新たな運用管理の手法を実践することが大前提となる――本特集では、運用管理の最新技術や使いこなし方を徹底的に深掘りする。

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理