OpenShiftのレプリカセット管理入門
0.はじめに
OpenShift Container Platform(以下、OCP)入門者向けに、OpenShiftのレプリカセットついて解説します。
レプリカセット(ReplicaSet, RS)とは、指定された数のPodを常に維持するKubernetes/OpenShiftのリソースです。
Podが異常終了した場合に自動で再作成し、アプリケーションの高可用性とスケーラビリティを提供します。
では、次の章から具体的な解説を進めます!
1. レプリカセット(ReplicaSet)の概要
レプリカセット(ReplicaSet, RS)は、指定された数のPodを維持し、アプリケーションのスケーラビリティ、フォールトトレランス、高可用性を提供するKubernetesリソースです。
レプリカセットの特徴
- 可用性の確保: 指定された数のPodを常に稼働させる。
- 障害復旧: Podが異常終了した場合、自動で新しいPodを作成。
- シームレスな更新: ローリングアップデートを通じてアプリケーションを更新可能。
- ラベルとセレクターを使用: 担当するPodを識別・管理。
デプロイメントとの違い
- デプロイメント(Deployment)は、レプリカセットを管理する上位の概念。
- レプリカセットはPodの数を維持するのが目的だが、デプロイメントはローリングアップデートやロールバックなどの管理機能を提供する。
通常、レプリカセットを直接操作せず、デプロイメントを使うのが一般的。
2. レプリカセットのデプロイと管理
2.1 レプリカセットの作成
まずは、レプリカセットのYAMLファイルを作成します。
replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: bitnami/apache
このマニフェストでは、以下を定義しています:
- replicas: 3 → Podを3つ維持
-
selector.matchLabels →
app: my-app
を持つPodを管理対象にする -
template.metadata.labels → Podに
app: my-app
のラベルを付与
レプリカセットを作成
oc apply -f replicaset.yaml
2.2 レプリカセットの状態確認
レプリカセットのステータスを確認します。
oc describe rs/my-replicaset
oc get rs
oc get pods
ポイント:
-
oc get rs
→ レプリカセットの一覧を表示。 -
oc get pods
→ レプリカセットが管理しているPodの一覧を表示。
2.3 レプリカセットのスケーリング
レプリカ数を動的に変更する方法を確認します。
レプリカ数を5に増やす
oc scale rs my-replicaset --replicas=5
または、YAMLを編集して適用:
vi replicaset.yaml # replicas: 5 に変更
oc apply -f replicaset.yaml
レプリカ数を2に減らす
oc scale rs my-replicaset --replicas=2
2.4 レプリカセットの削除
oc delete rs my-replicaset
注意:
- レプリカセットを削除すると、管理していたPodも削除される。
3. レプリカセット vs デプロイメント
レプリカセットはPodの維持管理を行いますが、通常はデプロイメント(Deployment)を使うのが一般的です。
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- image: bitnami/apache:2.4
name: my-app-container
デプロイメントの適用
oc apply -f deployment.yaml
ステータス確認
oc get all
3.1 コンテナイメージを最新バージョンへ更新
デプロイメントを使うと、ローリングアップデートが可能です。
oc set image deployment/my-app-deployment my-app-container=bitnami/apache:latest
メリット
- ダウンタイムなしで更新できる(ローリングアップデート)
- ロールバックが簡単にできる
4. ラベルとセレクターを利用した管理
ラベル(Label)とセレクター(Selector)
を活用することで、リソースをより柔軟に管理できます。
4.1 ラベル付きPodの作成
labeled-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-labeled-pod
labels:
app: my-app
environment: production
tier: frontend
spec:
containers:
- name: my-container
image: bitnami/nginx
oc create -f labeled-pod.yaml
4.2 ラベルの確認
oc get pod my-labeled-pod --show-labels
4.3 セレクターを利用してリソースをフィルタリング
oc get pods -l app=my-app
環境ごとにフィルタリング:
oc get pods -l 'environment in (production, staging)'
4.4 ラベルの更新
oc label pod my-labeled-pod environment=staging --overwrite=true
4.5 ラベルの削除
oc label pod my-labeled-pod tier-
5. まとめ
今回はOpenShiftのレプリカセットについて理解を深めるために、以下を学びました。
項目 | レプリカセット(ReplicaSet) | デプロイメント(Deployment) |
---|---|---|
役割 | 指定した数のPodを維持する | レプリカセットを管理し、更新やロールバックを提供 |
スケール機能 | 手動でスケール変更が可能 | 自動スケールやローリングアップデートに対応 |
更新方法 | 直接変更し適用する |
oc set image で更新可能 |
推奨用途 | シンプルなPodの維持 | アプリケーションの運用管理 |
通常の管理対象 | 直接操作は少ない(デプロイメントが管理) | メインで使用するリソース |
ポイント
- レプリカセットはPodの数を維持するが、通常はデプロイメントを使う。
- デプロイメントはローリングアップデートやロールバックが可能なため、より管理がしやすい。
- ラベルとセレクターを利用すると、リソース管理がより柔軟になる。
1回で覚えるのは難しいと思うので、何度かトライして覚えるで全然大丈夫です。
今後もOpenShiftについて解説していきます。
おわりっ!
Discussion