ポイント: Kubernetes ReplicaSetsは、希望する数のポッドレプリカが実行されることを保証し、手動のポッド作成と比較してデプロイメントを簡素化します。このガイドでは、ReplicaSetsを効果的に使用し、作成する方法を説明します。
- ReplicaSetsはラベルセレクタを通じてポッドレプリカを管理します。
- マニフェストの例は、ReplicaSetsを定義し、デプロイする方法を示しています。
このブログ記事では、KubernetesにおけるReplicaSetの概念について説明します。以下について説明します:
- RSとは
- ReplicaSetsの用途
- 作成方法
この投稿では、ポッド、minikube、およびkubectlについての基本的な理解があることを前提としています。
ReplicaSetsとは?
ReplicaSetは、指定された数のポッドレプリカが実行されることを保証するKubernetesコントローラーの1つです。(Kubernetesにおけるコントローラーは、クラスタの期待される状態と観察された状態を一致させるためのタスクを管理します。)
RSがないと、必要なポッドの数に応じて複数のマニフェストを作成する必要があり、単一のアプリケーションのレプリカをデプロイするために多くの作業が必要になります。Kubernetesの以前のバージョンでは、ReplicaSetはReplication Controllerと呼ばれていました。両者の主な違いは、ReplicaSetsがラベルセレクタというものを使用できることです。
ラベルは、ユーザーにとって意味があり便利なオブジェクトの属性を指定するために使用されるキー・バリューのペアであり、コアシステムの動作を変更するものではないことを忘れないでください。 ラベルセレクタは、Kubernetes内のオブジェクトのセットを特定するために使用されます。
ReplicaSetsは「セットベース」のラベルセレクタを使用できるようにします(例: 環境が (production, qa) にあるまたは tierが (frontend, backend) にない)対して「等式ベース」(例: 環境 = production または tier != frontend)は、レプリケーションコントローラーと共に使用されます。
ReplicaSetsで使用するオペレーター
ReplicaSetsで使用できるオペレーターの種類は3つあります:
- In
- Notin
- Exists
ReplicaSetsは、セレクタと一致するラベルを持つすべてのポッドを管理します。ポッドが作成されると、すべてのポッドが区別されないため、同じラベルセレクタを持つ別のReplicaSetsを作成すると、前のReplicaSetsはそれらのポッドを作成したと考え、問題が発生します。
これは重要な点であるため、ReplicaSets間でラベルセレクタが一致しないようにしてください。
ReplicaSetマニフェストの例
apiVersion: apps/v1 # our API version
kind: ReplicaSet # The kind we are creating
Metadata: # Specify all Metadata like name, labels
name: some-name
labels:
app: some-App
tier: some-Tier
Spec:
replicas: 3 # Here is where we tell k8s how many replicas we want
Selector: # This is our label selector field.
matchLabels:
tier: some-Tier
matchExpressions:
- {key: tier, operator: In, values: [some-Tier]} # we are using the set-based operators
template:
metadata:
labels:
app: some-App
tier: someTier
Spec: # This spec section should look like spec in a pod definition
Containers:
APIVersion、kind、およびMetadataは、Kubernetes内の他のオブジェクトと似ていますが、Specセクションは他のオブジェクトとは少し異なります。実際、上記のマニフェスト例には2つのSpecがあります。最初のSpecは、レプリカセットがどのように見えるべきかを宣言し、2番目のspecはコンテナのためのものです。「.spec.template」は最初のspecセクションの唯一の必須フィールドです。レプリカを指定しない場合は、1つのポッドだけがデプロイされます。また、「.spec.template.metadata.labels」は「.spec.selector」に持っているものと正確に一致する必要があります(これが上記のマニフェストで確認できます)、さもなければKubernetesはそれを作成することを許可しません。
ReplicaSet: 例
さて、ReplicaSetが何であるかを理解したので、1つ作成しましょう。この例では、3つのレプリカを持つシンプルなフロントエンドnginxアプリを作成するreplica.yamlファイルをデプロイします。
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicas
labels:
app: myapp
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
app: myapp
tier: frontend
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
まず、kubectl createコマンドを実行してマニフェストを適用します
$ kubectl create -f replica.yaml
replicaset.apps "myapp-replicas" created
次に、作成されたことを確認します
$ kubectl get replicaset
NAME DESIRED CURRENT READY AGE
myapp-replicas 3 3 3 15s
3つがデプロイされ、3つが準備完了であることが確認できます。また、ポッドを確認することもできます。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-replicas-67rkp 1/1 Running 0 33s
myapp-replicas-6kfd8 1/1 Running 0 33s
myapp-replicas-s96sg 1/1 Running 0 33s
3つすべてが0回の再起動で実行されていることが確認でき、アプリケーションがクラッシュしていないことがわかります。また、オブジェクトを記述することもでき、レプリカについての詳細情報を得ることができます。
$ kubectl describe replicaset myapp-replicas
Name: myapp-replicas
Namespace: default
Selector: tier=frontend,tier in (frontend)
Labels: app=myapp
tier=frontend
Annotations:
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=myapp
tier=frontend
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment:
Mounts:
Volumes:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 12m replicaset-controller Created pod: myapp-replicas-6kfd8
Normal SuccessfulCreate 12m replicaset-controller Created pod: myapp-replicas-67rkp
Normal SuccessfulCreate 12m replicaset-controller Created pod: myapp-replicas-s96sg
ReplicaSet FAQ
ReplicaSetsに関する簡単なFAQです。
3つのレプリカがもう必要ない場合、今は1つだけ必要ですか?
必要なのは、レプリカフィールドの値を変更するだけで、k8sはその数にスケールします。例えば「replicas: 1」です。変更を加えて再適用すると、1つのレプリカだけが実行されます。
ReplicaSetsからポッドを削除できますか?
はい、できます。ポッドからラベルを削除するのは簡単で、セットから削除されます。
RSをクリーンアップする方法は?
レプリカセットを削除するには、「kubectl delete replicaset myapp-replicas」を実行するだけです。このコマンドは、レプリカセットとポッドを削除します。
一般的にKubernetesでは、レプリケーションコントローラーの代わりにデプロイメント(レプリカセットを管理し、ポッドへの宣言的な更新を提供する高レベルの概念)を使用することを推奨しています。
追加リソース
Kubernetesに関する詳細は、これらのリソースを探索してください:
Kubernetesガイド
- Kubernetesとは何か (K8s)? Kubernetes基礎チュートリアル
- Kubernetesのベストプラクティスによるクラスター効率の向上
- ベストプラクティス: Kubernetes用にアプリケーションを設計する方法
- Kubernetes Pods: はじめに
- Kubernetes ReplicaSets: 簡単な紹介
- Kubernetesデプロイメントの完全解説
- Kubernetes DaemonSetsの使用と管理
- Kubernetesサービスの仕組み
- Kubernetesのポート、ターゲットポート、ノードポートの使用
- KubernetesでのConfigMapの作成と使用
- Kubernetes Secretsの紹介
- Kubernetesネットワーキングの基本
- Kubernetes Ingressの解説
- Kubernetes Helmチャートの紹介
- Kubernetesオペレーターパターンとは?
- KubernetesでStatefulSetとしてPostgreSQLをデプロイ
- Kubernetesカスタムリソース定義 (CRDs) の解説
- クラウドネイティブアプリケーションのための3つのKubernetesパターン
- Kubernetesコンピュートリソースの解説
- DevOpsパイプラインのためのKubernetesセキュリティ
- KubernetesとSpinnakerを使用した継続的デリバリー
- Kubernetesマルチクラスタ: 使用方法と理由
- Kubernetesモニタリング: 包括的ガイド
- Kubernetes vs Docker: 簡単な比較
- Kubernetes vs Docker Swarm: コンテナオーケストレーションツールの比較
- Kubernetes vs OpenShift: 違いは何ですか?
- Kubernetes認定: 取得方法と理由
これらの投稿は私自身のものであり、BMCの立場、戦略、または意見を必ずしも表すものではありません。