2019.09.25

「Kubernetesで初めてのアプリを作ろう」パート1: はじめに #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

Kubernetes: パワフルだけど時々扱いにくい

コンテナオーケストレータの選択肢としてKubernetesの重要性は増す一方です。なぜならKubernetesは、今日利用可能なコンテナオーケストレータのなかで最も広範な機能を有しているからです。しかしそれには欠点も伴います。最先端のジェット機のコックピットに乗り込むためにユーザは多大な努力を要求される上に、実際どのように飛ばせばいいかが明確ではないためです。

Kubernetesの複雑さは、多くのユーザにとって最初に導入する際の障壁となっています。このブログシリーズでは、Kubernetes向けアプリケーションの設計の基本を、実際に必要となるKubernetesオブジェクトに戦術的な焦点をあてながらご紹介していきます。しかしながらこの記事では、Twelve-Factor Appの設計原理やマイクロサービスアーキテクチャには触れません。アプリケーションの設計をしている人なら誰でもなじみのある、このような戦略的な議論には優れたアイデアもありますが、Docker Training Teamとしては、ここでは具体的なハンズオン演習にできる限り重きをおいていきたいと思います。

さらに、ここではアプリケーションアーキテクチャに焦点を当てていますが、Kubernetesを構築するdevopsエンジニアと開発者には、アプリケーションアーキテクチャについて読むだけでなく、理解することを強く推奨します。コンテナオーケストレーションが主流になるにつれ、devopsチームはアプリケーションアーキテクトたちがチームにサポートを期待するアーキテクチャパターンを予測する必要があります。一方で開発者は、特にネットワーキングや設定の利用に関するアプリケーションロジックに直接影響するオーケストレータの機能について把握しておかなければなりません。

ちょうどいいKubernetes

Kubernetesのように機能が豊富なマシンを使い始める際の成功の鍵は、理解が必要となる最小限の範囲を特定することです。核となる理論を理解した後で、その他の機能について学ぶ時間はたっぷりあります。アプリケーションを実行する場がKubernetesであれ何であれ、考慮すべき点は4つあります:

プロセス

コンパイルしたりインタプリタに通したりする、あなたが実際に実行しているコードが、アプリケーションの核です。これらのプロセスをスケジュールするだけではなく、維持したりスケールしたりする機能群がそのうち必要となっていくでしょう。そのために Pod と Controller を使うことになります。

ネットワーキング

アプリケーションを構成するプロセスは、お互いに、または外部リソースや外の世界と通信する必要が出てくる傾向にあります。そこで、アプリケーションのすべてのコンポーネント間の、サービスディスカバリやロードバランシングとルーティングを行える機能が必要となります。これには KubernetesのService を使用します。

設定

よく書かれたアプリケーションは設定をハードコーディングするのではなく、取り除きます。これはコーディングにおける「Don't Repeat Yourself (同じことを繰り返さない)」の原則を適用した直接的な結果です。アクセストークン、外部リソースのロケーション、環境変数など コンテキストによって変わる ものは、必要に応じて読み込んだり更新できる場所のみで定義するべきです。オーケストレータは取り外し可能な形式で、設定のプロビジョニングが可能であるべきです。これには volume と configMap を使います。

ストレージ

適切に構築されたアプリケーションはコンテナが短命であることを知っており、ファイルシステムは警告なしに破壊されることも知っています。コンテナによって収集または生成されたあらゆるデータは、コンテナへプロビジョニングが必要なあらゆるデータ同様、何らかの外部ストレージに保管するべきです。これには Container Storage Interface (CSI)プラグイン と persistentVolume を使用します。

これで すべて です。基本をマスターした後、あなたのKubernetesアプリが更なる高みに到達するために何を学ぶべきかのヒントとなる「上級者向けのトピック」は今後のブログシリーズでお伝えします。はじめは前述のコンポーネントに注力してください。

ちょうどいい高度な設計

記事のはじめに、このシリーズは戦略的なものよりも具体的なことに焦点を当てるとお話しました。しかしここで、高度な設計ポイントをいくつかご紹介したいと思います。これから先に続く技術的な決定を理解するためと、コンテナ化プラットフォームの恩恵を最大限受けられるようにするために必要なポイントです。どのオーケストレータを使用していようとも、アプリケーションのコンテナ化を成し遂げる際の標準を定義する、心に留めておくべき重要原則が3つあります。 可搬性 、 拡張性 、 共有性 です:

可搬性

どのようなアプリを構築するにせよ、あらゆるKubernetesクラスタ上でデプロイできるものでなくてはなりません。つまり基礎となるホストやファイルシステムの設定や機能などに、強固に依存しないアプリケーションでなければなりません。開発用のマシンからテストサーバへアプリケーションを移動することにストレスを感じるならば、何かを考え直す必要があるということです。

拡張性

コンテナ化アプリケーションは、より多くのコンテナを、コンテナのみでなく、より多くのコンピューティング資源と共に 水平的に 拡張する際、最もその拡張性が発揮されます。コンテナにどれだけのリソースが割り当てられているかを気にする必要はありません。クラスタの設定変更や負荷に適合しようと試みているとしても、コンテナは死ぬ運命にあり、オーケストレータが管理するオブジェクトもしばしば短命です。したがって、意図しているよりも多くのコンテナの複製を簡単に活用できるように、アプリケーションを改良する必要があります。典型的にはオーケストレータのルーティングとロードバランシング機能を使用することと、コンテナを可能な限りステートレスとすることです。

共有性

構築するすべてのアプリのメンテナンスやコンサルティングに永遠にかかわらなくてはならない事態は避けたいものです。自分が構築したアプリを、将来託すかもしれない開発者や、本番環境でそのアプリを管理しなければならない運用者、またはオープンソースの文脈でそのアプリを活用できるかもしれないサードパーティに対して、共有できることは重要です。可搬性に関しては、まだ開発途中です。クラスタからクラスタへとアプリを移動することが可能であることを確認中です。それは技術的に可能であるということ以上に、他者に託すことを 簡単に、そして信頼できる方法で 行えるか否かということを保証する必要があり、その確認の最中です。構築したアプリを新たな別のクラスタで起動することが、少なくとも最初の1回は誰にでもできるほど、可能な限り簡単にするつもりです。

Kubernetesにおける最初のアプリについての熟考

このシリーズでは今後、Kubernetes向けのシンプルな3層構造のウェブアプリについて、次の代表的なコンポーネントの観点から考察します:

アプリケーションが要求するすべてのデータを保持するデータベース
データベースへのアクセスが許可されているAPI
ユーザがウェブアクセス可能であり、データベースと通信できるAPIを使用するフロントエンド

たとえこのようなアプリケーションに自分は縁がないと思えても、これらはとてもためになる例です。さまざまな種類のアプリケーションに広く適用可能な判断ポイントをご紹介するので、どのように判断するかの例を確認できるでしょう。前述の一般的なアプリケーションは、皆さんを関連のある概念へのツアーにお連れするための車にすぎませんが、一般的に幅広く適応できる例でもあります。

あなたのアプリケーションの各コンポーネントのDockerイメージをすでに作成したと仮定してください。コンポーネントは先に上げたものに似ていても、まったく異なるものでも構いません。Dockerイメージの設計とビルドについての手引きが必要な方は、私の同僚のTibor Vassの、Dockerfileベストプラクティスについてのすばらしいブログ記事をご参照ください。