アーキテクチャー

REST API とのすべての通信チャネル、および etcd および API サーバーなどのマスターコンポーネント間の通信チャネルは TLS で保護されます。TLS は、X.509 サーバー証明書およびパブリックキーインフラストラクチャーを使用して強力な暗号化、データの整合性、およびサーバーの認証を提供します。

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

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

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

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

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

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

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

apiVersion: v1 

kind: Node 

metadata:
  creationTimestamp: null
  labels: 

    kubernetes.io/hostname: node1.example.com
  name: node1.example.com 

spec:
  externalID: node1.example.com 

status:
  nodeInfo:
    bootID: ""
    containerRuntimeVersion: ""
    kernelVersion: ""
    kubeProxyVersion: ""
    kubeletVersion: ""
    machineID: ""
    osImage: ""
    systemUUID: ""

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

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

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

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

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

Web コンソールの About ページから、クラスターのバージョン番号を確認できます。

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

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

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

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

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

図2.3 JVM コンソール

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

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

図2.4 OpenShift Online の StatefulSet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下は Pod のサンプル定義です。これは、統合コンテナーレジストリーという OpenShift Online インフラストラクチャーの一部で、長期間実行されるサービスを提供します。これは数多くの Pod の機能を示していますが、それらのほとんどは他のトピックで説明されるため、ここではこれらについて簡単に説明します。

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }
  labels:                                

    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-       

spec:
  containers:                            

  - env:                                 

    - 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 

    imagePullPolicy: IfNotPresent
    name: registry
    ports:                              

    - containerPort: 5000
      protocol: TCP
    resources: {}
    securityContext: { ... }            

    volumeMounts:                       

    - 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                 

  serviceAccount: default               

  volumes:                              

  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

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

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

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

apiVersion: v1
kind: Service
metadata:
  name: docker-registry      

spec:
  selector:                  

    docker-registry: default
  clusterIP: 172.30.136.123   

  ports:
  - nodePort: 0
    port: 5000               

    protocol: TCP
    targetPort: 5000         

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

$ 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 

spec:
  clusterIP: None 

  ports:
  - name: web
    port: 5432
    protocol: TCP
    targetPort: 8080
  selector:
    name: frontend 

  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 Online はそれらの Pod をポイントするエンドポイントオブジェクトを自動的に作成します。

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

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

OpenShift Online との対話はユーザーに関連付けられます。OpenShift Online ユーザーオブジェクトは、システムでパーミッションを付与できるアクターを表します。

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

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

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

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

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

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

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

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

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

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

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

OpenShift Online Starter では、24 時間を超えて非アクティブな状態が続くプロジェクトがアイドル状態になります。プロジェクトのネットワークアクティビティーが設定されたしきい値を下回ると、プロジェクトは非アクティブとみなされます。プロジェクトがアイドル状態になる場合、レプリカ数は 0 に設定され、すべての Pod が削除されます。プロジェクトの永続ボリューム (PV) および Persistent Volume Claim（永続ボリューム要求、PVC）はすべて変更されないままになります。ネットワークトラフィックを受信すると、レプリカ数はアイドル状態になる前の値にスケーリングされます。

Web コンソールでは、デプロイメントが 非アクティブのためのアイドル状態 として表示され、デプロイメントのスケールアップは手動で実行できます。

ネットワークトラフィックがプロジェクトのレプリカ数を復元しない場合、デプロイメントを手動でスケールアップする必要がある場合があります。

OpenShift Online Starter アカウントが非アクティブである場合 (3 日間プロジェクトに実行中の Pod がない場合)、アカウントのプロビジョニング解除について警告メールが送信されます。修正アクションを実行せず、Pod を 5 日以内に作成しないと、アカウントは自動的にプロビジョニング解除されます。アカウントのプロビジョニングが解除されると、再度登録できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

(ビルドまたはデプロイメント設定などの) イメージストリームタグを参照するオブジェクトを定義する場合には、Docker リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、OpenShift Onliine がこのイメージストリームタグを使用して 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 

  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 

  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>@<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 

      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  

  selector:    

    name: frontend
  template:    

    metadata:
      labels:  

        name: frontend 

    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: 

    matchLabels: 

      tier: frontend
    matchExpressions: 

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

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

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

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

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

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 

  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  

  strategy:
    type: Rolling      

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

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

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

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

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

明示的に定義されるグループのほかにも、システムグループまたは 仮想グループ が OpenShift で自動的にプロビジョニングされます。

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

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

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

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

OpenShift Online マスターには、ビルトイン OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。

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

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

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 

secret: "..." 

redirectURIs:
 - "http://www.example.com/" 

grantMethod: prompt 

')

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": ..., 

    "name": ..., 

    "group": ... 

  }
}

"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>", 

  "authorization_endpoint": "https://<master>/oauth/authorize", 

  "token_endpoint": "https://<master>/oauth/token", 

  "scopes_supported": [ 

    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 

    "code",
    "token"
  ],
  "grant_types_supported": [ 

    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 

    "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 / 

/ -H "X-CSRF-Token: xxx" 

*   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 

< 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' 

-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

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

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

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

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

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

OpenShift Online は以下の手順を使って認可を評価します。

OpenShift Online Pro では、ロール (表示 または 編集 など) をプロジェクトの他のユーザーまたはグループに付与できます。

コラボレーターの追加および削除についての詳細は、OpenShift Online Pro でのプロジェクトコラボレーションについて参照してください。

OpenShift Online Starter では、コラボレーションは利用できません。

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

PVC はプロジェクトに固有のもので、開発者が PV を使用する手段として作成し、使用します。PV リソース自体のスコープはいずれの単一プロジェクトにも設定されず、それらは OpenShift Online クラスター全体で共有でき、すべてのプロジェクトから要求できます。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: Recycle
    nfs:
      path: /tmp
      server: 172.17.0.2

各 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

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

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

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

OpenShift Online では、Kubernetes および OpenShift Online リソースの単一の受付チェーンを使用できます。これは、複数の個別の受付チェーンが使用されていた以前の状況からの変更点です。これは、トップレベルの admissionConfig.pluginConfig 要素に kubernetesMasterConfig.admissionConfig.pluginConfig に含まれていた受付プラグイン設定が含まれることを意味しています。

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

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

admissionConfig:
  pluginConfig:
    AlwaysPullImages: 

      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false 

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

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

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

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

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 Online には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。OpenShift Online は、サービスの 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 Online ルートは、外部クライアントが名前で到達できるように www.example.com などのホスト名でサービスを公開します。

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

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