GSP769

Ringkasan

Salah satu dari sekian banyak manfaat penggunaan Google Cloud adalah model penagihannya, di mana Anda hanya akan ditagih untuk resource yang Anda gunakan. Oleh karena itu, penting bagi Anda untuk tidak hanya mengalokasikan resource dalam jumlah yang wajar untuk aplikasi dan infrastruktur Anda, tetapi juga untuk memanfaatkannya secara efisien. Dengan GKE, terdapat sejumlah alat dan strategi yang dapat Anda gunakan untuk mengurangi penggunaan resource dan layanan yang berbeda sekaligus meningkatkan ketersediaan aplikasi Anda.

Lab ini akan membahas beberapa konsep yang akan membantu meningkatkan efisiensi resource dan ketersediaan workload Anda. Dengan memahami dan menyesuaikan workload cluster, Anda bisa memastikan bahwa Anda hanya menggunakan resource yang diperlukan dan mengoptimalkan biaya cluster Anda.

Tujuan

Dalam lab ini, Anda akan mempelajari cara:

• Membuat load balancer berbasis container melalui ingress
• Menguji load aplikasi
• Mengonfigurasi pemeriksaan keaktifan dan kesiapan
• Membuat anggaran disrupsi pod

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.

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.

Menyediakan lingkungan lab

1. Setel zona default Anda ke "":

gcloud config set compute/zone {{{project_0.default_zone|ZONE}}}

2. Klik Authorize.

3. Buat cluster tiga node:

gcloud container clusters create test-cluster --num-nodes=3 --enable-ip-alias

Flag --enable-ip-alias disertakan untuk mengaktifkan penggunaan IP alias untuk pod yang akan diperlukan untuk load balancing berbasis container melalui ingress.

Untuk lab ini, Anda akan menggunakan sebuah aplikasi web HTTP sederhana yang akan Anda deploy terlebih dahulu sebagai satu pod.

4. Buat manifes untuk pod gb-frontend:

cat << EOF > gb_frontend_pod.yaml apiVersion: v1 kind: Pod metadata: labels: app: gb-frontend name: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 256Mi ports: - containerPort: 80 EOF

5. Terapkan manifes yang baru dibuat ini ke cluster Anda:

kubectl apply -f gb_frontend_pod.yaml Catatan: Anda mungkin perlu menunggu selama 1 hingga 2 menit untuk mendapatkan skor untuk tugas ini.

Klik Check my progress untuk memverifikasi tujuan. Menyediakan Lingkungan Lab

Tugas 1. Load balancing berbasis container melalui ingress

Load balancing berbasis container memungkinkan load balancer langsung menarget Pod Kubernetes dan mendistribusikan traffic ke pod secara merata.

Tanpa Load balancing berbasis container, traffic load balancer akan berpindah ke grup instance node lalu diarahkan melalui aturan iptables ke pod yang mungkin berada atau tidak berada di node yang sama:

Load balancing berbasis container memungkinkan pod menjadi objek induk untuk load balancing, sehingga dapat mengurangi jumlah lompatan jaringan:

Selain penentuan rute yang lebih efisien, load balancing berbasis container menghasilkan pemanfaatan jaringan yang jauh lebih baik, peningkatan performa, distribusi traffic yang merata di seluruh Pod, dan health check di tingkat aplikasi.

Untuk dapat menggunakan load balancing berbasis container, setelan bawaan VPC harus diaktifkan pada cluster. Ini ditunjukkan saat Anda membuat cluster dan menyertakan flag --enable-ip-alias.

1. Manifes berikut ini akan mengonfigurasi layanan ClusterIP yang akan digunakan untuk mengarahkan traffic ke pod aplikasi Anda agar GKE dapat membuat grup endpoint jaringan:

cat << EOF > gb_frontend_cluster_ip.yaml apiVersion: v1 kind: Service metadata: name: gb-frontend-svc annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: ClusterIP selector: app: gb-frontend ports: - port: 80 protocol: TCP targetPort: 80 EOF

Manifes ini mencakup kolom anotasi di mana anotasi untuk cloud.google.com/neg akan mengaktifkan load balancing berbasis container untuk aplikasi Anda ketika ingress dibuat.

2. Terapkan perubahan pada cluster Anda:

kubectl apply -f gb_frontend_cluster_ip.yaml

3. Selanjutnya, buat ingress untuk aplikasi Anda:

cat << EOF > gb_frontend_ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gb-frontend-ingress spec: defaultBackend: service: name: gb-frontend-svc port: number: 80 EOF

4. Terapkan perubahan pada cluster Anda:

kubectl apply -f gb_frontend_ingress.yaml

Ketika ingress dibuat, load balancer HTTP (S) dibuat bersama dengan NEG (Grup Endpoint Jaringan) di setiap zona tempat cluster berjalan. Setelah beberapa menit, ingress akan diberi sebuah IP eksternal.

Load balancer yang dibuatnya memiliki layanan backend yang berjalan di project Anda, yang menentukan cara Cloud Load Balancing mendistribusikan traffic. Layanan backend ini memiliki status health yang terasosiasi dengannya.

5. Untuk memeriksa status health layanan backend, pertama-tama dapatkan namanya:

BACKEND_SERVICE=$(gcloud compute backend-services list | grep NAME | cut -d ' ' -f2)

6. Dapatkan status health untuk layanan tersebut:

gcloud compute backend-services get-health $BACKEND_SERVICE --global

Perlu waktu beberapa menit hingga health check menampilkan status health.

Output akan tampak seperti berikut:

--- backend: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/networkEndpointGroups/k8s1-95c051f0-default-gb-frontend-svc-80-9b127192 status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/instances/gke-test-cluster-default-pool-7e74f027-47qp ipAddress: 10.8.0.6 port: 80 kind: compute#backendServiceGroupHealth Catatan: Health check ini merupakan bagian dari load balancer Google dan berbeda dari pemeriksaan keaktifan dan kesiapan yang disediakan oleh Kubernetes API yang dapat digunakan untuk menentukan status health masing-masing pod. Health check load balancer Google Cloud menggunakan rute khusus di luar VPC project Anda untuk melakukan health check dan menentukan keberhasilan atau kegagalan backend.

Setelah status health setiap instance dilaporkan sebagai HEALTHY, Anda dapat mengakses aplikasi melalui IP eksternalnya.

7. Dapatkan dengan:

kubectl get ingress gb-frontend-ingress

8. Memasukkan IP eksternal di jendela browser akan memuat aplikasi.

Klik Check my progress untuk memverifikasi tujuan. Load Balancing Berbasis Container Melalui Ingress

Tugas 2. Menguji load aplikasi

Memahami kapasitas aplikasi Anda merupakan langkah penting yang harus dilakukan saat memilih permintaan resource dan batasan untuk pod aplikasi serta untuk menentukan strategi penskalaan otomatis terbaik.

Di awal lab, Anda sudah men-deploy aplikasi Anda sebagai sebuah pod. Dengan menguji load aplikasi yang berjalan pada satu pod tanpa konfigurasi penskalaan otomatis, Anda akan mengetahui jumlah permintaan serentak yang dapat ditangani oleh aplikasi, jumlah CPU dan memori yang dibutuhkan, dan bagaimana responnya terhadap load yang berat.

Untuk menguji load pod, Anda akan menggunakan Locust, sebuah framework open source untuk pengujian load.

1. Download file image Docker untuk Locust dalam Cloud Shell Anda:

gsutil -m cp -r gs://spls/gsp769/locust-image .

File dalam direktori locust-image yang tersedia meliputi file konfigurasi Locust.

2. Bangun image Docker untuk Locust lalu simpan dalam container registry project Anda:

gcloud builds submit \ --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/locust-tasks:latest locust-image

3. Verifikasi bahwa image Docker berada dalam container registry project Anda:

gcloud container images list

Output yang diharapkan:

Locust terdiri dari satu mesin utama dan sejumlah worker untuk menghasilkan load.

4. Dengan menyalin dan menerapkan manifes ini, Anda akan membuat sebuah deployment satu-pod untuk mesin utama dan sebuah deployment dengan 5 replika untuk worker-nya:

gsutil cp gs://spls/gsp769/locust_deploy_v2.yaml . sed 's/${GOOGLE_CLOUD_PROJECT}/'$GOOGLE_CLOUD_PROJECT'/g' locust_deploy_v2.yaml | kubectl apply -f -

5. Untuk mengakses Locust UI, ambil alamat IP eksternal dari layanan LoadBalancer yang sesuai:

kubectl get service locust-main

Jika nilai External IP Anda adalah <pending>, tunggu sebentar dan jalankan kembali perintah sebelumnya sampai nilai yang valid ditampilkan.

6. Di jendela browser baru, buka [EXTERNAL_IP_ADDRESS]:8089 untuk membuka halaman web Locust:

Klik Check my progress untuk memverifikasi tujuan. Menguji Load Aplikasi

Dengan Locust, Anda dapat melakukan swarm kepada aplikasi Anda dengan banyak pengguna secara bersamaan. Anda dapat menyimulasikan traffic dengan memasukkan sejumlah pengguna baru yang muncul dengan laju tertentu.

7. Untuk contoh ini, sebagai gambaran load normal, masukkan 200 sebagai jumlah pengguna yang akan disimulasikan dan 20 sebagai laju kemunculan baru.

8. Klik Start swarming.

Setelah beberapa detik, status harus menampilkan Running dengan 200 pengguna dan sekitar 150 permintaan per detik (RPS).

9. Beralih ke Konsol Cloud dan klik Navigation menu () > Kubernetes Engine.

10. Pilih Workloads dari panel sebelah kiri.

11. Lalu klik pod gb-frontend yang telah di-deploy.

Tindakan ini akan membuka halaman detail pod, tempat Anda dapat melihat grafik penggunaan CPU dan memori pod Anda. Amati nilai used dan nilai requested.

Catatan: Untuk melihat nilai metrik yang tercantum di bawah grafik, klik tiga titik di bagian kanan atas grafik dan pilih Expand chart legend dari menu dropdown.

Dengan pengujian load saat ini dengan sekitar 150 permintaan per detik, Anda dapat melihat pemanfaatan CPU yang berubah-ubah dari paling rendah .04 hingga paling tinggi .06. Angka ini mewakili 40-60% permintaan CPU untuk satu pod. Di sisi lain, pemanfaatan memori tetap berada pada angka sekitar 80Mi, jauh di bawah angka yang diminta yaitu 256Mi. Inilah angka kapasitas per-pod Anda. Informasi ini akan berguna saat mengonfigurasi Cluster Autoscaler, permintaan dan batasan resource, serta cara atau apakah Anda akan menerapkan horizontal atau vertical pod autoscaler.

Selain dasar pengukuran, Anda juga harus mempertimbangkan kemungkinan performa aplikasi Anda setelah terjadi burst atau lonjakan tiba-tiba.

12. Kembali ke jendela browser Locust lalu klik Edit pada status di bagian atas halaman.

13. Kali ini, masukkan 900 sebagai jumlah pengguna yang akan disimulasikan dan 300 sebagai laju kemunculan barunya.

14. Klik Start Swarming.

Pod Anda mendadak akan menerima 700 tambahan permintaan dalam waktu 2 - 3 detik. Setelah nilai RPS mencapai sekitar 150 dan statusnya menunjukkan 900 pengguna, buka lagi halaman Detail Pod dan amati perubahan yang terjadi pada grafik.

Sementara memori tetap sama, Anda akan melihat bahwa CPU mencapai puncaknya pada hampir .07 - itu sama dengan 70% permintaan CPU untuk pod Anda. Jika aplikasi ini adalah sebuah deployment, Anda mungkin dapat dengan aman mengurangi total permintaan memori ke jumlah yang lebih rendah dan mengonfigurasi horizontal autoscaler untuk memicu penggunaan CPU.

Tugas 3. Pemeriksaan kesiapan dan keaktifan

Menyiapkan pemeriksaan keaktifan

Jika dikonfigurasi dengan spesifikasi pod atau deployment Kubernetes, pemeriksaan keaktifan akan terus berjalan untuk mendeteksi apakah container perlu dimulai ulang dan memicu proses mulai ulang tersebut. Pemeriksaan ini membantu untuk otomatis memulai ulang aplikasi berkondisi deadlock yang mungkin masih dalam status berjalan. Sebagai contoh, load balancer yang dikelola kubernetes (seperti layanan) hanya akan mengirim traffic ke backend pod jika semua container lolos dari pemeriksaan kesiapan.

1. Untuk mendemonstrasikan pemeriksaan keaktifan, perintah berikut ini akan menghasilkan manifes untuk pod dengan pemeriksaan keaktifan yang didasarkan pada eksekusi perintah cat terhadap file yang dibuat saat proses pembuatannya:

cat << EOF > liveness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: liveness-probe name: liveness-demo-pod spec: containers: - name: liveness-demo-pod image: centos args: - /bin/sh - -c - touch /tmp/alive; sleep infinity livenessProbe: exec: command: - cat - /tmp/alive initialDelaySeconds: 5 periodSeconds: 10 EOF

2. Terapkan manifes ke cluster Anda untuk membuat pod:

kubectl apply -f liveness-demo.yaml

Nilai initialDelaySeconds menunjukkan berapa lama sebelum pemeriksaan pertama harus dilakukan setelah container dimulai. Nilai periodSeconds mengindikasikan seberapa sering pemeriksaan akan dilakukan.

Catatan: Pod juga dapat dikonfigurasi untuk mencakup startupProbe yang mengindikasikan apakah aplikasi di dalam container dimulai. Apabila ada nilai startupProbe, maka pemeriksaan lain tidak akan dilakukan hingga pemeriksaan startup menampilkan status Success. Ini direkomendasikan untuk aplikasi yang mungkin memiliki waktu mulai yang bervariasi untuk menghindari interupsi dari pemeriksaan keaktifan.

Dalam contoh ini, pemeriksaan keaktifan pada dasarnya memeriksa keberadaan file /tmp/alive pada sistem file container.

3. Anda dapat memverifikasi status health container pod dengan memeriksa peristiwa pod:

kubectl describe pod liveness-demo-pod

Di bagian bawah output, Anda dapat melihat bagian Peristiwa yang menampilkan 5 peristiwa terakhir pod. Pada titik ini, peristiwa pod seharusnya hanya mencakup peristiwa yang terkait dengan pembuatan dan permulaannya:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 19s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 18s kubelet Pulling image "centos" Normal Pulled 18s kubelet Successfully pulled image "centos" Normal Created 18s kubelet Created container liveness-demo-pod Normal Started 18s kubelet Started container liveness-demo-pod

Log peristiwa akan mencantumkan setiap kegagalan pemeriksaan keaktifan, serta peristiwa muat ulang yang terpicu karena kegagalan itu.

4. Hapus file yang sedang digunakan oleh pemeriksaan keaktifan secara manual:

kubectl exec liveness-demo-pod -- rm /tmp/alive

5. Setelah file dihapus, perintah cat yang digunakan oleh pemeriksaan keaktifan seharusnya menghasilkan kode keluar bukan nol.

6. Sekali lagi, periksa peristiwa pod:

kubectl describe pod liveness-demo-pod

Saat pemeriksaan keaktifan gagal, Anda akan melihat peristiwa ditambahkan ke log dengan menunjukkan serangkaian langkah yang dijalankan. Diawali dengan pemeriksaan keaktifan yang gagal (Liveness probe failed: cat: /tmp/alive: No such file or directory) dan diakhiri dengan dimulainya kembali container (Started container):

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Warning Unhealthy 36s (x3 over 56s) kubelet Liveness probe failed: cat: /tmp/alive: No such file or directory Normal Killing 36s kubelet Container liveness-demo-pod failed liveness probe, will be restarted Normal Pulling 6s (x2 over 2m20s) kubelet Pulling image "centos" Normal Pulled 6s (x2 over 2m20s) kubelet Successfully pulled image "centos" Normal Created 6s (x2 over 2m20s) kubelet Created container liveness-demo-pod Normal Started 6s (x2 over 2m20s) kubelet Started container liveness-demo-pod Catatan: Contoh dalam lab ini menggunakan pemeriksaan perintah untuk livenessProbe yang bergantung pada kode keluar dari perintah yang ditentukan. Selain pemeriksaan perintah, livenessProbe harus dikonfigurasi sebagai pemeriksaan HTTP yang tergantung pada respons HTTP, atau pemeriksaan TCP yang akan bergantung pada apakah koneksi TCP dapat dibuat pada port tertentu.

Menyiapkan pemeriksaan kesiapan

Meskipun pod berhasil dimulai dan dianggap berfungsi baik oleh pemeriksaan keaktifan, terdapat kemungkinan bahwa pod tersebut belum siap untuk segera menerima traffic. Hal ini biasa terjadi pada deployment yang berfungsi sebagai backend untuk layanan seperti load balancer. Pemeriksaan kesiapan digunakan untuk menentukan kapan pod dan container-nya siap untuk mulai menerima traffic.

1. Untuk mendemonstrasikan hal ini, buat manifes untuk membuat satu pod yang akan berfungsi sebagai server web uji bersama dengan load balancer:

cat << EOF > readiness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe EOF

2. Terapkan manifes ke cluster Anda dan gunakan untuk membuat load balancer:

kubectl apply -f readiness-demo.yaml

3. Ambil alamat IP eksternal yang ditetapkan ke load balancer Anda (penetapan alamat ini mungkin memerlukan waktu satu menit setelah perintah sebelumnya):

kubectl get service readiness-demo-svc

4. Masukkan alamat IP pada jendela browser dan Anda akan mendapatkan pesan error yang menandakan bahwa situs tersebut tidak dapat dijangkau.

5. Periksa peristiwa pod:

kubectl describe pod readiness-demo-pod

Output akan menunjukkan bahwa pemeriksaan kesiapan gagal:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

Tidak seperti pemeriksaan keaktifan, pemeriksaan kesiapan yang gagal tidak memicu pod untuk dimulai ulang.

6. Gunakan perintah berikut untuk menghasilkan file yang diperiksa oleh pemeriksaan kesiapan:

kubectl exec readiness-demo-pod -- touch /tmp/healthz

Bagian Conditions dari deskripsi pod kini seharusnya menampilkan True sebagai nilai untuk Ready.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Output:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

7. Sekarang, refresh tab browser yang memiliki IP eksternal readiness-demo-svc Anda. Anda seharusnya melihat pesan "Welcome to nginx!" terpampang.

Menetapkan pemeriksaan kesiapan yang efektif untuk container aplikasi Anda akan memastikan bahwa pod hanya menerima traffic setelah siap. Contoh pemeriksaan kesiapan yang efektif adalah memeriksa apakah cache yang diandalkan aplikasi Anda sudah dimuat saat sistem dimulai.

Klik Check my progress untuk memverifikasi tujuan. Pemeriksaan Kesiapan dan Keaktifan

Tugas 4. Anggaran disrupsi pod

Salah satu bagian dari upaya untuk memastikan keandalan dan ketersediaan aplikasi GKE Anda adalah pemanfaatan anggaran disrupsi pod (pdp). PodDisruptionBudget adalah resource Kubernetes yang membatasi jumlah pod dari sebuah aplikasi replika yang dapat berhenti bekerja secara bersamaan karena gangguan yang disengaja.

Gangguan yang disengaja mencakup tindakan administratif seperti menghapus deployment, memperbarui template pod deployment dan melakukan update berkelanjutan, mengosongkan node tempat pod aplikasi berada, atau memindahkan pod ke node lain.

Pertama, Anda perlu men-deploy aplikasi Anda sebagai sebuah deployment.

1. Menghapus aplikasi satu pod Anda:

kubectl delete pod gb-frontend

2. Lalu, hasilkan manifes yang akan membuatnya sebagai deployment 5 replika:

cat << EOF > gb_frontend_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: gb-frontend labels: run: gb-frontend spec: replicas: 5 selector: matchLabels: run: gb-frontend template: metadata: labels: run: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 128Mi ports: - containerPort: 80 protocol: TCP EOF

3. Terapkan deployment ini ke cluster Anda:

kubectl apply -f gb_frontend_deployment.yaml

Klik Check my progress untuk memverifikasi tujuan. Membuat Anggaran Disrupsi Pod

Sebelum membuat anggaran disrupsi pod (pod disruption budget, PDB), Anda akan mengosongkan node-node cluster Anda dan mengamati perilaku aplikasi Anda tanpa PDB.

4. Kosongkan node dengan melakukan loop melalui output dari node default-pool, lalu jalankan perintah kubectl drain pada masing-masing node:

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

Perintah di atas akan mengeluarkan pod dari node yang ditentukan dan menutup node tersebut sehingga tidak ada pod baru yang dapat dibuat di dalamnya. Jika resource yang tersedia memungkinkan, pod akan dipindahkan ke node yang berbeda.

5. Setelah node kosong, periksa jumlah replika gb-frontend Anda:

kubectl describe deployment gb-frontend | grep ^Replicas

Outputnya mungkin akan tampak seperti ini:

Replicas: 5 desired | 5 updated | 5 total | 0 available | 5 unavailable

Setelah mengosongkan node, deployment Anda mungkin hanya memiliki paling sedikit 0 replika yang tersedia, seperti yang ditunjukkan oleh output di atas. Tanpa adanya pod yang tersedia, aplikasi Anda akan praktis menjadi nonaktif. Mari kita coba mengosongkan node lagi, tetapi kali ini dengan anggaran disrupsi pod yang tersedia untuk aplikasi Anda.

6. Pertama-tama, aktifkan lagi node yang telah dikosongkan dengan menandainya sebagai dapat dijadwalkan (uncordoning). Perintah di bawah ini memungkinkan pod dijadwalkan pada node lagi:

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

7. Periksa status deployment Anda sekali lagi:

kubectl describe deployment gb-frontend | grep ^Replicas

Outputnya sekarang akan menyerupai yang berikut ini, dengan kelima replika yang tersedia:

Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable

8. Buat anggaran disrupsi pod yang akan mendeklarasikan jumlah minimum pod yang tersedia adalah 4:

kubectl create poddisruptionbudget gb-pdb --selector run=gb-frontend --min-available 4

9. Sekali lagi, kosongkan salah satu node cluster Anda dan amati hasilnya:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --timeout=30s --ignore-daemonsets --grace-period=10 "$node"; done

Setelah berhasil mengeluarkan salah satu pod aplikasi Anda, aplikasi akan mengulangi proses berikut ini:

evicting pod default/gb-frontend-597d4d746c-fxsdg evicting pod default/gb-frontend-597d4d746c-tcrf2 evicting pod default/gb-frontend-597d4d746c-kwvmv evicting pod default/gb-frontend-597d4d746c-6jdx5 error when evicting pod "gb-frontend-597d4d746c-fxsdg" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-tcrf2" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-6jdx5" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-kwvmv" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

10. Tekan CTRL+C untuk keluar dari perintah.

11. Periksa status deployment Anda sekali lagi:

kubectl describe deployment gb-frontend | grep ^Replicas

Sekarang, outputnya akan tampak seperti berikut:

Replicas: 5 desired | 5 updated | 5 total | 4 available | 1 unavailable

Hingga Kubernetes dapat menggunakan pod ke-5 pada node yang berbeda untuk mengeluarkan pod berikutnya, pod yang tersisa akan tetap tersedia untuk mematuhi PDB. Dalam contoh ini, anggaran disrupsi pod dikonfigurasi untuk mengindikasikan min-available, tetapi PDB juga dapat dikonfigurasi untuk menentukan max-unavailable. Kedua nilai tersebut dapat dinyatakan sebagai bilangan bulat yang mewakili jumlah pod, atau persentase dari total pod.

Selamat!

Anda telah mempelajari cara membuat load balancer berbasis container melalui ingress untuk memanfaatkan load balancing dan pemilihan rute yang lebih efisien. Anda telah menjalankan uji load sederhana pada sebuah aplikasi GKE serta mengamati penggunaan CPU dan memori dasarnya, serta bagaimana aplikasi tersebut merespons lonjakan traffic. Selain itu, Anda juga mengonfigurasi pemeriksaan keaktifan dan kesiapan serta anggaran disrupsi pod untuk memastikan ketersediaan aplikasi Anda. Alat dan teknik ini bersama-sama berkontribusi pada efisiensi keseluruhan aplikasi Anda saat dijalankan di GKE dengan meminimalkan traffic jaringan yang tidak relevan, menentukan indikator yang efektif untuk menilai bahwa suatu aplikasi berperilaku baik, dan meningkatkan ketersediaan aplikasi.

Langkah berikutnya/Pelajari lebih lanjut

Lihat referensi berikut untuk mempelajari lebih lanjut topik yang dibahas dalam lab ini:

• Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE: Menyiapkan Aplikasi Kubernetes Berbasis Cloud

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 12 Maret 2024

Lab Terakhir Diuji pada 12 Maret 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.