ローリングアップデート用にKubernetesを設定する方法

はじめに

ローリングアップデートは最新のアプリのライフサイクルの重要な部分であり、ユーザーは常に新機能とゼロダウンタイムを期待しています。 Kubernetesはこれまでレプリケーションコントローラーを使用してこの機能を有効にしていましたが、新しいバージョンではデプロイメントの使用を推奨しています。

このチュートリアルでは、KubernetesDeploymentsを使用してローリングアップデートを実行する方法を示します。この方法では、ロールバックサポートを確保しながら、アプリをすばやく更新してダウンタイムをゼロにすることができます。

前提条件

Kubernetesクラスター
ターミナルウィンドウへのアクセス
kubectlコマンドラインツール

ローリングアップデートを有効にする

Kubernetesデプロイは、ポッド管理を担当するKubernetesコントローラーであるReplicaSetsのラッパーとして機能します。デプロイメントは、ReplicaSetに追加機能を提供します。つまり、ヘルスチェック、ローリング更新、およびロールバックを実行します。

1.まず、 yamlを作成します Nano：

などのテキストエディタを使用した展開仕様のファイル

nano nginx-test.yaml

以下のサンプルファイルには、Kubernetesデプロイメントに必要な基本的な宣言が含まれています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

        ports:
        - containerPort: 80

2.ファイルを保存して終了します。

3.次に、 kubectl createを使用してデプロイメントを作成します コマンドとyaml 作成したファイル：

kubectl create -f nginx-test.yaml

4.展開を確認します：

kubectl get deployment

出力は、展開の準備ができていることを確認する必要があります：

4.次に、次のコマンドを実行して、ReplicaSetsを確認します。

kubectl get rs

サンプルファイルには4つのレプリカが指定されており、すべて準備完了として表示されます。

5.最後に、ポッドが稼働しているかどうかを確認します。

kubectl get pod

出力には、ポッドが準備完了で実行中であることが示されます。

ダウンタイムをゼロにする

ダウンタイムがゼロのローリング更新を構成するには、更新戦略を指定する必要があります。

1.次の宣言をデプロイyamlに追加します specの下のファイル カテゴリ：

minReadySeconds: 5
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

minReadySeconds 次のポッドが作成されるまで待機する時間をKubernetesに指示します。このプロパティにより、更新中にすべてのアプリケーションポッドが準備完了状態になります。
maxSurge 指定されたレプリカ数を超えるポッドの最大数（またはパーセンテージ）を指定します。上記の例では、ポッドの最大数は 5になります 4以降レプリカはyamlで指定されますファイル。
maxUnavailable 更新中に使用できないポッドの最大数（またはパーセンテージ）を宣言します。 maxSurgeの場合 0に設定されています、このフィールドを 0にすることはできません。

上記の仕様をデプロイに追加するyaml ファイルは、Kubernetesローリングアップデートの実行を開始するのに十分です。ただし、ダウンタイムがゼロであることを保証するものではありません。 Kubernetesは、新しいポッドの準備ができたことを認識できません。新しいポッドが作成されるとすぐに、古いポッドが削除されます。この問題により、新しいポッドがリクエストを受け入れることができるようになるまでダウンタイムが発生します。

この問題を解決するために、Kubernetesは準備プローブの概念を備えています。プローブはポッドの状態をチェックし、ポッド内のすべてのコンテナーの準備ができたときにのみローリング更新を続行できるようにします。準備プローブが成功し、 minReadySecondsで指定された時間が経過すると、ポッドは準備完了と見なされます。 合格しました。

2.準備プローブを設定するには、次の行を spec.template.specに追加します。 デプロイメントファイルのカテゴリ：

readinessProbe:
  httpGet:
    path: /
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1

initialDelaySeconds コンテナが起動した後、プローブが起動するまで待機する時間を指定します。
periodSeconds 2つのプローブ間の時間です。デフォルトは10です秒、最小値は 1 2番目。
successThreshold プロセス全体が成功したと見なされるために、失敗したプローブの後に連続して成功したプローブの最小数です。デフォルト値と最小値はどちらも1 。

ローリングアップデート用に適切に構成されたデプロイメントファイル全体は、次のようになります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0

        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1

3.ファイルを保存して終了します。

4.次に、 kubectl applyを使用します 変更を適用するには：

kubectl apply -f nginx-text.yaml --record

--record フラグはロールバックプロセスで目的を果たします。

出力は、デプロイメントが正常に構成されたことを示しています。

ローリングアップデートを実行する

ローリング更新を実行するには、3つの方法があります。

たとえば、アプリの画像を変更するには：

オプション1： kubectl setを使用できます コマンドラインでアクションを実行するには：

kubectl set image deployment nginx-deployment nginx=nginx:1.14.2 --record

オプション2：または、 spec.templates.spec.containersのイメージバージョンを変更します yamlのセクションファイル。次に、 kubectl replaceを使用します 更新を実行するには：

kubectl replace -f nginx-test.yaml

オプション3： kubectl editを使用することもできます デプロイメントを直接編集するには：

kubectl edit deployment nginx-deployment --record

開いたエディタで必要な変更を加えます：

変更は、エディターを閉じるときに適用されます。

ロールアウトステータスの確認

次の構文を使用して、展開のロールアウトステータスを確認します。

kubectl rollout status deployment nginx-deployment

出力は、ロールアウトが成功したことを確認します：

ローリングアップデートの一時停止と再開

それぞれのkubectl rolloutを使用してローリングアップデートを一時停止および再開します コマンド。

更新を一時停止するには、次のコマンドを実行します：

kubectl rollout pause deployment nginx-deployment

更新を再開するには、次のコマンドを実行します：

kubectl rollout resume deployment nginx-deployment

展開用のポッドのスケジュール

アフィニティプロパティと非アフィニティプロパティを使用して、Kubernetesがデプロイ内の特定のポッドをスケジュールするノードを制御します。

ポッドアフィニティ

アフィニティには2つのタイプがあります現在Kubernetesで利用可能：

requiredDuringSchedulingIgnoredDuringExecution 特定のプロセッサタイプなど、特定の条件を満たすノードでのみポッドを実行するようにKubernetesに指示します。
preferredDuringSchedulingIgnoredDuringExecution 与えられた基準を満たすノードがない場合に限り、ポッドを他の場所で実行できるようにします。

これらのプロパティは、 PodSpecにリストされていますファイル。たとえば、ポッドは次のように指定できます。

apiVersion: v1
kind: Pod
metadata:
  name: affinity-test
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/test-name
            operator: In
            values:
            - test1
            - test2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
  containers:
  - name: affinity-test
    image: k8s.gcr.io/pause:2.0

上記のファイルは、キーが kubernetes.io/test-nameであるラベルを持つノードでのみポッドを実行するようにKubernetesに指示しています。 値がtest1のいずれかである またはtest2 。さらに、Kubernetesは、キーが example-node-label-keyであるノードを優先します 、 example-node-label-valueを使用 価値。

ポッドアンチアフィニティ

ポッドの非親和性 すべてのポッドを同じノードで実行したくない場合に便利です。アフィニティと同様に機能し、同じ2つのタイプを使用できます- requiredDuringSchedulingIgnoredDuringExecution およびpreferredDuringSchedulingIgnoredDuringExecution 。

次の例では、Kubernetesに「テスト」アプリポッドをすでに「テスト」ポッドがあるノードにスケジュールしないように指示する非アフィニティルールを指定しています。

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: 
          - test
      topologyKey: Kubernetes.io/hostname

ロールバックの変更

更新プロセスで問題が発生した場合は、変更をロールバックして、アプリの以前のバージョンに戻すことができます。これを行うには、次のkubectl rolloutを使用します コマンド：

kubectl rollout history deployment nginx-deployment

出力には、 --recordを追加して作成された利用可能なリビジョンが一覧表示されます 更新実行時のフラグ：

必要なリビジョンを選択し、次のコマンドを入力して変更をロールバックします。

kubectl rollout undo deployment nginx-deployment --to-revision=1

上記のコマンドはリビジョン1にロールバックし、次の出力を生成します。