2 Kubernetesデプロイメントについて

コンテナは、アプリケーションをバンドルして実行するための優れたメカニズムを提供します。本番環境では、アプリケーションを実行するコンテナを管理し、停止時間がないことを確認する必要があります。たとえば、コンテナが停止した場合、別のコンテナがすぐに起動する必要があります。Kubernetesによってコンテナ管理が簡素化されます。

この章の内容は次のとおりです。

• Kubernetesとは
  Kubernetesは、コンテナ化されたワークロードやサービスを管理するためのポータブルで拡張可能なオープンソース・プラットフォームであり、宣言的な構成と自動化の両方を容易にします。
• Kubernetesの要件
  Oracle Identity and Access ManagementをKubernetesにデプロイするには、環境が特定の基準を満たす必要があります。
• Kubernetesアーキテクチャについて
  Kubernetesホストは、コントロール・プレーン・ノードとワーカー・ノードで構成されます。
• Kubernetesクラスタのサイズ設定
  高可用性ソリューションを維持するには、Kubernetesクラスタに少なくとも2つのワーカー・ノードと高可用性コントロール・プレーンが必要です。
• Oracleエンタープライズ・デプロイメントで使用される主要コンポーネント
  Oracleエンタープライズ・デプロイメントでは、ポッド、Kubernetesサービス、DNSなどのKubernetesコンポーネントが使用されます。

Kubernetesとは

Kubernetesは、コンテナ化されたワークロードやサービスを管理するためのポータブルで拡張可能なオープンソース・プラットフォームであり、宣言的な構成と自動化の両方を容易にします。

Kubernetesは、CrioやDockerなどのコンテナ・プラットフォームの上位に位置しています。Kubernetesは、コンテナ・イメージをホストのクラスタにデプロイできるようにするメカニズムを提供します。Kubernetesを使用してコンテナをデプロイすると、Kubernetesはそのコンテナをワーカー・ノードの1つにデプロイします。配置メカニズムは、ユーザーに対して透過的です。

Kubernetesは次を提供します:

• サービス検出とロード・バランシング: Kubernetesは、DNS名または独自のIPアドレスを使用してコンテナを公開できます。コンテナへのトラフィックが大きい場合、Kubernetesは、デプロイメントの安定を維持するため、負荷を調整してネットワーク・トラフィックを分散します。
• ストレージ・オーケストレーション: Kubernetesでは、選択したストレージ・システム(ローカル・ストレージ、NASストレージ、パブリック・クラウド・プロバイダなど)を自動的にマウントできます。
• 自動化されたロールアウトとロールバック: Kubernetesを使用してデプロイ済のコンテナの目的の状態を記述し、制御された速度で実際の状態を目的の状態に変更できます。たとえば、Kubernetesを自動化してデプロイメント用に新しいコンテナを作成し、既存のコンテナを削除して、すべてのリソースを新しいコンテナに導入できます。
• 自動ビン・パッキング: コンテナ化タスクの実行に使用できるノードのクラスタをKubernetesに提供し、各コンテナに必要なCPUおよびメモリー(RAM)を指定すると、Kubernetesはコンテナをノードに適合させ、使用可能なリソースを最大限に活用できます。
• 自己修復: Kubernetesは、失敗したコンテナを再起動し、コンテナを置換し、ユーザー定義のヘルス・チェックに応答しないコンテナを強制終了します。サービスを提供する準備ができるまで、それらをクライアントに通知しません。
• シークレットおよび構成管理: Kubernetesでは、パスワード、OAuthトークン、SSHキーなどの機密情報を格納および管理できます。コンテナ・イメージを再構築せず、スタック構成でシークレットを公開することなく、シークレットおよびアプリケーション構成をデプロイして更新できます。

Kubernetesの強みは、中間層にスケーラブルなプラットフォームを提供することにあります。Kubernetesをアプリケーション層のラッパーとして検討してください。つまり、アーキテクチャを設計する際には、従来のデプロイメントと同じネットワーク・セキュリティの考慮事項を適用する必要があります。Web層は、Kubernetesクラスタをホストするネットワーク外部にある別のDMZに引き続き保持し、ファイアウォールまたはセキュリティ・リストを使用してトラフィックを制御します。同じことが、データベースにも適用されます。データベースは、Kubernetesレイヤーからのアクセスを制御するファイアウォールまたはセキュリティ・リストを使用して、クラスタ外部にある別のネットワークに存在します。

Kubernetesをデプロイする場合、異なるワークロードを個別のKubernetesクラスタに保持するという従来の推奨事項を使用することを強くお薦めします。たとえば、開発ワークロードと本番ワークロードを同じKubernetesクラスタに混在させることはお薦めしません。

Kubernetesの要件

Oracle Identity and Access ManagementをKubernetesにデプロイするには、環境が特定の基準を満たす必要があります。

基準は次のとおりです:

• Kubernetesクラスタ1.19.7以上: クラスタは、Oracle Cloud Native Environmentによって提供されるものと類似したスタンドアロンKubernetesクラスタ、またはOracle Container Engine (OKE)などのクラウド管理対象Kubernetes環境です。デプロイメントに十分な容量のある十分なKubernetesワーカー・ノードが必要です。単一障害点をなくすには、複数のワーカー・ノードが必要です。スタンドアロンのKubernetes環境を使用している場合、高可用性のためにKubernetesコントロール・プレーンを構成する必要があります。
• 製品のデプロイ元である管理ホスト: このホストは、Kubernetesコントロール・ホスト、Kubernetesワーカー・ホストまたは独立したホストです。このホストには、クラスタと同じバージョンを使用してデプロイされるkubectl、およびhelmが必要です。

このガイドでは、次の製品バージョンを使用して検証される手順について説明します:

• Oracle Containers for Cloud (OKE) 1.28.2
• Oracle Cloud Native Environment 1.8
• Helm 3.13.1

デプロイメントに関するその他の考慮事項の詳細は、「技術的な概要 - クラウド・ネイティブ・インフラストラクチャ上のIAMコンテナ化されたサービスのデプロイメントおよびDevOpsの考慮事項」を参照してください。

Kubernetesアーキテクチャについて

Kubernetesホストは、コントロール・プレーン・ノードとワーカー・ノードで構成されます。

コントロール・プレーン: コントロール・プレーンは、Kubernetesコンポーネントの管理とアプリケーションのデプロイを担当します。エンタープライズ・デプロイメントでは、コントロール・プレーン・ホストの障害によってKubernetesクラスタが停止しないように、Kubernetesコントロール・プレーンの可用性が高いことを確認する必要があります。

ワーカー・ノード: コンテナがデプロイされる場所であるワーカー・ノード。

ノート:

個々のホストは、コントロール・プレーン・ホストとワーカー・ホストの両方にすることができます。

図2-1 Kubernetesクラスタの図

コンポーネントの説明:

• コントロール・プレーン: コントロール・プレーンは次で構成されます:
  • kube-apiサーバー: APIサーバーは、Kubernetes APIを公開するコントロール・プレーンのコンポーネントです。
  • etcd: Kubernetesのバックエンド・データストアおよびすべてのクラスタ・データを格納するために使用されます。
  • スケジューラ: スケジューラは、ワーカー・ノードへのコンテナの配置を担当します。この場合、リソース要件、ハードウェアおよびソフトウェア・ポリシーの制約、アフィニティ仕様およびデータ・アフィニティが考慮されます。
  • コントロール・マネージャ: コントローラ・プロセスの実行を担当します。コントローラ・プロセスは次で構成されます:
    • ノード・コントローラ
    • ルート・コントローラ
    • サービス・コントローラ

  コントロール・プレーンは、Kubernetes APIサーバーがデプロイされ、LBRによってフロント・エンド処理される3つのノードで構成されます。

• ワーカー・ノード・コンポーネント: ワーカー・ノードには次のコンポーネントが含まれます:
  • Kubelet: クラスタ内の各ワーカー・ノードで実行されるエージェント。これは、コンテナがポッド内で実行されていることを保証します。
  • Kubeプロキシ: Kubeプロキシは、クラスタの各ノードで実行されるネットワーク・プロキシです。これは、ポッド間通信およびクラスタ外通信を可能にするネットワーク・ルールを維持します。
  • アドオン: アドオンはクラスタをさらに拡張し、次のようなサービスを提供します:
    • DNS
    • Web UIダッシュボード
    • コンテナ・リソース・モニタリング
    • ロギング
  • ロード・バランサは、多くの場合、トラフィックをワーカー・ノードに転送しやすくするためにワーカー・ノードの前に配置されます。また、ロード・バランサはスケール・アップとスケール・アウトを簡略化することで、アプリケーション構成の変更の必要性をなくします。個々のNodePortサービスを使用している場合、NodePortサービスごとにパスウェイを作成する必要があるため、構成の変更が困難になることがあります。

Kubernetesクラスタのサイズ設定

高可用性ソリューションを維持するには、Kubernetesクラスタに少なくとも2つのワーカー・ノードと高可用性コントロール・プレーンが必要です。

容量を少なくしてワーカー・ノードの数を多くするか、容量を大きくしてワーカー・ノードの数を少なくするかを選択できます。ワーカー・ノードが2つで、1つが使用できなくなると、システム容量の50%が失われます。この設定では、障害が発生したノードが、正常に稼働しているノードで置き換えられるまで、単一障害点(正常に稼働しているワーカー・ノード)ができてしまいます。ワーカー・ノードの数が多ければ、その1つに障害が発生しても、複数のワーカー・ノードが残るため、単一障害点はなくなります。ただし、残りのワーカー・ノードには、障害が発生したワーカー・ノードで最初に実行されたポッドを実行できるだけの十分な容量が必要です。

クラスタのサイズ設定では、クラスタで実行されるすべてのポッドのリソース要件を算出し、Kubernetesサービスに20%のオーバーヘッドを追加する必要があります。必要な容量に応じてワーカー・ノードを追加するのは、比較的単純なプロセスです。クラスタで複数のアプリケーションを実行する場合は、それらすべてのアプリケーションに関連付けられたすべてのポッドを可用性の高い方法で実行できる容量が必要です。つまり、アプリケーション要件の合計が20CPUでメモリーが100GBの場合、少なくとも2つのワーカー・ノード(それぞれが10CPUおよび50GBのメモリーに20パーセントを加えたもの)が必要なため、ワーカー・ノードごとに12CPUおよび60GBのメモリーが必要になります。

ストレージ要件は、使用する予定のストレージのタイプによって異なります。各ポッドでは、ブロック・ストレージを少し使用して、イメージやローカル・データをホストします。また、永続ボリュームに格納されるデータには、NFSなどの共有ストレージが必要です。

次の表に、小規模、中規模および大規模の各システムのサイズ設定のリファレンスを示します。要件は製品ごとに異なり、Kubernetesのオーバーヘッドは考慮されていません:

表2-1 Oracle Unified Directoryのサイズ設定

システム・サイズ	ユーザー数	CPU	メモリー
開発	-	0.5	2GB
小規模	5000	4	16GB
中規模	50000	8	32GB
大規模	200万	16	64GB+

高可用性を実現するには、少なくとも2つのポッドが必要です。Oracle Unified Directory 12.2.1.4.0のパフォーマンスの詳細を参照してください。

表2-2 Oracle Access Managerのサイズ設定

システム・サイズ	ユーザー数	CPU	メモリー
開発	-	1	2GB
小規模	16000	4	60GB
中規模	24000	8	60GB
大規模	32000+	16	120GB

高可用性を実現するには、少なくとも2つのポッドが必要です。Oracle Container Engine for KubernetesでのOracle Access Management 12.2.1.4.0のパフォーマンスの詳細を参照してください。

表2-3 Oracle Identity Governanceのサイズ設定

システム・サイズ	ユーザー数	CPU	メモリー
開発	-	2	4GB
小規模	50000	4	5GB
中規模	150000	8	8GB
大規模	5000	20	12GB

高可用性を実現するには、少なくとも2つのポッドが必要です。大規模なシステムでは、少なくとも5つのポッドが必要です。『Oracle Identity Governanceサイジング・ガイド』を参照してください。

表2-4 Oracle Advanced Authenticationのサイズ設定

システム・サイズ	ユーザー数	CPU	メモリー
開発	-	1	2GB
小規模	16000	4	60GB
中規模	24000	8	60GB
大規模	32000+	16	120

高可用性を実現するには、少なくとも2つのポッドが必要です。

表2-5 Oracle Identity Role Intelligenceのサイズ設定

パラメータ	説明	小規模	中規模	大規模
executorInstances	エグゼキュータ・ポッドの数を指定します。	3	5	7
driverRequestCores	ドライバ・ポッドのCPUリクエストを指定します。	2	3	4
driverLimitCores	ドライバ・ポッドのハードCPU制限を指定します。	2	3	4
executorRequestCore	各エグゼキュータ・ポッドのCPUリクエストを指定します。	2	3	4
executorLimitCore	各エグゼキュータ・ポッドのハードCPU制限を指定します。	2	3	4
driverMemory	ドライバ・ポッドのハード・メモリー制限を指定します。	2GB	3GB	4GB
executorMemory	各エグゼキュータ・ポッドのハード・メモリー制限を指定します。	2GB	3GB	4GB

高可用性を実現するには、少なくとも2つのポッドが必要です。『Oracle Identity Role Intelligenceの管理』の「パフォーマンスのチューニング」を参照してください。

Oracleエンタープライズ・デプロイメントで使用される主要コンポーネント

Oracleエンタープライズ・デプロイメントでは、ポッド、Kubernetesサービス、DNSなどのKubernetesコンポーネントが使用されます。

この項では、Oracleエンタープライズ・デプロイメントで使用されるこれらの各Kubernetesコンポーネントについて説明します。

• コンテナ・イメージ
  
• ポッド
  
• ポッド・スケジューリング
  
• 永続ボリューム
  
• Kubernetesサービス
  
• イングレス・コントローラ
  
• ドメイン・ネーム・システム
  
• ネームスペース
  
• その他の製品
  

コンテナ・イメージ

コンテナ・イメージは、実行可能コードを含む、変更できない静的ファイルです。Kubernetesにデプロイされると、コンテナ・イメージはポッドの作成に使用されます。イメージには、Kubernetesでの実行に必要なシステム・ライブラリ、システム・ツールおよびOracleバイナリが含まれています。イメージでは、ホスト・マシンのOSカーネルが共有されます。

コンテナ・イメージは、親イメージまたはベース・イメージに構築されたファイル・システム・レイヤーからコンパイルされます。これらのレイヤーにより、様々なコンポーネントの再利用が促進されます。そのため、プロジェクトごとに、すべてを最初から作成する必要はありません。

ポッドのベースはコンテナ・イメージです。このコンテナ・イメージは読取り専用です。各ポッドには、コンテナ・イメージ独自のインスタンスがあります。

コンテナ・イメージには、製品の実行に必要なすべてのソフトウェアとライブラリが含まれています。オペレーティング・システム全体は必要ありません。多くのコンテナ・イメージには、viエディタやpingなどの標準的なオペレーティング・ユーティリティが含まれていません。

ポッドをアップグレードする際は、別のコンテナ・イメージを使用するよう、ポッドに指示することになります。たとえば、Oracle Unified Directoryのコンテナ・イメージが7月23日のパッチをベースにしている場合、10月23日のバンドル・パッチを使用するようにポッドをアップグレードするには、10月のイメージを使用してポッドを再起動するよう、ポッドに指示する必要があります。

Oracleコンテナは、特定のユーザーIDおよびグループIDを使用して構築されます。オラクル社から提供されるコンテナ・イメージでは、ユーザーID 1000とグループID 1000が使用されています。ファイル・システムまたは永続ボリュームへの書込みを有効にするには、このユーザーIDに書込みアクセス権を付与する必要があります。オラクル社から提供されるすべてのコンテナ・イメージで、このユーザーIDとグループIDが使用されています。

組織でこのユーザーIDまたはグループIDがすでに使用されている場合は、別のIDを使用するよう、イメージを再構成する必要があります。この特性は、このドキュメントの対象外です。

ポッド

ポッドは、共有ストレージ/ネットワーク・リソースを含む1つ以上のコンテナのグループであり、コンテナの実行方法の仕様です。ポッドのコンテンツは、常に同じ場所に配置されて共同スケジュールされ、共有コンテキストで実行されます。ポッドは、比較的密に結合された1つ以上のアプリケーション・コンテナを含むアプリケーション固有の論理ホストをモデル化します。

Oracleエンタープライズ・デプロイメントでは、各WebLogic Serverは異なるポッドで実行されます。各ポッドは、Kubernetesクラスタ内の他のポッドと通信できます。

ノードが使用できなくなっても、ポッドはKubernetes (バージョン1.5以上)によって自動的に削除されません。アクセスできないノード上で実行するポッドは、タイムアウトの後で「終了中」または「不明」状態になります。アクセスできないノード上のポッドをユーザーが正常に削除しようとするとき、ポッドもこのような状態になっている可能性があります。このような状態のポッドは、次のいずれかの方法でapiserverから削除できます:

• 管理者またはノード・コントローラがノード・オブジェクトを削除します。
• 応答のないノード上のkubeletが、応答を開始し、ポッドを終了し、apiserverからエントリを削除します。
• 管理者がポッドを強制的に削除します。

ベスト・プラクティスとして1番目または2番目のアプローチを使用することをお薦めします。ノードが稼働していないこと(ネットワークから完全に切断された場合や電源が停止されている場合など)が確認された場合は、ノード・オブジェクトを削除します。ノードがネットワーク分断の影響を受けている場合は、問題の解決を試みるか、分断が解消されるまで待機します。分断が解消すると、kubeletが、ポッドの削除を完了し、その名前をapiserver内で解放します。

通常、システムによって削除が完了されるのは、ポッドがノードで実行されなくなった場合、または管理者がポッドを削除した場合です。ポッドを強制的に削除してこれをオーバーライドできます。

ポッド・スケジューリング

デフォルトでは、Kubernetesは、ポッドの実行に十分な容量があるワーカー・ノードで実行されるようにそのポッドをスケジュールします。状況によっては、使用可能なワーカー・ノードのサブセットでスケジューリングが行われることが望ましい場合もあります。このタイプのスケジューリングは、Kubernetesラベルを使用して実現できます。

永続ボリューム

ポッドは、作成されるとコンテナ・イメージに基づいています。コンテナ・イメージは、デプロイする製品用にOracleによって提供されます。ポッドが作成されると、そのイメージに基づいてランタイム環境が作成されます。その環境は、ポッドが再起動されるたびにコンテナ・イメージでリフレッシュされます。つまり、ランタイム環境内で加えた変更は、コンテナが再起動されるたびに失われます。

永続ボリュームはディスクの領域であり、通常は、ポッドで使用可能であるがイメージ自体には含まれないNFSによって提供されます。これは、保持したいデータ(WebLogicドメイン構成など)をポッドの再起動後も引き続き使用できる、つまりデータが永続的であることを意味します。

永続ボリューム(PV)をポッドにマウントする方法は2つあります。

1. PVをポッドに直接マウントし、ポッドがクラスタ内のどこで起動してもPVを使用できるようにします。この方法の利点は、追加の構成をせずにどこでもポッドを起動できることです。この方法の欠点は、ポッドにマウントされるNFSボリュームが1つあることです。NFSボリュームが破損した場合は、バックアップに戻すか、障害時リカバリ・サイトにフェイルオーバーする必要があります。

2. PVをワーカー・ノードにマウントし、ローカル・ファイル・システムと同様にポッドと通信できるようにします。この方法の利点は、異なるNFSボリュームを異なるワーカー・ノードにマウントして、組込みの冗長性を提供できることです。このアプローチの短所は次のとおりです。

   • 管理オーバーヘッドの増加。
   • ポッドを、特定バージョンのファイル・システムを使用するノードに制限する必要があります。たとえば、奇数のポッドはすべて、ファイル・システム1にマウントされた奇数のワーカー・ノードを使用し、偶数のポッドはすべて、ファイル・システム2にマウントされた偶数のワーカー・ノードを使用するようにします。
   • ファイル・システムは、ポッドが起動される可能性があるすべてのワーカー・ノードにマウントする必要があります。大規模なクラスタとは異なり、この要件が、小規模なクラスタで問題になることはありません。
   • ワーカー・ノードがアプリケーションにリンクされます。ワーカー・ノードのメンテナンスを行う場合は、ファイル・システムと適切なラベルがリストアされていることを確認する必要があります。

   rsync cronジョブなどを使用して、NFSボリュームの内容が確実に同期されるようにプロセスを設定する必要があります。

   冗長性と可用性の最大化が目標の場合は、このソリューションを採用する必要があります。

Kubernetesサービス

Kubernetesサービスは、実行中のポッドの数に関係なく、ポッドで実行されているプロセスを公開します。たとえば、それぞれ異なるポッドで実行されているWebLogic管理対象サーバーのクラスタには、サービスが関連付けられます。このサービスは、クラスタ内の個々のポッドにリクエストをリダイレクトします。異なる方法でポッドと対話できる場合は、複数のサービスが必要です。

たとえば、HTTPまたはOAPのいずれかを使用して対話できるOAMサーバーのクラスタがある場合、2つのサービス(1つはHTTP用、もう1つはOAP用)を作成します。

Kubernetesサービスは、クラスタの内部または外部にできます。内部サービスのタイプはClusterIPで、外部サービスのタイプはNodePortです。

一部のデプロイメントでは、サービスの前面にプロキシを使用します。このプロキシは通常、Ngnixなどのイングレス・ロード・バランサによって提供されます。イングレスによって、基礎となるKubernetesサービスへの抽象化のレベルが許可されます。

Kubernetesを使用したときのNodePortサービスの結果は、イングレスを使用した場合と同様になります。NodePortモードでは、イングレスによってこれらのサービスの統合管理が可能になります。

このガイドでは、イングレスまたはネイティブKubernetes NodePortサービスを使用する方法について説明します。方法を組み合せるのではなく1つを選択することをお薦めします。このガイドでは、デモンストレーションの目的でNginx Ingress Controllerの使用方法について説明します。

Kubernetesサービスは、小規模なポート範囲を使用します。そのため、Kubernetesサービスが作成されると、ポート・マッピングが発生します。たとえば、ポッドがポート7001を使用している場合、Kubernetes/イングレス・サービスはそのポートとして30701を使用し、ポート30701を内部的に7001にマップします。個々のNodePortサービスを使用している場合は、クラスタ内の各ワーカー・ノードで、対応するKubernetesサービス・ポートが予約されることに注意してください。

Kubernetes/イングレス・サービスは、コンテナが実行されているワーカー・ノードに関係なく、各ワーカー・ノードで認識されます。したがって、ロード・バランサは、多くの場合、ルーティングおよびワーカー・ノードのスケーラビリティを簡略化するためにワーカー・ノードの前に配置されます。

サービスと対話するには、worker_node_hostname:Service portという形式を使用してサービスを参照する必要があります。この形式は、個々のNodePortサービスを使用しているか、統合されたイングレス・ノード・ポート・サービスを使用しているかに関係なく適用されます。

複数のワーカー・ノードがある場合、単一障害点を削除するには、コールに複数のワーカー・ノードを含める必要があります。これを行うには次のように様々な方法があります:

• ロード・バランサ
• ダイレクト・プロキシ・コール(OHSでWebLogicClusterディレクティブを使用するなど)
• DNS CName

特に指定のないかぎり、Oracleエンタープライズ・デプロイメントでは、ダイレクト・プロキシ・コールが使用されます。

イングレス・コントローラ

Kubernetesサービスと対話する方法は2つあります。外部に面するサービスは、アクセスするKubernetesオブジェクトごとに作成できます。このタイプのサービスは、Kubernetes NodePortサービスと呼ばれます。または、Kubernetesクラスタ内のイングレス・サービスを使用してリクエストを内部的にリダイレクトすることもできます。

• イングレスについて
  
• デプロイメント・オプション
  
• Secure Socket Layer
  
• イングレスのスコープ
  

イングレスについて

イングレスはKubernetesクラスタ内に存在するプロキシ・サーバーであり、クラスタ内のすべてのワーカー・ノードで各サービスのポートを予約するNodePortサービスとは異なります。イングレス・サービスを使用すると、すべてのHTTP/HTTPSトラフィックに対して単一のポートを予約できます。

イングレス・サービスは、Oracle HTTP Serverと同様に機能します。仮想ホストの概念があり、必要に応じてSSLを終了できます。様々なイングレスの実装があります。ただし、このガイドではNGNIXのインストールと構成について説明します。インストールは他のイングレス・サービスの場合と似ていますが、コマンド構文が異なる場合があります。したがって、別のイングレスを使用する場合は、該当する製造元ドキュメントを参照して同等のコマンドを確認してください。

イングレスはHTTP、HTTPS、LDAPおよびLDAPSプロトコルをプロキシできます。

イングレスは必須ではありません。個々のNodePortサービスを使用し、Oracle HTTP Serverを介してKubernetesサービスと通信できます。ただし、Oracle Identity Role Intelligence (OIRI)やOracle Advanced Authentication (OAA)などのOracle Identity and Access Managementマイクロサービスのみを使用している場合は、Oracle HTTP Serverではなくイングレス・サービスの使用をお薦めします。

デプロイメント・オプション

イングレスはKubernetesクラスタ内部で実行されます。様々な方法で構成できます:

• ロード・バランサ: ロード・バランサには、Kubernetesサービスと対話するために接続できる外部IPアドレスが用意されています。この機能はエンタープライズ・デプロイメントでは好ましくありません。最大限のセキュリティを保つため、Kubernetesサービスをインターネットに直接公開することはないからです。最もセキュアなメカニズムは、ロード・バランサにリクエストをルーティングして、そこから個別の非武装地帯(DMZ)に存在するOracle HTTP Serverにリクエストを転送することです。その後、HTTPサーバーがリクエストをアプリケーション層に渡します。
• NodePort: このモードでは、イングレスはKubernetesサービス間の単純なロード・バランサとして機能します。

  イングレスNodePortサービスを使用する場合と個々のNodePortサービスを使用する場合の違いは、イングレス・コントローラでは、提供するサービス・タイプごとにポートが1つ予約される点です。たとえば、すべてのHTTP通信用に1つ、すべてのLDAP通信用に1つ、などです。個々のノード・ポート・サービスでは、アプリケーションで使用されるサービスおよびタイプごとに1つのポートが予約されます。

  たとえば、OAMなどのアプリケーションには4つのサービス(管理サーバー用に2つ、OAM管理対象サーバー用に1つ、ポリシー管理対象サーバー用に1つ)があります。

  • イングレスでは、アプリケーション・サービスの数に関係なく、NodePortサービスが1つ予約されます。
  • 個々のNodePortサービスを使用して、OAMでは4つのポートが予約されます。

    この値は、Kubernetesクラスタにデプロイされたアプリケーションの数で乗算されます。ただし、イングレスでは引き続き1つのポートが使用されます。

Secure Socket Layer

HTTPリクエストのみを処理するようにイングレスを構成できます。ただし、このガイドでは、HTTPリクエストとHTTPSリクエストの両方を処理するイングレス・コントローラの設定について説明します。従来のデプロイメントおよびOracle HTTP Serverを使用している場合は、HTTPS接続が必要になることはほとんどありません。ただし、マイクロサービスを直接使用している場合は、HTTPS接続を使用する可能性が高くなります。

イングレスのスコープ

通常、Kubernetesクラスタごとに1つのイングレス・コントローラがあります。このコントローラがクラスタ内のすべてのネームスペースを管理します。複数のコントローラが異なるネームスペース・セットを管理して、同じクラスタ内で複数のイングレスを使用することもできます。複数のコントローラの構成については、このドキュメントでは扱いません。ただし、複数のイングレスを使用する場合は、「複数のイングレス・コントローラの実行」を参照してください。

ドメイン・ネーム・システム

クラスタに定義されているすべてのサービス(DNSサーバー自体を含む)には、DNS名が割り当てられます。デフォルトでは、クライアント・ポッドのDNS検索リストには、ポッド独自のネームスペースとクラスタのデフォルト・ドメインが含まれます。

Kubernetesクラスタ用に、次のタイプのDNSレコードが作成されます:

• サービス

  レコード・タイプ: AまたはAAAAレコード

  名前形式: my-svc.namespace.svc.cluster-example.com

• ポッド

  レコード・タイプ: AまたはAAAAレコード

  名前形式: podname.namespace.pod.cluster-example.com

Kubernetesでは、内部の名前解決に使用されるCoreDNSという組込みDNSサーバーを使用します。

外部の名前解決(login.example.comなど、クラスタの外部で使用される名前)は、Kubernetesクラスタ内では使用できない場合があります。この問題が発生した場合は、次のいずれかのオプションを使用できます:

• オプション1 - 会社ドメインのCoreDNSにセカンダリDNSサーバーを追加します。
• オプション2 - 外部ホストのCoreDNSに個々のホスト・エントリを追加します。たとえば、login.example.comです。

ネームスペース

ネームスペースによって、クラスタを仮想サブクラスタに編成できます。これは、様々なチームまたはプロジェクトでKubernetesクラスタを共有する場合に役立ちます。クラスタ内に任意の数のネームスペースを追加できます。各ネームスペースは、他のものから論理的に分離されますが、相互に通信できます。

エンタープライズ・デプロイメントでは、デプロイされたすべてのアーティファクトをまとめて維持するために、製品ごとに異なるネームスペースが使用されます。たとえば、すべてのOracle Access Managerコンポーネントは、Oracle Access Managerのネームスペースにデプロイされます。

このガイドで説明するデプロイメント手順では、次のネームスペースが使用されます:

表2-6 このガイドで使用されるネームスペース

ネームスペースの名前	説明
INGRESSNS	イングレス・コントローラのネームスペース。
ELKNS	ElasticsearchおよびKibanaのネームスペース。
MONITORING	PrometheusおよびGrafanaのネームスペース。
OUDNS	Oracle Unified Directory (OUD)のネームスペース。
OAMNS	Oracle Access Manager (OAM)のネームスペース。
OIGNS	Oracle Identity Governance (OIG)のネームスペース。
OIRINS	Oracle Identity Role Intelligence (OIRI)のネームスペース。
DINGNS	Oracle Identity Role Intelligence Data Ingesterのネームスペース。
OPNS	Oracle WebLogic Operatorのネームスペース。
OAANS	Oracle Advanced Authentication (OAA)のネームスペース。

その他の製品

Kubernetesに加え、他の製品を使用してKubernetesの使用性を向上させることができます。これらの製品には次のものがあります:

• Elasticsearch: Elasticsearchは、検索と分析を行う分散型で無料のオープン・エンジンで、あらゆる種類のデータを対象とします。Elasticsearchは、Elastic Stackの中央コンポーネントであり、データの取込み、エンリッチメント、ストレージ、分析および視覚化のための無料のオープン・ツールのセットです。一般に、(Elasticsearch、Logstash、Kibanaにちなんで)ELKスタックと呼ばれます。
  Elasticsearchは次の目的で使用されます:

  • ロギングおよびログ分析
  • インフラストラクチャ・メトリックとコンテナの監視
  • アプリケーション・パフォーマンスの監視
  • インフラストラクチャ・メトリックとコンテナの監視
• Kibana: Kibanaは、Elasticsearch用のデータの可視化および管理ツールです。Kibanaにより、リアルタイムのヒストグラム、折れ線グラフ、円グラフおよびマップが使用可能になります。Kibanaには、データに基づいて動的なインフォグラフィックをカスタマイズして作成できるCanvasなどの高度なアプリケーションや、地理空間データを視覚化するためのElastic Mapsもあります。
• Logstash: LogstashはFilebeatとともに使用され、ログ・ファイルをスクレイプし、Elasticsearchに送信する前に、Elasticsearchで認識できる形式に変換します。
• Grafana: Grafanaは、メトリック、ログおよびトレースを監視して分析できる完全な可観測性スタックです。データの格納場所に関係なく、データの問合せや視覚化、アラートの発行を行い、データを把握することができます。Grafanaは、Prometheusと組み合せて使用されることが多いです。
• Prometheus: Prometheusは、オープンソース・システムの監視およびアラートのツールキットです。Prometheusでは、メトリックが時系列データとして収集および格納されるため、メトリック情報は、ラベルと呼ばれるオプションのキーと値のペアとともに、記録されたタイムスタンプ付きで格納されます。