Kubernetes Engine (OKE)とKubernetesの概念

OKEは、Kubernetesを使用してコンテナ化されたアプリケーションをクラウドにデプロイするための、完全に管理されたスケーラブルで可用性の高いサービスです。開発チームがクラウドネイティブアプリケーションを確実に構築、デプロイ、管理したい場合は、OKEを使用します。仮想ノード、管理対象ノードまたは自己管理ノード上でアプリケーションを実行することを選択し、OKEによって既存のOCIテナンシにプロビジョニングされます。

OKEでは、Cloud Native Computing Foundation (CNCF)に準拠するものとして動作保証されているKubernetesのバージョンを使用します。OKEはISO準拠です(ISO-IEC 27001、27017、27018)。

Kubernetesは、ホストのクラスタ間でコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化するためのオープン・ソース・システムです. クラスタ内のホスト(またはノード)は連携して、コンテナ化されたワークロードを実行します。

Kubernetesは、これらのノード上のコンテナを管理およびスケジュールします。コンテナはポッドと呼ばれる論理ユニットに編成され、アプリケーション要件に基づいてデプロイおよびスケーリングされます。Podは、管理、ネットワーキング、サービスの検出を簡素化し、複雑な分散アプリケーションをKubernetesで簡単に構築および運用できるようにします。

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

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

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

OKEを使用して新しいクラスタを作成する場合は、作成するクラスタのタイプを指定します。次のものを指定できます。

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

より詳細な比較は、拡張クラスタと基本クラスタの比較を参照してください。

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

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

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

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

Kubernetesクラスタ・コントロール・プレーンは、Kubernetesのコア機能を実装します。OKEサービス・テナンシのコンピュート・インスタンス(コントロール・プレーン・ノードと呼ばれる)で実行されます。クラスタ・コントロール・プレーンは、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エンドポイント・サブネットへのアクセスを制御します。

Kubernetes APIへのアクセスは、複数のセキュリティ・レイヤーによって管理されます。OCI IAMポリシーを使用して、OKEを使用してクラスタを管理できるユーザーを制御し、クラスタ・コントロール・プレーン自体へのアクセスを取得します。クラスタ内で、Kubernetes RBACを使用して、認証されたユーザーおよびサービス・アカウントがKubernetes APIで実行できる内容を制御します(たとえば、kubectlを使用する場合)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービス全般の詳細は、Kubernetesのドキュメントを参照してください。OKEを使用したロード・バランサ・サービスの作成の詳細は、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のドキュメントを参照してください。

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

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

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

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