2019.10.03

「Kubernetesで初めてのアプリを作ろう」パート3: Service経由の通信 #docker #kubernetes #k8s

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

このブログシリーズのパート1では、Kubernetesでの初めてのアプリ構築の基本をご紹介しました。そしてパート2では、PodとControllerとしてのプロセスについて議論しました。今回は、Pod同士の通信を確実とするための、Kubernetesにおけるネットワーキングの設定方法をご紹介します。

Service経由の通信を設定

現時点までに、私たちはControllerが管理するPodとしてワークロードをデプロイしました。しかしPod同士がお互いに通信する確実で実践的な方法がありません。また、ネットワークに接続しているPodに対して私たちがクラスタの外からアクセスする方法もありません。Kubernetesのネットワーキングモデルによれば、デフォルトであらゆるPodは他のすべてのPodに、当該PodのIPアドレスで通信可能です。しかし、Podは潜在的に再スケジュールされるにも関わらず、各IPアドレスを探し出してそのリストを維持する、言い換えると新しいIPアドレスを取得しなければいけません。もしこれを手動で行うならば、退屈で破綻しやすい作業となるでしょう。

それよりも、アプリケーションのネットワーキング部分の構築を始める準備ができたときには、Kubernetes serviceについて考えるべきです。Kubernetes serviceは、不確かなPodのIPアドレスを通じてではなく、Controllerで定義された固定のメタデータを通じて、トラフィックをPodに転送する信頼できるシンプルなネットワーキングエンドポイントを提供します。シンプルなアプリケーションでは、2つのServiceでほとんどのユースケースをカバーできます: clusterIPとnodePort serviceです。これによって必要となる、もう1つの判断ポイント:

判断ポイントその3: 各Controllerにルーティングするには、どのようなServiceを使うべきか？

シンプルなユースケースでは、clusterIPかnodePort serviceのどちらかを選びます。 どちらを選択するかの決め手になるのは、対象のPodがクラスタ外からアクセス可能とするか否かです。 私たちが例に挙げているアプリケーションでは、ユーザが私たちのウェブアプリにアクセスできるよう、ウェブのフロントエンドは外部からのアクセスを可能とする必要があります。

この場合、私たちはnodePort serviceを作成します。これはKubernetesクラスタ内のあらゆるホスト上の特定のポートから、フロントエンドのPodにトラフィックを転送するものです（Swarmファンの皆さまへ: これはL4ルーティングメッシュに等しい機能です)。

KubernetesのnodePort serviceによって、当該Podへの外部からのトラフィックをルーティングすることができます。

プライベートAPIとデータベースPodは、セキュリティとトラフィック制御の観点から、内部アクセスのみ可能としたい場合もあるでしょう。この場合はclusterIP serviceが最適です。clusterIP serviceは、IPアドレスとポートを提供します。これは 同じクラスタ内の他のコンテナのみに トラフィックの転送を可能とし、バックエンドのPodへの転送も行うものです。