DevSecOps

Kubernetes デプロイ

ある分類やアプリのテスト手法では、プログラムを変更またはアップグレードします。システムを停止せずに変更することが目標です。ユーザーに気づかれずアップデートを導入するために欠かせない戦略です。

マイクロサービスベースのアプリやクラウド環境へのデプロイでは、継続的デリバリーを円滑にするために負荷の少ないデプロイが求められます。Kubernetesは構成管理の業界標準となり、アプリの革新性と信頼性を両立させます。

テスターがアプリをインストール、デプロイ、ロールバックし、ソフトウェアのリリースを整理する際に、素早く反復と実験を行い、利用者のニーズを満たすことを可能にしています。

Kubernetes デプロイメントとは？

Kubernetes のデプロイは、アプリに宣言的な変更を加えられるリソースオブジェクトです。管理者がイメージ、必要なポッド数など、データベースのライフサイクルに関わる要素を定義できます。Kubernetesのバックエンドが配置処理を担うので、テクノロジーを更新しても運用者が手動で対応する必要はありません。

Deploymentオブジェクトでは宣言的な設定が可能で、GitOpsフレームワークにも利用できます。Kubernetesの仕組みは、クラスターの必要リソースをそろえてデプロイメントKubernetesで指定された理想の状態を実現しようとします。これにより手動でアプリを更新・インストールする負担やエラーを減らせます。

‍

Kubernetes デプロイの戦略

Kubernetesはソフトウェアを柔軟に導入できるため、多様な場面で使えます。アプリの目標状態を設定すると、デプロイコントローラーが作業を開始します。段階的に配置プランを調整しながら、導入効率を高めることができます。

Rolling Update Strategy

ローリングアップデート方式では、あるバージョンから別のバージョンへスムーズかつ段階的にパッケージを更新します。新しい要素が準備できると新しいReplicaSetが配置され、同時に旧バージョンのレプリカが順番に停止されていきます。最終的には新しいバージョンがすべての旧ポッドを置き換えます。

ローリングアップデートによる利点は、より滑らかなアップグレードができることです。一方、完了までに時間がかかる場合があります。

Kubernetes Recreate Deployment

再作成(Recreate)手法では、新しいバージョンに切り替える際、現在稼働中のポッドをすべて停止し、ゼロから作り直します。この方式はユーザーの利用が影響を受けないテスト環境でよく使われます。

古い実装を一旦停止してから新しいデプロイインスタンスを起動するため、パッケージの状態を一新できる反面、ダウンタイムが生じることが想定されます。

Kubernetes Canary Deployment

カナリア移行では、新しいアプリを一部のポッドと特定のユーザーグループのみで運用します。この方式は実稼働環境で機能をテストする際に用いられます。新バージョンがすべての検証を通過したら規模を拡大し、古いバージョンを徐々に置き換えます。

限られたユーザーだけに新機能を試してもらいたい場合に有効です。万が一問題があっても元に戻しやすく、システム全体を危険にさらさずに新コードを試せます。

Kubernetes Blue/Green Distribution

Blue/Green方式では、新しいバージョンを本番でしっかりテストしたうえで一気にアップグレードできます。このケースでは、旧バージョンと新バージョンを両方とも本番環境で稼働させます。新バージョン(green)が正常に動作していると確認できたら、ロードバランスを担うKubernetes Serviceオブジェクトのセレクタフィールドを新タグに更新し、瞬時にユーザーを新バージョンへ誘導します。

KubernetesでのBlue/Greenデプロイは、異なるバージョン間の互換性を気にせず素早い切り替えを実現できます。ただし、切り替えまでは両バージョンを同時稼働させるため、リソースが多く消費されます。

A/B Testing Categorization

カナリア方式と似ていますが、A/Bテストでは対象とするユーザーグループを限定しつつ、アプリの機能だけではなく端末タイプや地域などの使用条件とパフォーマンス目標との関連を測定します。

他の導入手法より設定は増える場合がありますが、複数のバージョンを同時に稼働させる必要があるケースでは有効です。

‍

Kubernetes デプロイの主なユースケース

最終的な展開目標は「デプロイを仕上げること」です。システムを止めずにクラスターを望ましい状態へ近づけられます。

Kubernetes デプロイの例として、以下の使い方があります。

新しいポッドやReplicaSetを繰り返し生成できます。Kubernetesは定義ファイルのパラメーターをもとに、ポッドやReplicaSetをレプリケートします。
ポッドとReplicaSetの望ましい状態を宣言的に記述します。YAML定義ファイルに、ポッドとReplicaSetの最終形を記述することが可能です。
インストール済みのクラスターが不安定になった場合でも、以前の状態にロールバックできます。Kubernetesはすべてのデプロイ履歴を保管しており、必要ならいつでも戻せます。たとえばポッドがクラッシュループに陥るときなどに役立ちます。ロールバックが行われると、デプロイのリビジョンも更新されます。
トラフィック増加時に容量を拡張する場面でも有用です。より多くのポッドやReplicaSetを生成することで対応し、必要に応じて自動的にポッドを追加する設定も可能です。

‍

Kubernetes デプロイを使うメリット

Kubernetesはコンテナオーケストレーション管理プラットフォームとして、アプリのデプロイ、スケーリング、更新管理などの手間を大幅に減らし、効率化します。さらにKubernetesスケールデプロイメントコントローラーは常にポッドやノードの状態を監視し、制御プレーンがポッド停止やノード障害を自動検出して、同じ稼働状態のコピーを起動します。これにより、必要なアプリケーションが途切れることなく動くように保ちます。

このようにKubernetesによる継続的デプロイは、ポッドの起動からクラスター上で所定の状態を保つことまで一連の作業を自動化します。自動化が増えれば増えるほど、作業はより迅速かつ正確に行えます。

‍

K8s デプロイツール

従来はアプリのアップデートを行う際、サーバーを停止してアップグレードし、再デプロイするのに数時間のダウンタイムが発生し、さらにすべてが正常かどうか長時間待機する必要がありました。うまくいけば数時間のサービス停止で済むものの、問題が起きるとシステムの不安定化を招き、ユーザーも開発者も大きな負担を被りました。

また、一回ごとのリリース作業をスクリプト化して再現可能にする必要があったため、開発者が小さく頻繁な更新を行い、ユーザーからのフィードバックを早期に得るのは難しかったのです。

しかし、Kubernetesのdeployment yamlを使うと、クラスターがアプリのワーカーノードやポッドの健康状態を監視し、必要に応じて自動ロールバックやインスタンスの置き換えを行うので、ダウンタイムを回避できます。各リリースはYAMLファイルの仕様として保持されるため、本番導入前にテスト環境で検証可能です。

Kubernetesはマイクロサービス構成に適しており、各ポッドを独立してデプロイ、更新、スケールアウトできます。さまざまなデプロイ戦略を用いることで、最初に一部だけ更新して問題があればロールバックするなど、全体を危険にさらさず新しい機能を試せます。特定サービスのスケールだけ増やすことも簡単です。スケジュールされたリリースにより、開発者はサービスを定期的に更新しやすくなります。

‍