Persyaratan jaringan

Untuk menginstal dan mengoperasikan software Distributed Cloud khusus untuk bare metal, jaringan Anda harus memenuhi persyaratan dalam dokumen ini. Persyaratan ini mencakup konektivitas eksternal ke Google, konektivitas Lapisan 2 dan Lapisan 3 antara node cluster dan load balancer, rentang alamat IP untuk Pod dan Service, serta port yang digunakan komponen cluster. Jika node Anda menjalankan Red Hat Enterprise Linux (RHEL) dengan firewalld, dokumen ini juga menunjukkan cara membuka port yang diperlukan.

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.

Catatan: Meskipun Container Registry dinonaktifkan, Artifact Registry masih menggunakan URL gcr.io yang sama dengan yang digunakan oleh Container Registry. Untuk mengetahui informasi selengkapnya, lihat Repositori gcr.io.

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 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 bidang kontrol atau kumpulan node khusus. Untuk mengetahui informasi selengkapnya, lihat Memilih dan mengonfigurasi load balancer.

Saat Anda menggunakan Load balancing Lapisan 2 yang dipaketkan dengan MetalLB (spec.loadBalancer.mode: bundled dan spec.loadBalancer.type: layer2), node load balancer memerlukan kedekatan Lapisan 2. Persyaratan kedekatan Lapisan 2 berlaku baik saat Anda menjalankan load balancer di node bidang kontrol atau di kumpulan node load balancing khusus. Load balancing yang dipaketkan 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 yang Dipaketkan, 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 di subnet mesin load balancer dan dapat dirutekan ke gateway subnet.
• Pengguna bertanggung jawab untuk mengizinkan traffic load balancer ingress.

Jaringan Pod dan Service

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

Jumlah Pod dan Service 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 Service 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 Service

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 Service Kubernetes. Gunakan alamat IP di ruang alamat pribadi, seperti yang dijelaskan dalam RFC 1918. File konfigurasi cluster telah diisi otomatis dengan nilai yang termasuk 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 diisi otomatis	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, Anda mungkin perlu menggunakan rentang CIDR yang berbeda dari nilai yang telah diisi sebelumnya. Secara khusus, rentang Service dan Pod tidak boleh tumpang-tindih dengan hal berikut:

• 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 preflight memblokir pembuatan dan upgrade cluster jika alamat IP yang tumpang-tindih teridentifikasi.

Catatan: Blok CIDR Pod dan Service 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 Service (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, sehingga mengurangi nilai mask untuk meningkatkan jumlah alamat IP.

clusterNetwork.pods.cidrBlocks dan nodeConfig.podDensity.maxPodsPerNode (dijelaskan di bagian berikut) tidak dapat diubah, jadi rencanakan dengan cermat pertumbuhan cluster Anda di masa mendatang agar tidak kehabisan kapasitas node. Untuk mengetahui jumlah maksimum Pod per cluster, Pod per node, dan node per cluster yang direkomendasikan 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, yaitu 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 per node yang dikonfigurasi:

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 untuk 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 melebihi 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 pengaruh jumlah Pod dan Service serta faktor lainnya terhadap 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, sedangkan koneksi lainnya, termasuk worker node, hanya memerlukan konektivitas Lapisan 3.
• File konfigurasi menentukan alamat IP untuk worker node pool. 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.33 dan yang lebih baru

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Inbound	2379 - 2381	API klien, metrik, dan kondisi server etcd	kube-apiserver dan etcd
TCP	Inbound	2382 - 2384	API klien server, metrik, dan kondisi etcd-events	kube-apiserver dan etcd-events
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	6444	Server Kubernetes API	Semua
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	9192 (default, tetapi dapat dikonfigurasi)	Port Agen Node (hanya berlaku untuk cluster yang menggunakan Agen Node) (berlaku untuk versi 1.33 dan yang lebih baru)	node-agent-port
TCP	Inbound	9977	Menerima peristiwa audit dari server API	audit-proxy
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	10257	kube-controller-manager (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Inbound	10259	kube-scheduler (perubahan nomor port untuk versi 1.28 dan yang lebih tinggi)	Milik sendiri
TCP	Inbound	11002	Container inti GKE Identity Service terikat ke port melalui hostPort (berlaku untuk versi 1.29 dan yang lebih baru)	Milik sendiri
TCP	Inbound	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.29-1.32

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Inbound	2379 - 2381	API klien, metrik, dan kondisi server etcd	kube-apiserver dan etcd
TCP	Inbound	2382 - 2384	API klien server, metrik, dan kondisi etcd-events	kube-apiserver dan etcd-events
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	6444	Server Kubernetes API	Semua
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	9977	Menerima peristiwa audit dari server API	audit-proxy
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	10257	kube-controller-manager (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Inbound	10259	kube-scheduler (perubahan nomor port untuk versi 1.28 dan yang lebih tinggi)	Milik sendiri
TCP	Inbound	11002	Container inti GKE Identity Service terikat ke port melalui hostPort (berlaku untuk versi 1.29 dan yang lebih baru)	Milik sendiri
TCP	Inbound	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.28

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Inbound	2379 - 2381	API klien, metrik, dan kondisi server etcd	kube-apiserver dan etcd
TCP	Inbound	2382 - 2384	API klien server, metrik, dan kondisi etcd-events	kube-apiserver dan etcd-events
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	6444	Server Kubernetes API	Semua
TCP	Inbound	8444	Container inti GKE Identity Service terikat ke port melalui hostPort (hanya berlaku untuk versi 1.28)	Semua
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	9977	Menerima peristiwa audit dari server API	audit-proxy
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	10257	kube-controller-manager (perubahan nomor port untuk versi 1.28 dan yang lebih baru)	Milik sendiri
TCP	Inbound	10259	kube-scheduler (perubahan nomor port untuk versi 1.28 dan yang lebih tinggi)	Milik sendiri
TCP	Inbound	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.16

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster admin	Workstation admin
TCP	Inbound	2379 - 2381	API klien, metrik, dan kondisi server etcd	kube-apiserver dan etcd
TCP	Inbound	2382 - 2384	API klien server, metrik, dan kondisi etcd-events (berlaku untuk versi 1.16 dan yang lebih baru)	kube-apiserver dan etcd-events
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	6444	Server Kubernetes API	Semua
TCP	Inbound	9100	Metrik penyajian	node-exporter
TCP	Inbound	9443	Menyajikan/mem-proxy metrik untuk komponen bidang kontrol (Persyaratan port ini berlaku untuk cluster versi 1.16 dan yang lebih rendah.)	kube-control-plane-metrics-proxy
TCP	Inbound	9977	Menerima peristiwa audit dari server API	audit-proxy
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10251	kube-scheduler	Milik sendiri
TCP	Inbound	10252	kube-controller-manager	Milik sendiri
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	14443	Layanan Webhook ANG	kube-apiserver dan ang-controller-manager

Versi 1.15 dan yang lebih rendah

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

Worker node

Versi 1.33 dan yang lebih baru

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	9192 (default, tetapi dapat dikonfigurasi)	Port Agen Node (hanya berlaku untuk cluster yang menggunakan Agen Node) (berlaku untuk versi 1.33 dan yang lebih baru)	node-agent-port
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	30000 - 32767	Layanan NodePort	Milik sendiri

Versi 1.29-1.32

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	30000 - 32767	Layanan NodePort	Milik sendiri

Versi 1.28

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	9100	auth-proxy	node-exporter
TCP	Inbound	9101	Menyajikan metrik node hanya di localhost (berlaku untuk versi 1.28 dan yang lebih baru)	node-exporter
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	30000 - 32767	Layanan NodePort	Milik sendiri

Versi 1.16

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	9100	Metrik penyajian	node-exporter
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	30000 - 32767	Layanan NodePort	Milik sendiri

Versi 1.15 dan yang lebih rendah

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	9100	Metrik penyajian	node-exporter
TCP	Inbound	10250	kubelet API	Self dan bidang kontrol
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	30000 - 32767	Layanan NodePort	Milik sendiri

Node load balancer

Versi 1.33 dan yang lebih baru

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Inbound	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan kolom controlPlaneLBPort.	Semua
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP dan UDP	Inbound	7946	Health check MetalLB	Node load balancer
TCP	Inbound	9192 (default, tetapi dapat dikonfigurasi)	Port Agen Node (hanya berlaku untuk cluster yang menggunakan Agen Node) (berlaku untuk versi 1.33 dan yang lebih baru)	node-agent-port
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	11000	Port pemroses untuk metrik HAProxy (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih baru)	Semua
TCP	Inbound	11001	Port pemrosesan untuk GKE Identity Service (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih baru)	Semua

Versi 1.29-1.32

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Inbound	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan kolom controlPlaneLBPort.	Semua
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP dan UDP	Inbound	7946	Health check MetalLB	Node load balancer
TCP	Inbound	10256	Health check node	Semua
TCP	Inbound	11000	Port pemroses untuk metrik HAProxy (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih baru)	Semua
TCP	Inbound	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	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Inbound	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan kolom controlPlaneLBPort.	Semua
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP dan UDP	Inbound	7946	Health check MetalLB	Node load balancer
TCP	Inbound	8443	Port pemantauan untuk GKE Identity Service (tidak dapat diubah) (hanya berlaku untuk versi 1.28)	Semua
TCP	Inbound	10256	Health check node	Semua

Versi 1.16

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Inbound	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan kolom controlPlaneLBPort.	Semua
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	7946	Health check MetalLB	node load balancer
TCP	Inbound	10256	Health check node	Semua

Versi 1.15 dan yang lebih rendah

Protokol	Arah	Rentang port	Tujuan	Digunakan oleh
TCP	Inbound	22	Penyediaan dan pembaruan node cluster pengguna	Node cluster admin
TCP	Inbound	443	Pengelolaan cluster Port ini dapat dikonfigurasi dalam file konfigurasi cluster dengan kolom controlPlaneLBPort.	Semua
TCP	Keduanya	4240	Health check CNI	Semua
UDP	Inbound	6081	Enkapsulasi GENEVE	Milik sendiri
TCP	Inbound	7946	Health check MetalLB	node load balancer
TCP	Inbound	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	Inbound	22	Penyediaan dan pembaruan node cluster	Semua node
TCP	Inbound	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 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 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 persyaratan port spesifik untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh sebagaimana mestinya.

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 worker node

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

Untuk persyaratan port spesifik untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh sebagaimana mestinya.

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 persyaratan port spesifik untuk versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Perbarui perintah contoh sebagaimana mestinya.

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 baru. 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 apa yang Anda temukan di langkah sebelumnya:

   • public: zona yang telah ditetapkan untuk digunakan di area publik tempat hanya koneksi masuk yang dipilih yang diterima.
   • trusted: zona yang telah ditentukan 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 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.

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

Mengonfirmasi konfigurasi port Anda

Untuk memverifikasi konfigurasi port, gunakan langkah-langkah berikut pada node bidang kontrol, worker, 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 Anda:

   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.