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, dan spesialis Jaringan yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta mendesain dan merancang jaringan untuk organisasi mereka. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

Persyaratan jaringan eksternal

Google Distributed Cloud memerlukan koneksi internet untuk tujuan operasional. Google Distributed Cloud mengambil komponen cluster dari Container 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 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 di artikel Menginstal di balik proxy.

Persyaratan jaringan internal

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

Saat Anda menggunakan Load balancing Layer 2 yang dipaketkan dengan MetalLB (spec.loadBalancer.mode: bundled dan spec.loadBalancer.type: layer2), node load balancer memerlukan adjacency 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 yang dipaketkan dengan BGP mendukung protokol Lapisan 3, sehingga tidak diperlukan adjacency Lapisan 2 yang ketat.

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 yang Dipaketkan, semua alamat IP virtual (VIP) harus berada di subnet mesin load balancer dan dapat dirutekan ke gateway subnet.
• Pengguna bertanggung jawab untuk mengizinkan traffic load balancer masuk.

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 Anda pertimbangkan saat merencanakan penginstalan cluster.

Jumlah Pod dan Layanan yang dapat Anda miliki di cluster 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 lain yang akan digunakan untuk alamat ClusterIP Layanan Kubernetes. Gunakan alamat IP di ruang alamat pribadi, seperti yang dijelaskan dalam RFC 1918. File konfigurasi cluster diisi otomatis dengan nilai yang berada dalam batas yang dijelaskan dalam tabel berikut:

Batas	Pod	Layanan
Rentang minimum	Nilai mask /18 (16.384 alamat)	Nilai mask /24 (256 alamat)
Rentang yang telah diisi sebelumnya	Nilai mask /16 (65.536 alamat)	Nilai mask /20 (4.096 alamat)
Rentang maksimum	Nilai mask /8 (16.777.216 alamat)	Nilai mask /12 (1.048.576 alamat)

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

• Alamat IP node di cluster mana pun

• VIP yang digunakan oleh node 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 diidentifikasi.

Catatan: Blok CIDR Pod dan Layanan untuk cluster dibagi menjadi rentang alamat IP yang lebih kecil untuk setiap node cluster. Google Distributed Cloud menggunakan penafsiran alamat jaringan (NAT) untuk memetakan rentang alamat IP Pod ini ke alamat IP Node. Jika salah satu alamat IP Pod ini sesuai dengan alamat IP eksternal, alamat eksternal tersebut dianggap tidak dapat dijangkau dari dalam cluster.

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 akhiran blok CIDR, yang mengurangi nilai mask untuk meningkatkan jumlah alamat IP.

clusterNetwork.pods.cidrBlocks dan nodeConfig.podDensity.maxPodsPerNode (dijelaskan di bagian berikut) tidak dapat diubah sehingga rencanakan dengan cermat pertumbuhan cluster Anda di masa mendatang agar tidak kehabisan kapasitas node. Untuk nilai 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 maksimum hingga 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.

Catatan: Setelan maxPodsPerNode hanya memperhitungkan pod yang berjalan, pod yang menggunakan resource. Misalnya, Tugas Kubernetes membuat satu atau beberapa pod untuk menyelesaikan tugas tertentu. Pod biasanya berjalan hingga menyelesaikan tugas (atau gagal) dan berhenti. Pod yang dihentikan ini biasanya tidak dibersihkan secara otomatis, sehingga muncul di node saat Anda menjalankan kubectl get pods. Namun, karena pod yang dihentikan tidak menggunakan resource apa pun, termasuk alamat IP, pod tersebut tidak berkontribusi pada total pod maksimum 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 Anda ingin mengembangkan cluster di luar batas ini, sebaiknya tetapkan clusterNetwork.pods.cidrBlocks ke blok CIDR pod yang jauh lebih besar dari nilai yang diisi otomatis.

Untuk mengetahui informasi selengkapnya tentang pengaruh jumlah Pod dan Service serta faktor lainnya terhadap skalabilitas cluster, lihat Melakukan penskalaan ke atas 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, sedangkan 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 port UDP dan TCP digunakan oleh komponen Kubernetes di node cluster dan load balancer.

Node bidang kontrol

Versi 1.29

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Masuk	2379 - 2381	API, metrik, dan status klien server etcd	kube-apiserver dan etcd
TCP	Masuk	2382 - 2384	API, metrik, dan status server klien 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	9100	auth-proxy	node-exporter
TCP	Masuk	9101	Menayangkan metrik node hanya di localhost (berlaku 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 kontrol dan mandiri
TCP	Masuk	10256	Health check node	Semua
TCP	Masuk	10257	kube-controller-manager (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Masuk	10259	kube-scheduler (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Masuk	11002	Penampung inti Identity Service GKE terikat ke port melalui hostPort (berlaku untuk versi 1.29 dan yang lebih baru)	Milik sendiri
TCP	Masuk	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.28

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Masuk	2379 - 2381	API, metrik, dan status klien server etcd	kube-apiserver dan etcd
TCP	Masuk	2382 - 2384	API, metrik, dan status server klien 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	8444	Penampung inti Identity Service GKE terikat ke port melalui hostPort (hanya berlaku untuk versi 1.28)	Semua
TCP	Masuk	9100	auth-proxy	node-exporter
TCP	Masuk	9101	Menayangkan metrik node hanya di localhost (berlaku 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 kontrol dan mandiri
TCP	Masuk	10256	Health check node	Semua
TCP	Masuk	10257	kube-controller-manager (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Masuk	10259	kube-scheduler (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Masuk	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.16

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Masuk	2379 - 2381	API, metrik, dan status klien server etcd	kube-apiserver dan etcd
TCP	Masuk	2382 - 2384	API, metrik, dan status server klien etcd-events (berlaku 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	Melayani metrik	node-exporter
TCP	Masuk	9443	Melayani/membuat proxy metrik untuk komponen panel kontrol (Persyaratan port ini ditujukan 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 kontrol dan mandiri
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

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Masuk	2379 - 2381	API, metrik, dan status 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	Melayani metrik	node-exporter
TCP	Masuk	9443	Melayani/membuat proxy metrik untuk komponen panel kontrol (Persyaratan port ini ditujukan 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 kontrol dan mandiri
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.29

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Masuk	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Masuk	9100	auth-proxy	node-exporter
TCP	Masuk	9101	Menayangkan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih tinggi)	node-exporter
TCP	Masuk	10250	kubelet API	Bidang kontrol dan mandiri
TCP	Masuk	10256	Health check node	Semua
TCP	Masuk	30.000 - 32.767	Layanan NodePort	Milik sendiri

Versi 1.28

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Masuk	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Masuk	9100	auth-proxy	node-exporter
TCP	Masuk	9101	Menayangkan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih tinggi)	node-exporter
TCP	Masuk	10250	kubelet API	Bidang kontrol dan mandiri
TCP	Masuk	10256	Health check node	Semua
TCP	Masuk	30.000 - 32.767	Layanan NodePort	Milik sendiri

Versi 1.16

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

Versi 1.15 dan yang lebih lama

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

Node load balancer

Versi 1.29

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan 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
TCP	Masuk	11000	Port pemrosesan untuk metrik HAProxy (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih baru)	Semua
TCP	Masuk	11001	Port pemrosesan untuk GKE Identity Service (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih baru)	Semua

Versi 1.28

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan 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	8443	Port pemrosesan untuk GKE Identity Service (tidak dapat diubah) (hanya berlaku untuk versi 1.28)	Semua
TCP	Masuk	10256	Health check node	Semua

Versi 1.16

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan 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

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan 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.

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Masuk	22	Penyediaan dan pembaruan node cluster	Semua node
TCP	Masuk	443	Server Kubernetes API untuk cluster yang ditambahkan Port ini dapat dikonfigurasi dalam konfigurasi cluster, menggunakan kolom controlPlaneLBPort.	Node bidang kontrol dan load balancer

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 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 sesuai kebutuhan.

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 node pekerja:

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 sesuai kebutuhan.

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 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 sesuai kebutuhan.

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 dalam 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. Cantumkan 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. Cantumkan 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 zona dan kebijakan 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 hal yang Anda temukan di langkah sebelumnya:

   • public: zona standar untuk digunakan di area publik tempat hanya koneksi masuk tertentu yang diterima.
   • trusted: zona standar dalam lingkungan 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 akan mencantumkan port yang perlu 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 diikuti dengan protokol. Contoh, 10250-10252/tcp.

Catatan: Bug di beberapa kernel Linux untuk Red Hat Enterprise Linux (RHEL) 9.2 mungkin mengakibatkan download image yang sangat lambat. Untuk informasi selengkapnya, termasuk petunjuk solusi, lihat Download lambat dalam penampung di RHEL 9.2.

Mengonfirmasi konfigurasi port

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

1. Jalankan perintah Network Mapper berikut untuk melihat port 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 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.