OHSデプロイメントで使用される主要コンポーネント

コンテナ・イメージ

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

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

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

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

ポッドをアップグレードする際は、別のコンテナ・イメージを使用するよう、ポッドに指示することになります。たとえば、Oracle HTTP Serverのコンテナ・イメージが2025年7月のバンドル・パッチをベースにしている場合、2025年7月のバンドル・パッチを使用するようにポッドをアップグレードするには、2025年7月のイメージを使用するようポッドに指示し、ポッドを再起動する必要があります。アップグレードの詳細は、「パッチ適用およびアップグレード」を参照してください。

ポッド

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

Oracle HTTP Server (OHS)デプロイメントでは、各OHSは異なるポッドで実行されます。

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

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

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

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

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

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

Kubernetesサービス

Kubernetesサービスは、実行中のポッドの数に関係なく、ポッドで実行されているプロセスを公開します。たとえば、それぞれ異なるポッドで実行されているOracle HTTP Serverには、サービスが関連付けられます。このサービスは、クラスタ内の個々のポッドにリクエストをリダイレクトします。

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

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

このガイドでは、Oracle HTTP Server (OHS)はタイプNodePortとして公開され、イングレスはOHSへのアクセスには使用されません。

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

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

OHSがmod_wl_ohsを使用してWebLogic Serverと通信している場合、OHSはworker_node_hostname:Service portという形式を使用してこれらのサービスと対話します。この形式は、個々のNodePortサービスを使用しているか、統合されたイングレス・ノード・ポート・サービスを使用しているかに関係なく適用されます。

OHSが複数のWebLogicワーカー・ノードと通信する場合、単一障害点を削除するには、コールに複数のワーカー・ノードを含める必要があります。このガイドでは、OHSはWebLogicClusterディレクティブを使用してダイレクト・プロキシ・コールを行います。詳細は、「Oracle HTTP Serverでサポートされているアーキテクチャ」を参照してください。

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

このガイドではOracle HTTP Server (OHS)アクセスにNodePortを使用しますが、OHSが独立したKubernetesクラスタ上のWebLogic Serverと通信する場合、WebLogicClusterディレクティブはWebLogic Serverで使用されるイングレス・コントローラのポートを指している必要があります。

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

イングレス・サービスは、Oracle HTTP Serverと同様に機能します。仮想ホストの概念があり、必要に応じてSSLを終了できます。

詳細は、「Oracle HTTP Serverでサポートされているアーキテクチャ」を参照してください。

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

クラスタに定義されているすべてのサービス(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サーバーを使用します。

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

オプション1 - 会社ドメインのCoreDNSにセカンダリDNSサーバーを追加します。
オプション2 - 外部ホストのCoreDNSに個々のホスト・エントリを追加します。例: loadbalancer.example.com

ネームスペース

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

このガイドでは、OHSデプロイメントはネームスペースohsnsを使用します。

3.3 OHSデプロイメントで使用される主要コンポーネント