Persyaratan jaringan

Dokumen ini berisi penjelasan mengenai persyaratan jaringan untuk menginstal dan mengoperasikan Google Distributed Cloud.

Persyaratan jaringan eksternal

Google Distributed Cloud memerlukan koneksi internet untuk tujuan operasional. Google Distributed Cloud mengambil komponen cluster dari Container Registry dan cluster tersebut didaftarkan dengan Connect.

Anda dapat terhubung ke Google menggunakan internet publik melalui HTTPS, virtual private network (VPN), atau koneksi Dedicated Interconnect.

Jika mesin yang Anda gunakan untuk workstation admin dan node cluster menggunakan server proxy untuk mengakses internet, server proxy Anda harus mengizinkan beberapa koneksi tertentu. Untuk mengetahui detailnya, lihat bagian prasyarat dari Menginstal di belakang proxy.

Persyaratan jaringan internal

Google Distributed Cloud dapat berfungsi dengan konektivitas Lapisan 2 atau Lapisan 3 di antara node cluster. Node load balancer dapat berupa node bidang kontrol atau kumpulan node khusus. Untuk mengetahui informasi selengkapnya, baca artikel Memilih dan mengonfigurasi load balancer.

Saat Anda menggunakan load balancing Paket Lapisan 2 dengan MetalLB (spec.loadBalancer.mode: bundled dan spec.loadBalancer.type: layer2), node load balancer memerlukan kedekatan Lapisan 2. Persyaratan kedekatan Lapisan 2 berlaku baik Anda menjalankan load balancer pada node bidang kontrol maupun dalam kumpulan node load balancing khusus. Load balancing paket dengan BGP mendukung protokol Lapisan 3, sehingga kedekatan Lapisan 2 yang ketat tidak diperlukan.

Persyaratan untuk mesin load balancer adalah sebagai berikut:

  • Untuk load balancing Lapisan 2 Paket, semua load balancer untuk cluster tertentu berada di domain Lapisan 2 yang sama. Node bidang kontrol juga harus berada di domain Lapisan 2 yang sama.
  • Untuk load balancing Lapisan 2 Paket, semua alamat IP virtual (VIP) harus berada dalam subnet mesin load balancer dan dapat dirutekan ke gateway subnet.
  • Pengguna bertanggung jawab untuk mengizinkan traffic load balancer masuk.

Jaringan pod

Dengan Google Distributed Cloud, Anda dapat mengonfigurasi hingga 250 pod per node. Kubernetes menetapkan blok Classless Inter-Domain Routing (CIDR) ke setiap node sehingga setiap pod dapat memiliki alamat IP yang unik. Ukuran blok CIDR sesuai dengan jumlah maksimum pod per node. Tabel berikut mencantumkan ukuran blok CIDR yang ditetapkan Kubernetes ke setiap node berdasarkan pod maksimum yang dikonfigurasi per node:

Pod maksimum per node Blok CIDR per node Jumlah alamat IP
32 /26 64
33 – 64 /25 128
65 – 128 /24 256
129 - 250 /23 512

Menjalankan 250 pod per node mengharuskan Kubernetes mencadangkan blok CIDR /23 untuk setiap node. Dengan asumsi bahwa cluster Anda menggunakan nilai default /16 untuk kolom clusterNetwork.pods.cidrBlocks, cluster Anda memiliki batas (2(23-16))=128 node. Jika ingin mengembangkan cluster di luar batas ini, Anda dapat meningkatkan nilai clusterNetwork.pods.cidrBlocks atau mengurangi nilai nodeConfig.podDensity.maxPodsPerNode. Metode ini memiliki beberapa kelemahan.

Deployment cluster pengguna tunggal dengan ketersediaan tinggi

Diagram berikut mengilustrasikan sejumlah konsep jaringan utama untuk Google Distributed Cloud dalam satu kemungkinan konfigurasi jaringan.

Konfigurasi jaringan standar Google Distributed Cloud

Pertimbangkan informasi berikut untuk memenuhi persyaratan jaringan:

  • Node bidang kontrol menjalankan load balancer, dan semuanya memiliki konektivitas Lapisan 2, sedangkan koneksi lainnya, termasuk node pekerja, hanya memerlukan konektivitas Lapisan 3.
  • File konfigurasi menentukan alamat IP untuk kumpulan node pekerja. File konfigurasi juga menentukan VIP untuk tujuan berikut:
    • Service
    • Masuk
    • Akses bidang kontrol melalui Kubernetes API
  • Anda memerlukan koneksi ke Google Cloud.

Penggunaan port

Bagian ini mengidentifikasi persyaratan port untuk cluster Google Distributed Cloud. Tabel berikut menunjukkan cara port UDP dan TCP digunakan oleh komponen Kubernetes pada node cluster dan load balancer.

Node bidang kontrol

Versi 1.28

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster admin Workstation admin
TCP Masuk 2379 - 2381 API, metrik, dan kondisi klien server etcd kube-apiserver dan etcd
TCP Masuk 2382 - 2384 API, metrik, dan kondisi klien server peristiwa etcd-events kube-apiserver dan etcd-events
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 6444 Server Kubernetes API Semua
TCP Masuk 8443 dan 8444 GKE Identity Service v2 Deployment ais yang berjalan di namespace anthos-identity-service
TCP Masuk 9100 proxy-auth node-exporter
TCP Masuk 9101 Menayangkan metrik node hanya di localhost

(Persyaratan untuk port yang ditambahkan untuk versi 1.28 dan yang lebih tinggi.)

node-exporter
TCP Masuk 9977 Menerima peristiwa audit dari server API audit-proxy
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10256 Health check node Semua
TCP Masuk 10257 kube-controller-manager

(Nomor port diubah untuk versi 1.28 dan yang lebih baru.)

Milik sendiri
TCP Masuk 10259 kube-scheduler

(Nomor port diubah untuk versi 1.28 dan yang lebih tinggi.)

Milik sendiri
TCP Masuk 14443 Layanan Webhook ANG kube-apiserver dan ang-controller-manager

Versi 1.16

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster admin Workstation admin
TCP Masuk 2379 - 2381 API, metrik, dan kondisi klien server etcd kube-apiserver dan etcd
TCP Masuk 2382 - 2384 API, metrik, dan kondisi klien server peristiwa etcd-events

(Persyaratan untuk port yang ditambahkan untuk versi 1.16 dan yang lebih baru.)

kube-apiserver dan etcd-events
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 6444 Server Kubernetes API Semua
TCP Masuk 9100 Metrik penayangan node-exporter
TCP Masuk 9443 Metrik penayangan/proxy untuk komponen bidang kontrol (Persyaratan port ini adalah untuk cluster versi 1.16 dan yang lebih lama.) kube-control-plane-metrics-proxy
TCP Masuk 9977 Menerima peristiwa audit dari server API audit-proxy
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10251 kube-scheduler Milik sendiri
TCP Masuk 10252 kube-controller-manager Milik sendiri
TCP Masuk 10256 Health check node Semua
TCP Masuk 14443 Layanan Webhook ANG kube-apiserver dan ang-controller-manager

Versi 1.15 dan yang lebih lama

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster admin Workstation admin
TCP Masuk 2379 - 2381 API, metrik, dan kondisi klien server etcd kube-apiserver dan etcd
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 6444 Server Kubernetes API Semua
TCP Masuk 9100 Metrik penayangan node-exporter
TCP Masuk 9443 Metrik penayangan/proxy untuk komponen bidang kontrol (Persyaratan port ini adalah untuk cluster versi 1.16 dan yang lebih lama.) kube-control-plane-metrics-proxy
TCP Masuk 9977 Menerima peristiwa audit dari server API audit-proxy
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10251 kube-scheduler Milik sendiri
TCP Masuk 10252 kube-controller-manager Milik sendiri
TCP Masuk 10256 Health check node Semua
TCP Masuk 14443 Layanan Webhook ANG kube-apiserver dan ang-controller-manager

Node pekerja

Versi 1.28

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 9100 proxy-auth node-exporter
TCP Masuk 9101 Menayangkan metrik node hanya di localhost

(Persyaratan untuk port yang ditambahkan untuk versi 1.28 dan yang lebih tinggi.)

node-exporter
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10256 Health check node Semua
TCP Masuk 30.000 - 32.767 Layanan NodePort Milik sendiri

Versi 1.16

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 9100 Metrik penayangan node-exporter
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10256 Health check node Semua
TCP Masuk 30.000 - 32.767 Layanan NodePort Milik sendiri

Versi 1.15 dan yang lebih lama

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 10250 kubelet API Bidang mandiri dan kontrol
TCP Masuk 10256 Health check node Semua
TCP Masuk 30.000 - 32.767 Layanan NodePort Milik sendiri

Node load balancer

Versi 1.28

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Masuk 443 Pengelolaan cluster

Port ini dapat dikonfigurasi di konfigurasi cluster, menggunakan kolom controlPlaneLBPort.

Semua
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP dan UDP Masuk 7946 Health check MetalLB Node load balancer
TCP Masuk 10256 Health check node Semua

Versi 1.16

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Masuk 443 Pengelolaan cluster

Port ini dapat dikonfigurasi di konfigurasi cluster, menggunakan kolom controlPlaneLBPort.

Semua
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 7946 Health check MetalLB node load balancer
TCP Masuk 10256 Health check node Semua

Versi 1.15 dan yang lebih lama

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster pengguna Node cluster admin
TCP Masuk 443 Pengelolaan cluster

Port ini dapat dikonfigurasi di konfigurasi cluster, menggunakan kolom controlPlaneLBPort.

Semua
TCP Keduanya 4240 Health check CNI Semua
UDP Masuk 6081 Enkapsulasi GENEVE Milik sendiri
TCP Masuk 7946 Health check MetalLB node load balancer
TCP Masuk 10256 Health check node Semua

Persyaratan port multi-cluster

Dalam konfigurasi multi-cluster, cluster yang ditambahkan harus menyertakan port berikut untuk berkomunikasi dengan cluster admin.

Protocol Arah Rentang port Tujuan Digunakan oleh
TCP Masuk 22 Penyediaan dan update node cluster Semua node
TCP Masuk 443 Server Kubernetes API untuk cluster yang ditambahkan

Port ini dapat dikonfigurasi di konfigurasi cluster, menggunakan kolom controlPlaneLBPort.

Node bidang kontrol dan load balancer

Mengonfigurasi port yang dilindungi firewall

Anda tidak perlu menonaktifkan firewall untuk menjalankan Google Distributed Cloud di Red Hat Enterprise Linux (RHEL). Untuk menggunakan firewall, Anda harus membuka port UDP dan TCP yang digunakan oleh node bidang kontrol, worker, dan load balancer seperti yang dijelaskan dalam Penggunaan port di halaman ini. Contoh konfigurasi berikut menunjukkan cara membuka port dengan firewall-cmd, utilitas command line yang dilindungi firewall. Anda harus menjalankan perintah sebagai pengguna root.

Konfigurasi contoh node bidang kontrol

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan pada server yang menjalankan node bidang kontrol:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Ganti PODS_CIDR dengan blok CIDR yang dicadangkan untuk pod Anda yang dikonfigurasi di kolom clusterNetwork.pods.cidrBlocks. Blok CIDR default untuk pod adalah 192.168.0.0/16.

Konfigurasi contoh node pekerja

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan pada server yang menjalankan worker node:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Ganti PODS_CIDR dengan blok CIDR yang dicadangkan untuk pod Anda yang dikonfigurasi di kolom clusterNetwork.pods.cidrBlocks. Blok CIDR default untuk pod adalah 192.168.0.0/16.

Konfigurasi contoh node load balancer

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan pada server yang menjalankan node load balancer:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Ganti PODS_CIDR dengan blok CIDR yang dicadangkan untuk pod Anda yang dikonfigurasi di kolom clusterNetwork.pods.cidrBlocks. Blok CIDR default untuk pod adalah 192.168.0.0/16.

Konfirmasi konfigurasi port

Untuk memverifikasi konfigurasi port Anda, gunakan langkah-langkah berikut pada node bidang kontrol, pekerja, dan load balancer:

  1. Jalankan perintah Network Mapper berikut untuk melihat port mana yang terbuka:

    nmap localhost
    
  2. Jalankan perintah berikut untuk mendapatkan setelan konfigurasi firewall:

    firewall-cmd --zone=public --list-all-policies
    firewall-cmd --zone=public --list-ports
    firewall-cmd --zone=public --list-services
    firewall-cmd --zone=k8s-pods --list-all-policies
    firewall-cmd --zone=k8s-pods --list-ports
    firewall-cmd --zone=k8s-pods --list-services
    
  3. Jika perlu, jalankan kembali perintah dari bagian sebelumnya untuk mengonfigurasi node Anda dengan benar. Anda mungkin perlu menjalankan perintah sebagai pengguna root.

Masalah umum untuk firewall

Saat menjalankan Google Distributed Cloud dengan firewalld diaktifkan di Red Hat Enterprise Linux (RHEL), perubahan pada firewalld dapat menghapus rantai iptables Cilium di jaringan host. Rantai iptables ditambahkan oleh Pod anetd saat dimulai. Hilangnya rantai iptables Cilium menyebabkan Pod di Node kehilangan konektivitas jaringan di luar Node.

Perubahan pada firewalld yang menghapus rantai iptables mencakup, tetapi tidak terbatas pada:

  • Memulai ulang firewalld, menggunakan systemctl

  • Memuat ulang firewalld dengan klien command line (firewall-cmd --reload)

Untuk menerapkan perubahan firewalld tanpa menghapus rantai iptables, mulai ulang anetd di Node:

  1. Temukan dan hapus Pod anetd dengan perintah berikut untuk memulai ulang anetd:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Ganti ANETD_XYZ dengan nama Pod anetd.