type
status
date
slug
summary
tags
category
icon
password

目標

デプロイされたアプリケーションを管理するためにリソースを操作する。

目的

  • Podのレプリカ数を制御する。
  • Podのスケジューリング方法を説明し、制御する。
  • アプリケーションのビルドに使用されるイメージ、イメージストリーム、およびテンプレートを管理する。

セクション

  • アプリケーションのスケーリング（および実践演習）
  • Podのスケジューリング制御（および実践演習）
  • イメージ、イメージストリーム、およびテンプレートの管理（および実践演習）

ラボ

  • アプリケーションデプロイメントの管理

アプリケーションのスケーリング

目的

このセクションを完了すると、Pod のレプリカ数を制御できるようになります。

レプリケーションコントローラー

レプリケーションコントローラーは、指定された数のPodが常に稼働していることを保証します。
  • Podが削除されたり管理者によって明示的に削除された場合、新たなPodを作成します。
  • 逆に、実行中のPodの数が指定されたレプリカ数を超えた場合、不要なPodを削除して調整します。

レプリケーションコントローラーの主な構成要素

  1. 希望するレプリカ数
  1. レプリケートするPodの定義
  1. 管理対象の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）を設定する必要があります。
📖 参考情報
 
Relate Posts
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説！
Lazy loaded image
03-IBM Cloud 柔らか層本 メモ：Classic Infrastructure
Lazy loaded image
02-IBM Cloud 柔らか層本 メモ：Virtual Private Cloud（VPC）概要
Lazy loaded image
01-IBM Cloud 柔らか層本 メモ：IBM Cloudとは
Lazy loaded image
Arcserve入門
Lazy loaded image
01：Ansible概要
Lazy loaded image
59- 第13章：永続ストレージの割り当て-4：ラボ61- 第14章：アプリケーションデプロイメントの管理-2：アプリケーションスケーリングの演習
Loading...
minami
minami
一个普通的干饭人🍚
Announcement

🎉 ブログへようこそ 🎉

notion image
名前:みなみ独立事務所
性別:男
国籍:China
完全独学だけで基本情報をはじめ31個の資格を仕事をしながら合格。 現在はIT会社の技術担当や、ブログの執筆や学習支援などを手掛けています。 独学で合格できる学習法、勉強法、試験対策を配信します！

📚 主な内容

💻 IT・システム開発
🏠 不動産 × 宅建士
🎓 MBA 学習記録

🔍 コンテンツの探し方

現在、サイトのデザインはシンプルなため、情報がやや探しにくいかもしれません。
気になるテーマを探す際は、タグ検索の利用をおすすめします。
Search | みなみの風物詩
自分らしく未来へ
Search | みなみの風物詩
https://www.minami.ac.cn/search
Search | みなみの風物詩
Catalog
0%