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

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

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

Container Engine for Kubernetesを使用してクラスタを作成する場合、基本的なクラスタまたは拡張クラスタとして新しいクラスタを作成できます。

Container Engine for Kubernetesで新しいクラスタを作成する場合、作成するクラスタのタイプを指定します。次を指定できます。

• 拡張クラスタ:拡張クラスタは、基本クラスタでサポートされていない機能(仮想ノード、クラスタ・アドオン管理、ワークロード・アイデンティティ、クラスタごとの追加のワーカー・ノードなど)など、使用可能なすべての機能をサポートしています。拡張クラスタには、財務的に裏付けられたサービス・レベル合意(SLA)が付属しています。
• 基本クラスタ:基本クラスタでは、KubernetesおよびContainer Engine for Kubernetesによって提供されるすべてのコア機能がサポートされますが、Container Engine for Kubernetesが提供する拡張機能はいずれもサポートされません。基本クラスタにはサービス・レベル目標値(SLO)が付属していますが、財務的に裏付けられたサービス・レベル契約(SLA)は含まれていません。

クラスタの作成時に次の点に注意してください:

• コンソールを使用してクラスタを作成する場合、クラスタの作成時に拡張機能を選択しない場合は、基本クラスタとして新しいクラスタを作成するオプションがあります。基本クラスタの作成を明示的に選択しないかぎり、新しいクラスタはデフォルトで拡張クラスタとして作成されます。
• CLIまたはAPIを使用してクラスタを作成する場合、基本クラスタまたは拡張クラスタのどちらを作成するかを指定できます。作成するクラスタのタイプを明示的に指定しない場合は、デフォルトで新しいクラスタが基本クラスタとして作成されます。

拡張クラスタとして新しいクラスタを作成すると、拡張機能を最初に選択しなかった場合でも、拡張機能を後で簡単に追加できます。新しいクラスタを基本クラスタとして作成する場合は、後で基本クラスタを拡張クラスタにアップグレードすることもできます。ただし、拡張クラスタを基本クラスタにダウングレードすることはできません。

「拡張クラスタと基本クラスタの比較」を参照してください。

Container Engine for Kubernetesドキュメントのクラスタへのすべての参照は、特に明記されていないかぎり、拡張クラスタと基本クラスタの両方を参照することに注意してください。

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エンドポイント・サブネットへのアクセスを制御します。

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

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

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

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

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

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

ノード・プールの作成時に、ノード・プール内のワーカー・ノードがすべて仮想ノードとして作成されているか、またはすべて管理対象ノードとして作成されているかを指定します。

Container Engine for Kubernetesを使用してノード・プールを作成する場合、ノード・プール内のワーカー・ノードを次のいずれかとして作成することを指定します:

• Oracleによって完全に管理される仮想ノード。仮想ノードはサーバーレスのKubernetesエクスペリエンスを提供し、データ・プレーン・インフラストラクチャのアップグレードやクラスタの容量の管理といった運用上のオーバーヘッドなしで、コンテナ化されたアプリケーションを大規模に実行できます。拡張クラスタにのみ仮想ノードを作成できます。
• 管理対象ノード。テナンシのコンピュート・インスタンス(ベア・メタルまたは仮想マシン)で実行され、少なくとも部分的に管理されます。管理対象ノードの管理を担当しているため、特定の要件を満たすように柔軟に構成できます。管理対象ノードのKubernetesのアップグレードおよびクラスタ容量の管理は、ユーザーの責任となります。管理対象ノードは、基本クラスタと拡張クラスタの両方に作成できます。

管理対象ノードとの仮想ノードの比較を参照してください。

Container Engine for Kubernetesドキュメントのノードおよびワーカー・ノードへのすべての参照は、特に明記されていないかぎり、仮想ノードと管理対象ノードの両方を参照します。

詳細は、自己管理ノードの使用を参照してください。

Container Engine for Kubernetesドキュメントのノードおよびワーカー・ノードへのすべての参照では、特に明記されていないかぎり自己管理ノードが対象となります。

ワーカー・ノード実行されているアプリケーションが複数のコンテナで構成されている場合、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サービスの定義を参照してください。

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のドキュメントを参照してください。