8.3. OpenShift Container Platform 用の Kubernetes マニフェストの作成
コンテナーイメージは、コンテナー化されたアプリケーション用の基本的なビルディングブロックですが、OpenShift Container Platform などの Kubernetes 環境でそのアプリケーションを管理し、デプロイするには、より多くの情報が必要になります。イメージ作成後に実行される通常の手順は以下のとおりです。
- Kubernetes マニフェストで使用する各種リソースを理解する
- 実行するアプリケーションの種類に関する決定
- サポートコンポーネントの収集
- マニフェストの作成、およびそのマニフェストの Git リボジトリーへの保管。これにより、マニフェストをソースバージョン管理システムに保管し、監査と追跡、次の環境へのプロモートとデプロイ、必要な場合は以前のバージョンへのロールバックなどを実行でき、これを他者と共有することができます。
8.3.1. Kubernetes Pod およびサービスについて
コンテナーイメージは Docker を使用する基本単位であり、Kubernetes が使用する基本単位は Pod と呼ばれます。Pod はアプリケーションのビルドの次の手順で使用されます。Pod には、1 つ以上のコンテナーを含めることができます。Pod はデプロイやスケーリングおよび管理を実行する単一の単位であることに留意してください。
Pod での実行内容を決定する際に考慮する必要のある主要な点として、スケーラビリティーと namespace を考慮することができます。デプロイメントを容易にするには、コンテナーを Pod にデプロイして、Pod 内に独自のロギングとモニタリングコンテナーを含めることができるかもしれません。後に、Pod を実行し、追加のインスタンスをスケールアップすることが必要になると、それらの他のコンテナーもスケールアップできます。namespace の場合、Pod 内のコンテナーは同じネットワークインターフェイス、共有ストレージボリューム、メモリーや CPU などのリソース制限を共有します。これにより、Pod のコンテンツを単一の単位として管理することが容易になります。また Pod 内のコンテナーは、System V セマフォや POSIX 共有メモリーなどの標準的なプロセス間通信を使用することにより、相互に通信することができます。
個々の Pod が Kubernetes 内のスケーラブルな単位を表すのに対し、サービス は、負荷分散などの完全なタスクを実行する完全で安定したアプリケーションを作成するために複数の Pod をグループ化する手段を提供します。 また、サービスは削除されるまで同じ IP アドレスで利用可能な状態になるため、Pod より永続性があります。サービスが使用できる状態の場合、サービスは名前で要求され、OpenShift Container Platform クラスターはその名前を IP アドレスとポートに解決し、そこからサービスを設定する Pod に到達することができます。
性質上、コンテナー化されたアプリケーションは、それらが実行されるオペレーティングシステムから分離され、したがってユーザーからも分離されます。Kubernetes マニフェストの一部には、コンテナー化されたアプリケーションとの通信の詳細な制御を可能にする ネットワークポリシー を定義して、アプリケーションを内外のネットワークに公開する方法が記述されています。HTTP、HTTPS の受信要求やクラスター外からの他のサービスをクラスター内のサービスに接続するには、Ingress リソースを使用することができます。
コンテナーが、サービスを通じて提供されるデータベースストレージではなくディスク上のストレージを必要とする場合、ボリューム をマニフェストに追加して、そのディスクを Pod で使用可能にすることができます。永続ボリューム (PV) を作成するか、Pod 定義に追加されるボリュームを動的に作成するようにマニフェストを設定することができます。
アプリケーションを設定する Pod のグループを定義した後に、それらの Pod を Deployment および DeploymentConfig オブジェクトで定義できます。
8.3.2. アプリケーションのタイプ
次に、アプリケーションのタイプが、その実行方法にどのように影響するかを検討します。
Kubernetes は、各種のアプリケーションに適した異なるタイプのワークロードのタイプを定義します。アプリケーションに適したワークロードを決定するために、アプリケーションが以下のどのタイプに該当するかを確認してください。
-
完了まで実行されることが意図されている。 例として、アプリケーションはレポートを作成するために起動される場合、レポートの完了時に終了することが想定されます。このアプリケーションはその後一ヵ月間再度実行されない場合もあります。これらのタイプのアプリケーションに適した OpenShift Container Platform オブジェクトには、
JobおよびCronJobオブジェクトがあります。 - 継続的に実行することが予想されている。 長時間実行されるアプリケーションの場合、デプロイメント を作成できます。
-
高い可用性が必要。 使用しているアプリケーションに高可用性が必要な場合は、2 つ以上のインスタンスを持てるようにデプロイメントのサイズを設定する必要があります。
DeploymentまたはDeploymentConfigオブジェクトの場合、このタイプのアプリケーション用に レプリカセット を組み込むことができます。レプリカセットを使用すると、Pod は複数のノード間で実行され、ワーカーが停止してもアプリケーションを常に利用可能な状態にすることができます。 - すべてのノード上で実行される必要がある。 Kubernetes アプリケーションのタイプによっては、すべてのマスターまたはワーカーノード上のクラスターで実行することが意図されています。DNS およびモニタリングアプリケーションは、すべてのノード上で継続的に実行する必要があるアプリケーションの例です。このタイプのアプリケーションは、デーモンセット として実行することができます。また、デーモンセットはノードラベルに基づいて、ノードのサブセット上でも実行できます。
- ライフサイクル管理を必要とする。 アプリケーションが他者も使用できるようにする場合には、Operator を作成することを検討してください。Operator を使用すると、インテリジェンスを組み込むことが可能となり、自動的なバックアップやアップグレードなどを自動かできます。Operator Lifecycle Manager (OLM) と組み合わせることで、クラスターマネージャーは、Operator を選択された namespace に公開し、クラスター内のユーザーが Operator を実行できるようになります。
-
アイデンティティーまたは番号付けの要件がある。アプリケーションには、アイデンティティーや番号付けの要件がある場合があります。 たとえば、アプリケーションの 3 つのインスタンスのみを実行し、インスタンスに
0、1、2という名前を付けることが求められる場合があります。このアプリケーションには、ステートフルセット が適しています。 ステートフルセットは、データベースや zookeeper クラスターなどの独立したストレージが必要なアプリケーションに最も適しています。
8.3.3. 利用可能なサポートコンポーネント
作成するアプリケーションには、データベースやロギングコンポーネントなどのサポートコンポーネントが必要な場合があります。このニーズに対応するために、OpenShift Container Platform の Web コンソールで利用可能な以下のカタログから必要なコンポーネントを取得できる場合があります。
- OperatorHub: 各 OpenShift Container Platform 4.14 クラスターで利用できます。OperatorHub により、Red Hat、認定 Red Hat パートナー、コミュニティーメンバーおよびクラスターのオペレーターなどから Operator が利用可能になります。クラスター Operator は、それらの Operator をクラスター内のすべての場所または選択された namespace で利用可能にします。そのため、開発者は Operator を起動し、それらをアプリケーションと共に設定することができます。
-
テンプレート: ワンオフタイプのアプリケーションの場合に役立ちます。この場合、インストール後のコンポーネントのライフサイクルは重要ではありません。テンプレートは、最小限のオーバーヘッドで Kubernetes アプリケーションの開発を始める簡単な方法を提供します。テンプレートは、
Deployment、Service、Route、またはその他のオブジェクトなどのリソース定義のリストである場合があります。名前またはリソースを変更する必要がある場合に、それらの値をパラメーターとしてテンプレートに設定できます。
サポートする Operator およびテンプレートは、開発チームの特定のニーズに合わせて設定し、開発者が作業に使用する namespace で利用可能にすることができます。 多くの場合、共有テンプレートは他のすべての namespace からアクセス可能になるために openshift namespace に追加されます。
8.3.4. マニフェストの適用
Kubernetes マニフェストを使用して、Kubernetes アプリケーションを設定するコンポーネントのより詳細な情報を得ることができます。これらのマニフェストは YAML ファイルとして作成し、oc apply などのコマンドを実行して、それらをクラスターに適用してデプロイできます。
8.3.5. 次のステップ
この時点で、コンテナー開発のプロセスを自動化する方法を検討します。この際、イメージをビルドしてレジストリーにプッシュするいくつかの CI パイプラインがあることが望ましいと言えます。とくに GitOps パイプラインは、アプリケーションのビルドに必要なソフトウェアを保管する Git リボジトリーにコンテナー開発を統合します。
ここまでのワークフローは以下のようになります。
-
Day 1: YAML を作成します。次に
oc applyコマンドを実行して、YAML をクラスターに適用し、機能することを確かめます。 - Day 2: YAML コンテナー設定ファイルを独自の Git リポジトリーに配置します。ここから、アプリのインストールやその改善の支援に携わるメンバーが YAML をプルダウンし、アプリを実行するクラスターにこれを適用できます。
- Day 3: アプリケーション用の Operator の作成を検討します。
