第24章 Ingress トラフィックの固有の外部 IP の割り当て
24.1. 概要
外部トラフィックをクラスターにつなぐ方法の 1 つとして、ExternalIP または IngressIP アドレスを使用することができます。
この機能は、クラウド以外のデプロイメントでのみサポートされます。クラウド (GCE、AWS、および OpenStack) デプロイメントの場合、ロードバランサーサービスを使用し、クラウドの自動デプロイメントでサービスのエンドポイントをターゲットに設定します。
OpenShift Container Platform は 2 つの IP アドレスのプールをサポートします。
- IngressIP は、サービスの外部 IP アドレスを選択する場合に Loadbalancer で使用されます。
- ExternalIP は、ユーザーが設定されたプールから特定 IP を選択する場合に使用されます。
これらはいずれも、ネットワークインターフェースコントローラー (NIC) または仮想イーサネット、または外部ルーティングのいずれであっても、使用される OpenShift Container Platform ホストのデバイスに設定される必要があります。この場合、Ipfailover はホストを設定し、NIC を設定するため、これを使用することが推奨されます。
IngressIP および ExternalIP はいずれも外部トラフィックのクラスターへのアクセスを可能にし、適切にルーティングされている場合に、外部トラフィックはサービスが公開する TCP/UDP ポート経由でサービスのエンドポイントに到達できます。これは、外部 IP をサービスに手動で割り当てる際に、制限された数の共有 IP アドレスのポート領域を管理しなくてはならない場合よりも単純になります。またこれらのアドレスは、高可用性を設定する場合に仮想 IP (VIP) としても使用できます。
OpenShift Container Platform は IP アドレスの自動および手動割り当ての両方をサポートしており、それぞれのアドレスは 1 つのサービスの最大数に割り当てられることが保証されます。これにより、各サービスは、ポートが他のサービスで公開されているかによらず、自らの選択したポートを公開できます。
24.2. 制限
ExternalIP を使用するには、以下を実行できます。
-
externalIPNetworkCIDRs範囲から IP アドレスを選択します。 マスター設定ファイルで、IP アドレスを
ingressIPNetworkCIDRプールから割り当てます。この場合、OpenShift Container Platform はローカルバランサーサービスタイプのクラウド以外のバージョンを実装し、IP アドレスをサービスに割り当てます。注意割り当てた IP アドレスがクラスター内の 1 つ以上のノードで終了することを確認する必要があります。既存の
oc adm ipfailoverを使用して外部 IP の可用性が高いことを確認します。
手動で設定された外部 IP の場合、起こり得るポートのクラッシュについては 「first-come, first-served (先着順)」で処理されます。ポートを要求する場合、その IP アドレスに割り当てられていない場合にのみ利用可能となります。以下は例になります。
手動で設定された外部 IP のポートのクラッシュ例
2 つのサービスが同じ外部 IP アドレス 172.7.7.7 で手動で設定されている。
MongoDB service A がポート 27017 を要求し、次に MongoDB service B が同じポートを要求する。最初の要求がこのポートを取得します。
ただし、Ingress コントローラーが外部 IP を割り当てる場合、ポートのクラッシュは問題とはなりません。コントローラーが各サービスに固有のアドレスを割り当てるためです。
24.3. 固有の外部 IP を使用するようクラスターを設定する
クラウド以外のクラスターで、ingressIPNetworkCIDR はデフォルトで 172.29.0.0/16 に設定されています。クラスター環境がこのプライベート範囲をまだ使用していない場合は、このデフォルトを使用できます。ただし、異なる範囲を使用する必要がある場合は、ingress IP を割り当てる前に、/etc/origin/master/master-config.yaml ファイルで ingressIPNetworkCIDR を設定する必要があります。次に、マスターサービスを再起動します。
LoadBalancer タイプのサービスに割り当てられる外部 IP は常に ingressIPNetworkCIDR の範囲にあります。ingressIPNetworkCIDR が割り当てられた外部 IP がこの範囲内からなくなるように変更される場合、影響を受けるサービスには、新規の範囲と互換性のある新規の外部 IP が割り当てられます。
高可用性を使用している場合、この範囲は 255 IP アドレスより少なくなければなりません。
/etc/origin/master/master-config.yaml のサンプル
networkConfig: ingressIPNetworkCIDR: 172.29.0.0/16
24.3.1. サービスの Ingress IP の設定
Ingress IP を割り当てるには、以下を実行します。
loadBalancerIP設定で特定の IP を要求する LoadBalancer サービスの YAML ファイルを作成します。LoadBalancer 設定サンプル
apiVersion: v1 kind: Service metadata: name: egress-1 spec: ports: - name: db port: 3306 loadBalancerIP: 172.29.0.1 type: LoadBalancer selector: name: my-db-selectorPod に LoadBalancer サービスを作成します。
$ oc create -f loadbalancer.yaml
外部 IP のサービスを確認します。たとえば、
myserviceという名前のサービスを確認します。$ oc get svc myservice
LoadBalancer タイプのサービスに外部 IP が割り当てられている場合、出力には IP が表示されます。
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE myservice 172.30.74.106 172.29.0.1 3306/TCP 30s
24.4. 開発またはテスト目的での Ingress CIDR のルーティング
ingress CIDR のトラフィックをクラスターのノードに送信する静的ルートを追加します。以下は例になります。
# route add -net 172.29.0.0/16 gw 10.66.140.17 eth0
上記の例では、172.29.0.0/16 は ingressIPNetworkCIDR、10.66.140.17 はノード IP です。
24.4.1. サービス externalIP
クラスターの内部 IP アドレスに加えて、アプリケーション開発者はクラスターの外部にある IP アドレスを設定することができます。OpenShift Container Platform 管理者は、トラフィックがこの IP を持つノードに到達することを確認する必要があります。
externalIP は、master-config.yaml ファイルで設定される externalIPNetworkCIDRs 範囲から管理者によって選択される必要があります。master-config.yaml が変更される際に、マスターサービスは再起動される必要があります。
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
externalIPNetworkCIDR /etc/origin/master/master-config.yaml のサンプル
networkConfig: externalIPNetworkCIDR: 172.47.0.0/24
サービス externalIP 定義 (JSON)
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "my-service"
},
"spec": {
"selector": {
"app": "MyApp"
},
"ports": [
{
"name": "http",
"protocol": "TCP",
"port": 80,
"targetPort": 9376
}
],
"externalIPs" : [
"80.11.12.10" 1
]
}
}
- 1
- ポート が公開される外部 IP アドレスの一覧です (これは内部 IP アドレス一覧に追加される一覧です)。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.