Konsep Kubernetes

Menyebarkan aplikasi pada beberapa mesin (menggunakan wadah yang digunakan di Pod)

Pantau kesehatan wadah dan mulai ulang kontainer yang gagal

Skala kontainer naik dan turun berdasarkan beban

Perbarui wadah dengan versi baru

Mengalokasikan sumber daya antar kontainer

Menyeimbangkan lalu lintas di seluruh mesin

Containerized — Kubernetes adalah alat orkestrasi kontainer. Untuk menggunakan Kubernetes, Anda harus terlebih dahulu mengkontainer aplikasi Anda. Tergantung pada jenis aplikasi, ini bisa sebagai satu set layanan mikro, sebagai pekerjaan batch atau dalam bentuk lain. Kemudian, aplikasi Anda dapat memanfaatkan alur kerja Kubernetes yang mencakup ekosistem alat yang sangat besar, di mana kontainer dapat disimpan sebagai gambar dalam registri kontainer, diterapkan ke cluster Kubernetes , dan dijalankan pada node yang tersedia. https://kubernetes.io/docs/concepts/architecture/nodes/ Anda dapat membangun dan menguji container individual di komputer lokal Anda dengan Docker atau runtime container lainnya, sebelum menyebarkannya ke cluster Kubernetes Anda.

Dapat diskalakan — Jika permintaan untuk aplikasi Anda melebihi kapasitas instans yang sedang berjalan dari aplikasi tersebut, Kubernetes dapat meningkatkan skala. Sesuai kebutuhan, Kubernetes dapat mengetahui apakah aplikasi memerlukan lebih banyak CPU atau memori dan merespons dengan memperluas kapasitas yang tersedia secara otomatis atau menggunakan lebih banyak kapasitas yang ada. Penskalaan dapat dilakukan pada tingkat Pod, jika ada cukup komputasi yang tersedia untuk menjalankan lebih banyak instance aplikasi (penskalaan otomatis Pod horizontal), atau pada tingkat node, jika lebih banyak node perlu dibawa ke atas untuk menangani peningkatan kapasitas (Cluster Autoscaler atau Karpenter). https://karpenter.sh/ Karena kapasitas tidak lagi diperlukan, layanan ini dapat menghapus Pod yang tidak perlu dan mematikan node yang tidak diperlukan.

Tersedia — Jika aplikasi atau node menjadi tidak sehat atau tidak tersedia, Kubernetes dapat memindahkan beban kerja yang sedang berjalan ke node lain yang tersedia. Anda dapat memaksa masalah hanya dengan menghapus instance yang sedang berjalan dari beban kerja atau node yang menjalankan beban kerja Anda. Intinya di sini adalah bahwa beban kerja dapat dibawa di lokasi lain jika mereka tidak dapat lagi berjalan di tempat mereka berada.

Deklaratif — Kubernetes menggunakan rekonsiliasi aktif untuk terus-menerus memeriksa apakah status yang Anda deklarasikan untuk cluster Anda cocok dengan status sebenarnya. Dengan menerapkan objek Kubernetes ke cluster, biasanya melalui file YAML-formatted konfigurasi, Anda dapat, misalnya, meminta untuk memulai beban kerja yang ingin Anda jalankan di cluster Anda. Anda nantinya dapat mengubah konfigurasi untuk melakukan sesuatu seperti menggunakan versi kontainer yang lebih baru atau mengalokasikan lebih banyak memori. Kubernetes akan melakukan apa yang perlu dilakukan untuk menetapkan keadaan yang diinginkan. Ini dapat mencakup menaikkan atau menurunkan node, menghentikan dan memulai ulang beban kerja, atau menarik wadah yang diperbarui.

Dapat di komposisi — Karena aplikasi biasanya terdiri dari beberapa komponen, Anda ingin dapat mengelola satu set komponen ini (sering diwakili oleh beberapa wadah) bersama-sama. Sementara Docker Compose menawarkan cara untuk melakukan ini secara langsung dengan Docker, perintah Kubernetes Kompose dapat membantu Anda melakukannya dengan Kubernetes. Lihat Menerjemahkan File Compose Docker ke Sumber Daya Kubernetes untuk contoh cara melakukannya.

Dapat diperluas — Tidak seperti perangkat lunak berpemilik, proyek Kubernetes open source dirancang agar terbuka bagi Anda memperluas Kubernetes dengan cara apa pun yang Anda suka untuk memenuhi kebutuhan Anda. API dan file konfigurasi terbuka untuk modifikasi langsung. Third-parties didorong untuk menulis Peng ontrol mereka sendiri, untuk memperluas infrastruktur dan fitur pengguna akhir Kubernetes. Webhook memungkinkan Anda mengatur aturan cluster untuk menegakkan kebijakan dan beradaptasi dengan perubahan kondisi. Untuk ide selengkapnya tentang cara memperluas cluster Kubernetes, lihat Memperluas Kubernetes.

Portabel — Banyak organisasi telah menstandarisasi operasi mereka di Kubernetes karena memungkinkan mereka untuk mengelola semua kebutuhan aplikasi mereka dengan cara yang sama. Pengembang dapat menggunakan pipeline yang sama untuk membangun dan menyimpan aplikasi kontainer. Aplikasi tersebut kemudian dapat digunakan ke cluster Kubernetes yang berjalan di lokasi, di cloud, di terminal titik penjualan di restoran, atau pada perangkat IoT yang tersebar di lokasi jarak jauh perusahaan. Sifat open source-nya memungkinkan orang untuk mengembangkan distribusi Kubernetes khusus ini, bersama dengan alat yang diperlukan untuk mengelolanya.

Perangkat Keras — Jika Anda tidak memiliki perangkat keras yang tersedia untuk menjalankan Kubernetes sesuai kebutuhan Anda, penyedia cloud seperti AWS Amazon EKS dapat menghemat biaya di muka. Dengan Amazon EKS, ini berarti Anda dapat menggunakan sumber daya cloud terbaik yang ditawarkan oleh AWS, termasuk instans komputasi (Amazon Elastic Compute Cloud), lingkungan pribadi Anda sendiri (Amazon VPC), manajemen identitas dan izin pusat (IAM), dan penyimpanan (Amazon EBS). AWS mengelola komputer, jaringan, pusat data, dan semua komponen fisik lainnya yang diperlukan untuk menjalankan Kubernetes. Demikian juga, Anda tidak perlu merencanakan pusat data Anda untuk menangani kapasitas maksimum pada hari-hari dengan permintaan tertinggi Anda. Untuk Amazon EKS Anywhere, atau cluster Kubernetes lokal lainnya, Anda bertanggung jawab untuk mengelola infrastruktur yang digunakan dalam penerapan Kubernetes Anda, tetapi Anda masih dapat mengandalkan AWS untuk membantu Anda menjaga Kubernetes tetap mutakhir.

Manajemen pesawat kontrol — Amazon EKS mengelola keamanan dan ketersediaan bidang kontrol Kubernetes yang di AWS hosting, yang bertanggung jawab untuk menjadwalkan wadah, mengelola ketersediaan aplikasi, dan tugas utama lainnya, sehingga Anda dapat fokus pada beban kerja aplikasi Anda. Jika cluster Anda rusak, AWS harus memiliki sarana untuk mengembalikan cluster Anda ke status berjalan. Untuk Amazon EKS Anywhere, Anda akan mengelola pesawat kontrol sendiri.

Upgrade teruji — Saat Anda meningkatkan cluster Anda, Anda dapat mengandalkan Amazon EKS atau Amazon EKS Anywhere untuk menyediakan versi teruji dari distribusi Kubernetes mereka.

Add-onsAda ratusan proyek yang dibangun untuk memperluas dan bekerja dengan Kubernetes yang dapat Anda tambahkan ke infrastruktur cluster Anda atau gunakan untuk membantu menjalankan beban kerja Anda. Alih-alih membangun dan mengelola add-on itu sendiri, AWS menyediakan Add-on Amazon EKS yang dapat Anda gunakan dengan cluster Anda. Amazon EKS Anywhere menyediakan Paket Kurasi yang mencakup build dari banyak proyek open source populer. Jadi, Anda tidak perlu membangun perangkat lunak sendiri atau mengelola patch keamanan kritis, perbaikan bug, atau peningkatan. Demikian juga, jika default memenuhi kebutuhan Anda, biasanya sangat sedikit konfigurasi add-on tersebut yang diperlukan. Lihat Perluas Cluster untuk detail tentang memperluas cluster Anda dengan add-on.

Bidang kontrol ter AWS kelola — memastikan bahwa cluster Amazon EKS tersedia dan dapat diskalakan karena mengelola bidang kontrol untuk Anda dan membuatnya tersedia di seluruh Zona AWS Ketersediaan.

Manajemen simpul — Alih-alih menambahkan node secara manual, Anda dapat meminta Amazon EKS membuat node secara otomatis sesuai kebutuhan, menggunakan Grup Node Terkelola (lihatSederhanakan siklus hidup node dengan grup node terkelola) atau Karpenter. Grup Node Terkelola memiliki integrasi dengan Kubernet es Cluster Autoscaling. Dengan menggunakan alat manajemen node, Anda dapat memanfaatkan penghematan biaya, dengan hal-hal seperti Instans Spot dan konsolidasi node, serta ketersediaan, menggunakan fitur Pen jadwalan untuk mengatur cara beban kerja diterapkan dan node dipilih.

Jaringan cluster — Menggunakan CloudFormation template, eksctl mengatur jaringan antara komponen bidang kontrol dan bidang data (node) di cluster Kubernetes. Ini juga mengatur titik akhir di mana komunikasi internal dan eksternal dapat berlangsung. Lihat jaringan De-mystifying cluster untuk node pekerja Amazon EKS untuk detailnya. Komunikasi antara Pod di Amazon EKS dilakukan menggunakan Amazon EKS Pod Identities (lihatPelajari cara EKS Pod Identity memberikan akses Pod AWS layanan), yang menyediakan sarana untuk membiarkan Pod memanfaatkan metode AWS cloud untuk mengelola kredenSIAL dan izin.

Add-Ons— Amazon EKS menyelamatkan Anda dari keharusan membangun dan menambahkan komponen perangkat lunak yang biasa digunakan untuk mendukung cluster Kubernetes. Misalnya, saat Anda membuat cluster Amazon EKS dari Konsol Manajemen AWS, secara otomatis menambahkan Amazon EKS kube-proxy (Kelola kube-proxy di cluster Amazon EKS), plugin Amazon VPC CNI untuk Kubernetes (), dan add-on CoreDNS (Tetapkan IP ke Pod dengan Amazon VPC CNI). Mengelola CoreDNS untuk DNS di klaster Amazon EKS Lihat Add-on Amazon EKS lebih lanjut tentang add-on ini, termasuk daftar yang tersedia.

Berkomunikasi dengan komponen cluster (server API) — Server API (kube-apiserver) mengekspos API Kubernetes sehingga permintaan ke cluster dapat dibuat dari dalam dan luar cluster. Dengan kata lain, permintaan untuk menambah atau mengubah objek cluster (Pod, Layanan, Node, dan sebagainya) dapat berasal dari perintah luar, seperti permintaan dari kubectl untuk menjalankan Pod. Demikian juga, permintaan dapat dibuat dari server API ke komponen dalam cluster, seperti query ke kubelet layanan untuk status Pod.

Menyimpan data tentang cluster (penyimpanan nilai etcd kunci) - etcd Layanan ini menyediakan peran penting untuk melacak status cluster saat ini. Jika etcd layanan menjadi tidak dapat diakses, Anda tidak akan dapat memperbarui atau menanyakan status cluster, meskipun beban kerja akan terus berjalan untuk sementara waktu. Untuk alasan itu, cluster kritis biasanya memiliki beberapa instance etcd layanan yang seimbang dengan beban yang berjalan pada satu waktu dan melakukan pencadangan berkala dari penyimpanan nilai etcd kunci jika terjadi kehilangan atau kerusakan data. Perlu diingat bahwa, di Amazon EKS, ini semua ditangani untuk Anda secara otomatis secara default. Amazon EKS Anywhere menyediakan instruksi untuk pencadangan dan pemulihan https://anywhere.eks.amazonaws.com/docs/clustermgmt/etcd-backup-restore/ etcd. Lihat Model Data etcd untuk mempelajari cara etcd mengelola data.

Jadwal Pod ke node (Scheduler) — Permintaan untuk memulai atau menghentikan Pod di Kubernetes diarahkan ke Penjadwal Kubernetes (kube-scheduler). https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/ Karena cluster dapat memiliki beberapa node yang mampu menjalankan Pod, terserah Penjadwal untuk memilih node mana (atau node, dalam kasus replika) Pod harus dijalankan. Jika tidak ada cukup kapasitas yang tersedia untuk menjalankan Pod yang diminta pada node yang ada, permintaan akan gagal, kecuali Anda telah membuat ketentuan lain. Ketentuan tersebut dapat mencakup mengaktifkan layanan seperti Managed Node Groups (Sederhanakan siklus hidup node dengan grup node terkelola) atau Karpenter yang dapat secara otomatis memulai node baru untuk menangani beban kerja.

Menjaga komponen dalam keadaan yang diinginkan (Controller Manager) - Pengelola Pengontrol Kubernetes berjalan sebagai proses daemon (kube-controller-manager) untuk mengamati keadaan cluster dan membuat perubahan pada cluster untuk membangun kembali status yang diharapkan. Secara khusus, ada beberapa pengontrol yang mengawasi objek Kubernetes yang berbeda, yang meliputistatefulset-controller,,, endpoint-controller cronjob-controllernode-controller, dan lainnya.

Mengelola sumber daya cloud (Cloud Controller Manager) — Interaksi antara Kubernetes dan penyedia cloud yang melakukan permintaan untuk sumber daya pusat data yang mendasarinya ditangani oleh Cloud Controller Manager (cloud-controller-manager). Pengontrol yang dikelola oleh Cloud Controller Manager dapat menyertakan pengontrol rute (untuk menyiapkan rute jaringan cloud), pengontrol layanan (untuk menggunakan layanan penyeimbangan beban cloud), dan pengendali siklus hidup node (untuk menjaga node tetap sinkron dengan Kubernetes sepanjang siklus hidupnya).

Kelola setiap node (kubelet) — Server API berkomunikasi dengan layanan kubelet yang berjalan di setiap node untuk memastikan bahwa node terdaftar dengan benar dan Pod yang diminta oleh Penjadwal sedang berjalan. Kubelet dapat membaca manifes Pod dan mengatur volume penyimpanan atau fitur lain yang dibutuhkan oleh Pod pada sistem lokal. Ini juga dapat memeriksa kesehatan wadah yang berjalan secara lokal.

Jalankan kontainer pada node (runtime kontainer) — Runtime Con tainer pada setiap node mengelola kontainer yang diminta untuk setiap Pod yang ditugaskan ke node. Itu berarti bahwa ia dapat menarik gambar kontainer dari registri yang sesuai, menjalankan wadah, menghentikannya, dan menanggapi pertanyaan tentang wadah. Runtime wadah default adalah containerd. Pada Kubernetes 1.24, integrasi khusus Docker (dockershim) yang dapat digunakan sebagai runtime container dihapus dari Kubernetes. Meskipun Anda masih dapat menggunakan Docker untuk menguji dan menjalankan container di sistem lokal Anda, untuk menggunakan Docker dengan Kubernetes Anda sekarang harus Meng instal Mesin Docker pada setiap node untuk menggunakannya dengan Kubernetes.

Mengelola jaringan antar kontainer (kube-proxy) — Untuk dapat mendukung komunikasi antar Pod, Kubernetes menggunakan fitur yang disebut sebagai Layanan untuk mengatur jaringan Pod yang melacak alamat IP dan port yang terkait dengan Pod tersebut. Layanan kube-proxy berjalan di setiap node untuk memungkinkan komunikasi antar Pod berlangsung.

Gambar dasar — Sebuah image wadah dasar adalah wadah yang biasanya dibangun dari versi minimal sistem file sistem operasi (seperti Red Hat Enterprise Linux atau Ubuntu) atau sistem minimal yang ditingkatkan untuk menyediakan perangkat lunak untuk menjalankan jenis aplikasi tertentu (seperti aplikasi nodejs atau python).

Perangkat lunak aplikasi — Anda dapat menambahkan perangkat lunak aplikasi Anda ke wadah Anda dengan cara yang sama seperti Anda menambahkannya ke sistem Linux. Misalnya, di Dockerfile Anda, Anda dapat menjalankan npm dan yarn menginstal JavaScript aplikasi atau yum dan dnf menginstal paket RPM. Dengan kata lain, menggunakan perintah RUN di Dockerfile, Anda dapat menjalankan perintah apa pun yang tersedia di sistem file gambar dasar Anda untuk menginstal perangkat lunak atau mengkonfigurasi perangkat lunak di dalam gambar kontainer yang dihasilkan.

Petunjuk - Referensi Dockerfile menjelaskan instruksi yang dapat Anda tambahkan ke Dockerfile saat Anda mengkonfigurasinya. Ini termasuk instruksi yang digunakan untuk membangun apa yang ada di wadah itu sendiri (ADDatau COPY file dari sistem lokal), mengidentifikasi perintah untuk dijalankan ketika wadah dijalankan (CMDatauENTRYPOINT), dan menghubungkan wadah ke sistem yang dijalankannya (dengan mengidentifikasi yang akan dijalankan sebagai, lokal VOLUME untuk dipasang, atau port keEXPOSE). USER

Penyimpanan - Ketika wadah yang sedang berjalan dihentikan dan dihapus, penyimpanan data dalam wadah itu akan hilang, kecuali Anda mengatur penyimpanan yang lebih permanen. Kubernetes mendukung banyak jenis penyimpanan yang berbeda dan mengabstraksinya di bawah payung Volume. https://kubernetes.io/docs/concepts/storage/volumes/ Jenis penyimpanan termasuk CephFS, NFS, iSCSI , dan lainnya. Anda bahkan dapat menggunakan perangkat blok lokal dari komputer lokal. Dengan salah satu jenis penyimpanan yang tersedia dari cluster Anda, Anda dapat memasang volume penyimpanan ke titik pemasangan yang dipilih di sistem file wadah Anda. Volume Per https://kubernetes.io/docs/concepts/storage/persistent-volumes/ sistent adalah volume yang terus ada setelah Pod dihapus, sedangkan Volume Ephemeral dihapus saat Pod dihapus. Jika administrator cluster membuat kelas penyimpanan yang berbeda untuk cluster Anda, Anda mungkin memiliki opsi untuk memilih atribut penyimpanan yang Anda gunakan, seperti apakah volume dihapus atau direklamasi setelah digunakan, apakah volume akan diperluas jika lebih banyak ruang diperlukan, dan bahkan apakah volume tersebut memenuhi persyaratan kinerja tertentu.

Rahasia — Dengan membuat Rahasia tersedia untuk wadah dalam spesifikasi Pod, Anda dapat memberikan izin yang dibutuhkan kontainer tersebut untuk mengakses sistem file, database, atau aset terlindungi lainnya. Kunci, kata sandi, dan token adalah salah satu item yang dapat disimpan sebagai rahasia. Menggunakan rahasia membuatnya sehingga Anda tidak perlu menyimpan informasi ini dalam gambar wadah, tetapi hanya perlu membuat rahasia tersedia untuk menjalankan wadah. Mirip dengan rahasia ConfigMaps. A ConfigMap cenderung menyimpan informasi yang kurang penting, seperti pasangan kunci-nilai untuk mengonfigurasi layanan.

Sumber daya kontainer — Objek untuk konfigurasi kontainer lebih lanjut dapat mengambil bentuk konfigurasi sumber daya. Untuk setiap wadah, Anda dapat meminta jumlah memori dan CPU yang dapat digunakan, serta menempatkan batas jumlah total sumber daya yang dapat digunakan wadah. Lihat Manajemen Sumber Daya untuk Pod dan Kontainer untuk contoh.

Gang guan — Pod dapat terganggu tanpa sadar (node turun) atau secara sukarela (upgrade diinginkan). Dengan mengonfigurasi anggaran gangguan Pod, Anda dapat memberikan beberapa kontrol atas seberapa tersedia aplikasi Anda saat terjadi gangguan. Lihat Menentukan Anggaran Gang guan untuk aplikasi Anda untuk contoh.

Ruang nama — Kubernetes menyediakan cara yang berbeda untuk mengisolasi komponen Kubernetes dan beban kerja satu sama lain. Menjalankan semua Pod untuk aplikasi tertentu di Namespace yang sama adalah cara umum untuk mengamankan dan mengelola Pod tersebut bersama-sama. Anda dapat membuat ruang nama Anda sendiri untuk digunakan atau memilih untuk tidak menunjukkan namespace (yang menyebabkan Kubernetes menggunakan namespace). default Komponen bidang kontrol Kubernetes biasanya berjalan di namespace sistem ku be.

Aplikasi stateless — Aplikasi stateless tidak menyimpan data sesi klien, jadi sesi lain tidak perlu merujuk kembali ke apa yang terjadi pada sesi sebelumnya. Ini membuatnya lebih mudah untuk mengganti Pod dengan yang baru jika menjadi tidak sehat atau memindahkannya tanpa menyimpan status. Jika Anda menjalankan aplikasi stateless (seperti server web), Anda dapat menggunakan Deployment untuk menyebarkan Pod dan ReplicaSets. A ReplicaSet menentukan berapa banyak instance Pod yang ingin Anda jalankan secara bersamaan. Meskipun Anda dapat menjalankan ReplicaSet secara langsung, adalah umum untuk menjalankan replika langsung dalam Deployment, untuk menentukan berapa banyak replika Pod yang harus berjalan pada satu waktu.

Aplikasi stateful — Aplikasi stateful adalah aplikasi di mana identitas Pod dan urutan peluncuran Pod penting. Aplikasi ini membutuhkan penyimpanan persisten yang stabil dan perlu dikerahkan dan diskalakan secara konsisten. Untuk menerapkan aplikasi stateful di Kubernetes, Anda dapat menggunakan. StatefulSets Contoh aplikasi yang biasanya dijalankan sebagai a StatefulSet adalah database. Dalam a StatefulSet, Anda dapat menentukan replika, Pod dan wadahnya, volume penyimpanan untuk dipasang, dan lokasi dalam wadah tempat data disimpan. Lihat Menjalankan Aplikasi Status yang Direplikasi untuk contoh database yang digunakan sebagai. StatefulSet

Per-node Aplikasi — Ada kalanya Anda ingin menjalankan aplikasi pada setiap node di cluster Kubernetes Anda. Misalnya, pusat data Anda mungkin mengharuskan setiap komputer menjalankan aplikasi pemantauan atau layanan akses jarak jauh tertentu. Untuk Kubernetes, Anda dapat menggunakan a DaemonSet untuk memastikan bahwa aplikasi yang dipilih berjalan pada setiap node di cluster Anda.

Aplikasi berjalan sampai selesai — Ada beberapa aplikasi yang ingin Anda jalankan untuk menyelesaikan tugas tertentu. Ini bisa termasuk yang menjalankan laporan status bulanan atau membersihkan data lama. Ob jek Job dapat digunakan untuk mengatur aplikasi untuk memulai dan menjalankan, lalu keluar ketika tugas selesai. Sebuah CronJob objek memungkinkan Anda mengatur aplikasi untuk berjalan pada jam, menit, hari tertentu dalam sebulan, bulan, atau hari dalam seminggu, menggunakan struktur yang ditentukan oleh format crontab Linux.

Layanan — Karena Pod dapat berpindah ke node dan alamat yang berbeda, Pod lain yang perlu berkomunikasi dengan Pod pertama mungkin merasa sulit untuk menemukan di mana ia berada. Untuk mengatasi masalah ini, Kubernetes memungkinkan Anda mewakili aplikasi sebagai Layanan. https://kubernetes.io/docs/concepts/services-networking/service/ Dengan Layanan, Anda dapat mengidentifikasi Pod atau set Pod dengan nama tertentu, lalu menunjukkan port apa yang mengekspos layanan aplikasi tersebut dari Pod dan port apa yang dapat digunakan aplikasi lain untuk menghubungi layanan tersebut. Pod lain dalam cluster hanya dapat meminta Layanan berdasarkan nama dan Kubernetes akan mengarahkan permintaan itu ke port yang tepat untuk instance Pod yang menjalankan layanan itu.

Ingress — Ingress adalah apa yang dapat membuat aplikasi yang diwakili oleh Layanan Kubernetes tersedia untuk klien yang berada di luar cluster. Fitur dasar Ingress termasuk penyeimbang beban (dikelola oleh Ingress), pengontrol Ingress, dan aturan untuk perutean permintaan dari pengontrol ke Layanan. Ada beberapa Pengontrol Ingress yang dapat Anda pilih dengan Kubernetes.

Memulai dengan Amazon EKS — eksctl

Membuat cluster Amazon EKS

Menyebarkan aplikasi sampel di Linux

Mengatur dan memantau sumber daya cluster