k8s_clearily_series④ Deployment
kubernetesついて明瞭に説明していく「k8s_clearily_series」の四回目になります。
第四回目はkubernetesを実運用で使用する上で必須になる「Deployment」について下記に記載の4つの観点から詳細な説明をさせていただきます。
- Deploymentとは
- ライフサイクル
- Podのイメージ管理
- Nodeへの配置
Deploymentとは
kubernetesのクラスター上でアプリケーション（Pod）をデプロイし、管理するためのリソースになります。管理する内容については、ライフサイクルの記述やアプリケーション（Pod）に使用するイメージ、Podに対してNodeに配置するPodの数などが主な機能になります。
では、次からは「ライフサイクル」「イメージ管理」「Nodeへの配置数」この3つについて詳細なお話をさせていただきます。
ライフサイクル
Deploymentにおけるライフサイクルは複数のステップで構成されております。ではそのステップを下記に記載させていただきます。
STEP:1 マニフェストファイル（YAMLファイル）とDeploymentの作成
まず、最初はDeploymentを定義するYAMLファイルを作成します。このYAMLファイルにはアプリケーションをデプロイするにあたって必要なコンテナイメージ、Podの可用性を担保するためのレプリカ数やLabelなどの設定が含まれます。
# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ngninx-deploy
spec:
replicas: 2 # レプリカ数を指定することで作成されるPodの数が指定できる
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers: # Deployに必要なコンテナの情報（コンテナイメージなど）
- name: nginx
image: nginx作成されたYAMLファイルは、プライベートで使用するGit（GitHubやGitlab）などに保存されることになり、「kubectl apply」コマンドを使用してGitからKubernetesクラスターへDeploymentの作成を実行します。作成されたDeploymentは指定したReplicasの数だけ、KubernetesクラスターにPodの作成を行います。
STEP:２ ローリングアップデート
コンテナアプリケーションの変更や更新時には、新しいバージョンのイメージをYAMLファイルに記載の上でDeploymentの更新を実施します。
その際にローリングアップデートと呼ばれるサービスの中断を最小限に抑える方法が実施されます。
STEP:３ 監視とスケーリング
Deploymentと関連するサービスの監視を実施し、必要に応じてオートスケーリング機能を活用して、
アプリケーションのパフォーマンスや可用性を確保します。このオートスケーリングには2つの種類がございます。
水平Podオートスケーリングは、クラウドベースのアプリケーションやサービスの運用において、効率性と費用対効果の高いものになっており、Kubernetesの公式ドキュメントにも記載されているオートスケーリングになります。
垂直Podオートスケーリングは、現在公式に直接サポートされている機能はなく、Kubernetesの公式ドキュメントにも記載されておりません。（2024年3月現在）
ただ、クラウドの各種マネージドサービスであるEKS（AWS）やAKS（Azure）、GKE（Google）などではクラウドが提供するサービスと組み合わせて使用することが可能となっております。
STEP:４ Deploymentの削除
Deploymentの削除やリソースの削減が必要になった際には、Deploymentに関連するReplicaSetやPodなどのリソースを適切に削除することができます。
Deploymentでは、ローリングアップデートやスケーリング、削除など柔軟性と信頼性を提供するための多くの機能を提供しております。
イメージ管理
Deploymentを使用したイメージ管理を行うことによって、アップデートやバージョン管理、ポリシーの適用などが可能となります。ここではイメージ管理のポイントを記載させていただきます。
Point:１ イメージのタグ付け
Deploymentで使用するイメージのタグ付けを行うことによって、バージョンやリビジョン（改定情報など）を識別します。コンテナ（Docker）を使用する際には、通常はレジストリからコンテナイメージをビルドする際に、コンテナイメージに対してタグ付けを行います。
Point:２ Deploymentの更新
Deploymentでコンテナの新しいバージョンを使用するには更新の実施が必要になります。その際にレジストリに新しいコンテナがあるということを前提にした上で、kubectlコマンドを使用してレジストリから新しいイメージをタグ付けをしつつ、反映を行う必要がございます。
Point:３ ローリングアップデートとロールバックの実行
Deploymentの更新により、古いポッドが新しいイメージに順次置き換えられます。これにより、システムの停止を最小限に抑えながらアプリケーションを更新できます。ローリングアップデートはデフォルトでKubernetesに組み込まれており、更新がスムーズに実行されます。※Deploymentのライフサイクル STEP:2に記載済み
そして、ロールバックが実行できることによって、新しいイメージによる更新が問題を引き起こした場合、Deploymentを以前の状態に戻すことができます。ロールバックもDeploymentに組み込まれた機能になります。
Point:４ イメージのセキュリティ管理
イメージのセキュリティ管理は重要になります。そのため定期的な脆弱性スキャンやセキュリティアップデートを実行することが推奨されます。
スキャンツールには「Trivy」「Clair」「Sysdig」などのKubernetesエコシステムにて存在する様々なスキャンツールを利用を行い、コンテナレジストリやKubernetesクラスターに反映されているPodのイメージに対して脆弱性スキャンを実施します。
セキュリティアップデートには、脆弱性スキャンを実施したものをデプロイします。その後はローリングアップデートとロールバックを利用して、システムが安定して運用するようにします。
Nodeへの配置
Deploymentでは、Kubernetesクラスターを安定運用するためにNodeへの配置数を最適化し、アプリケーションのパフォーマンスと可用性を確保します。そのためには下記の手順に従うことになります。
手順：１ スケジューリングとNodeの選択
Deploymentが管理するPodの新しいインスタンスが作成されると、ControlPlaneノードにあるkube-scheduller（以降スケジューラー）がPodをkube-apiserverを介して、適切なNodeにスケジュールします。スケジューラーは、クラスタ内の利用可能なリソース、Podの要件、およびクラスタのスケジューリングポリシーを考慮して行われます。
また、Podがスケジュールされる際に、Kubernetesは異なるNodeのリソース状況やノードの制約を考慮します。
Podが特定のNodeに配置される決定には、CPUやメモリの利用可能性、ネットワークの帯域幅、およびノードに適用されているラベルやアノテーションなどが含まれます。
手順：２ ReplicaSetによるPodの管理
Deploymentによって管理されるPodは、一般的にReplicaSetによって作成されます。ReplicaSetは、指定されたレプリカ数（Podのコピー数）を維持する責任があります。Podは、クラスタ内の異なるNodeに均等に分散されるように配置されます。これにより、システムの冗長性と可用性が向上します。
手順：３ Podの監視と再配置
Kubernetesは定期的にポッドの状態を監視し、必要に応じて再配置を行います。例えば、Nodeがダウンした場合や
Podの健全性が損なわれた場合、Kubernetesはそのポッドを別の利用可能なNodeに再配置します。
まとめ
今回はDeploymentのライフサイクルにおける展開、更新、削除についてお話をさせていただき、その上でイメージ管理とNodeへの配置についてお話をさせていただきました。
次回はserviceリソースについて、お話させていただきます。