概要
Kubernetes の基礎知識をお持ちの方なら、Kubernetes が分散されたアプリケーションおよびサービスを大規模に実行するために設計されたオープンソースのコンテナ・オーケストレーション・プラットフォームであることはご存じでしょう。しかし、そのコンポーネントやそれらの相互作用についてはどうでしょうか。
ここでは、Kubernetes の基礎となる設計原則を簡単に説明してから、Kubernetes のさまざまなコンポーネントがどのように連携するかを見ていきます。
Kubernetes コントロールプレーンでの処理
コントロールプレーン
まず、Kubernetes クラスタの中枢であるコントロールプレーンから説明します。ここには、クラスタを制御する Kubernetes コンポーネントと、クラスタの状態と構成に関するデータがあります。これらは、Kubernetes のコアコンポーネントが、十分な数のコンテナが必要なリソースで実行されていることを確認するという重要な作業を担います。
コントロールプレーンは、常にコンピュートマシンとコンタクトしています。特定の方法で実行されるようにクラスタを構成すると、コントロールプレーンがそれを確実に実行します。
kube-apiserver
Kubernetes クラスタを操作する必要がある場合は、API にアクセスします。Kubernetes API は、Kubernetes コントロールプレーンのフロントエンドであり、内部からの要求と外部からの要求を処理します。API サーバーは要求が有効かどうかを判断し、有効な場合は処理します。API へは、REST 呼び出し、kubectl コマンドライン・インタフェース、または kubeadm などの他のコマンドラインツールを使用してアクセスできます。
kube-scheduler
クラスタの健全性は保たれているか。新しいコンテナが必要な場合、どこにデプロイするのか。Kubernetes スケジューラーが見るのはこれらの点です。
スケジューラーは、クラスタの健全性とともに、Pod のリソースニーズ (CPU やメモリーなど) を考慮します。そして、Pod を適切なコンピュートノードにスケジュールします。
kube-controller-manager
コントローラーは実際のクラスタの実行を処理します。Kubernetes コントローラー・マネージャー 1 つで、いくつかのコントローラー機能を実行します。あるコントローラーはスケジューラーに問い合わせて、正しい数の Pod が稼働していることを確認します。Pod がダウンした場合、別のコントローラーが検知して応答します。あるコントローラーは、要求が適切なエンドポイントに送信されるようサービスを Pod に接続します。また、アカウントや API アクセストークンを作成するためのコントローラーもあります。
etcd
構成データとクラスタの状態に関する情報は、key-value ストアデータベースである etcd 内にあります。etcd は、フォールトトレラントで分散されており、クラスタに関する信頼できる基本的な情報源となるように設計されています。
Kubernetes ノードでの処理
ノード
Kubernetes クラスタは少なくとも 1 つのコンピュートノードを必要としますが、通常は多数を有しています。Pod は、ノードで実行されるようにスケジュールされ、オーケストレーションされます。クラスタの容量をスケールアップする必要がある場合は、ノードを追加します。
Pod
Pod は、Kubernetes オブジェクトモデルで最小かつ最も単純なユニットです。アプリケーションの単一のインスタンスを表します。各 Pod は、1 つのコンテナまたは密結合された複数のコンテナと、コンテナの実行方法を制御するオプションで構成されます。ステートフル・アプリケーションを実行するために、Pod を永続ストレージに接続することもできます。
コンテナ・ランタイム・エンジン
コンテナを実行するために、各コンピュートノードにコンテナ・ランタイム・エンジンがあります。Docker は 1 つの例ですが、Kubernetes は rkt や CRI-O などの他の Open Container Initiative 準拠のランタイムもサポートしています。
kubelet
各コンピュートノードには、コントロールプレーンと通信する小さなアプリケーションである kubelet が含まれています。kubelet は、コンテナが Pod で実行されていることを確認します。コントロールプレーンが、ノードでの何らかの処理を必要とする場合、kubelet がアクションを実行します。
kube-proxy
各コンピュートノードには、Kubernetes ネットワークサービスを容易にするためのネットワークプロキシである kube-proxy も含まれています。kube-proxy は、オペレーティングシステムのパケットフィルタリング・レイヤーまたはトラフィック自体の転送に依存して、クラスタ内外のネットワーク通信を処理します。
その他 Kubernetes クラスタに必要なもの
永続ストレージ
Kubernetes は、アプリケーションを実行するコンテナを管理するだけでなく、クラスタに付帯するアプリケーションデータも管理できます。Kubernetes を使用すると、基盤となるストレージ・インフラストラクチャの詳細を知らなくても、ストレージリソースをリクエストできます。永続ボリュームは、Pod ではなくクラスタに固有のものなので、Pod が終了しても存続できます。
コンテナレジストリ
Kubernetes が依存するコンテナイメージは、コンテナレジストリに格納されます。これは、構成したレジストリまたはサードパーティのレジストリにすることができます。
基盤となるインフラストラクチャ
Kubernetes の実行場所はユーザーが選択できます。ベアメタルサーバー、仮想マシン、パブリッククラウド・プロバイダー、プライベートクラウド、ハイブリッドクラウド環境を使用できます。Kubernetes の主な利点の 1 つは、さまざまな種類のインフラストラクチャで動作することです。
簡単なものではない
ここまで Kubernetes アーキテクチャの概要を簡単に説明してきましたが、これは表面を軽くなぞったに過ぎません。これらのコンポーネントが相互に、そして外部のリソースやインフラストラクチャとどのように通信するかを考えると、Kubernetes クラスタの構成とセキュリティの確保がどれだけ大きな課題となりうるかをお分かりいただけるでしょう。
Kubernetes は、大規模で複雑なコンテナ化されたアプリケーションを調整するためのツールを提供しますが、多くの決断はユーザーに委ねられています。ユーザーは、オペレーティングシステム、コンテナランタイム、継続的インテグレーション/継続的デリバリー (CI/CD) ツール、アプリケーションサービス、ストレージ、およびその他のほとんどのコンポーネントを選択します。また、ロール、アクセス制御、マルチテナンシー、安全なデフォルト設定の管理作業もあります。さらに、Kubernetes を自分で実行するか、サポートされているバージョンを提供できるベンダーと連携して実行するかを選択できます。
この選択の自由は、Kubernetes の柔軟な特質の一環です。実装は複雑になるかもしれませんが、Kubernetes を使用すると、コンテナ化されたアプリケーションを独自の条件で実行し、組織の変化にアジャイルに対応できます。
Kubernetes でクラウドネイティブ・アプリケーションを構築する
この Web セミナーシリーズでは、アプリケーションの構築、実行、デプロイ、モダナイズに必要な、エンタープライズ向け Kubernetes にデータプラットフォームを確立するために役立つ専門家の視点を学ぶことができます。
Red Hat OpenShift の Kubernetes を選ぶ理由
Red Hat は、Kubernetes を含むオープンソース・コンテナ・テクノロジーのリーダー企業であるとともに積極的に開発も行っており、コンテナ・インフラストラクチャの保護、単純化、自動更新に不可欠なツールを生み出しています。
Red Hat® OpenShift® はエンタープライズ・グレードの Kubernetes ディストリビューションです。Red Hat OpenShift を使用すると、DevOps 用の単一の統合プラットフォームをチームで利用できます。Red Hat OpenShift は、開発者に言語、フレームワーク、ミドルウェア、データベースの選択肢を提供するとともに、CI/CD を介したビルドおよびデプロイの自動化により生産性を大幅に向上させます。コンテナ向けに設計されたデータおよびストレージサービス・プラットフォームである Red Hat OpenShift Data Foundation も利用できます。
