OpenShift Container Platform 内で、Kubernetes はコンテナーまたはホストのセット全体でコンテナー化されたアプリケーションを管理し、デプロイメント、メンテナンス、およびアプリケーションのスケーリングのメカニズムを提供します。Docker サービスはコンテナー化されたアプリケーションをパッケージ化し、インスタンス化し、これを実行します。Kubernetes クラスターは 1 つ以上のマスターおよびノードセットで構成されます。

また、オプションとして高可用性 (HA) のマスターを設定し、クラスターから単一障害点がなくなるようにすることもできます。

マスターは、API サーバー、コントローラーマネージャーサーバー、および etcd などのマスターコンポーネントが含まれるホストです。マスターはその Kubernetes クラスターでノードを管理し、Pod がノードで実行されるようスケジュールします。

ノードはコンテナーのランタイム環境を提供します。Kubernetes クラスターの各ノードには、マスターで管理される必要なサービスがあります。また、ノードには Docker サービス、kubelet および サービスプロキシー を含む Pod を実行するための必要なサービスも含まれます。

OpenShift Container Platform は、ノードをクラウドプロバイダー、物理システムまたは仮想システムから作成します。Kubernetes は、それらのノードの表現であるノードオブジェクトと対話します。マスターはノードオブジェクトからの情報を使用し、ヘルスチェックでノードを検証します。ノードはヘルスチェックをパスするまで無視され、マスターはノードが有効になるまでチェックを継続します。Kubernetes ドキュメントにはノード管理についての詳細が記載されています。

管理者は CLI を使用して OpenShift Container Platform インスタンスでノードを管理できます。ノードサーバーの起動時に完全な設定およびセキュリティーオプションを定義するには、専用のノード設定ファイルを使用します。

apiVersion: v1 1
kind: Node 2
metadata:
  creationTimestamp: null
  labels: 3
    kubernetes.io/hostname: node1.example.com
  name: node1.example.com 4
spec:
  externalID: node1.example.com 5
status:
  nodeInfo:
    bootID: ""
    containerRuntimeVersion: ""
    kernelVersion: ""
    kubeProxyVersion: ""
    kubeletVersion: ""
    machineID: ""
    osImage: ""
    systemUUID: ""

OpenShift Container Platform は、Docker Hub、サードパーティーによって実行されるプライベートレジストリーおよび統合 OpenShift Container Platform レジストリーを含む、イメージのソースとして Docker レジストリー API を実装するすべてのサーバーを利用できます。

OpenShift Container Platform は OpenShift Container レジストリー (OCR) という統合コンテナーレジストリーを提供します。これは、新規イメージリポジトリーをオンデマンドで自動的にプロビジョニングする機能を追加します。これにより、作成されるイメージをプッシュするためのアプリケーションビルドのビルトインロケーションがユーザーに提供されます。

新規イメージが OCR にプッシュされるたびに、レジストリーは OpenShift Container Platform に新規イメージについて通知し、namespace、名前、およびイメージメタデータなどの関連するすべての情報を伝えます。OpenShift Container Platform の異なる部分が新規イメージに対応し、新規ビルドおよびデプロイメントを作成します。

また OCR はビルドおよびデプロイメントの統合なしに、単独でコンテナーレジストリーとして機能するスタンドアロンコンポーネントとしてデプロイできます。詳細については、「OpenShift Container レジストリーのスタンドアロンデプロイメントのインストール」を参照してください。

OpenShift Container Platform はサードパーティーのイメージを使用してコンテナーを作成できますが、これらのレジストリーは OpenShift Container Platform レジストリーと同じイメージ通知サポートを提供する訳ではありません。取得されたタグの更新は、oc import-image <stream> を実行するのと同様に単純です。新規イメージが検出されると、事前に記述されたビルドおよびデプロイメントの応答が発生します。

OpenShift Container Platform Web コンソールは、Web ブラウザーからアクセスできるユーザーインターフェースです。開発者は Web コンソールを使用してプロジェクトのコンテンツの可視化、ブラウズ、および管理を実行できます。

Web コンソールはマスター上の Pod として実行されます。Web コンソールを実行するために必要な静的なアセットは Pod によって提供されます。また、管理者は拡張を使用して Web コンソールのカスタマイズを実行できます。これにより、Web コンソールによる読み込みの実行時にスクリプトを実行でき、カスタムスタイルシートを読み込むことができます。

ブラウザーから Web コンソールにアクセスする際に、まず必要な静的アセットをすべて読み込みます。次に、openshift start オプションの --public-master で定義される値、openshift-web-console namespace で定義される webconsole-config Config Map の関連パラメーター masterPublicURL で定義される値を使用して、OpenShift Container Platform API に要求を行います。Web コンソールは WebSocket を使用して API サーバーとの継続的な接続を維持し、更新情報を利用可能になる時点で受信します。

図2.1 Web コンソール要求アーキテクチャー

Web コンソールの設定されたホスト名および IP アドレスは、ブラウザーが要求を クロスオリジン の要求とみなす場合でも API サーバーに安全にアクセスできるようにホワイトリスト化されます。異なるホスト名を使用して Web アプリケーションから API サーバーにアクセスするには、openshift start で --cors-allowed-origins オプションを指定するか、または関連するマスター設定ファイルパラメーターの corsAllowedOrigins で指定してホスト名をホワイトリスト化する必要があります。

corsAllowedOrigins パラメーターは設定フィールドで制御されます。値に対してピニングやエスケープは実行されません。以下は、ホスト名を固定し、ドットをエスケープする方法の例を示しています。

corsAllowedOrigins:
- (?i)//my\.subdomain\.domain\.com(:|\z)

Web コンソールのヘルプアイコンから CLI ダウンロードにアクセスできます。

クラスター管理者は、これらのリンクの追加のカスタマイズを実行できます。

OpenShift Container Platform のテスト済みの統合を確認します。

ログイン後、Web コンソールは開発者に現在選択されているプロジェクトの概要を提供します。

図2.2 Web コンソールのプロジェクト概要

Java イメージをベースとする Pod の場合、Web コンソールは関連する統合コンポーネントを表示し、管理するための hawt.io ベースの JVM コンソールへのアクセスを公開します。コンテナーに jolokia という名前のポートがある場合、Connect リンクが Browse → Pods ページの Pod の詳細に表示されます。

図2.3 JVM コンソールへのリンクを持つ Pod

JVM コンソールへの接続後に、接続されている Pod の関連コンポーネントに応じて異なるページが表示されます。

図2.4 JVM コンソール

以下のページが利用可能になります。

StatefulSet コントローラーは Pod の一意のアイデンティティーを提供し、デプロイメントおよびスケーリングの順序を決定します。StatefulSet の使用は一意のネットワーク ID、永続ストレージ、正常なデプロイメントおよびスケーリング、および正常な削除および終了に役立ちます。

図2.5 OpenShift Container Platform の StatefulSet