Kubernetesを学び始める人は、最初の週からプラットフォームのすべてのコンポーネントや選択肢を理解しようとする必要はない。これが、Portainer.ioのJoep Piscaerが示す結論である。VMwareアーキテクトとしての過去の経験と、コンテナベースの環境へ移行する開発者やIT担当者が同じ疑問に直面するという観察に基づき、実際にはどこから学び始めればよいのかという問いに答えている。
筆者は、一般的な学習経路が必ずしも適切な出発点を提供するとは限らないと考えている。Kubernetesのドキュメントは広範で、有料コースは同じドキュメントを再提示するだけの場合がある。一方、認定資格の学習経路はすぐに深い内容へ進んだり、基本概念を関連づけた理解を構築せずに長いリソース一覧を提示したりすることがある。そこで、筆者は「足場」と呼ぶメンタルモデル、つまり多くの細部へ進む前にプラットフォームの挙動を説明できる、限られた数の考え方から始めることを提案している。
望ましい状態の仕組みから始める
最初の概念は、望ましい状態とリコンシリエーションである。Kubernetesでは、単にコンテナを起動するコマンドを発行するのではなく、特定の状態が存在すべきだと宣言する。その後、プラットフォームは現実の状態とこの宣言を継続的に比較し、両者の差を修正する。筆者によれば、自己修復、スケーリング、段階的なデプロイといった機能は、望ましい状態やその変更方法が異なるだけで、同じ仕組みに含まれる。
この概念は、教育面でも実務面でも重要である。各機能を別々の機能として暗記するのではなく、学習者はKubernetesの挙動を、1つの仕組みを複数の形で適用したものとして捉えられる。筆者は、この理解がないと、プラットフォームの残りの部分が、暗記しなければならない独立した機能の長い一覧に見えてしまうと強調している。
ノードモデルの違いを理解する
2つ目の柱は、コントロールプレーンとワーカーノードの分離に加え、ノードが「交換可能」であることの意味を理解することである。筆者はこれを、VMwareにおける従来の経験と比較している。そこではチームが、故障したESXiホストを修復したり、そこからワークロードを移動したり、アップグレードしてからサービスに戻したりすることがある。
一方、Kubernetesでは、ノードが故障した際に、システムが必ずしもそのノード自体を救済しなければならないとは考えない。正常なノードであればどのノードでも任意のワークロードを実行できるため、システムは特定のハードウェアを守るのではなく、障害が発生したノードを回避して置き換えるように設計されている。Piscaerは、従来のインフラ管理の習慣をこのモデルへ持ち込むと、必要に応じて手放すことを前提に設計されたコンポーネントを、チームが保護してしまう可能性があると指摘している。
ネットワークにおける問題の層を特定する
筆者は、ネットワークを4つの連続した層として学ぶことを提案している。コンテナからPodへ、Podからサービスへ、サービスからIngressゲートウェイへ、そしてIngressゲートウェイから外部世界へ、という層である。
この見方によれば、ネットワークの診断で混乱が生じる大きな理由は、チームが問題の発生している層を特定していないことにある。PodのIPアドレスは存在するが変化し、サービスのIPアドレスは仮想的で安定している一方、必ずしもそこを直接リッスンするプロセスが存在するわけではない。調査対象の層を把握すれば、追加の診断コマンドを実行する前に、混乱の大部分を取り除ける可能性がある。
requestsとlimitsを運用上の境界として扱う
原典では、リソースのrequestsとlimitsを、単なる目安の値ではなく、ワークロードの存続を左右する契約として説明している。スケジューラーはrequestの値を使って、ワークロードを実行するのに適した場所を決定する。一方、limitは超えてはならない上限を表す。
リソースを過大に申告すると容量の浪費につながる可能性がある一方、過小に申告すると、ノードの空き容量がなくなった際に、重要なタイミングでPodが退避させられる可能性がある。筆者はこの誤りを、テスト環境では動作するのに本番環境では崩壊するワークロードに繰り返し見られる差と結びつけ、問題はアプリケーションのコードではなく、リソースの記述にある可能性を説明している。
CNIとCSIのプラグインが存在する理由
5つ目の柱は、Kubernetesに単一の実装を組み込むのではなく、ネットワークとストレージをCNIやCSIのようなプラグインに委ねている理由を理解することである。原典は、プラットフォームが契約を定義する一方で、実装をプラグインに委ねていると説明している。エッジ環境にある小規模なクラスターの要件は、規制対象となるマルチリージョン環境の要件とは根本的に異なるためである。
これは、ツールや選択肢のエコシステムが広い理由を説明する。ネットワークに複数の選択肢があるのは、必ずしも偶発的な混乱ではなく、すべての環境に単一の設計を強制するのではなく、柔軟性を選んだことの直接的な結果である。ただし、だからといってプラグインの選択が容易になったわけではない。複数の選択肢を正しい文脈に置いて理解できるということである。
学習者にとって実際に何が変わるのか
提案されている方法は、GitOps、監視、サービスメッシュ、ポリシーエンジンといったトピックをなくすものではない。ただし、学習者がそれらに意味を見いだせる問題に直面するまで、後回しにする。基本的な仕組み、コントロールプレーンとノードの構造、ネットワークの経路、リソースの境界を理解した後であれば、これらのトピックへの移行は、「地図」全体を網羅しようとする試みではなく、具体的な実務上の問いに基づくものになる。
これは教育上の見解であり、認定資格を取得するための公式な学習経路や、専門的なドキュメントの代替ではない。また、原典はセットアップ手順や実行コマンドを提示しておらず、初期理解を構築するための枠組みを示しているだけである。記事の最後で筆者は、kubeschool.portainer.ioにある、ベンダー中立であると説明する無料の学習リソースに言及している。このリソースは筆者が所属する組織と関係しているため、ここでは独立して検証されたリファレンスではなく、原典が推奨するリソースとして見るべきである。