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