クラウドでのKubernetesトポロジの設計について
Oracle Cloud Infrastructure Container Engine for Kubernetesは、コンテナ化されたアプリケーションをクラウドのKubernetesクラスタにデプロイする際に使用できる、管理対象、スケーラブルで高可用性のサービスです。
アーキテクチャ
クラウド内のKubernetesベースのトポロジのアーキテクチャは、コンテナ化されたワークロードをパブリック・インターネットからアクセスできるようにするかどうか、ノード・プールのサイズと数、およびワークロードのフォルト・トレランス要件などの要因に依存します。
次の図は、複数の可用性ドメインを含むOracle Cloud Infrastructureリージョン内のKubernetesクラスタの参照アーキテクチャを示しています。
- 仮想クラウド・ネットワーク(VCN):トポロジ内のすべてのリソースは単一のVCN内にあります。
- サブネット:
このアーキテクチャのVCNには、2つのパブリックと2つのプライベートの4つのサブネットが含まれています。パブリック・サブネットの1つはベース・ホスト用、もう1つはインターネットに対応するロード・バランサ用です。2つのプライベート・サブネットのうちの1つは、Kubernetesクラスタを管理するために必要なツールを含む管理ホスト用です。もう1つのプライベート・サブネットは、Kubernetesクラスタのノード用です。
すべてのサブネットはリージョンです。つまり、アーキテクチャ・ダイアグラムのAD1、AD2およびAD3のように省略された、リージョン内のすべての可用性ドメインにまたがります。このため、ドメインの障害から保護されます。リージョン内の可用性ドメインへデプロイするリソースには、サブネットを使用できます。
- ネットワーク・ゲートウェイ
- サービス・ゲートウェイ(オプション)
サービス・ゲートウェイを使用すると、VCNのリソースから、Oracle Cloud Infrastructure Object Storage、Oracle Cloud Infrastructure File Storage、Oracle Cloud Infrastructure DatabaseなどのOracleサービスにアクセスできるようになります。つまり、パブリック・インターネットへのトラフィックは公開されません。サービス・ゲートウェイを介した接続は、VCN内のリソースから開始できますが、リソースが通信するサービスからは開始できません。
- NATゲートウェイ(オプション)
NATゲートウェイを使用すると、VCNのプライベート・サブネットにアタッチされたコンピュート・インスタンスは、パブリック・インターネットにアクセスできます。NATゲートウェイを介した接続は、VCN内のリソースから開始できますが、パブリック・インターネットからは開始できません。
- インターネット・ゲートウェイ
インターネット・ゲートウェイを使用すると、パブリック・インターネットとVCN内のパブリック・サブネットのすべてのリソース間の接続が可能になります。
- サービス・ゲートウェイ(オプション)
- 基礎ホスト(オプション)
Bastionホストは、クラウドの外部からのトポロジへのエントリ・ポイントとして機能するコンピュート・インスタンスです。
基本ホストは通常DMZにプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークにそれらのリソースを配置することで、機密のリソースを保護できます。定期的に監査できる、単一の既知のエントリ・ポイントを公開できます。したがって、トポロジの機密性の高いコンポーネントの公開は、それらへのアクセスを危険にさらすことなく回避できます。
サンプル・トポロジ内のベース・ホストはパブリック・サブネットに接続され、パブリックIPアドレスを持ちます。イングレス・セキュリティ・ルールは、パブリック・インターネットからベース・ホストへのSSH接続を許可するように構成されています。追加のセキュリティ・レベルを提供するために、特定のIPアドレス・ブロックからベース・ホストへのSSHアクセスのみを制限できます。
プライベート・サブネットのOracle Cloud Infrastructureインスタンスには、ベース・ホストを介してアクセスできます。これを行うには、
ssh-agent転送を有効にします。この転送では、ベース・ホストに接続し、コンピュータから資格証明を転送して次のサーバーにアクセスできます。また、SSHトンネリングを動的に使用して、プライベート・サブネット内のインスタンスにアクセスできます。動的トンネルは、ローカルポート上のSOCKSプロキシを提供しますが、リモートホストからの接続です。 - ロード・バランサ・ノード:
ロード・バランサ・ノードは、コンテナ化されたアプリケーションを実行している使用可能なKubernetesノードにトラフィックをインターセプトおよび分散します。アプリケーションをパブリック・インターネットからアクセスできる必要がある場合はパブリック・ロード・バランサを使用し、それ以外の場合はパブリックIPアドレスのないプライベート・ロード・バランサを使用します。アーキテクチャは2つのロード・バランサ・ノードを示し、それぞれが個別の可用性ドメインにあります。
- 管理ホスト(オプション):
管理ホストを使用することで、
kubectl、helmおよびクラウド外部のOracle Cloud Infrastructure CLIなどのインフラストラクチャ管理ツールのインストールおよび実行を回避できます。参照アーキテクチャでは、管理ホストはプライベート・サブネットにあり、ベース・ホストを介してアクセスできます。管理ホスト上でOracle Cloud Infrastructure CLIを実行できるようにするには、それをインスタンス・プリンシパルとして指定する必要があります。 - Kubernetesワーカー・ノード:
Kubernetes就業者ノードは、コンテナ化済アプリケーションをデプロイできるコンピュート・インスタンスです。この参照アーキテクチャ内のすべての就業者ノードは単一ノード・プールにあり、プライベート・サブネットにアタッチされます。必要に応じて、複数のノード・プールを作成できます。
参照アーキテクチャ内の就業者ノードは、パブリック・インターネットから直接アクセスできません。コンテナ化されたアプリケーションのユーザーは、ロード・バランサを介してそれらにアクセスできます。管理者は、ベース・ホストを介して就業者ノードにアクセスできます。
このアーキテクチャは、3つの就業者ノードを示し、それぞれがリージョン内の個別の可用性ドメインAD1、AD2およびAD3になります。Oracleのテナンシで実行されるKubernetesマスター・ノードは、表示されません。
コンテナ化されたアプリケーションをデプロイするリージョンに単一の可用性ドメインが含まれている場合、ワーカー・ノードは、次のアーキテクチャに示すように、可用性ドメイン内のフォルト・ドメイン(FD)全体に分散されます。
必要なサービスおよび権限について
このソリューションには、次のサービスと権限が必要です。
| サービス | 必要な権限 |
|---|---|
| Oracle Cloud Infrastructure Identity and Access Management | 動的グループおよびポリシーを管理します。 |
| Oracle Cloud Infrastructure Networking | Vcn、サブネット、インターネット・ゲートウェイ、NATゲートウェイ、サービス・ゲートウェイ、ルート表およびセキュリティ・リストを管理します。 |
| Oracle Cloud Infrastructure Compute | コンピュート・インスタンスを管理します。 |
| Oracle Cloud Infrastructure Container Engine for Kubernetes | クラスタとノード・プールを管理します。
「クラスタの作成とデプロイメントのポリシー構成」を参照してください。 |