Cara kerja penyebaran Kubernetes
Aplikasi pelacakan drone memiliki beberapa komponen yang disebarkan secara terpisah satu sama lain. Tugas Anda adalah mengonfigurasi penyebaran untuk komponen-komponen ini pada kluster. Di sini, Anda melihat beberapa opsi penyebaran yang tersedia untuk Anda untuk menyebarkan komponen-komponen ini.
Opsi penyebaran
Ada beberapa opsi untuk mengelola penyebaran pod dalam kluster Kubernetes saat Anda menggunakan kubectl. Opsinya adalah:
- Template pod
- Pengontrol replikasi
- Rangkaian replika
- Penyebaran
Anda dapat menggunakan salah satu dari empat definisi jenis objek Kubernetes ini untuk menyebarkan pod atau pod. File-file ini menggunakan YAML untuk menjelaskan status pod atau pod yang dimaksudkan untuk disebarkan.
Apa itu template pod?
Template pod memungkinkan Anda menentukan konfigurasi pod yang ingin disebarkan. Templat berisi informasi seperti nama gambar kontainer dan registri kontainer mana yang akan digunakan untuk mengambil gambar. Templat juga menyertakan informasi konfigurasi runtime, seperti port yang akan digunakan. Template didefinisikan dengan menggunakan YAML dengan cara yang sama seperti saat Anda membuat file Docker.
Anda dapat menggunakan template untuk menyebarkan pod secara manual. Namun, pod yang disebarkan secara manual tidak diluncurkan kembali setelah gagal, dihapus, atau dihentikan. Untuk mengelola siklus hidup sebuah pod, Anda harus membuat objek Kubernetes dengan level lebih tinggi.
Apa itu pengontrol replikasi?
Pengontrol replikasi menggunakan template pod dan mendefinisikan sejumlah pod tertentu yang harus dijalankan. Pengontrol ini membantu Anda menjalankan beberapa instans dari pod yang sama, dan memastikan pod selalu berjalan pada satu atau beberapa node di dalam kluster. Pengontrol mengganti pod yang sedang berjalan dengan cara ini dengan pod baru jika gagal, dihapus, atau dihentikan.
Misalnya, anggap Anda menyebarkan situs web front-end pelacakan drone, dan pengguna mulai mengakses situs web. Jika semua pod gagal karena alasan apa pun, situs web ini tidak tersedia untuk pengguna anda kecuali Anda meluncurkan pod baru. Pengontrol replikasi membantu Anda memastikan situs web Anda selalu tersedia.
Apa itu set replika?
Set replika menggantikan pengontrol replikasi sebagai cara yang disukai untuk menyebarkan replika. Set replika menyertakan fungsionalitas yang sama dengan pengontrol replikasi, tetapi memiliki opsi konfigurasi tambahan untuk menyertakan nilai pemilih.
Pemilih memungkinkan set replika untuk mengidentifikasi semua pod yang berjalan di bawahnya. Dengan menggunakan fitur ini, Anda dapat mengelola pod berlabel nilai yang sama dengan nilai pemilih, namun tidak dibuat dengan set yang direplikasi.
Apa itu penyebaran?
Penyebaran membuat objek manajemen satu tingkat lebih tinggi dari set replika, dan memungkinkan Anda untuk menyebarkan dan mengelola pembaruan untuk pod dalam kluster.
Misalnya, Anda memiliki lima instans aplikasi yang diterapkan di kluster. Ada lima pod yang menjalankan aplikasi versi 1.0.0.
Jika memutuskan untuk memperbarui aplikasi secara manual, Anda dapat menghapus semua pod, lalu meluncurkan pod baru yang menjalankan aplikasi versi 2.0.0. Dengan strategi ini, aplikasi Anda mengalami waktu henti.
Sebagai gantinya, Anda ingin menjalankan pembaruan bergulir di mana Anda meluncurkan pod dengan versi baru aplikasi Anda sebelum menghapus pod versi aplikasi yang lebih lama. Pembaruan bergulir meluncurkan satu pod sekaligus alih-alih menurunkan semua pod yang lebih lama sekaligus. Penyebaran menghormati jumlah replika yang dikonfigurasi di bagian yang menjelaskan informasi tentang set replika. Ini mempertahankan jumlah pod yang ditentukan dalam set replika karena mengganti pod lama dengan pod baru.
Penyebaran, secara default, menyediakan strategi pembaruan bergulir untuk memperbarui pod. Anda juga dapat menggunakan strategi buat ulang. Strategi ini mengakhiri pod sebelum meluncurkan pod baru.
Penyebaran juga memberi Anda strategi rollback, yang dapat Anda eksekusi dengan menggunakan kubectl.
Penyebaran menggunakan file definisi berbasis YAML dan memudahkan pengelolaan penyebaran. Perlu diingat bahwa penyebaran memungkinkan Anda menerapkan perubahan apa pun pada kluster Anda. Misalnya, Anda dapat menyebarkan versi baru dari sebuah aplikasi, memperbarui label, dan menjalankan replika pod lainnya.
kubectl memiliki sintaksis yang nyaman untuk membuat penyebaran secara otomatis ketika Anda menggunakan perintah kubectl run untuk menyebarkan sebuah pod. Perintah ini membuat penyebaran dengan set replika dan pod yang diperlukan. Namun, perintah tidak membuat file definisi. Ini adalah praktik terbaik untuk mengelola semua penyebaran dengan file definisi penyebaran, dan melacak perubahan dengan menggunakan sistem kontrol versi.
Pertimbangan penyebaran
Kubernetes memiliki persyaratan khusus tentang cara Anda mengonfigurasi jaringan dan penyimpanan untuk sebuah kluster. Cara Anda mengonfigurasi kedua aspek ini memengaruhi keputusan Anda tentang cara mengekspos aplikasi Anda di jaringan kluster dan menyimpan data.
Misalnya, setiap layanan di aplikasi pelacakan drone memiliki persyaratan khusus untuk akses pengguna, akses jaringan antarproses, dan penyimpanan data. Sekarang, lihat aspek-aspek kluster Kubernetes ini dan bagaimana hal tersebut memengaruhi penyebaran aplikasi.
Jaringan Kubernetes
Misalnya Anda memiliki kluster dengan satu pesawat kontrol dan dua node. Ketika Anda menambahkan node ke Kubernetes, sebuah alamat IP secara otomatis ditugaskan ke setiap node dari jajaran jaringan privat internal. Misalnya, asumsikan bahwa rentang jaringan lokal Anda adalah 192.168.1.0/24.
Setiap pod yang Anda terapkan akan diberi IP dari kumpulan alamat IP. Misalnya, misalnya, konfigurasi Anda menggunakan rentang jaringan 10.32.0.0/12, seperti yang ditunjukkan gambar berikut.
Secara default, pod dan node tidak dapat berkomunikasi satu sama lain dengan menggunakan rentang alamat IP yang berbeda.
Untuk lebih mempersulit masalah, ingatlah bahwa pod bersifat sementara. Alamat IP pod bersifat sementara, dan tidak dapat digunakan untuk menyambung kembali ke pod yang baru dibuat. Konfigurasi ini memengaruhi cara aplikasi Anda berkomunikasi dengan komponen internalnya dan bagaimana Anda dan layanan berinteraksi dengannya secara eksternal.
Untuk menyederhanakan komunikasi, Kubernetes mengharapkan Anda untuk mengonfigurasi jaringan sedemikian rupa sehingga:
- Pod dapat berkomunikasi satu sama lain di seluruh node tanpa Network Address Translation (NAT).
- Node dapat berkomunikasi dengan semua pod, dan sebaliknya, tanpa NAT.
- Agen pada sebuah node dapat berkomunikasi dengan semua node dan pod.
Kubernetes menawarkan beberapa opsi jaringan yang dapat diinstal untuk mengonfigurasi jaringan. Contohnya termasuk Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T, dan Weave Net.
Penyedia cloud juga menyediakan solusi jaringan mereka sendiri. Misalnya, Azure Kubernetes Service (AKS) mendukung antarmuka jaringan kontainer Azure Virtual Network (CNI), Kubenet, Flannel, Cilium, dan Antrea.
Layanan Kubernetes
Layanan Kubernetes adalah objek Kubernetes yang menyediakan jaringan yang stabil untuk pod. Layanan Kubernetes memungkinkan komunikasi antara node, pod, dan pengguna aplikasi, baik internal maupun eksternal, ke kluster.
Kubernetes menetapkan sebuah layanan sebuah alamat IP pada pembuatan, sama seperti node atau pod. Alamat ini ditetapkan dari rentang IP kluster layanan; misalnya, 10.96.0.0/12. Layanan juga diberi nama DNS berdasarkan nama layanan dan port TCP.
Di aplikasi pelacakan drone, komunikasi jaringan adalah sebagai berikut:
Situs web dan RESTful API dapat diakses oleh pengguna di luar kluster.
Layanan tembolok dalam memori dan antrean pesan dapat diakses oleh front end dan API RESTful, masing-masing, tetapi tidak untuk pengguna eksternal.
Antrean pesan memerlukan akses ke layanan pemrosesan data, tetapi tidak untuk pengguna eksternal.
Database NoSQL dapat diakses oleh tembolok dalam memori dan layanan pemrosesan data, tetapi tidak untuk pengguna eksternal.
Untuk mendukung skenario ini, Anda dapat mengonfigurasi tiga jenis layanan untuk mengekspos komponen aplikasi Anda.
| Layanan | Keterangan |
|---|---|
| ClusterIP | Alamat yang ditetapkan ke layanan yang membuat layanan tersedia untuk serangkaian layanan di dalam kluster. Misalnya, komunikasi antara komponen front-end dan back-end aplikasi Anda. |
| NodePort | Port node antara 30000 dan 32767 yang ditetapkan sarana kontrol Kube ke layanan; misalnya, 192.169.1.11 pada kluster01. Anda kemudian mengonfigurasi layanan dengan port target pada pod yang ingin diekspos. Misalnya, mengonfigurasi port 80 pada pod yang menjalankan salah satu front end. Anda sekarang dapat mengakses front end melalui IP node dan alamat port. |
| LoadBalancer | Load balancer yang memungkinkan distribusi beban antara node yang menjalankan aplikasi anda, dan mengekspos pod ke akses jaringan publik. Anda biasanya mengonfigurasi penyeimbang muatan saat menggunakan penyedia cloud. Dalam hal ini, lalu lintas dari load balancer eksternal diarahkan ke pod yang menjalankan aplikasi anda. |
Di aplikasi pelacakan drone, Anda mungkin memutuskan untuk mengekspos situs web pelacakan dan RESTful API dengan menggunakan LoadBalancer dan layanan pemrosesan data dengan menggunakan ClusterIP.
Cara mengelompokkan pod
Mengelola pod berdasarkan alamat IP tidaklah praktis. Alamat IP pod berubah saat pengontrol membuatnya kembali, dan Anda mungkin memiliki sejumlah pod yang berjalan.
Objek layanan memungkinkan Anda untuk menargetkan dan mengelola pod tertentu di kluster Anda dengan menggunakan label pemilih. Anda mengatur label pemilih dalam definisi layanan agar sesuai dengan label pod yang didefinisikan dalam berkas definisi pod.
Misalnya, anggaplah bahwa Anda memiliki banyak pod yang sedang berjalan. Hanya beberapa pod ini yang berada di bagian depan, dan Anda ingin menyetel layanan LoadBalancer yang hanya menargetkan pod front-end. Anda dapat menerapkan layanan untuk mengekspos pod ini dengan mereferensikan label pod sebagai nilai pemilih dalam berkas definisi layanan. Layanan hanya mengelompokkan pod yang cocok dengan label. Jika sebuah pod dihapus dan dibuat kembali, pod baru akan secara otomatis ditambahkan ke grup layanan melalui label yang cocok.
Penyimpanan Kubernetes
Kubernetes menggunakan konsep volume penyimpanan yang sama dengan yang Anda temukan saat menggunakan Docker. Volume Docker kurang dikelola daripada volume Kubernetes, karena masa pakai volume Docker tidak dikelola. Masa pakai volume Kubernetes adalah masa pakai eksplisit yang sesuai dengan masa pakai pod. Kecocokan seumur hidup ini berarti volume hidup lebih lama dari kontainer yang berjalan di dalam pod. Namun, jika pod dihapus, begitu juga volumenya.
Kubernetes menyediakan opsi untuk menyediakan penyimpanan persisten dengan penggunaan PersistentVolumes. Anda juga dapat meminta penyimpanan khusus untuk pod dengan menggunakan PersistentVolumeClaims.
Ingatlah kedua opsi ini saat Anda menerapkan komponen aplikasi yang memerlukan penyimpanan tetap, seperti antrean pesan dan database.
Pertimbangan integrasi cloud
Kubernetes tidak mendikte tumpukan teknologi yang Anda gunakan di aplikasi cloud-native Anda. Di lingkungan cloud seperti Azure, Anda dapat menggunakan beberapa layanan di luar kluster Kubernetes.
Ingat dari sebelumnya bahwa Kubernetes tidak menyediakan salah satu layanan berikut:
- Middleware
- Kerangka kerja pemrosesan data
- Database
- Penembolokan
- Sistem penyimpanan kluster
Dalam solusi pelacakan drone ini, ada tiga layanan yang menyediakan fungsionalitas middleware: database NoSQL, layanan cache dalam memori, dan antrean pesan. Anda dapat memilih MongoDB Atlas untuk solusi NoSQL, Redis untuk mengelola cache dalam memori dan, RabbitMQ atau Kafka tergantung pada kebutuhan antrean pesan Anda.
Ketika Anda menggunakan lingkungan cloud seperti Azure, ini adalah praktik terbaik untuk menggunakan layanan di luar kluster Kubernetes. Keputusan ini dapat menyederhanakan konfigurasi dan manajemen kluster. Misalnya, Anda dapat menggunakan Azure Cache for Redis untuk layanan penembolokan dalam memori, pesan Azure Service Bus untuk antrean pesan, dan Azure Cosmos DB untuk database NoSQL.