Kubernetes Engine (OKE)とKubernetesの概念

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

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

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

Kubernetes Engineを使用して新しいクラスタを作成する際には、作成するクラスタのタイプを指定します。次を指定できます:

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

クラスタを作成する際には次のことに注意してください:

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

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

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

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

Kubernetesクラスタ・コントロール・プレーンは、Kubernetesのコア機能を実装します。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は、コンテナ・ストレージ・インタフェース、flexvolumeドライバおよびflexvolumeプロビジョナも実装します(詳細は、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内のワーカー・ノード・サブネットに接続されます。

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

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

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

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

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

詳細については、Working with Self-Managed Nodesを参照してください。

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

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

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

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

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

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

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

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

Kubernetesは、ネットワーク・リソース管理用のコンテナ・ネットワーク・インタフェース(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のドキュメントを参照してください。

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

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

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

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