Persyaratan jaringan

Dokumen ini menguraikan persyaratan jaringan untuk menginstal dan mengoperasikan Google Distributed Cloud (khusus software) di bare metal.

Halaman ini ditujukan untuk Admin dan arsitek, Operator, serta Spesialis jaringan yang mengelola siklus proses infrastruktur teknologi dasar, serta mendesain dan membangun arsitektur jaringan untuk organisasi mereka. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Persyaratan jaringan eksternal

Google Distributed Cloud memerlukan koneksi internet untuk tujuan operasional. Google Distributed Cloud mengambil komponen cluster dari Artifact Registry, dan cluster didaftarkan dengan Connect Agent.

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

Jika komputer 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 di artikel Menginstal di belakang proxy.

Persyaratan jaringan internal

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

Saat Anda menggunakan Load balancing Layer 2 gabungan dengan MetalLB (spec.loadBalancer.mode: bundled dan spec.loadBalancer.type: layer2), node load balancer memerlukan kedekatan Layer 2. Persyaratan kedekatan Lapisan 2 berlaku baik saat Anda menjalankan load balancer di node bidang kontrol maupun di kumpulan node load balancing khusus. Load balancing gabungan 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 Layer 2 yang Dipaketkan, semua load balancer untuk cluster tertentu berada di domain Layer 2 yang sama. Node bidang kontrol juga harus berada di domain Layer 2 yang sama.
• Untuk load balancing Lapisan 2 Gabungan, semua alamat IP virtual (VIP) harus berada di subnet mesin load balancer dan dapat di-routing ke gateway subnet.
• Pengguna bertanggung jawab untuk mengizinkan traffic load balancer ingress.

Jaringan Pod dan Service

Rentang alamat IP yang tersedia untuk Layanan dan Pod ditentukan dalam file konfigurasi cluster. Bagian berikut membahas batasan minimum dan maksimum untuk rentang alamat dan beberapa faktor terkait yang perlu dipertimbangkan saat merencanakan penginstalan cluster.

Jumlah Pod dan Layanan yang dapat Anda miliki di cluster Anda dikontrol oleh setelan berikut:

• clusterNetwork.pods.cidrBlocks menentukan jumlah Pod yang diizinkan di cluster Anda.

• clusterNetwork.services.cidrBlocks menentukan jumlah Layanan yang diizinkan di cluster Anda.

• nodeConfig.podDensity.maxPodsPerNode menentukan jumlah maksimum Pod yang dapat berjalan di satu node.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Rentang alamat IP untuk Pod dan Layanan

Anda menentukan rentang alamat IP sebagai blok Classless Inter-Domain Routing (CIDR)yang akan digunakan untuk Pod dan blok CIDR lainnya yang akan digunakan untuk alamat ClusterIP Layanan Kubernetes. Gunakan alamat IP di ruang alamat pribadi, seperti yang dijelaskan dalam RFC 1918. File konfigurasi cluster sudah diisi dengan nilai yang berada dalam batas yang dijelaskan dalam tabel berikut:

Untuk menghindari tumpang-tindih dengan alamat IP yang dapat dijangkau di jaringan Anda, Anda mungkin perlu menggunakan rentang CIDR yang berbeda dari nilai yang telah diisi sebelumnya. Secara khusus, rentang Layanan dan Pod tidak boleh tumpang-tindih dengan berikut ini:

• Alamat IP node di cluster mana pun

• VIP yang digunakan oleh node bidang kontrol dan load balancer

• Alamat IP server DNS atau server NTP

Pemeriksaan pra-penerbangan memblokir pembuatan dan upgrade cluster jika alamat IP yang tumpang-tindih teridentifikasi.

Anda dapat meningkatkan rentang jaringan Layanan (clusterNetwork.services.cidrBlocks) setelah membuat cluster, tetapi Anda tidak dapat mengurangi jumlah alamat IP yang dialokasikan atau mengubahnya. Anda hanya dapat mengubah sufiks blok CIDR, mengurangi nilai mask untuk meningkatkan jumlah alamat IP.

clusterNetwork.pods.cidrBlocks dan nodeConfig.podDensity.maxPodsPerNode (dijelaskan di bagian berikut) bersifat tetap sehingga rencanakan dengan cermat pertumbuhan cluster Anda di masa mendatang untuk menghindari kehabisan kapasitas node. Untuk jumlah maksimum yang direkomendasikan untuk Pod per cluster, Pod per node, dan node per cluster berdasarkan pengujian, lihat Batas.

Pod maksimum per node

Di bare metal, Google Distributed Cloud memungkinkan Anda mengonfigurasi hingga maksimum 250 pod per node. Kubernetes menetapkan blok CIDR ke setiap node sehingga setiap pod dapat memiliki alamat IP yang unik. Ukuran blok CIDR pod sesuai dengan jumlah maksimum pod per node.

Tabel berikut mencantumkan ukuran blok CIDR yang ditetapkan Kubernetes ke setiap node berdasarkan Pod maksimum per node yang dikonfigurasi:

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 Anda ingin mengembangkan cluster melampaui batas ini, sebaiknya tetapkan clusterNetwork.pods.cidrBlocks ke blok CIDR pod yang jauh lebih besar daripada nilai yang telah diisi sebelumnya.

Untuk mengetahui informasi selengkapnya tentang cara jumlah Pod dan Layanan serta faktor lainnya memengaruhi skalabilitas cluster, lihat Menskalakan cluster Google Distributed Cloud.

Deployment cluster pengguna tunggal dengan ketersediaan tinggi

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

Pertimbangkan informasi berikut untuk memenuhi persyaratan jaringan:

• Node bidang kontrol menjalankan load balancer, dan semuanya memiliki konektivitas Lapisan 2, sementara koneksi lain, termasuk node pekerja, hanya memerlukan konektivitas Lapisan 3.
• File konfigurasi menentukan alamat IP untuk node pool pekerja. File konfigurasi juga menentukan VIP untuk tujuan berikut:
  • Layanan
  • 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 penggunaan port UDP dan TCP oleh komponen Kubernetes di node cluster dan load balancer.

Node bidang kontrol

Node pekerja

Node load balancer

Persyaratan port multi-cluster

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

Mengonfigurasi port firewalld

Anda tidak perlu menonaktifkan firewalld untuk menjalankan Google Distributed Cloud di Red Hat Enterprise Linux (RHEL). Untuk menggunakan firewalld, Anda harus membuka port UDP dan TCP yang digunakan oleh node bidang kontrol, pekerja, 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 firewalld. Anda harus menjalankan perintah sebagai pengguna root.

Contoh konfigurasi node bidang kontrol

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan di 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=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/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

Untuk mengetahui persyaratan port tertentu untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh yang sesuai.

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.

Contoh konfigurasi node pekerja

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan di 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

Untuk mengetahui persyaratan port tertentu untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh yang sesuai.

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.

Contoh konfigurasi node load balancer

Blok perintah berikut menunjukkan contoh cara membuka port yang diperlukan di 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

Untuk mengetahui persyaratan port tertentu untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh yang sesuai.

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 tambahan untuk RHEL 9.2 dan 9.4

Red Hat Enterprise Linux (RHEL) versi 9.2 dan 9.4 didukung sebagai GA di versi 1.29.400 dan yang lebih tinggi. Dengan RHEL versi 9.2 dan 9.4, Anda harus melakukan konfigurasi firewalld tambahan pada node agar layanan dan pod Anda berfungsi dengan baik:

1. Mencantumkan antarmuka aktif untuk node guna menemukan antarmuka node utama:

   firewall-cmd --list-interfaces
   

   Berdasarkan konvensi penamaan untuk antarmuka mesin Linux, nama antarmuka utama Anda mungkin terlihat seperti salah satu dari berikut ini: eth0, eno1, ens1, atau enp2s0.

2. Mencantumkan zona untuk node guna menemukan zona yang digunakan antarmuka utama:

   firewall-cmd --list-all-zones
   

   Misalnya, jika antarmuka utama Anda adalah eno1, bagian respons berikut menunjukkan bahwa antarmuka utama berada di zona public:

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. Jalankan perintah firewalld berikut untuk menyiapkan detail kebijakan dan zona kustom untuk RHEL 9.2 atau 9.4:

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   Ganti IN_ZONE dengan salah satu nilai berikut, berdasarkan temuan Anda di langkah sebelumnya:

   • public: zona yang telah ditentukan sebelumnya untuk digunakan di area publik tempat hanya koneksi masuk tertentu yang diterima.
   • trusted: zona yang telah ditentukan sebelumnya dalam lingkungan yang terkontrol tempat semua koneksi jaringan diterima.
   • Nama zona kustom yang telah Anda tentukan.

4. Ikuti dokumentasi vendor untuk mengonfigurasi solusi penyimpanan Anda.

   Misalnya, jika Anda menggunakan Portworx untuk mengelola workload stateful, persyaratan jaringan Portworx mencantumkan port yang harus tetap terbuka.

   Untuk setiap port yang tercantum dalam dokumentasi vendor, jalankan perintah berikut:

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   Ganti PORT_INFO dengan nomor port atau rentang nomor port yang diikuti dengan protokol. Contoh, 10250-10252/tcp.

Konfirmasi konfigurasi port Anda

Untuk memverifikasi konfigurasi port, gunakan langkah-langkah berikut di bidang kontrol, worker, dan node load balancer:

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

   nmap localhost
   

2. Jalankan perintah berikut untuk mendapatkan setelan konfigurasi firewalld:

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

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 firewalld

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.