Kubernetesで初めてのアプリを作ろう」: まとめ #docker #kubernetes #k8s
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
強力なコンテナオーケストレータであるKubernetesは、ITアーキテクトに選ばれるコンテナオーケストレータとしての地位を確立してきました。しかし欠点もあります。最先端のジェット機のコックピットに乗り込むためにユーザは多大な努力を要求される上に、実際どのように飛ばせばいいかが明確ではないのです。Kubernetesの複雑さは、多くのユーザにとって最初に導入する際の障壁となっています。
私が書いたブログシリーズ「Kubernetesで初めてのアプリを作ろう」では、Kubernetes向けアプリケーションの設計の基本を、実際に必要となるKubernetesオブジェクトに戦術的な焦点をあてながらご紹介しました。各記事では詳細を深堀りしていますので、ここでは各記事へのリンクと共に、記事の概要をご紹介します。
その1: まず始めに
ちょうどいいKubernetes
Kubernetesのように機能が豊富なマシンを使い始める際の成功の鍵は、理解が必要となる最小限の範囲を特定することです。核となる理論を理解した後で、その他の機能について学ぶ時間はたっぷりあります。アプリケーションを実行する場がKubernetesであれ何であれ、考慮すべき点は4つあります:
- プロセス: Kubernetesにおいては、プロセスをスケジューリング・維持・スケーリングするためにPodとControllerを使用することを意味します。
- ネットワーキング: KubernetesのServiceによって、アプリケーションコンポーネントは相互に対話することが可能となります。
- 設定: よく書かれたアプリケーションは設定をハードコーディングするのではなく、取り除きます。Kubernetesでは、VolumesとconfigMapを使用します。
- ストレージ: コンテナは短命なので、維持したいデータはどこか別の場所に保管しなければなりません。これには Container Storage Interface (CSI) プラグイン と persistentVolume を使用します。
ちょうどいい設計
ここで、高度な設計ポイントをいくつかご紹介したいと思います。これから先に続く技術的な決定を理解するためと、コンテナ化プラットフォームの恩恵を最大限受けられるようにするために必要なポイントです。オーケストレータを使用していようとも、アプリケーションのコンテナ化を成し遂げる際の標準を定義する、心に留めておくべき重要原則が3つあります: 可搬性、拡張性、共有性 です。これら3つは、コンテナ化がアプリケーションにもたらす基本的な利点です。あなたがアプリケーションをコンテナ化した際に、これら3つについて 恩恵を感じられない 場合は、何かを考え直す必要があるかもしれません。
アプリケーションの開発に使用するKubernetesと、その始め方についてもっと知りたい方は、ブログシリーズ 「Kubernetesで初めてのアプリを作ろう」その1をご覧ください。
その2: プロセスの設定
いかなるアプリケーションもその核となるのは実行プロセスです。そしてKubernetesでは Pod としてプロセスを作成します。Podは個々のコンテナに比べて、少し手が込んでいます。すなわち、コンテナの一群としてまとめてスケジュールでき、単一ホストにまとめて配置できます。これが最初の判断ポイントとなります。 プロセスをどのようにPodにまとめればよいのでしょうか？
1つのPodは2つ以上のコンテナをもつことができますが、同じPod内にあるコンテナは同時にスケールしなければなりません。
Podの設定に際して考慮すべき重要な点は2つあります:
Podsとコンテナは一緒にスケーリングできなくてはなりません。 アプリケーションのスケールアップが必要な場合、Podを追加しなければなりません。それにはPodが有する各コンテナの複製が伴います。
KubernetesのControllerは、Podのスケジュールに最適です。 なぜならDeploymentやdaemonSetなどのControllerは、Podが持っている機能以上に、ワークロードの維持やスケーリングのための多数の運用機能を提供しているからです。
アプリケーション管理のためのプロセスの設定について、もっと知りたい方はブログシリーズ「Kubernetesで初めてのアプリを作ろう」その2をご覧ください。
その3: Service経由の通信
Controllerが管理するPodとしてワークロードをデプロイしたのち、開発者に煩雑な作業を発生させずに、これらのPodがお互いに通信する確実な方法を確立しなければなりません。
そこで KubernetesのService の出番です。KubernetesのServiceは、Controllerで定義された固定のメタデータを通じて、トラフィックをPodに転送するための信頼できるシンプルなネットワーキングエンドポイントを提供します。基本的なアプリケーションでは clusterIP と nodePort の2つのServiceでほとんどのユースケースをカバーできます。これによって必要となる、もう1つの判断ポイント: 各Controllerにルーティングするには、どのようなServiceを使うべきか？
どちらを選択すべきかを決める最もシンプルなポイントは、対象のPodがクラスタ外からアクセス可能とするか否かです。
- Kubernetesの nodePort serviceによって、当該Podへの外部からのトラフィックをルーティングすることができます。
- Kubernetesの clusterIP serviceは同じクラスタ内部からのトラフィックのみを許可します。
KubernetesのService経由の通信についてと、 clusterIP と nodePort Serviceのどちらを選ぶべきかについては、ブログシリーズ「Kubernetesで初めてのアプリを作ろう」その3をご覧ください。
その4: 設定
あらゆるコンテナ化アプリのデザイン原則の中心にあるものは、可搬性です。Kubernetesでアプリケーションを構築する際、アプリが意図する環境特有の 設定 で起きる問題に対処しなければなりません。
よく設計されたアプリケーションは、設定をコンテナ自身とは切り離した独立したオブジェクトとして扱います。また設定はコンテナの実行時にプロビジョニングされます。アプリケーションを設計するときは、このようにプラガブルとしたい設定がどれであるかを特定する必要があります。これによって必要となる、もう1つの判断ポイント: どのアプリケーション設定が、環境ごとに変更が必要か？
通常、これらは各環境ごとに変更される環境変数または設定ファイルになります。例えば、ステージング環境と本番環境で異なるサービス用のアクセストークンや、異なるポート設定などです。
アプリケーション内でプラガブルな設定を特定したら、Kubernetesのシステムである Volume と configMap を使って、望みの動作をさせることができます。
ConfigMapとVolumeは、コンテナに設定を提供するための働きをします。
設定についてもっと知りたい方は、ブログシリーズ「Kubernetesで初めてのアプリを作ろう」その4をご覧ください。
その5: ストレージ
Kubernetes向けのアプリケーションを構築する際に私たちが考慮したいコンポーネントの最後は、ストレージです。コンテナのファイルシステムは一時的なものだということを思い出してください。つまりそこに保存されているデータは、そのコンテナが終了または再スケジュールされると、コンテナとともに削除されるリスクを伴っています。
価値あるデータを生成または収集するコンテナはすべて、安定した外部のストレージにデータをプッシュするべきです。逆に、大量のデータのプロビジョニングが必要なすべてのコンテナは、外部ストレージからそのデータを取得しましょう。
これによって必要となる、もう1つの判断ポイント: あなたのアプリケーションが収集または使用するデータのうち、Podのライフサイクルを越えて存続すべきデータはどれか？
これに取り組むためには、Kubernetesのストレージモデルを活用します。Kubernetesのストレージモデルは、多くの部品によって成り立っています: Container Storage Interface (CSI) プラグイン、 StorageClass 、 PersistentVolume (PV)、 PersistentVolumeClaim (PVC)、 Volume です。
あなたのアプリケーションのために、Kubernetesのストレージモデルをどのように活用すべきかについて、もっと知りたい方は、「Kubernetesで初めてのアプリを作ろう」その5をご覧ください。
今後の抱負
多岐にわたるアプリケーションのコンテナ化に際して必要となる基本のKubernetesの機能を紹介しました。また次の段階として、より高度な情報を得るために参照すべき場所もご紹介しました。実際にワークロードのコンテナ化、それらのネットワーキング、設定のモジュール化、ストレージでのプロビジョニングを行って、今回紹介した項目に習熟してください。
Kubernetesアプリケーション構築の基本をマスターしたら、 「このアプリケーションは基本的な可搬性・拡張性・共有性の価値をどれだけ満たしているか？」 と自問自答してください。コンテナはクラスタ間やユーザ間を簡単に行き来できるものとして開発された技術ですが、あなたが構築したアプリケーション全体も同様でしょうか？アプリケーションの一貫性を保ちつつ、実行予定のいかなるユニットテストも統合テストも無効化せずに、アプリケーションをさまざまに移動するには、どうすればよいでしょうか？
Docker Appは、1つのイメージを移動させるのと同じくらい簡単に移動できる、統合バンドル内にアプリケーションをパッケージングすることで、この課題を解決する取り組みに乗り出しました。Kubernetesアプリケーションのためのこの新たな形式についての詳細は、今後ブログ記事で紹介して参ります。
KubernetesとDockerについてもっと知りたい人は：
- Docker EnterpriseとDocker DesktopにおけるKubernetesの実行について、もっと知る。
- Docker社によるPlay with Kubernetesもご覧ください。
2020年はじめには、Kubernetesトレーニングも開始する予定です。トレーニングでは、より詳細な事例とハンズオン演習を提供します。トレーニングを受講可能な時期についてお知らせを受け取るには、こちらにサインアップしてください: トレーニングについてお知らせを受け取る
