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

コンテナ・イメージ

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

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

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

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

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

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

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

ポッド

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

OUDSMデプロイメントでは、各OUDSMインスタンスは異なるポッドで実行されます。

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

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

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

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

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

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

永続ボリューム

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

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

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

PVをポッドに直接マウントし、ポッドがクラスタ内のどこで起動してもPVを使用できるようにします。この方法の利点は、追加の構成をせずにどこでもポッドを起動できることです。この方法の欠点は、ポッドにマウントされるNFSボリュームが1つあることです。NFSボリュームが破損した場合は、バックアップに戻すか、障害時リカバリ・サイトにフェイルオーバーする必要があります。
PVをワーカー・ノードにマウントし、ローカル・ファイル・システムと同様にポッドと通信できるようにします。この方法の利点は、異なるNFSボリュームを異なるワーカー・ノードにマウントして、組込みの冗長性を提供できることです。このアプローチの短所は次のとおりです。
- 管理オーバーヘッドの増加。
- ポッドを、特定バージョンのファイル・システムを使用するノードに制限する必要があります。たとえば、奇数のポッドはすべて、ファイル・システム1にマウントされた奇数のワーカー・ノードを使用し、偶数のポッドはすべて、ファイル・システム2にマウントされた偶数のワーカー・ノードを使用するようにします。
- ファイル・システムは、ポッドが起動される可能性があるすべてのワーカー・ノードにマウントする必要があります。大規模なクラスタとは異なり、この要件が、小規模なクラスタで問題になることはありません。
- ワーカー・ノードがアプリケーションにリンクされます。ワーカー・ノードのメンテナンスを行う場合は、ファイル・システムと適切なラベルがリストアされていることを確認する必要があります。
rsync cronジョブなどを使用して、NFSボリュームの内容が確実に同期されるようにプロセスを設定する必要があります。
冗長性と可用性の最大化が目標の場合は、このソリューションを採用する必要があります。

Kubernetesサービス

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

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

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

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

このガイドでは、Nginxイングレス・コントローラを使用したイングレスを使用する方法について説明します。

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

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

サービスと対話するには、worker_node_hostname:Serviceポートという形式を使用してサービスを参照する必要があります。

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

ロード・バランサ
ダイレクト・プロキシ・コール
DNS CName

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

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

イングレスはKubernetesクラスタ内に存在するプロキシ・サーバーであり、クラスタ内のすべてのワーカー・ノードで各サービスのポートを予約するNodePortサービスとは異なります。イングレス・サービスを使用すると、すべてのHTTP/HTTPSトラフィックに対して単一のポートを予約できます。イングレス・サービスには仮想ホストの概念があり、必要に応じてSSLを終了できます。様々なイングレスの実装があります。ただし、このガイドではNGNIXのインストールと構成について説明します。インストールは他のイングレス・サービスの場合と似ていますが、コマンド構文が異なる場合があります。したがって、別のイングレスを使用する場合は、該当するベンダー・ドキュメントを参照して同等のコマンドを確認してください。イングレスはHTTP、HTTPS、LDAPおよびLDAPSプロトコルをプロキシできます。イングレスは必須ではありません。

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

ロード・バランサ: ロード・バランサには、Kubernetesサービスと対話するために接続できる外部IPアドレスが用意されています。
NodePort: このモードでは、イングレスはKubernetesサービス間の単純なロード・バランサとして機能します。イングレスNodePortサービスを使用する場合と個々のNodePortサービスを使用する場合の違いは、イングレス・コントローラでは、提供するサービス・タイプごとにポートが1つ予約される点です。たとえば、すべてのHTTP通信用に1つ、すべてのLDAP通信用に1つ、などです。個々のノード・ポート・サービスでは、アプリケーションで使用されるサービスおよびタイプごとに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サーバーを使用します。
外部の名前解決(loadbalancer.example.comなど、クラスタの外部で使用される名前)は、Kubernetesクラスタ内では使用できない場合があります。この問題が発生した場合は、次のいずれかのオプションを使用できます:
- オプション1 - 会社ドメインのCoreDNSにセカンダリDNSサーバーを追加します。
- オプション2 - 外部ホストのCoreDNSに個々のホスト・エントリを追加します。

ネームスペース

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

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