|
Kubernetesへのアプリケーションのデプロイは簡単ではありません。DeploymentをPodとしてデプロイし、Service内でのアクセス性を定義する必要があります。これらのリソースはすべて、YAMLファイルを正しく定義・設定する必要があります。 重要な点として、アプリケーションはデータベースとの通信、Webコンテンツの管理、ログの設定などが必要になる場合があります。さらに、これらのパラメータはデプロイメント環境によって異なる可能性があります。こうした状況により、YAML定義のコードベースが急増し、各コードベースに1行か2行の変更しか含まれていないため、ソースの特定が困難になる可能性があります。 Kustomizeは、これらの問題を解決するために設計されたオープンソースの構成管理ツールです。Kubernetes v1.14以降、kubectlはKustomizeとkustomizationファイルを完全にサポートしています。 この記事では、小規模なウェブアプリケーションを構築し、Kustomize を使って設定拡張を管理し、異なる設定で開発環境と本番環境にアプリケーションをデプロイします。さらに、Kustomize の Base と Overlay を使用してこれらの可変設定を階層化し、コードの可読性と保守性を向上させる方法も紹介します。 K8sミートアップ 前提条件 まず、次のことが必要です。
K8sミートアップ ステップ1: Kustomizeなしでアプリケーションをデプロイする Kustomize を使用してアプリケーションをデプロイする前に、まずは従来のデプロイを試みます。今回は、Nginx でホストされている静的 Web アプリケーションである sammy-app の開発版をデプロイし、Web コンテンツを ConfigMap にデータとして保存し、Deployment 内の Pod にインストールします。それぞれに個別の YAML ファイルが必要なので、作成します。 まず、アプリケーションとそのすべての設定ファイル用のフォルダを作成します。この記事のすべてのコマンドはこのフォルダから実行します。ホームディレクトリに新しいフォルダを作成します。
次に、テキスト エディターを使用して、configmap.yml という名前のファイルを作成して開きます。
次のコンテンツを追加します。 ~/sammy-app/configmap.yml これにより、新しい ConfigMap オブジェクトが作成され、sammy-app という名前が付けられ、いくつかの HTML Web コンテンツが data: に保存されます。 ファイルを保存して閉じます。 別のdeployment.yml ファイルを作成して開きます。
次のコンテンツを追加します。 ~/sammy-app/deployment.yml これにより、新しいデプロイメントオブジェクトが作成され、名前とラベルに sammy-app が追加され、レプリカ数が 1 に設定され、使用するオブジェクトが Nginx v1.17 コンテナイメージであることが指定されます。さらに、コンテナポートが 80 に設定され、CPU とメモリのリクエストと制限が定義され、ログレベルが DEBUG に設定されます。 ファイルを保存して閉じます。 両方のファイルがKubernetesクラスターにデプロイされました。次に、`cat`コマンドを`kubectl`にパイプするための複数のオブジェクトを作成します。
しばらく待ってから、kubectl を使用してアプリケーションのステータスを確認します。
最終的に、READY 列に、1/1 コンテナとともに実行中のポッドとアプリケーションが表示されます。 Podは実行されており、Deploymentによってサポートされていますが、アプリケーションにアクセスできません。まず、Serviceを追加する必要があります。 3 番目の YAML ファイル (service.yml) を作成して開きます。
次のコンテンツを追加します。 ~/sammy-app/service.yml これにより、sammy-app という名前の新しい Service オブジェクトが作成されます。ほとんどのクラウドプロバイダーでは、spec.type を LoadBalancer に設定するとロードバランサーがプロビジョニングされます。spec.ports は、指定されたラベルを持つすべての Pod のターゲット TCP ポートを指定します。 spec.ports は、sammy-app のタグが付けられたすべての Pod のターゲットとして TCP ポート 80 を指定します。 ファイルを保存して閉じます。 次に、Service を Kubernetes クラスターにデプロイします。
しばらく待ってから、kubectl を使用してアプリケーションのステータスを再度確認します。
最後に、EXTERNAL-IP 列にサービスのパブリック IP が表示され、一意の IP が your_external_ip に表示されます。 表示された IP アドレスをコピーして Web ブラウザに入力すると、DEVELOPMENT アプリケーションのバージョンを確認できます。 ターミナルでは、CTRL + C を押すことでサービスの監視を停止できます。 このステップでは、sammy-app の開発バージョンを Kubernetes にデプロイします。ステップ 2 と 3 では、Kustomize を使用して sammy-app の開発バージョンを再デプロイし、その後、構成を少し変更した本番環境バージョンをデプロイします。この新しいワークフローを使用することで、Kustomize が構成変更をより適切に管理し、開発ワークフローを簡素化する方法を確認できます。 K8sミートアップ ステップ2: Kustomizeを使用してアプリケーションをデプロイする このステップでは、デフォルトの Kubernetes アプローチではなく Kustomize を使用して、まったく同じアプリケーションをデプロイします。 現在のファイルシステムは次のようになります。 このアプリケーションを Kustomize 経由でデプロイするには、kustomization.yml ファイルを追加する必要があります。
このファイルは、kubectl が kustomation ファイルを処理するために使用する kubectl -k を使用するときに管理するリソースを指定します。 次のコンテンツを追加します。 ~/sammy-app/kustomization.yml ファイルを保存して閉じます。 再デプロイする前に、手順 1 から既存の Kubernetes リソースを削除します。
次に、Kustomize を使用して再デプロイします。
`kubectl -f` を使用して Kubernetes にファイルからリソースを作成するように指示する代わりに、`-k` とディレクトリ (この場合、`.` は現在のディレクトリを表します) を使用します。これにより、`kubectl` を使用して `Kustomize` にアクセスし、そのディレクトリ内の `kustomization.yml` ファイルを検査します。 これにより、ConfigMap、Deployment、Serviceの3つのリソースがすべて作成されます。`get pods`コマンドを使用して、Deploymentを確認します。
READY 列に、実行中のアプリケーションと 1/1 コンテナを含む別のポッドが表示されます。 `get services` コマンドを再実行すると、パブリックにアクセス可能な EXTERNAL-IP 経由でもサービスが表示されます。
これで、Kustomize を使用して Kubernetes 構成を管理することができました。次のステップでは、少し異なる構成で sammy-app を本番環境にデプロイし、Kustomize を使用してこれらの差異を管理します。 K8sミートアップ ステップ 3: Kustomize を使用してアプリケーションを管理します。 複数のリソースタイプを扱い始めると、Kubernetesのリソース設定ファイルは急増し始めます。特に開発環境と本番環境のように環境間の違いが小さい場合は顕著です。deployment-development.yml と deployment-production.yml ファイルはあっても、deployment.yml ファイルは存在しない、といった状況です。 Nginx Dockerイメージの新しくリリースされたバージョンを使い始めたらどうなるか想像してみてください。おそらく、`deployment-development.yml`で新しいバージョンをテストし、そのまま使い続けたいと思ったものの、`deployment-production.yml`で更新するのを忘れてしまうでしょう。その結果、開発環境で実行されているNginxのバージョンが、本番環境で実行されているバージョンと異なる可能性があります。このような設定エラーは、アプリケーションに不具合をもたらす可能性があります。 Kustomize はこれらの管理問題を大幅に簡素化します。Kubernetes 設定ファイルと kustomization.yml ファイルを含むファイルシステムができました。 現在、sammy-app を本番環境にデプロイする準備をしており、アプリケーションの本番バージョンを次の点で開発バージョンと異なるものにしたいと考えています。
まず、Kustomize 方式で整理するための新しいディレクトリを作成します。
これにより、「デフォルト」構成のベースが保持されます。この例では、これはsammy-appの開発バージョンです。 ここで、現在の sammy-app/ 構成をこのディレクトリに移動します。
次に、本番環境の設定用の新しいディレクトリを作成します。Kustomizeではこれをオーバーレイと呼びます。オーバーレイはベースの上にあるレイヤーと見なすことができ、機能するにはベースが必要です。
本番オーバーレイを定義するために別の kustomization.yml ファイルを作成します。
次のコンテンツを追加します。 ~/sammy-app/オーバーレイ/production/kustomization.yml このファイルは、オーバーレイのベースと、Kubernetesがリソースにパッチを適用する際に使用する戦略を指定します。この例では、ConfigMapとDeploymentリソースを更新するための戦略的マージスタイルのパッチ（SMP）を指定しています。 ファイルを保存して閉じます。 最後に、新しい deployment.yml ファイルと configmap.yml ファイルを overlays/production/ ディレクトリに追加します。 まず、新しいdeployment.yml ファイルを作成します。
ファイルに次の内容を追加します。 ~/sammy-app/オーバーレイ/production/deployment.yml この新しいdeployment.ymlの内容に注目してください。変更されたリソース（この場合はアプリケーションのDeployment）を識別するTypeMetaフィールドのみが含まれ、残りのフィールドはコンテナリソースのリクエストと制限（requestとlimit）などの新しいフィールド値を指定するためにネストされています。 ファイルを保存して閉じます。 次に、本番オーバーレイ用の新しい configmap.yml を作成します。
次のコンテンツを追加します。 ~/sammy-app/overlays/production/configmap.yml ここでは、テキストがDEVELOPMENTからPRODUCTIONに変更され、テキストの色も赤（#f22）から青（#22f）に変更されています。Kustomizeのような構成管理ツールがなければ、このような微妙な変更を見つけて追跡するのは非常に面倒です。 ディレクトリ構造は次のようになります。 以下の手順では、基本設定を使用してデプロイします。まず、既存のリソースを削除します。
基本構成を Kubernetes にデプロイします。
デプロイメントの確認:
期待される基本構成を確認できるようになりました。開発バージョンは、サービス EXTERNAL-IP で確認できます。 今すぐ本番環境の構成をデプロイします。
デプロイメントを再確認します。
予想される本番構成が表示され、本番バージョンがサービス EXTERNAL-IP に表示されます。 本番環境の構成では、Pod は 1 つではなく合計 3 つあることに注意してください。デプロイメント リソースをチェックして、マイナーな変更も有効になっていることを確認できます。
ブラウザで your_external_ip にアクセスして、Web サイトの製品版を表示します。 現在、アプリケーションの差分管理にはKustomizeを使用しています。当初の問題の一つを思い出してください。Nginxミラーのバージョンを変更したい場合、Baseのdeployment.ymlファイルを変更するだけで、そのBaseを使用するOverlayにもKustomizeを通じて変更が反映されます。これにより、開発ワークフローが大幅に簡素化され、可読性が向上し、エラーの可能性も低減されます。 K8sミートアップ 結論は この記事では、小規模なウェブアプリケーションを構築し、Kubernetesにデプロイした後、Kustomizeを使用して異なる環境向けのアプリケーション構成の管理を簡素化した方法について説明します。ほぼ同一のYAMLファイル群を階層化モデルに再編成することで、エラーや手動設定を削減し、コードの識別と保守を容易にしました。 |
