Azure Kubernetes Service クラスターでアプリケーションをデプロイする
あなたの会社では、クラウドベースのビデオ レンダリング サービスをデプロイする方法を検討しています。 あなたは、クラウドネイティブの開発プラットフォームとして Azure Kubernetes Service (AKS) を選択しました。 クラスターを構成すると、コンポーネントのいずれかをビデオ レンダリング アプリケーションにデプロイできます。 あなたは、会社の Web サイトの静的バージョンをデプロイして、Kubernetes デプロイ プロセスを確認することにします。
Kubernetes のデプロイ方法について説明する前に、同様のアプリケーションを Kubernetes 以外の環境にデプロイするために実行するいくつかの手順を確認することにしましょう。
ターゲットのプラットフォームとして Azure 仮想マシン (VM) を使用するものとします。 最初の手順として、アプリケーションをホストするようにサーバー ソフトウェアを準備します。 次の処理を行います。
- オペレーティング システムのインストール。
- OS を最新のセキュリティとソフトウェアの修正プログラムに更新する。
- Web サーバー ソフトウェアをインストールして構成する。
- Web アプリケーションをデプロイする。
顧客からの需要の増加に対処するために Web サイトをスケーリングする場合、新しい VM ごとに、このプロセスを繰り返します。
別の方法として、Azure Container Instances などのコンテナーベースのプラットフォームで Web サイトを実行する方法があります。 基になるサーバー テクノロジについて心配する必要はありませんが、この戦略を手動で使用するには、いくつかのコンテナーを構成し、管理する必要があります。
Kubernetes と AKS は、コンテナーを調整するのに役立ちます。 Kubernetes コンテナーのオーケストレーション機能を使用すると、クラスター上のワークロードを簡単に管理できます。 コンテナー イメージから構築されたコンテナーを使用してワークロードをデプロイして、AKS クラスター内でアプリケーションを実行します。
以下では、AKS クラスターでワークロードを作成する方法について説明します。
コンテナー レジストリとは
コンテナー レジストリを使用すると、後でデプロイするために、コンテナー イメージをクラウドに安全に格納することができます。 コンテナー レジストリを、複数のバージョンのコンテナー イメージを格納するアーカイブと見なすことができます。 格納された各イメージには、識別用のタグが割り当てられます。
たとえば、イメージ contoso-website:latest があるとします。これは、contoso-website:v1.0.0 というタグが付けられたイメージとは異なるバージョンです。
コンテナー レジストリは、パブリックまたはプライベートのどちらでも指定できます。 プライベート レジストリでイメージにアクセスしてダウンロードするには資格情報が必要で、コンテナー イメージを格納するときにはこの戦略に従います。
Kubernetes では、コンテナー レジストリでホストされているイメージのみをデプロイできます。 通常、プライベート コンテナー レジストリの作成は、標準の AKS デプロイ戦略に含まれます。
Kubernetes ポッドとは
Kubernetes "ポッド" によって、コンテナーとアプリケーションが論理構造にグループ化されます。 これらのポッドにはインテリジェンスがなく、1 つ以上のアプリケーション コンテナーで構成されます。 各ポッドには IP アドレス、ネットワーク ルール、公開されたポートがあります。
たとえば、contoso-website に関連するすべてのワークロードを検索する場合、ラベル app と値 contoso-website を使用して、ポッドのクエリをクラスターに対して実行します。
Kubernetes デプロイとは
Kubernetes デプロイは、ポッドの進化です。 デプロイでは、ポッドをインテリジェントなオブジェクトにラップし、それにより、ポッドを "スケール アウト" することができます。アプリケーションを簡単に複製したり、スケーリングしたりして、より多くの負荷をサポートすることができます。複雑なネットワーク ルールを構成する必要はありません。
デプロイを使用すると、ユーザーは、イメージ タグを変更するだけで、ダウンタイムなしでアプリケーションを更新できます。 デプロイを更新する場合、すべてのアプリを削除する代わりに、オンライン アプリを 1 つずつオフにします。 その後、それらを最新バージョンに置き換えます。 この側面は、どんなデプロイでも、可用性に目に見える影響を与えることなく、そのデプロイ内のポッドを更新できることを意味します。
Kubernetes マニフェスト ファイル
Kubernetes マニフェスト ファイルを使用すると、ワークロードを YAML 形式で宣言的に記述することができ、Kubernetes オブジェクトの管理が簡素化されます。
ワークロードを手動でデプロイする必要がある場合を想像してみてください。 いくつかの側面について検討し、それらを管理する必要があります。 コンテナーの作成、特定のノードの選択とポッドへのラップ、ポッドの実行、実行の監視などを行う必要があります。
マニフェスト ファイルには、記述されたワークロードの作成と管理に必要なすべての情報が含まれます。
Kubernetes ラベルとは
Kubernetes ラベルを使用すると、Kubernetes オブジェクトを論理的にグループ化できます。 これらのラベルにより、システムは、特定の名前を持つラベルと一致するオブジェクトのクエリをクラスターに対して実行できます。
マニフェスト ファイルの構造
マニフェスト ファイルの構造は、作成するリソースの種類によって異なります。 ただし、マニフェスト ファイルで共有される共通の命令があります。 これらの命令では、使用する API、作成するワークロードの種類などのさまざまな側面を定義します。
すべてのマニフェスト ファイルには、最初の 2 つのエントリとして、2 つの重要なキー apiVersion と kind が含まれます。 デプロイ ファイルの例を次に示します。
apiVersion: apps/v1 # Where in the API it resides
kind: Deployment # The kind of workload we're creating
apiVersion キーでは、デプロイするオブジェクトを管理する API サーバー エンドポイントを定義します。
kind キーでは、このデプロイで作成するワークロードを定義します。
すべてのファイルのその他の共通キーは、metadata キーと name キーです。 すべての Kubernetes リソースには名前が "必要" です。 この名前は、metadata キーに含まれます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: contoso-website # This will be the name of the deployment
デプロイでオブジェクトをグループ化する
デプロイでは、label を使用してポッドを検索し、グループ化します。 ラベルは、デプロイのマニフェスト ファイルの一部として定義します。
次に例を示します。 spec 定義に追加された selector 定義で定義されている matchLabels の値に注意してください。
# deployment.yaml
# ...
spec:
selector:
matchLabels:
app: contoso-website
# ...
この時点から、すべてのファイルの構造は、Kubernetes に作成するように指示しているリソースの種類によって異なります。
デプロイ ファイルを適用する
Kubernetes の配置マニフェスト ファイルをデプロイするには、kubectl を使用します。 コマンドの例を次に示します。
kubectl apply -f ./deployment.yaml