type
status
date
slug
summary
tags
category
icon
password
书籍
目標
OpenShift のネットワークの概念を理解し、探索する。
学習内容
- OpenShift が ソフトウェア定義ネットワーク（SDN） をどのように実装しているかを説明する
- OpenShift のルーティングの仕組みを理解し、実際にルートを作成する
セクション
- OpenShift のソフトウェア定義ネットワーク（SDN）の実装を理解する（ハンズオン演習あり）
- ルートを作成する（ハンズオン演習あり）
実習
- OpenShift のネットワーク概念を探索する
OpenShift におけるソフトウェア定義ネットワーク（SDN）の実装
目標
このセクションを修了すると、受講者は OpenShift がソフトウェア定義ネットワーク（SDN）をどのように実装しているか を説明できるようになります。
ソフトウェア定義ネットワーク（SDN）
通常、Docker のネットワークは ホスト専用の仮想ブリッジ を使用し、ホスト内のすべてのコンテナがこのブリッジに接続されます。このブリッジに接続されたコンテナ同士は通信できますが、異なるホスト上のコンテナとは通信できません。
一般的に、この問題を解決するために ポートマッピング を使用します。コンテナのポートをホストのポートにバインドし、ホストのポートを通じて通信を行います。しかし、多数のホストとコンテナが存在する環境では、ポートの管理が煩雑で難しくなります。
この課題を解決するために、OpenShift Container Platform はソフトウェア定義ネットワーク（SDN）を採用しています。
SDN とは？
SDN（Software-Defined Networking）は、ネットワークの複数のレイヤーを抽象化し、ネットワーク管理を容易にするモデル です。SDN では、トラフィックを制御する「コントロールプレーン」と、実際にデータを転送する「データプレーン」を分離 することで、柔軟なネットワーク管理を可能にします。
OpenShift 3.9 の SDN プラグイン
OpenShift Container Platform 3.9 では、3 つの SDN プラグイン を使用して Pod ネットワークを構成 できます。
- ovs-subnet（デフォルト）
- すべての Pod が フラットなネットワーク に接続される
- Pod 間・サービス間の通信が自由に行える
- ovs-multitenant
- プロジェクト単位の分離を強化 するプラグイン
- 各プロジェクトに Virtual Network ID（VNID） を割り当て、異なるプロジェクト間で Pod・サービスの通信を制限
- VNID = 0 のプロジェクトは、すべての Pod と通信可能（OpenShift のデフォルトプロジェクトは VNID = 0）
- ovs-networkpolicy
- 管理者が独自のネットワーク分離ポリシーを定義できるプラグイン
- Kubernetes の NetworkPolicy オブジェクト を使用して通信制限を設定可能
OpenShift SDN の役割
OpenShift SDN は、Open vSwitch（OVS）を使用したオーバーレイネットワークを構築 し、クラスター内のネットワークを維持します。
通常、マスターノードはクラスターのネットワークを通じてコンテナにアクセスできません。ただし、管理者がマスターをノードとして構成することでアクセスが可能になります。
OpenShift Container Platform のデフォルトインストールにおけるネットワーク動作
OpenShift Container Platform をデフォルトでインストールすると、各 Pod は固有の IP アドレスを取得 します。Pod 内のすべてのコンテナは、同じホスト上にあるかのように動作 します。
Pod ごとに IP アドレスが割り当てられることで、ポートの割り当て、ネットワーク、DNS、ロードバランシング、アプリケーションの設定、移行 などの点で、Pod は物理ホストや仮想マシンのように扱われます。
Pod を直接アクセスする場合、アプリケーションが特定のポートでリスンしている場合、そのポート番号を指定する必要があります。例えば：
このように、Pod を直接アクセスする場合も、Service を通じてアクセスする場合も、適切なポート番号を指定することが重要です。
Kubernetes のサービス（Service）
Kubernetes には サービス（Service） という概念があり、これは OpenShift のアプリケーションにおいて不可欠なリソースです。
サービスは 複数の Pod の前に配置されるロードバランサーの役割 を果たします。サービスは 固定の IP アドレス を提供し、個々の Pod の IP アドレスを追跡する必要なく、Pod との通信を可能にします。
Service を通じてアクセスする場合、Service は Pod に対して安定した名前を提供します。例えば：
ほとんどの実際のアプリケーションは単一のポッドとして実行されません。アプリケーションは水平方向にスケールする必要があり、ユーザーの需要に対応するために複数のポッドで実行されることがあります。OpenShiftクラスターでは、ポッドがクラスター内のノード間で継続的に作成され、削除されます。ポッドが作成されるたびに、異なるIPアドレスが割り当てられます。別のポッドのIPアドレスをポッドが発見する必要がないように、サービスはポッドが実行されている場所に依存せず、他のポッドが使用するための一意のIPアドレスを提供します。サービスは、クライアントからのリクエストをメンバーポッド間で負荷分散します。
OPENSHIFT ネットワーク トポロジー
サービスの背後で実行されているポッドのセットは、OpenShift Container Platformによって自動的に管理されます。各サービスには、クライアントが接続するための一意のIPアドレスが割り当てられます。このIPアドレスは、OpenShift SDNから来ており、ポッドの内部ネットワークとは異なりますが、クラスター内からのみ可視です。選択子と一致する各ポッドは、エンドポイントとしてサービスリソースに追加されます。ポッドが作成されたり削除されたりする際に、サービスの背後にあるエンドポイントは自動的に更新されます。
以下は、最小限のサービス定義のYAML形式の例です：
kind：Kubernetesリソースの種類。この場合はサービス（Service）。
name：サービスの一意の名前。
ports：サービスによって公開されるネットワークポートを説明するオブジェクトの配列。targetPort属性は、ポッドのコンテナ定義からcontainerPort属性と一致する必要があります。クライアントはサービスポートに接続し、サービスはポッド仕様で定義されたtargetPortにパケットを転送します。
selector：サービスがパケットを転送するポッドを見つけるために使用する属性。ターゲットポッドはそのメタデータに一致するラベルを持つ必要があります。サービスが一致するラベルを持つ複数のポッドを見つけた場合、ネットワーク接続はそれらのポッド間で負荷分散されます。
クラスター内外のトラフィックの取得
デフォルトでは、ポッドおよびサービスのIPアドレスはOpenShiftクラスター外部からは到達できません。OpenShiftクラスター外部からサービスにアクセスする必要があるアプリケーションには、次の3つの方法があります：
- HostPort/HostNetwork: このアプローチでは、クライアントはホストのネットワークポートを介して直接アプリケーションポッドにアクセスできます。アプリケーションポッド内のポートは、それらが実行されているホストのポートにバインドされます。このアプローチでは、実行するには昇格された権限が必要であり、クラスター内で多くのポッドが実行されている場合にポートの競合が発生するリスクがあります。
- http://<ホストのIPアドレス>:<ホスト上のポート番号> http://192.168.1.100:30080
注：このアプローチは、このコースの範囲外です。
- NodePort: これは、サービスがノードホストの利用可能なポートにバインドされ、その後接続をサービスのIPアドレスにプロキシする古いKubernetesベースのアプローチです。
oc edit svcコマンドを使用してサービス属性を編集し、NodePortをタイプとして指定し、nodePort属性にポート値を提供します。OpenShiftはその後、ノードホストのパブリックIPアドレスとnodePortで設定されたポート値を通じてサービスに接続をプロキシします。このアプローチは、非HTTPトラフィックをサポートします。 - http://<NodeIP>:<NodePort> http://192.168.1.100:30080
- OpenShift ルート: これはOpenShiftで推奨されるアプローチです。サービスは一意のURLを使用して公開されます。
oc exposeコマンドを使用してサービスを外部アクセス用に公開するか、OpenShift Webコンソールからサービスを公開できます。このアプローチでは、現在、HTTP、HTTPS、SNI付きTLS、WebSocketのみがサポートされています。 - http://<サービス名>-<プロジェクト名>.<クラスターのドメイン>
- http://hello-service.default.apps.example.com
注意
OpenShift のルートについては、次のセクションで詳しく説明します。
以下の図は、NodePort サービスがどのように Kubernetes サービスへの外部アクセスを許可するかを示しています。
以下はNodePortサービス定義のYAML構文の例です：
ポッドが受信リクエストを待機するポート。このポートはポッド仕様のポート番号と一致します。
ホストマシン上のポート。外部クライアントはこのポートを通じて接続します。
サービスのタイプ。この場合、
NodePortとして設定されています。OpenShiftはサービスをサービス定義の
nodePort属性に定義された値にバインドし、このポートはクラスター内のすべてのノードでトラフィックを受け入れるように開かれます。外部クライアントは、任意のノードのパブリックIPアドレスとnodePortを使ってサービスに接続できます。リクエストはサービスの背後にあるポッド間でラウンドロビン方式で負荷分散されます。OpenShiftルートは主にHTTPおよびHTTPSトラフィックに制限されていますが、NodePortは非HTTPトラフィックを処理できます。なぜなら、システム管理者が公開するポートを選択し、クライアントがTCPやUDPなどのプロトコルを使ってこのポートに接続できるからです。
注意
NodePort属性のポート番号はデフォルトで30000-32767の範囲に制限されています。この範囲はOpenShiftのマスター設定ファイルで構成可能です。
注意
NodePortはクラスター内のすべてのノードで開かれており、マスターも含まれます。NodePortの値が指定されていない場合、OpenShiftは自動的に設定された範囲内でランダムなポートを割り当てます。
外部ネットワークへのアクセス
ポッドはホストのアドレスを使って外部ネットワークと通信できます。ホストがポッドが接続する必要があるサーバーを解決できる限り、ポッドはネットワークアドレス変換（NAT）メカニズムを使用してターゲットサーバーと通信できます。
参考
サービスに関する追加情報は、OpenShift SDNセクションに記載されたOpenShift Container Platformのアーキテクチャドキュメントで確認できます。
整理
- ClusterIP：
- クラスター内部からのみアクセス可能です。
- サービスのIPやサービス名（例えば
http://service-name.namespace.svc.cluster.local）を使ってアクセスできます。
- NodePort：
- クラスター内のどのノードのIPでもアクセス可能です。
- アクセス方法は
http://<ノードIP>:<NodePort>です。
- LoadBalancer：
- 外部のロードバランサーIPを使ってアクセスできます。
- Kubernetesでは、LoadBalancerタイプのサービスに外部IPが割り当てられ、外部からそのIPを通じてアクセスします。
- Route（OpenShift特有）：
- ドメイン名（例:
http://service-name.apps.cluster-domain.com）を使ってサービスにアクセスできます。 - RouteはリクエストをNodePortやLoadBalancerサービスに自動的に転送します。
まとめ：
- ClusterIPはクラスター内部専用。
- NodePortとLoadBalancerは外部アクセス可能で、NodePortはノードIP経由、LoadBalancerは外部のロードバランサーIP経由。
- RouteはNodePortやLoadBalancerにリクエストを転送し、ドメイン名でアクセスできます。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/1a6d7ae8-88e2-8064-8021-fe832a242fd6
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
