Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Persyaratan jaringan

Dokumen ini menguraikan persyaratan jaringan untuk menginstal dan mengoperasikan Google Distributed Cloud.

Halaman ini ditujukan untuk Admin dan arsitek, Operator, serta Spesialis jaringan yang mengelola siklus hidup teknologi yang mendasarinya infrastruktur, lalu merancang dan merancang jaringan organisasi mereka. Kepada mempelajari lebih lanjut tentang peran umum dan contoh tugas yang kami rujuk dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise yang umum.

Persyaratan jaringan eksternal

Google Distributed Cloud memerlukan koneksi internet untuk tujuan operasional. Google Distributed Cloud mengambil komponen cluster dari Container Registry, dan cluster tersebut terdaftar di Connect.

Anda dapat terhubung ke Google menggunakan internet publik melalui HTTPS, sebuah jaringan pribadi (VPN), atau Dedicated Interconnect.

Jika komputer yang Anda gunakan untuk workstation admin dan node cluster menggunakan server {i>proxy<i} untuk mengakses internet, server {i>proxy<i} Anda harus mengizinkan beberapa koneksi tertentu. Untuk detailnya, lihat bagian prasyarat di Menginstal di belakang proxy.

Persyaratan jaringan internal

Google Distributed Cloud dapat berfungsi dengan Lapisan 2 atau Layer 3 konektivitas antar-node cluster. Node load balancer dapat menjadi kontrol node bidang atau satu set node khusus. Untuk informasi selengkapnya, lihat Memilih dan mengonfigurasi load balancer.

Bila Anda menggunakan load balancing Bundled Layer 2 dengan MetalLB (spec.loadBalancer.mode: bundled dan spec.loadBalancer.type: layer2), node load balancer memerlukan Lapisan 2 terdekat. Persyaratan kedekatan Lapisan 2 berlaku baik saat Anda menjalankan beban pada node bidang kontrol atau pada set node load balancing khusus. Dukungan load balancing dengan BGP dalam paket Protokol Lapisan 3, sehingga jarak 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 sama Domain lapisan 2.
Untuk load balancing Lapisan 2 Paket, semua alamat IP virtual (VIP) harus di subnet mesin load balancer dan di subnet yang berbeda.
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 Classless Inter-Domain Routing (CIDR) blokir ke setiap node, sehingga tiap pod dapat memiliki alamat IP unik. Ukuran CIDR sesuai dengan jumlah maksimum pod per node. Tabel berikut berisi daftar 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 limit (2^(23-16))=128 node. Jika Anda ingin mengembangkan cluster di luar batas ini, Anda dapat meningkatkan nilai clusterNetwork.pods.cidrBlocks atau turunkan 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 Lapisan 2 konektivitas, sementara koneksi lainnya, termasuk worker node, hanya memerlukan Konektivitas Lapisan 3.
File konfigurasi menentukan alamat IP untuk kumpulan node pekerja. File konfigurasi juga menentukan VIP untuk tujuan:
- 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 penggunaan port UDP dan TCP oleh Kubernetes komponen pada node cluster dan load balancer.

Node bidang kontrol

Versi 1.29

Protokol	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	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 mandiri dan kontrol
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	Container inti GKE Identity Service diikat ke port melalui `hostPort` (berlaku untuk versi 1.29 dan yang lebih tinggi)	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 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	8444	Container inti GKE Identity Service diikat 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 mandiri dan kontrol
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 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 (berlaku untuk versi 1.16 dan yang lebih tinggi)	`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 (Port ini persyaratan 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

Protokol	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 (Port ini persyaratan 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.29

Protokol	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	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 mandiri dan kontrol
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 update 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 mandiri dan kontrol
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 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

Protokol	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

Node load balancer

Versi 1.29

Protokol	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 cluster file konfigurasi 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 pemroses untuk metrik HAProxy (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih tinggi)	Semua
TCP	Masuk	11001	Port pemroses untuk GKE Identity Service (tidak dapat diubah) (berlaku untuk versi 1.29 dan yang lebih tinggi)	Semua

Versi 1.28

Protokol	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 cluster file konfigurasi 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 pemroses 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 update node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi di cluster file konfigurasi 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 update node cluster pengguna	Node cluster admin
TCP	Masuk	443	Pengelolaan cluster Port ini dapat dikonfigurasi di cluster file konfigurasi 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 mencakup hal-hal berikut porta untuk berkomunikasi dengan cluster admin.

Protokol	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 UDP dan TCP port yang digunakan oleh bidang kontrol, worker, dan node load balancer seperti yang dijelaskan dalam Penggunaan port di halaman ini. Contoh konfigurasi berikut menunjukkan cara membuka port dengan firewall-cmd, command line firewall utilitas. Anda harus menjalankan perintah sebagai pengguna root.

Konfigurasi contoh node bidang kontrol

Blok perintah berikut menunjukkan contoh cara membuka perintah yang diperlukan porta 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 porta tertentu bagi versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Memperbarui contoh perintah sebagaimana mestinya.

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

Konfigurasi contoh node pekerja

Blok perintah berikut menunjukkan contoh cara membuka perintah yang diperlukan port 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 porta tertentu bagi versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Memperbarui contoh perintah sebagaimana mestinya.

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

Konfigurasi contoh node load balancer

Blok perintah berikut menunjukkan contoh cara membuka perintah yang diperlukan port 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 porta tertentu bagi versi cluster yang ingin Anda gunakan, lihat bagian Penggunaan port sebelumnya. Memperbarui contoh perintah sebagaimana mestinya.

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

Konfirmasi konfigurasi port

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

Jalankan perintah Network Mapper berikut untuk melihat port mana yang terbuka:
```
nmap localhost
```

Jalankan perintah berikut untuk mendapatkan setelan konfigurasi firewall:

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

Jika perlu, jalankan kembali perintah dari bagian sebelumnya untuk mengonfigurasi {i>node <i}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 Cilium iptables banyak rantai pada jaringan {i>host<i}. Rantai iptables ditambahkan oleh Pod anetd sejak dimulai. Hilangnya rantai iptables Cilium menyebabkan Pod di {i>Node<i} untuk kehilangan konektivitas jaringan di luar {i>Node<i}.

Perubahan pada firewalld yang menghapus rantai iptables disertakan, 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 pada Node:

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.