Fitur jaringan Distributed Cloud terhubung

Halaman ini menjelaskan fitur jaringan Google Distributed Cloud Connected, termasuk subnetwork, sesi peering BGP, dan load balancing.

Prosedur di halaman ini hanya berlaku untuk rak yang terhubung ke Distributed Cloud, kecuali load balancing, yang berlaku untuk rak yang terhubung ke Distributed Cloud dan server yang terhubung ke Distributed Cloud.

Jejaring stack ganda IPv4/IPv6

Distributed Cloud Connected memungkinkan Anda membuat cluster yang menggunakan jaringan stack ganda IPv4/IPv6. Untuk memanfaatkan fungsi ini, Anda harus memesan Distributed Cloud yang terhubung dengan jaringan IPv4/IPv6 dual-stack yang diaktifkan. Anda tidak dapat mengonfigurasi ulang deployment Distributed Cloud yang ada dan hanya IPv4 yang terhubung ke jaringan dual-stack IPv4/IPv6. Untuk memeriksa apakah deployment Anda mendukung jaringan stack ganda IPv4/IPv6, ikuti petunjuk di Mendapatkan informasi tentang mesin dan periksa nilai label dualstack_capable yang ditampilkan.

Dalam cluster stack ganda, stack IPv4 menggunakan mode pulau, sedangkan stack IPv6 menggunakan mode datar. Oleh karena itu, Anda harus menentukan alamat IPv6 node dan pod individual yang berbeda-beda yang termasuk dalam subnetwork yang sama. Untuk mengetahui informasi selengkapnya, lihat Model jaringan mode datar vs. mode pulau.

Misalnya, jika node yang terhubung ke Distributed Cloud dan mesin lokal lainnya berada di domain Layer 2 yang sama, Anda dapat menentukan blok CIDR IPv6 untuk cluster sebagai berikut:

Tujuan pemblokiran Rentang blok Ukuran blok
Subnetwork IPv6 fd12::/56 2^72
Pod fd12::1:0/59 2^69
Layanan fd12::2:0/59 2^69

Contoh ini mengasumsikan hal berikut:

  • Blok CIDR node, pod, dan layanan termasuk dalam superjaringan fd:12::/56.
  • Alamat IP node, pod, dan layanan adalah subnetwork dari blok CIDR yang ditentukan.
  • Tidak ada subnetwork yang tumpang-tindih.

Jejaring stack ganda IPv4/IPv6 memerlukan load balancing Lapisan 2 untuk peering BGP IPv4 dan load balancing Lapisan 3 untuk peering IPv6. Untuk mengetahui informasi selengkapnya, lihat Load balancing.

Untuk mengetahui informasi selengkapnya tentang men-deploy workload di cluster stack ganda IPv4/IPv6, lihat bagian berikut:

Aktifkan Distributed Cloud Edge Network API

Sebelum dapat mengonfigurasi jaringan pada deployment Distributed Cloud yang terhubung, Anda harus mengaktifkan Distributed Cloud Edge Network API. Untuk melakukannya, selesaikan langkah-langkah di bagian ini. Secara default, server Distributed Cloud terhubung dikirimkan dengan Distributed Cloud Edge Network API yang sudah diaktifkan.

Konsol

  1. Di konsol Google Cloud , buka halaman Distributed Cloud Edge Network API.

    Mengaktifkan API

  2. Klik Enable.

gcloud

Gunakan perintah berikut:

gcloud services enable edgenetwork.googleapis.com

Mengonfigurasi jaringan di Distributed Cloud terhubung

Bagian ini menjelaskan cara mengonfigurasi komponen jaringan pada deployment yang terhubung ke Distributed Cloud Anda.

Batasan berikut berlaku untuk server yang terhubung ke Distributed Cloud:

  • Anda hanya dapat mengonfigurasi subnetwork, dan
  • Subnetwork hanya mendukung ID VLAN; subnetwork berbasis CIDR tidak didukung.

Konfigurasi jaringan umum untuk Distributed Cloud yang terhubung terdiri dari langkah-langkah berikut:

  1. Opsional: Lakukan inisialisasi konfigurasi jaringan zona target, jika perlu.

  2. Membuat jaringan.

  3. Buat satu atau beberapa subnetwork dalam jaringan.

  4. Buat sesi peering BGP northbound dengan router PE menggunakan lampiran Interconnect yang sesuai.

  5. Buat sesi peering BGP southbound dengan pod yang menjalankan beban kerja Anda menggunakan subnetwork yang sesuai.

  6. Opsional: Buat sesi peering BGP loopback untuk ketersediaan tinggi.

  7. Uji konfigurasi Anda.

  8. Hubungkan pod Anda ke jaringan.

Opsional: Lakukan inisialisasi konfigurasi jaringan zona Distributed Cloud

Anda harus menginisialisasi konfigurasi jaringan zona terhubung Distributed Cloud dalam kasus berikut:

  • Segera setelah hardware yang terhubung ke Distributed Cloud Anda dipasang di lokasi Anda.
  • Anda mengupgrade ke Distributed Cloud terhubung versi 1.3.0 atau yang lebih baru pada deployment Distributed Cloud terhubung yang ada, tetapi tidak berpartisipasi dalam pratinjau pribadi Distributed Cloud Edge Network API.

Menginisialisasi konfigurasi jaringan zona akan membuat router default bernama default dan jaringan default bernama default. Selain itu, router default dikonfigurasi untuk melakukan peering dengan semua interkoneksi yang Anda minta saat Anda memesan hardware yang terhubung ke Distributed Cloud dengan membuat lampiran interkoneksi yang sesuai. Konfigurasi ini menyediakan konektivitas uplink dasar untuk deployment yang terhubung ke Distributed Cloud ke jaringan lokal Anda.

Menginisialisasi konfigurasi jaringan zona adalah prosedur sekali saja. Untuk petunjuk lengkap, lihat Melakukan inisialisasi konfigurasi jaringan zona.

Membuat jaringan

Untuk membuat jaringan baru, ikuti petunjuk di Membuat jaringan. Anda juga harus membuat setidaknya satu subnetwork dalam jaringan untuk mengizinkan node yang terhubung ke Distributed Cloud terhubung ke jaringan.

Buat satu atau beberapa subnetwork

Untuk membuat subnetwork, ikuti petunjuk dalam Membuat subnetwork. Anda harus membuat setidaknya satu subnetwork di jaringan untuk mengizinkan node mengakses jaringan. VLAN yang sesuai dengan setiap subnetwork yang Anda buat akan otomatis tersedia untuk semua node di zona.

Untuk server yang terhubung ke Distributed Cloud, Anda hanya dapat mengonfigurasi subnet menggunakan ID VLAN. Subnetwork berbasis CIDR tidak didukung.

Membuat sesi peering BGP ke utara

Saat Anda membuat jaringan dan sub-jaringannya yang sesuai, keduanya bersifat lokal untuk zona yang terhubung dengan Distributed Cloud. Untuk mengaktifkan konektivitas keluar, Anda harus membuat setidaknya satu sesi peering BGP ke utara antara jaringan dan router edge peering Anda.

Untuk membuat sesi peering BGP northbound, lakukan hal berikut:

  1. Buat daftar interkoneksi yang tersedia di zona Anda lalu pilih interkoneksi target untuk sesi peering ini.

  2. Buat satu atau beberapa lampiran interkoneksi pada interkoneksi yang dipilih. Lampiran Interconnect menautkan router yang Anda buat pada langkah berikutnya dengan interconnect yang dipilih.

  3. Buat router. Router ini merutekan traffic antara interkoneksi dan jaringan Anda menggunakan lampiran interkoneksi yang Anda buat pada langkah sebelumnya.

  4. Tambahkan antarmuka ke router untuk setiap lampiran interconnect yang Anda buat sebelumnya dalam prosedur ini. Untuk setiap antarmuka, gunakan alamat IP switch top-of-rack (ToR) yang sesuai di rak yang terhubung ke Distributed Cloud Anda. Untuk mengetahui petunjuknya, lihat Membangun sesi peering utara.

  5. Tambahkan peer untuk setiap antarmuka yang Anda buat di router pada langkah sebelumnya.

Membuat sesi peering BGP southbound

Untuk mengaktifkan konektivitas inbound ke workload dari jaringan lokal, Anda harus membuat satu atau beberapa sesi peering BGP southbound antara router edge peering dan subnetwork tempat pod Anda berada. Alamat IP gateway untuk setiap subnetwork adalah alamat IP switch ToR yang sesuai di rack yang terhubung ke Distributed Cloud Anda.

Untuk membuat sesi peering BGP southbound, lakukan hal berikut:

  1. Tambahkan antarmuka ke router di jaringan target untuk setiap subnetwork yang ingin Anda sediakan dengan konektivitas masuk. Untuk mengetahui petunjuknya, lihat Membuat sesi peering southbound.

  2. Tambahkan peer untuk setiap antarmuka yang Anda buat di router pada langkah sebelumnya.

Opsional: Buat sesi peering BGP loopback

Untuk mengaktifkan konektivitas dengan ketersediaan tinggi antara beban kerja dan jaringan lokal, Anda dapat membuat sesi peering BGP loopback antara pod target dan kedua switch ToR di rak yang terhubung ke Distributed Cloud. Sesi peering loopback membuat dua sesi peering independen untuk pod, satu dengan setiap switch ToR.

Untuk membuat sesi peering BGP loopback, lakukan hal berikut:

  1. Tambahkan antarmuka loopback ke router di jaringan target. Untuk mengetahui petunjuknya, lihat Membuat sesi peering loopback.

  2. Tambahkan peer untuk antarmuka loopback.

Menguji konfigurasi Anda

Untuk menguji konfigurasi komponen jaringan yang Anda buat, lakukan langkah-langkah berikut:

  1. Periksa status operasional jaringan.

  2. Periksa status penyediaan setiap subnetwork.

  3. Periksa status operasional interkoneksi.

  4. Periksa status operasional lampiran interkoneksi.

  5. Periksa status operasional router.

Hubungkan pod ke jaringan

Untuk menghubungkan pod ke jaringan dan mengonfigurasi fungsi jaringan lanjutan, ikuti petunjuk di operator Fungsi Jaringan.

Load balancing

Distributed Cloud connected dilengkapi dengan solusi load balancing berikut:

  • Load balancing lapisan 2 dengan MetalLB
  • Load balancing lapisan 3 dengan load balancer Google Distributed Cloud

Solusi load balancing yang dibuat ke dalam Distributed Cloud yang terhubung tidak dapat menggunakan awalan IP virtual layanan Kubernetes yang tumpang-tindih. Jika Anda memiliki deployment terhubung Distributed Cloud yang sudah ada dan menggunakan load balancing MetalLB Lapisan 2, dan Anda ingin beralih ke load balancing Lapisan 3 dengan load balancer Google Distributed Cloud, Anda harus menggunakan awalan IP virtual layanan yang tidak tumpang-tindih dengan awalan yang digunakan oleh konfigurasi load balancing MetalLB Lapisan 2.

Load balancing lapisan 2 dengan MetalLB

Distributed Cloud dilengkapi dengan solusi load balancing jaringan yang dibundel berdasarkan MetalLB dalam mode Layer 2. Anda dapat menggunakan solusi ini untuk mengekspos layanan yang berjalan di zona Distributed Cloud Anda ke dunia luar menggunakan alamat IP virtual (VIP) sebagai berikut:

  1. Administrator jaringan Anda merencanakan topologi jaringan dan menentukan subnet alamat IPv4 dan IPv6 virtual yang diperlukan saat memesan Distributed Cloud. Google mengonfigurasi hardware Distributed Cloud Anda sesuai dengan pesanan sebelum pengiriman. Perhatikan hal-hal berikut:
    • Subnetwork VIP ini dibagikan di antara semua cluster Kubernetes yang berjalan dalam zona Distributed Cloud Anda.
    • Rute untuk subnetwork VIP yang diminta diiklankan melalui sesi BGP antara zona Distributed Cloud dan jaringan lokal Anda.
    • Alamat pertama (ID jaringan), kedua (gateway default), dan terakhir (alamat siaran) di subnetwork dicadangkan untuk fungsi sistem inti. Jangan tetapkan alamat tersebut ke kumpulan alamat konfigurasi MetalLB Anda.
    • Setiap cluster harus menggunakan rentang VIP terpisah yang berada dalam subnetwork VIP yang dikonfigurasi.
  2. Saat Anda membuat cluster di zona Distributed Cloud, administrator cluster Anda menentukan kumpulan alamat layanan ClusterIP dan pod menggunakan notasi CIDR. Administrator jaringan Anda memberikan subnetwork VIP LoadBalancer yang sesuai kepada administrator cluster Anda.

  3. Setelah cluster dibuat, administrator cluster akan mengonfigurasi kumpulan VIP yang sesuai. Anda harus menentukan kumpulan VIP menggunakan flag --external-lb-address-pools saat membuat cluster. Flag menerima file dengan payload YAML atau JSON dalam format berikut:

     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

    Untuk menentukan kumpulan alamat VIP, berikan informasi berikut dalam payload:

    • name: nama deskriptif yang secara unik mengidentifikasi kumpulan alamat VIP ini.
    • addresses: daftar alamat IPv4 dan IPv6, rentang alamat, dan subnetwork yang akan disertakan dalam kumpulan alamat ini.
    • avoid_buggy_ips: Mengecualikan alamat IP yang berakhiran .0 atau .255.
    • manual_assign: Memungkinkan Anda menetapkan alamat secara manual dari kumpulan ini dalam konfigurasi layanan LoadBalancer target, bukan meminta pengontrol MetalLB menetapkannya secara otomatis.

    Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi kumpulan alamat VIP, lihat artikel Menentukan kumpulan alamat dalam dokumentasi MetalLB.

  4. Administrator cluster membuat layanan Kubernetes LoadBalancer yang sesuai.

Node Distributed Cloud dalam satu node pool berbagi domain Layer 2 yang sama dan oleh karena itu juga merupakan node load balancer MetalLB.

Load balancing lapisan 3 dengan load balancer Google Distributed Cloud

Distributed Cloud connected dilengkapi dengan solusi load balancing jaringan yang dibundel berdasarkan load balancer yang dibundel Google Distributed Cloud dalam mode Lapisan 3 yang dikonfigurasi sebagai speaker BGP. Anda dapat menggunakan solusi ini untuk mengekspos layanan yang berjalan di zona yang terhubung ke Distributed Cloud Anda ke dunia luar menggunakan VIP.

Anda dapat menentukan rentang VIP untuk layanan LoadBalancer yang sesuai dengan menggunakan ConfigMap metallb-config. Contoh:

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

Pada contoh sebelumnya, setiap layanan LoadBalancer yang Anda konfigurasi akan otomatis diberi alamat IP virtual dari rentang 10.100.10.66/27 yang ditentukan dalam ConfigMap. VIP ini kemudian diiklankan ke arah utara oleh speaker BGP Distributed Cloud yang dikonfigurasi di switch ToR melalui resource BGPPeer.

Saat Anda membuat cluster Distributed Cloud, resource berikut akan dibuat secara otomatis di cluster tersebut:

  • Resource BGPLoadBalancer yang membuat instance load balancer BGP.
  • Resource NetworkGatewayGroup yang menentukan alamat IP mengambang lokal yang akan digunakan untuk speaker BGP. Alamat IP ini otomatis ditetapkan ke dua alamat IP terakhir dari subnetwork node Kubernetes yang ditetapkan ke cluster.

Setelah resource tersebut tersedia, Anda dapat menyiapkan sesi BGP ke switch ToR Distributed Cloud dengan mengonfigurasi resource BGPPeer yang sesuai. Untuk melakukannya, Anda harus memiliki nomor sistem otonom (ASN) yang diperlukan dan alamat IP peer loopback untuk switch ToR. Alamat IP ini berfungsi sebagai endpoint sesi BGP switch ToR pada resource jaringan default. Perlu diingat bahwa nilai parameter network harus pod-network.

Berikut adalah contoh dua resource 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

Mengonfigurasi otomatisasi load balancing BGP Lapisan 3 untuk peering IPv6

Sebelum dapat mulai menggunakan peering IPv6 di cluster jaringan stack ganda IPv4/IPv6, Anda harus menghubungi Dukungan Google untuk mengaktifkan otomatisasi load balancer Google Distributed Cloud di deployment Distributed Cloud yang terhubung.

Buat layanan LoadBalancer Layer 3

Setelah mengaktifkan otomatisasi load balancer Google Distributed Cloud di deployment yang terhubung ke Distributed Cloud, buat instance layanan LoadBalancer Lapisan 3. Contoh:

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

Periksa status sesi BGP dan layanan load balancing

Untuk memeriksa status sesi BGP, gunakan perintah berikut:

kubectl get bgpsessions.networking.gke.io -A

Perintah ini menampilkan output yang mirip dengan contoh berikut:

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

Untuk memverifikasi bahwa layanan LoadBalancer Anda diiklankan oleh speaker BGP, gunakan perintah berikut:

kubectl get bgpadvertisedroutes.networking.gke.io -A

Perintah ini menampilkan output yang mirip dengan contoh berikut:

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

Traffic masuk Distributed Cloud

Selain load balancing, Distributed Cloud Connected juga mendukung resource Ingress Kubernetes. Resource Ingress Kubernetes mengontrol alur traffic HTTP(S) ke layanan Kubernetes yang berjalan di cluster yang terhubung ke Distributed Cloud Anda. Contoh berikut mengilustrasikan resource Ingress umum:

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

Jika dikonfigurasi, traffic jaringan akan mengalir melalui layanan istio-ingress, yang secara default diberi alamat IP acak dari kumpulan VIP yang ditentukan dalam konfigurasi MetalLB Anda. Anda dapat memilih alamat IP tertentu atau alamat IP virtual dari konfigurasi MetalLB menggunakan kolom loadBalancerIP dalam definisi layanan istio-ingress. Contoh:

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

Fungsi ini tidak tersedia di server yang terhubung ke Distributed Cloud.

Menonaktifkan resource Distributed Cloud Ingress default

Secara default, saat Anda membuat cluster yang terhubung ke Distributed Cloud, Distributed Cloud akan otomatis mengonfigurasi layanan istio-ingress untuk cluster. Anda memiliki opsi untuk membuat cluster yang terhubung ke Distributed Cloud tanpa layanan istio-ingress. Caranya, selesaikan langkah-langkah berikut:

gcloud

  1. Buat file konfigurasi YAML bernama SystemsAddonConfig.yaml dengan isi berikut:

    systemAddonsConfig:
 ingress:
   disabled: true

  2. Teruskan file SystemsAddonConfig.yaml menggunakan flag --system-addons-config dalam perintah pembuatan cluster Anda. Anda harus menggunakan versi gcloud alpha untuk menggunakan fitur ini. Contoh:

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

    Untuk mengetahui informasi selengkapnya tentang cara membuat cluster Distributed Cloud, lihat Membuat cluster.

API

  1. Tambahkan konten JSON berikut ke payload JSON dalam permintaan pembuatan cluster Anda:

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

  2. Kirimkan permintaan pembuatan cluster seperti yang dijelaskan dalam Membuat cluster.

Layanan NodePort

Distributed Cloud connected mendukung layanan NodePort Kubernetes yang memproses koneksi di node Distributed Cloud pada nomor port pilihan Anda. Layanan NodePort mendukung protokol TCP, UDP, dan SCTP. Contoh:

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

Dukungan SCTP

Distributed Cloud Connected mendukung Stream Control Transmission Protocol (SCTP) di antarmuka jaringan utama untuk jaringan internal dan eksternal. Dukungan SCTP mencakup jenis layanan NodePort, LoadBalancer, dan ClusterIP. Pod dapat menggunakan SCTP untuk berkomunikasi dengan pod lain dan resource eksternal. Contoh berikut mengilustrasikan cara mengonfigurasi IPERF sebagai layanan ClusterIP menggunakan SCTP:

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

Fungsi ini tidak tersedia di server yang terhubung ke Distributed Cloud.

Modul kernel SCTP

Mulai dari versi 1.5.0, Distributed Cloud terhubung mengonfigurasi modul kernel sctp Edge OS sebagai dapat dimuat. Dengan begitu, Anda dapat memuat stack protokol SCTP Anda sendiri di ruang pengguna kernel.

Selain itu, Distributed Cloud terhubung memuat modul berikut ke dalam kernel secara default:

Nama modul Nama konfigurasi
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

Resource ClusterDNS

Distributed Cloud connected mendukung resource Google Distributed Cloud ClusterDNS untuk mengonfigurasi server nama upstream untuk domain tertentu dengan menggunakan bagian spec.domains. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi resource ini, lihat spec.domains.

Fungsi ini tidak tersedia di server yang terhubung ke Distributed Cloud.

Langkah berikutnya