GSP767

Ringkasan

Infrastruktur yang mendasari cluster Google Kubernetes Engine terdiri atas node yang merupakan instance Compute VM individual. Lab ini menunjukkan bagaimana pengoptimalan infrastruktur cluster Anda dapat membantu menghemat biaya dan menghasilkan arsitektur yang lebih efisien untuk aplikasi Anda.

Anda akan mempelajari strategi untuk membantu memaksimalkan pemanfaatan (dan menghindari kurang dimanfaatkannya) resource infrastruktur Anda yang berharga melalui pemilihan jenis mesin yang dirancang dengan tepat untuk contoh workload. Selain jenis infrastruktur yang Anda gunakan, lokasi geografis fisik infrastruktur tersebut juga memengaruhi biaya. Melalui latihan ini, Anda akan mempelajari cara membuat strategi hemat biaya untuk mengelola cluster regional dengan ketersediaan lebih tinggi.

Tujuan

Dalam lab ini, Anda akan mempelajari cara:

• Memeriksa Penggunaan Resource dari suatu Deployment
• Meningkatkan Skala Deployment
• Memigrasikan Workload Anda ke Node Pool dengan Jenis Mesin yang Dioptimalkan
• Menjelajahi Opsi Lokasi untuk Cluster Anda
• Memantau Log Aliran antara Pod di Zona Berbeda
• Memindahkan Chatty Pod untuk Meminimalkan Biaya Traffic Lintas Zona

Penyiapan dan persyaratan

Sebelum mengklik tombol Mulai Lab

Baca petunjuk ini. Lab memiliki timer dan Anda tidak dapat menjedanya. Timer, yang dimulai saat Anda mengklik Start Lab, akan menampilkan durasi ketersediaan resource Google Cloud untuk Anda.

Lab praktik ini dapat Anda gunakan untuk melakukan sendiri aktivitas lab di lingkungan cloud sungguhan, bukan di lingkungan demo atau simulasi. Untuk mengakses lab ini, Anda akan diberi kredensial baru yang bersifat sementara dan dapat digunakan untuk login serta mengakses Google Cloud selama durasi lab.

Untuk menyelesaikan lab ini, Anda memerlukan:

• Akses ke browser internet standar (disarankan browser Chrome).

Catatan: Gunakan jendela Samaran atau browser pribadi untuk menjalankan lab ini. Hal ini akan mencegah konflik antara akun pribadi Anda dan akun Siswa yang dapat menyebabkan tagihan ekstra pada akun pribadi Anda.

• Waktu untuk menyelesaikan lab. Ingat, setelah dimulai, lab tidak dapat dijeda.

Catatan: Jika Anda sudah memiliki project atau akun pribadi Google Cloud, jangan menggunakannya untuk lab ini agar terhindar dari tagihan ekstra pada akun Anda.

Cara memulai lab dan login ke Google Cloud Console

1. Klik tombol Start Lab. Jika Anda perlu membayar lab, jendela pop-up akan terbuka untuk memilih metode pembayaran. Di sebelah kiri adalah panel Lab Details dengan info berikut:

   • Tombol Open Google Cloud console
   • Waktu tersisa
   • Kredensial sementara yang harus Anda gunakan untuk lab ini
   • Informasi lain, jika diperlukan, untuk menyelesaikan lab ini

2. Klik Open Google Cloud console (atau klik kanan dan pilih Open Link in Incognito Window jika Anda menjalankan browser Chrome).

   Lab akan menjalankan resource, lalu membuka tab lain yang menampilkan halaman Sign in.

   Tips: Atur tab di jendela terpisah secara berdampingan.

   Catatan: Jika Anda melihat dialog Choose an account, klik Use Another Account.

3. Jika perlu, salin Username di bawah dan tempel ke dialog Sign in.

   {{{user_0.username | "Username"}}}

   Anda juga dapat menemukan Username di panel Lab Details.

4. Klik Next.

5. Salin Password di bawah dan tempel ke dialog Welcome.

   {{{user_0.password | "Password"}}}

   Anda juga dapat menemukan Password di panel Lab Details.

6. Klik Next.

   Penting: Anda harus menggunakan kredensial yang diberikan lab. Jangan menggunakan kredensial akun Google Cloud Anda. Catatan: Menggunakan akun Google Cloud sendiri untuk lab ini dapat dikenai biaya tambahan.

7. Klik halaman berikutnya:

   • Setujui persyaratan dan ketentuan.
   • Jangan tambahkan opsi pemulihan atau autentikasi 2 langkah (karena ini akun sementara).
   • Jangan mendaftar uji coba gratis.

Setelah beberapa saat, Konsol Google Cloud akan terbuka di tab ini.

Catatan: Untuk melihat menu dengan daftar produk dan layanan Google Cloud, klik Navigation menu di kiri atas.

Lab ini membuat cluster kecil yang akan Anda gunakan. Penyediaan cluster memakan waktu sekitar 2-5 menit.

Jika Anda sudah menekan tombol Start Lab dan melihat pesan berwarna biru yang berbunyi resource being provisioned dengan lingkaran tanda memuat, berarti cluster Anda masih dibuat.

Anda dapat mulai membaca petunjuk dan penjelasan berikutnya sambil menunggu, tetapi perintah shell apa pun tidak akan berfungsi hingga resource Anda selesai disediakan.

Tugas 1. Memahami jenis mesin Node

Ringkasan umum

Jenis mesin adalah sekumpulan resource hardware tervirtualisasi yang tersedia untuk instance virtual machine (VM), termasuk ukuran memori sistem, jumlah CPU virtual (vCPU), dan batas persistent disk. Jenis mesin dikelompokkan dan dikurasi berdasarkan kelompok untuk workload yang berbeda.

Saat memilih jenis mesin untuk node pool Anda, kelompok jenis mesin untuk tujuan umum biasanya menawarkan rasio harga-performa terbaik untuk berbagai workload. Jenis mesin untuk tujuan umum terdiri atas seri N dan seri E2:

Perbedaan antara jenis mesin mungkin akan membantu aplikasi Anda, tetapi mungkin juga tidak. Secara umum, E2 memiliki performa yang serupa dengan N1, tetapi dengan biaya yang lebih murah. Biasanya, memanfaatkan jenis mesin E2 saja sudah bisa membantu menghemat biaya.

Namun, dengan cluster, resource yang digunakan harus dioptimalkan berdasarkan kebutuhan aplikasi Anda. Untuk aplikasi atau deployment yang lebih besar dan perlu penskalaan secara besar-besaran, akan lebih murah untuk mengumpulkan workload Anda pada beberapa mesin yang dioptimalkan, bukan menyebarkannya ke banyak mesin untuk tujuan umum.

Anda harus memahami detail aplikasi untuk kemajuan pengambilan keputusan ini. Jika aplikasi Anda memiliki persyaratan khusus, Anda dapat memastikan jenis mesin dirancang agar sesuai dengan aplikasi tersebut.

Di bagian berikut, Anda akan melihat aplikasi demo dan memigrasikannya ke node pool dengan jenis mesin yang dirancang dengan baik.

Tugas 2. Memilih jenis mesin yang tepat untuk aplikasi Hello

Memeriksa persyaratan cluster demo Hello

Saat sistem dimulai, lab Anda menghasilkan Cluster Demo Hello dengan dua node medium E2 (2vCPU, memori 4 GB). Cluster ini men-deploy satu replika aplikasi web sederhana bernama Aplikasi Hello, yakni server web yang ditulis dalam Go dan merespons semua permintaan dengan pesan "Hello, World!".

1. Setelah lab Anda selesai melakukan penyediaan, di Konsol Cloud, klik Navigation Menu, lalu klik Kubernetes Engine.

2. Di jendela Kubernetes Clusters, pilih hello-demo-cluster.

3. Di jendela berikut, pilih tab Nodes:

Anda sekarang akan melihat daftar node cluster Anda:

Amati cara GKE memanfaatkan resource cluster Anda. Anda dapat melihat berapa banyak CPU dan memori yang diminta oleh tiap node, serta berapa banyak potensi yang dapat dialokasikan node Anda.

4. Klik node pertama cluster Anda.

Lihat bagian Pod. Anda akan melihat pod hello-server di namespace default. Jika Anda tidak melihat pod hello-server, kembali dan pilih node kedua dari cluster Anda.

Anda akan melihat bahwa pod hello-server meminta 400 mcpu. Anda juga akan melihat beberapa pod kube-system lainnya yang berjalan. Pod ini dimuat untuk membantu mengaktifkan layanan cluster GKE, seperti pemantauan.

5. Tekan tombol Back untuk kembali ke halaman Nodes sebelumnya.

Anda akan melihat bahwa dibutuhkan dua node E2-medium untuk menjalankan satu replika Hello-App bersama layanan kube-system yang penting. Selain itu, saat Anda menggunakan sebagian besar resource CPU cluster, Anda hanya akan menggunakan sekitar 1/3 dari memori yang dapat dialokasikan.

Jika workload untuk aplikasi ini benar-benar statis, Anda dapat membuat jenis mesin menggunakan rancangan yang disesuaikan dengan jumlah CPU dan memori yang dibutuhkan. Dengan melakukannya, Anda akan menghemat biaya untuk keseluruhan infrastruktur cluster Anda.

Namun, cluster GKE sering kali menjalankan beberapa workload, dan workload tersebut biasanya perlu ditingkatkan dan diturunkan skalanya.

Apa yang akan terjadi jika Aplikasi Hello ditingkatkan skalanya?

Mengaktifkan Cloud Shell

Cloud Shell adalah mesin virtual yang dilengkapi dengan berbagai alat pengembangan. Mesin virtual ini menawarkan direktori beranda persisten berkapasitas 5 GB dan berjalan di Google Cloud. Cloud Shell menyediakan akses command-line untuk resource Google Cloud Anda.

1. Klik Activate Cloud Shell di bagian atas konsol Google Cloud.

Setelah terhubung, Anda sudah diautentikasi, dan project ditetapkan ke PROJECT_ID Anda. Output berisi baris yang mendeklarasikan PROJECT_ID untuk sesi ini:

Project Cloud Platform Anda dalam sesi ini disetel ke YOUR_PROJECT_ID

gcloud adalah alat command line untuk Google Cloud. Alat ini sudah terinstal di Cloud Shell dan mendukung pelengkapan command line.

2. (Opsional) Anda dapat menampilkan daftar nama akun yang aktif dengan perintah ini:

gcloud auth list

3. Klik Authorize.

4. Output Anda sekarang akan terlihat seperti ini:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net Untuk menyetel akun aktif, jalankan: $ gcloud config set account `ACCOUNT`

5. (Opsional) Anda dapat menampilkan daftar project ID dengan perintah ini:

gcloud config list project

Output:

[core] project = <project_ID>

Contoh output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Catatan: Untuk mendapatkan dokumentasi gcloud yang lengkap di Google Cloud, baca panduan ringkasan gcloud CLI.

Meningkatkan skala aplikasi Hello

1. Akses kredensial cluster Anda:

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Tingkatkan skala Hello-Server Anda:

kubectl scale deployment hello-server --replicas=2

Klik Check my progress untuk memastikan Anda telah melakukan tugas di atas. Meningkatkan Skala Aplikasi Hello

3. Kembali ke Konsol, pilih Workloads dari menu Kubernetes Engine di sebelah kiri.

Anda mungkin akan melihat hello-server dengan status error Does not have minimum availability.

Catatan: Di lab, Anda mungkin tidak melihat error tersebut. Bergantung pada versi kubernetes dari cluster Anda, pod kube-system dapat memiliki permintaan resource yang lebih kecil, dan cluster tersebut mungkin dapat mengakomodasi workload baru. Jika Anda tidak melihat error, jangan khawatir. Error ini tidak berpengaruh pada penyelesaian lab ini.

4. Klik pesan error untuk mendapatkan detail status. Anda akan melihat bahwa alasannya adalah Insufficient cpu.

Hal inilah yang diharapkan. Jika Anda ingat, cluster hampir tidak memiliki resource CPU lagi, dan Anda meminta 400m lagi dengan replika hello-server yang lain.

5. Tingkatkan node pool untuk menangani permintaan baru Anda:

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. Jika diminta untuk melanjutkan, ketik y, lalu tekan enter.

7. Di Konsol, muat ulang halaman Workloads sampai Anda melihat status workload hello-server berubah menjadi OK:

Memeriksa cluster Anda

Setelah workload berhasil ditingkatkan skalanya, buka kembali tab node di cluster Anda.

1. Klik hello-demo-cluster:

2. Lalu, klik tab Nodes.

Node pool yang lebih besar mampu menangani workload yang lebih berat, tetapi lihatlah bagaimana resource infrastruktur Anda digunakan.

Meskipun GKE menggunakan resource cluster dengan kemampuan terbaiknya, beberapa pengoptimalan masih dapat dilakukan di sini. Anda dapat melihat bahwa salah satu node Anda menggunakan sebagian besar memorinya, tetapi dua node Anda memiliki sejumlah besar memori yang tidak terpakai.

Pada titik ini, jika Anda terus meningkatkan skala aplikasi, Anda akan mulai melihat pola yang sama. Kubernetes akan mencoba menemukan node untuk tiap replika baru deployment hello-server, tetapi gagal, lalu membuat node baru dengan CPU sekitar 600m.

Masalah binpacking

Masalah binpacking muncul ketika Anda harus memasukkan item dengan berbagai volume/bentuk ke dalam container atau “wadah” yang bentuknya teratur dalam jumlah terbatas. Pada dasarnya, tantangannya adalah memasukkan item ke dalam wadah dengan jumlah sesedikit mungkin, dan “mengemasnya” seefisien mungkin.

Hal ini serupa dengan tantangan yang dihadapi ketika Anda mencoba mengoptimalkan cluster Kubernetes untuk aplikasi yang dijalankannya. Anda memiliki sejumlah aplikasi, kemungkinan besar dengan kebutuhan resource yang berbeda-beda (yaitu memori dan CPU). Anda harus mencoba memasukkan semua aplikasi ini ke dalam resource infrastruktur yang dikelola Kubernetes untuk Anda (tempat sebagian besar biaya cluster Anda berada) seefisien mungkin.

Cluster Demo Hello Anda tidak menggunakan binpacking yang sangat efisien. Akan lebih hemat biaya jika Kubernetes dikonfigurasi agar menggunakan jenis mesin yang lebih sesuai dengan workload ini.

Catatan: Untuk kemudahan, lab ini berfokus pada pengoptimalan satu aplikasi. Pada kenyataannya, cluster Kubernetes Anda kemungkinan besar akan menjalankan banyak aplikasi dengan kebutuhan yang berbeda-beda. Kubernetes memiliki alat untuk membantu Anda mencocokkan workload aplikasi Anda dengan berbagai mesin yang dapat diakses Kubernetes. Anda dapat menggunakan beberapa Node Pool GKE agar satu cluster Kubernetes mengelola beberapa jenis mesin.

Bermigrasi ke node pool yang dioptimalkan

• Buat node pool baru dengan jenis mesin yang lebih besar:

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Klik Check my progress untuk memastikan Anda telah melakukan tugas di atas. Membuat node pool

Sekarang, Anda dapat memigrasikan pod ke node pool baru dengan mengikuti langkah-langkah berikut:

1. Menghalangi node pool yang ada: Operasi ini menandai node dalam node pool yang ada (node) sebagai tidak dapat dijadwalkan. Kubernetes akan menghentikan penjadwalan Pod baru ke node ini setelah Anda menandainya sebagai tidak dapat dijadwalkan.
2. Mengosongkan node pool yang ada: Operasi ini mengeluarkan workload yang berjalan di node dari node pool yang ada (node) secara tuntas.

• Pertama, halangi node pool asli:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl cordon "$node"; done

• Selanjutnya, hapus pool:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl drain --force --ignore-daemonsets --delete-local-data --grace-period=10 "$node"; done

Pada titik ini, Anda akan melihat pod berjalan pada node pool yang baru, yakni larger-pool:

kubectl get pods -o=wide

3. Setelah pod dimigrasikan, node pool yang lama dapat dihapus dengan aman:

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. Jika diminta untuk melanjutkan, ketik y, lalu enter.

Penghapusan dapat memerlukan waktu sekitar 2 menit. Baca bagian selanjutnya sambil menunggu.

Analisis biaya

Anda sekarang akan menjalankan workload yang sama, yang memerlukan tiga mesin e2-medium pada satu mesin e2-standard-2.

Lihat biaya per jam untuk menyiapkan jenis mesin dengan inti bersama dan standar e2:

Standard:

Shared Core:

Biaya tiga mesin e2-medium adalah sekitar $0,1 per jam, sementara satu e2-standard-2 tercantum dengan harga sekitar $0,067 per jam.

Menghemat $0,4 per jam mungkin tampak kecil, tetapi biaya ini dapat bertambah sepanjang waktu aplikasi berjalan. Penghematan ini juga akan lebih terlihat dalam skala yang lebih besar. Karena mesin e2-standard-2 dapat mengemas workload Anda dengan lebih efisien dan lebih sedikit ruang yang tidak terpakai, biaya peningkatan skala tidak akan cepat bertambah.

Hal ini menarik karena E2-medium adalah jenis mesin dengan inti bersama yang dirancang agar hemat biaya untuk aplikasi yang kecil dan tidak memerlukan banyak resource. Namun, untuk workload Hello-App saat ini, Anda akan melihat bahwa penggunaan node pool dengan jenis mesin yang lebih besar ternyata menjadi strategi yang lebih hemat biaya.

Di Konsol Cloud, Anda harus tetap berada di tab Nodes dari cluster hello-demo Anda. Muat ulang tab ini dan periksa kolom CPU Requested serta CPU Allocatable untuk node larger-pool Anda.

Perhatikan bahwa ada ruang untuk melakukan pengoptimalan lebih lanjut. Node baru dapat memuat replika lain dari workload Anda tanpa perlu menyediakan node lain. Atau sekali lagi, Anda mungkin dapat memilih jenis mesin berukuran kustom yang sesuai dengan kebutuhan CPU dan memori aplikasi, sehingga menghemat lebih banyak resource.

Perlu diperhatikan bahwa harga ini akan bervariasi, tergantung lokasi cluster Anda. Bagian selanjutnya dari lab ini akan membahas pemilihan region terbaik dan pengelolaan cluster regional.

Memilih lokasi yang sesuai untuk sebuah cluster

Ringkasan region dan zona

Resource Compute Engine, yang digunakan untuk node cluster Anda, dihosting di beberapa lokasi di seluruh dunia. Lokasi ini terdiri atas region dan zona. Region adalah lokasi geografis spesifik tempat Anda dapat menghosting resource. Region memiliki tiga zona atau lebih.

Resource yang ada di suatu zona, seperti instance virtual machine atau persistent disk zona, disebut sebagai resource zona. Resource lainnya, seperti alamat IP eksternal statis, merupakan resource regional. Resource regional dapat digunakan oleh resource mana pun di region yang bersangkutan, di mana pun zonanya, sedangkan resource zona hanya dapat digunakan oleh resource lain di zona yang sama.

Saat memilih region atau zona, penting untuk mempertimbangkan faktor-faktor berikut:

1. Menangani kegagalan - Jika resource untuk aplikasi Anda hanya didistribusikan di satu zona dan zona tersebut tidak tersedia, aplikasi Anda juga tidak akan tersedia. Untuk skala yang lebih besar, aplikasi dengan permintaan tinggi sering kali merupakan praktik terbaik untuk mendistribusikan resource di beberapa zona atau region untuk menangani kegagalan.
2. Mengurangi latensi jaringan - Untuk mengurangi latensi jaringan, Anda mungkin perlu memilih region atau zona yang dekat dengan titik layanan Anda. Misalnya, jika sebagian besar pelanggan Anda berada di Pantai Timur Amerika Serikat, Anda mungkin perlu memilih region dan zona utama yang dekat dengan wilayah tersebut.

Praktik terbaik untuk cluster

Biaya bervariasi antar-region berdasarkan berbagai faktor. Misalnya, resource di region us-west2 cenderung lebih mahal dibandingkan dengan yang ada di us-central1.

Saat memilih region atau zona untuk cluster Anda, periksa hal yang dilakukan aplikasi Anda. Untuk lingkungan produksi yang sensitif terhadap latensi, menempatkan aplikasi Anda di region/zona dengan latensi jaringan yang lebih rendah dan efisiensi yang lebih tinggi mungkin akan memberi Anda rasio performa-harga terbaik.

Namun, lingkungan pengembangan yang tidak sensitif terhadap latensi dapat ditempatkan di region yang lebih murah untuk mengurangi biaya.

Catatan: Untuk mengetahui informasi selengkapnya tentang VM dan harga per region, baca Dokumentasi harga instance VM.

Menangani ketersediaan cluster

Jenis cluster yang tersedia di GKE meliputi: zona (zona tunggal atau multizona) dan regional. Pada kenyataannya, cluster zona tunggal akan menjadi pilihan yang paling murah. Namun, untuk ketersediaan tinggi aplikasi Anda, yang terbaik adalah mendistribusikan resource infrastruktur cluster Anda ke seluruh zona.

Dalam banyak kasus, memprioritaskan ketersediaan di cluster Anda melalui cluster regional atau multizona akan menghasilkan arsitektur terbaik dari segi rasio harga-performa.

Catatan: Cluster multizona memiliki setidaknya satu zona tambahan yang ditentukan, tetapi hanya memiliki satu replika bidang kontrol yang berjalan di satu zona. Workload masih dapat berjalan selama pemadaman layanan zona bidang kontrol, tetapi konfigurasi tidak dapat dibuat pada cluster hingga bidang kontrol tersedia.

Cluster regional memiliki beberapa replika bidang kontrol, yang berjalan di beberapa zona dalam region tertentu. Node juga berjalan di tiap zona tempat replika bidang kontrol dijalankan. Cluster regional menggunakan resource paling banyak, tetapi menawarkan ketersediaan terbaik.

Pelajari lebih lanjut dari artikel Jenis cluster.

Tugas 3. Mengelola cluster regional

Penyiapan

Mengelola resource cluster Anda di beberapa zona menjadi sedikit lebih rumit. Jika tidak berhati-hati, biaya tambahan mungkin akan timbul akibat komunikasi antarzona yang tidak perlu antara pod Anda.

Di bagian ini, Anda akan mengamati traffic jaringan cluster Anda dan memindahkan dua chatty pod agar berada di zona yang sama. Chatty pod adalah pod yang menghasilkan banyak traffic ke satu sama lain.

1. Di tab Cloud Shell, buat cluster regional baru (perintah ini memerlukan waktu beberapa menit untuk diselesaikan):

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Untuk mendemonstrasikan traffic antara pod dan node Anda, Anda akan membuat dua pod pada node terpisah di cluster regional Anda. Kita akan menggunakan ping untuk menghasilkan traffic dari satu pod ke pod lainnya guna menghasilkan traffic yang kemudian dapat kita pantau.

2. Jalankan perintah ini untuk membuat manifes bagi pod pertama Anda:

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. Buat pod pertama di Kubernetes menggunakan perintah ini:

kubectl apply -f pod-1.yaml

4. Selanjutnya, jalankan perintah ini untuk membuat manifes bagi pod kedua Anda:

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. Buat pod kedua di Kubernetes:

kubectl apply -f pod-2.yaml

Klik Check my progress untuk memastikan Anda telah melakukan tugas di atas. Memeriksa Pembuatan Pod

Pod yang Anda buat menggunakan container node-hello dan menampilkan pesan Hello Kubernetes saat diminta.

Jika Anda melihat kembali file pod-2.yaml yang Anda buat, Anda dapat melihat bahwa Pod Anti Affinity adalah aturan yang ditentukan. Dengan demikian, Anda dapat memastikan bahwa pod tidak dijadwalkan pada node yang sama dengan pod-1. Hal ini dilakukan dengan mencocokkan ekspresi berdasarkan label security: demo dari pod-1. Pod Affinity digunakan untuk memastikan pod dijadwalkan pada node yang sama, sementara Pod Anti Affinity digunakan untuk memastikan pod tidak dijadwalkan pada node yang sama.

Catatan: Kubernetes juga memiliki konsep Node Affinity, yang dapat membantu Anda mengoptimalkan aplikasi mana yang dijalankan pada jenis mesin apa.

Pada kasus ini, Pod Anti Affinity digunakan untuk membantu mengilustrasikan traffic di antara node, tetapi penggunaan Pod Anti Affinity dan Pod Affinity secara cerdas dapat membantu Anda memanfaatkan resource cluster regional Anda dengan lebih baik.

6. Lihat pod yang Anda buat:

kubectl get pod pod-1 pod-2 --output wide

Anda akan melihat kedua pod ditampilkan dengan status Running dan IP internal.

Contoh output: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

Catat alamat IP pod-2. Anda akan menggunakannya dalam perintah berikut.

Menyimulasikan traffic

1. Dapatkan shell ke container pod-1 Anda:

kubectl exec -it pod-1 -- sh

2. Di shell Anda, kirim permintaan ke pod-2 menggantikan [POD-2-IP] dengan IP internal ditampilkan untuk pod-2:

ping [POD-2-IP]

Catat latensi rata-rata yang diperlukan untuk melakukan ping pod-2 dari pod-1.

Memeriksa log alur

Dengan pod-1 melakukan ping terhadap pod-2, Anda dapat mengaktifkan log alur pada subnet VPC tempat cluster dibuat untuk mengamati traffic.

1. Di Konsol Cloud, buka Navigation Menu, lalu pilih VPC Network di bagian Networking.

2. Temukan subnet default di region , lalu klik subnet tersebut.

3. Klik Edit di bagian atas layar.

4. Pilih Flow Logs agar menjadi On.

5. Selanjutnya, klik Save.

6. Lalu, klik View Flow Logs in Logs Explorer.

Sekarang Anda akan melihat daftar log yang menampilkan sejumlah besar informasi tiap kali sesuatu dikirim atau diterima dari salah satu instance Anda.

Jika log tidak dihasilkan, ganti / sebelum vpc_flows dengan %2F seperti diperlihatkan pada screenshot di atas.

Ini mungkin agak sulit dibaca. Selanjutnya, ekspor ke tabel BigQuery sehingga Anda dapat mengkueri informasi yang relevan.

7. Klik More actions > Create Sink.

8. Beri nama sink Anda dengan FlowLogsSample.

9. Klik Next.

Tujuan sink

• Untuk Sink Service, pilih BigQuery Dataset.
• Untuk BigQuery Dataset, pilih Create new BigQuery dataset.
• Beri nama set data Anda sebagai 'us_flow_logs', lalu klik CREATE DATASET.

Semua hal lainnya dapat dibiarkan apa adanya.

1. Klik Create Sink.

2. Sekarang, periksa set data yang baru Anda buat. Di Konsol Cloud, dari Navigation Menu di bagian Analytics, klik BigQuery.

3. Klik Done.

4. Pilih nama project Anda, lalu pilih us_flow_logs untuk melihat tabel yang baru dibuat. Jika tidak ada tabel di sana, Anda mungkin perlu memuat ulang hingga tabel tersebut dibuat.

5. Klik tabel compute_googleapis_com_vpc_flows_xxx di bawah set data us_flow_logs.

6. Klik Query > In new tab.

7. Di BigQuery Editor, tempelkan kode berikut di antara SELECT dan FROM:

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. Klik Run.

Anda akan melihat log alur seperti sebelumnya, tetapi difilter berdasarkan source zone, source vm, destination zone, dan destination vm.

Temukan beberapa baris yang memiliki panggilan yang dilakukan antara dua zona yang berbeda di cluster regional-demo Anda.

Catatan: Log Anda tidak akan menunjukkan angka-angka yang sama persis seperti gambar contoh.

Dengan mengamati log alur, Anda dapat melihat bahwa sering terjadi traffic antarzona yang berbeda.

Selanjutnya, Anda akan memindahkan pod ke zona yang sama dan mengamati manfaatnya.

Memindahkan chatty pod untuk meminimalkan biaya traffic lintas zona

1. Kembali ke Cloud Shell, tekan Ctrl + C untuk membatalkan perintah ping.

2. Ketik perintah exit untuk keluar dari shell pod-1:

exit

3. Jalankan perintah ini untuk mengedit manifes pod-2:

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

Hal ini akan mengubah aturan Pod Anti Affinity Anda menjadi aturan Pod Affinity dengan tetap menggunakan logika yang sama. Sekarang pod-2 akan dijadwalkan pada node yang sama dengan pod-1.

4. Hapus pod-2 yang sedang berjalan:

kubectl delete pod pod-2

5. Setelah pod-2 dihapus, buat ulang menggunakan manifes yang baru diedit:

kubectl create -f pod-2.yaml

Klik Check my progress untuk memastikan Anda telah melakukan tugas di atas. Menyimulasikan Traffic

6. Lihat pod yang Anda buat dan pastikan keduanya Running atau berjalan:

kubectl get pod pod-1 pod-2 --output wide

Dari output-nya, Anda dapat melihat bahwa Pod-1 dan Pod-2 sekarang berjalan di node yang sama.

Catat alamat IP pod-2. Anda akan menggunakannya dalam perintah berikut.

7. Dapatkan shell ke container pod-1 Anda:

kubectl exec -it pod-1 -- sh

8. Di shell Anda, kirim permintaan ke pod-2 menggantikan [POD-2-IP] dengan IP internal untuk pod-2 dari perintah sebelumnya:

ping [POD-2-IP]

Anda akan melihat waktu ping rata-rata antar-pod ini sekarang jauh lebih cepat.

Pada tahap ini, Anda dapat kembali ke set data BigQuery log alur dan memeriksa log terbaru untuk memastikan tidak ada lagi komunikasi antarzona yang tidak diinginkan.

Analisis biaya

Lihat harga traffic keluar VM-VM dalam Google Cloud:

Ketika pod melakukan ping satu sama lain dari zona berbeda, biayanya adalah $0,01 per GB. Meskipun mungkin terlihat kecil, biaya ini dapat bertambah dengan sangat cepat dalam cluster berskala besar dengan beberapa layanan yang sering melakukan panggilan antarzona.

Setelah Anda memindahkan pod ke zona yang sama, ping akan menjadi gratis.

Selamat!

Anda telah mempelajari pengoptimalan biaya untuk Virtual Machine yang merupakan bagian dari cluster GKE. Pertama, dengan memigrasikan workload ke node pool dengan jenis mesin yang lebih sesuai. Kemudian, dengan membangun pemahaman tentang kelebihan dan kekurangan berbagai region. Dan terakhir, dengan memindahkan chatty pod dalam cluster regional agar selalu berada di zona yang sama dengan pod yang diajak berkomunikasi.

Lab ini telah menunjukkan kepada Anda alat dan strategi yang hemat biaya untuk VM GKE. Namun demikian, untuk melakukan pengoptimalan virtual machine, Anda harus memahami aplikasi dan kebutuhannya terlebih dahulu. Mengetahui jenis workload yang akan Anda jalankan dan memperkirakan permintaan aplikasi Anda hampir selalu akan memengaruhi keputusan terkait lokasi dan jenis mesin yang paling efektif untuk virtual machine yang mendasari cluster GKE Anda.

Pemanfaatan infrastruktur cluster Anda secara efisien akan sangat membantu mengoptimalkan biaya Anda.

Langkah berikutnya/Pelajari lebih lanjut

• Dokumen Jenis Mesin
• Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE: Pilih jenis mesin yang tepat
• Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE: Pilih region yang sesuai

Sertifikasi dan pelatihan Google Cloud

...membantu Anda mengoptimalkan teknologi Google Cloud. Kelas kami mencakup keterampilan teknis dan praktik terbaik untuk membantu Anda memahami dengan cepat dan melanjutkan proses pembelajaran. Kami menawarkan pelatihan tingkat dasar hingga lanjutan dengan opsi on demand, live, dan virtual untuk menyesuaikan dengan jadwal Anda yang sibuk. Sertifikasi membantu Anda memvalidasi dan membuktikan keterampilan serta keahlian Anda dalam teknologi Google Cloud.

Manual Terakhir Diperbarui pada 30 April 2024

Lab Terakhir Diuji pada 30 April 2024

Hak cipta 2024 Google LLC Semua hak dilindungi undang-undang. Google dan logo Google adalah merek dagang dari Google LLC. Semua nama perusahaan dan produk lain mungkin adalah merek dagang masing-masing perusahaan yang bersangkutan.