コンテナ・エンジンおよびKubernetesの概念

このトピックでは、Container Engine for Kubernetesを使用する際に理解しておく必要がある主な概念について説明します。

Kubernetesクラスタ

Kubernetesクラスタは、ノード(アプリケーションを実行しているマシン)のグループです。各ノードは、物理マシンでも仮想マシンでもかまいません。ノードの容量(CPU数およびメモリー量)は、ノードの作成時に定義されます。クラスタは次で構成されます:

  • コントロール・プレーン・ノード(以前はマスター・ノードと呼ばれていました)。通常、高可用性のために3つのコントロール・プレーン・ノードがあります。
  • ノード・プールに編成されたワーカー・ノード。

Kubernetesクラスタ・コントロール・プレーンおよびKubernetes API

Kubernetesクラスタ・コントロール・プレーンは、Kubernetesのコア機能を実装します。Container Engine for Kubernetesサービス・テナンシのコンピュート・インスタンス(コントロール・プレーン・ノードと呼ばれる)で実行されます。クラスタ・コントロール・プレーンは、Oracleによって完全に管理されます。

クラスタ・コントロール・プレーンは、次のような多数のプロセスを実行します:

  • kube-apiserver。Kubernetesコマンドライン・ツール(kubectl)やその他のコマンドライン・ツール、および直接RESTコールからリクエストされたKubernetes API操作をサポートします。kube-apiserverには、高度なKubernetes操作に必要なアドミッション・コントローラが含まれています。
  • kube-controller-manager。様々なKubernetesコンポーネント(たとえば、レプリケーション・コントローラ、エンドポイント・コントローラ、ネームスペース・コントローラ、サービス・アカウント・コントローラ)を管理します
  • kube-scheduler。クラスタ内のジョブを実行する場所を制御します
  • etcd。クラスタの構成データを保存します
  • (ノード・コントローラを使用して)ワーカー・ノードを更新および削除するcloud-controller-manager。type: LoadBalancerのKubernetesサービスが作成されたときに(サービス・コントローラを使用して)、および(ルート・コントローラを使用して)ネットワーク・ルートを設定するロード・バランサを作成します。oci-cloud-controller-managerは、コンテナ-storage-interface、フレックスボリューム・ドライバおよびフレックスボリューム・プロビジョニングも実装します(詳細は、GitHubのOCI Cloud Controller Manager (CCM)ドキュメントを参照してください)。

Kubernetes APIを使用すると、エンド・ユーザーはKubernetesリソース(ポッド、ネームスペース、構成マップ、イベントなど)を問い合せて操作できます。

クラスタ・コントロール・プレーン上のKubernetes APIには、VCNのサブネットでホストされているエンドポイントを介してアクセスします。このKubernetes APIエンドポイント・サブネットは、プライベート・サブネットまたはパブリック・サブネットにできます。Kubernetes APIエンドポイントのパブリック・サブネットを指定する場合、(プライベートIPアドレスに加えて)オプションでパブリックIPアドレスをKubernetes APIエンドポイントに割り当てることができます。セキュリティ・リストまたはネットワーク・セキュリティ・グループに定義されたセキュリティ・ルールを使用して、Kubernetes APIエンドポイント・サブネットへのアクセスを制御します。

ノート

以前のリリースでは、クラスタはVCNに統合されていないパブリックKubernetes APIエンドポイントでプロビジョニングされていました。

CLIまたはAPIを使用してこのようなクラスタの作成を続行できますが、コンソールは使用できません。

Kubernetesワーカー・ノードおよびノード・プール

ワーカー・ノードはクラスタ・データ・プレーンを構成します。ワーカー・ノードは、クラスタにデプロイしたアプリケーションを実行する場所です。

各ワーカー・ノードでは、次のような多数のプロセスが実行されます:

  • クラスタ・コントロール・プレーンと通信するためのkubelet
  • ネットワーク・ルールを維持するためのkube-proxy

クラスタ・コントロール・プレーン・プロセスは、ワーカー・ノードの状態をモニターおよび記録し、それらのノード間でリクエストされた操作を分散します。

ノード・プールは、すべて同じ構成を持つクラスタ内のワーカー・ノードのサブセットです。ノード・プールを使用すると、クラスタ内に異なる構成を持つマシンのプールを作成できます。たとえば、クラスタ内のノードの1つのプールを仮想マシンとして作成し、ノードの別のプールをベア・メタル・マシンとして作成できます。クラスタには最低1つのノード・プールが必要ですが、ノード・プールにはワーカー・ノードが含まれている必要はありません。

ノード・プール内のワーカー・ノードは、VCN内のワーカー・ノード・サブネットに接続されます。

ポッド

ワーカー・ノード実行されているアプリケーションが複数のコンテナで構成されている場合、Kubernetesは、コンテナをポッドと呼ばれる単一の論理ユニットにグループ化し、管理と検出を容易にします。ポッド内のコンテナは、同じネットワーキング・ネームスペースと同じストレージ領域を共有し、クラスタ・コントロール・プレーンによって単一のオブジェクトとして管理できます。同じ機能を提供する多くのポッドを、サービスと呼ばれる単一の論理セットにグループ化できます。

Kubernetesクラスタは、Container Network Interface (CNI)プラグインを使用して、ワーカー・ノードで実行されているポッドのネットワーク接続を実装します。CNIプラグインは、ネットワークインタフェースの構成、IPアドレスのプロビジョニング、および接続の保守を行います。

ポッドの詳細は、Kubernetesのドキュメントを参照してください。

サービス

Kubernetesでは、サービスはポッドの論理セットおよびポッドにアクセスするためのポリシーを定義する抽象概念です。サービスのターゲットとなるポッドのセットは、通常、セレクタによって決定されます。

アプリケーションの一部(フロントエンドなど)では、クラスタ外部の外部IPアドレスにサービスを公開できます。

Kubernetes ServiceTypesを使用すると、公開するサービスの種類を指定できます。LoadBalancer ServiceTypeは、VCNのロード・バランサ・サブネット上にOracle Cloud Infrastructureロード・バランサを作成します。

サービス全般の詳細は、Kubernetesのドキュメントを参照してください。Container Engine for Kubernetesを使用したロード・バランサ・サービスの作成の詳細は、LoadBalancerタイプのKubernetesサービスの定義を参照してください。

コンテナ・ネットワーク・インタフェース(CNI)プラグイン

Kubernetesは、ネットワーク・リソース管理にContainer Network Interface (CNI)仕様を採用しました。CNIは、Linuxコンテナでネットワーク・インタフェースを構成するためのプラグインを記述するための仕様およびライブラリと、サポートされる多数のプラグインで構成されます。

Kubernetesクラスタは、Container Network Interface (CNI)プラグインを使用して、ワーカー・ノードで実行されているポッドのネットワーク接続を実装します。CNIプラグインは、ネットワークインタフェースの構成、IPアドレスのプロビジョニング、および接続の保守を行います。

詳細は、GitHubのCNIドキュメンテーションを参照してください。

マニフェスト・ファイル(またはポッド仕様)

Kubernetesマニフェスト・ファイルは、アプリケーションをKubernetesクラスタ内のノードにデプロイする方法を指定するyamlまたはjsonファイルの命令で構成されています。この命令には、Kubernetesデプロイメント、Kubernetesサービス、およびクラスタに作成されるその他のKubernetesオブジェクトに関する情報が含まれます。マニフェストは通常、ポッド仕様、またはdeployment.yamlファイルとも呼ばれます(他のファイル名も使用できます)。Kubernetesマニフェスト・ファイルに含めるパラメータについては、Kubernetesのドキュメントで説明しています。

アドミッション・コントローラ

Kubernetesアドミッション・コントローラは、クラスタにオブジェクト(ポッドなど)を許可する前に、Kubernetes API Serverへの認証済および認可済リクエストをインターセプトします。アドミッション・コントローラは、オブジェクトを検証または変更(あるいはその両方)できます。Kubernetesの多くの高度な機能では、有効なアドミッション・コントローラが必要です。詳細は、Kubernetesのドキュメントを参照してください。

Container Engine for Kubernetesを使用してクラスタを作成するときに選択するKubernetesバージョンによって、そのクラスタでサポートされるアドミッション・コントローラが決まります。サポートされているアドミッション・コントローラ、Kubernetes APIサーバーでの実行順序、およびサポートされているKubernetesバージョンについては、サポートされているアドミッション・コントローラを参照してください。

ネームスペース

Kubernetesクラスタは、ネームスペースに編成して、クラスタのリソースを複数のユーザーに分割できます。最初、クラスタには次のネームスペースがあります:

  • デフォルト(他のネームスペースがないリソースの場合)
  • kube-system (Kubernetesシステムによって作成されたリソース)
  • kube-node-lease (ノード可用性の決定に役立てるための、ノードごとに1つのリース・オブジェクトの場合)
  • kube-public (通常、クラスタ全体でアクセスできる必要があるリソースに使用される)

ネームスペースの詳細は、Kubernetesのドキュメントを参照してください。