Kubernetes Deployments: The Ultimate GuideーPart2

Kubernetesのデプロイメント ：究極のガイド パート2

今回の記事はKubernetesのデプロイメントに関しての記事です。少し長いので4つに分けて投稿します。第2回目はレプリカセットなどについてです。

Replica sets make scaling pods easy

もし私たちがポッドを持っていて、全く同じのポッドがほしいと思ったら、Kubernetesにまた戻って「ウェブ２という名前のポッドがほしい。そのポッドの特徴は～～」とお願いします。そして、同じ特徴のものを再利用します。そえから、ポッドが必要なときはずっとそれを何回でも繰り返します。

これはむしろ不便です。というのも、それら全てのポッドを追跡し続けるのが私たちの役目だからです。そして、それらのポッドが全てsyncの中に入っていて同じ仕様を使うということを確認していく必要があります。

それらをよりシンプルにするために、Kubernetesによってレプリカセットという高レベルの構造が提供されます。レプリカセットの仕様はポッドの仕様にすごくよく似ているように見えます。数字を運ぶというところは似ていませんが、必要なレプリカの数（つまり、その特定の仕様を持つポッド）を示すというところはとてもよく似ています。

Kubernetesに「ウェブという名前のレプリカセットがほしい、３つのポッドがあって、そのポッドの特徴は～」と伝えます。するとKubernetesはそれに準じて３つのマッチするポッドそのものを作ってくれます。もし、全く０から始めた場合でも、３つのポッドは生成されるでしょう。もし既に３つのポッドを持っている場合は、何も起こりません。というのも欲しいものを既に手に入れているからです。

# pod-replicas.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: web-replicas
labels:
app: web
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
app: web
tier: frontend
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

Replica sets are particularly relevant for scaling and high availability

レプリカセットは、特にスケーリングと高可用性に関連している

スケーリングの場合、既存のレプリカセットをアップデートして、必要なレプリカ数を変更できるためです。 結果として、Kubernetesはポッドを作成または削除するため、最終的に希望する数になります。

高可用性の場合、Kubernetesは継続的にクラスターの中で起こっていることをモニターします。そして、何も起こらなくても、希望した数があるということを確認してくれます。

ノードが下がった場合、ウェブポッドの一つを取得し、Kubernetesは置き換えるために他のポッドを生成します。ノードがダウンしていないことが判明したが、しばらくの間単に到達不能または応答しなくなったことが判明した場合、戻ったときにポッドが1つある可能性があります。 その後、Kubernetesはポッドを終了して、要求された番号が正確に残っていることを確認します。

What happens when we change the definition of a pod?

ポッドの設定を変えると何が起こるのでしょうか。

通常ポッドの設定はあまり変えることがありません。例えば、よくより新しいバージョンのコンテナイメージに置き換えたいときなどです。

覚えておくこと：レプリカセットの目的は「この仕様に対応するNポッドがあるということを確かめること」です。その設定を変更したらどうなるでしょうか？突然、新しい仕様に対応したゼロポッドができました。

今までdeclarativeシステムがどのように機能するかを見てきました。つまり、Kubernetesはすぐに新しい仕様に合ったNポッドを作る必要がありということです。その古いポッドは手動で排除されるまでは存在します。

それらのポッドがきれいに自動的に CI/CD パイプラインで取り除かれると、そして新しいポッドの作成がより緩やかに行われる可能性がある場合、とても便利だと思います。

間もなく公開されるKubernetesを伴ったCI/CDについての無料のebookのコピーが必要な方はこちらからサインアップしてください。.

Deployments drive replica sets

デプロイメントがレプリカセットをコントロールします。

これはまさにデプロイメントの役割です。一見、その デプロイメント の仕様というのはレプリカセットの仕様ととてもよく似ているように見えます。ポッドの仕様￥とレプリカの数という特徴があります。（そして、また他にもありますがそれは後ほどお話したいと思います）

# deployment-nginx.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80

しかし、デプロイメントは、ポッドを直接生成したり削除したりはしません。デプロイメントはその作業を1つ以上のレプリカセットに委任します。

デプロイメントを生成するとき、指定した正確なポッド仕様を使用してレプリカセットを生成します。

デプロイメントをアップデートし、レプリカの数を調整するとき、デプロイメントは、そのアップデートがレプリカセットまで届きます。

When the configuration changes

ポッドの仕様そのものをアップデートしなければいけないとき、とても興味深いことになります。例えば、仕様するイメージ、もしくはアプリケーションのパラメーターを（コマンドライン引数、 環境変数、コンフィグレーションファイルなどを通して）変更したいと思った場合（というのも新しいバージョンがリリースされるから）場合です。

ポッドの仕様をアップデートする場合、デプロイメントはアップデートされたポッドを伴った新しいレプリカセットを生成します。そのレプリカセットの初期サイズはゼロです。 次に、そのレプリカセットのサイズは徐々に大きくなり、他のレプリカセットのサイズは小さくなります。

サウンドミキシングボードが目の前にあり、新しいレプリカセットではフェードイン（音量を上げる）し、古いレプリカセットではフェードアウト（音量を下げる）することが想像できます。

プロセス全体を通して、ユーザーが中断することなく、古いレプリカセットと新しいレプリカセットの両方のポッドにリクエストが送信されます。

これは全体像ですが、このプロセスをさらに強靭にするために、もっと細かい設定があります。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。