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.access.redhat.com にてレジストリーを提供しています。OpenShift Container Platform はカスタムコンテナーイメージを管理するための独自の内部レジストリーも提供します。

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

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

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

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

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

以下は Pod のサンプル定義です。これは、統合コンテナーレジストリーという OpenShift Container Platform インフラストラクチャーの一部で、長期間実行されるサービスを提供します。これは数多くの 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 は、サービスが一貫して利用可能な状態である場合に任意でサービスに追加したり削除したりでき、サービスに依存するすべてのものが一貫したアドレスでサービスを参照できます。デフォルトのサービス clusterIP アドレスは OpenShift Container Platform 内部ネットワークからのもので、Pod が相互にアクセスできるようにするために使用されます。

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

サービスには、アクセス時に該当のサポートする Pod にプロキシー化される 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:
  ExternalIPNetworkCIDR: 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 要求は、anonymous (匿名) システムユーザーによる要求として認証されます。認証が実行されると、ユーザーの実行が許可される内容がポリシーによって決定されます。

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

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

システムのほとんどのオブジェクトのスコープは namespace 別に設定されますが、一部にはノードやユーザーを含め、予想されるもので namaspace がないものがあります。

Kubernetes ドキュメントには namespace についてのさらに詳細な情報が記載されています。

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

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

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

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

開発者および管理者は、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 イメージを参照するための抽象化を提供します。イメージストリームとそのタグを使用して、利用可能なイメージを確認し、リポジトリーのイメージが変更される場合でも必要な特定のイメージを使用していることを確認できます。

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

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

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

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

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

(ビルド設定またはデプロイメント設定などの) イメージストリームタグを参照するオブジェクトを定義する際は、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 のインスタンス数を判別します。

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

レプリケーションコントローラーは、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 を作成することを目的としている点でレプリケーションコントローラーに似ています。相違点としては、レプリケーションコントローラーは継続的に実行されている Pod を対象としていますが、ジョブは 1 回だけ実行する (one-time) 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 で作成されるオブジェクトの一覧を生成するためにパラメーター化され、処理されるオブジェクトのセットを記述します。作成するオブジェクトには、ユーザーがプロジェクト内で作成するパーミッションを持つすべてのものが含まれます。たとえば、サービス、ビルド設定、およびデプロイメント設定などが含まれます。テンプレートは、テンプレートで定義されるすべてのオブジェクトに適用されるラベルのセットも定義します。

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