デプロイ時の課題をKubernetes×Helmで解決！ サードパーティリソースへのアクセス管理

原題：How to Manage Access to 3rd Party Resources in Kubernetes with Helm

　Kubernetesはコンテナ化されたアプリケーションのイノベーションプラットフォームとして、近年注目されています。Kubernetesを使用すると、コンテナ化されたアプリケーションをクラウド/オンプレミス/ハイブリッド環境で簡単にデプロイして実行できます。そんなKubernetesの躍進を支えたテクノロジーの1つが、Kubernetesアプリケーションのパッケージ化/インストール/管理に使用されるHelmだと言えるでしょう。Talendのクラウドアプリケーションでも、KubernetesとHelmを使用しています。本稿では、デプロイ時に発生する課題への対応にKubernetesのリソースとHelmチャートを使用する方法を紹介します。なお、この記事はTalend本社ブログから翻訳・転載したものです。

　原文：How to Manage Access to 3rd Party Resources in Kubernetes with Helm

Helmとは？

　Helmは、KubernetesのSIG-Appsで開発されているものです。yum, aptに相当するパッケージマネージャーで、Linux、 OSXのバイナリが用意されています。しがって、DevOpsに携わる人は覚えておきたい情報です。

はじめに

　ここでは、PostgreSQLデータベースへの接続が必要なKubernetesアプリケーションを例に説明します。

　まず、アプリケーションのデプロイを管理するためにHelmチャートを作成します。この段階ではまだ、PostgreSQLのプロビジョニング方法と、アプリケーションからPostgreSQLへの接続の管理方法について詳細は分かりません。

　これらの最適な方法は、一見すぐに見つかるように思えますが、PostgreSQLには多様なデプロイ方法があるため、実際にはより複雑な問題となります。そこで、まずはPostgreSQLのデプロイシナリオをいくつか検討してみましょう。以下のシナリオは、TalendがKubernetesとHelmを試す過程で実際に使用したものです。

組み込み型のデプロイシナリオ

　次の図に示すように、このシナリオではKubernetesクラスター内のアプリケーションとともにPostgreSQLがデプロイされます。

図1：組み込み型PostgreSQLのプロビジョニング

　これは、実稼働システム向けの完璧なシナリオとは言えないかもしれませんが、PostgreSQLを短時間で稼働するための簡単で柔軟な方法です。

　公式のKubernetes Helmチャートリポジトリーでは、クラスター内にPostgreSQLデータベースをインストールして構成するPostgreSQLチャートが提供されています。データベース名、データベースのユーザー名、データベースのパスワードは、values.yamlファイル内に指定したり、インストール時に入力パラメーターとして指定したりできます。このチャートでKubernetesのシークレットに格納されたデータベースのパスワードは、PostgreSQLコンテナをホストするポッドと、データベースに接続する必要があるアプリケーションによって使用されます。

OSBA展開シナリオ

　サービスプロバイダーは、OSBA（Open Service Broker API）を使ってKubernetesなどのクラウドネイティブなプラットフォームで実行するアプリケーションにサービスを提供できます。これは、Kubernetesのマニフェストを使用してクラウドプロバイダーが管理するリソースを、プロビジョニングすることを目的としています。

　このシナリオでは、Kubernetesサービスカタログを使用してMicrosoft Azureサービスブローカーに接続し、PostgreSQLデータベースをプロビジョニングします。

図2：OSBA PostgreSQLのプロビジョニング

　Azure Data Catalogサービスは、3種類のPostgreSQL構成を提案しています。

• クラスターのみのプロビジョニング
• クラスターとデータベースのプロビジョニング
• 既存クラスターでの新しいデータベースのプロビジョニング

　ここでは、組み込み型のモデルと同様のセットアップを行うために、クラスターとデータベースの両方のプロビジョニングを選択しています。

　クラスター/データベースがプロビジョニングされると、サービスブローカーは、Kubernetesクラスター内にシークレットを作成します。シークレットには、PostgreSQLデータベースにアクセスするために必要なすべてのパラメーター（ホスト、ポート、データベース名、ユーザー、パスワードなど）が含まれます。組み込み型シナリオの場合と同様に、このシークレットはデータベースに接続する必要のあるアプリケーションによって使用されます。

　作成されたシークレットはサービスブローカープロバイダーが決定したフォーマット方式に大きく依存するので、注意してください。シークレットのキーは、クラウドプロバイダーによって異なる可能性があります。Open Service Broker for AzureとPostgreSQLの詳細もご覧ください。

外部展開シナリオ

　このシナリオでは、PostgreSQLデータベースがKubernetesクラスターの外部でプロビジョニング/管理されることになります。外部とは、クラウド環境のマネージドサービス（Amazon RDS）、クラウド/オンプレミス環境でユーザー自身が管理しているPostgreSQLクラスターなどです。

　Kubernetesが提供する「セレクター無しのサービス」は、特殊なサービスで、クラスター内のリソースからクラスター外のリソースへの通信を可能にします。このシナリオでは、セレクター無しのサービスを使用して、クラスター内に展開されたアプリケーションから外部のPostgreSQLデータベースに接続します。

図3：外部PostgreSQLのプロビジョニング

　データベースホストとアクセスクレデンシャルは、クラスター内のアプリケーションがアクセスできるKubernetesシークレットに格納されています。この場合、シークレットの属性は、サービスに必要なパラメーターと一致するように自動的に選択されます。