ネットワーキング

GKE On-Prem は、Service や Ingress のような Kubernetes のネットワーキングのコンセプトを使用します。このドキュメントでは、すぐに使用可能な GKE On-Prem ネットワーキングの構成方法について説明します。

クラスタ サービスのオペレーションとアイランド モード

GKE On-Prem はアイランド モード構成を使用します。このモードでは、Pod はクラスタ内で相互に直接通信できますが、クラスタの外部から Pod へはアクセスできません。この構成により、外部ネットワークに接続されていないネットワーク内に「アイランド」が形成されます。クラスタは BGP を使用して（Calco CNI プラグインを介して）クラスタノード全体に完全なノード間メッシュを形成し、Pod がクラスタ内の他の Pod に直接アクセスできるようにします。

Pod からクラスタ外のターゲットに向かう下り（外向き）トラフィックは、すべてノード IP によって NAT 処理されます。GKE On-Prem は、クラスタ内にデプロイされた ClusterIP Service の Ingress オブジェクト ルールを処理する Envoy ベースの Ingress コントローラを搭載した L7 ロードバランサを備えています。Ingress コントローラ自体は、クラスタ内の NodePort Service として公開されます。

Ingress NodePort Service には、L3/L4 F5 ロードバランサを介してアクセスできます。インストールにより、ロードバランサで仮想 IP アドレス（VIP）がポート 80 とポート 443 で構成されます。VIP は Ingress コントローラの NodePort Service のポートを参照します。これは外部クライアントがクラスタ内の Service にアクセスする方法です。

ユーザー クラスタは、loadBalancerIP フィールドが Service の仕様で構成されている限り、LoadBalancer のタイプの Service を実行できます。loadBalancerIP フィールドに、使用する VIP を指定する必要があります。これは、Service の NodePorts を指す F5 で構成されます。

F5 ロードバランサを使用する代わりに、手動負荷分散モードを有効にすることもできます。手動負荷分散を使用する場合、タイプ LoadBalancer の Service は実行できません。代わりに、タイプ NodePort の Service を作成し、それらをバックエンドとして使用するようにロードバランサを手動で構成できます。また、Ingress オブジェクトを使用して Service を外部クライアントに公開することもできます。

注: "externalTrafficPolicy": "Local" は現在、F5 BIG-IP 統合ではサポートされていません。

ネットワーキング アーキテクチャ

^{図: GKE On-Prem ネットワーキング}

ノード IP アドレス

DHCP またはノードの静的に割り当てられた IP アドレス（あるいは、仮想マシンまたは VM と呼ばれる）。データセンター内部でルーティング可能であることが必要です。静的 IP を手動で割り当てることができます。

Pod CIDR ブロック

クラスタのすべての Pod にはルーティングできない CIDR ブロック。この範囲から、より小さい /24 範囲がノード単位で割り当てられます。N 個のノードを持つクラスタが必要な場合は、N 個の /24 ブロックをサポートするうえで十分な大きさが、このブロックにあることを確認します。

Service CIDR ブロック

アイランド モードでは、Pod CIDR ブロックの場合と同様に、クラスタ内でのみ使用されます。ノード、VIP、Pod の CIDR ブロックと重複しない非公開 CIDR ブロック。クラスタ間で同じブロックを共有できます。ブロックのサイズによってサービスの数が決まります。Ingress サービスには 1 つの Service IP が必要です。クラスタ DNS などの Kubernetes サービスには 10 個以上の IP が必要です。

Service VIP

Service を公開するときに、L4 Ingress の F5 に対して構成する N 個のルーティング可能な IP アドレス。これらの VIP は、LoadBalancer タイプの Service を作成するときに生成される loadBalancerIP 値と同じです。

コントロール プレーン VIP

Kubernetes API サーバーの F5 ロードバランサに対して構成するルーティング可能な IP アドレス。

Ingress VIP

各ノードで実行する Envoy プロキシとの関連で、L7 Ingress の F5 ロードバランサに対して構成するルーティング可能な IP アドレス。

network 構成

これらのパラメータは、クラスタ構成ファイルの network フィールドにキャプチャされます。

以下に、ほとんどのパラメータが指定された network フィールドの例を示します。

# Example of a network section with static node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: static
    addressblock:
      hostconfig:
        dns: 8.8.8.8
        tod: 192.138.210.214
      blocks:
        - netmask: 255.255.252.0
          gateway: 10.116.232.0
          ips:
            - ip: 10.116.232.23
              hostname: host1.enterprise.net
            - ip: 10.116.232.65
              hostname: host2.enterprise.net
            - ip: 10.116.232.66
              hostname: host3.enterprise.net
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: # encoded value
      password: # encoded value
      partition: admin-partition

network フィールドは 3 つのサブフィールド（clusterip、nodeip、loadbalancer）から成り、クラスタ用に異なるネットワーク設定を構成します。nodeip.blocks サブフィールドは省略可能です。nodeip.mode が静的に設定されている場合、このフィールドを指定する必要があります。

ノードが DHCP を介して IP を取得するように構成されている場合は、network フィールドを次のように構成します。

# Example of a network section using DHCP for node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: dhcp
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: admin
      password: secret
      partition: user-partition

例: URL 経由でウェブ アプリケーションにアクセスする

ゲストブック ウェブ アプリケーションが、frontend という名前の Deployment としてクラスタで実行されているとします。URL www.guestbook.com を使用してアプリケーションに接続することを必要としています。クラスタで実行されている Deployment に URL をマッピングする方法が必要です。これには Kubernetes Ingress オブジェクトを使用します。

まず、クラスタの既存の Ingress VIP を指定する *.guestbook.com のワイルドカード DNS エントリを作成します。

*.guestbook.com    A   [INGRESS_VIP]

続いて、フロントエンド Deployment の Service を作成する必要があります。kubectl expose を実行すると、Deployment の Pod を論理的にグループ化する Service が作成され、クラスタ内の共通の IP アドレスが指定されます。

kubectl expose deployment frontend

これで、次のような ClusterIP タイプの Service が作成されます。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: ClusterIP

URL www.guestbook.com を先ほど作成したフロントエンド Service にマッピングする必要があります。以下の Ingress を適用すると、次のようにマッピングが作成されます。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  labels:
    app: guestbook
spec:
  rules:
    - host: www.guestbook.com
      http:
        paths:
          - backend:
              serviceName: frontend   # name of the frontend Service
              servicePort: 80

次に www.guestbook.com にアクセスすると、ブラウザでウェブ アプリケーションが開きます。

この仕組みは次のとおりです。

• ワイルドカード DNS エントリを作成したため、URL にアクセスするとクラスタの Ingress VIP にアクセスすることになります。
• クラスタはホスト名に基づいて適切な Ingress オブジェクトを探します。この場合は www.guestbook.com です。
• トラフィックはフロントエンド Pod にポート転送されます。

例: IP アドレス経由でウェブ アプリケーションにアクセスする

アプリケーションがウェブ アプリケーションでない場合や、ネットワークの制約がある場合は、Service 専用の VIP を作成することをおすすめします。これは、LoadBalancer タイプの Kubernetes Service を使用して行うことができます。

以下の Service は、guestbook アプリケーション専用の VIP を作成します。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]

この Service を適用すると、F5 コンソールに VIP が表示され、コンソールの [Pools] メニューにノードの IP アドレスが表示されます。IP アドレスにアクセスすると、アプリケーションが読み込まれます。