今日は誰もが耳にしたことはあっても説明できないKubernetesについてお話しします。この技術がわかりにくいのは実際に直面するまで多くの人が気づかない問題を解決するものだからです。誰もが重要だとは知っていますが何をするものかと尋ねるとみんな一様に言葉に詰まります。これはDockerの代替品でもクラウドOSでもありません。よく相互解されるのですが混乱するのも無理はありません。Kubernetesは直面するまで存在すら知らない問題を解決するツールだからです。管理すべきコンテナが数個を超えた時に初めて不可欠なツールとなります。このエピソードを終える頃にはKubernetesの正体やコンテナとの関係性、そしてゼロから構築したくないチームにとってなぜAzure Kubernetesサービスが実用的であるかが理解できるはずです。コーヒーを片手にさあ見ていきましょう。コンテナ以前の問題。まずはその問題に立ち返ってみましょう。10年前のソフトウェア企業を想像してみてください。いくつかのアプリを動かすためにサーバーを購入しOSをインストールしてすべて手作業でデプロイしていました。アプリごとに専用のマシンが必要でリソースを共有することはできませんでした。あるアプリが大量のメモリを必要とし、別のアプリがほとんど使わなくてもそれぞれに専用のサーバーが必要でした。その無駄は甚大でした。サーバーの稼働率は20%程度でしたが、アプリ間で依存関係の競合が起きるため統合することもできませんでした。部屋中がサーバーで埋め尽くされ、どれもほとんど稼働していないのに電力と冷却コストを消費し、常にメンテナンスが必要な状態でした。あるアプリはPython3、7を必要とし、別のアプリは3.8を必要とします。古いライブラリが必要なものもあれば、最新版が必要なものもありました。同じマシンで動かせば不具合が起きるため、結局サーバーを買い増し、ほとんど遊んでいるハードウェアに金を払い続けることになったのです。仮想マシン、VM、和物理サーバーを分割できるため多少の助けにはなりましたが、各VMはOS全体を抱えるため非常に重く、リスクとメモリを消費し、起動に数分もかかりました。

しかも、それぞれを個別に設定する必要があり、膨大な手間がかかりました。依然として、すべてのOSを管理しパッチを当て、更新し、セキュリティを確保しなければなりませんでした。チームは、もっと軽量でポータブルなものを必要としていました。VMのようなオーバーヘッドなしに、アプリと実行に必要なすべてをパッケージ化でき、マシン間で簡単に移動できる方法です。そこで登場したのがコンテナです。コンテナの正体。コンテナとは、アプリケーションと実行に必要なすべてを詰め込んだ小さなパッケージのことです。つまり、コード、ランタイム、ライブラリ、設定ファイルがすべて一つのユニットとしてまとめられています。ソフトウェアのための輸送用コンテナだと考えてください。輸送用コンテナはトラック、列車、船のどれに乗せてもコンテナ自体は変わりません。ソフトウェアコンテナも同じ仕組みで動作します。一度ビルドすれば、ノートPC、テストサーバー、本番環境のどこでも同じように動作します。コンテナと仮想マシンの主な違いは、効率性の高さです。仮想マシンは独自のフルOSを実行するため、それぞれが専用のカーネルやシステムファイル一式を必要とします。コンテナはホストOSを共有します。それは、独自の分離された環境を持つ単なるプロセスにすぎません。つまり、コンテナは数分ではなく、数秒で起動します。メモリ使用量も少なく、一台のマシンにより多くのコンテナを詰め込めます。Dockerは、開発者がコマンド一つで簡単に構築実行できるようにしたことで、コンテナを普及させました。その瞬間自分の環境では動く、という問題が解消され始めました。ノートPC上のコンテナでアプリが動けば、サーバー上でも同じように動作します。環境がどこでも一貫しているのです。しかし、コンテナはある問題を解決する一方で、新たな問題を生み出しました。数個のコンテナであれば、手動管理でも問題ありません。自分で起動や停止を行い、状況を把握できるからです。では、数百個になったらどうなるでしょうか?どのサーバーでどのコンテナを動かすか決め、失敗したものを再起動し、互いに接続し、アクセス急増時にはスケールアップする必要があります。

それは新たな課題であり、まさにそこでKubernetesの出番となります。オーケストレーションの問題です。さて、コンテナを導入し、アプリをパッケージ化し、どこでも一貫して動くようになり、順調に見えます。しかし、それも束の間のことです。10個や20個のコンテナなら、手動で管理できます。どのサーバーで何を動かしているか把握し、クラッシュすれば再起動し、あちこちを更新することも可能です。管理可能な範囲です。しかし、やがてアプリケーションは成長します。マイクロサービスへと移行するのです。すると、一つの巨大なアプリではなく、20個の小さなアプリに分かれます。信頼性のために各アプリを複数コピーして動かすと、今や200個ものコンテナを扱うことになります。もはや手動管理では限界です。各サーバーにどのコンテナを配置するかを決め、失敗時には再起動し、通信できるように接続しなければなりません。セールや製品発表などでトラフィックが急増すればスケールアップし、落ち着けばスケールダウンする必要もあります。また、ダウンタイムなしで更新をロールアウトするには、古いコンテナを新しいものへ一つずつ慎重に入れ替え、何も壊さないようにしなければなりません。これらがオーケストレーションの問題であり、まさにKubernetesが解決するために作られたものなのです。Kubernetesはコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのプラットフォームです。データセンター向けのオペレーティングシステムだと考えてください。WindowsやLinuxが単一のコンピュータ上でCPUやメモリ、リスクなどのリソースを管理するように、Kubernetesはサーバー群全体のリソースを管理します。すべてのマシンを、一つの巨大なコンピューティングパワーの集合体として扱うのです。実行したい内容を伝えれば、どこで動かし、どのように維持し、どのように他と接続するかをKubernetesが判断します。核となる概念は、Pod、Node、そしてクラスタです。それでは、Kubernetesがどのように動作するのかを見ていきましょう。

Kubernetesにおける最小単位は、Pod、Podと呼ばれます。Podは一つ以上のコンテナをまとめる役割を持ちます。同じPod内のコンテナはストレージとネットワークを共有しているため、ローカルホスト経由で互いに通信できます。Podはデプロイの最小単位だと考えると良いでしょう。Kubernetesでは、コンテナを直接デプロイすることはありません。デプロイするのはPodです。Podは単独では動かず、Nodeの上で動作します。Nodeとは、Kubernetesクラスタの一部である物理または仮想サーバーのことです。各NodeはPodを動かすために必要なソフトウェアを実行しており、他にもいくつかの要素が含まれていますが、それは後ほど説明します。クラスタとは、統合された一つのシステムとして管理されるすべてのNodeの集合体です。簡単に言えば、Podはアプリケーションであり、Nodeはその実行場所、そしてクラスタが環境全体を指します。Podは一時的な存在です。いつでも作成、破棄、移動が可能です。これは設計上の仕様です。Nodeに障害が発生しても、KubernetesはPodを別のNodeへ移動させます。スケールアップが必要な時は、新しいPodを作成します。Podがクラッシュした場合は、自動的に置き換えられます。システム全体がPodを一時的なものとして扱うのです。しかし、Podが頻繁に入れ替わると、通信先を特定する方法が必要になります。そこで、Podと直接通信するのではなくサービスを介して通信します。サービスは安定したネットワークアドレスを提供し、Podが入れ替わっても正しいPodへトラフィックを転送します。ホテルを想像してみてください。ホテルの電話番号がこのサービスに当たります。部屋の宿泊客は常に入れ替わりますが、ホテルの電話番号は変わりません。フロントに電話をかければ、適切な部屋に回線を繋いでくれますよね。Kubernetesのサービスも、まさにこれと同じ働きをします。アプリケーションを実行している現在のPodへ常に誘導する、固定のアドレスを提供してくれるのです。コントロールプレーン、それはクラスターの頭脳です。

ここまで、Pod、ノード、クラスターについて見てきました。では、何をどこで動かすのか、誰が決めているのでしょうか。それはコントロールプレーンの役割です。すべてのKubernetesクラスターには必ず備わっており、システム全体を司る頭脳となっています。すべての決定はここで行われます。コントロールプレーンにはいくつかのコンポーネントがあります。最初の一つはAPIサーバーで、これはクラスターの正面玄関として機能します。コマンドライン、ダッシュボード、自動化スクリプトなど、Kubernetesに送るあらゆるコマンドはAPIサーバーを経由します。APIサーバーはリクエストを認証し、要求された操作の権限があるかを確認してから、適切な場所へ渡します。Kubernetesでは、APIサーバーを通さずに何かが行われることはありません。次はスケジューラーで、各Podをどのノードで実行するかを決定します。このアプリケーションを実行したいと指示すると、スケジューラーは利用可能な全ノードを調査し、CPU、メモリ、リスク容量などのリソース状況を確認して、最適なノードを選びます。それはまるで、宿泊客のニーズに合わせて部屋を割り当てるホテルのマネージャーのようです。荷物が多い客には広い部屋を、軽量なアプリケーションには空き容量のある小さなノードを割り当てます。次にコントローラーマネージャーがあります。このコンポーネントはクラスターを監視し、実際の状態が宣言した通りであることを保証します。例えば、ウェブアプリを3つコピーして実行したいと宣言したとします。コントローラーマネージャーは、実際に3つのコピーが実行されているかを確認します。もし1つがクラッシュすれば、それを検知して代替品を起動します。誰かが誤ってPodを削除しても、新しいPodを作成します。クラスターの整合性を保つためのコンポーネントです。そして最後に、クラスターのデータベースであるETCDがあります。何が実行されているか、どこで実行されているか、どのように構成されているかなど、すべてを記録します。クラスター全体にとっての信頼の拠り所となります。

APIサーバーが正面玄関なら、ETCDはすべての記録が保管されているバックオフィスのキャビネットのようなものです。この設計の素晴らしい点は、やりたいことを宣言するだけで、Kubernetesがそれを実現する方法を考えてくれることです。やり方を支持するのではなく、最終的な結果をどうすべきかを伝えるのです。これが宣言的モデルであり、Kubernetesのあらゆる動作の革新となる考え方です。ワークロード、デプロイメント、サービス、そしてスケーリング。では、実際にKubernetesでアプリケーションを実行する方法についてお話ししましょう。Podを直接作成することはありません。その代わりに、デプロイメントと呼ばれるより高レベルなオブジェクトを使用します。デプロイメントとは、Podのコピーをいくつ実行するか、どのコンテナイメージを使うか、新しいバージョンが出た際にどう更新するかをKubernetesに伝えるマネージャーだと考えてください。これがステートレスアプリケーションを実行する標準的な方法です。デプロイメントを更新して新しいバージョンのアプリをプッシュすると、Kubernetesはローリングアップデートを実行します。Podを一つずつ置き換え、常に少なくとも一つのコピーが実行されている状態を保ちます。つまり、ダウンタイムやユーザーへの突然の中断が発生しません。新しいバージョンで問題が発生しても、単一のコマンドで以前のバージョンにロールバックできます。これは強力な安全策です。しかし、Podにはアクセスできる必要があります。そこで役立つのがサービスです。サービスは安定したネットワークアドレスを提供し、適切なPodへトラフィックをルーティングします。また、それらのPodをアプリケーションの他の部分や外部へ公開することも可能です。サービスは、クラスター内でのみアクセス可能な内部向けか、インターネットからアクセス可能なパブリックIPを持つ外部向けかに分かれます。さて、スケーリングについてお話ししましょう。Kubernetesは需要に応じてアプリケーションを自動的に拡大・縮小できます。目標、例えばCPU使用率70%を設定すると、使用率がそれを超えればPodを追加し、下がればPodを削除します。

トラフィックの急増時にはアプリケーションをスケールアップし、落ち着けばスケールダウンします。手動操作は必要ありません。しかし、この強力な機能には複雑さが伴います。自身のKubernetesクラスターを運用する場合、コントロールプレーン、アップグレード、セキュリティパッチ、バックアップのすべてに責任を持つ必要があります。ノード障害、ネットワーク構成、クラスターのスケーリングに対応するには深い専門知識が必要です。多くのチームはアプリケーションの開発よりもクラスターの管理に時間を費やしています。そこで登場するのが、マネージドKubernetesです。セルフマネージドとマネージドKubernetesの違いについて。それでは、自身でKubernetesを運用する現実について話しましょう。独自のクラスターを構築すると、コントロールプレーン、アップグレード、セキュリティパッチ、ETCDのバックアップなど、すべてに責任を負うことになります。APIサーバーがダウンした場合、それはあなたの責任です。使用しているバージョンにセキュリティの脆弱性が見つかれば、自分でパッチを適用する必要があります。ETCDが破損した場合は、バックアップから復元しなければなりません。これらすべてに深い専門知識が求められます。ノードの障害、クラスターレベルでのネットワークの仕組み、そしてシステムを壊さずにスケールさせる方法を理解しておく必要があります。多くのチームが驚くのは、次の点です。多くの組織が、その上で動くアプリケーションの構築よりも、Kubernetesクラスターの管理に多くの時間を費やしています。絶えずアップグレードと格闘し、ネットワークの問題をトラブルシューティングし、ノード障害に対処しています。クラスターの管理がフルタイムの仕事になってしまうのです。本来、Kubernetesを採用した目的はそこではないはずです。ここでマネージドKubernetesサービスの出番です。Azure Kubernetes Service、AXEのようなサービスは、コントロールプレーンを代行してくれます。AzureがAPIサーバー、ETCD、スケジューラー、コントローラーマネージャーを管理します。

パッチ適用や稼働維持について心配する必要はもうありません。お支払いいただくのは、ワークロードを実際に実行する仮想マシンであるワーカーノードの分だけです。コントロールプレーン自体は無料です。これにより、状況は劇的に変わります。クラスターの保守に時間を費やす代わりに、チームは構築中のアプリケーションという真に重要なことに集中できます。ほとんどのチーム特にこれから始めるチームにとって、マネージドクバネテスが正しい選択です。運用オーバーヘッドなしで、クバネテスのすべての力を活用できます。AXE、Azureで実現するシンプルなクバネテス。では、AXEとは正確には何でしょうか?これはAzureのマネージドクバネテスサービスであり、ゼロから構築することなくフル機能のクラスターを提供します。前述の通りコントロールプレーンは無料ですので、ワークロードを実行する仮想マシンの分のみをお支払いいただきます。つまり、小さく初めて低コストで運用し、ニーズの拡大に合わせてスケールアップできるということです。Azureが面倒な作業のすべてを担います。コントロールプレーンのアップグレードパッチ適用、ヘルス監視はすべて対応済みです。システムを稼働し続けるためだけに、専任のクバネテス専門家チームを抱える必要はありません。また、AXEはAzureエコシステムの一部であるため、おそらくすでにお使いのツールと統合されます。認証のためのAzure Active Directory、ログとメトリックのためのAzure Monitor、ガバナンスのためのAzure Policyなどがあります。これらはすべて最初から連携して動作します。個別の部品を後付けする必要はありません。GitHub ActionsやAzure DevOpsを使ったCI、CD Pipelineの設定はわずか数分で完了します。リポジトリに変更をプッシュすれば、新しいコンテナイメージが自動的にビルドされ、Azureコンテナレジストリにプッシュされ、AXE上のデプロイメントが更新されます。手動の手順も、サーバーへのSSHログインも不要です。すべてが自動化されています。

初心者向けには、AXEオートマチックモードがあり、クラスター構成に関するあらゆる決定を自分でしたくないチーム向けに設計されています。スケーリング、ネットワーキング、セキュリティ、アップグレードのためのすぐに使えるデフォルト設定を提供します。始めるためにKubernetesの専門家になる必要はありません。アプリケーションについて記述するだけで、残りはAXEが処理します。一つのコマンドでクラスターが作成され、一つのマニフェストファイルでアプリケーションが実行されます。AXEで習得したスキルは、どのKubernetes環境にも転用可能です。内部では標準のKubernetesが動いているからです。独自システムを学ぶのではなく、Azureが運用の複雑さを代行する本物の技術を学んでいるのです。これで全体像がつかめたはずです。コンテナはアプリケーションをパッケージ化してどこでも一貫して実行できるようにし、Kubernetesはそのコンテナを大規模にオーケストレーションして、デプロイ、スケーリング、復旧を自動的に処理します。AXEはコントロールプレーンを管理し、使い慣れたAzureツールと統合することで、そのオーケストレーションを扱いやすくします。要点はこれです。Kubernetesは巨大なエンジニアリングチームを抱える大手テック企業だけのものではありません。AXEのようなマネージドサービスがあれば、あらゆるチームが利用できるのです。今週の宿題はシンプルです。無料のAzureアカウントを作成し、AXEクラスターを立ち上げて、簡単なアプリケーションをデプロイしてみてください。わずか数分で、このプラットフォームがいかに進化しているかを実感できるはずです。もっと深く学びたいですか?次回のエピソードでは、最初のコンテナイメージを作成し、Azureコンテナレジストリにプッシュする方法を解説します。お気に入りのPodcastプラットフォームで登録し、Kubernetesを始めたばかりの仲間にぜひシェアしてください。