「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への転送も行うものです。
Kubernetes clusterIP serviceは同じクラスタ内部からのトラフィックのみを許可します。
チェックポイント その3: yamlを書き、ルーティングを検証する
Kubernetes yamlを書いて、自身のアプリケーションに適切に選択したServiceを記述しましょう。そしてトラフィックが期待どおりにルーティングすることを確認しましょう。
高度なトピックス
前述のシンプルなルーティングとサービスディスカバリによって、Pod同士の通信とシンプルなトラフィックの流入が可能となります。しかし今後構築するアプリケーション向けには、高度なパターンが数多くあります:
Headless Service
これは特定のPodのディスカバリとルーティングに使用できます。statefulSet controllerによって宣言されたステートフルなPodに使用します。
Kubernetes IngressとIngressController
これらのオブジェクトは、レイヤー7でのルーティング向けや、スティッキーセッションやパスベースルーティングなどのパターンの実装向けに、マネージドプロキシを提供します。
ReadinessProbe
これは前述のLivenessProbeとまったく同じように機能しますが、コンテナとPodのヘルス管理の代わりに、ネットワークトラフィックの受け入れに対する準備状況をモニタリングし対応するものです。
NetworkPolicy
これは通常のフラットでオープンなKubernetesネットワークを分割します。これにより、無許可のエンドポイントとの通信を防ぐため、Podにどの流入・流出の通信を受け入れ可能とするかを定義することができます。
Kubernetesアプリケーション設定パート4に続きます。
この記事でご紹介したトピックスについての詳細は、Kubernetesドキュメントをご参照ください:
Docker社によるPlay with Kubernetesもご覧ください。
2020年はじめには、Kubernetesトレーニングも開始する予定です。トレーニングでは、より詳細な事例とハンズオン演習を提供します。トレーニングを受講可能な時期についてお知らせを受け取るには、こちらにサインアップしてください: トレーニングについてお知らせを受け取る
原文: Designing Your First Application in Kubernetes, Part 3: Communicating via Services
