概要

Kubernetesの目玉機能にローリングアップデートというものがあります。

これは、コンテナの更新の際になるべくダウンタイムを減らすために使用できます。

今回はこのローリングアップデートを使う方法について説明します。

ローリングアップデートとは

ローリングアップデートはダウンタイムをなるべくないようにしてアプリケーションを更新する方法のひとつです。

具体的なダウンタイムを減らす方法としては、稼働しているアプリケーションを順番に新しいバージョンのものに切り替えていくという方法でダウンタイムを減らしています。

Kubernetesでは、設定にもよりますが新しいバージョンのアプリケーションが動いているPodを起動して、起動が完了したら古いPodと置き換えていくということを行なっています。

maxSurgeとmaxUnavailable

Kubernetesでは、maxSurgeとmaxUnavailableという設定項目を使用して、ローリングアップデートの際の新規Podのデプロイの動作をある程度制御できます。

maxSurgeでは、replicasで設定している起動するコンテナの数を超えて起動できるコンテナの数を設定します。

maxUnavailableでは、正常動作していないPodの数をいくつまで許すかをしています。

例えば、replicasを3、maxSurgeを2、maxUnavailableを1とした場合、ローリングアップデートを行うと3つのPodのうち、ひとつのPodが動作しなくなります、つまりUnavailableとなります。そして、maxSurgeとして2を設定しているので、replicasの数から追加で2つPodを起動できるので、最大5つのPodを起動できることから、新しく置き換える予定の3つのPodが起動します。この起動を終えると、起動してあった古い2つのPodを新しく起動した3つのPodで置き換えます。これで新しいPodの3つで古いPodを置き換えることができ、ローリングアップデートがうまくできました。

もうひとつ例を挙げておきます。replicasを3、maxSurgeを2、maxUnavailableを0とした場合、ローリングアップデートを行うと、2つの新しいPodが起動し、起動を終えると古いPodを2つ置き換えます。次に1つの新しいPodが起動し、起動を終えると、残りの古い1つのPodを新しく起動したPodで置き換えます。これでローリングアップデートがうまくできました。

このように、ローリングアップデートの動作をある程度制御することができます。

設定方法

次に、YAMLで実際の設定方法を示します。

replicasを3、maxSurgeを2、maxUnavailableを1とした場合の設定は次になります。

spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
    type: RollingUpdate

設定はspecの下に書きます。

他にも、replicasを3、maxSurgeを2、maxUnavailableを0とした場合の設定は次になります。

spec:
   replicas: 3
   strategy:
     rollingUpdate:
       maxSurge: 2
       maxUnavailable: 0
     type: RollingUpdate

簡単にローリングアップデートの設定をすることができました。

実行方法

ローリングアップデートを行う方法としてkubectlコマンドを使ったものを紹介します。

kubectlコマンドを使ったローリングアップデートでは、設定のimageの部分を変更することで行います。

次に、test-dockerという名前のイメージを使用したtestという名前のdeploymentで、containersのnameにtestを設定している場合に、test-docker:v1.1という名前のイメージを使うように更新するコマンドを示します。

kubectl set image deployment/test test=test-docker:v1.1

このコマンドを実行すると自動的に設定したイメージでPodが起動するように更新されます。

CI/CDの過程でこのようなコマンドを実行するようにすれば自動でアプリケーションを更新するようにできます。

さいごに

仕組みさえ分かってしまえば簡単にローリングアップデートができます。

皆さんも試してみてください。