ポイント: Kubernetesデプロイメントは、Podとレプリカセットを管理するための宣言的な更新を可能にし、ダウンタイムなしでアプリケーションのシームレスな更新を促進します。これにより、ユーザーはデプロイメントを効率的にスケール、ロールバック、および管理できます。
- デプロイメント管理には、kubectl apply、scale、およびrolloutなどの重要なコマンドが含まれます。
- ユーザーは、アプリケーションの安定性を保つために、デプロイメントを簡単に一時停止、再開、ロールバックできます。
Kubernetes デプロイメントは、Pods と ReplicaSets に宣言的な更新を提供するプロセスです。ユーザーがマニフェスト (YAML) ファイルで望ましい状態を宣言でき、コントローラーが現在の状態を宣言された状態に変更します。それでは、Kubernetes デプロイメントを作成して使用する方法を見ていきましょう。デプロイメントプロセスを簡素化し、管理、スケール、ロールバックを行うために Kubernetes デプロイメントを活用する方法を説明します。この記事の目的のために、Windows 環境で Windows Subsystem for Linux (WSL) を使用してローカルにデプロイされた Kubernetes クラスターを使用します。
Kubernetes デプロイメントの作成
まず、4 つのレプリカを持つシンプルな Nginx デプロイメントを作成します。他の Kubernetes 構成と同様に、デプロイメントファイルには以下が含まれます：
- apiVersion (apps/v1)
- Kind (Deployment)
- メタデータと、レプリカとデプロイメントに関連する構成を定義する spec セクション
nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
# Define the Deployment Name
name: nginx-deployment
labels:
app: webserver
spec:
# Define the Number of Pods
replicas: 4
# Define the Selector
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers: # Container Details
- name: nginx
image: nginx:latest # Image
ports:
- containerPort: 80
次のコマンドを使用してデプロイメントを作成できます。コマンドを保存するために --record フラグを追加しました。
kubectl apply -f nginx-deployment.yaml --record
結果:
上記のデプロイメントファイルのメタデータおよび仕様セクションに次のエントリを定義しました。
- デプロイメント名とラベル（app: webserver）。
- レプリカ数（ポッド）、コントローラーがターゲットポッドを選択するセレクター。（ラベルはmatchLabelsフィールドを使用して必要なポッドを選択するために使用されます。）テンプレートセクションにはポッドの実際のテンプレートが含まれています。このセクションは、各ポッドが持つメタデータと仕様（コンテナ定義）を定義します。この場合、Nginxイメージとコンテナポートを80として定義しました。
しばらく後にKubernetesクラスターを確認すると、指定されたテンプレートでポッドがデプロイされているのがわかります。また、describeコマンドを使用してデプロイメントの詳細を取得できます。
kubectl get all
結果:
kubectl describe deployment nginx-deployment
結果:
レプリカセットの公開
デプロイメントを作成したので、Nginxウェブサーバーが正しくデプロイされたかどうかを確認する必要があります。これを達成するための簡単な方法は、デプロイメントを公開するサービスオブジェクトを作成することです。ここで重要なのは、デプロイメントを公開する方法とパラメーターは、Kubernetesクラスターの設定によって異なる可能性があるということです。
kubectl expose deployment nginx-deployment --type=LoadBalancer --name=nginx-web-server
結果:
kubectl get services
結果:
次に、ローカルホストのポート80に移動して、デフォルトのNginxサーバーのランディングページが表示されるかどうかを確認します。
Kubernetes デプロイメントの詳細を確認
Kubernetes クラスターを管理する際の最初のステップは、成功したデプロイメントを確認することです。この目的のために、kubectl rollout status および kubectl get deployment コマンドを使用できます。
- kubectl rollout status は、デプロイメントが成功したかどうかをユーザーに知らせます。
- kubectl get deployment は、望ましいレプリカ数と更新されたレプリカ数、実行中のレプリカ数とその可用性を示します。前述のように、kubectl describe コマンドを使用してデプロイメントの完全な情報を得ることができます。
kubectl rollout status deployment nginx-deployment
kubectl get deployment nginx-deployment
結果：
デプロイメント中に作成された ReplicaSets に関する情報を取得するために、kubectl get ReplicaSet コマンドを使用できます。デフォルトでは、Kubernetes は ReplicaSet 名に pod-template-hash 値を自動的に追加します。ただし、ReplicaSet の名前を変更しないでください。そうすると、デプロイメントが壊れます。
kubectl get replicaset
結果：
kubectl get pod コマンドを使用して、セレクターを定義しながらデプロイメントに関連するポッドに関する情報のみを取得できます。この場合、セレクターとして「app:webserver」ラベルを使用します。
kubectl get pod --selector=app=webserver
結果:
Kubernetesデプロイメントの管理
デプロイメントを作成し、その情報を取得する方法がわかりました。次のステージはデプロイメントの管理です。デプロイメントがシンプルなReplicaSetと異なる点は、デプロイメントがユーザーにポッド（ポッドテンプレート）を更新することを可能にし、基盤となるアプリケーションに中断を引き起こさない点です。
デプロイメントのローリングアップデートの実行
デプロイメント内のNginxサーバーのバージョンを特定のサーバーバージョンにターゲットに変更する必要があると仮定しましょう。これを行うには、次のいずれかの方法を使用できます:
- kubectl set imageコマンドを使用
- デプロイメントの設定ファイルを変更
set imageコマンドの使用
set imageコマンドは、テンプレートのコンテナ名と必要なイメージ名を使用してポッドを更新するために使用できます。
kubectl set image deployment nginx-deployment nginx=nginx:1.19.10
結果:
get rollout statusコマンドを直ちに実行すれば、ローリングプロセスが得られます。
kubectl rollout status deployment nginx-deployment
結果:
デプロイメント設定ファイルの変更
edit deploymentコマンドを使用して設定ファイルを編集できます。関連するセクション（コンテナイメージ）に移動し、必要な変更を行います。新しい設定を保存する瞬間にKubernetesはポッドの更新プロセスを開始します。
kubectl edit deployment nginx-deployment
デプロイメント編集ビュー（nginx-deployment）:
デプロイメント戦略
Kubernetesは「Recreate」と「RollingUpdate」の2つのデプロイメント戦略を使用してポッドを再作成します。これらの戦略は.spec.strategy.typeフィールドで定義できます。RollingUpdate戦略はデフォルトのデプロイメント戦略です。
- Recreate は、新しいポッドを作成する前にすべての既存のポッドを削除します。
- RollingUpdate は、ローリングアップデート方式でポッドを再作成します。さらに、アプリケーションの可用性を中断することなく、ポッドを段階的に削除および再作成します。この戦略は、ローリングアップデートプロセスを制御するためにmaxUnavailableおよびmaxSurgeの値を利用します。
- maxUnavailable は、更新プロセスで利用できない最大のポッド数を定義します。
- maxSurge は、作成できる最大のポッド数を定義します。
私たちのデプロイメントでは、明示的に戦略を定義していないため、KubernetesはデフォルトのRollingUpdate戦略を使用します。describeコマンドを使用して、デプロイメントの現在の戦略を確認できます。
kubectl describe deployment nginx-deployment | grep Strategy
結果:
上記の出力から、RollingUpdate戦略のデフォルト設定はmax unavailableが25%、max surgeが25%であることがわかります。私たちの設定では4つのレプリカを作成しています。上記の設定に基づく更新プロセスでは、1つのポッドが破壊される一方で、1つのポッドが作成されます（4の25%は1です）。describeコマンドを使用してデプロイメントのイベントを表示し、更新プロセスの理解を深めることができます。
kubectl describe deployment nginx-deployment
結果:
現在のReplicaSetを見ると、4つのポッドがあり、古いReplicaSetにはポッドが存在しないことがわかります。
kubectl get replicasets
結果:
デプロイメントの一時停止と再開
Kubernetesデプロイメントは、デプロイメントを一時停止および再開する機能を提供します。これにより、ユーザーは新しいReplicaSetのローリングをトリガーすることなく、変更を加えたり問題に対処したりできます。デプロイメントを一時停止するには、「rollout pause deploy」コマンドを使用できます。
kubectl rollout pause deploy nginx-deployment
結果:
今、デプロイメントの一時停止状態でNginxイメージを更新すると、コントローラーは変更を受け入れますが、新しいReplicaSetのローリングをトリガーすることはありません。ローリングステータスを見ると、保留中の変更が表示されます。
kubectl set image deployment nginx-deployment nginx=nginx:1.20 --record
kubectl rollout status deployment nginx-deployment
結果:
「rollout resume deploy」コマンドを実行することで、デプロイメントを再開できます。
kubectl rollout resume deploy nginx-deployment
kubectl rollout status deployment nginx-deployment
結果:
デプロイメントのスケーリング
デプロイメントはReplicaSetsに依存してポッドを管理するため、ポッドの数を増減できます。このスケーリングは次のいずれかの方法で行うことができます:
- 手動
- 自動スケーリングルールを設定することによって
手動スケーリング
scaleコマンドを使用してレプリカパラメータでデプロイメントを望む数にスケールできます。たとえば、次のコマンドを使用して、デプロイメントを4ポッドから8ポッドにスケールアップします。
kubectl scale deployment nginx-deployment --replicas=8
kubectl rollout status deployment nginx-deployment
結果:
このデプロイメントに関連するポッドを見ると、現在8つのポッドがあるのがわかります。
kubectl get pod --selector=app=webserver
結果:
自動スケーリング
デプロイメントのスケーリングのベストプラクティスは、自動スケーリングルールを設定することです。これにより、ポッドは事前定義された閾値に応じてスケールします。では、ノードのCPU負荷に応じてスケールする自動スケーリングルールを作成しましょう。
kubectl autoscale deployment nginx-deployment --min=5 --max=10 --cpu-percent=70
結果:
上記の設定に従うと、CPU負荷が70%を超えると、デプロイメントは最大ポッド数（最大10ポッド）に達するまでスケールします。一方、負荷が減少すると、5ポッド（最小5ポッド）になるまで徐々にスケールバックします。
デプロイメントのロールバック
Kubernetesは、以前のリビジョンにデプロイメントをロールバックすることもサポートしています。これは、デプロイメントの変更を元に戻すことを可能にする重要な機能です。たとえば、重要な本番バグがクラスターにデプロイされた場合、バグが修正されるまでダウンタイムなしで、以前のリビジョンにデプロイメントをロールバックすることができます。設定を誤ったイメージで更新したと仮定しましょう。（この例ではcaddyウェブサーバーを使用します。）
kubectl set image deployment nginx-deployment nginx=caddy:latest --record
結果:
ここで、デプロイメントコントローラーの履歴機能が役立ちます。コントローラーはポッドテンプレートに対する変更を追跡し、履歴に保持します。コマンドにrecordフラグを指定すると、それは履歴に反映されます。
kubectl rollout history deployment nginx-deployment
結果:
リビジョン番号を使用してデプロイメントコントローラーに以前のリビジョンにロールバックするよう指示できます。まず、ロールバックするリビジョンが正しいデプロイメントであるか確認しましょう。ここでは、3番目のリビジョンにロールバックしようとしています。historyコマンドで指定したリビジョンの詳細を取得するには、リビジョンを指定します。
kubectl rollout history deployment nginx-deployment --revision=3
結果:
リビジョンを確認した後、「kubectl rollout undo」コマンドを「to-revision」パラメータと共に使用してデプロイメントをロールバックします。
kubectl rollout undo deployment nginx-deployment --to-revision=3
kubectl rollout status deployment nginx-deployment
結果:
以上です！これでデプロイメントを正常にロールバックしました。ロールバック後、現在の設定としてデプロイされたため、3番目のリビジョンは表示されなくなります。しかし、ロールバックされた新しいデプロイメントのために、より高いリビジョン番号の新しいレコードを見ることができます。
kubectl rollout history deployment nginx-deployment
結果:
K8sデプロイメントの要約
この記事では、Kubernetesデプロイメントの機能の表面をほんの少し触れただけです。ユーザーは、デプロイメントを他のすべてのKubernetes機能と組み合わせることで、あらゆるニーズに適したより強力なコンテナ化アプリケーションを作成できます。
関連する読み物
Kubernetes ガイド
- Kubernetes (K8s) とは？ Kubernetes 基礎チュートリアル
- Kubernetes クラスター効率を高めるためのベストプラクティス
- ベストプラクティス：Kubernetes 用にアプリケーションを構築する方法
- Kubernetes Pods：入門
- Kubernetes ReplicaSets：簡単な紹介
- Kubernetes デプロイメントの完全な説明
- Kubernetes DaemonSets の使用と管理
- Kubernetes サービスの仕組み
- Kubernetes ポート、TargetPort、および NodePort の使用
- Kubernetes における ConfigMaps の作成と使用
- Kubernetes Secrets の紹介
- Kubernetes ネットワーキングの基礎
- Kubernetes Ingress の説明
- Kubernetes Helm チャートの紹介
- Kubernetes オペレーター パターンとは？
- Kubernetes での StatefulSet としての PostgreSQL のデプロイ
- Kubernetes カスタムリソース定義 (CRD) の説明
- クラウドネイティブアプリケーションのための 3 つの Kubernetes パターン
- Kubernetes コンピュートリソースの説明
- DevOps パイプラインのための Kubernetes セキュリティ
- Kubernetes と Spinnaker を使用した継続的デリバリー
- Kubernetes マルチクラスタ：使用方法と理由
- Kubernetes モニタリング：包括的ガイド
- Kubernetes vs Docker：簡単な比較
- Kubernetes vs Docker Swarm：コンテナオーケストレーションツールの比較
- Kubernetes vs OpenShift：違いは何ですか？
- Kubernetes 認定：取得方法と理由
これらの投稿は私自身の見解であり、BMCの立場、戦略、または意見を必ずしも表すものではありません。