Distributed Cloud コネクテッドのネットワーキング機能

このページでは、サブネットワーク、BGP ピアリング セッション、ロード バランシングなど、Google Distributed Cloud コネクテッドのネットワーキング機能について説明します。

このページの手順は、Distributed Cloud コネクテッド ラックにのみ適用されます。ロード バランシングは、Distributed Cloud コネクテッド ラックと Distributed Cloud コネクテッド サーバーの両方に適用されます。

IPv4/IPv6 デュアルスタック ネットワーキング

Distributed Cloud コネクテッドを使用すると、IPv4/IPv6 デュアルスタック ネットワーキングを使用するクラスタを作成できます。この機能を利用するには、デュアルスタック IPv4/IPv6 ネットワーキングを有効にして Distributed Cloud コネクテッドを注文する必要があります。Distributed Cloud コネクテッドの既存の IPv4 のみのデプロイを IPv4/IPv6 デュアルスタック ネットワーキングに再構成することはできません。デプロイで IPv4/IPv6 デュアルスタックネットワーキングがサポートされているかどうかを確認するには、マシンに関する情報を取得するの手順に沿って、dualstack_capable ラベルの戻り値を確認します。

デュアルスタック クラスタでは、IPv4 スタックはアイランド モードを使用し、IPv6 スタックはフラットモードを使用します。このため、同じサブネットワークに属する個別のノードと Pod の IPv6 アドレスを指定する必要があります。詳細については、 フラットモードとアイランド モードのネットワーク モデルをご覧ください。

たとえば、Distributed Cloud コネクテッド ノードと他のローカル マシンが同じレイヤ 2 ドメインに存在する場合は、クラスタの IPv6 CIDR ブロックを次のように指定できます。

ブロックの目的 ブロック範囲 ブロックサイズ
IPv6 サブネットワーク fd12::/56 2^72
Pod fd12::1:0/59 2^69
サービス fd12::2:0/59 2^69

この例では、次のことを前提としています。

  • ノード、Pod、Service の CIDR ブロックは、fd:12::/56 スーパーネットワークに属しています。
  • ノード、Pod、Service の IP アドレスは、指定された CIDR ブロックのサブネットワークです。
  • サブネットワークが重複していません。

IPv4/IPv6 デュアルスタック ネットワーキングでは、IPv4 BGP ピアリングにレイヤ 2 ロード バランシング、IPv6 ピアリングにレイヤ 3 ロード バランシングが必要です。詳細については、ロード バランシングをご覧ください。

IPv4/IPv6 デュアルスタック クラスタへのワークロードのデプロイの詳細については、以下をご覧ください。

Distributed Cloud Edge Network API を有効にする

Distributed Cloud の接続されたデプロイでネットワーキングを構成する前に、Distributed Cloud Edge Network API を有効にする必要があります。これを行うには、このセクションの手順を完了します。デフォルトでは、Distributed Cloud コネクテッド サーバーには、Distributed Cloud Edge Network API がすでに有効になっています。

コンソール

  1. コンソールで、 [Distributed Cloud Edge Network API] ページに移動します。 Google Cloud

    API の有効化

  2. [有効にする] をクリックします。

gcloud

次のコマンドを使用します。

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud コネクテッドでネットワーキングを構成する

このセクションでは、Distributed Cloud コネクテッド デプロイでネットワーキング コンポーネントを構成する方法について説明します。

Distributed Cloud コネクテッド サーバーには、次の制限が適用されます。

  • サブネットワークと ネットワークインターフェースのみを構成できます。
  • サブネットワークは VLAN ID のみをサポートします。CIDR ベースのサブネットワークはサポートされていません。

Distributed Cloud コネクテッドの一般的なネットワーク構成は、次の手順で構成されます。

  1. 省略可: 必要に応じて、ターゲット ゾーンのネットワーク構成を初期化します。

  2. ネットワークを作成します。

  3. ネットワーク内に 1 つ以上のサブネットワークを作成します。

  4. 対応する Interconnect アタッチメントを使用して、PE ルーターとのノースバウンド BGP ピアリング セッションを確立します。

  5. 対応するサブネットワークを使用して、ワークロードを実行する Pod とのサウスバウンド BGP ピアリング セッションを確立します。

  6. 省略可: 高可用性のためにループバック BGP ピアリング セッションを確立します。

  7. 構成をテストします。

  8. Pod をネットワークに接続します。

省略可: Distributed Cloud ゾーンのネットワーク構成を初期化する

次のような場合は、Distributed Cloud コネクテッド ゾーンのネットワーク構成を初期化する必要があります。

  • Distributed Cloud コネクテッド ハードウェアがオンプレミスにインストールされた直後。
  • 既存の Distributed Cloud コネクテッド デプロイで Distributed Cloud コネクテッド バージョン 1.3.0 以降にアップグレードしたが、Distributed Cloud Edge Network API のプライベート プレビューに参加していない。

ゾーンのネットワーク構成を初期化すると、default という名前のデフォルト ルーターと default という名前のデフォルト ネットワークが作成されます。また、対応する Interconnect アタッチメントを作成することで、Distributed Cloud コネクテッド ハードウェアの注文時にリクエストしたすべての Interconnect とピアリングするように default ルーターを構成します。この構成により、Distributed Cloud コネクテッド デプロイにローカル ネットワークへの基本的なアップリンク接続が提供されます。

ゾーンのネットワーク構成の初期化は、1 回限りの手順です。詳細な手順については、 ゾーンのネットワーク構成を初期化するをご覧ください。

ネットワークを作成する

新しいネットワークを作成するには、 ネットワークを作成するの手順に沿って操作します。 また、Distributed Cloud コネクテッド ノードがネットワークに接続できるように、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。

1 つ以上のサブネットワークを作成する

サブネットワークを作成するには、 サブネットワークを作成するの手順に沿って操作します。 ノードがネットワークにアクセスできるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。作成した各サブネットワークに対応する VLAN は、ゾーン内のすべてのノードで自動的に使用できます。

Distributed Cloud コネクテッド サーバーの場合、VLAN ID を使用してサブネットワークのみを構成できます。CIDR ベースのサブネットワークは対象外です。

ノースバウンド BGP ピアリング セッションを確立する

ネットワークとその対応するサブネットワークを作成すると、それらは Distributed Cloud コネクテッド ゾーンに対してローカルになります。アウトバウンド接続を有効にするには、ネットワークとピアリング エッジルーターの間に少なくとも 1 つのノースバウンド BGP ピアリング セッションを確立する必要があります。

ノースバウンド BGP ピアリング セッションを確立するには、次の操作を行います。

  1. ゾーンで使用可能な Interconnect を一覧表示 し、このピアリング セッションのターゲット Interconnect を選択します。

  2. 選択した Interconnect に 1 つ以上の Interconnect アタッチメントを作成します。Interconnect アタッチメントは、次のステップで作成するルーターを選択した Interconnect にリンクします。

  3. ルーターを作成します。このルーターは、前のステップで作成した Interconnect アタッチメントを使用して、Interconnect とネットワーク間のトラフィックをルーティングします。

  4. この手順で作成した Interconnect アタッチメントごとに、ルーターにインターフェースを追加します。各インターフェースで、Distributed Cloud コネクテッド ラック内の対応するトップオブラック（ToR）スイッチの IP アドレスを使用します。手順については、 ノースバウンド ピアリング セッションを確立するをご覧ください。

  5. ピアを追加します。前のステップでルーターに作成した インターフェースごと

サウスバウンド BGP ピアリング セッションを確立する

ローカル ネットワークからワークロードへのインバウンド接続を有効にするには、ピアリング エッジルーターと Pod が属するサブネットワークの間に 1 つ以上のサウスバウンド BGP ピアリング セッションを確立する必要があります。各サブネットワークのゲートウェイ IP アドレスは、Distributed Cloud コネクテッド ラック内の対応する ToR スイッチの IP アドレスです。

サウスバウンド BGP ピアリング セッションを確立するには、次の操作を行います。

  1. インバウンド接続でプロビジョニングするサブネットワークごとに、ターゲット ネットワークのルーターにインターフェースを追加します。手順については、 サウスバウンド ピアリング セッションを確立するをご覧ください。

  2. ピアを追加します 前のステップでルーターに作成したインターフェースごとに。

省略可: ループバック BGP ピアリング セッションを確立する

ワークロードとローカル ネットワーク間の高可用性接続を有効にするには、ターゲット Pod と Distributed Cloud コネクテッド ラック内の両方の ToR スイッチの間にループバック BGP ピアリング セッションを確立します。ループバック ピアリング セッションは、Pod に対して 2 つの独立したピアリング セッションを確立します。1 つは各 ToR スイッチとのセッションです。

ループバック BGP ピアリング セッションを確立するには、次の操作を行います。

  1. ターゲット ネットワークのルーターにループバック インターフェースを追加します。手順については、 ループバック ピアリング セッションを確立するをご覧ください。

  2. ピアを追加します。 ループバック インターフェース

設定をテストする

作成したネットワーク コンポーネントの構成をテストするには、次の操作を行います。

  1. ネットワークの運用ステータスを確認します。

  2. 各サブネットワークのプロビジョニング ステータスを確認します。

  3. Interconnect の運用ステータスを確認します。

  4. Interconnect アタッチメントの運用ステータスを確認します。

  5. ルーターの運用ステータスを確認します。

Pod をネットワークに接続する

Pod をネットワークに接続して高度なネットワーク機能を構成するには、 ネットワーク機能オペレータの手順に沿って操作します。

ロード バランシング

Distributed Cloud コネクテッドには、次のロード バランシング ソリューションが付属しています。

  • MetalLB を使用したレイヤ 2 ロード バランシング
  • Google Distributed Cloud ロードバランサを使用したレイヤ 3 ロード バランシング

Distributed Cloud コネクテッドに組み込まれているロード バランシング ソリューションでは、重複する Kubernetes Service 仮想 IP プレフィックスを使用できません。レイヤ 2 MetalLB ロード バランシングを使用する既存の Distributed Cloud コネクテッド デプロイがあり、Google Distributed Cloud ロードバランサを使用したレイヤ 3 ロード バランシングに切り替える場合は、レイヤ 2 MetalLB ロード バランシング構成で使用されているプレフィックスと重複しない Service 仮想 IP プレフィックスを使用する必要があります。

MetalLB を使用したレイヤ 2 ロード バランシング

Distributed Cloud には、レイヤ 2 モードの MetalLB に基づくネットワーク ロード バランシング ソリューションのバンドルが含まれます。 このソリューションを使用すると、仮想 IP アドレス（VIP）を使用して、Distributed Cloud ゾーンで実行されるサービスを外部に公開できます。

  1. ネットワーク管理者は、ネットワーク トポロジを計画し、Distributed Cloud の注文時に必要な仮想 IPv4 アドレスと IPv6 アドレスのサブネットワークを指定します。Google は、配信前に Distributed Cloud ハードウェアを適切に構成します。 次の点に注意してください。
    • この VIP サブネットワークは、Distributed Cloud ゾーン内で実行されるすべての Kubernetes クラスタ間で共有されます。
    • リクエストされた VIP サブネットワークのルートは、Distributed Cloud ゾーンとローカル ネットワーク間の BGP セッションを介してアドバタイズされます。
    • サブネットワーク内の最初（ネットワーク ID）、2 番目（デフォルト ゲートウェイ）、最後（ブロードキャスト アドレス）のアドレスは、コア システム 機能用に予約されています。これらのアドレスを MetalLB 構成のアドレスプールに割り当てないでください。
    • 各クラスタは、構成された VIP サブネットワーク内の個別の VIP 範囲を使用する必要があります。
  2. Distributed Cloud ゾーンにクラスタを作成するときに、クラスタ管理者は CIDR 表記を使用して Pod と ClusterIP Service のアドレスプールを指定します。ネットワーク管理者は、適切な LoadBalancer VIP サブネットワークをクラスタ管理者に提供します。

  3. クラスタが作成されたら、クラスタ管理者は対応する VIP プールを構成します。クラスタの作成時に --external-lb-address-pools フラグを使用して VIP プールを指定する必要があります。このフラグは、次の形式の YAML または JSON ペイロードを含むファイルを受け入れます。

     addressPools:
 - name: foo
   addresses:
   - 10.2.0.212-10.2.0.221
   - fd12::4:101-fd12::4:110
   avoid_buggy_ips: true
   manual_assign: false

 - name: bar
   addresses:
   - 10.2.0.202-10.2.0.203
   - fd12::4:101-fd12::4:102
   avoid_buggy_ips: true
   manual_assign: false

    VIP アドレスプールを指定するには、ペイロードに次の情報を指定します。

    • name: この VIP アドレスプールを一意に識別する説明的な名前。
    • addresses: このアドレスプールに含める IPv4 アドレスと IPv6 アドレス、アドレス範囲、サブネットワークのリスト。
    • avoid_buggy_ips: .0 または .255 で終わる IP アドレスを除外します。
    • manual_assign: MetalLB コントローラが自動的に割り当てるのではなく、 ターゲット LoadBalancer Service の構成でこのプールからアドレスを手動で割り当てることができます。

    VIP アドレスプールの構成の詳細については、MetalLB ドキュメントの アドレスプールを指定する をご覧ください。

  4. クラスタ管理者は、適切な Kubernetes LoadBalancer Service を作成します。

単一ノードプールの Distributed Cloud ノードは共通のレイヤ 2 ドメインを共有するため、MetalLB ロードバランサ ノードでもあります。

Google Distributed Cloud ロードバランサを使用したレイヤ 3 ロード バランシング

Distributed Cloud コネクテッドには、BGP スピーカーとして構成されたレイヤ 3 モードの Google Distributed Cloud バンドル ロードバランサに基づくネットワーク ロード バランシング ソリューションのバンドルが含まれます。このソリューションを使用すると、VIP を使用して、Distributed Cloud コネクテッド ゾーンで実行されるサービスを外部に公開できます。

対応する LoadBalancer Service の VIP 範囲は、metallb-config ConfigMap を使用して指定できます。次に例を示します。

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

上記の例では、構成した各 LoadBalancer Service に、ConfigMap で指定された 10.100.10.66/27 範囲の仮想 IP アドレスが自動的に割り当てられます。これらの VIP は、BGPPeer リソースを介して、ToR スイッチで構成された Distributed Cloud BGP スピーカーによってノースバウンドにアドバタイズされます。

Distributed Cloud クラスタを作成すると、そのクラスタに次のリソースが自動的に作成されます。

  • BGP ロードバランサをインスタンス化する BGPLoadBalancer リソース。
  • BGP スピーカーに使用するローカル フローティング IP アドレスを指定する NetworkGatewayGroup リソース。これらの IP アドレスは、クラスタに割り当てられた Kubernetes ノード サブネットワークの最後の 2 つの IP アドレスに自動的に設定されます。

これらのリソースを使用すると、対応する BGPPeer リソースを構成して、BGP セッションを Distributed Cloud ToR スイッチに設定できます。これを行うには、必要な自律システム番号（ASN）と ToR スイッチのループバック ピア IP アドレスが必要です。これらの IP アドレスは、デフォルトのネットワーク リソース上の ToR スイッチ BGP セッション エンドポイントとして機能します。network パラメータの値は pod-network である必要があります。

2 つの BGPPeer リソースの例を次に示します。

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

IPv6 ピアリングのレイヤ 3 BGP ロード バランシングの自動化を構成する

IPv4/IPv6 デュアルスタック ネットワーキング クラスタで IPv6 ピアリングの使用を開始する前に、Google サポートに連絡して、Distributed Cloud コネクテッド デプロイで Google Distributed Cloud ロードバランサの自動化を有効にする必要があります。

レイヤ 3 LoadBalancer Service を作成する

Distributed Cloud コネクテッド デプロイで Google Distributed Cloud ロードバランサの自動化を有効にしたら、レイヤ 3 LoadBalancer Service をインスタンス化します。次に例を示します。

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

BGP セッションとロード バランシング サービスのステータスを確認する

BGP セッションのステータスを確認するには、次のコマンドを使用します。

kubectl get bgpsessions.networking.gke.io -A

このコマンドは、次の例のような出力を返します。

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

LoadBalancer Service が BGP スピーカーによってアドバタイズされていることを確認するには、次のコマンドを使用します。

kubectl get bgpadvertisedroutes.networking.gke.io -A

このコマンドは、次の例のような出力を返します。

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

Distributed Cloud イングレス

Distributed Cloud コネクテッドは、ロード バランシングに加えて、Kubernetes Ingress リソースもサポートしています。Kubernetes Ingress リソースは、Distributed Cloud コネクテッド クラスタで実行される Kubernetes Service への HTTP(S) トラフィックのフローを制御します。次の例は、一般的な Ingress リソースを示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

構成すると、ネットワーク トラフィックは istio-ingress Service を通過します。この Service には、デフォルトで MetalLB 構成で指定された VIP プールからランダムな IP アドレスが割り当てられます。istio-ingress Service 定義の loadBalancerIP フィールドを使用して、MetalLB 構成から特定の IP アドレスまたは仮想 IP アドレスを選択できます。次に例を示します。

apiVersion: v1
kind: service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

この機能は、Distributed Cloud コネクテッド サーバーでは使用できません。

デフォルトの Distributed Cloud Ingress リソースを無効にする

デフォルトでは、Distributed Cloud コネクテッド クラスタを作成すると、Distributed Cloud はクラスタの istio-ingress Service を自動的に構成します。istio-ingress Service なしで Distributed Cloud コネクテッド クラスタを作成することもできます。手順は次のとおりです。

gcloud

  1. 次の内容で SystemsAddonConfig.yaml という名前の YAML 構成ファイルを作成します。

    systemAddonsConfig:
 ingress:
   disabled: true

  2. クラスタ作成コマンドで --system-addons-config フラグを使用して、SystemsAddonConfig.yaml ファイルを渡します。この機能を使用するには、gcloud alpha バージョンを使用する必要があります。次に例を示します。

    gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml

    Distributed Cloud クラスタの作成の詳細については、 クラスタを作成するをご覧ください。

API

  1. クラスタ作成リクエストの JSON ペイロードに次の JSON コンテンツを追加します。

    "systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}

  2. クラスタを作成する の説明に沿って、クラスタ作成リクエストを送信します。

NodePort Service

Distributed Cloud コネクテッドは、任意のポート番号で Distributed Cloud ノードの接続をリッスンする Kubernetes NodePort Service をサポートしています。NodePort Service は、TCP、UDP、SCTP プロトコルをサポートしています。次に例を示します。

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

SCTP のサポート

Distributed Cloud コネクテッドは、内部ネットワーキングと外部ネットワーキングの両方で、プライマリ ネットワーク インターフェースの Stream Control Transmission Protocol（SCTP）をサポートしています。SCTP のサポートには、NodePort、LoadBalancer、ClusterIP の Service タイプが含まれます。Pod は SCTP を使用して、他の Pod や外部リソースと通信できます。次の例は、SCTP を使用して IPERF を ClusterIP Service として構成する方法を示しています。

apiVersion: v1
kind: pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

この機能は、Distributed Cloud コネクテッド サーバーでは使用できません。

SCTP カーネル モジュール

バージョン 1.5.0 以降では、Distributed Cloud コネクテッドは sctp Edge OS カーネル モジュールをロード可能として構成します。これにより、独自の SCTP プロトコル スタックをカーネル ユーザー空間にロードできます。

また、Distributed Cloud コネクテッドは、デフォルトで次のモジュールをカーネルにロードします。

モジュール名 構成名
fou CONFIG_NET_FOU
nf_conntrack_proto_gre CONFIG_NF_CT_PROTO_GRE
nf_conntrack_proto_sctp CONFIG_NF_CT_PROTO_SCTP
inotify CONFIG_INOTIFY_USER
xt_redirect CONFIG_NETFILTER_XT_TARGET_REDIRECT
xt_u32 CONFIG_NETFILTER_XT_MATCH_U32
xt_multiport CONFIG_NETFILTER_XT_MATCH_MULTIPORT
xt_statistic CONFIG_NETFILTER_XT_MATCH_STATISTIC
xt_owner CONFIG_NETFILTER_XT_MATCH_OWNER
xt_conntrack CONFIG_NETFILTER_XT_MATCH_CONNTRACK
xt_mark CONFIG_NETFILTER_XT_MARK
ip6table_mangle CONFIG_IP6_NF_MANGLE
ip6_tables CONFIG_IP6_NF_IPTABLES
ip6table_filter CONFIG_IP6_NF_FILTER
ip6t_reject CONFIG_IP6_NF_TARGET_REJECT
iptable_mangle CONFIG_IP_NF_MANGLE
ip_tables CONFIG_IP_NF_IPTABLES
iptable_filter CONFIG_IP_NF_FILTER

ClusterDNS リソース

Distributed Cloud コネクテッドは、spec.domains セクションを使用して特定のドメインのアップストリーム ネームサーバーを構成するための Google Distributed Cloud ClusterDNS リソースをサポートしています。このリソースの構成の詳細については、spec.domains をご覧ください。

この機能は、Distributed Cloud コネクテッド サーバーでは使用できません。

次のステップ