Konsep Kubernetes

Amazon Elastic Kubernetes Service (Amazon EKS) AWS adalah layanan terkelola berdasarkan proyek Kubernetes open source. Meskipun ada hal-hal yang perlu Anda ketahui tentang bagaimana layanan Amazon EKS terintegrasi dengan AWS Cloud (terutama ketika Anda pertama kali membuat kluster Amazon EKS), setelah aktif dan berjalan, Anda menggunakan cluster Amazon EKS Anda dengan cara yang sama seperti yang Anda lakukan pada cluster Kubernetes lainnya. Jadi untuk mulai mengelola klaster Kubernetes dan menerapkan beban kerja, Anda memerlukan setidaknya pemahaman dasar tentang konsep Kubernetes.

Halaman ini membagi konsep Kubernetes menjadi tiga bagian:Mengapa Kubernetes?,, dan. Klaster Beban kerja Bagian pertama menjelaskan nilai menjalankan layanan Kubernetes, khususnya sebagai layanan terkelola seperti Amazon EKS. Bagian Beban Kerja mencakup bagaimana aplikasi Kubernetes dibangun, disimpan, dijalankan, dan dikelola. Bagian Cluster menjabarkan berbagai komponen yang membentuk klaster Kubernetes dan apa tanggung jawab Anda untuk membuat dan memelihara klaster Kubernetes.

Saat Anda membaca konten ini, tautan akan mengarahkan Anda ke deskripsi lebih lanjut tentang konsep Kubernetes dalam dokumentasi Amazon EKS dan Kubernetes, jika Anda ingin menyelami topik apa pun yang kami bahas di sini. Untuk detail tentang cara Amazon EKS mengimplementasikan bidang kontrol Kubernetes dan fitur komputasi, lihat. Arsitektur Amazon EKS

Mengapa Kubernetes?

Kubernetes dirancang untuk meningkatkan ketersediaan dan skalabilitas saat menjalankan aplikasi kontainer berkualitas produksi yang kritis terhadap misi. Daripada hanya menjalankan Kubernetes pada satu mesin (meskipun itu mungkin), Kubernetes mencapai tujuan tersebut dengan memungkinkan Anda menjalankan aplikasi di seluruh rangkaian komputer yang dapat memperluas atau mengontrak untuk memenuhi permintaan. Kubernetes menyertakan fitur-fitur yang memudahkan Anda untuk:

• 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

Memiliki Kubernetes mengotomatiskan jenis tugas kompleks ini memungkinkan pengembang aplikasi untuk fokus membangun dan meningkatkan beban kerja aplikasi mereka, daripada mengkhawatirkan infrastruktur. Pengembang biasanya membuat file konfigurasi, diformat sebagai file YAMG, yang menggambarkan keadaan aplikasi yang diinginkan. Ini dapat mencakup kontainer mana yang akan dijalankan, batas sumber daya, jumlah replika Pod, alokasi CPU/memori, aturan afinitas, dan banyak lagi.

Atribut Kubernetes

Untuk mencapai tujuannya, Kubernetes memiliki atribut berikut:

• Containerized - Kubernetes adalah alat orkestrasi kontainer. Untuk menggunakan Kubernetes, Anda harus terlebih dahulu memiliki aplikasi Anda dalam kontainerisasi. 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, di-deploy ke cluster Kubernetes, dan dijalankan pada node yang tersedia. Anda dapat membangun dan menguji kontainer individual di komputer lokal Anda dengan Docker atau runtime kontainer lain, sebelum menerapkannya ke cluster Kubernetes Anda.

• Scalable — 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 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 tingkat Pod, jika ada cukup komputasi yang tersedia untuk menjalankan lebih banyak instance aplikasi (horizontal Pod autoscaling), atau pada tingkat node, jika lebih banyak node perlu dibawa ke atas 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.

• Available — 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 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 objek Kubernetes ke cluster, biasanya melalui file konfigurasi berformat YAML, 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 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. Sementara Docker Compose menawarkan cara untuk melakukan ini secara langsung dengan Docker, perintah Kubernetes Kompose dapat membantu Anda melakukannya dengan Kubernetes. Lihat Translate a Docker Compose File ke Kubernetes Resources untuk contoh cara melakukannya.

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

• Portable — 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 diterapkan ke klaster Kubernetes yang berjalan di lokasi, di cloud, di point-of-sales terminal di restoran, atau pada perangkat IOT yang tersebar di seluruh situs jarak jauh perusahaan. Sifat open source-nya memungkinkan orang untuk mengembangkan distribusi Kubernetes khusus ini, bersama dengan alat yang diperlukan untuk mengelolanya.

Mengelola Kubernetes

Kode sumber Kubernetes tersedia secara bebas, jadi dengan peralatan Anda sendiri, Anda dapat menginstal dan mengelola Kubernetes sendiri. Namun, Kubernetes yang mengelola sendiri membutuhkan keahlian operasional yang mendalam dan membutuhkan waktu dan upaya untuk mempertahankannya. Karena alasan tersebut, kebanyakan orang yang menerapkan beban kerja produksi memilih penyedia cloud (seperti Amazon EKS) atau penyedia lokal (seperti Amazon EKS Anywhere) dengan distribusi Kubernetes yang telah diuji sendiri dan dukungan para ahli Kubernetes. Ini memungkinkan Anda untuk menurunkan banyak angkat berat yang tidak berdiferensiasi yang diperlukan untuk mempertahankan cluster Anda, termasuk:

• Hardware — 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 komputer (Amazon Elastic Compute Cloud), lingkungan pribadi Anda sendiri (Amazon VPC), identitas pusat dan manajemen izin (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 permintaan tertinggi Anda. Untuk Amazon EKS Anywhere, atau cluster Kubernetes lainnya di premis, Anda bertanggung jawab untuk mengelola infrastruktur yang digunakan dalam penerapan Kubernetes Anda, tetapi Anda masih dapat mengandalkan AWS untuk membantu Anda menjaga Kubernetes tetap up to date.

• Manajemen pesawat kontrol — Amazon EKS mengelola keamanan dan ketersediaan pesawat kontrol Kubernetes yang AWS di-host, yang bertanggung jawab untuk menjadwalkan kontainer, mengelola ketersediaan aplikasi, dan tugas-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 meng-upgrade klaster, Anda dapat mengandalkan Amazon EKS atau Amazon EKS Anywhere untuk menyediakan versi distribusi Kubernetes mereka yang telah diuji.

• 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 add-on itu sendiri, AWS sediakan Add-on Amazon EKS 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 Perluas Cluster detail tentang memperluas klaster Anda dengan add-on.

Kubernetes beraksi

Diagram berikut menunjukkan aktivitas utama yang akan Anda lakukan sebagai Admin Kubernetes atau Pengembang Aplikasi untuk membuat dan menggunakan klaster Kubernetes. Dalam prosesnya, ini menggambarkan bagaimana komponen Kubernetes berinteraksi satu sama lain, menggunakan AWS cloud sebagai contoh penyedia cloud yang mendasarinya.

Admin Kubernetes membuat klaster Kubernetes menggunakan alat khusus untuk jenis penyedia tempat klaster akan dibangun. Contoh ini menggunakan AWS cloud sebagai penyedia, yang menawarkan layanan Kubernetes terkelola yang disebut Amazon EKS. Layanan terkelola secara otomatis mengalokasikan sumber daya yang diperlukan untuk membuat klaster, termasuk membuat dua Virtual Private Clouds VPCs (Amazon) baru untuk klaster, menyiapkan jaringan, dan memetakan izin Kubernetes langsung ke yang baru untuk manajemen aset cloud. VPCs Layanan terkelola juga melihat bahwa layanan pesawat kontrol memiliki tempat untuk dijalankan dan mengalokasikan nol atau lebih EC2 instance Amazon sebagai node Kubernetes untuk menjalankan beban kerja. AWS mengelola satu VPC Amazon itu sendiri untuk bidang kontrol, sedangkan VPC Amazon lainnya berisi node pelanggan yang menjalankan beban kerja.

Banyak tugas Admin Kubernetes ke depan dilakukan dengan menggunakan alat Kubernetes seperti. kubectl Alat itu membuat permintaan layanan langsung ke bidang kontrol cluster. Cara kueri dan perubahan dibuat ke cluster kemudian sangat mirip dengan cara Anda melakukannya di klaster Kubernetes mana pun.

Pengembang aplikasi yang ingin menyebarkan beban kerja ke cluster ini dapat melakukan beberapa tugas. Pengembang perlu membangun aplikasi menjadi satu atau beberapa gambar kontainer, lalu mendorong gambar tersebut ke registri kontainer yang dapat diakses oleh cluster Kubernetes. AWS menawarkan Amazon Elastic Container Registry (Amazon ECR) Registry ECR) untuk tujuan itu.

Untuk menjalankan aplikasi, pengembang dapat membuat file konfigurasi berformat YAML yang memberi tahu cluster cara menjalankan aplikasi, termasuk kontainer mana yang akan ditarik dari registri dan cara membungkus kontainer tersebut dalam Pod. Bidang kontrol (scheduler) menjadwalkan kontainer ke satu atau lebih node dan runtime kontainer pada setiap node benar-benar menarik dan menjalankan kontainer yang diperlukan. Pengembang juga dapat mengatur penyeimbang beban aplikasi untuk menyeimbangkan lalu lintas ke kontainer yang tersedia yang berjalan pada setiap node dan mengekspos aplikasi sehingga tersedia di jaringan publik ke dunia luar. Dengan semua itu dilakukan, seseorang yang ingin menggunakan aplikasi dapat terhubung ke titik akhir aplikasi untuk mengaksesnya.

Bagian berikut membahas detail masing-masing fitur ini, dari perspektif Kubernetes Clusters dan Workloads.

Klaster

Jika tugas Anda adalah memulai dan mengelola klaster Kubernetes, Anda harus tahu bagaimana klaster Kubernetes dibuat, ditingkatkan, dikelola, dan dihapus. Anda juga harus tahu komponen apa yang membentuk cluster dan apa yang perlu Anda lakukan untuk mempertahankan komponen tersebut.

Alat untuk mengelola klaster menangani tumpang tindih antara layanan Kubernetes dan penyedia perangkat keras yang mendasarinya. Untuk alasan itu, otomatisasi tugas-tugas ini cenderung dilakukan oleh penyedia Kubernetes (seperti Amazon EKS atau Amazon EKS Anywhere) menggunakan alat yang khusus untuk penyedia. Misalnya, untuk memulai kluster Amazon EKS Anda dapat menggunakaneksctl create cluster, sedangkan untuk Amazon EKS Anywhere Anda dapat menggunakaneksctl anywhere create cluster. Perhatikan bahwa sementara perintah ini membuat cluster Kubernetes, mereka khusus untuk penyedia dan bukan bagian dari proyek Kubernetes itu sendiri.

Pembuatan klaster dan alat manajemen

Proyek Kubernetes menawarkan alat untuk membuat klaster Kubernetes secara manual. Jadi jika Anda ingin menginstal Kubernetes pada satu mesin, atau menjalankan bidang kontrol pada mesin dan menambahkan node secara manual, Anda dapat menggunakan alat CLI seperti kind, minikube, atau kubeadm yang terdaftar di bawah Kubernetes Install Tools. Untuk menyederhanakan dan mengotomatiskan siklus hidup penuh pembuatan dan pengelolaan klaster, jauh lebih mudah untuk menggunakan alat yang didukung oleh penyedia Kubernetes yang sudah mapan, seperti Amazon EKS atau Amazon EKS Anywhere.

Di AWS Cloud, Anda dapat membuat kluster Amazon EKS menggunakan alat CLI, seperti eksctl, atau alat deklaratif lainnya, seperti Terraform (lihat Amazon EKS Blueprints for Terraform). Anda juga dapat membuat cluster dari AWS Management Console. Lihat fitur Amazon EKS untuk daftar apa yang Anda dapatkan dengan Amazon EKS. Tanggung jawab Kubernetes yang diambil Amazon EKS untuk Anda meliputi:

• Bidang kontrol terkelola —AWS memastikan bahwa klaster Amazon EKS 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 (lihatSederhanakan siklus hidup node dengan 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 menyiapkan jaringan antara control plane dan komponen data plane (node) di cluster Kubernetes. Ini juga mengatur titik akhir di mana komunikasi internal dan eksternal dapat berlangsung. Lihat De-mystifying jaringan cluster untuk node pekerja Amazon EKS untuk detailnya. Komunikasi antar Pod di Amazon EKS dilakukan dengan menggunakan Amazon EKS Pod Identities (lihatPelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS), 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 klaster Kubernetes. Misalnya, ketika Anda membuat klaster Amazon EKS dari AWS Management Console, secara otomatis akan menambahkan Amazon EKS kube-proxy ()Kelola kube-proxy di kluster Amazon EKS, plugin Amazon VPC CNI untuk Kubernetes (), dan add-on CoreDNS ()Tetapkan IPs ke Pod dengan Amazon VPC CNI. Kelola CoreDNS untuk DNS di kluster Amazon EKS Lihat lebih Add-on Amazon EKS lanjut tentang add-on ini, termasuk daftar yang tersedia.

Untuk menjalankan cluster Anda di komputer dan jaringan lokal Anda sendiri, Amazon menawarkan Amazon EKS Anywhere. Alih-alih AWS Cloud menjadi penyedia, Anda memiliki pilihan untuk menjalankan Amazon EKS Anywhere di VMWare vSphere, bare metal (penyedia Tinkerbell), Snow CloudStack, atau platform Nutanix menggunakan peralatan Anda sendiri.

Amazon EKS Anywhere didasarkan pada perangkat lunak Amazon EKS Distro yang sama yang digunakan oleh Amazon EKS. Namun, Amazon EKS Anywhere mengandalkan implementasi yang berbeda dari antarmuka Kubernetes Cluster API (CAPI) untuk mengelola siklus hidup penuh mesin di klaster Amazon EKS Anywhere (seperti CAPV untuk vSphere dan CAPC for). CloudStack Karena seluruh cluster berjalan pada peralatan Anda, Anda mengambil tanggung jawab tambahan untuk mengelola bidang kontrol dan mencadangkan datanya (lihat etcd nanti di dokumen ini).

Komponen cluster

Komponen cluster Kubernetes dibagi menjadi dua area utama: control plane dan worker node. Control Plane Components mengelola cluster dan menyediakan akses ke miliknya APIs. Node pekerja (kadang-kadang hanya disebut sebagai Nodes) menyediakan tempat di mana beban kerja yang sebenarnya dijalankan. Komponen Node terdiri dari layanan yang berjalan pada setiap node untuk berkomunikasi dengan bidang kontrol dan menjalankan kontainer. Kumpulan node pekerja untuk cluster Anda disebut sebagai Data Plane.

Bidang kontrol

Bidang kontrol terdiri dari satu set layanan yang mengelola cluster. Layanan ini semua mungkin berjalan pada satu komputer atau dapat tersebar di beberapa komputer. Secara internal, ini disebut sebagai Control Plane Instances ()CPIs. Bagaimana CPIs dijalankan tergantung pada ukuran cluster dan persyaratan untuk ketersediaan tinggi. Seiring meningkatnya permintaan di klaster, layanan pesawat kontrol dapat menskalakan untuk menyediakan lebih banyak contoh layanan tersebut, dengan permintaan diseimbangkan beban di antara instans.

Tugas yang dilakukan oleh komponen-komponen dari bidang kontrol Kubernetes meliputi:

• Berkomunikasi dengan komponen cluster (API server) — Server API (kube-apiserver) mengekspos API Kubernetes 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 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 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 Amazon EKS, ini semua ditangani untuk Anda secara otomatis secara default. Amazon EKS Anywhere menyediakan instruksi untuk pencadangan dan pemulihan etcd. Lihat Model Data etcd untuk mempelajari cara etcd mengelola data.

• Schedule Pods to Nodes (Scheduler) — Permintaan untuk memulai atau menghentikan Pod di Kubernetes diarahkan ke Kubernetes Scheduler (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 Managed Node Groups (Sederhanakan siklus hidup node dengan grup node terkelola) atau Karpenter yang dapat secara otomatis memulai node baru untuk menangani beban kerja.

• Menyimpan komponen dalam keadaan yang diinginkan (Controller Manager) — Kubernetes Controller Manager berjalan sebagai proses daemon (kube-controller-manager) untuk melihat status klaster dan membuat perubahan pada cluster untuk membangun kembali status yang diharapkan. Secara khusus, ada beberapa pengontrol yang mengawasi objek Kubernetes yang berbeda, yang mencakup a,,statefulset-controller, endpoint-controllercronjob-controller, node-controller dan lainnya.

• Kelola 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).

Node Pekerja (bidang data)

Untuk klaster Kubernetes simpul tunggal, beban kerja berjalan pada mesin yang sama dengan bidang kontrol. Namun, konfigurasi yang lebih standar adalah memiliki satu atau lebih sistem komputer terpisah (Node) yang didedikasikan untuk menjalankan beban kerja Kubernetes.

Ketika Anda pertama kali membuat klaster Kubernetes, beberapa alat pembuatan klaster memungkinkan Anda untuk mengonfigurasi sejumlah node tertentu untuk ditambahkan ke cluster (baik dengan mengidentifikasi sistem komputer yang ada atau dengan meminta penyedia membuat yang baru). Sebelum beban kerja ditambahkan ke sistem tersebut, layanan ditambahkan ke setiap node untuk mengimplementasikan fitur-fitur ini:

• Manage each node (kubelet) — Server API 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 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 Menginstal Docker Engine 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 menyiapkan jaringan Pod yang melacak alamat IP dan port yang terkait dengan Pod tersebut. Layanan kube-proxy berjalan pada setiap node untuk memungkinkan komunikasi antar Pod berlangsung.

Perluas Cluster

Ada beberapa layanan yang dapat Anda tambahkan ke Kubernetes untuk mendukung cluster, tetapi tidak dijalankan di bidang kontrol. Layanan ini sering berjalan langsung pada node di namespace sistem kube atau di namespace sendiri (seperti yang sering dilakukan dengan penyedia layanan pihak ketiga). Contoh umum adalah layanan CoreDNS, yang menyediakan layanan DNS ke cluster. Lihat Menemukan layanan bawaan untuk informasi tentang cara melihat layanan klaster mana yang berjalan di kube-system di klaster Anda.

Ada berbagai jenis add-on yang dapat Anda pertimbangkan untuk ditambahkan ke cluster Anda. Agar klaster tetap sehat, Anda dapat menambahkan fitur observabilitas (lihatPantau kinerja klaster Anda dan lihat log) yang memungkinkan Anda melakukan hal-hal seperti pencatatan, audit, dan metrik. Dengan informasi ini, Anda dapat memecahkan masalah yang terjadi, seringkali melalui antarmuka observabilitas yang sama. Contoh jenis layanan ini termasuk Amazon GuardDuty, CloudWatch (lihatPantau data cluster dengan Amazon CloudWatch), AWS Distro for, plugin Amazon VPC CNI untuk Kubernetes (lihatTetapkan IPs ke Pod dengan Amazon VPC CNI) OpenTelemetry, dan Grafana Kubernetes Monitoring. Untuk penyimpanan (lihatMenyimpan data aplikasi untuk klaster Anda), add-on ke Amazon EKS termasuk Amazon Elastic Block Store CSI Driver (lihatSimpan volume Kubernetes dengan Amazon EBS), Amazon Elastic File System CSI Driver (lihatSimpan sistem file elastis dengan Amazon EFS), dan beberapa add-on penyimpanan pihak ketiga seperti Amazon FSx untuk driver NetApp ONTAP CSI). Simpan aplikasi berkinerja tinggi FSx untuk NetApp ONTAP

Untuk daftar yang lebih lengkap dari add-on Amazon EKS yang tersedia, lihatAdd-on Amazon EKS.

Beban kerja

Kubernetes mendefinisikan Workload sebagai “sebuah aplikasi yang berjalan di Kubernetes.” Aplikasi tersebut dapat terdiri dari serangkaian layanan mikro yang dijalankan sebagai Container di Pod, atau dapat dijalankan sebagai pekerjaan batch atau jenis aplikasi lainnya. Tugas Kubernetes adalah memastikan bahwa permintaan yang Anda buat untuk objek yang akan disiapkan atau dikerahkan dilakukan. Sebagai seseorang yang menerapkan aplikasi, Anda harus mempelajari tentang bagaimana kontainer dibuat, bagaimana Pod didefinisikan, dan metode apa yang dapat Anda gunakan untuk menerapkannya.

Kontainer

Elemen paling dasar dari beban kerja aplikasi yang Anda gunakan dan kelola di Kubernetes adalah sebuah Pod. Sebuah Pod mewakili cara memegang komponen aplikasi serta mendefinisikan spesifikasi yang menggambarkan atribut Pod. Bandingkan ini dengan sesuatu seperti paket RPM atau Deb, yang mengemas perangkat lunak bersama untuk sistem Linux, tetapi tidak berjalan sendiri sebagai entitas.

Karena Pod adalah unit deployable terkecil, biasanya memiliki satu kontainer. Namun, beberapa kontainer dapat berada di dalam Pod jika kontainer digabungkan dengan erat. Misalnya, sebuah kontainer server web mungkin dikemas dalam Pod dengan jenis kontainer sidecar yang dapat menyediakan logging, monitoring, atau layanan lain yang terkait erat dengan kontainer server web. Dalam hal ini, berada di Pod yang sama memastikan bahwa untuk setiap instance Pod yang sedang berjalan, kedua container selalu berjalan pada node yang sama. Demikian juga, semua kontainer dalam sebuah Pod berbagi lingkungan yang sama, dengan kontainer dalam sebuah Pod berjalan seolah-olah mereka berada di host terisolasi yang sama. Efek dari hal ini adalah bahwa kontainer berbagi satu alamat IP yang menyediakan akses ke Pod dan kontainer dapat berkomunikasi satu sama lain seolah-olah mereka berjalan di localhost mereka sendiri.

Spesifikasi Pod (PodSpec) menentukan status Pod yang diinginkan. Anda dapat menerapkan Pod individual atau beberapa Pod dengan menggunakan sumber daya beban kerja untuk mengelola Template Pod. Sumber daya beban kerja meliputi Deployments (untuk mengelola beberapa Replika Pod), StatefulSets(untuk menyebarkan Pod yang perlu unik, seperti Pod database), dan DaemonSets(di mana sebuah Pod perlu dijalankan secara terus menerus pada setiap node). Lebih lanjut tentang itu nanti.

Sementara Pod adalah unit terkecil yang Anda gunakan, sebuah kontainer adalah unit terkecil yang Anda buat dan kelola.

Kontainer Bangunan

Pod sebenarnya hanya sebuah struktur di sekitar satu atau lebih kontainer, dengan setiap kontainer itu sendiri memegang sistem file, executable, file konfigurasi, pustaka, dan komponen lain untuk benar-benar menjalankan aplikasi. Karena sebuah perusahaan bernama Docker Inc. pertama kali mempopulerkan kontainer, beberapa orang menyebut kontainer sebagai Kontainer Docker. Namun, Open Container Initiative telah menetapkan runtime kontainer, gambar, dan metode distribusi untuk industri. Ditambah fakta bahwa kontainer dibuat dari banyak fitur Linux yang ada, yang lain sering menyebut kontainer sebagai Kontainer OCI, Kontainer Linux, atau hanya Kontainer.

Saat Anda membangun wadah, Anda biasanya memulai dengan Dockerfile (secara harfiah dinamai itu). Di dalam Dockerfile itu, Anda mengidentifikasi:

• 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 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.

• 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).

Sementara docker perintah dan layanan secara tradisional telah digunakan untuk membangun container (docker build), alat lain yang tersedia untuk membangun gambar kontainer termasuk podman dan nerdctl. Lihat Membangun Gambar Kontainer yang Lebih Baik atau Ikhtisar Docker Build untuk mempelajari tentang membangun kontainer.

Menyimpan Wadah

Setelah Anda membangun gambar kontainer Anda, Anda dapat menyimpannya dalam registri distribusi kontainer di workstation Anda atau di registri kontainer publik. Menjalankan registri kontainer pribadi di workstation Anda memungkinkan Anda menyimpan gambar kontainer secara lokal, membuatnya tersedia untuk Anda.

Untuk menyimpan gambar kontainer dengan cara yang lebih umum, Anda dapat mendorongnya ke registri kontainer publik. Registries kontainer publik menyediakan lokasi sentral untuk menyimpan dan mendistribusikan gambar kontainer. Contoh pendaftar kontainer publik termasuk Amazon Elastic Container Registry, registri Red Hat Quay, dan registri Docker Hub.

Saat menjalankan beban kerja kontainer di Amazon Elastic Kubernetes Service (Amazon EKS), kami sarankan untuk menarik salinan Gambar Resmi Docker yang disimpan di Amazon Elastic Container Registry. Amazon ECR telah menyimpan gambar-gambar ini sejak 2021. Anda dapat mencari gambar kontainer populer di Galeri Publik Amazon ECR, dan khusus untuk gambar Docker Hub, Anda dapat mencari Galeri Docker Amazon ECR.

Menjalankan kontainer

Karena kontainer dibangun dalam format standar, kontainer dapat berjalan di mesin apa pun yang dapat menjalankan runtime kontainer (seperti Docker) dan yang isinya cocok dengan arsitektur mesin lokal (seperti x86_64 atauarm). Untuk menguji kontainer atau menjalankannya di desktop lokal Anda, Anda dapat menggunakan docker run atau podman run perintah untuk memulai penampung di localhost. Namun, untuk Kubernetes, setiap node pekerja memiliki runtime container yang di-deploy dan terserah Kubernetes untuk meminta sebuah node menjalankan sebuah container.

Setelah wadah ditugaskan untuk berjalan pada node, node akan melihat apakah versi yang diminta dari gambar kontainer sudah ada di node. Jika tidak, Kubernetes memberi tahu runtime container untuk menarik container itu dari registri container yang sesuai, lalu jalankan container tersebut secara lokal. Perlu diingat bahwa image kontainer mengacu pada paket perangkat lunak yang dipindahkan antara laptop Anda, registri kontainer, dan node Kubernetes. Sebuah wadah mengacu pada instance yang sedang berjalan dari gambar itu.

Pod

Setelah kontainer Anda siap, bekerja dengan Pod termasuk mengonfigurasi, menerapkan, dan membuat Pod dapat diakses.

Mengkonfigurasi Pod

Ketika Anda mendefinisikan sebuah Pod, Anda menetapkan satu set atribut untuk itu. Atribut tersebut harus menyertakan setidaknya nama Pod dan image container yang akan dijalankan. Namun, ada banyak hal lain yang ingin Anda konfigurasikan dengan definisi Pod Anda juga (lihat PodSpechalaman untuk detail tentang apa yang bisa masuk ke Pod). Ini termasuk:

• Penyimpanan — Ketika wadah yang sedang berjalan dihentikan dan dihapus, penyimpanan data dalam wadah itu akan hilang, kecuali jika Anda mengatur penyimpanan yang lebih permanen. Kubernetes mendukung berbagai jenis penyimpanan dan mengabstraksinya di bawah payung Volume. 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 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 kelas penyimpanan yang berbeda untuk 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 komponen dan beban kerja Kubernetes 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 namespace sendiri untuk digunakan atau memilih untuk tidak menunjukkan namespace (yang menyebabkan Kubernetes menggunakan namespace). default Komponen bidang kontrol Kubernetes biasanya berjalan di namespace sistem kube.

Konfigurasi yang baru saja dijelaskan biasanya dikumpulkan bersama dalam file YAMB untuk diterapkan ke cluster Kubernetes. Untuk klaster Kubernetes pribadi, Anda mungkin hanya menyimpan file YAMAL ini di sistem lokal Anda. Namun, dengan klaster dan beban kerja yang lebih kritis, GitOpsadalah cara populer untuk mengotomatiskan penyimpanan dan pembaruan pada beban kerja dan sumber daya infrastruktur Kubernetes.

Objek yang digunakan untuk mengumpulkan dan menyebarkan informasi Pod ditentukan oleh salah satu metode penerapan berikut.

Menerapkan Pod

Metode yang akan Anda pilih untuk menerapkan Pod tergantung pada jenis aplikasi yang Anda rencanakan untuk dijalankan dengan Pod tersebut. Berikut adalah beberapa pilihan Anda:

• 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 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 di Kubernetes, Anda dapat menggunakannya. 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 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 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 format crontab Linux.

Membuat aplikasi dapat diakses dari jaringan

Dengan aplikasi yang sering digunakan sebagai satu set layanan mikro yang berpindah ke tempat yang berbeda, Kubernetes membutuhkan cara agar layanan mikro tersebut dapat menemukan satu sama lain. Selain itu, bagi orang lain untuk mengakses aplikasi di luar klaster Kubernetes, Kubernetes membutuhkan cara untuk mengekspos aplikasi itu di alamat dan port luar. Fitur terkait jaringan ini dilakukan dengan objek Service dan Ingress, masing-masing:

• 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 Services tersedia untuk klien yang berada di luar klaster. 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 dengan Kubernetes.

Langkah selanjutnya

Memahami konsep dasar Kubernetes dan bagaimana kaitannya dengan Amazon EKS akan membantu Anda menavigasi dokumentasi Amazon EKS dan dokumentasi Kubernetes untuk menemukan informasi yang Anda perlukan untuk mengelola klaster Amazon EKS dan menerapkan beban kerja ke klaster tersebut. Untuk mulai menggunakan Amazon EKS, pilih dari yang berikut ini:

• Memulai dengan Amazon EKS - eksctl

• Buat kluster Amazon EKS

• Menyebarkan contoh aplikasi di Linux

• Mengatur dan memantau sumber daya cluster