Kubernetes Deployments: The Ultimate GuideーPart4
Kubernetesのデプロイメント ：究極のガイド パート4
今回の記事はKubernetesのデプロイメントに関しての記事です。少し長いので4つに分けて投稿します。今回が最後のチャプターとなります。最後の第4回目はより高度なKubernetesのデプロイメントストラテジー、ブルー/グリーンデプロイメントについてです。
Advanced Kubernetes deployment strategies
より高度なKubernetesのデプロイメントストラテジーです。
場合によっては、新しいバージョンをロールアウトするときに、よりコントロールする必要があるときもあります。
あなたはご存じかもしれませんが、2つの有名なテクニックは、ブルー/グリーンデプロイメントとカナリアデプロイメントです
Blue / green deployment with Kubernetes
ブルー/グリーンデプロイメントでは、以前に説明したように段階的に行うのではなく、すべてのトラフィックを古いバージョンから新しいバージョンに即座に切り替えていきます。 それは、次のようないくつかの理由があるからです。
- 古いリクエストと新しいリクエストが混在することは望ましくありません。また、あるバージョンから次のバージョンへのブレークを可能な限りクリーンにする必要があります。
- 複数のコンポーネント（たとえば、WebフロントエンドとAPIバックエンド）を同時に更新していますが、新しいバージョンのWebフロントエンドが古いバージョンのAPIバックエンドとトークしたり、その逆を行うことは望ましくありません。
- 何か問題が発生した場合、古いコンテナのセットが再起動するのを待たずに、できるだけ早く元に戻す機能が必要です。
（Kubernetesの意味で）複数のデプロイメントを生成し、サービスのセレクターを変更することにより、あるデプロイメントから別のデプロイメントに切り替えることにより、ブルー/グリーンデプロイメントを実現できます。
これは思ったより簡単です！
次のコマンドは、 nginx および httpdこんてなイメージをそれぞれ使用して、ブルー/グリーン2つのデプロイメントを生成します。
kubectl create deployment blue --image=nginxkubectl create deployment green --image=httpd
次に、webと呼ばれるサービスを生成します。最初はトラフィックをどこにも送信しません。
kubectl create service clusterip web --tcp=80これでkubectl edit service webを実行してサービス web のセレクターを更新できます。 これにより、サービスWebの設定がKubernetes APIから取得され、テキストエディターで開かれます。以下のセクションを見てください。
selector:app: web
…そして、 web をお好みに合わせてブルーまたはグリーンに置き換えます。 保存して終了です。 kubectl は、更新された設定をKubernetes APIにプッシュします。するとどうでしょう！ サービス web は、対応するデプロイメントにトラフィックを送信しています。
（kubectl get svc web でそのサービスのIPアドレスを取得し、 curlでそのIPアドレスに接続することにより、自分で確認できます。）
テキストエディターで行った変更は、次のように（たとえば)kubectl パッチを使用して、コマンドラインから行うこともできます。
kubectl patch service web -p '{"spec": {"selector": {"app": "green"}}}'ブルー/グリーン展開の利点は、トラフィックの切り替えがほぼ瞬時に行われることです。また、サービス定義を再度更新することで、同じ速度で以前のバージョンにロールバックできます。
ブルー/グリーンデプロイメントの利点は、トラフィックの切り替えがほぼ瞬時に行われることです。また、サービスの設定を再度更新することで、同じ速度で以前のバージョンにロールバックできます。
Canary deployment with Kubernetes
カナリアデプロイメントは、炭鉱で使用されたカナリアを意味し、一酸化炭素などの有毒ガスの危険な濃度を検出します。 鉱夫たちはカゴの中のカナリアを炭鉱の中に運び入れます。 カナリアは人間よりも有毒ガスに敏感なので、カナリアが亡くなった場合、それはそのエリアがとても危険な場所だということを意味し、炭鉱夫たちが死亡する前にそこから逃げる必要があるということを教えてくれます。
それでは、これがソフトウェアのデプロイメントにどのように対応しているでしょうか。
場合によっては、短期間であっても、すべてのユーザーに欠陥のあるバージョンを使用させることはできません。 その代わり、新しいバージョンの部分的なロールアウトを行います。 たとえば、新しいバージョンを実行するレプリカをいくつかデプロイします。 または、ユーザーの1％をその新しいバージョンに送ります。
このテクニックは、セットアップにも関連するもので、最後にはKubernetesのラベルとセレクターのネイティブメカニズムのおかげで、比較的簡単になります。
前の例では、サービスのセレクターを変更しましたが、ポッドのラベルを変更することもできます。
たとえば、ラベル status=enabledのポッドを検索するようにサービスのセレクターが設定されている場合、次のようにしてそのようなラベルを特定のポッドに適用できます。
kubectl label pod fronted-aabbccdd-xyz status=enabledラベルも一度に提供することができます。以下のように：
kubectl label pods -l app=blue,version=v1.5 status=enabledそして、簡単にこのようにそれらを取り除くことも可能です。
kubectl label pods -l app=blue,version=v1.4 status-まとめ
より自信を持ってデプロイメントする（ deploy with more confidence）ために使用できるいくつかの手法を見ました。 これらの手法のいくつかは、デプロイメント自体に起因するダウンタイムを単純に短縮するため、ユーザーに影響を与えることを恐れることなく、より頻繁にデプロイできます。
これらのテクニックは安全ベルトのような存在であり、悪いバージョンがサービスを停止するのを防ぎます。 また、特に難しいシーケンスを試す前にビデオゲームの「保存」ボタンを押すなど、何か問題が発生した場合はいつでも元に戻ることができるなど、安心感を与えてくれます。
Kubernetesのおかげで、開発者とオペレーションチームがこれらのテクニックを活用できるようになり、より安全なデプロイメントを可能にしてくれます。 デプロイメントに関連するリスクが低い場合、それはより頻繁に、段階的にデプロイし、実装時に変更した結果をより簡単に確認できることを意味します。 たとえば、週または月に1回デプロイする代わりに、です。
その結果、開発速度が向上し、修正および新機能の市場投入時間が短縮され、アプリケーションの可用性が向上します。今回はコンテナと継続的デリバリーを実装するためのポイントを説明しました。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
