アーキテクチャー

REST API とのすべての通信チャネル、および etcd および API サーバーなどの マスターコンポーネント 間の通信チャネルは TLS で保護されます。TLS は、X.509 サーバー証明書およびパブリックキーインフラストラクチャーを使用して強力な暗号化、データの整合性、およびサーバーの認証を提供します。デフォルトで、新規の内部 PKI は OpenShift Container Platform のそれぞれのデプロイメントについて作成されます。内部 PKI は 2048 ビット RSA キーおよび SHA-256 署名を使用します。パブリックホストのカスタム証明書もサポートされます。

OpenShift Container Platform は Golang の標準ライブラリーの実装である crypto/tls を使用し、外部の crypto および TLS ライブラリーには依存しません。追加で、外部ライブラリーに依存して、クライアントは GSSAPI 認証および OpenPGP 署名を使用できます。GSSAPI は通常 OpenSSL の libcrypto を使用する MIT Kerberos または Heimdal Kerberos のいずれかによって提供されます。OpenPGP 署名の検証は libgpgme および GnuPG によって処理されます。

セキュアでない SSL 2.0 および SSL 3.0 バージョンは、サポート対象外であり、利用できません。OpenShift Container Platform サーバーおよび oc クライアントはデフォルトで TLS 1.2 のみを提供します。TLS 1.0 および TLS 1.1 はサーバー設定で有効にできます。サーバーおよびクライアントは共に認証される暗号化アルゴリズムと完全な前方秘匿性を持つ最新の暗号スイートを優先的に使用します。暗号スイートと RC4、3DES、および MD5 などの非推奨で、セキュアでないアルゴリズムは無効化されています。また、内部クライアント (LDAP 認証など) によっては、TLS 1.0 から 1.2 設定の制限が少なく、より多くの暗号スイートが有効化されています。

以下は OpenShift Container Platform のサーバーの有効にされた暗号スイートの一覧であり、oc クライアントは優先される順序で並べ替えられます。

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

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

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

2.1.2.1. コントロールプレーンの静的 Pod

コントロールプレーンのコンポーネント、API サーバーおよびコントローラーマネージャーのコンポーネントは、kubelet で操作される 静的 Pod として実行されます。

etcd が同じホストに共存しているマスターでは、etcd も静的 Pod に移動されます。RPM ベースの etcd は依然として、マスターではない etcd ホスト上でサポートされます。

さらに、ノードコンポーネントの openshift-sdn と openvswitch が systemd サービスではなく、DaemonSet を使用して実行されます。

図2.1 コントロールプレーンホストのアーキテクチャーの変更

マスターおよびノードの設定 のトピックに記載されているように、静的 Pod として実行中のコントロールプレーンのコンポーネントの場合でさえも、マスターホストは /etc/origin/master/master-config.yaml ファイルからの設定をソースとして使用します。

起動シーケンスの概要

Hyperkube は、すべての Kubernetes (kube-apiserver、controller-manager、scheduler、proxy、および kubelet) を含むバイナリーです。起動時に、kubelet は kubepods.slice を作成します。次に、kubelet は kubepods.slice 内に QoS レベルのスライス burstable.slice と best-effort.slice を作成します。Pod が開始されると、kubelet は pod<UUID-of-pod>.slice 形式で Pod レベルのスライスを作成し、そのパスを Container Runtime Interface (CRI) の反対側のランタイムに渡します。次に、Docker または CRI-O は、Pod レベルのスライス内にコンテナーレベルのスライスを作成します。

Pod のミラーリング

マスターノード上の kubelet は自動的に、コントロールプレーンの静的 Pod ごとに、API サーバー上に ミラーの Pod を作成し、kube-system プロジェクトのクラスターで表示できるようにします。これらの静的 Pod のマニフェストは、デフォルトで、マスターホスト上の /etc/origin/node/pods ディレクトリーに配置されている openshift-ansible インストーラーによりインストールされます。

これらの Pod は、以下の hostPath ボリュームを定義します。

/etc/origin/master	すべての証明書、設定ファイル、admin.kubeconfig ファイルが含まれます。
/var/lib/origin	バイナリーの潜在的なコアダンプとボリュームが含まれます。
/etc/origin/cloudprovider	クラウドプロバイダー固有の設定 (AWS、Azure など) が含まれます。
/usr/libexec/kubernetes/kubelet-plugins	追加のサードパーティーのボリュームプラグインが含まれます。
/etc/origin/kubelet-plugins	システムコンテナーに向けた追加のサードパーティーのボリュームプラグインが含まれます。

静的 Pod で実行できる一連の操作は制限されています。以下に例を示します。

$ oc logs master-api-<hostname> -n kube-system

API サーバーからの標準出力を返します。ただし、

$ oc delete pod master-api-<hostname> -n kube-system

上記のコマンドでは実際には Pod は削除されません。

別の例として、クラスター管理者は、API サーバーの loglevel を増やすなど、一般的な操作を実行して、問題が発生した場合により詳細なデータを参照できるようにする場合があります。コンテナー内で実行中のプロセスに渡せるように、/etc/origin/master/master.env ファイルを編集して、OPTIONS 変数の --loglevel パラメーターを変更する必要があります。変更を適用するには、コンテナー内で実行中のプロセスを再起動する必要があります。

マスターサービスの再起動

コントロールプレーンの静的 Pod で実行中のコントロールプレーンサービスを再起動するには、マスターホストの master-restart コマンドを使用します。

マスター API を再起動します。

# master-restart api

コントローラーを再起動します。

# master-restart controllers

etcd を再起動します。

# master-restart etcd

マスターサービスログの表示

コントロールプレーンの静的 Pod で実行中のコントロールプレーンサービスのログを表示するには、適切なコンポーネントの master-logs コマンドを使用します。

# master-logs api api

# master-logs controllers controllers

# master-logs etcd etcd

ノードはコンテナーのランタイム環境を提供します。Kubernetes クラスターの各ノードには、マスターで管理される必須のサービスが含まれます。また、ノードには、コンテナーランタイム、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: ""

2.1.3.4. ノードのブートストラップ

ノードの設定はマスターからブートストラップされます。つまり、ノードが事前定義済みの設定、クライアントとサーバーの証明書をマスターからプルします。これにより、ノード間の相違点を減らして、より多くの設定を集約し、クラスターを必要な状態で収束させることで、ノードの起動時間を短縮することができます。 証明書のローテーションや集約された証明書の管理はデフォルトで有効にされます。

図2.2 ノードブートストラップのワークフローに関する概要

ノードサービスの起動時に、ノードは /etc/origin/node/node.kubeconfig ファイルと他のノード設定ファイルが存在するかチェックしてから、クラスターに参加します。存在しない場合には、ノードはマスターから設定をプルしてから、クラスターに参加します。

ConfigMaps は、クラスターにノードの設定を保存するために使用され、ノードホスト上の /etc/origin/node/node-config.yaml で設定ファイルを生成します。デフォルトのノードグループやその ConfigMaps の定義については、クラスターのインストールガイドの ノードグループとホストマッピングの定義 を参照してください。

ノードブートストラップのワークフロー

自動ノードブートストラップのプロセスでは、以下のワークフローを使用します。

1. デフォルトでは、クラスターのインストール時に、clusterrole、clusterrolebinding および serviceaccount オブジェクトのセットが、ノードブートストラップで使用するために作成されます。

   • system:node-bootstrapper クラスターロールは、ノードのブートストラップ時に、証明書署名要求 (CSR) の作成に使用します。

     $ oc describe clusterrole.authorization.openshift.io/system:node-bootstrapper

     出力例

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			kubernetes.io/bootstrapping=rbac-defaults
     Annotations:		authorization.openshift.io/system-only=true
     			openshift.io/reconcile-protect=false
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

   • 以下の node-bootstrapper サービスアカウントを、openshift-infra プロジェクトに作成します。

     $ oc describe sa node-bootstrapper -n openshift-infra

     出力例

     Name:                node-bootstrapper
     Namespace:           openshift-infra
     Labels:              <none>
     Annotations:         <none>
     Image pull secrets:  node-bootstrapper-dockercfg-f2n8r
     Mountable secrets:   node-bootstrapper-token-79htp
                          node-bootstrapper-dockercfg-f2n8r
     Tokens:              node-bootstrapper-token-79htp
                          node-bootstrapper-token-mqn2q
     Events:              <none>

   • 以下の system:node-bootstrapper のクラスターロールのバインディングは、ノードブートストラップのクラスターロールとサービスアカウント向けです。

     $ oc describe clusterrolebindings system:node-bootstrapper

     出力例

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			<none>
     Annotations:		openshift.io/reconcile-protect=false
     Role:			/system:node-bootstrapper
     Users:			<none>
     Groups:			<none>
     ServiceAccounts:	openshift-infra/node-bootstrapper
     Subjects:		<none>
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

2. また、デフォルトでは、クラスターのインストール時に、openshift-ansible のインストーラーにより、OpenShift Container Platform の認証局とその他のさまざまな証明書、鍵、kubeconfig ファイルが /etc/origin/master ディレクトリーに作成されます。注目すべき 2 つのファイルは以下のとおりです。

   /etc/origin/master/admin.kubeconfig	system:admin ユーザーを使用します。
   /etc/origin/master/bootstrap.kubeconfig	マスター以外のノードブートストラップノードに使用します。

   1. /etc/origin/master/bootstrap.kubeconfig は、インストーラーが以下のように node-bootstrapper のサービスアカウントを使用するときに作成されます。

      $ oc --config=/etc/origin/master/admin.kubeconfig \
          serviceaccounts create-kubeconfig node-bootstrapper \
          -n openshift-infra

   2. マスターノードでは、ブートストラップファイルとして /etc/origin/master/admin.kubeconfig を使用し、/etc/origin/node/boostrap.kubeconfig にコピーされます。他のマスター以外のノードでは、/etc/origin/master/bootstrap.kubeconfig ファイルは、他のノードすべてに対して、各ノードホストごとに /etc/origin/node/boostrap.kubeconfig にコピーされます。

   3. 次に、/etc/origin/master/bootstrap.kubeconfig は、以下のように、フラグ --bootstrap-kubeconfig を使用して kubelet に渡されます。

      --bootstrap-kubeconfig=/etc/origin/node/bootstrap.kubeconfig

3. kubelet は、指定の /etc/origin/node/bootstrap.kubeconfig ファイルで先に起動します。内部での初期接続後に、kubelet は証明書署名要求 (CSR) を作成して、マスターに送信します。

4. CSR はコントローラーマネージャーを使用して検証、承認されます (特に、証明署名コントローラー)。承認された場合には、kubelet クライアントとサーバー証明書は /etc/origin/node/ceritificates ディレクトリーに作成されます。以下に例を示します。

   # ls -al /etc/origin/node/certificates/

   出力例

   total 12
   drwxr-xr-x. 2 root root  212 Jun 18 21:56 .
   drwx------. 4 root root  213 Jun 19 15:18 ..
   -rw-------. 1 root root 2826 Jun 18 21:53 kubelet-client-2018-06-18-21-53-15.pem
   -rw-------. 1 root root 1167 Jun 18 21:53 kubelet-client-2018-06-18-21-53-45.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:53 kubelet-client-current.pem -> /etc/origin/node/certificates/kubelet-client-2018-06-18-21-53-45.pem
   -rw-------. 1 root root 1447 Jun 18 21:56 kubelet-server-2018-06-18-21-56-52.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:56 kubelet-server-current.pem -> /etc/origin/node/certificates/kubelet-server-2018-06-18-21-56-52.pem

5. CSR の承認後に、node.kubeconfig ファイルが /etc/origin/node/node.kubeconfig に作成されます。
6. kubelet は、/etc/origin/node/certificates/ ディレクトリーにある /etc/origin/node/node.kubeconfig ファイルと証明書で再起動されます。 再起動後に、クラスターへの参加の準備ができます。

ノード設定のワークフロー

ノードの設定を取得するには、以下のワークフローを使用します。

1. 最初に、ノードの kubelet は、/etc/origin/node/ ディレクトリーにあるブートストラップの設定ファイル bootstrap-node-config.yaml を使用して起動され、ノードのプロビジョニング時に作成されます。
2. 各ノードで、ノードサービスファイルは、/usr/local/bin/ ディレクトリーにあるローカルスクリプト openshift-node を使用して、指定の bootstrap-node-config.yaml で kubelet を起動します。
3. マスターごとに、/etc/origin/node/pods ディレクトリーには、マスターに静的 Pod として作成された apiserver、controller および etcd の Pod のマニフェストが含まれます。

4. クラスターのインストール時に、sync DaemonSet が作成され、ノードごとに同期 Pod を作成します。同期 Pod は、/etc/sysconfig/atomic-openshift-node ファイル内の変更をモニターリングします。特に、設定される BOOTSTRAP_CONFIG_NAME を監視します。BOOTSTRAP_CONFIG_NAME は、openshift-ansible インストーラーにより設定され、対象のノードが所属するノード設定グループをもとにした ConfigMap の名前です。

   デフォルトでは、インストーラーは以下のノード設定グループを作成します。

   • node-config-master
   • node-config-infra
   • node-config-compute
   • node-config-all-in-one
   • node-config-master-infra

   各グループの ConfigMap は openshift-node プロジェクトに作成されます。

5. 同期 Pod は、BOOTSTRAP_CONFIG_NAME の値セットを基に適切な ConfigMap を抽出します。
6. 同期 Pod は kubelet 設定に ConfigMap データを変換し、対象のノードホスト用に /etc/origin/node/node-config.yaml を作成します。このファイルに変更が加えられると (またはファイルが初めて作成される場合には)、kubelet が再起動されます。

ノード設定の変更

ノードの設定は、openshift-node プロジェクトの適切な ConfigMap を編集して変更します。/etc/origin/node/node-config.yaml は直接変更しないでください。

たとえば、node-config-compute グループに含まれるノードの場合は、以下のコマンドを使用して ConfigMap を編集します。

$ oc edit cm node-config-compute -n openshift-node

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

OpenShift Container Platform には OpenShift Container レジストリー (OCR) という統合コンテナーイメージレジストリーがあり、新規イメージリポジトリーのプロビジョニングをオンデマンドで自動化できるようになります。この OCR を使用することで、アプリケーションビルドの組み込まれた保管場所が用意され、作成されたイメージをプッシュできます。

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

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

OpenShift Container Platform はサードパーティーレジストリーからのイメージを使用してコンテナーを作成できますが、これらのレジストリーは統合 OpenShift Container Platform レジストリーと同じイメージ通知のサポートを提供する訳ではありません。このため、OpenShift Container Platform はイメージストリームの作成時にリモートレジストリーからタグをフェッチします。フェッチされたタグの更新は、oc import-image <stream> を実行するだけで簡単に実行できます。新規イメージが検出されると、以前に記述されたビルドとデプロイメントの応答が生じます。

エンタープライズ向けの高品質なコンテナーイメージレジストリーを必要とされる場合、Red Hat Quay をホストされたサービスとして、また独自のデータセンターやクラウド環境にインストールするソフトウェアとしてご利用いただけます。Red Hat Quay の高度なレジストリーには、geo レプリケーション、イメージのスキャニング、およびイメージのロールバック機能が含まれます。

Quay.io サイトにアクセスし、独自のホストされる Quay レジストリーアカウントをセットアップします。その後、Quay チュートリアル に従って Quay レジストリーにログインし、イメージの管理を開始します。または、独自の Red Hat Quay レジストリーをセットアップする方法についての詳細は、Red Hat Quay のスタートガイド を参照してください。

Red Hat Quay レジストリーへのアクセスは、任意のリモートコンテナーイメージレジストリーと同様に OpenShift Container Platform から実行できます。Red Hat Quay にアクセスするための認証情報をセキュリティー保護されたレジストリーとしてセットアップする方法については、Allowing Pods to Reference Images from Other Secured Registriesを参照してください。

Red Hat Container Catalog で利用可能なすべてのコンテナーイメージはイメージレジストリーの registry.access.redhat.com でホストされます。OpenShift Container Platform 3.11 では、Red Hat Container Catalog は registry.access.redhat.com から registry.redhat.io に移行しました。

新規レジストリーの registry.redhat.io ではイメージおよび OpenShift Container Platform でホストされるコンテンツへのアクセスに認証が必要になります。新規レジストリーへの移行後も、既存レジストリーはしばらく利用可能になります。

新規レジストリーは、以下の方法を使用して認証に標準の OAuth メカニズムを使用します。

ユーザー名またはパスワード、または認証トークンのいずれかの認証情報を使用して docker login を使用し、新規レジストリーのコンテンツにアクセスします。

すべてのイメージストリームは新規レジストリーを参照します。新規レジストリーにはアクセスに認証が必要となるため、OpenShift namespace には imagestreamsecret という新規シークレットがあります。

認証情報は 2 つの場所に配置する必要があります。

新規レジストリーにアクセスするには、以下を実行します。

OpenShift Container Platform Web コンソールは、Web ブラウザーからアクセスできるユーザーインターフェイスです。開発者は Web コンソールを使用して プロジェクト のコンテンツを視覚的に把握し、参照し、管理することができます。

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

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

図2.3 sWeb コンソール要求アーキテクチャー

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

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

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

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

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

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

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

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

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

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

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

図2.6 JVM コンソール

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

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

図2.7 OpenShift Container Platform の StatefulSet

OpenShift Container Platform アプリケーションの基本的な単位は コンテナー と呼ばれています。Linux コンテナーテクノロジー は、指定されたリソースのみと対話するために実行中のプロセスを分離する軽量なメカニズムです。

数多くのアプリケーションインスタンスは、相互のプロセス、ファイル、ネットワークなどを可視化せずに単一ホストのコンテナーで実行される可能性があります。通常、コンテナーは任意のワークロードに使用されますが、各コンテナーは Web サーバーまたはデータベースなどの (通常はマイクロサービスと呼ばれることの多い) 単一サービスを提供します。

Linux カーネルは数年にわたりコンテナーテクノロジーの各種機能を統合してきました。最近では、Docker プロジェクトはホストで Linux コンテナーの便利な管理インターフェイスを開発しました。OpenShift Container Platform および Kubernetes は複数ホストのインストール間で Docker 形式のコンテナーのオーケストレーションを実行する機能を追加します。

OpenShift Container Platform の使用時に Docker CLI と直接対話することはないものの、それらの機能および用語を理解しておくことは、OpenShift Container Platform のロールやアプリケーションのコンテナー内での機能を理解する上で重要です。docker RPM は RHEL 7、CentOS および Fedora の一部として利用できるため、これを OpenShift Container Platform とは別に実験的に使用することができます。ガイド付きの情報については、Get Started with Docker Formatted Container Images on Red Hat Systems という記事を参照してください。

OpenShift Container Platform のコンテナーは Docker 形式のコンテナーの イメージ をベースにしています。イメージは、単一コンテナーを実行するためのすべての要件、およびそのニーズおよび機能を記述するメタデータを含むバイナリーです。

これはパッケージ化テクノロジーとして考えることができます。コンテナーには、作成時にコンテナーに追加のアクセスを付与しない限り、イメージで定義されるリソースにのみアクセスできます。同じイメージを複数のホストにまたがって複数のコンテナーにデプロイし、それらの間で負荷を分散することにより、OpenShift Container Platform はイメージにパッケージ化されたサービスの冗長性および水平的なスケーリングを提供できます。

Docker CLI を直接使用してイメージをビルドすることができますが、OpenShift Container Platform はコードおよび設定を既存イメージに追加して新規イメージの作成を支援するビルダーイメージも提供します。

アプリケーションは一定期間をかけて開発されるため、単一のイメージ名が同じイメージの数多くの異なるバージョンを参照する場合があります。それぞれの異なるイメージは、通常は 12 文字 (例: fd44297e2ddb) に省略されるそのハッシュ (fd44297e2ddb050ec4f…​ などの長い 16 進数) で一意に参照されます。

イメージバージョンタグポリシー

バージョン番号ではなく、Docker サービスはタグ (v1、v2.1、GA、またはデフォルト latest) を必要なイメージを指定するためのイメージ名に追加して適用するため、同じイメージが centos (これは latest タグを意味します)、centos:centos7、または fd44297e2ddb として参照される場合があります。

イメージへのタグの付け方は更新ポリシーを定めます。より具体的なタグを使用すると、イメージが更新される頻度は低くなります。以下を使用して選択した OpenShift Container Platform イメージポリシーを決定します。

コンテナーイメージレジストリーは Docker 形式のコンテナーイメージの保存および取得を行うサービスです。レジストリーには、1 つ以上のイメージリポジトリーのコレクションが含まれます。それぞれのイメージレジストリーには、1 つ以上のタグ付けされたイメージが含まれます。Docker は独自のレジストリーである Docker Hub を提供しますが、プライベートまたはサードパーティーのレジストリーを使用することもできます。Red Hat はサブスクリプションをお持ちのお客様に対し、registry.redhat.io にてレジストリーを提供しています。また、OpenShift Container Platform はカスタムコンテナーイメージを管理するための独自の内部レジストリーも提供しています。

以下の図では、コンテナー、イメージ、およびレジストリー間の関係が描写されています。

OpenShift Container Platform は、pod の Kubernetes の概念を活用しています。これはホスト上に共にデプロイされる 1 つ以上の コンテナー であり、定義され、デプロイされ、管理される最小のコンピュート単位です。

Pod はコンテナーに対するマシンインスタンス (物理または仮想) とほぼ同等のものです。各 Pod には独自の内部 IP アドレスが割り当てられるため、そのポートスペース全体を所有し、Pod 内のコンテナーはそれらのローカルストレージおよびネットワークを共有できます。

Pod にはライフサイクルがあります。それらは定義された後にノードで実行されるために割り当てられ、コンテナーが終了するまで実行されるか、その他の理由でコンテナーが削除されるまで実行されます。ポリシーおよび終了コードによっては、Pod は終了後に削除されるか、コンテナーのログへのアクセスを有効にするために保持される可能性があります。

OpenShift Container Platform は Pod をほとんどがイミュータブルなものとして処理します。Pod が実行中の場合は Pod に変更を加えることができません。OpenShift Container Platform は既存 Pod を終了し、これを変更された設定、ベースイメージのいずれかまたはその両方で再作成して変更を実装します。OpenShift Container Platform は既存 Pod を終了し、これを変更された設定、ベースイメージのいずれかまたはその両方で再作成して変更を実装します。そのため、通常 Pod はユーザーから直接管理されるのでははく、ハイレベルの コントローラー で管理される必要があります。

以下は Pod のサンプル定義です。これは数多くの Pod の機能を示していますが、それらのほとんどは他のトピックで説明されるため、ここではこれらについて簡単に説明します。

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }
  labels:                                1
    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-       2
spec:
  containers:                            3
  - env:                                 4
    - name: OPENSHIFT_CA_DATA
      value: ...
    - name: OPENSHIFT_CERT_DATA
      value: ...
    - name: OPENSHIFT_INSECURE
      value: "false"
    - name: OPENSHIFT_KEY_DATA
      value: ...
    - name: OPENSHIFT_MASTER
      value: https://master.example.com:8443
    image: openshift/origin-docker-registry:v0.6.2 5
    imagePullPolicy: IfNotPresent
    name: registry
    ports:                              6
    - containerPort: 5000
      protocol: TCP
    resources: {}
    securityContext: { ... }            7
    volumeMounts:                       8
    - mountPath: /registry
      name: registry-storage
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-br6yz
      readOnly: true
  dnsPolicy: ClusterFirst
  imagePullSecrets:
  - name: default-dockercfg-at06w
  restartPolicy: Always                 9
  serviceAccount: default               10
  volumes:                              11
  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

init コンテナーは、Pod アプリコンテナーが起動する前に起動する Pod のコンテナーです。Init コンテナーはボリュームを共有し、ネットワーク操作を実行し、計算を実行してから残りのコンテナーを起動します。Init コンテナーは一部の条件が満たされるまでアプリケーションの起動をブロックしたり、遅延させたりすることもできます。

Pod の起動時でボリュームの初期化後に、init コンテナーは順番に起動します。各 init コンテナーは、次のコンテナーが起動する前に正常に終了する必要があります。init コンテナーが (ランタイムを原因に) 起動に失敗するか、または失敗して終了する場合、これは Pod の 再起動ポリシーに基づいてリタイアします。

Pod は init コンテナーがすべて成功するまで準備状態になりません。

一部の init コンテナーの使用例については、Kubernetes ドキュメントを参照してください。

以下の例は、2 つの init コンテナーを持つ単純な Pod の概要を示しています。最初の init コンテナーは myservice を待機し、2 つ目は mydb を待機します。両方のコンテナーに成功すると、Pod は起動します。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice 1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb 2
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

各 init コンテナーには、readinessProbe を除くすべての アプリコンテナーのフィールド が含まれます。Pod の起動を継続するには、Init コンテナーは終了している必要があり、完了 (completion) 以外の readiness を定義することはできません。

Init コンテナーには Pod の activeDeadlineSeconds およびコンテナーの livenessProbe を含めることができ、init コンテナーの永久的な失敗を防ぐことができます。有効な期限には init コンテナーで使用される時間が含まれます。

Kubernetes サービス は内部ロードバランサーとして機能します。これは、受信する接続をプロキシー送信するために一連のレプリケートされた Pod を特定します。バッキング Pod は、サービスが一貫して利用可能な状態の間に任意でサービスに追加されたり、削除されたりします。これにより、サービスに依存して同じアドレスの Pod を参照するすべてのものを有効にします。 デフォルトのサービス clusterIP アドレスは OpenShift Container Platform 内部ネットワークからのもので、Pod が相互にアクセスできるように使用されます。

サービスへの外部アクセスを許可するには、クラスターの外部にある追加の externalIP および ingressIP アドレスをサービスに割り当てることができます。これらの externalIP アドレスを、サービスへの高可用性のあるアクセスを提供する仮想 IP アドレスにすることもできます。

サービスには IP アドレスとポートのペアが割り当てられるため、アクセスされる際に、適切なバッキングポートにプロキシー送信されます。サービスは、ラベルセレクターを使用して特定ポートで特定のネットワークサービスを提供する実行中のすべてのコンテナーを見つけます。

Pod と同様に、サービスは REST オブジェクトです。以下の例は、上記の定義された Pod のサービス定義を示しています。

apiVersion: v1
kind: Service
metadata:
  name: docker-registry      1
spec:
  selector:                  2
    docker-registry: default
  clusterIP: 172.30.136.123   3
  ports:
  - nodePort: 0
    port: 5000               4
    protocol: TCP
    targetPort: 5000         5

Kubernetes ドキュメント には、サービスについての詳細が記載されています。

networkConfig:
  externalIPNetworkCIDRs:
  - 192.0.1.0.0/24

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "name": "http",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ],
        "externalIPs" : [
            "192.0.1.1"         1
        ]
    }
}

networkConfig:
  ingressIPNetworkCIDR: 172.29.0.0/16

kubernetesMasterConfig:
  servicesNodePortRange: ""

$ oc get pods -o wide

NAME               READY  STATUS    RESTARTS   AGE    IP            NODE
frontend-1-287hw   1/1    Running   0          7m     172.17.0.3    node_1
frontend-1-68km5   1/1    Running   0          7m     172.17.0.6    node_1

apiVersion: v1
kind: Service
metadata:
  labels:
    app: ruby-helloworld-sample
    template: application-template-stibuild
  name: frontend-headless 1
spec:
  clusterIP: None 2
  ports:
  - name: web
    port: 5432
    protocol: TCP
    targetPort: 8080
  selector:
    name: frontend 3
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

$ oc get svc

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
frontend            ClusterIP   172.30.232.77    <none>        5432/TCP   12m
frontend-headless   ClusterIP   None             <none>        5432/TCP   10m

$ dig frontend.test A +search +short

172.30.232.77

$ dig frontend-headless.test A +search +short

172.17.0.3
172.17.0.6

ラベルは、API オブジェクトを編成し、分類し、選択するために使用されます。たとえば、Pod にはラベルでタグ付けされてから、サービス はラベルセレクターを使用してそれらがプロキシー送信する Pod を識別します。これにより、サービスが Pod のグループを参照することを可能にし、Pod を関連エンティティーとして異なるコンテナーで処理することもできます。

ほとんどのオブジェクトには、そのメタデータにラベルを組み込むことができます。そのため、ラベルは任意で関連付けられたオブジェクトを分類するために使用できます。 たとえば、特定アプリケーションのすべての Pod、サービス、レプリケーションコントローラー、および デプロイメント設定 を分類できます。

ラベルは、以下の例にあるように単純なキー/値のペアです。

labels:
  key1: value1
  key2: value2

以下を検討してください。

role=webserver ラベルを持つ Pod を使用するために定義されるサービスまたはレプリケーションコントローラーはこれらの Pod のいずれも同じグループの一部として処理します。

Kubernetes ドキュメント には、ラベルについての詳細が記載されています。

サービスをサポートするサーバーはそのエンドポイントと呼ばれ、サービスと同じ名前を持つタイプ Endpoints のオブジェクトで指定されます。サービスが Pod でサポートされる場合、それらの Pod は通常はサービス仕様のラベルセレクターで指定され、OpenShift Container Platform はそれらの Pod をポイントするエンドポイントオブジェクトを自動的に作成します。

場合によっては、サービスを作成する場合でも、OpenShift Container Platform クラスターの Pod ではなく、外部ホストでサポートされるようにする必要があります。この場合、サービスの selector フィールドを省略し、エンドポイントオブジェクトを手動で作成 できます。

OpenShift Container Platform は、大半のユーザーが Pod およびサービス用に予約されたネットワークブロックの IP アドレスを参照するエンドポイントオブジェクトの手動による作成を許可しないことに注意してください。endpoints/restricted のリソースの create パーミッション を持つクラスター管理者その他ユーザーのみがこれらのエンドポイントオブジェクトを作成できます。

OpenShift Container Platform との対話はユーザーに関連付けられます。OpenShift Container Platform ユーザーオブジェクトはシステム内のパーミッションを付与されるアクターを表します。 パーミッションは ロールをそれらまたはそれらのグループに追加して付与されます。

ユーザーにはいくつかのタイプが存在します。

すべてのユーザーには、OpenShift Container Platform にアクセスするために何らかの認証が必要になります。認証がないか、無効な認証を持つ API 要求は、匿名 システムユーザーによって要求される際に認証されます。認証が実行されると、認可されている ユーザーの実行内容がポリシーによって決定されます。

Kubernetes namespace はクラスターのリソースのスコープを設定するメカニズムを提供します。OpenShift Container Platform では、プロジェクトは追加のアノテーションを含む Kubernetes namespace です。

Namespace は以下の一意のスコープを提供します。

システム内の大半のオブジェクトのスコープは namespace で設定されますが、一部はノードやユーザーを含め、除外され、namaspace が設定されません。

namespace の詳細は、Kubernetes ドキュメント を参照してください。

プロジェクトは追加のアノテーションを持つ Kubernetes namespace であり、通常ユーザーのリソースへのアクセスが管理される中心的な手段です。プロジェクトはユーザーのコミュニティーが他のコミュニティーとは切り離してコンテンツを編成し、管理することを許可します。ユーザーには、管理者によってプロジェクトへのアクセスが付与される必要があり、許可される場合はプロジェクトを作成でき、それらの独自のプロジェクトへのアクセスが自動的に付与されます。

プロジェクトには、別個の 名前、displayName、および 説明 を含めることができます。

各プロジェクトは、以下の独自のセットのスコープを設定します。

クラスター管理者は プロジェクトを作成 でき、プロジェクトの管理者権限をユーザーコミュニティーの任意のメンバーに委任できます。クラスター管理者は、開発者が独自のプロジェクトを作成することも許可できます。

開発者および管理者は、CLI または Web コンソール を使用して プロジェクトとの対話 を実行できます。

ビルド とは、入力パラメーターを結果として作成されるオブジェクトに変換するプロセスです。ほとんどの場合、このプロセスは入力パラメーターまたはソースコードを実行可能なイメージに変換するために使用されます。BuildConfig オブジェクトはビルドプロセス全体の定義です。

OpenShift Container Platform は、Docker 形式のコンテナーをビルドイメージから作成し、それらをコンテナーイメージレジストリーにプッシュして Kubernetes を利用します。

ビルドオブジェクトは共通の特性を共有します。これらには、ビルドの入力、ビルドプロセスを完了する必要性、ビルドプロセスのロギング、正常なビルドからのリリースのパブリッシュ、およびビルドの最終ステータスのパブリッシュが含まれます。ビルドはリソースの制限を利用し、CPU 使用、メモリー使用およびビルドまたは Pod の実行時間などのリソースの制限を指定します。

OpenShift Container Platform ビルドシステムは、ビルド API で指定される選択可能なタイプに基づくビルドストラテジー を幅広くサポートします。利用可能なビルドストラテジーは主に 3 つあります。

デフォルトで、Docker ビルドおよび S2I ビルドがサポートされます。

ビルドの結果作成されるオブジェクトはこれを作成するために使用されるビルダーによって異なります。Docker および S2I ビルドの場合、作成されるオブジェクトは実行可能なイメージです。カスタムビルドの場合、作成されるオブジェクトはビルダーイメージの作成者が指定するものになります。

さらに、Pipeline ビルド ストラテジーを使用して、高度なワークフローを実装することができます。

ビルドコマンドの一覧については、開発者ガイド を参照してください。

OpenShift Container Platform の Docker を使用したビルドについての詳細は、アップストリームドキュメントを参照してください。

イメージストリームおよびその関連付けられたタグは、OpenShift Container Platform 内で コンテナーイメージ を参照するための抽象化を提供します。イメージストリームとそのタグを使用して、利用可能なイメージを確認し、リポジトリーのイメージが変更される場合でも必要な特定のイメージを使用していることを確認できます。

イメージストリームには実際のイメージデータは含まれませんが、イメージリポジトリーと同様に、関連するイメージの単一の仮想ビューが提示されます。

ビルド および デプロイメント をそれぞれ実行し、ビルドおよびデプロイメントを、新規イメージが追加される際やこれに対応する際の通知をイメージストリームで確認できるように設定できます。

たとえば、デプロイメントで特定のイメージを使用しており、そのイメージの新規バージョンを作成する場合に、対象のイメージの新しいバージョンが選択されるように、デプロイメントを自動的に実行することができます。

デプロイメントまたはビルドで使用するイメージストリームタグが更新されない場合には、コンテナーイメージレジストリーのコンテナーイメージが更新されても、ビルドまたはデプロイメントは以前の (既知でおそらく適切であると予想される) イメージをそのまま使用します。

ソースイメージは以下のいずれかに保存できます。

(ビルドまたはデプロイメント設定などの) イメージストリームタグを参照するオブジェクトを定義する場合には、Docker リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、OpenShift Container Platform がこのイメージストリームタグを使用して Docker リポジトリーにクエリーを送信して、対象のイメージに関連付けられた ID を特定して、正確なイメージを使用します。

イメージストリームメタデータは他のクラスター情報と共に etcd インスタンスに保存されます。

以下のイメージストリームには、Python v3.4 イメージをポイントする 34 と、Python v3.5 イメージをポイントする 35 の 2 つのタグが含まれます。

$ oc describe is python

Name:			python
Namespace:		imagestream
Created:		25 hours ago
Labels:			app=python
Annotations:		openshift.io/generated-by=OpenShiftWebConsole
			openshift.io/image.dockerRepositoryCheck=2017-10-03T19:48:00Z
Docker Pull Spec:	docker-registry.default.svc:5000/imagestream/python
Image Lookup:		local=false
Unique Images:		2
Tags:			2

34
  tagged from centos/python-34-centos7

  * centos/python-34-centos7@sha256:28178e2352d31f240de1af1370be855db33ae9782de737bb005247d8791a54d0
      14 seconds ago

35
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:2efb79ca3ac9c9145a63675fb0c09220ab3b8d4005d35e0644417ee552548b10
      7 seconds ago

イメージストリームの使用には、いくつかの大きな利点があります。

イメージストリームのキュレートされたセットについては、OpenShift Image Streams and Templates library を参照してください。

イメージストリームの使用時に、イメージストリームタグのポイント先およびタグおよびイメージへの変更の影響について把握しておくことは重要デス。以下に例を示します。

docker.io/openshift/jenkins-2-centos7:3.6.0

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  creationTimestamp: 2017-09-29T13:33:49Z
  generation: 1
  labels:
    app: ruby-sample-build
    template: application-template-stibuild
  name: origin-ruby-sample 1
  namespace: test
  resourceVersion: "633"
  selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
  uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
  dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample 2
  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d 3
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5 4
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest 5

<image-stream-name>@<image-id>

origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest

<image stream name>:<tag>

origin-ruby-sample:latest

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

apiVersion: v1
kind: ImageStreamMapping
metadata:
  creationTimestamp: null
  name: origin-ruby-sample
  namespace: test
tag: latest
image:
  dockerImageLayers:
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
    size: 196634330
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
    size: 177723024
  - name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
    size: 55679776
  - name: sha256:92114219a04977b5563d7dff71ec4caa3a37a15b266ce42ee8f43dba9798c966
    size: 11939149
  dockerImageMetadata:
    Architecture: amd64
    Config:
      Cmd:
      - /usr/libexec/s2i/run
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Labels:
        build-date: 2015-12-23
        io.k8s.description: Platform for building and running Ruby 2.2 applications
        io.k8s.display-name: 172.30.56.218:5000/test/origin-ruby-sample:latest
        io.openshift.build.commit.author: Ben Parees <bparees@users.noreply.github.com>
        io.openshift.build.commit.date: Wed Jan 20 10:14:27 2016 -0500
        io.openshift.build.commit.id: 00cadc392d39d5ef9117cbc8a31db0889eedd442
        io.openshift.build.commit.message: 'Merge pull request #51 from php-coder/fix_url_and_sti'
        io.openshift.build.commit.ref: master
        io.openshift.build.image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
        io.openshift.build.source-location: https://github.com/openshift/ruby-hello-world.git
        io.openshift.builder-base-version: 8d95148
        io.openshift.builder-version: 8847438ba06307f86ac877465eadc835201241df
        io.openshift.s2i.scripts-url: image:///usr/libexec/s2i
        io.openshift.tags: builder,ruby,ruby22
        io.s2i.scripts-url: image:///usr/libexec/s2i
        license: GPLv2
        name: CentOS Base Image
        vendor: CentOS
      User: "1001"
      WorkingDir: /opt/app-root/src
    Container: 86e9a4a3c760271671ab913616c51c9f3cea846ca524bf07c04a6f6c9e103a76
    ContainerConfig:
      AttachStdout: true
      Cmd:
      - /bin/sh
      - -c
      - tar -C /tmp -xf - && /usr/libexec/s2i/assemble
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Hostname: ruby-sample-build-1-build
      Image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
      OpenStdin: true
      StdinOnce: true
      User: "1001"
      WorkingDir: /opt/app-root/src
    Created: 2016-01-29T13:40:00Z
    DockerVersion: 1.8.2.fc21
    Id: 9d7fd5e2d15495802028c569d544329f4286dcd1c9c085ff5699218dbaa69b43
    Parent: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
    Size: 441976279
    apiVersion: "1.0"
    kind: DockerImage
  dockerImageMetadataVersion: "1.0"
  dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

$ oc describe is/<image-name>

$ oc describe is/python

Name:			python
Namespace:		default
Created:		About a minute ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			1

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

$ oc describe istag/<image-stream>:<tag-name>

$ oc describe istag/python:latest

Image Name:	sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Docker Image:	centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Name:		sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Created:	2 minutes ago
Image Size:	251.2 MB (first layer 2.898 MB, last binary layer 72.26 MB)
Image Created:	2 weeks ago
Author:		<none>
Arch:		amd64
Entrypoint:	container-entrypoint
Command:	/bin/sh -c $STI_SCRIPTS_PATH/usage
Working Dir:	/opt/app-root/src
User:		1001
Exposes Ports:	8080/tcp
Docker Labels:	build-date=20170801

oc tag <image-name:tag> <image-name:tag>

$ oc tag python:3.5 python:latest

Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.

$ oc describe is/python

Name:			python
Namespace:		default
Created:		5 minutes ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			2

latest
  tagged from python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      5 minutes ago

$ oc tag <repositiory/image> <image-name:tag>

$ oc tag docker.io/python:3.6.0 python:3.6

Tag python:3.6 set to docker.io/python:3.6.0.

$ oc tag <image-name:tag> <image-name:latest>

$ oc tag python:3.6 python:latest

Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.

$ oc tag -d <image-name:tag>

$ oc tag -d python:3.5

Deleted tag default/python:3.5.

$ oc tag <repositiory/image> <image-name:tag> --scheduled

$ oc tag docker.io/python:3.6.0 python:3.6 --scheduled

Tag python:3.6 set to import docker.io/python:3.6.0 periodically.

$ oc tag <repositiory/image> <image-name:tag>

レプリケーションコントローラー は、指定した Pod のレプリカ数が常に実行されていることを確認します。Pod の終了または削除が行われた場合に、レプリケーションコントローラーが機能し、定義した数になるまでインスタンス化する数を増やします。同様に、必要以上の数の Pod が実行されている場合には、定義された数に一致させるために必要な数の Pod を削除します。

レプリケーションコントローラー設定は以下で設定されています。

セレクターは、レプリケーションコントローラーが管理する Pod に割り当てられるラベルセットです。これらのラベルは、Pod 定義に組み込まれ、レプリケーションコントローラーがインスタンス化します。レプリケーションコントローラーは、必要に応じて調節するために、セレクターを使用して、すでに実行中の Pod 数を判断します。

レプリケーションコントローラーは、追跡もしませんが、負荷またはトラフィックに基づいて自動スケーリングを実行することもありません。この場合、そのレプリカ数が外部の自動スケーラーで調整される必要があります。

レプリケーションコントローラーは、ReplicationController というコアの Kubernetes オブジェクトです。

以下は、ReplicationController 定義のサンプルです。

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

レプリケーションコントローラー と同様に、レプリカセットで、指定数の Pod レプリカが特定の時間実行されるようにします。レプリカセットとレプリケーションコントローラーの相違点は、レプリカセットではセットベースのセレクター要件をサポートし、レプリケーションコントローラーは等価ベースのセレクター要件のみをサポートする点です。

レプリカセットは、ReplicaSet と呼ばれるコアの Kubernetes オブジェクトです。

以下は、ReplicaSet 定義のサンプルです。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

ジョブは、その目的が特定の理由のために Pod を作成することである点でレプリケーションコントローラーと似ています。違いは、レプリケーションコントローラーの場合は、継続的に実行されている Pod を対象としていますが、ジョブは 1 回限りの Pod を対象としています。ジョブは正常な完了を追跡し、指定された完了数に達すると、ジョブ自体が完了します。

以下の例は、π (Pi) を 2000 桁計算し、これを出力してから完了します。

apiVersion: extensions/v1
kind: Job
metadata:
  name: pi
spec:
  selector:
    matchLabels:
      app: pi
  template:
    metadata:
      name: pi
      labels:
        app: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

ジョブの使用方法についての詳細は、ジョブのトピックを参照してください。

レプリケーションコントローラーでビルドする OpenShift Container Platform はデプロイメントの概念を使用したソフトウェアの開発およびデプロイメントライフサイクルの拡張サポートを追加します。最も単純な場合に、デプロイメントは新規アプリケーションコントローラーのみを作成し、それに Pod を起動させます。ただし、OpenShift Container Platform デプロイメントは、イメージの既存デプロイメントから新規デプロイメントに移行する機能を提供し、レプリケーションコントローラーの作成前後に実行するフックも定義します。

OpenShift Container Platform DeploymentConfig オブジェクトはデプロイメントの以下の詳細を定義します。

デプロイヤー Pod は、デプロイメントがトリガーされるたびに、手動または自動であるかを問わず、(古いレプリケーションコントローラーの縮小、新規レプリケーションコントローラーの拡大およびフックの実行などの) デプロイメントを管理します。デプロイメント Pod は、デプロイメントのログを維持するためにデプロイメントの完了後は無期限で保持されます。デプロイメントが別のものに置き換えられる場合、以前のレプリケーションコントローラーは必要に応じて簡単なロールバックを有効にできるように保持されます。

デプロイメントの作成およびその対話方法についての詳細は、デプロイメント を参照してください。

以下は、いくつかの省略およびコールアウトを含む DeploymentConfig 定義のサンプルです。

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

テンプレートでは、パラメーター化や処理が可能な一連のオブジェクトを記述し、OpenShift Container Platform で作成するための オブジェクト の一覧を生成します。作成するオブジェクトには、ユーザーがプロジェクト内で作成するパーミッションを持つすべてのものが含まれます。たとえば、サービス、ビルド設定、および デプロイメント設定 が含まれます。また、テンプレートでは ラベル のセットを定義して、これをテンプレート内に定義されたすべてのオブジェクトに適用できます。

テンプレートの作成および使用についての詳細は、テンプレートについてのガイド を参照してください。

認証層は、OpenShift Container Platform API への要求に関連付けられたユーザーを識別します。次に、認可層は要求が許可されるかどうかを判別するために要求側のユーザーについての情報を使用します。

管理者として、マスター設定ファイルを使用して、認証の設定を実行できます。

OpenShift Container Platform の ユーザー は、OpenShift Container Platform API に要求できるエンティティーです。通常、これは OpenShift Container Platform と対話している開発者または管理者のアカウントを表します。

ユーザーは 1 つ以上の グループ に割り当てることができます。それぞれのグループはユーザーの特定のセットを表します。グループは、認可ポリシーを管理 し、個々のユーザーにではなく、一度に複数ユーザーにパーミッションを付与する場合などに役立ちます。たとえば、アクセスをユーザーに個別に付与するのではなく、プロジェクト 内の複数の オブジェクト に対するアクセスを許可できます。

明示的に定義されるグループのほかにも、システムグループまたは 仮想グループ が OpenShift で自動的にプロビジョニングされます。これらは、クラスターのバインディングを表示 する際に確認できます。

仮想グループのデフォルトセットでは、とくに以下の点に留意してください。

OpenShift Container Platform API への要求は以下の方法で認証されます。

無効なアクセストークンまたは無効な証明書での要求は認証層によって拒否され、401 エラーが出されます。

アクセストークンまたは証明証が提供されない場合、認証層は system:anonymous 仮想ユーザーおよび system:unauthenticated 仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。

$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>

$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth

OpenShift Container Platform マスターには、組み込まれた OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。

新しい OAuth のトークンが要求されると、OAuth サーバーは設定済みの アイデンティティプロバイダー を使用して要求したユーザーのアイデンティティーを判別します。

次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセスユーザーを作成し、使用できるようにトークンを返します。

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')

serviceaccounts.openshift.io/oauth-redirecturi.<name>

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

$ oc get events | grep ServiceAccount

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

$ oc describe sa/proxy | grep -A5 Events

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

{
  "issuer": "https://<master>", 1
  "authorization_endpoint": "https://<master>/oauth/authorize", 2
  "token_endpoint": "https://<master>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 1
/ -H "X-CSRF-Token: xxx" 2

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 1
< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 1
-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 2

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

Role-based Access Control (RBAC: ロールベースアクセス制御) オブジェクトは、ユーザーがプロジェクト内で所定の アクション を実行することが許可されるかどうかを決定します。

これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。

これにより、開発者はローカルロールおよびバインディング を使用し、それらの プロジェクト へのアクセスを持つユーザーを制御します。認可は、認証 とは異なる別の手順であることに注意してください。 認可の手順は、アクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。

認可は以下を使用して管理されます。

クラスター管理者は、CLI の使用によりルール、ロールおよびバインディングを可視化できます。

たとえば、admin および basic-user の デフォルトクラスターロールのルールセットを示す以下の抜粋を考慮してみましょう。

$ oc describe clusterrole.rbac admin basic-user

Name:		admin
Labels:		<none>
Annotations:	openshift.io/description=A user that has edit rights within the project and can change the project's membership.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  appliedclusterresourcequotas					[]			[]		[get list watch]
  appliedclusterresourcequotas.quota.openshift.io		[]			[]		[get list watch]
  bindings							[]			[]		[get list watch]
  buildconfigs							[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs/instantiate					[]			[]		[create]
  buildconfigs.build.openshift.io/instantiate			[]			[]		[create]
  buildconfigs/instantiatebinary				[]			[]		[create]
  buildconfigs.build.openshift.io/instantiatebinary		[]			[]		[create]
  buildconfigs/webhooks						[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io/webhooks			[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs							[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds							[]			[]		[create delete deletecollection get list patch update watch]
  builds.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds/clone							[]			[]		[create]
  builds.build.openshift.io/clone				[]			[]		[create]
  builds/details						[]			[]		[update]
  builds.build.openshift.io/details				[]			[]		[update]
  builds/log							[]			[]		[get list watch]
  builds.build.openshift.io/log					[]			[]		[get list watch]
  configmaps							[]			[]		[create delete deletecollection get list patch update watch]
  cronjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  daemonsets.extensions						[]			[]		[get list watch]
  deploymentconfigrollbacks					[]			[]		[create]
  deploymentconfigrollbacks.apps.openshift.io			[]			[]		[create]
  deploymentconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/instantiate					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/instantiate		[]			[]		[create]
  deploymentconfigs/log						[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/log			[]			[]		[get list watch]
  deploymentconfigs/rollback					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/rollback			[]			[]		[create]
  deploymentconfigs/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io/scale			[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/status					[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/status			[]			[]		[get list watch]
  deployments.apps						[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/rollback				[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/status					[]			[]		[create delete deletecollection get list patch update watch]
  endpoints							[]			[]		[create delete deletecollection get list patch update watch]
  events							[]			[]		[get list watch]
  horizontalpodautoscalers.autoscaling				[]			[]		[create delete deletecollection get list patch update watch]
  horizontalpodautoscalers.extensions				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimports						[]			[]		[create]
  imagestreamimports.image.openshift.io				[]			[]		[create]
  imagestreammappings						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreammappings.image.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams							[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/layers						[]			[]		[get update]
  imagestreams.image.openshift.io/layers			[]			[]		[get update]
  imagestreams/secrets						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io/secrets			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/status						[]			[]		[get list watch]
  imagestreams.image.openshift.io/status			[]			[]		[get list watch]
  imagestreamtags						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamtags.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  jenkins.build.openshift.io					[]			[]		[admin edit view]
  jobs.batch							[]			[]		[create delete deletecollection get list patch update watch]
  limitranges							[]			[]		[get list watch]
  localresourceaccessreviews					[]			[]		[create]
  localresourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  localsubjectaccessreviews					[]			[]		[create]
  localsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  localsubjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  namespaces							[]			[]		[get list watch]
  namespaces/status						[]			[]		[get list watch]
  networkpolicies.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  persistentvolumeclaims					[]			[]		[create delete deletecollection get list patch update watch]
  pods								[]			[]		[create delete deletecollection get list patch update watch]
  pods/attach							[]			[]		[create delete deletecollection get list patch update watch]
  pods/exec							[]			[]		[create delete deletecollection get list patch update watch]
  pods/log							[]			[]		[get list watch]
  pods/portforward						[]			[]		[create delete deletecollection get list patch update watch]
  pods/proxy							[]			[]		[create delete deletecollection get list patch update watch]
  pods/status							[]			[]		[get list watch]
  podsecuritypolicyreviews					[]			[]		[create]
  podsecuritypolicyreviews.security.openshift.io		[]			[]		[create]
  podsecuritypolicyselfsubjectreviews				[]			[]		[create]
  podsecuritypolicyselfsubjectreviews.security.openshift.io	[]			[]		[create]
  podsecuritypolicysubjectreviews				[]			[]		[create]
  podsecuritypolicysubjectreviews.security.openshift.io		[]			[]		[create]
  processedtemplates						[]			[]		[create delete deletecollection get list patch update watch]
  processedtemplates.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  projects							[]			[]		[delete get patch update]
  projects.project.openshift.io					[]			[]		[delete get patch update]
  replicasets.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  replicasets.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers.extensions/scale			[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/status					[]			[]		[get list watch]
  resourceaccessreviews						[]			[]		[create]
  resourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  resourcequotas						[]			[]		[get list watch]
  resourcequotas/status						[]			[]		[get list watch]
  resourcequotausages						[]			[]		[get list watch]
  rolebindingrestrictions					[]			[]		[get list watch]
  rolebindingrestrictions.authorization.openshift.io		[]			[]		[get list watch]
  rolebindings							[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.authorization.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.rbac.authorization.k8s.io			[]			[]		[create delete deletecollection get list patch update watch]
  roles								[]			[]		[create delete deletecollection get list patch update watch]
  roles.authorization.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  roles.rbac.authorization.k8s.io				[]			[]		[create delete deletecollection get list patch update watch]
  routes							[]			[]		[create delete deletecollection get list patch update watch]
  routes.route.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  routes/custom-host						[]			[]		[create]
  routes.route.openshift.io/custom-host				[]			[]		[create]
  routes/status							[]			[]		[get list watch update]
  routes.route.openshift.io/status				[]			[]		[get list watch update]
  scheduledjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  secrets							[]			[]		[create delete deletecollection get list patch update watch]
  serviceaccounts						[]			[]		[create delete deletecollection get list patch update watch impersonate]
  services							[]			[]		[create delete deletecollection get list patch update watch]
  services/proxy						[]			[]		[create delete deletecollection get list patch update watch]
  statefulsets.apps						[]			[]		[create delete deletecollection get list patch update watch]
  subjectaccessreviews						[]			[]		[create]
  subjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  subjectrulesreviews						[]			[]		[create]
  subjectrulesreviews.authorization.openshift.io		[]			[]		[create]
  templateconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  templateconfigs.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances						[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  templates							[]			[]		[create delete deletecollection get list patch update watch]
  templates.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]


Name:		basic-user
Labels:		<none>
Annotations:	openshift.io/description=A user that can get basic information about projects.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources						Non-Resource URLs	Resource Names	Verbs
  ---------						-----------------	--------------	-----
  clusterroles						[]			[]		[get list]
  clusterroles.authorization.openshift.io		[]			[]		[get list]
  clusterroles.rbac.authorization.k8s.io		[]			[]		[get list watch]
  projectrequests					[]			[]		[list]
  projectrequests.project.openshift.io			[]			[]		[list]
  projects						[]			[]		[list watch]
  projects.project.openshift.io				[]			[]		[list watch]
  selfsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  selfsubjectrulesreviews				[]			[]		[create]
  selfsubjectrulesreviews.authorization.openshift.io	[]			[]		[create]
  storageclasses.storage.k8s.io				[]			[]		[get list]
  users							[]			[~]		[get]
  users.user.openshift.io				[]			[~]		[get]

ローカルロールバインディングを表示して得られる以下の概要は、各種のユーザーおよびグループにバインドされた上記のロールを示しています。

$ oc describe rolebinding.rbac admin basic-user -n alice-project

Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name		Namespace
  ----	----		---------
  User	system:admin
  User	alice


Name:		basic-user
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe
  Group	devel

クラスターロール、ローカルロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。

OpenShift Container Platform が承認を評価する際、いくつかの要因が組み合わさって決定が行われます。

OpenShift Container Platform は以下の手順を使って承認を評価します。

2 つのレベルの RBAC ロールおよびバインディングが認可を制御します。

この 2 つのレベルからなる階層により、ローカルロールでの個別プロジェクト内のカスタマイズが可能になる一方で、クラスターロールによる複数プロジェクト間での再利用が可能になります。

評価時に、クラスターロールのバインディングおよびローカルロールのバインディングが使用されます。以下に例を示します。

ロールはポリシールールのコレクションであり、一連のリソースで実行可能な一連の許可された動詞です。OpenShift Container Platform には、クラスター全体 または ローカル で、ユーザーおよびグループにバインドできるデフォルトのクラスターロールのセットが含まれます。

プロジェクト管理者は、ローカルロールとローカルバインディングを表示する ために、CLI を使用してロールを可視化できます。 これには、それぞれのロールが関連付けられる動詞およびリソースのマトリクスが含まれます。

プロジェクトのローカルロールの作成方法についてはこちらを参照してください。

$ oc auth reconcile -f <file> 1

ユーザーの実行できる内容を制御する RBAC リソースのほかに、OpenShift Container Platform は Pod が実行できる内容および Pod がアクセスできる内容を制御する SCC (security context constraints) を提供します。管理者は CLI を使用して SCC を管理することができます。

SCC は永続ストレージへのアクセスを管理する場合にも非常に便利です。

SCC は、システムで許可されるために Pod の実行時に必要となる一連の条件を定義するオブジェクトです。管理者は以下を制御できます。

デフォルトでは、7 つの SCC がクラスターに追加され、クラスター管理者は CLI を使用してそれらを表示できます。

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]

各 SCC の定義についても、クラスター管理者は CLI を使用して表示できます。たとえば、特権付き SCC の場合は、以下のようになります。

$ oc get -o yaml --export scc/privileged

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: 1
- '*'
apiVersion: v1
defaultAddCapabilities: [] 2
fsGroup: 3
  type: RunAsAny
groups: 4
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: [] 5
runAsUser: 6
  type: RunAsAny
seLinuxContext: 7
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: 8
  type: RunAsAny
users: 9
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'

SCC の users および groups フィールドは使用できる SCC を制御します。デフォルトで、クラスター管理者、ノードおよびビルドコントローラーには特権付き SCC へのアクセスが付与されます。認証されるすべてのユーザーには制限付き SCC へのアクセスが付与されます。

Docker には、Pod の各コンテナーについて許可される デフォルトの機能一覧 があります。コンテナーはこれらの機能をデフォルト一覧から使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルトから一部をドロップしてこの一覧を変更できます。allowedCapabilities、defaultAddCapabilities、および requiredDropCapabilities フィールドは Pod からのこのような要求を制御し、要求できる機能を決定し、各コンテナーに追加するものや禁止する必要のあるものを決定するために使用されます。

特権付き SCC:

制限付き SCC:

SCC は Pod がアクセスできるセキュリティー機能を制限する各種の設定およびストラテジーで設定されています。これらの設定は以下のカテゴリーに分類されます。

volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs

rules:
- apiGroups:
  - security.openshift.io 1
  resources:
  - securitycontextconstraints 2
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
  resourceNames:
  - myPermittingSCC 3

OpenShift Container Platform プロジェクト内で、namespace でスコープ設定されたすべてのリソース (サードパーティーのリソースを含む) に対して実行できる動詞を判別します。以下を実行します。

$ oc policy can-i --list --loglevel=8

この出力で、情報収集のために実行する必要のある API 要求を判断しやすくなります。

ユーザーが判読可能な形式で情報を取得し直すには、以下を実行します。

$ oc policy can-i --list

この出力により、詳細な一覧が表示されます。

特定の verb (動詞) を実行可能かどうかを判断するには、以下を実行します。

$ oc policy can-i <verb> <resource>

ユーザースコープ は、指定のスコープに関する詳細情報を提供します。以下に例を示します。

$ oc policy can-i <verb> <resource> --scopes=user:info

ストレージの管理は、コンピュートリソースの管理とは異なります。OpenShift Container Platform は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、永続ボリューム要求 (PVC) を使用すると、基礎となるストレージインフラストラクチャーについての特定の知識がなくても PV リソースを要求することができます。

PVC は プロジェクト に固有のもので、開発者が PV を使用する手段として作成し、使用します。PV リソース自体のスコープはいずれの単一プロジェクトにも設定されず、それらは OpenShift Container Platform クラスター全体で共有でき、すべてのプロジェクトから要求できます。PV が PVC に バインド された後は、その PV を追加の PVC にバインドすることはできません。これにはバインドされた PV を単一の namespace (バインディングプロジェクトの namespace) にスコープ設定する作用があります。

PV は、クラスター管理者によってプロビジョニングされるクラスターの既存のネットワーク設定されたストレージの一部を表す PersistentVolume API オブジェクトで定義されます。これは、ノードがクラスターリソースであるのと同様にクラスター内のリソースです。PV は Volumes などのボリュームプラグインですが、PV を使用する個々の Pod から独立したライフサイクルを持ちます。PV オブジェクトは、NFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムのいずれの場合でも、ストレージの実装の詳細をキャプチャーします。

PVC は、開発者によるストレージの要求を表す PersistentVolumeClaim API オブジェクトによって定義されます。これは Pod がノードリソースを消費する点で Pod に似ており、PVC は PV リソースを消費します。たとえば、Pod は特定のレベルのリソース (CPU およびメモリーなど) を要求し、PVC は特定の ストレージ容量 および アクセスモード を要求できます (たとえば、それらは読み取り/書き込みで 1 回、読み取り専用で複数回マウントできます)。

PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。

各 PV には、以下の例のように、ボリュームの仕様およびステータスである spec および status が含まれます。

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /tmp
      server: 172.17.0.2

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
  annotations:
    volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec 1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

各 PVC には、要求の仕様およびステータスである spec および status が含まれます。 以下に例を示します。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: gold

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

PV および PVC 仕様に API フィールドを組み込み、raw ブロックボリュームを静的にプロビジョニングできます。

ブロックボリュームを使用するには、まず BlockVolume 機能ゲートを有効にする必要があります。マスターの機能ゲートを有効にするには、feature-gates を apiServerArguments および controllerArguments に追加します。ノードの機能ゲートを有効にするには、feature-gates を kubeletArguments に追加します。以下に例を示します。

kubeletArguments:
   feature-gates:
     - BlockVolume=true

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  resources:
    requests:
      storage: 10Gi

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  1
        - name: data
          devicePath: /dev/xvda 2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc 3

永続ストレージに加え、Pod とコンテナーは、操作に一時または短期的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。

OpenShift Container Platform 3.10 以前は、一時ローカルストレージは、コンテナーの書き込み可能な階層、logs ディレクトリー、EmptyDir ボリュームを使用して Pod に公開されていました。Pod は、スクラッチスペース、キャッシュ、ログに一時ローカルストレージを使用します。ローカルストレージのアカウントや分離がないことに関連する問題には、以下が含まれます。

一時ストレージは、永続ボリュームとは異なり、体系化されておらず、システム、コンテナーランタイム、Openshift Container Platform での他の用途に加え、ノードで実行中のすべての Pod 間で実際のデータではなく領域を共有します。一時ストレージのフレームワークは、Pod が一時的なストレージのニーズを指定するだけでなく、随時 OpenShift Container Platform が Pod をスケジューリングし、ローカルストレージが過剰に使用されないように保護します。

一時ストレージフレームワークでは、管理者および開発者がこのローカルストレージの管理を改善できますが、I/O スループットやレイテンシーに関する確約はありません。

一時ローカルストレージは常に、プライマリーパーティションで利用できるようになっています。プライマリーパーティション、Root、ランタイムを作成する基本的な方法には 2 種類あります。

クラスター管理者は、非終了状態のすべての Pod の一時ストレージに対して制限範囲や一時ストレージの要求数を定義する クォータを設定 することで、プロジェクト内で一時ストレージを管理できます。開発者は Pod およびコンテナーのレベルで、このコンピュートリソースの 要求および制限 を設定することもできます。

/bin/df をツールとして使用し、一時コンテナーデータが置かれているボリューム (/var/lib/origin および /var/lib/docker) の一時ストレージの使用をモニターすることができます。/var/lib/docker がクラスター管理者によって別のディスクに配置されている場合は、df コマンドを使用すると、/var/lib/origin の使用可能なスペースのみが表示されます。

df -h コマンドを使用して、/var/lib 内の使用済みおよび使用可能なスペースの人間が判読できる値を表示します。

$ df -h /var/lib

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

受付制御プラグインはリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および認可後にこれを実行します。

クラスターに要求が受け入れられる前に、受付制御プラグインがそれぞれ、順番に実行されます。この順番に実行されているプラグインのいずれかが要求を拒否すると、要求全体がただちに拒否され、エンドユーザーにエラーが返されます。

受付制御プラグインは、システムで設定されたデフォルトを適用するために受信オブジェクトを変更する場合があります。さらに、受付制御プラグインはクォータ使用の増分などを実行する要求処理の一環として関連するリソースを変更する場合もあります。

OpenShift Container Platform は Kubernetes および OpenShift Container Platform リソースの単一の受付チェーンを使用します。これは、トップレベルの admissionConfig.pluginConfig 要素に kubernetesMasterConfig.admissionConfig.pluginConfig に含まれていた受付プラグイン設定が含まれることを意味しています。

kubernetesMasterConfig.admissionConfig.pluginConfig は admissionConfig.pluginConfig に移動し、マージされる必要があります。

サポートされるすべての受付プラグインは単一チェーン内で順序付けられます。admissionConfig.pluginOrderOverride または kubernetesMasterConfig.admissionConfig.pluginOrderOverride を設定する必要はなくなります。代わりに、プラグイン固有の設定を追加するか、または以下のような DefaultAdmissionConfig スタンザを追加してデフォルトでオフになっているプラグインを有効にする必要があります。

admissionConfig:
  pluginConfig:
    AlwaysPullImages: 1
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false 2

disable を true にすると、on にデフォルト設定される受付プラグインが無効になります。

クラスター管理者は、一部の受付コントロールプラグインを、以下のような特定の動作を制御するように設定できます。

コンテナーを使用する受付コントローラーも init コンテナーをサポートします。

デフォルトの受付コントローラーのほかにも、受付 Webhook を受付チェーンの一部として使用できます。

受付 Webhook は Webhook サーバーを呼び出して、ラベルの挿入など、作成時に Pod を変更するか、または受付プロセス時に Pod 設定の特定の部分を検証します。

受付 Webhook はリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。

OpenShift Container Platform では、API 受付チェーンで Webhook サーバーを呼び出す受付 Webhook オブジェクトを使用できます。

設定可能な 2 種類の受付 Webhook オブジェクトがあります。

Webhook および外部 Webhook サーバーの設定については本書では扱いません。ただし、Webhook サーバーは、OpenShift Contaniner Platform で適切に機能するために、インターフェイスに準拠する必要があります。

オブジェクトがインスタンス化されると、OpenShift Container Platform は API 呼び出しを実行してオブジェクトを許可します。受付プロセスでは、変更用の受付コントローラー は Webhook を呼び出して、アフィニティーラベルの挿入などのタスクを実行します。受付プロセスの終了時に、検証用の受付コントローラー は Webhook を呼び出し、アフィニティーラベルの検証などにより、オブジェクトが適切に設定されていることを確認します。検証にパスすると、OpenShift Container Platform はオブジェクトを設定済みとしてスケジュールします。

API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。

受付コントローラーと Webhook サーバー間の通信のセキュリティーは TLS を使用して保護する必要があります。CA 証明書を生成し、その証明書を使用して Webhook サーバーで使用されるサーバー証明書に署名します。PEM 形式の CA 証明書は、サービス提供証明書のシークレットなどのメカニズムを使用して受付コントローラーに提供されます。

以下の図は、複数の Webhook を呼び出す 2 つの受付 Webhook を含むプロセスを示しています。

受付 Webhook の単純な使用事例として、リソースの構文検証が挙げられます。たとえば、すべての Pod に共通のラベルセットを指定する必要のあるインフラストラクチャーがあり、そのラベルが指定されていない Pod は永続化させないようにする場合に、Webhook を作成してこれらのラベルを挿入したり、別の Webhook でラベルの有無を検証したりすることができます。これらのラベルを挿入する Webhook と、ラベルが存在することを確認する別の Webhook を作成できます。次に、OpenShift Container Platform は、ラベルがあり、検証に合格した Pod をスケジュールし、ラベルがないために合格しなかった Pod を拒否します。

共通のユースケースには以下が含まれます。

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: MutatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace:  5
        name: 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace: default  5
        name: kubernetes 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration
  metadata:
    name: namespacereservations.admission.online.openshift.io
  webhooks:
  - name: namespacereservations.admission.online.openshift.io
    clientConfig:
      service:
        namespace: default
        name: webhooks
       path: /apis/admission.online.openshift.io/v1beta1/namespacereservations
      caBundle: KUBE_CA_HERE
    rules:
    - operations:
      - CREATE
      apiGroups:
      - ""
      apiVersions:
      - "b1"
      resources:
      - namespaces
    failurePolicy: Ignore

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  containers:
    - name: webhook
      image: myrepo/myimage:latest
      imagePullPolicy: IfNotPresent
      ports:
- containerPort: 8000

apiVersion: v1
kind: Service
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  ports:
    - port: 443
      targetPort: 8000
  selector:
role: webhook

制限範囲は、Kubernetes namespace のリソースに設定される最小/最大の制限を実施するメカニズムを提供します。

制限範囲を namespace に追加することで、個別の Pod またはコンテナーによる CPU およびメモリーの最小および最大使用量を適用できます。

CPU とメモリーの制限については、max 値を指定し、LimitRange オブジェクトで min 制限を指定しない場合、リソースは max 値を超える CPU/メモリーリソースを消費する可能性があります。

Kubernetes は、namespace で作成されるオブジェクト数と、namespace 内のオブジェクト間で要求されるリソース合計量の両方を制限できます。これにより、namespace 内の複数のチームで単一の Kubernetes クラスターを共有でき、あるチームによって別のチームがクラスターリソース不足になることを防ぐことができます。

ResourceQuota についての詳細は、クラスター管理 を参照してください。

Kubernetes の Resource は、Pod またはコンテナーによって要求され、割り当てられ、消費されるものです。例として、メモリー (RAM)、CPU、ディスク時間、およびネットワーク帯域幅があります。

詳細は、開発者ガイド を参照してください。

シークレット は、キー、パスワード、および証明書などの機密情報のストレージです。これらは所定の Pod でアクセスできますが、定義とは別に保持されます。

永続ボリューム は、クラスター管理者によってプロビジョニングされるインフラストラクチャーのオブジェクト (PersistentVolume) です。永続ボリュームは、ステートフルなアプリケーションの耐久性のあるストレージを提供します。

PersistentVolumeClaim オブジェクトは、Pod 作成者によるストレージの要求 です。Kubernetes は、要求を利用可能なボリュームのプールに対して一致させ、それらをバインドします。この要求は、Pod によってボリュームとして使用されます。Kubernetes はボリュームがこれを要求する Pod と同じノードで利用可能であることを確認します。

Kubernetes は、確実に Pod 間がネットワークで接続されるようにし、内部ネットワークから IP アドレスを各 Pod に割り当てます。こうすることで、Pod 内の全コンテナーが同じホスト上にいるかように動作します。各 Pod に IP アドレスを割り当てると、ポートの割り当て、ネットワーク、名前の指定、サービス検出、負荷分散、アプリケーション設定、移行などの点で、Pod を物理ホストや仮想マシンのように扱うことができます。

Pod 間のリンクを作成する必要はないので、この IP アドレスを使用して Pod 間で直接相互に通信することは推奨されません。代わりに、サービス を作成して、そのサービスと対話することが推奨されます。

フロントエンドサービスやバックエンドサービスなど、複数の サービス を実行して複数の Pod で使用している場合には、フロントエンド Pod がバックエンドサービスと通信できるように、ユーザー名、サービス IP などの環境変数を作成します。サービスが削除され、再作成された場合には、新規の IP アドレスがサービスに割り当てられるので、サービス IP の環境変数の更新値を取得するには、フロントエンド Pod を再作成する必要があります。さらに、バックエンドサービスは、フロントエンド Pod を作成する前に作成し、サービス IP が正しく生成され、フロントエンド Pod に環境変数として提供できるようにする必要があります。

そのため、OpenShift Container Platform には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。OpenShift Container Platform は、サービスの DNS クエリーに応答するマスターでSkyDNSを実行することで、スプリット DNS をサポートします。マスターは、デフォルトで、ポート 53 をリッスンします。

ノードが起動すると、以下のメッセージで、Kubelet が正しくマスターに解決されていることが分かります。

0308 19:51:03.118430    4484 node.go:197] Started Kubelet for node
openshiftdev.local, server at 0.0.0.0:10250
I0308 19:51:03.118459    4484 node.go:199]   Kubelet is setting 10.0.2.15 as a
DNS nameserver for domain "local"

2 番目のメッセージが表示されない場合は、Kuernetes サービスが利用できない可能性があります。

ノードホストで、各コンテナーのネームサーバーのフロントにマスター名が追加され、コンテナーの検索ドメインはデフォルトでは、.<pod_namespace>.cluster.local になります。コンテナーは、ノード上の他のネームサーバーよりも先にネームサーバーのクエリーをマスターに転送します。これは、Docker 形式のコンテナーではデフォルトの動作です。 マスターは、以下の形式の .cluster.local ドメインでクエリーに対応します

これにより、新しいサービスを取得するためにフロントエンドの pod を再起動し、サービスに対して新しい IP を作成せずに済みます。また、pod がサービスの DNS を使用するので、環境変数を使用する必要がなくなります。さらに、DNS は変更しないので、設定ファイルで db.local としてデータベースサービスを参照できます。また、検索はサービス IP に対して解決するため、ワイルドカードの検索もサポートされます。 さらにサービス名 (つまり DNS) が事前に確立しているので、フロントエンド Pod の前にバックエンドサービスを作成する必要がなくなります。

この DNS 構造では、ポータル IP はサービスに割り当てられず、kube-proxy は負荷分散しないまたはエンドポイントのルーティングを提供するヘッドレスサービスに対応しています。サービス DNS は依然として使用でき、サービスの Pod ごとに 1 つずつある複数のレコードに対応し、クライアントによる Pod 間のラウンドロビンを可能にします。

OpenShift Container Platform は、Software Defined Networking (SDN) アプローチを使用して、クラスターのネットワークを統合し、OpenShift Container Platform クラスターの Pod 間の通信を可能にします。OpenShift SDN により、このような Pod ネットワークが確立され、メンテナーンスされます。 OpenShift SDN は Open vSwitch (OVS) を使用してオーバーレイネットワークを設定します。

OpenShift SDN では以下のように、Pod ネットワークを設定するための SDN プラグインを 3 つ提供します。

OpenShift Container Platform master では、OpenShift SDN が、etcd に保存されている、ノードのレジストリーを管理します。システム管理者がノードを登録すると、OpenShift SDN がクラスターネットワークから未使用のサブネットを割り当てて、レジストリーのこのサブネットを保存します。ノードが削除されると、OpenShift SDN はレジストリーからサブネットを削除し、このサブネットを割り当て可能とみなします。

デフォルトの設定では、クラスターネットワークは 10.128.0.0/14 ネットワーク (つまり 10.128.0.0 - 10.131.255.255) で、ノードには /23 サブネット (つまり 10.128.0.0/23、10.128.2.0/23、10.128.4.0/23 など) が割り当てられます。つまり、このクラスターネットワークには、512 個のサブネットをノードに割り当てることができ、特定のノードには 510 個のアドレスが割り当てられ、このノードで実行中のコンテナーに割り当てることができます。クラスターネットワークのサイズやアドレス範囲、さらにホストのサブネットサイズは、設定可能です。

マスター上の OpenShift SDN は、ローカル (マスター) ホストがクラスターネットワークにアクセスできるように設定しないことに注意してください。したがって、マスターホストは、ノードとしても実行されていない限り、クラスターネットワーク経由で Pod にアクセスできません。

ovs-multitenant プラグインを使用する場合には、OpenShift SDN マスターはプロジェクトの作成や削除を監視し、VXLAN VNID をプロジェクトに割り当てます。 この VNID は後で、ノードが正しくトラフィックを分離するために使用します。

ノードでは OpenShift SDN は先に、前述のレジストリーに、SDN マスターを持つローカルホストを登録し、マスターがノードにサブネットを割り当てられるようにします。

次に OpenShift SDN は、3 つのネットワークデバイスを作成、設定します。

Pod がホストで起動されるたびに、OpenShift SDN は以下を行います。

OpenShift SDN ノードは、SDN マスターからのサブネットの更新も監視します。新しいサブネットが追加された場合には、リモートサブネットの宛先 IP アドレスノードを持つパケットが vxlan0 (br0 のポート 1) に移動してネットワーク送信されるように、br0 に OpenFlow ルールを追加します。ovs-subnet プラグインは VNID 0 が指定された VXLAN に全パケットを送信しますが、ovs-multitenant プラグインは、ソースコンテナーに対して適切な VNID を使用します。

A と B の 2 つのコンテナーがあり、コンテナー A の eth0 をベースにするピア仮想 Ethernet デバイスの名前が vethA、コンテナー B の eth0 のピア名が vethB とします。

コンテナー A がローカルホスト上にあり、コンテナー B もローカルホスト上にあるとします。その場合には、コンテナー A からコンテナー B のパケットフローは以下のようになります。

eth0 (A の netns) → vethA → br0 → vethB → eth0 (B の netns)

次に、コンテナー A がローカルホストに、コンテナー B がクラスターネットワーク上のリモートホストにあると想定します。その場合には、コンテナー A からコンテナー B のパケットフローは以下のようになります。

eth0 (A の netns 内) → vethA → br0 → vxlan0 → ネットワーク ^[1] → vxlan0 → br0 → vethB → eth0 (B の netns 内)

最後に、コンテナー A が外部ホストに接続すると、トラフィックは以下のようになります。

eth0 (A の netns) → vethA → br0 → tun0 → (NAT) → eth0 (物理デバイス) → インターネット

パケット配信の意思決定はほぼ、OVS ブリッジ br0 の OpenFlow ルールをもとに行われ、プラグインのネットワークアーキテクチャーを簡素化し、ルーティングを柔軟化します。ovs-multitenant プラグインの場合は、OpenFlow ルールを元にした意思決定により、強制的なネットワーク分離 が可能になります。

ovs-multitenant プラグインを使用して、ネットワーク分離を実現できます。デフォルト以外のプロジェクトに割り当てられた Pod からパケットが送信される場合は、OVS ブリッジ br0 により、このパケットに、プロジェクトが割り当てた VNID のタグを付けます。パケットが、ノードのクラスターサブネットに含まれる別の IP アドレスに転送される場合には、OVS ブリッジは、VNID が一致する場合にのみ、宛先の Pod に対するこのパケットの配信を許可します。

パケットが別のノードから VXLAN トンネル経由で受信された場合には、トンネル ID を VNID として使用し、OVS ブリッジは、トンネル ID が宛先の Pod の VNID に一致する場合にのみ、ローカル Pod へのパケットの配信を許可します。

他のクラスターサブネットが宛先のパケットは、その VNID でタグ付けされ、クラスターサブネットを所有するノードのトンネルの宛先アドレスが指定された VXLAN トンネルに配信されます。

前述の通り、VNID 0 は、任意の VNID が指定されたトラフィックは VNID 0 が割り当てられた Pod に、VNID 0 が指定されたトラフィックは任意の Pod に送信できる点で特権があります。デフォルト の OpenShift Container Platform プロジェクトには VNID 0 が割り当てられています。他のプロジェクトにはすべて、一意の分離可能な VNID が割り当てられています。 クラスター管理者はオプションで、管理者 CLI を使用してプロジェクトの Pod ネットワークを管理 できます。

OpenShift SDN は、デフォルトで Ansible ベースのインストール手順の一部としてインストール設定されます。詳細情報は、OpenShift SDNのセクションを参照してください。

Kuryr (具体的には Kuryr-Kubernetes) は、CNI と OpenStack Neutron を使用して構築した SDN ソリューションです。Kuryr の利点として、幅広い Neutron SDN バックエンドを使用でき、Kubernetes Pod と OpenStack 仮想マシン (VM) の相互接続性が確保できる点が挙げられます。

Kuryr-Kubernetes と OpenShift Container Platform の統合は主に、OpenStack の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。

HAProxy テンプレートのルーター実装は、テンプレートルータープラグインの参照実装です。これは、openshift3/ose-haproxy-router リポジトリーを使用して、テンプレートルータープラグインとともに、HAProxy インスタンスを実行します。

テンプレートルーターには 2 つのコンポーネントがあります。

コントローラーおよび HAProxy は、Pod 内に常駐しており、デプロイメント設定で管理されます。ルーターの設定プロセスは、oc adm router コマンドで自動化されています。

コントローラーは、ルートとエンドポイントに変更がないか、また、HAProxy プロキシーを監視します。変更が検出されたら、新しい haproxy-config ファイルを作成して、HAProxy を再起動します。haproxy-config ファイルは、ルーターのテンプレートファイルと OpenShift Container Platform からの情報をベースに構築されます。

HAProxy テンプレートファイルは、必要に応じてカスタマイズして、OpenShift Container Platform で現在サポートされていない機能をサポートすることができます。HAProxy マニュアル では、HAProxy がサポートする全機能を説明しています。

以下の図では、データがプラグインを使用してマスターから最終的に HAProxy 設定にどのように移動するかが記載されています。

図5.4 HAProxy ルーターデータフロー

HAProxy テンプレートルーターメトリクス

HAProxy ルーターは、外部のメトリクスコレクションや集計システム (例 Prometheus、statsd) で消費されるように、Prometheus 形式 のメトリクスを提供して公開します。ルーターは、HAProxy CSV 形式 のメトリクスを提供するように設定したり、まったくルーターメトリクスを提供しないように設定したりできます。

メトリクスは、ルーターコントローラーおよび HAProxy の両方から 5 秒ごとに取得されます。ルーターメトリクスカウンターは、ルーターのデプロイ時に 0 から開始され、経時的に増加します。HAProxy メトリクスカウンターは、HAProxy が再読み込みされるたびに 0 にリセットされます。ルーターはフロントエンド、バックエンド、サーバーごとに HAProxy 統計を収集します。サーバーが 500 台以上ある場合に、リソースの使用量を減らすには、バックエンドでは複数のサーバーを利用できるので、サービスではなく、バックエンドをレポートします。

この統計は 利用可能な HAProxy 統計 のサブセットです。

以下の HAProxy メトリクスは定期的に収集され、Prometheus 形式に変換されます。フロントエンドはすべて、"F" カウンターが収集されます。バックエンドごとのカウンターを収集する場合には、サーバーごとの "S" サーバーカウンターが収集されます。それ以外の場合は、バックエンドごとに "B" カウンターが収集され、サーバーカウンターは収集されません。

詳細は、ルーター環境変数を参照してください。

以下の表を参照してください。

列 1 - HAProxy CSV 統計のインデックス

列 2

列 3 - カウンター

列 4 - カウンターの説明

ルーターコントローラーは、以下のアイテムを収集します。これらは、Prometheus 形式のメトリクスでのみ提供されます。

OpenShift Container Platform は Kubernetes に組み込まれた機能を利用して Pod へのポート転送をサポートします。これは、HTTP と SPDY または HTTP/2 などの多重化ストリーミングプロトコルを使用して実装されます。

開発者は CLIを 使用して Pod にポート転送できます。CLI は、ユーザーが指定した各ローカルポートをリッスンし、記載のプロトコルを使用して転送します。

Kubelet は、クライアントからのポート転送要求を処理します。要求を受信すると、応答をアップグレードし、クライアントがポート転送ストリームを作成するまで待機します。新規ストリームを受信したら、ストリームと Pod ポート間のデータをコピーします。

アーキテクチャーの観点では、Pod のポートに転送するためのいくつかのオプションがあります。OpenShift Container Platform でサポートされる現在の実装はノードホストで直接 nsenter を呼び出し、Pod ネットワークの namespace に入り、socat を呼び出してストリームと Pod のポート間のデータをコピーします。ただし、カスタムの実装には、nsenter と socat のバイナリーをホストにインストールしなくていいように、これらのバイナリーを実行するヘルパー Pod の実行が含まれています。

OpenShift Container Platform は Kubernetes に内蔵されている機能を活用し、コンテナーでのコマンド実行をサポートします。これは、HTTP と SPDY または HTTP/2 などの多重化ストリーミングプロトコルを使用して実装されます。

開発者は CLI を使用して、コンテナーでリモートコマンドを実行します。

Kubelet は、クライアントからのリモート実行要求を処理します。要求を受信すると応答をアップグレードして、要求ヘッダーを評価してどのストリーム (stdin、stdout および/または stderr) を受信するか判断し、クライアントがストリームを作成するまで待機します。

Kubelet が全ストリームを受信したら、コンテナーでコマンドを実行して、ストリームとコマンドの stdin、stdout および stderr を適切にコピーします。コマンドが中断されたら、Kubelet はアップグレードされた接続と基盤の接続を終了します。

アーキテクチャー的に、コンテナーでコマンドを実行するオプションがあります。OpenShift Container Platform で現在サポートされている実装では、ノードホストで nsenter を直接呼び出して、コマンド実行前に、ノードホストがコンテナーの namespace に入ることができるようにします。ただし、カスタム実装には docker exec の使用や、ホストでインストールする必要のある nsenter バイナリーが必須とならないように nsenter を実行するヘルパーコンテナーの実行が含まれる場合があります。

OpenShift Container Platform ルートは、外部クライアントが名前でサービスに到達できるように、www.example.com などのホスト名で サービス を公開します。

ホスト名の DNS 解決はルーティングとは別に処理されます。管理者が、OpenShift Container Platform ルーターを実行する OpenShift Container Platform ノードに解決するように DNS ワイルドカードエントリー を設定している場合があります。異なるホスト名を使用している場合には、DNS レコードを個別に変更して、ルーターを実行するノードに解決する必要があります。

各ルーターは名前 (63 文字に制限)、サービスセレクター、およびオプションのセキュリティー設定で設定されています。

OpenShift Container Platform 管理者は、OpenShift Container Platform のノードに ルーター をデプロイできるので、開発者が作成した ルートを外部クライアントが利用できるようになります。OpenShift Container Platform のルーティング層はプラグ可能で、複数の ルータープラグイン がデフォルトで提供され、サポートされています。

ルーターは、サービスセレクターを使用して、サービスと、サービスをバッキングするエンドポイントを検索します。ルーターとサービス両方が負荷分散を提供する場合には、OpenShift Container Platform はルーターの負荷分散を使用します。ルーターはサービスの IP アドレスに関連の変更がないかを検出して、その設定に合わせて変化します。これは、カスタムルーターが API オブジェクトの変更を外部のルーティングソリューションに通信できるので、便利です。

要求のパスは、1 つまたは複数のルーターに対して、ホスト名の DNS を解決することから始まります。推奨の方法は、複数のルーターインスタンスでバックされる 1 つまたは複数の仮想 IP (VIP) アドレスを参照するワイルドカード DNS エントリーでクラウドドメインを定義する方法です。クラウドドメイン外の名前とアドレスを使用するルートには、個別の DNS エントリー設定が必要です。

VIP アドレスがルーターよりも少ない場合には、アドレス分のルーターが active で、残りは passive になります。passive ルーターは ホットスタンバイ ルーターとして知られています。たとえば、VIP アドレスが 2 つ、ルーターが 3 つの場合には、active-active-passive 設定になります。ルーターの VIP 設定に関する詳細情報は、高可用性を参照してください。

ルートは、ルーターセット間で シャード化 されます。管理者は、クラスター全体でシャード化を設定し、ユーザーはプロジェクトに含まれる namespace にシャード化を設定できます。オペレーターは、シャード化すると、複数のルーターグループを定義できるようになります。このグループ内の各ルーターはトラフィックのサブネット 1 つにのみ対応できます。

OpenShift Container Platform ルーターは、外部のホスト名マッピングと、ルーターに区別情報を直接渡すプロトコルを使用して サービス エンドポイントの負荷分散を行います。ルーターは、送信先を判断できるように、プロトコルにホスト名が存在している必要があります。

ルータープラグインはデフォルトで、ホストポート 80 (HTTP) および 443 (HTTPS) にバインドできます。つまり、配置されていないと、これらのポートは使用されないので、ルーターはノードに配置されている必要があります。または、ルーターは、ROUTER_SERVICE_HTTP_PORT および ROUTER_SERVICE_HTTPS_PORT 環境変数を設定して、他のポートをリッスンするように設定してください。

ルーターは、ホストノードのポートにバインドされるので、ルーターがホストネットワークを使用している場合には (デフォルト)、各ノードに 1 つしかこれらのポートをリッスンするルーターを配置できません。クラスターネットワークは、全ルーターがクラスター内のすべての Pod にアクセスできるように設定します。

ルーターは以下のプロトコルをサポートします。

セキュアな接続を確立するには、クライアントとサーバーに共通する 暗号化 を取り決める必要があります。時間が経つにつれ、よりセキュリティーの高く、新しい暗号化が利用でき、クライアントソフトウェアに統合されます。以前のクライアントは陳腐化し、セキュリティーの低い、以前の暗号化は使用が停止されます。デフォルトでは、ルーターは、一般的に入手できる、幅広いクライアントに対応します。ルーターは、任意のクライアントをサポートする暗号化の中で選択したものを使用し、セキュリティーが低い暗号化を使用しないように設定できます。

検証された利用可能なルータープラグインについては、利用可能なプラグインのセクションを参照してください。

これらのルーターのデプロイ方法については、ルーターのデプロイを参照してください。

スティッキーセッションの実装は、基盤のルーター設定により異なります。デフォルトの HAProxy テンプレートは、balance source 命令を使用してスティッキーセッションを実装し、ソース IP を基に分散されます。さらに、このテンプレートルータープラグインは、サービス名と namespace を基盤の実装に渡します。これは、ピア間で同期させるスティックテーブルの実装など、より高度な設定に使用できます。

スティッキーセッションは、ユーザー体験の向上のため、ユーザーのセッションからの全トラフィックが確実に同じ Pod に移動されるようにします。ユーザーの要求を満たしながら、Pod は後続の要求で使用できるように、データをキャッシュします。たとえば、バックエンド Pod が 5 つと負荷分散ルーターが 2 つあるクラスターでは、要求を処理するルーターがどれであっても、同じ Pod で、同じ Web ブラウザーからの web トラフィックを受信できるように確保できます。

ルーティングトラフィックを同じ Pod に返すことが望まれる場合でも、保証はできませんが、HTTP ヘッダーを使用して、cookie を設定し、最後の接続で使用した Pod を判断できます。ただし、HTTP ヘッダーを使用して Cookie を設定し、最後の接続で使用された Pod を判別できます。ユーザーがアプリケーションに別のリクエストを送信すると、ブラウザーは Cookie を再送信し、ルーターはトラフィックの送信先を認識します。

クラスター管理者は、スティッキネスをオフにして、他の接続とパススルールートを分割することも、完全にスティッキネスをオフにすることもできます。

デフォルトでは、パススルールートのスティッキーセッションは、source 負荷分散ストラテジーを使用して実装します。すべてのパスルート用には、ROUTER_TCP_BALANCE_SCHEME 環境変数 で、個別ルート用には、haproxy.router.openshift.io/balance ルート固有のアノテーション で、デフォルトを変更することができます。

他の種類のルートはデフォルトで leastconn 負荷分散ストラテジーを使用しますが、これは ROUTER_LOAD_BALANCE_ALGORITHM 環境変数を使用して変更できます。また、個別ルートには haproxy.router.openshift.io/balance ルート固有のアノテーション を使用して変更することができます。

さらに、このテンプレートルータープラグインは、サービス名と namespace を基盤の実装に渡します。これは、ピア間で同期させるスティックテーブルの実装など、より高度な設定に使用できます。

このルーター実装固有の設定は、ルーターコンテナーの /var/lib/haproxy/conf ディレクトリーにある haproxy-config.template ファイルに保存されます。ファイルは カスタマイズ可能です。

このセクションで説明されているアイテムはすべて、ルーターの デプロイメント設定 に環境変数を指定して設定を変更するか、oc set env コマンドを使用します。

$ oc set env <object_type>/<object_name> KEY1=VALUE1 KEY2=VALUE2

以下に例を示します。

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=127.0.0.1 ROUTER_LOG_LEVEL=debug