kubernetesロールオーバー

シリーズカタログ

简介

kubernetesがサービスをクラスタ化する場合、アップグレードする必要があり、伝統的なアプローチは、オフラインで更新された最初のサービスであり、かつ、トラフィックの更新と構成を停止し、サービスを再起動します。クラスタサイズが大きいビジネスである場合は、この作業が課題となって、だけでなく、最初のピットストップのすべて、その後徐々にアップグレードアプローチが長いサービス時間につながるが利用できません。kubernetesは、問題を解決するためのロールオーバー（ローリングアップデート）方法を提供します。

簡単に言えば、アップデートは、サービスの複数のインスタンスのためにローリングされ、更新のアップグレードサービスを中断することはありません。各インスタンス一つずつではなく、すべての更新のすべてのインスタンスによって別々に一つの回転更新の更新を使用して、サービスの複数のインスタンスのために、一般的に。

サービスのK8Sクラスタの展開のために、更新を転がすことは一度だけポッドを更新参照し、サービスの中断を避けるために、代わりに同時にすべてのポッドのシャットダウンのサービスを以下の、個別に更新しました。

サービス、展開、RS、RCとポッドとの間の関係

私たちのアプリケーションがデプロイされるためには、一般的には、より抽象的なサービスコンポーネントです。kubernetesにマッチサービスにそのようなエンドポイントポッド、ベアラ・トラフィックの実際のエンティティのサービスとして、ラベルのセレクタを介してポッドを設定します。クラスタの展開内のポッドは、スケジューリングは、コピーの数は、これらのRCの展開または管理するための高レベルの抽象化を介して行われます。図は次のとおりです。

Kubernetesの新バージョンでは、ポッドは、レプリカセットの背後に隠されているコピーの数を維持するのに実用的なプレーで展開、この概念の導入で役割を交換ReplicationControllerをお勧めします。

したがって、我々は基本的にポッドのコレクションのうち、試合の保守の更新をローリングKubernetesにローリング更新サービスを見て、コピーのポッドの展開、スケジューリングとディスパッチを制御するが、それは正確に展開し、複製コントローラであるため、後者の二つのことができます更新をロールkubernetesエンティティサービスが直面して本当にです。

kubectlローリング・アップデートアップデートを使用

ポッドを作成し、主にRCの使用のために、道をコマンドにkubectlローリング・アップデートを使用してください。
次の例での最初の外観は、作成RC nginxの-デモ-V1-rc.yml nginxのは、の4つのコピーが含まれています。

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-demo-v1
spec:
  replicas: 4
  selector:
    app: nginx-demo
    ver: v1
  template:
    metadata:
      labels:
        app: nginx-demo
        ver: v1
    spec:
      containers:
        - name: nginx-demo
          image: nginx:1.10.1
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: NGX_DEMO_VER
              value: v1

次のようにサービスを作成し、nginxの-デモ-svc.ymlを読み取ります。

apiVersion: v1
kind: Service
metadata:
  name: nginx-demo-svc
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: nginx-demo

RCとサービスを作成します：

kubectl create -f nginx-demo-v1-rc.yml
kubectl create -f nginx-demo-svc.yml

後v1のNGX_DEMO_VERの値を参照してアクセスすることによって、することができますいずれかのポッドの環境変数を作成しました

今、私たちは、既存のポッドをアップグレードするためのnginx-デモ-V2-rc.ymlファイルを作成します。

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-demo-v2
spec:
  replicas: 4
  selector:
    app: nginx-demo
    ver: v2
  template:
    metadata:
      labels:
        app: nginx-demo
        ver: v2
    spec:
      containers:
        - name: nginx-demo
          image: nginx:1.11.9
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: NGX_DEMO_VER
              value: v2

アップデートを実行します。

kubectl rolling-update nginx-demo-svc -f nginx-demo-v2-rc.yml

なお、ローリング・アップグレード、YMLファイルの2つのバージョンの違いを実行する場合：

• RCの名前は古いRCと同じ名前にすることはできません
• セレクタでは、少なくとも新しいR​​Cとしてそれを識別するために、古いRCのラベルと異なるラベルを持つ必要があります。

我々は、次による更新の完全なプロセスを見ることができます：

kubectl rolling-update nginx-demo-v1 --udpate-period=10s -f nginx-demo-v2-rc.yml

すべての古いポッドは、新しいポッドの完成によって置き換えられた場合、アップデートは完了です。

kubectlローリング更新実現ロールオーバーの欠点を使用します。

• ローリング更新ロジックは、N APIServerが完了kubectlするコマンドによって発行され、ネットワークが中断の更新を引き起こす可能性があります

• 私たちは、新たなRCを作成する必要があり、名前は、RCのように更新することはできません

• ロールバックはまた、ローリング・アップデートを実行する必要がありますが、古いバージョンの新しいバージョンに置き換え

• 行っローリング・アップデート・サービスは、クラスタ内に記録されていない、フォローアップは、ローリング・更新履歴を追跡することはできません

今日では、RCのアプローチは展開の選択肢となっています。

展開的ローリング更新

展開のkubernetesは、高レベルの抽象化です。展開は、ポッド内のコピーの展開の数ことを確実にするために使用レプリカセットを作成します。ポッドでのローリング更新の展開に、あなただけが展開独自のYMLファイルを変更する必要があり、アプリケーションをすることができます。この変更は、完全にアップグレードされるまでポッド古いRSを減らし、同時に新しいRSにポッドの数を増やし、新しいレプリカセットを作成します。サーバ側で起こったこのすべては、あなたがkubectlの参加を必要としません。

展開YMLファイルのnginx-デモdm.ymlを作成します：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-demo
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-demo
        version: v1
    spec:
      containers:
        - name: deployment-demo
          image: nginx:1.10.1
          ports:
            - containerPort: 80
              protocol: TCP

展開の作成：

kubect create -f nginx-demo-dm.yml --record

次のようにその後、我々は直接、展開ファイルを変更することができます。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-demo
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-demo
        version: v2
    spec:
      containers:
        - name: deployment-demo
          image: nginx:1.11.9
          ports:
            - containerPort: 80
              protocol: TCP

二箇所の合計のバージョンV2に変更し、変更し、ミラーnginxのは1.11.9へ1.10.1から変更、変更を適用するために、次の操作を実行します。

kubectl apply -f nginx-demo-dm.yml --record

今回は、実行することができますkubectl get rsアップグレードを実行するかどうかを確認するために変更RSを参照してください。あなたもできるkubectl describe deployment nginx-demoの詳細表示rolling-updateプロセスを。あなたはまた、可能kubectl rollout status deployment/nginx-demoでステータスを更新します。

変更が以外の手段を使用するように適用する適用に加えて、あなたが直接アップグレードできる別の方法があります。これは、を介して行われkubectl edit nginx-demo-dm.yml、配布ファイルを編集後に、適用実行することなく、自動的にアップグレードされますのためにそれを保存します。

私たちは、apiserver履歴更新レコードを指示するために使用され--record引数を使用して、展開操作の実装では、注意があります。次のコマンドを使用して、更新履歴を表示することができます。

kubectl rollout history deployment nginx-demo

指定されたリビジョンの詳細を表示します：

kubectl rollout history deployment hello-deployment --revision=2

アップグレードが完了した後、削除されません古いRSは、この情報は、ロールバックを容易にするために、サーバー側に保存されることに留意すべきです。
ポッドロールバック操作での展開は、直接実装ロールアウトアンドゥ展開が戻っ記録改訂レコードにロールバックすることができ、非常に簡単です：

kubectl rollout undo deployment nginx-demo

以下の操作、指定されたバージョンへのロールバックを実行します：

kubectl rollout undo deployment hello-deployment --to-version=2

オリジナル住所