Kubernetes ReplicaSets: 簡単な紹介

Kubernetes ReplicaSets: 簡単な紹介

  • ITOps・DevOps
6分で読めます 更新日 Jan 9, 2019

ポイント: 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に関する詳細は、これらのリソースを探索してください:

これらの投稿は私自身のものであり、BMCの立場、戦略、または意見を必ずしも表すものではありません。

ITOps・DevOpsの関連記事

BMCからのさらなる情報に興味がありますか?

ザ・ブリーフは、メインフレームとエンタープライズオーケストレーションに関する月刊メールです:研究、顧客ストーリー、製品ニュース、イベント。

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ザ・ブリーフに登録しました

ザ・ブリーフは、メインフレームとエンタープライズオーケストレーション—BMC AMIおよびControl-M—に関するアナリストの研究、顧客の展開、両者にわたるイベントを網羅しています。