type
status
date
slug
summary
tags
category
icon
password
书籍
目標
デプロイされたアプリケーションを管理するためにリソースを操作する。
目的
- Podのレプリカ数を制御する。
- Podのスケジューリング方法を説明し、制御する。
- アプリケーションのビルドに使用されるイメージ、イメージストリーム、およびテンプレートを管理する。
セクション
- アプリケーションのスケーリング（および実践演習）
- Podのスケジューリング制御（および実践演習）
- イメージ、イメージストリーム、およびテンプレートの管理（および実践演習）
ラボ
- アプリケーションデプロイメントの管理
アプリケーションのスケーリング
目的
このセクションを完了すると、Pod のレプリカ数を制御できるようになります。
レプリケーションコントローラー
レプリケーションコントローラーは、指定された数のPodが常に稼働していることを保証します。
- Podが削除されたり管理者によって明示的に削除された場合、新たなPodを作成します。
- 逆に、実行中のPodの数が指定されたレプリカ数を超えた場合、不要なPodを削除して調整します。
レプリケーションコントローラーの主な構成要素
- 希望するレプリカ数
- レプリケートするPodの定義
- 管理対象のPodを識別するセレクター
セレクターは、レプリケーションコントローラーが管理するすべてのPodが持つべきラベルの集合です。
また、レプリケーションコントローラーが新しく作成するPodの定義にも同じラベルを含める必要があります。
このセレクターを使って、すでに実行中のPodの数を把握し、適切にスケール調整を行います。
注意:
レプリケーションコントローラーは自動スケーリングを行いません。負荷やトラフィックを監視しないためです。
水平Podオートスケーラー（Horizontal Pod Autoscaler） を使用すると、後述の方法で自動スケーリングを実現できます。
Kubernetesの管理者は通常、レプリケーションコントローラーを直接管理しますが、OpenShiftの推奨方法は、デプロイメント設定（DeploymentConfig） を利用し、レプリケーションコントローラーを必要に応じて作成・変更することです。
デプロイメント設定からのレプリケーションコントローラーの作成
OpenShiftでアプリケーションを作成する最も一般的な方法は、以下のいずれかです。
oc new-appコマンドを使用する
- Webコンソールを利用する
この方法で作成されたアプリケーションは、DeploymentConfig リソースを使用します。
このリソースが実行時にレプリケーションコントローラーを作成し、アプリケーションのPodを管理します。
DeploymentConfig の役割
- 作成するPodのレプリカ数を定義する
- 作成するPodのテンプレートを指定する
重要:
DeploymentConfig や ReplicationController の template 属性と、OpenShift の**テンプレートリソース（Template Resource）**を混同しないように注意してください。後者は、特定のプログラミング言語やフレームワークに基づいてアプリケーションを構築するためのものです。
MySQLデータベースのDeploymentConfigの例
以下は、
oc new-app コマンドを使用して作成された MySQL データベースコンテナの DeploymentConfig リソースの例です。ポイント:
replicas: Podのレプリカ数を指定する。
selector: Podのカウントに使用され、サービスのロードバランスにも使われる。
template: レプリケーションコントローラーが作成するPodのテンプレート。
labels: 作成されるPodのラベルは、selectorのラベルと一致する必要がある。
アプリケーションのレプリカ数を変更する
DeploymentConfig または ReplicationController リソースのレプリカ数は、
oc scale コマンドを使用して動的に変更できます。DeploymentConfig リソースは、この変更を ReplicationController に伝え、ReplicationController は新しい Pod（レプリカ）を作成したり、既存の Pod を削除したりして、指定された数に調整します。
ReplicationController リソースを直接操作することも可能ですが、推奨される方法は DeploymentConfig を操作することです。なぜなら、コンテナイメージの新しいリリースによってデプロイがトリガーされると、ReplicationController の直接の変更が失われる可能性があるためです。
Pod のオートスケール（自動スケール）
OpenShift では、HorizontalPodAutoscaler（HPA） リソースを使用して、アプリケーションの負荷に応じて DeploymentConfig のスケールを自動化できます。
HPA は、OpenShift の メトリクスサブシステム（Metrics Subsystem） が収集したパフォーマンスデータを基に動作します。本書の後半で説明しますが、特に Heapster コンポーネント がないとオートスケールは機能しません。
HPA を作成する推奨方法は、
oc autoscale コマンドを使用することです。このコマンドは、CPU 使用率を 80% 以下に保つように、myapp の DeploymentConfig のレプリカ数を調整する HorizontalPodAutoscaler リソースを作成します。
- 最小・最大レプリカ数（--min, --max） を設定することで、急な負荷増加に対応しつつ、OpenShift クラスタが過負荷にならないように調整できます。
- 負荷の変動が大きい場合は、あらかじめ一定数の Pod を用意しておくことを推奨します。逆に、レプリカ数が多すぎると、クラスタのリソースを圧迫し、他のアプリケーションに影響を与える可能性があります。
HPA リソースの情報を取得するには、
oc get および oc describe コマンドを使用します。⚠ 注意
HPA は、Pod が適切な リソースリクエスト（resource requests） を定義している場合にのみ機能します（リソースリクエストの詳細は後述）。
oc new-app コマンドで作成した Pod は、デフォルトではリソースリクエストを定義していないことが多いため、HPA を使用する場合は、カスタム YAML や JSON ファイルを作成するか、プロジェクトにリソース範囲（resource range）を設定する必要があります。📖 参考情報
- ReplicationController についての詳細は、Red Hat OpenShift Container Platform の アーキテクチャ章 を参照:OpenShift Container Platform Documentation
- Pod のオートスケールについての詳細は、Developer Guide 章 を参照:OpenShift Container Platform Documentation
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/1a9d7ae8-88e2-808e-974f-dcd0d9a7abce
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
