Konsep Kubernetes

Menerapkan aplikasi pada beberapa mesin (menggunakan kontainer yang di-deploy di Pod)

Pantau kesehatan kontainer dan mulai ulang kontainer yang gagal

Skalakan kontainer ke atas dan ke bawah berdasarkan beban

Perbarui wadah dengan versi baru

Alokasikan sumber daya antar kontainer

Menyeimbangkan lalu lintas di seluruh mesin

Containerized — Kubernetes adalah alat orkestrasi kontainer. Untuk menggunakannyaKubernetes, Anda harus terlebih dahulu memiliki aplikasi Anda dalam wadah. Tergantung pada jenis aplikasi, ini bisa sebagai satu set layanan mikro, sebagai pekerjaan batch atau dalam bentuk lain. Kemudian, aplikasi Anda dapat memanfaatkan Kubernetes alur kerja yang mencakup ekosistem alat yang sangat besar, di mana kontainer dapat disimpan sebagai gambar dalam registri kontainer, disebarkan ke Kubernetescluster, dan dijalankan pada node yang tersedia. Anda dapat membuat dan menguji kontainer individual di komputer lokal Anda dengan Docker atau runtime kontainer lain, sebelum menerapkannya ke cluster AndaKubernetes.

Scalable — Jika permintaan untuk aplikasi Anda melebihi kapasitas instance yang sedang berjalan dari aplikasi tersebut, Kubernetes dapat ditingkatkan. Sesuai kebutuhan, Kubernetes dapat mengetahui apakah aplikasi membutuhkan 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 level 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 dimunculkan untuk menangani peningkatan kapasitas (Cluster Autoscaler atau Karpenter). Karena kapasitas tidak lagi diperlukan, layanan ini dapat menghapus Pod yang tidak perlu dan mematikan node yang tidak dibutuhkan.

Tersedia — Jika aplikasi atau node menjadi tidak sehat atau tidak tersedia, Kubernetes dapat memindahkan beban kerja yang berjalan ke node lain yang tersedia. Anda dapat memaksakan 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 diangkat 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 klaster Anda cocok dengan status sebenarnya. Dengan menerapkan Kubernetesobjek ke kluster, biasanya melalui file konfigurasi YAML yang diformat, 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. Kubernetesakan melakukan apa yang perlu dilakukan untuk menetapkan keadaan yang diinginkan. Ini dapat mencakup membawa node ke atas atau ke bawah, menghentikan dan memulai ulang beban kerja, atau menarik kontainer yang diperbarui.

Composable — Karena aplikasi biasanya terdiri dari beberapa komponen, Anda ingin dapat mengelola satu set komponen ini (sering diwakili oleh beberapa kontainer) bersama-sama. Meskipun Docker Compose menawarkan cara untuk melakukan ini secara langsungDocker, perintah Kubernetes Kompose dapat membantu Anda melakukannya. Kubernetes Lihat Menerjemahkan File Docker Tulis ke Kubernetes Sumber Daya untuk contoh cara melakukannya.

Extensible — Tidak seperti perangkat lunak berpemilik, Kubernetes proyek open source dirancang untuk terbuka bagi Anda memperluas cara Kubernetes apa pun yang Anda inginkan untuk memenuhi kebutuhan Anda. APIsdan file konfigurasi terbuka untuk modifikasi langsung. Pihak ketiga didorong untuk menulis Controller mereka sendiri, untuk memperluas infrastruktur dan prestasi pengguna akhirKubernetes. Webhooks memungkinkan Anda menyiapkan aturan klaster untuk menegakkan kebijakan dan beradaptasi dengan perubahan kondisi. Untuk ide lebih lanjut tentang cara memperluas Kubernetes cluster, lihat Memperluas Kubernetes.

Portable — Banyak organisasi telah menstandarisasi operasi mereka 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 Kubernetes cluster yang berjalan di tempat, di awan, di point-of-sales terminal di restoran, atau pada IOT perangkat yang tersebar di seluruh situs jarak jauh perusahaan. Sifat open source-nya memungkinkan orang untuk mengembangkan Kubernetes distribusi khusus ini, bersama dengan alat yang diperlukan untuk mengelolanya.

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

Manajemen bidang kontrol — Amazon EKS mengelola keamanan dan ketersediaan bidang Kubernetes kontrol yang AWS di-host, yang bertanggung jawab untuk menjadwalkan kontainer, 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 memulihkan cluster Anda ke status berjalan. Untuk Amazon EKS Anywhere, Anda akan mengelola sendiri pesawat kontrol.

Upgrade yang diuji - Saat Anda meningkatkan klaster, Anda dapat mengandalkan Amazon atau EKS Amazon EKS Anywhere untuk menyediakan versi distribusi yang diuji. Kubernetes

Add-on — Ada ratusan proyek yang dibangun untuk memperluas dan bekerja dengan Kubernetes yang dapat Anda tambahkan ke infrastruktur klaster Anda atau gunakan untuk membantu menjalankan beban kerja Anda. Alih-alih membangun dan mengelola sendiri add-on tersebut, AWS sediakan EKSAdd-on Amazon yang dapat Anda gunakan dengan cluster Anda. Amazon EKS Anywhere menyediakan Paket Terkurasi yang mencakup pembuatan 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 konfigurasi yang sangat sedikit dari add-on tersebut diperlukan. Lihat Memperluas Cluster untuk detail tentang memperluas klaster Anda dengan add-on.

Bidang kontrol terkelola — AWS memastikan bahwa EKS klaster Amazon tersedia dan dapat diskalakan karena mengelola bidang kontrol untuk Anda dan membuatnya tersedia di seluruh AWS Availability Zone.

Manajemen node - Alih-alih menambahkan node secara manual, Anda dapat meminta Amazon EKS membuat node secara otomatis sesuai kebutuhan, menggunakan Grup Node Terkelola atau Karpenter. Grup Node Terkelola memiliki integrasi dengan Kubernetes Cluster Autoscaling. Menggunakan alat manajemen node, Anda dapat memanfaatkan penghematan biaya, dengan hal-hal seperti Instans Spot dan konsolidasi node, dan ketersediaan, menggunakan fitur Penjadwalan untuk mengatur bagaimana beban kerja diterapkan dan node dipilih.

Jaringan cluster — Menggunakan CloudFormation template, eksctl mengatur jaringan antara bidang kontrol dan komponen bidang data (node) di Kubernetes cluster. Ini juga mengatur titik akhir di mana komunikasi internal dan eksternal dapat berlangsung. Lihat Mende-mistifikasi jaringan cluster untuk node EKS pekerja Amazon untuk detailnya. Komunikasi antar Pod di Amazon EKS dilakukan dengan menggunakan Amazon EKS Pod Identities, yang menyediakan sarana untuk membiarkan Pod memanfaatkan metode AWS cloud untuk mengelola kredensyal dan izin.

Add-On — Amazon EKS menyelamatkan Anda dari keharusan membangun dan menambahkan komponen perangkat lunak yang biasa digunakan untuk mendukung Kubernetes cluster. Misalnya, ketika Anda membuat EKS klaster Amazon dari konsol AWS Manajemen, secara otomatis menambahkan EKS kube-proxy Amazon, VPC CNI plugin Amazon untukKubernetes, dan add-on Core. DNS Lihat EKSadd-on Amazon untuk informasi lebih lanjut tentang add-on ini, termasuk daftar yang tersedia.

Berkomunikasi dengan komponen cluster (APIserver) — API Server (kube-apiserver) mengekspos Kubernetes API sehingga permintaan ke cluster dapat dibuat baik dari dalam maupun luar cluster. Dengan kata lain, permintaan untuk menambah atau mengubah objek klaster (Pod, Services, Nodes, dan sebagainya) dapat berasal dari perintah luar, seperti permintaan dari kubectl untuk menjalankan Pod. Demikian juga, permintaan dapat dibuat dari API server 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 keadaan cluster saat ini. Jika etcd layanan menjadi tidak dapat diakses, Anda tidak akan dapat memperbarui atau menanyakan status klaster, meskipun beban kerja akan terus berjalan untuk sementara waktu. Untuk alasan itu, cluster kritis biasanya memiliki beberapa instance etcd layanan yang seimbang beban yang berjalan pada satu waktu dan melakukan pencadangan berkala dari penyimpanan nilai etcd kunci jika terjadi kehilangan atau kerusakan data. Ingatlah bahwa, di AmazonEKS, ini semua ditangani untuk Anda secara otomatis secara default. Amazon EKS Anywhere menyediakan instruksi untuk pencadangan dan pemulihan etcd. Lihat Model etcd Data untuk mempelajari cara etcd mengelola data.

Jadwalkan Pod ke Node (Scheduler) — Permintaan untuk memulai atau menghentikan Pod di Kubernetes diarahkan ke KubernetesScheduler (kube-scheduler). Karena sebuah cluster dapat memiliki beberapa node yang mampu menjalankan Pod, maka terserah Scheduler untuk memilih node (atau node, dalam kasus replika) Pod mana yang harus dijalankan. Jika tidak ada kapasitas yang cukup 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 Grup Node Terkelola atau Karpenter yang dapat secara otomatis memulai node baru untuk menangani beban kerja.

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

Mengelola sumber daya cloud (Cloud Controller Manager) — Interaksi antara Kubernetes dan penyedia cloud yang melakukan permintaan 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 pengontrol siklus hidup node (untuk menjaga node tetap sinkron dengan Kubernetes sepanjang siklus hidupnya).

Manage each node (kubelet) — API Server berkomunikasi dengan layanan kubelet yang berjalan pada setiap node untuk memastikan bahwa node terdaftar dengan benar dan Pod yang diminta oleh Scheduler 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 sebuah node (container runtime) — Container Runtime pada setiap node mengelola kontainer yang diminta untuk setiap Pod yang ditetapkan ke node. Itu berarti ia dapat menarik gambar kontainer dari registri yang sesuai, menjalankan penampung, menghentikannya, dan menanggapi kueri tentang wadah. Runtime kontainer default adalah containerd. Pada Kubernetes 1.24, integrasi khusus Docker (dockershim) yang dapat digunakan sebagai runtime kontainer dibatalkan dari. Kubernetes Meskipun Anda masih dapat menggunakan Docker untuk menguji dan menjalankan kontainer di sistem lokal Kubernetes Anda, untuk menggunakannya Docker sekarang Anda harus Menginstal Docker Mesin pada setiap node untuk menggunakannyaKubernetes.

Mengelola jaringan antar kontainer (kube-proxy) — Untuk dapat mendukung komunikasi antar Pod menggunakan Layanan, Kubernetes diperlukan cara untuk menyiapkan jaringan Pod untuk melacak alamat IP dan port yang terkait dengan Pod tersebut. Layanan kube-proxy berjalan pada setiap node untuk memungkinkan komunikasi antar Pod berlangsung.

Sebuah image dasar (base container image) adalah wadah yang biasanya dibangun dari versi minimal dari 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 aplikasi Java atau yum dan dnf untuk menginstal RPM paket. Dengan kata lain, menggunakan RUN perintah 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.

Instruksi — Referensi Dockerfile menjelaskan instruksi yang dapat Anda tambahkan ke Dockerfile saat Anda mengonfigurasinya. 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 USER untuk dijalankan sebagai, lokal VOLUME untuk dipasang, atau port keEXPOSE).

Penyimpanan — Ketika wadah yang sedang berjalan dihentikan dan dihapus, penyimpanan data dalam wadah itu akan hilang, kecuali jika Anda mengatur penyimpanan yang lebih permanen. Kubernetesmendukung banyak jenis penyimpanan yang berbeda dan mengabstraksinya di bawah payung Volume. Jenis penyimpanan termasuk CephFS,, i NFSSCSI, 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 container Anda. Volume Persisten adalah salah satu yang terus ada setelah Pod dihapus, sementara Volume Ephemeral dihapus ketika Pod dihapus. Jika administrator klaster Anda membuat yang berbeda StorageClassesuntuk klaster Anda, Anda mungkin memiliki opsi untuk memilih atribut penyimpanan yang Anda gunakan, seperti apakah volume dihapus atau direklamasi setelah digunakan, apakah itu akan diperluas jika lebih banyak ruang diperlukan, dan bahkan apakah itu memenuhi persyaratan kinerja tertentu.

Secrets — Dengan membuat Secrets tersedia untuk container dalam spesifikasi Pod, Anda dapat memberikan izin yang dibutuhkan container tersebut untuk mengakses sistem file, basis data, atau aset lain yang dilindungi. 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 kontainer, tetapi hanya perlu membuat rahasia tersedia untuk menjalankan wadah. Mirip dengan Rahasia adalah ConfigMaps. A ConfigMap cenderung menyimpan informasi yang kurang penting, seperti pasangan nilai kunci untuk mengonfigurasi layanan.

Sumber daya kontainer — Objek untuk mengkonfigurasi kontainer lebih lanjut dapat berbentuk konfigurasi sumber daya. Untuk setiap kontainer, 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 Container untuk contoh.

Gangguan — Pod dapat terganggu secara tidak sengaja (sebuah node turun) atau secara sukarela (upgrade diinginkan). Dengan mengonfigurasi anggaran gangguan Pod, Anda dapat mengontrol seberapa tersedia aplikasi Anda saat terjadi gangguan. Lihat Menentukan Anggaran Gangguan untuk aplikasi Anda untuk contoh.

Namespaces — Kubernetes menyediakan berbagai cara untuk mengisolasi Kubernetes komponen 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 penggunaan namespace). default Kuberneteskomponen bidang kontrol biasanya berjalan di kube-systemnamespace.

Aplikasi stateless — Aplikasi stateless tidak menyimpan data sesi klien, jadi sesi lain tidak perlu merujuk kembali ke apa yang terjadi pada sesi sebelumnya. Ini membuat 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 mendefinisikan berapa banyak instance dari sebuah Pod yang ingin Anda jalankan secara bersamaan. Meskipun Anda dapat menjalankan ReplicaSet secara langsung, adalah umum untuk menjalankan replika secara langsung di dalam Deployment, untuk menentukan berapa banyak replika Pod yang harus dijalankan pada satu waktu.

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

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

Aplikasi berjalan hingga selesai — Ada beberapa aplikasi yang ingin Anda jalankan untuk menyelesaikan tugas tertentu. Ini bisa termasuk yang menjalankan laporan status bulanan atau membersihkan data lama. Objek Job dapat digunakan untuk menyiapkan aplikasi untuk memulai dan menjalankan, lalu keluar ketika tugas selesai. CronJobObjek memungkinkan Anda mengatur aplikasi untuk berjalan pada jam, menit, hari tertentu dalam sebulan, bulan, atau hari dalam seminggu, menggunakan struktur yang ditentukan oleh crontabformat Linux.

Services — Karena sebuah Pod dapat berpindah ke node dan alamat yang berbeda, Pod lain yang perlu berkomunikasi dengan Pod pertama dapat merasa sulit untuk menemukan di mana Pod tersebut berada. Untuk mengatasi masalah ini, Kubernetes memungkinkan Anda mewakili aplikasi sebagai Layanan. Dengan Service, Anda dapat mengidentifikasi Pod atau kumpulan Pod dengan nama tertentu, kemudian menunjukkan port apa yang mengekspos layanan aplikasi tersebut dari Pod dan port apa yang dapat digunakan aplikasi lain untuk menghubungi layanan tersebut. Pod lain di dalam klaster dapat dengan mudah meminta Service dengan nama dan Kubernetes akan mengarahkan permintaan tersebut ke port yang tepat untuk sebuah instance dari Pod yang menjalankan layanan tersebut.

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

Buat cluster sederhana

Buat cluster yang lebih kompleks

Menyebarkan aplikasi sampel

Jelajahi cara mengelola klaster Anda