【ITニュース解説】Day 59: A Broken Deployment and a NIC

この記事では、システム開発や運用において直面するトラブルシューティングの具体的な事例を通して、問題発見から解決までのプロセス、そしてそこから得られる重要な教訓について解説する。特にシステムエンジニアを目指す初心者にとって、実践的な考え方やツール、そしてドキュメントの活用法を学ぶ良い機会となるだろう。取り上げるのは、Kubernetesにおけるアプリケーションのデプロイ失敗と、Azure仮想マシンへのネットワークインターフェース（NIC）追加という二つの異なるタスクだ。

まず、KubernetesでRedisのデプロイメントが起動しないという問題に直面した状況を考える。Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのシステムだ。このタスクでは、redis-deploymentという名前のデプロイメントで起動するはずのPodが、なぜか正常に動作しない状態だった。 問題解決の第一歩として、kubectl get podsコマンドでPodの現在の状態を確認する。次に、kubectl describe pod <pod-name>コマンドを実行し、該当するPodの詳細情報を取得した。このコマンドの出力の一番下にあるEventsセクションには、Podが起動に失敗した原因が示されていた。そこには、「MountVolume.SetUp failed for volume "config" : configmap "redis-cofig" not found」というエラーメッセージがあった。これは、「configという名前のボリュームをマウントしようとしたが、redis-cofigという名前のConfigMap（コンテナに設定情報を提供するKubernetesのオブジェクト）が見つからないため失敗した」という意味である。

このエラーを受けて、kubectl get cmコマンドでクラスター内に存在するConfigMapの一覧を確認したところ、実際にはredis-configという名前のConfigMapが存在していた。つまり、デプロイメントの設定ファイル内でredis-cofigと誤ってタイプミスしていたことが原因だった。 このタイプミスを修正するため、kubectl get deployment redis-deployment -o yaml > redis-deployment.yamlコマンドで現在のデプロイメント設定をYAML形式でファイルにエクスポートした。エクスポートしたファイル内で、ConfigMapの名前をredis-cofigから正しいredis-configへと修正し、kubectl apply -f redis-deployment.yamlコマンドで修正を適用した。

修正後、新しいPodが起動し始めたが、再び停止してしまった。今度の状態はImagePullBackOffだった。これは、「コンテナイメージの取得に失敗した」ことを意味する。再度kubectl describe podで確認すると、containersセクションのimageフィールドで、redis:alpinと指定されている部分があった。正しくはredis:alpineであるべきで、ここでもタイプミスが原因だった。 この二つ目のタイプミスを修正するため、再びYAMLファイルを編集し、redis:alpinをredis:alpineに直した。そして、kubectl delete deployment redis-deploymentで既存のデプロイメントを一度削除し、kubectl apply -f redis-deployment.yamlで修正済みのファイルからデプロイメントを再作成した。 デプロイメントの再作成後、kubectl get podsでPodが正常に起動していることを確認し、kubectl logs <redis-pod-name>でコンテナのログを、kubectl exec <redis-pod-name> -- redis-cli pingでRedisサーバーが応答するかを確認した。結果、「PONG」と返ってきたことで、Redisが正常に動作していることが確認できた。

この経験から学べる重要な教訓がいくつかある。一つは、エラーメッセージだけにとらわれず、設定ファイル全体をじっくりと読み込むことの重要性だ。最初からYAMLファイルを注意深く確認していれば、二つのタイプミスを一度に見つけることができ、より効率的に問題を解決できたはずだ。エラーメッセージは最初に見つかった問題しか報告しないため、それに続く別の問題が隠れてしまうことがある。 また、Kubernetesオブジェクトの更新方法にも注意が必要だ。kubectl applyコマンドは、設定ファイルが変更されたことを検知すると、自動的に新しいPodをロールアウト（展開）してくれるため、kubectl deleteしてからkubectl applyする必要はなかった。deleteコマンドを使用すると、ロールアウトの履歴情報なども失われてしまう可能性があるため、本番環境での利用は避けるべきである。 さらに、kubectl set imageのような特定のフィールドを直接修正するコマンドや、kubectl diffやkubectl apply --dry-run=serverといった変更をプレビューするコマンドも、安全かつ効率的な運用に役立つ。公式ドキュメントでは、kubectl describe podsからデバッグを始めること、ConfigMapは参照前に作成すること、PodのSTATUSとPhaseの違いを理解すること、そしてオブジェクト管理には一貫した手法を用いることなどが推奨されている。

次に、Azureでの仮想マシン（VM）にネットワークインターフェース（NIC）を追加するタスクについて見ていこう。NICは、VMがネットワークと通信するための部品である。 このタスクでは、既存のxfusion-nicというNICを、既存のxfusion-vmというVMにアタッチ（接続）する必要があった。Azureでは、稼働中のVMにNICを直接アタッチすることはできないという制約がある。VMを一度「割り当て解除（deallocate）」する必要があるのだ。これは、AWS（Amazon Web Services）のように稼働中にNICをアタッチできるクラウドサービスとは異なる点であり、クラウドプロバイダーごとの違いを理解することの重要性を示している。 VMを割り当て解除すると、VMのダウンタイムが発生するため、実際に操作を行う前に、VMとNICが適切に構成されているかを確認しておくことが重要だ。具体的には、az network nic showコマンドを使って、NICがVMと同じ仮想ネットワーク（VNET）内にあるか、まだ別のVMにアタッチされていないか、そして両者が同じAzureリージョン（地理的な場所）にあるかを確認した。これらはNICのアタッチが成功するための必須条件である。

事前チェックが完了したら、いよいよ操作に移る。まず、az vm deallocate -g $RG -n xfusion-vmコマンドでVMを割り当て解除する。ここで重要なのは、az vm stopコマンドではなくdeallocateを使用することだ。stopコマンドはVMを停止するものの、リソースはホストに確保されたままで課金が続く。一方、deallocateはVMが基盤となるハードウェアのリソースを解放するため、NICの変更が可能になり、VMに対する課金も一部停止される。 VMの割り当て解除後、az vm nic add -g $RG --vm-name xfusion-vm --nics xfusion-nicコマンドでNICをVMにアタッチし、最後にaz vm start -g $RG -n xfusion-vmコマンドでVMを再起動した。 操作後、az network nic showやaz vm get-instance-viewコマンドを使って、NICがVMに正しくアタッチされ、VMとそのエージェントが正常に稼働していることを確認した。この時、VMに元々あったNICは「Primary: true」となり、新しく追加されたNICは「Primary: false」となる。これは、最初のNICがプライマリとして設定され、追加されたNICはセカンダリとして扱われることを意味する。

このタスクで特に注意すべき点として、VMサイズごとのNICの最大数を確認する際の失敗談がある。VMサイズによってはアタッチできるNICの数が制限されているため、事前にaz vm list-skusコマンドを使って確認しようとした。しかし、このコマンドは非常に重く、実行するたびにラボセッションが強制終了してしまった。AzureはNICの最大数制限を自動的に適用するため、この事前チェックは不要だった。このような情報は、Azureの公式ドキュメントやVMサイズ一覧表で確認する方が適切で、時間やリソースを無駄にしない賢い方法だと言える。

このAzureタスクから得られる教訓は、安価に確認できることは事前にすべて確認し、高価な（時間やリソースを消費する）情報は、実際に操作してシステムに検証させるというバランス感覚だ。また、NICの変更はVMのダウンタイムを伴うため、計画的に実施すること、割り当て解除が動的IPアドレスの解放などの副作用を持つことを理解しておくことが重要だ。さらに、NICをアタッチしただけではゲストOS（VM内部のオペレーティングシステム）で自動的にルーティング設定が行われない場合があり、手動での設定が必要となるケースがあることも覚えておくべきだろう。

これらの二つのタスクを通して、トラブルシューティングやクラウドサービスの運用において共通して重要なのは、問題の現象を正確に把握し、原因を特定するために適切なツールや情報を活用すること、そして、操作の前後で状態を確認し、意図しない結果にならないよう慎重に進めることである。また、公式ドキュメントを読み込み、それぞれのサービスの特性や制約を深く理解することは、効率的かつ安全なシステム運用に不可欠だ。エラーを見つけたらすぐに修正するのではなく、関連する情報を全体的に確認する習慣を身につけることが、隠れた問題を見つけ出し、再発を防ぐための鍵となるだろう。