Halaman ini diterjemahkan oleh Cloud Translation API.

Membandingkan model jaringan di GKE

Autopilot Standard

Dokumen ini menjelaskan model jaringan yang digunakan oleh Google Kubernetes Engine (GKE) dan perbedaannya dengan model jaringan di lingkungan Kubernetes lainnya. Dokumen ini mencakup konsep berikut:

Model jaringan paling umum yang digunakan oleh berbagai implementasi Kubernetes.
Mekanisme penentuan alamat IP dari model jaringan yang paling umum.
Kelebihan dan kekurangan yang dihadirkan oleh setiap model jaringan.
Deskripsi terperinci tentang model jaringan default yang digunakan GKE.

Dokumen ini ditujukan untuk arsitek cloud, engineer operasi, dan engineer jaringan yang mungkin familier dengan implementasi Kubernetes lainnya dan berencana menggunakan GKE. Dokumen ini mengasumsikan bahwa Anda sudah memahami Kubernetes dan model jaringan dasarnya. Anda juga harus memahami konsep jaringan seperti pemberian alamat IP, penafsiran alamat jaringan (NAT), firewall, dan proxy.

Dokumen ini tidak membahas cara memodifikasi model jaringan GKE default untuk memenuhi berbagai batasan alamat IP. Jika Anda kekurangan alamat IP saat bermigrasi ke GKE, lihat strategi pengelolaan alamat IP saat bermigrasi ke GKE.

Implementasi model jaringan umum

Anda dapat mengimplementasikan model jaringan Kubernetes dengan berbagai cara. Namun, implementasi apa pun harus selalu memenuhi persyaratan berikut:

Setiap Pod memerlukan alamat IP yang unik.
Pod dapat berkomunikasi dengan Pod lain di semua node tanpa menggunakan NAT.
Agen pada node, seperti kubelet, dapat berkomunikasi dengan semua Pod di node tersebut.
Pod di jaringan host node dapat berkomunikasi dengan semua Pod di semua node tanpa menggunakan NAT.

Ada lebih dari 20 implementasi yang berbeda untuk model jaringan Kubernetes yang dikembangkan untuk memenuhi persyaratan ini.

Implementasi ini dapat dikelompokkan ke dalam tiga jenis model jaringan. Ketiga model ini berbeda dalam hal berikut:

Cara Pod berkomunikasi dengan layanan non-Kubernetes di jaringan perusahaan.
Cara Pod berkomunikasi dengan cluster Kubernetes lainnya di organisasi yang sama.
Apakah NAT diperlukan untuk komunikasi di luar cluster atau tidak.
Apakah alamat IP Pod dapat digunakan kembali di cluster lain atau di tempat lain di jaringan perusahaan atau tidak.

Setiap penyedia cloud telah mengimplementasikan satu atau beberapa jenis model ini.

Tabel berikut mengidentifikasi tiga jenis model yang umum digunakan, dan implementasi Kubernetes yang digunakan:

Nama model jaringan	Digunakan dalam implementasi ini
Terintegrasi penuh atau datar	GKE Amazon Elastic Kubernetes Service (EKS) Azure Kubernetes Service (AKS) saat menggunakan jaringan Azure CNI (lanjutan)
Mode pulau atau jembatan	Azure Kubernetes Service (AKS) saat menggunakan jaringan Kubenet (dasar) yang merupakan setelan default Oracle Container Engine for Kubernetes (OKE) Berbagai implementasi Kubernetes lokal
Terisolasi atau dengan air gap	Tidak biasa digunakan oleh implementasi Kubernetes, tetapi dapat digunakan dengan implementasi apa pun saat cluster di-deploy di jaringan terpisah atau virtual private cloud (VPC)

Ketika dokumen ini menjelaskan model jaringan, model ini mengacu pada efeknya pada jaringan lokal yang terhubung. Namun, Anda dapat menerapkan konsep yang dijelaskan untuk jaringan lokal yang terhubung ke jaringan yang terhubung melalui virtual private network (VPN) atau melalui interkoneksi pribadi, termasuk koneksi ke penyedia cloud lainnya. Untuk GKE, koneksi ini mencakup semua konektivitas melalui Cloud VPN atau Cloud Interconnect.

Model jaringan yang terintegrasi penuh

Model jaringan yang terintegrasi penuh (atau datar) menawarkan kemudahan komunikasi dengan aplikasi di luar Kubernetes dan di cluster Kubernetes lainnya. Penyedia layanan cloud utama umumnya mengimplementasikan model ini karena penyedia tersebut dapat mengintegrasikan implementasi Kubernetes mereka secara erat dengan software-defined network (SDN) mereka.

Saat menggunakan model yang terintegrasi penuh, alamat IP yang Anda gunakan untuk Pod akan dirutekan dalam jaringan tempat cluster Kubernetes berada. Selain itu, jaringan yang mendasarinya mengetahui node tempat alamat IP Pod berada. Dalam banyak penerapan, alamat IP Pod pada node yang sama berasal dari rentang alamat IP Pod khusus yang telah ditetapkan. Namun, rentang alamat yang telah ditetapkan bukanlah persyaratan.

Diagram berikut menunjukkan opsi komunikasi Pod dalam model jaringan yang terintegrasi penuh:

Diagram jaringan yang menunjukkan pola komunikasi dalam model jaringan yang terintegrasi penuh.

Diagram sebelumnya tentang model jaringan yang terintegrasi sepenuhnya menunjukkan pola komunikasi berikut:

Pod dalam cluster Kubernetes dapat saling berkomunikasi langsung.
Pod dapat berkomunikasi dengan Pod lain di cluster lainnya selama cluster tersebut berada dalam jaringan yang sama.
Pod tidak memerlukan NAT untuk berkomunikasi dengan aplikasi lain di luar cluster, terlepas dari apakah aplikasi tersebut berada di jaringan yang sama atau jaringan yang saling terhubung.

Diagram juga menunjukkan bahwa rentang alamat IP Pod berbeda-beda di antara cluster yang berbeda.

Model jaringan yang terintegrasi penuh tersedia dalam implementasi berikut:

Secara default, GKE mengimplementasikan model ini. Untuk informasi selengkapnya tentang implementasi ini, lihat model jaringan GKE nanti dalam dokumen ini.
Secara default, Amazon EKS mengimplementasikan model ini. Dalam implementasi ini, Amazon EKS menggunakan Amazon VPC Container Networking Interface (CNI) Plugin for Kubernetes guna menetapkan alamat IP Pod langsung dari ruang alamat VPC. Plugin CNI ini menetapkan alamat IP dari subnet default tempat node berada atau dari subnet kustom. Alamat IP pod tidak berasal dari rentang alamat IP Pod khusus per node.
Di Azure, AKS mengimplementasikan model ini saat menggunakan Azure CNI (jaringan lanjutan). Implementasi ini bukan konfigurasi default. Dalam implementasi ini, setiap Pod mendapatkan alamat IP dari subnet. Anda juga dapat mengonfigurasi jumlah maksimum Pod per node. Dengan demikian, jumlah alamat IP yang direservasi di awal untuk Pod pada node tersebut sama dengan jumlah maksimum Pod per node.

Penggunaan model jaringan yang terintegrasi sepenuhnya memberikan kelebihan berikut:

Data telemetri yang lebih baik. Alamat IP pod terlihat di seluruh jaringan. Visibilitas ini membuat data telemetri lebih berguna dibandingkan di model lain karena Pod dapat diidentifikasi, bahkan dari data telemetri yang dikumpulkan di luar cluster.
Konfigurasi firewall yang lebih mudah. Saat menetapkan aturan firewall, membedakan traffic node dan traffic Pod lebih mudah dilakukan di model jaringan yang terintegrasi penuh daripada pada model lainnya.
Kompatibilitas yang lebih baik. Pod dapat berkomunikasi menggunakan protokol yang tidak mendukung NAT.
Proses debug yang lebih baik. Jika diizinkan oleh firewall, resource di luar cluster dapat langsung menjangkau Pod selama proses debug.
Kompatibilitas dengan mesh layanan. Mesh layanan, seperti Istio atau Cloud Service Mesh, dapat berkomunikasi dengan mudah di seluruh cluster karena Pod dapat saling berkomunikasi secara langsung. Beberapa implementasi mesh layanan hanya mendukung konektivitas Pod ke Pod untuk mesh layanan multi-cluster.

Penggunaan model jaringan yang terintegrasi penuh memiliki kekurangan berikut:

Penggunaan alamat IP. Anda tidak dapat menggunakan kembali alamat IP Pod dalam jaringan, dan setiap alamat IP harus unik. Persyaratan ini dapat mengakibatkan ada banyak alamat IP yang perlu direservasi untuk Pod.
Persyaratan SDN. Model jaringan yang terintegrasi penuh memerlukan integrasi yang mendalam dengan jaringan yang mendasarinya karena implementasi Kubernetes perlu memprogram SDN secara langsung. Pemrograman SDN bersifat transparan bagi pengguna dan tidak menimbulkan kerugian bagi pengguna. Namun, model jaringan yang terintegrasi mendalam seperti itu tidak dapat diimplementasikan dengan mudah di lingkungan lokal yang dikelola sendiri.

Model jaringan mode pulau

Model jaringan mode pulau (atau jembatan) biasanya digunakan untuk implementasi Kubernetes lokal yang tidak memungkinkan integrasi mendalam dengan jaringan yang mendasarinya. Saat Anda menggunakan model jaringan mode pulau, Pod di cluster Kubernetes dapat berkomunikasi dengan resource di luar cluster melalui semacam gateway atau proxy.

Diagram berikut menunjukkan opsi komunikasi Pod dalam model jaringan mode pulau:

Diagram jaringan yang menunjukkan pola komunikasi dalam model jaringan mode pulau.

Diagram sebelumnya tentang model jaringan mode pulau menunjukkan cara Pod dalam cluster Kubernetes dapat saling berkomunikasi secara langsung. Diagram ini juga menunjukkan bahwa Pod dalam cluster perlu menggunakan gateway atau proxy saat berkomunikasi dengan aplikasi di luar cluster atau Pod dalam cluster lainnya. Meskipun komunikasi antara cluster dan aplikasi eksternal memerlukan satu gateway, komunikasi cluster ke cluster memerlukan dua gateway. Traffic antara dua cluster melewati satu gateway saat meninggalkan cluster pertama dan gateway lainnya saat memasuki cluster lain.

Ada berbagai cara untuk mengimplementasikan gateway atau proxy dalam model jaringan terisolasi. Implementasi berikut adalah dua gateway atau proxy yang paling umum:

Menggunakan node sebagai gateway. Implementasi ini biasa digunakan jika node di cluster adalah bagian dari jaringan yang sudah ada dan alamat IP-nya dapat dirutekan secara native dalam jaringan ini. Dalam hal ini, node itu sendiri adalah gateway yang menyediakan konektivitas dari dalam cluster ke jaringan yang lebih besar. Traffic keluar dari Pod ke luar cluster dapat diarahkan ke cluster lain atau ke aplikasi non-Kubernetes, misalnya untuk memanggil API lokal di jaringan perusahaan. Untuk traffic keluar ini, node yang berisi Pod menggunakan NAT sumber (SNAT) untuk memetakan alamat IP Pod ke alamat IP node. Untuk mengizinkan aplikasi di luar cluster berkomunikasi dengan Service di dalam cluster, Anda dapat menggunakan jenis layanan NodePort untuk sebagian besar implementasi. Dalam beberapa implementasi, Anda dapat menggunakan jenis layanan LoadBalancer untuk mengekspos Service. Saat menggunakan jenis layanan LoadBalancer, Anda memberi Service tersebut alamat IP virtual yang melakukan load balance antar-node dan dirutekan ke pod yang merupakan bagian dari Service.

Diagram berikut menunjukkan pola implementasi saat menggunakan node sebagai gateway:

Diagram sebelumnya menunjukkan bahwa penggunaan node sebagai gateway tidak memengaruhi komunikasi Pod ke Pod dalam cluster. Pod di dalam cluster masih saling berkomunikasi secara langsung. Namun, diagram juga menunjukkan pola komunikasi berikut di luar cluster:
- Cara Pod berkomunikasi dengan cluster lain atau aplikasi non-Kubernetes menggunakan SNAT saat meninggalkan node.
- Cara traffic dari luar Service di cluster lain atau aplikasi non-Kubernetes memasuki cluster melalui layanan NodePort sebelum diteruskan ke Pod yang benar dalam cluster tersebut.
Menggunakan virtual machine (VM) proxy dengan beberapa antarmuka jaringan. Pola implementasi ini menggunakan proxy untuk mengakses jaringan yang berisi cluster Kubernetes. Proxy harus memiliki akses ke ruang alamat IP Pod dan node. Dalam pola ini, setiap VM proxy memiliki dua antarmuka jaringan: satu antarmuka di jaringan perusahaan yang lebih besar dan satu antarmuka lagi di jaringan yang berisi cluster Kubernetes.

Diagram berikut menunjukkan pola implementasi saat menggunakan VM proxy:

Diagram sebelumnya menunjukkan bahwa penggunaan proxy dalam mode pulau tidak memengaruhi komunikasi dalam cluster. Pod di cluster masih dapat saling berkomunikasi secara langsung. Namun, diagram ini juga menunjukkan cara komunikasi dari Pod ke cluster lain atau aplikasi non-Kubernetes melalui proxy yang memiliki akses ke jaringan cluster dan ke jaringan tujuan. Selain itu, komunikasi yang masuk ke cluster dari luar juga akan melewati jenis proxy yang sama.

Model jaringan mode pulau tersedia dalam implementasi berikut:

Secara default, Azure Kubernetes Service (AKS) menggunakan jaringan mode pulau saat menggunakan jaringan Kubenet (dasar). Saat AKS menggunakan jaringan mode pulau, jaringan virtual yang berisi cluster hanya menyertakan alamat IP node. Alamat IP pod bukan bagian dari jaringan virtual. Sebagai gantinya, Pod menerima alamat IP dari ruang logis yang berbeda. Model mode pulau yang digunakan oleh AKS juga merutekan traffic Pod ke Pod antar-node menggunakan rute yang ditentukan pengguna dengan penerusan IP yang diaktifkan pada antarmuka node. Untuk komunikasi Pod ke resource di luar cluster, node menggunakan SNAT untuk memetakan alamat IP Pod ke alamat IP node sebelum traffic keluar meninggalkan node.
Di Oracle Container Engine for Kubernetes (OKE), komunikasi Pod ke Pod menggunakan jaringan overlay VXLAN. Selain itu, traffic dari Pod ke aplikasi di luar cluster menggunakan SNAT untuk memetakan alamat IP Pod ke alamat IP node.

Penggunaan model jaringan mode pulau memiliki kelebihan berikut:

Penggunaan alamat IP. Alamat IP pod di cluster dapat digunakan kembali di cluster lain. Namun, alamat IP yang sudah digunakan oleh layanan eksternal di jaringan perusahaan tidak dapat digunakan untuk Pod jika komunikasi perlu terjadi antara Pod dan layanan tersebut. Oleh karena itu, praktik terbaik untuk jaringan mode pulau adalah mereservasi ruang alamat IP Pod yang unik dalam jaringan, dan menggunakan ruang alamat IP ini untuk semua cluster.
Setelan keamanan yang lebih mudah. Karena Pod tidak terekspos secara langsung ke bagian lain jaringan perusahaan, Anda tidak perlu mengamankan Pod terhadap traffic masuk yang berasal dari bagian lain jaringan perusahaan.

Menggunakan model jaringan mode pulau memiliki kekurangan berikut:

Telemetri yang tidak akurat. Data telemetri yang dikumpulkan di luar cluster hanya berisi alamat IP node, bukan alamat IP Pod. Kurangnya alamat IP Pod akan mempersulit identifikasi sumber dan tujuan traffic.
Proses debug yang lebih sulit. Saat melakukan proses debug, Anda tidak dapat terhubung langsung ke Pod dari luar cluster.
Konfigurasi firewall yang lebih sulit. Anda hanya dapat menggunakan alamat IP node saat mengonfigurasi firewall. Dengan demikian, setelan firewall yang dihasilkan mengizinkan semua Pod di sebuah node dan node itu sendiri untuk menjangkau layanan di luar, atau tidak mengizinkan satu pun Pod untuk menjangkau layanan luar.
Kompatibilitas dengan mesh layanan. Dengan mode pulau, komunikasi langsung Pod ke Pod di seluruh cluster dalam mesh layanan, seperti Istio atau Cloud Service Mesh, tidak mungkin dilakukan.

Ada batasan lainnya terkait beberapa implementasi mesh layanan. Dukungan multi-cluster Cloud Service Mesh untuk cluster GKE di Google Cloud hanya mendukung cluster di jaringan yang sama. Untuk implementasi Istio yang mendukung model multi-jaringan, komunikasi harus dilakukan melalui Istio Gateways, yang membuat deployment mesh layanan multi-cluster lebih kompleks.

Model jaringan terisolasi

Model jaringan terisolasi (atau dengan air gap) paling sering digunakan untuk cluster yang tidak memerlukan akses ke jaringan perusahaan yang lebih besar, kecuali melalui API yang dapat dilihat publik. Saat Anda menggunakan model jaringan terisolasi, setiap cluster Kubernetes akan diisolasi dan tidak dapat menggunakan alamat IP internal untuk berkomunikasi dengan bagian jaringan lainnya. Cluster berada di jaringan pribadinya sendiri. Jika ada Pod dalam cluster yang perlu berkomunikasi dengan layanan di luar cluster, komunikasi ini harus menggunakan alamat IP publik untuk traffic masuk dan keluar.

Diagram berikut menunjukkan opsi komunikasi Pod dalam model jaringan terisolasi:

Diagram jaringan yang menunjukkan pola komunikasi dalam model jaringan terisolasi.

Diagram sebelumnya tentang model jaringan terisolasi menunjukkan bahwa Pod dalam cluster Kubernetes dapat saling berkomunikasi secara langsung. Diagram ini juga menunjukkan bahwa Pod tidak dapat menggunakan alamat IP internal untuk berkomunikasi dengan Pod di cluster lain. Selain itu, Pod dapat berkomunikasi dengan aplikasi di luar cluster hanya jika kriteria berikut terpenuhi:

Terdapat gateway internet yang menghubungkan cluster ke luar.
Aplikasi luar menggunakan alamat IP eksternal untuk komunikasi.

Terakhir, diagram menunjukkan bagaimana ruang alamat IP yang sama untuk Pod dan node dapat digunakan kembali di antara lingkungan yang berbeda.

Model jaringan terisolasi biasanya tidak digunakan oleh implementasi Kubernetes. Namun, Anda dapat memperoleh model jaringan terisolasi dalam implementasi apa pun. Anda hanya perlu men-deploy cluster Kubernetes di jaringan atau VPC yang terpisah tanpa konektivitas ke layanan lain atau jaringan perusahaan. Implementasi yang dihasilkan akan memiliki kelebihan dan kekurangan yang sama dengan model jaringan terisolasi.

Menggunakan mode jaringan terisolasi memiliki kelebihan berikut:

Penggunaan alamat IP. Anda dapat menggunakan kembali semua alamat IP internal di cluster: alamat IP node, alamat IP Service, dan alamat IP Pod. Penggunaan kembali alamat IP internal dapat dilakukan karena setiap cluster memiliki jaringan pribadinya sendiri dan komunikasi ke resource di luar cluster hanya terjadi melalui alamat IP publik.
Kontrol. Administrator cluster memiliki kontrol penuh atas alamat IP di cluster dan tidak perlu melakukan tugas pengelolaan alamat IP apa pun. Misalnya, administrator dapat mengalokasikan ruang alamat 10.0.0.0/8 penuh untuk Pod dan Service di cluster, meskipun alamat tersebut sudah digunakan di organisasi.
Keamanan. Komunikasi di luar cluster dikontrol secara ketat dan, jika diizinkan, menggunakan antarmuka eksternal dan NAT yang ditentukan dengan baik.

Menggunakan model jaringan terisolasi memiliki kekurangan berikut:

Tidak ada komunikasi pribadi. Komunikasi yang menggunakan alamat IP internal tidak diizinkan ke cluster lain atau layanan lain di jaringan.

Model jaringan GKE

GKE menggunakan model jaringan yang terintegrasi sepenuhnya dengan cluster yang di-deploy dalam jaringan Virtual Private Cloud (VPC) yang juga dapat berisi aplikasi lain.

Sebaiknya gunakan cluster VPC native untuk lingkungan GKE Anda. Anda dapat membuat cluster native VPC di Standard atau Autopilot. Jika Anda memilih mode Autopilot, mode VPC native selalu aktif dan tidak dapat dinonaktifkan. Paragraf berikut menjelaskan model jaringan GKE dalam mode Standard dan catatan tentang perbedaannya dengan Autopilot.

Pengelolaan alamat IP di cluster native VPC

Saat Anda menggunakan cluster VPC native, alamat IP Pod adalah alamat IP sekunder di setiap node. Setiap node akan diberikan subnet spesifik dari rentang alamat IP Pod yang Anda pilih dari ruang alamat IP internal saat membuat cluster. Secara default, cluster VPC native menetapkan subnet /24 ke setiap node untuk digunakan sebagai alamat IP Pod. Subnet /24 sesuai dengan alamat IP 256. Dalam mode Autopilot, cluster menggunakan subnet /26 yang sesuai dengan alamat 64, dan Anda tidak dapat mengubah setelan subnet ini.

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.

Karena alamat IP Pod dapat dirutekan dalam jaringan VPC, Pod dapat menerima traffic, secara default, dari resource berikut:

Dari layanan lain di jaringan VPC.
Dari jaringan VPC yang terhubung melalui Peering Jaringan VPC.
Dari jaringan lokal yang terhubung melalui Cloud VPN atau Cloud Interconnect.

Mengelola komunikasi traffic eksternal dengan agen penyamaran IP

Saat Anda berkomunikasi dari Pod ke layanan di luar cluster, agen penyamaran IP mengatur tampilan traffic ke layanan tersebut. Agen penyamaran IP menangani alamat IP pribadi dan eksternal secara berbeda, seperti yang diuraikan dalam poin berikut:

Secara default, agen penyamaran IP tidak menyamarkan traffic ke alamat IP internal, termasuk alamat IP RFC 1918, dan alamat IP non-RFC 1918 yang biasa digunakan secara internal. (Untuk informasi selengkapnya, lihat daftar tujuan default non-penyamaran). Karena alamat IP internal tidak disamarkan, node ini tidak menggunakan NAT pada alamat tersebut.
Untuk alamat IP eksternal, agen penyamaran IP menyamarkan alamat tersebut ke alamat IP node. Dengan demikian, alamat yang disamarkan tersebut diterjemahkan ke alamat IP eksternal oleh Cloud NAT atau ke alamat IP eksternal instance virtual machine (VM).

Anda juga dapat menggunakan alamat IP publik yang digunakan secara pribadi (PUPI) di dalam jaringan VPC atau jaringan yang terhubung. Jika menggunakan alamat PUPI, Anda masih dapat memanfaatkan model jaringan yang terintegrasi sepenuhnya dan melihat alamat IP Pod secara langsung sebagai sumber. Untuk mencapai kedua sasaran ini, Anda harus menyertakan alamat PUPI dalam daftar nonMasqueradeCIDRs.

Memahami alur traffic Pod di jaringan GKE

Diagram berikut menunjukkan cara Pod berkomunikasi dalam model jaringan GKE:

Diagram jaringan yang menunjukkan pola komunikasi dalam model jaringan GKE.

Diagram sebelumnya menunjukkan cara Pod di lingkungan GKE menggunakan alamat IP internal untuk berkomunikasi langsung dengan resource berikut:

Pod lain dalam cluster yang sama.
Pod di cluster GKE lainnya dalam jaringan VPC yang sama.
Aplikasi Google Cloud lainnya dalam jaringan VPC yang sama.
Aplikasi lokal yang terhubung melalui Cloud VPN.

Diagram ini juga menunjukkan hal yang terjadi jika Pod perlu menggunakan alamat IP eksternal untuk berkomunikasi dengan aplikasi. Saat traffic meninggalkan node, node tempat Pod berada menggunakan SNAT untuk memetakan alamat IP Pod ke alamat IP node. Setelah traffic meninggalkan node, Cloud NAT akan menerjemahkan alamat IP node ke alamat IP eksternal.

Untuk manfaat yang telah dijelaskan sebelumnya dalam dokumen ini, terutama agar alamat IP Pod terlihat di semua data telemetri, Google telah memilih model jaringan yang terintegrasi penuh. Di GKE, alamat IP Pod diekspos dalam Log Aliran VPC (termasuk nama Pod dalam metadata), Duplikasi Paket, Logging Aturan Firewall, dan di log aplikasi Anda sendiri untuk tujuan yang tidak disamarkan.