Ringkasan jaringan

Autopilot Standard

---

Halaman ini menyediakan panduan untuk aspek utama jaringan Google Kubernetes Engine (GKE). Informasi ini berguna bagi pengguna yang baru mulai menggunakan Kubernetes, serta operator cluster atau developer aplikasi berpengalaman yang memerlukan lebih banyak pengetahuan mengenai jaringan Kubernetes agar dapat mendesain aplikasi dengan lebih baik atau mengonfigurasi workload Kubernetes.

Kubernetes memungkinkan Anda menentukan secara deklaratif cara aplikasi di-deploy, cara aplikasi berkomunikasi satu sama lain dan dengan bidang kontrol Kubernetes, serta cara klien dapat menjangkau aplikasi Anda. Halaman ini juga memberikan informasi tentang cara GKE mengonfigurasi layanan Google Cloud, yang relevan dengan jaringan.

Saat Anda menggunakan Kubernetes untuk mengatur aplikasi, penting untuk mengubah cara berpikir Anda tentang desain jaringan aplikasi dan host-nya. Dengan Kubernetes, Anda memikirkan cara Pod, Service, dan klien eksternal berkomunikasi, daripada memikirkan cara host atau mesin virtual (VM) Anda terhubung.

Software-defined networking (SDN) canggih Kubernetes memungkinkan pemilihan rute dan penerusan paket untuk Pod, Service, dan node di berbagai zona dalam cluster regional yang sama. Kubernetes dan Google Cloud juga secara dinamis mengonfigurasi aturan pemfilteran IP, tabel perutean, dan aturan firewall pada setiap node, bergantung pada model deklaratif deployment Kubernetes dan konfigurasi cluster Anda di Google Cloud.

Peringatan: Jangan melakukan perubahan secara manual pada node karena node akan diganti oleh GKE, dan cluster Anda mungkin tidak berfungsi dengan benar. Satu-satunya alasan untuk mengakses node secara langsung adalah untuk men-debug masalah pada konfigurasi Anda.

Prasyarat

Halaman ini menggunakan terminologi yang terkait dengan lapisan Transpor, Internet, dan Application dari suite Internet protocol, termasuk HTTP, dan DNS, tetapi Anda tidak perlu menjadi ahli dalam topik ini.

Selain itu, konten ini mungkin lebih mudah dipahami jika memiliki pemahaman dasar tentang konsep dan utilitas pengelolaan jaringan Linux seperti aturan dan perutean iptables.

Terminologi yang terkait dengan alamat IP di Kubernetes

Model jaringan Kubernetes sangat bergantung pada alamat IP. Service, Pod, container, dan node berkomunikasi menggunakan alamat IP dan port. Kubernetes menyediakan berbagai jenis load balancing untuk mengarahkan traffic ke Pod yang tepat. Semua mekanisme ini akan dijelaskan secara lebih mendetail nanti. Perhatikan istilah-istilah berikut saat Anda membaca:

• ClusterIP: Alamat IP yang ditetapkan ke Service. Dalam dokumen lain, ini mungkin disebut "Cluster IP". Alamat ini stabil selama masa aktif Layanan, seperti yang dibahas dalam Layanan.
• Alamat IP Pod: Alamat IP yang ditetapkan ke Pod tertentu. Ini bersifat sementara, seperti yang dibahas di Pod.
• Alamat IP node: Alamat IP yang ditetapkan ke node tertentu.

Persyaratan jaringan cluster

Cluster publik dan pribadi memerlukan konektivitas ke *.googleapis.com, *.gcr.io, dan alamat IP bidang kontrol. Persyaratan ini dipenuhi dengan aturan izinkan egress dan aturan firewall yang dibuat otomatis yang dibuat oleh GKE.

Untuk cluster publik, jika menambahkan aturan firewall yang menolak traffic keluar dengan prioritas lebih tinggi, Anda harus membuat aturan firewall untuk mengizinkan *.googleapis.com, *.gcr.io, dan alamat IP bidang kontrol.

Untuk mengetahui informasi selengkapnya tentang persyaratan cluster pribadi, lihat Persyaratan dan batasan

Jaringan di dalam cluster

Bagian ini membahas jaringan dalam cluster Kubernetes, yang berkaitan dengan alokasi IP, Pod, Service, DNS, dan bidang kontrol.

Alokasi IP

Kubernetes menggunakan berbagai rentang IP untuk menetapkan alamat IP ke node, Pod, dan Service.

• Setiap node memiliki alamat IP yang ditetapkan dari jaringan Virtual Private Cloud (VPC) cluster. IP node ini menyediakan konektivitas dari komponen kontrol seperti kube-proxy dan kubelet ke server Kubernetes API. Alamat IP ini adalah koneksi node ke cluster lainnya.
• Setiap node memiliki sekumpulan alamat IP yang akan ditetapkan oleh GKE kepada Pod yang berjalan di node tersebut (blok CIDR/24 secara default). Secara opsional, Anda dapat menentukan rentang IP saat membuat cluster. Fitur rentang CIDR Pod Fleksibel memungkinkan Anda mengurangi ukuran rentang alamat IP Pod untuk node dalam kumpulan node.

Catatan: Untuk cluster Standar, Anda dapat menjalankan maksimum 256 Pod pada sebuah node dengan rentang /23, bukan 512 seperti yang mungkin Anda harapkan. Hal ini menyediakan buffer sehingga Pod tidak menjadi tidak dapat dijadwalkan karena kurangnya alamat IP untuk sementara dalam rentang alamat IP Pod untuk node tertentu. Untuk semua rentang, jumlah Pod yang dapat dijadwalkan sebagai alamat IP dalam rentang maksimal setengahnya. Cluster Autopilot dapat menjalankan maksimum 32 Pod per node.

• Setiap Pod memiliki satu alamat IP yang ditetapkan dari rentang CIDR Pod dari node-nya. Alamat IP ini digunakan bersama oleh semua container yang berjalan di dalam Pod, dan menghubungkannya ke Pod lain yang berjalan di cluster.
• Setiap Service memiliki alamat IP, yang disebut ClusterIP, yang ditetapkan dari jaringan VPC cluster. Secara opsional, Anda dapat menyesuaikan jaringan VPC saat membuat cluster.
• Setiap bidang kontrol memiliki alamat IP publik atau internal berdasarkan jenis cluster, versi, dan tanggal pembuatan. Untuk informasi selengkapnya, lihat deskripsi bidang kontrol.

Model jaringan GKE tidak mengizinkan alamat IP digunakan kembali di seluruh jaringan. Saat bermigrasi ke GKE, Anda harus merencanakan alokasi alamat IP untuk Mengurangi penggunaan alamat IP internal di GKE.

MTU

MTU yang dipilih untuk antarmuka Pod bergantung pada Antarmuka Jaringan Container (CNI) yang digunakan oleh Node cluster dan setelan MTU VPC yang mendasarinya. Untuk mengetahui informasi selengkapnya, lihat Pod.

Autopilot dikonfigurasi untuk selalu mewarisi MTU VPC.

Nilai MTU antarmuka Pod adalah 1460 atau diwarisi dari antarmuka utama Node.

CNI	MTU	GKE Standard
kubenet	1460	Default
kubenet (GKE versi 1.26.1 dan yang lebih baru)	Diwarisi	Default
Calico	1460	Diaktifkan menggunakan --enable-network-policy. Untuk mengetahui detailnya, silakan melihat Mengontrol komunikasi antara Pod dan Layanan menggunakan kebijakan jaringan.
netd	Diwarisi	Diaktifkan menggunakan salah satu opsi berikut: Visibilitas intranode Workload Identity Federation untuk GKE Jaringan stack ganda IPv4/IPv6
GKE Dataplane V2	Diwarisi	Diaktifkan menggunakan --enable-dataplane-v2. Untuk mengetahui detailnya, lihat Menggunakan GKE Dataplane V2.

Untuk mengetahui informasi lebih lanjut, lihat cluster VPC native.

Pod

Di Kubernetes, Pod adalah unit paling dasar yang dapat di-deploy dalam cluster Kubernetes. Sebuah Pod menjalankan satu container atau lebih. Nol atau beberapa Pod berjalan di satu node. Setiap node dalam cluster adalah bagian dari kumpulan node.

Di GKE, node ini adalah mesin virtual, masing-masing berjalan sebagai instance di Compute Engine.

Pod juga dapat terpasang ke volume penyimpanan eksternal dan resource kustom lainnya. Diagram ini menunjukkan satu node yang menjalankan dua Pod, masing-masing dipasang ke dua volume.

Saat Kubernetes menjadwalkan Pod untuk berjalan di sebuah node, Kubernetes akan membuat namespace jaringan untuk Pod tersebut di kernel Linux node. Namespace jaringan ini menghubungkan antarmuka jaringan fisik node, seperti eth0, dengan Pod menggunakan antarmuka jaringan virtual, sehingga paket dapat mengalir ke dan dari Pod. Antarmuka jaringan virtual terkait dalam namespace jaringan root node terhubung ke jembatan Linux yang memungkinkan komunikasi antar-Pod pada node yang sama. Pod juga dapat mengirim paket di luar node menggunakan antarmuka virtual yang sama.

Kubernetes menetapkan alamat IP (alamat IP Pod) ke antarmuka jaringan virtual di namespace jaringan Pod dari rentang alamat yang dicadangkan untuk Pod pada node tersebut. Rentang alamat IP ini adalah subset rentang alamat IP yang ditetapkan ke cluster untuk Pod, yang dapat Anda konfigurasi saat membuat cluster.p

Container yang berjalan di dalam Pod menggunakan namespace jaringan Pod. Dari sudut pandang container, Pod tampak seperti mesin fisik dengan satu antarmuka jaringan. Semua container dalam Pod melihat antarmuka jaringan yang sama ini. Setiap localhost container terhubung, melalui Pod, ke antarmuka jaringan fisik node, seperti eth0.

Perlu diperhatikan bahwa konektivitas ini sangat berbeda, bergantung pada apakah Anda menggunakan Antarmuka Jaringan Container (CNI) GKE atau memilih untuk menggunakan implementasi Calico dengan mengaktifkan Kebijakan jaringan saat membuat cluster.

• Jika Anda menggunakan CNI GKE, salah satu ujung pasangan Virtual Ethernet Device (veth) terpasang ke Pod dalam namespace-nya, dan ujung lainnya terhubung ke perangkat bridge Linux cbr0.¹ Dalam hal ini, perintah berikut menunjukkan berbagai alamat MAC Pod yang dilampirkan ke cbr0:

  arp -n
  

  Menjalankan perintah berikut dalam container toolbox akan menunjukkan akhir namespace root setiap pasangan veth yang dipasang ke cbr0:

  brctl show cbr0
  

• Jika Kebijakan Jaringan diaktifkan, salah satu ujung pasangan veth akan dilampirkan ke Pod dan ujung lainnya ke eth0. Dalam hal ini, perintah berikut menunjukkan berbagai alamat MAC Pod yang terpasang ke perangkat Veth yang berbeda:

  arp -n
  

  Menjalankan perintah berikut di container toolbox akan menunjukkan bahwa tidak ada perangkat bridge Linux bernama cbr0:

  brctl show
  

Aturan iptable yang memfasilitasi penerusan dalam cluster berbeda dari satu skenario ke skenario lainnya. Perhatikan perbedaan ini selama pemecahan masalah konektivitas secara terperinci.

Secara default, setiap Pod memiliki akses tanpa filter ke semua Pod lain yang berjalan di semua node cluster, tetapi Anda dapat membatasi akses di antara Pod. Kubernetes secara rutin menghancurkan dan membuat ulang Pod. Hal ini terjadi saat node pool diupgrade, mengubah konfigurasi deklaratif Pod atau mengubah image container, atau saat node menjadi tidak tersedia. Oleh karena itu, alamat IP Pod merupakan detail implementasi, dan Anda tidak boleh mengandalkannya. Kubernetes menyediakan alamat IP stabil menggunakan Service.

1. Jembatan jaringan virtual cbr0 hanya dibuat jika ada Pod yang menetapkan hostNetwork: false.↩

Perbankan & Keuangan

Di Kubernetes, Anda dapat menetapkan key-value pair arbitrer yang disebut label ke resource Kubernetes mana pun. Kubernetes menggunakan label untuk mengelompokkan beberapa Pod terkait ke dalam satu unit logis yang disebut Service. Service memiliki alamat IP dan port yang stabil, dan menyediakan load balancing di antara kumpulan Pod yang labelnya cocok dengan semua label yang Anda tentukan di pemilih label saat Anda membuat Service.

Catatan: Service di Kubernetes sepenuhnya tidak terkait dengan layanan di Docker. Service Docker lebih dekat dengan Pod Kubernetes.

Diagram berikut menunjukkan dua Service terpisah, yang masing-masing terdiri dari beberapa Pod. Setiap Pod dalam diagram memiliki label app=demo, tetapi label lainnya berbeda. "frontend" layanan cocok dengan semua Pod dengan app=demo dan component=frontend, sedangkan "pengguna" Service cocok dengan semua Pod dengan app=demo dan component=users. Pod Klien tidak sama persis dengan salah satu pemilih Service, sehingga bukan merupakan bagian dari kedua Service tersebut. Namun, Pod Klien dapat berkomunikasi dengan salah satu Service karena berjalan di cluster yang sama.

Kubernetes menetapkan alamat IP yang stabil dan andal ke setiap Service yang baru dibuat (ClusterIP) dari kumpulan alamat IP Service yang tersedia di cluster singkat ini. Kubernetes juga menetapkan nama host ke ClusterIP, dengan menambahkan entri DNS. ClusterIP dan nama host bersifat unik di dalam cluster dan tidak berubah di sepanjang siklus proses Layanan. Kubernetes hanya merilis ClusterIP dan nama host jika Service dihapus dari konfigurasi cluster. Anda dapat menjangkau Pod sehat yang menjalankan aplikasi Anda menggunakan ClusterIP atau nama host Service.

ekilas, Service mungkin tampak sebagai titik tunggal kegagalan untuk aplikasi Anda. Namun, Kubernetes mendistribusikan traffic secara merata di seluruh kumpulan Pod lengkap, yang berjalan di banyak node, sehingga cluster dapat menahan pemadaman yang memengaruhi satu atau beberapa (tetapi tidak semua) node.

Proxy Kube

Kubernetes mengelola konektivitas antara Pod dan Layanan menggunakan komponen kube-proxy, yang biasanya berjalan sebagai Pod statis pada setiap node.

kube-proxy, yang bukan proxy inline, melainkan pengontrol load balancing berbasis traffic keluar, mengawasi server Kubernetes API dan terus memetakan ClusterIP ke Pod yang sehat dengan menambahkan dan menghapus aturan NAT (DNAT) tujuan ke subsistem iptables node. Saat container yang berjalan di Pod mengirim traffic ke ClusterIP Service, node akan memilih Pod secara acak dan mengarahkan traffic ke Pod tersebut.

Saat mengonfigurasi Service, Anda dapat memilih untuk memetakan ulang port pemrosesnya dengan menentukan nilai untuk port dan targetPort.

• port adalah tempat klien menjangkau aplikasi.
• targetPort adalah port tempat aplikasi benar-benar memproses traffic dalam Pod.

kube-proxy mengelola pemetaan ulang port ini dengan menambahkan dan menghapus aturan iptables pada node.

Cara kube-proxy di-deploy bergantung pada versi GKE cluster:

• Untuk GKE versi 1.16.0 dan 1.16.8-gke.13, kube-proxy di-deploy sebagai DaemonSet.
• Untuk versi GKE yang lebih baru dari 1.16.8-gke.13, kube-proxy di-deploy sebagai Pod statis untuk node.

DNS

GKE menyediakan opsi DNS cluster terkelola berikut ini untuk me-resolve nama layanan dan nama eksternal:

• kube-dns: add-on cluster yang di-deploy secara default di semua cluster GKE. Untuk informasi selengkapnya, lihat Menggunakan kube-dns.

• Cloud DNS: infrastruktur DNS cluster yang dikelola cloud yang menggantikan kube-dns di dalam cluster. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Cloud DNS untuk GKE.

GKE juga menyediakan NodeLocal DNSCache sebagai add-on opsional dengan kube-dns atau Cloud DNS untuk meningkatkan performa DNS cluster.

Untuk mempelajari lebih lanjut cara GKE menyediakan DNS, lihat Penemuan layanan dan DNS.

Bidang kontrol

Di Kubernetes, bidang kontrol mengelola proses bidang kontrol, termasuk server Kubernetes API. Cara mengakses bidang kontrol bergantung pada versi cluster GKE Autopilot atau Standard.

Cluster dengan Private Service Connect

Cluster pribadi atau publik yang memenuhi salah satu kondisi berikut, menggunakan Private Service Connect untuk menghubungkan node dan bidang kontrol secara pribadi:

• Cluster publik baru dalam versi 1.23 pada atau setelah 15 Maret 2022.
• Cluster pribadi baru dalam versi 1.29 setelah 28 Januari 2024.

Cluster publik yang sudah ada dan tidak memenuhi kondisi sebelumnya sedang dimigrasikan ke Private Service Connect. Oleh karena itu, cluster ini mungkin sudah menggunakan Private Service Connect. Untuk memeriksa apakah cluster Anda menggunakan Private Service Connect, jalankan perintah gcloud container clusters describe. Jika cluster publik Anda menggunakan Private Service Connect, resource privateClusterConfig memiliki nilai berikut:

• Kolom peeringName kosong atau tidak ada.
• Kolom privateEndpoint memiliki nilai yang ditetapkan.

Namun, cluster pribadi yang sudah ada yang tidak memenuhi kondisi sebelumnya belum dimigrasikan.

Anda dapat membuat cluster yang menggunakan Private Service Connect dan mengubah isolasi cluster.

Gunakan jaringan yang diizinkan untuk restrict akses ke bidang kontrol cluster Anda dengan menentukan origin yang dapat menjangkau bidang kontrol.

Peringatan: Cluster publik dengan Private Service Connect yang dibuat sebelum 30 Januari 2022 menggunakan endpoint dan aturan penerusan Private Service Connect. Kedua resource diberi nama gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe dan mengizinkan bidang kontrol dan node untuk terhubung secara pribadi. GKE membuat resource ini secara otomatis tanpa biaya. Jika resource ini dihapus, masalah jaringan cluster, termasuk periode nonaktif, akan terjadi.

Jaringan di luar cluster

Bagian ini menjelaskan bagaimana traffic dari luar cluster menjangkau aplikasi yang berjalan di dalam cluster Kubernetes. Informasi ini penting saat mendesain aplikasi dan workload cluster Anda.

Anda sudah membaca cara Kubernetes menggunakan Service untuk menyediakan alamat IP stabil bagi aplikasi yang berjalan dalam Pod. Secara default, Pod tidak mengekspos alamat IP eksternal karena kube-proxy mengelola semua traffic di setiap node. Pod dan container-nya dapat berkomunikasi dengan bebas, tetapi koneksi di luar cluster tidak dapat mengakses Service. Misalnya, dalam ilustrasi sebelumnya, klien di luar cluster tidak dapat mengakses Layanan frontend menggunakan ClusterIP-nya.

GKE menyediakan tiga jenis load balancer untuk mengontrol akses dan menyebarkan traffic yang masuk di seluruh cluster Anda secara merata. Anda dapat mengonfigurasi satu Service untuk menggunakan beberapa jenis load balancer secara bersamaan.

• Load balancer eksternal mengelola traffic yang berasal dari luar cluster dan di luar jaringan VPC Google Cloud Anda. Mereka menggunakan aturan penerusan yang terkait dengan jaringan Google Cloud untuk mengarahkan traffic ke node Kubernetes.
• Load balancer internal mengelola traffic yang berasal dari dalam jaringan VPC yang sama. Seperti load balancer eksternal, load balancer menggunakan aturan penerusan yang terkait dengan jaringan Google Cloud untuk merutekan traffic ke node Kubernetes.
• Load Balancer Aplikasi adalah load balancer eksternal khusus yang digunakan untuk traffic HTTP(S). Solusi ini menggunakan resource Ingress, bukan aturan penerusan, untuk mengarahkan traffic ke node Kubernetes.

Saat mencapai node Kubernetes, traffic akan ditangani dengan cara yang sama, terlepas dari jenis load balancer. Load balancer tidak mengetahui node mana dalam cluster yang menjalankan Pod untuk Servicenya. Sebagai gantinya, platform ini akan menyeimbangkan traffic di semua node dalam cluster, bahkan yang tidak menjalankan Pod yang relevan. Pada cluster regional, beban didistribusikan ke seluruh node di semua zona untuk region cluster. Saat traffic dirutekan ke sebuah node, node tersebut akan mengarahkan traffic ke Pod, yang mungkin berjalan di node yang sama atau node yang berbeda. Node meneruskan traffic ke Pod yang dipilih secara acak menggunakan aturan iptables yang dikelola kube-proxy pada node.

Saat load balancer mengirimkan traffic ke sebuah node, traffic tersebut mungkin akan diteruskan ke Pod di node yang berbeda. Hal ini memerlukan hop jaringan tambahan. Jika ingin menghindari hop tambahan, Anda dapat menentukan bahwa traffic harus mengarah ke Pod yang berada di node yang sama dengan yang awalnya menerima traffic.

Untuk menentukan bahwa traffic harus mengarah ke Pod pada node yang sama, tetapkan externalTrafficPolicy ke Local dalam manifes Service Anda:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: demo
    component: users
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Saat Anda menetapkan externalTrafficPolicy ke Local, load balancer hanya akan mengirimkan traffic ke node yang memiliki Pod responsif yang dimiliki oleh Service. Load balancer menggunakan health check untuk menentukan node mana yang memiliki Pod yang sesuai.

Load balancer eksternal

Jika Service harus dapat dijangkau dari luar cluster dan di luar jaringan VPC, Anda dapat mengonfigurasi Service sebagai LoadBalancer, dengan menetapkan type Service ke Loadbalancer saat menentukan Service. GKE kemudian menyediakan Load Balancer Jaringan passthrough eksternal di depan Service. Load Balancer Jaringan passthrough eksternal mengetahui semua node di cluster Anda dan mengonfigurasi aturan firewall jaringan VPC Anda guna mengizinkan koneksi ke Service dari luar jaringan VPC, menggunakan alamat IP eksternal Service. Anda dapat menetapkan alamat IP eksternal statis ke Service.

Untuk mempelajari aturan firewall lebih lanjut, lihat Aturan firewall yang dibuat secara otomatis.

Detail teknis

Saat menggunakan load balancer eksternal, traffic yang tiba awalnya dirutekan ke node menggunakan aturan penerusan yang terkait dengan jaringan Google Cloud. Setelah traffic mencapai node, node akan menggunakan tabel NAT iptables untuk memilih Pod. kube-proxy mengelola aturan iptables pada node.

Load balancer internal

Untuk traffic yang perlu menjangkau cluster Anda dari dalam jaringan VPC yang sama, Anda dapat mengonfigurasi Service untuk menyediakan Load Balancer Jaringan passthrough internal. Load Balancer Jaringan passthrough internal memilih alamat IP dari subnet VPC cluster Anda, bukan alamat IP eksternal. Aplikasi atau layanan dalam jaringan VPC dapat menggunakan alamat IP ini untuk berkomunikasi dengan Service di dalam cluster.

Detail teknis

Load balancing internal disediakan oleh Google Cloud. Saat traffic mencapai node tertentu, node tersebut akan menggunakan tabel NAT iptables untuk memilih Pod, meskipun Pod berada di node yang berbeda. kube-proxy mengelola aturan iptables pada node.

Untuk mengetahui informasi selengkapnya tentang load balancer internal, lihat Menggunakan Load Balancer Jaringan passthrough internal.

Load Balancer Aplikasi

Banyak aplikasi, seperti API layanan web RESTful, berkomunikasi menggunakan HTTP(S). Anda dapat mengizinkan klien di luar jaringan VPC Anda untuk mengakses jenis aplikasi ini menggunakan Ingress Kubernetes.

Ingress memungkinkan Anda memetakan nama host dan jalur URL ke Layanan dalam cluster. Saat menggunakan Load Balancer Aplikasi, Anda harus mengonfigurasi Layanan agar dapat menggunakan NodePort, serta ClusterIP. Saat traffic mengakses Service pada IP node di NodePort, GKE mengarahkan traffic ke Pod yang responsif untuk Service. Anda dapat menentukan NodePort atau mengizinkan GKE untuk menetapkan port acak yang tidak digunakan.

Saat Anda membuat resource Ingress, GKE akan menyediakan Load Balancer Aplikasi eksternal dalam project Google Cloud. Load balancer mengirimkan permintaan ke alamat IP node di NodePort. Setelah permintaan mencapai node, node akan menggunakan tabel NAT iptables untuk memilih Pod. kube-proxy mengelola aturan iptables pada node.

Definisi Ingress ini merutekan traffic untuk demo.example.com ke Service bernama frontend pada port 80, dan demo-backend.example.com ke Service bernama users pada port 8080.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 80
  - host: demo-backend.example.com
    http:
      paths:
      - backend:
          service:
            name: users
            port:
              number: 8080

Buka GKE Ingress untuk Load Balancer Aplikasi untuk mengetahui informasi selengkapnya.

Detail teknis

Saat Anda membuat objek Ingress, pengontrol GKE Ingress mengonfigurasi Load Balancer Aplikasi sesuai dengan aturan dalam manifes Ingress dan manifes Layanan terkait. Klien mengirimkan permintaan ke Load Balancer Aplikasi. Load balancer adalah proxy yang sebenarnya; metode tersebut memilih sebuah node dan meneruskan permintaan ke kombinasi NodeIP:NodePort node tersebut. Node menggunakan tabel NAT iptables untuk memilih Pod. kube-proxy mengelola aturan iptables pada node.

Membatasi konektivitas antar-node

Membuat aturan firewall masuk atau keluar yang menargetkan node di cluster Anda mungkin memiliki efek yang buruk. Misalnya, menerapkan aturan penolakan traffic keluar ke node di cluster Anda dapat merusak fitur seperti NodePort dan kubectl exec.

Membatasi konektivitas ke Pod dan Service

Secara default, semua Pod yang berjalan dalam cluster yang sama dapat berkomunikasi dengan bebas. Namun, Anda dapat membatasi konektivitas dalam cluster dengan cara yang berbeda, bergantung pada kebutuhan Anda.

Membatasi akses di antara Pod

Anda dapat membatasi akses di antara Pod menggunakan kebijakan jaringan. Definisi kebijakan jaringan memungkinkan Anda membatasi ingress dan egress dari Pod berdasarkan kombinasi arbitrer dari label, rentang IP, dan nomor port.

Secara default, tidak ada kebijakan jaringan, sehingga semua traffic di antara Pod dalam cluster diizinkan. Segera setelah Anda membuat kebijakan jaringan pertama di namespace, semua traffic lainnya akan ditolak.

Setelah membuat kebijakan jaringan, Anda harus mengaktifkannya secara eksplisit untuk cluster. Untuk informasi selengkapnya, lihat Mengonfigurasi kebijakan jaringan untuk aplikasi.

Membatasi akses ke load balancer eksternal

Jika Service Anda menggunakan load balancer eksternal, traffic dari alamat IP eksternal mana pun dapat mengakses Service Anda secara default. Anda dapat membatasi rentang alamat IP yang dapat mengakses endpoint dalam cluster dengan mengonfigurasi opsi loadBalancerSourceRanges saat mengonfigurasi Service. Anda dapat menentukan beberapa rentang, dan memperbarui konfigurasi Service yang berjalan kapan saja. Instance kube-proxy yang berjalan pada setiap node mengonfigurasi aturan iptables node tersebut untuk menolak semua traffic yang tidak cocok dengan loadBalancerSourceRanges yang ditentukan. Tidak ada aturan firewall VPC yang dibuat.

Membatasi akses ke Load Balancer Aplikasi

Jika layanan Anda menggunakan Load Balancer Aplikasi, Anda dapat menggunakan kebijakan keamanan Google Cloud Armor untuk membatasi alamat IP eksternal yang dapat mengakses Layanan dan respons mana yang akan ditampilkan saat akses ditolak karena kebijakan keamanan. Anda dapat mengonfigurasi Cloud Logging untuk mencatat informasi tentang interaksi ini.

Jika kebijakan keamanan Google Cloud Armor tidak cukup mendetail, Anda dapat mengaktifkan Identity-Aware Proxy di endpoint untuk menerapkan autentikasi dan otorisasi berbasis pengguna untuk aplikasi Anda. Untuk mengetahui informasi selengkapnya, buka tutorial mendetail untuk mengonfigurasi IAP.

Masalah umum

Bagian ini membahas masalah umum.

Node dengan container yang diaktifkan tidak dapat terhubung ke rentang 172.17/16

VM node dengan containerd diaktifkan tidak dapat terhubung ke host yang memiliki IP dalam 172.17/16. Untuk informasi selengkapnya, lihat Konflik dengan rentang alamat IP 172.17/16.

Langkah selanjutnya

• Pelajari Service.
• Pelajari Pod.
• Menyiapkan cluster dengan VPC Bersama.