レプリケーションコントローラーとレプリカセットを使用してポッドを管理する

これまでに学習した基本的な使用方法の一部はPod直接操作されますPod。オンラインサービスがある場合Pod、遭遇する可能性のあるいくつかのシナリオについて考えてみましょう。

ある運営活動が大成功し、Webサイトのアクセス数が一気に増加
現在実行中のPodノードに障害が発生したため、Podサービスを正常に提供できません

前者の場合は、一般的なイベントの前に訪問者数を大まかに計算し、事前にいくつかの訪問者を開始し、イベント終了後に超過分を殺すことを考えPodますPod。ちょっと面倒ですが、それでも対処できるはずです。

2 番目のケースでは、ある夜にサービスがダウンしているという大量のアラームを受信し、その後起きてコンピュータの電源を入れ、別のノードで新しいコンピュータを再起動すると、問題は非常にうまく解決されますPod。

これらの問題をすべて手動で解決したら、焼き畑の時代に戻ったように見えますよね? 管理に役立つツールがあれば、そうでない場合は自動的に追加されPodます上記の問題を手動で解決する必要がないように、Pod適切Podなノードで再起動してください。Pod

幸いなことに、Kubernetesこのようなリソースオブジェクトが提供されています。

レプリケーションコントローラー: デプロイとアップグレードに使用されますPod
レプリカセット: 次世代Replication Controller
導入: より便利な管理PodとReplica Set

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

Replication Controllerこの略語はシステムの中核となる概念の 1 つでRCあり、簡単に言うと、いつでも実行できることが保証されるコピー数を意味しRCます。実際の数が指定した数より大きい場合は、冗長なものを終了します。実際の数が指定した数より小さい場合は、新しいものを開始します。失敗した場合、削除された場合、またはハングアップした場合は、自動的に新しいものを作成して、コピー数を確保するため、たとえ 1 つしかなくても、それを管理するために使用する必要があります。KubernetesRCPodPodPodPodPodRCPodPodRCPod

考えてみましょう。今上記の問題が発生した場合、完全に自動化できない最初の問題を除いて、残りについては心配する必要はありません。実行中のノードがハングアップして検出に失敗した場合PodはRC、Pod1 つのノードを再起動するPodだけ、新しいノードを手動で作成する必要はありませんPod。最初のケースであれば、Podイベント開始前に 10 部を割り当て、イベント終了後に部数を 2 に変更します。これは、手動で開始して手動で閉じるよりもはるかに優れています。後でやらせてくださいリソースの使用状況に応じて自動的に拡大および縮小できる別のリソースオブジェクトを導入することHPAで、将来そのような状況でも実際にスリープ状態に入ることができるようになります。

RC先ほど使用したNginxものを管理するために使用してみましょうPod。YAMLファイルは次のとおりです。

apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-demo
  labels:
    name: rc
spec:
  replicas: 3
  selector:
    name: rc
  template:
    metadata:
     labels:
       name: rc
    spec:
     containers:
     - name: nginx-demo
       image: nginx
       ports:
       - containerPort: 80

上記のYAMLファイルは、以前のPod形式に関連しています。

親切：ReplicationController
spec.replicas:Podレプリカの数を指定します。デフォルトは 1 です。
spec.selector:RCこの属性を使用して、制御対象をフィルタリングします。Pod
spec.template: これは以前に定義したモジュールですが、追加する必要PodはありませんapiVersionkind
spec.template.metadata.labels:現在のものを制御できるように、ここにPodあるものは同じでlabelsある必要があることに注意してください。spec.selectorRCPod

このYAMLファイルの意味は、リソースオブジェクトを定義することですRC。その名前はですrc-demo。常に 3 つが実行されることが保証されておりPod、Podミラーのミラーはnginxミラーです。

spec.selectorこれら 2 つのフィールドは同じである必要があることに注意してください。そうでない場合、作成は失敗します。もちろん、デフォルトでテンプレート内のフィールドと同じになるように、フィールドをspec.template.metadata.labels省略することもできます。したがって、不要な間違いを避けるためには、書かない方がよいでしょう。spec.selectorPodmetadata.labels

次に、上記のオブジェクトを作成しましょうRC(rc-demo.yaml として保存)。

$ kubectl create -f rc-demo.yaml

表示RC:

$ kubectl get rc

特定の情報を表示します。

$ kubectl describe rc rc-demo

次に、次のようにしてコピー数を 2 にRC変更します。Pod

$ kubectl apply -f rc-demo.yaml

また

$ kubectl edit rc rc-demo

また、ローリングアップグレードRCにも使用。たとえば、ミラーアドレスを次のように変更しますnginx:1.7.9。

$ kubectl rolling-update rc-demo --image=nginx:1.7.9

ただし、複数のコンテナがある場合は、ファイルを変更Podして変更する必要があります。YAML

$ kubectl rolling-update rc-demo -f rc-demo.yaml

アップグレードの完了後に新しい問題が発生し、ワンクリックで以前のバージョンにロールバックしたい場合は、RC同じ方法を使用してミラーアドレスを以前のアドレスに置き換えてから、アップグレードを再度ロールすることしかできません。

レプリケーションセット（RS）

Replication Setの略語はRS、の急速な発展に伴い、公式は代わりにとをKubernetes使用することを推奨しています。実際、との機能は基本的に同じです。唯一の違いは、等価ベース(env=dev またはenvironment!=qa)のみをサポートすることです。 ) ですが、コレクションベース(バージョン (v1.0、v2.0)) もサポートされており、複雑な運用および保守管理に非常に便利です。RSDeploymentRCRSRCRCselectorRSselector

kubectlコマンドラインツールで説明されているコマンドのほとんどは、リソースオブジェクトRCにも適用されますRS。ただし、これを単独で使用することはほとんどありませんRS。Deploymentユーザーがアップグレード機能をカスタマイズする必要がある場合や、まったくアップグレードする必要がない場合を除き、主にこの上位レベルのリソースオブジェクトによって使用されます。一般に、直接使用するのではなく、Podこれを使用することをお勧めしDeploymentますReplica Set。

RC最後に、 /の特徴と機能をいくつかまとめてみましょうRS。

ほとんどの場合、RC実装を定義することでPodコピーの作成と数を制御できます。
RC完全なPod定義モジュールを含めます (apiversionとを除くkind)
RCコピーの制御をlabel selector実現する機構Pod
RC内部のPod部数を変更することでPod拡大・縮小機能を実現できます
RC内のPodテンプレートでイメージのバージョンを変更することでPod、ローリングアップグレード機能を実現できます（ただし、ワンクリックロールバックはサポートされておらず、同様にイメージアドレスの変更が必要です）

ここでの最初の紹介を管理するには、RCまたはを使用します。RSPod