3.3. Pod およびサービス
3.3.1. Pod
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 はユーザーから直接管理されるのでははく、ハイレベルの コントローラー で管理される必要があります。
OpenShift Container Platform ノードホストごとの Pod の最大数については、クラスターの最大値 について参照してください。
レプリケーションコントローラー によって管理されないベア Pod はノードの中断時に再スケジュールされません。
以下は Pod のサンプル定義です。これは数多くの Pod の機能を示していますが、それらのほとんどは他のトピックで説明されるため、ここではこれらについて簡単に説明します。
Pod オブジェクト定義 (YAML)
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
- 1
- Pod には 1 つまたは複数の ラベル でタグ付けすることができ、このラベルを使用すると、一度の操作で Pod グループの選択や管理が可能になります。これらのラベルは、キー/値形式で
metadata
ハッシュに保存されます。この例で使用されているラベルは docker-registry=default です。 - 2
- Pod にはそれらの namespace 内に任意の名前がなければなりません。Pod 定義は
generateName
属性で名前のベースを指定できますが、一意の名前を生成するためにランダムな文字が自動的に追加されます。 - 3
コンテナー
はコンテナー定義の配列を指定します。 この場合 (ほとんどの場合)、これは 1 つのみになります。- 4
- 必要な値を各コンテナーに渡すために、環境変数を指定することができます。
- 5
- Pod の各コンテナーは独自の Docker 形式のコンテナーイメージ からインスタンス化されます。
- 6
- コンテナーは、Pod の IP で利用可能にされるポートにバインドできます。
- 7
- OpenShift Container Platform は、コンテナーが特権付きコンテナーとして実行されるか、選択したユーザーとして実行されるかどうかを指定するセキュリティーコンテキストを定義します。デフォルトのコンテキストには多くの制限がありますが、管理者は必要に応じてこれを変更できます。
- 8
- コンテナーは外部ストレージボリュームがコンテナー内にマウントされるかどうかを指定します。この場合、レジストリーのデータを保存するためのボリュームと、OpenShift Container Platform API に対して要求を行うためにレジストリーが必要とする認証情報へのアクセス用のボリュームがあります。
- 9
- 10
- OpenShift Container Platform API に対して要求する Pod は一般的なパターンです。この場合、
serviceAccount
フィールドがあり、これは要求を行う際に Pod が認証する必要のある サービスアカウント ユーザーを指定するために使用されます。これにより、カスタムインフラストラクチャーコンポーネントの詳細なアクセス制御が可能になります。 - 11
- Pod は、コンテナーで使用できるストレージボリュームを定義します。この場合、レジストリーストレージの一時的なボリュームおよびサービスアカウントの認証情報が含まれる
secret
ボリュームが提供されます。
この Pod 定義には、Pod が作成され、ライフサイクルが開始された後に OpenShift Container Platform によって自動的に設定される属性が含まれません。Kubernetes Pod ドキュメント には、Pod の機能および目的についての詳細が記載されています。
3.3.1.1. Pod 再起動ポリシー
Pod 再起動ポリシーは、Pod のコンテナーの終了時に OpenShift Container Platform が応答する方法を決定します。このポリシーは Pod のすべてのコンテナーに適用されます。
以下の値を使用できます。
-
Always
: Pod が再起動するまで、Pod で正常に終了したコンテナーの継続的な再起動を、指数関数のバックオフ遅延 (10 秒、20 秒、40 秒) で試行します。デフォルトはAlways
です。 -
OnFailure
: Pod で失敗したコンテナーの継続的な再起動を、5 分を上限として指数関数のバックオフ遅延 (10 秒、20 秒、40 秒) で試行します。 -
Never
: Pod で終了したコンテナーまたは失敗したコンテナーの再起動を試行しません。Pod はただちに失敗し、終了します。
いったんノードにバインドされた Pod は別のノードにバインドされなくなります。これは、Pod がのノードの失敗後も存続するにはコントローラーが必要であることを示しています。
条件 | コントローラーのタイプ | 再起動ポリシー |
---|---|---|
(バッチ計算など) 終了することが予想される Pod |
| |
(Web サービスなど) 終了しないことが予想される Pod |
| |
マシンごとに 1 回実行される必要のある Pod | Daemonset | 任意 |
Pod のコンテナーが失敗し、再起動ポリシーが OnFailure
に設定される場合、Pod はノード上に留まり、コンテナーが再起動します。コンテナーを再起動させない場合には、再起動ポリシーの Never
を使用します。
Pod 全体が失敗すると、OpenShift Container Platform は新規 Pod を起動します。開発者はアプリケーションが新規 Pod で再起動される可能性に対応する必要があります。とくに、アプリケーションは、一時的なファイル、ロック、以前の実行で生じた未完成の出力などを処理する必要があります。
Kubernetes アーキテクチャーでは、クラウドプロバイダーからの信頼性のあるエンドポイントが必要です。クラウドプロバイダーが停止している場合、kubelet は OpenShift Container Platform が再起動されないようにします。
基礎となるクラウドプロバイダーのエンドポイントに信頼性がない場合は、クラウドプロバイダー統合を使用してクラスターをインストールしないでください。クラスターを、非クラウド環境で実行する場合のようにインストールします。インストール済みのクラスターで、クラウドプロバイダー統合をオンまたはオフに切り替えることは推奨されていません。
OpenShift Container Platform が失敗したコンテナーについて再起動ポリシーを使用する方法の詳細は、Kubernetes ドキュメントの State の例 を参照してください。