Panduan Kubernetes, Bagian 2: Membuat dan Bekerja dengan Cluster

Terakhir kali, kami memeriksa dua pendekatan untuk bekerja dengan layanan microser. Secara khusus, salah satunya melibatkan penggunaan wadah Docker, di mana Anda dapat mengeksekusi kode layanan microservice dan tambahan. Hari ini, menggunakan gambar kontainer kami yang ada, kami akan bekerja dengan Kubernetes.

Memperkenalkan Kubernet

Saya berjanji, dan saya tidak membesar-besarkan sama sekali bahwa ketika Anda membaca artikel ini, tanyakan pada diri sendiri: "Mengapa Kubernet tidak disebut Supernetes?"


Supernetes

Jika Anda membaca bagian sebelumnya dari materi ini, maka Anda tahu bahwa di sana kami melihat banyak hal yang berkaitan dengan mempersiapkan aplikasi untuk kontainerisasi dan bekerja dengan wadah Docker. Tampaknya bagi Anda bahwa hal yang paling sulit menanti Anda sekarang, tetapi, pada kenyataannya, apa yang akan kita bicarakan di sini jauh lebih sederhana daripada apa yang sudah kita ketahui. Satu-satunya alasan mengapa mempelajari Kubernetes mungkin tampak seperti tugas yang menakutkan bagi seseorang adalah jumlah informasi tambahan yang Anda butuhkan untuk memahami Kubernetes dan menggunakannya secara efektif. Kami telah membahas semua "informasi tambahan" yang diperlukan untuk keberhasilan pengembangan Kubernetes.

▍Apa itu Kubernet?

Di bagian pertama artikel ini, setelah meluncurkan layanan microser dalam wadah, Anda diminta untuk memikirkan masalah penskalaan aplikasi yang dikemas dalam wadah.
Saya sarankan merenungkannya bersama-sama, dalam format pertanyaan dan jawaban:

Pertanyaan: Bagaimana skala aplikasi kemas?
Jawab: Luncurkan wadah tambahan.

Pertanyaan: Dan bagaimana beban didistribusikan di antara mereka? Bagaimana jika server tertentu sudah digunakan secara maksimal, dan kontainer perlu digunakan di server lain? Bagaimana menemukan cara paling efisien untuk menggunakan perangkat keras?
Jawab: Jadi ... Saya akan melihat di Internet ...

Pertanyaan: Bagaimana cara memperbarui program tanpa mengganggu sistem? Dan, jika pembaruan mengandung kesalahan, bagaimana cara kembali ke versi aplikasi yang berfungsi?

Bahkan, itu adalah teknologi Kubernetes yang memberikan jawaban yang layak untuk ini dan banyak pertanyaan lainnya. Saya akan mencoba mempersempit definisi Kubernetes menjadi satu kalimat: "Kubernetes adalah sistem manajemen wadah yang mengabstraksi infrastruktur yang mendasarinya (lingkungan di mana wadah beroperasi)."

Saya percaya bahwa sekarang Anda tidak terlalu jelas tentang konsep "manajemen kontainer", meskipun kami telah menyebutkan ini. Di bawah ini kami akan mempertimbangkan teknologi ini dalam praktiknya. Namun, konsep "abstrak infrastruktur dasar" pertama kali ditemukan. Karena itu, sekarang kita akan mempertimbangkannya.

▍Perbaikan infrastruktur dasar

Kubernet memungkinkan aplikasi untuk abstrak dari infrastruktur, memberi kami API sederhana yang dapat Anda kirim permintaan. Kubernetes mencoba memenuhi permintaan ini menggunakan semua kemampuannya. Misalnya, dalam bahasa reguler, permintaan serupa dapat dijelaskan sebagai berikut: "Kubernetes, perluas 4 wadah gambar X". Setelah menerima perintah, Kubernetes akan menemukan node yang tidak terlalu sibuk (mereka juga disebut "node" - dari bahasa Inggris "node"), di mana Anda dapat menggunakan kontainer baru.


Permintaan server API

Apa artinya ini bagi pengembang? Ini berarti bahwa dia tidak perlu khawatir tentang jumlah node, tentang di mana tepatnya wadah diluncurkan, atau bagaimana mereka berinteraksi. Dia tidak harus berurusan dengan optimasi perangkat keras atau khawatir tentang node yang mungkin tidak berfungsi (dan sesuatu yang serupa, menurut hukum Murphy, pasti akan terjadi), karena, jika perlu, node baru dapat ditambahkan ke cluster Kubernetes. Jika ada sesuatu yang salah dengan beberapa node yang ada, Kubernetes akan menyebarkan kontainer ke node yang masih dalam keadaan sehat.

Banyak dari apa yang ditunjukkan pada gambar sebelumnya sudah tidak asing lagi bagi Anda. Tetapi ada juga sesuatu yang baru:

• Server API Melakukan panggilan ke server ini adalah satu-satunya cara untuk berinteraksi dengan cluster yang kita miliki, apakah kita berbicara tentang memulai atau menghentikan wadah, memeriksa status sistem, bekerja dengan log, atau melakukan tindakan lain.
• Kubelet. Ini adalah agen yang memantau wadah di dalam simpul dan berinteraksi dengan simpul utama.

Harap dicatat bahwa dalam beberapa kalimat sebelumnya kami menggunakan istilah "wadah", tetapi di sini akan lebih tepat untuk menggunakan istilah "pod". Entitas-entitas ini sering disebut "pod" dalam publikasi berbahasa Rusia, dan kadang-kadang - "pod", dalam dokumentasi , mengklarifikasi konsep "pod", mereka berbicara tentang "kawanan paus" (pod of whales) atau "pod kacang" tetapi tidak ada yang menyebutnya "kawanan" atau "buah". Berbicara tentang mereka, kita akan menggunakan kata "di bawah". Sekarang Anda dapat mempertimbangkannya sebagai wadah, kami akan berbicara lebih banyak tentang polong di bawah ini.

Kita akan berhenti pada ini untuk saat ini, karena kita dapat membicarakan semua ini lebih lanjut, dan, di samping itu, ada banyak materi bagus mengenai teori Kubernet. Misalnya, ini adalah dokumentasi resmi, meskipun tidak mudah dibaca, atau buku seperti ini .

▍ Standarisasi pekerjaan dengan penyedia layanan cloud

Kekuatan lain Kubernetes terletak pada kenyataan bahwa teknologi ini berkontribusi pada standardisasi kerja dengan penyedia layanan cloud (Cloud Service Provider, CSP). Ini adalah pernyataan yang berani. Perhatikan contoh berikut. Seorang spesialis yang mengenal Azure atau Google Cloud Platform dengan baik harus mengerjakan proyek yang dirancang untuk lingkungan cloud yang benar-benar baru baginya, yang dengannya ia tidak terbiasa. Dalam situasi ini, banyak yang bisa salah. Misalnya, tenggat waktu untuk pengiriman proyek mungkin tertunda, perusahaan klien proyek mungkin perlu menyewa lebih banyak sumber daya cloud dari yang direncanakan, dan sebagainya.

Saat menggunakan Kubernetes, masalah seperti itu tidak dapat muncul, karena, terlepas dari penyedia layanan cloud mana yang sedang kita bicarakan, bekerja dengan Kubernetes selalu terlihat sama. Pengembang, dalam gaya deklaratif, memberi tahu server API apa yang ia butuhkan, dan Kubernetes bekerja dengan sumber daya sistem, yang memungkinkan pengembang mengabaikan detail implementasi sistem ini.

Tetap bertahan sedikit pada gagasan ini, karena ini adalah peluang Kubernet yang sangat kuat. Bagi perusahaan, ini berarti bahwa keputusan mereka tidak terikat dengan CSP tertentu. Jika sebuah perusahaan menemukan penawaran yang lebih baik di pasar layanan cloud, ia dapat dengan bebas mengambil keuntungan dari penawaran ini dengan pindah ke penyedia baru. Apalagi pengalaman yang diperoleh spesialis perusahaan tidak hilang di mana pun.

Sekarang mari kita bicara tentang penggunaan praktis Kubernet

Praktik Kubernetes: Pod

Kami mengkonfigurasi peluncuran layanan microser dalam wadah, proses pengaturannya cukup membosankan, tetapi kami berhasil mendapatkan sistem yang berfungsi. Selain itu, seperti yang telah disebutkan, solusi kami tidak memiliki skala yang baik dan tidak tahan terhadap kegagalan. Kami akan memecahkan masalah ini dengan Kubernetes. Selanjutnya, kami akan membawa sistem kami ke formulir yang sesuai dengan skema berikut. Yaitu, kontainer akan dikelola oleh Kubernetes.


Microservices bekerja di sebuah cluster yang dikelola oleh Kubernetes

Di sini, kita akan menggunakan Minikube untuk penyebaran lokal cluster dan untuk menguji kemampuan Kubernetes, meskipun semua yang akan kita lakukan di sini dapat dilakukan menggunakan platform cloud seperti Azure atau Google Cloud Platform.

▍Instalasi dan mulai Minikube

Untuk menginstal Minikube, ikuti instruksi yang ditemukan dalam dokumentasi . Selama instalasi Minikube, Anda juga akan menginstal Kubectl. Ini adalah klien yang memungkinkan permintaan untuk dibuat ke server API Kubernetes.

Untuk memulai Minikube, jalankan perintah minikube start , dan setelah itu selesai, jalankan perintah kubectl get nodes . Akibatnya, Anda akan melihat sesuatu seperti berikut:

 kubectl get nodes NAME       STATUS ROLES     AGE VERSION minikube   Ready <none>    11m v1.9.0 

Minikube menempatkan kami pada sebuah cluster yang hanya terdiri dari satu simpul. Benar, ini cocok untuk kita. Mereka yang bekerja dengan Kubernetes tidak perlu khawatir tentang persis berapa banyak node dalam cluster, karena Kubernetes memungkinkan Anda untuk abstrak dari detail seperti itu.

Sekarang mari kita bicara tentang polong.

▍Pods

Saya sangat suka wadah, dan Anda mungkin juga menyukainya sekarang. Mengapa Kubernetes menawarkan kami untuk menggunakan pod, entitas yang merupakan unit komputasi minimum yang dapat digunakan dalam sistem ini? Apa fungsinya di bawah? Faktanya adalah bahwa perapian dapat mencakup satu atau lebih kontainer yang berbagi runtime yang sama.

Tetapi apakah perlu untuk melakukan, misalnya, dua wadah dalam satu perapian? Bagaimana mengatakannya ... Biasanya hanya ada satu wadah per wadah, dan itulah yang akan kita lakukan. Tetapi untuk kasus-kasus ketika, misalnya, dua kontainer memerlukan akses bersama ke gudang data yang sama, atau jika mereka terhubung menggunakan teknik komunikasi antarproses, atau jika mereka terhubung erat untuk beberapa alasan lain, semua ini dapat direalisasikan dengan menjalankannya dalam satu perapian. Kemungkinan lain yang membedakan pod adalah mereka tidak harus menggunakan wadah Docker. Jika perlu, di sini Anda dapat menerapkan teknologi lain untuk kontainerisasi aplikasi, misalnya - Rkt .

Diagram berikut menunjukkan properti perapian bernomor.


Properti Perapian

Pertimbangkan sifat-sifat ini.

1. Setiap pod di kluster Kubernetes memiliki alamat IP yang unik.
2. Perapian dapat berisi banyak wadah. Mereka berbagi nomor port yang tersedia, yaitu, misalnya, mereka dapat saling bertukar informasi melalui localhost (secara alami, mereka tidak dapat menggunakan port yang sama). Interaksi dengan wadah yang terletak di pod lain diatur menggunakan alamat IP pod ini.
3. Wadah dalam pod berbagi volume penyimpanan data, alamat IP, nomor port, ruang nama IPC.

Perlu dicatat bahwa kontainer memiliki sistem file tersendiri, tetapi mereka dapat berbagi data menggunakan sumber daya Kubernet yang disebut Volume .

Bagi kami, apa yang telah dikatakan tentang perapian sudah cukup untuk terus menguasai Kubernet. Baca lebih lanjut tentang mereka di sini .

▍ Deskripsi perapian

Berikut ini adalah file manifes untuk aplikasi sa-frontend .

 apiVersion: v1 kind: Pod                                            # 1 metadata: name: sa-frontend                                  # 2 spec:                                                # 3 containers:   - image: rinormaloku/sentiment-analysis-frontend # 4     name: sa-frontend                              # 5     ports:       - containerPort: 80 

Mari kita jelaskan beberapa parameter yang ditentukan di dalamnya.

1. Kind : Menentukan jenis sumber daya Kubernet yang ingin kita buat. Dalam kasus kami, ini adalah Pod .
2. Name : nama sumber daya. Kami menyebutnya sa-frontend .
3. Spec : objek yang menggambarkan kondisi sumber daya yang diinginkan. Properti paling penting di sini adalah susunan wadah.
4. Image : gambar wadah yang ingin kami jalankan di pod ini.
5. Name : nama unik untuk wadah di bawahnya.
6. ContainerPort : port tempat wadah itu mendengarkan. Parameter ini dapat dianggap sebagai indikasi bagi siapa yang membaca file ini (jika Anda mengabaikan parameter ini, ini tidak akan membatasi akses ke port).

▍Membuat SA-Frontend perapian

File deskripsi pod yang kita bicarakan dapat ditemukan di resource-manifests/sa-frontend-pod.yaml . Anda harus pergi ke folder ini menggunakan alat terminal, atau, ketika Anda memanggil perintah yang sesuai, tentukan path lengkap ke file. Ini adalah perintah ini dan contoh reaksi sistem terhadapnya:

 kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created 

Untuk mengetahui apakah itu berfungsi di bawah, jalankan perintah berikut:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s 

Jika status perapian selama eksekusi perintah ini adalah ContainerCreating , maka Anda dapat menjalankan perintah yang sama dengan --watch . Karena itu, ketika perapian berada dalam status Running , informasi tentang ini akan ditampilkan secara otomatis.

▍Akses ke aplikasi dari luar

Untuk mengatur akses ke aplikasi dari luar, akan benar untuk membuat sumber daya Kubernet dari jenis Layanan, yang akan kita bicarakan di bawah ini, tetapi di sini, untuk singkatnya, kami akan menggunakan port forwarding sederhana:

 kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80 

Jika sekarang Anda pergi melalui browser di 127.0.0.1:88 , Anda dapat melihat halaman Bereaksi aplikasi.

▍ Pendekatan penskalaan yang salah

Kami telah mengatakan bahwa salah satu kemampuan Kubernetes adalah penskalaan aplikasi. Untuk mengalami kesempatan ini, kami akan menjalankan yang lain di bawah. Buat deskripsi sumber daya Pod lainnya dengan menempatkan kode berikut di file sa-frontend-pod2.yaml :

 apiVersion: v1 kind: Pod                                           metadata: name: sa-frontend2      #   spec:                                                containers:   - image: rinormaloku/sentiment-analysis-frontend     name: sa-frontend                                  ports:       - containerPort: 80 

Seperti yang Anda lihat, jika Anda membandingkan deskripsi ini dengan apa yang kami periksa di atas, satu-satunya perubahan di dalamnya adalah nilai properti Name .

Buat yang baru di bawah:

 kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created 

Pastikan itu berjalan:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s sa-frontend2                  1/1 Running 0 7s 

Sekarang kami memiliki dua perapian! Benar, tidak ada yang istimewa untuk dinikmati di sini. Harap dicatat bahwa solusi untuk masalah penskalaan aplikasi yang ditampilkan di sini memiliki banyak kelemahan. Kita akan berbicara tentang bagaimana melakukannya dengan benar di bagian sumber daya Kubernetes lain yang disebut Deployment.

Sekarang pertimbangkan apa yang kita dapatkan setelah meluncurkan dua perapian identik. Yaitu, server web Nginx sekarang berjalan di dua pod yang berbeda. Dalam hal ini, kita dapat mengajukan dua pertanyaan:

1. Bagaimana cara memberikan akses ke server-server ini dari luar, dengan URL?
2. Bagaimana cara mengatur keseimbangan beban di antara mereka?

Pendekatan penskalaan salah

Di antara alat Kubernetes ada sumber daya dari layanan Formulir. Mari kita bicarakan mereka.

Praktik Kubernetes: Layanan

Layanan Kubernetes bertindak sebagai titik akses ke set perapian yang menyediakan fungsi yang sama dengan perapian ini. Layanan melakukan solusi dari tugas-tugas sulit bekerja dengan perapian dan menyeimbangkan beban di antara mereka.


Layanan Kubernetes Melayani Alamat IP

Di kluster Kubernet kami akan ada pod yang mengimplementasikan fungsi yang berbeda. Ini adalah aplikasi front-end, aplikasi web Spring, dan aplikasi Flask yang ditulis dengan Python. Hal ini menimbulkan pertanyaan tentang bagaimana layanan perlu memahami pod mana yang perlu dikerjakan, yaitu, bagaimana mencari tahu berdasarkan informasi apa yang harus dihasilkan sistem dari daftar titik akhir untuk pod.

Ini dilakukan dengan abstraksi Kubernetes lain yang disebut Label. Bekerja dengan tag terdiri dari dua tahap:

1. Penugasan label akan memberikan layanan untuk bekerja dengan.
2. Menerapkan "pemilih" ke layanan, yang menentukan pod mana yang diberi label, layanan akan bekerja.

Mungkin ini lebih mudah dibayangkan sebagai ilustrasi daripada menggambarkan.


Pod berlabel dan file manifesnya

Kita lihat di sini dua perapian yang, menggunakan app: sa-frontend construct, diberi label yang sama. Layanan ini tertarik pada polong dengan tanda tersebut.

Tag

Label memberi pengembang cara sederhana untuk mengatur sumber daya Kubernetes. Mereka adalah pasangan nilai kunci, Anda dapat menugaskan mereka ke sumber daya apa pun. Ubah file deskripsi hearth aplikasi frontend dan bawa ke tampilan yang ditunjukkan pada gambar sebelumnya. Setelah itu, simpan file-file ini dan jalankan perintah berikut:

 kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured 

Ketika perintah ini dieksekusi, sistem akan mengeluarkan peringatan (itu tidak sesuai dengan kami yang kami gunakan apply alih-alih create , kami memahami ini), tetapi, setelah peringatan, ia melaporkan bahwa pod yang sesuai dikonfigurasikan. Kami dapat memeriksa apakah label diberi label, dengan memfilter log yang ingin kami tampilkan informasinya:

 kubectl get pod -l app=sa-frontend NAME           READY STATUS    RESTARTS AGE sa-frontend    1/1 Running   0 2h sa-frontend2   1/1 Running   0 2h 

Cara lain untuk memverifikasi bahwa label memang telah diberi label adalah dengan melampirkan kunci --show-labels ke perintah sebelumnya. Karena ini, informasi tentang pod mereka juga akan mencakup data pada tanda mereka.

Sekarang tag telah ditetapkan dan kami siap mengonfigurasi layanan untuk bekerja dengannya. Karenanya, kami akan membahas deskripsi layanan seperti LoadBalancer .


Load balancing menggunakan layanan seperti LoadBalancer

▍ Deskripsi Layanan

Berikut ini adalah deskripsi YAML dari layanan seperti LoadBalancer :

 apiVersion: v1 kind: Service              # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer       # 2 ports: - port: 80               # 3   protocol: TCP          # 4   targetPort: 80         # 5 selector:                # 6   app: sa-frontend       # 7 

Jelaskan teks ini:

1. Kind : kami membuat layanan, sumber daya Service .
2. Type : jenis sumber daya yang ditunjukkan dalam spesifikasinya. Kami memilih jenis LoadBalancer , karena dengan layanan ini kami ingin menyelesaikan masalah keseimbangan beban antara perapian.
3. Port : port tempat layanan menerima permintaan.
4. Protocol : Protokol yang digunakan oleh layanan.
5. TargetPort : port tempat permintaan masuk dialihkan.
6. Selector : objek yang berisi informasi tentang pod mana layanan harus bekerja.
7. app: sa-frontend : properti ini menunjukkan dengan pod mana layanan akan bekerja. Yaitu, ini adalah pod tempat app: sa-frontend label app: sa-frontend diberikan.

Untuk membuat layanan, Anda harus menjalankan perintah berikut:

 kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created 

Anda dapat memeriksa status layanan sebagai berikut:

 kubectl get svc NAME             TYPE CLUSTER-IP      EXTERNAL-IP PORT(S) AGE sa-frontend-lb   LoadBalancer 10.101.244.40   <pending> 80:30708/TCP 7m 

Di sini Anda dapat melihat bahwa properti EXTERNAL-IP berada dalam status <pending> , tetapi Anda tidak dapat menunggu untuk itu berubah. Ini karena kami menggunakan Minikube. Jika kami membuat layanan seperti itu saat bekerja dengan penyedia layanan cloud tertentu, seperti Azure atau Google Cloud Platform, maka layanan tersebut akan memiliki alamat IP publik yang memungkinkan untuk mengaksesnya dari Internet.

Meskipun demikian, Minikube tidak akan mengizinkan kami untuk dipusingkan, memberi kami perintah yang berguna untuk debugging lokal sistem:

 minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser... 

Berkat perintah ini, browser akan diluncurkan yang akan mengakses layanan. Setelah layanan menerima permintaan, itu akan mengarahkannya kembali ke salah satu perapian (tidak masalah yang mana yang berada di bawahnya). Abstraksi ini memungkinkan kita untuk melihat sekelompok perapian sebagai entitas tunggal dan bekerja dengannya, menggunakan layanan sebagai titik akses tunggal untuk mereka.

Di bagian ini, kami berbicara tentang cara menetapkan label ke sumber daya, cara menggunakannya ketika mengkonfigurasi layanan sebagai penyeleksi. Di sini kami menggambarkan dan menciptakan layanan seperti LoadBalancer . Berkat ini, kami memecahkan masalah penskalaan aplikasi (penskalaan terdiri dari menambahkan perapian baru dengan label yang sesuai ke kluster) dan mengatur penyeimbangan beban antara perapian menggunakan layanan sebagai titik masuk.

Praktik Kubernetes: Penempatan

Penempatan adalah abstraksi dari Kubernet yang memungkinkan kita untuk mengontrol apa yang selalu ada dalam siklus hidup aplikasi. Ini tentang mengelola perubahan aplikasi. Aplikasi yang tidak berubah adalah aplikasi yang "mati". Jika aplikasi "hidup", maka Anda mungkin menemukan fakta bahwa persyaratannya berubah secara berkala, kodenya berkembang, kode ini dikemas dan digunakan. Selain itu, kesalahan dapat dilakukan pada setiap langkah proses.

Sumber daya dari tampilan Penerapan memungkinkan Anda untuk mengotomatiskan transisi dari satu versi aplikasi ke yang lain. Ini dilakukan tanpa mengganggu sistem, dan jika terjadi kesalahan selama proses ini, kami akan memiliki kesempatan untuk dengan cepat kembali ke versi aplikasi yang berfungsi sebelumnya.

▍Gunakan penyebaran

Sekarang cluster memiliki dua perapian dan layanan yang memberikan akses kepada mereka dari luar dan menyeimbangkan beban pada mereka.


Cluster Status Saat Ini

Kami berbicara tentang fakta bahwa menjalankan dua perapian berbeda dengan fungsi yang sama bukanlah ide yang baik. Saat menggunakan skema semacam itu, kita harus bekerja dengan masing-masing perapian secara terpisah, membuat, memperbarui, menghapus setiap perapian tertentu, mengamati keadaannya. Dengan pendekatan ini, tidak perlu berbicara tentang pembaruan cepat sistem atau rollback cepat dari pembaruan yang gagal. Kami tidak puas dengan keadaan ini, oleh karena itu kami akan menggunakan kemungkinan sumber daya Penempatan, yang ditujukan untuk menyelesaikan masalah di atas.

Sebelum kita melanjutkan pekerjaan, mari kita merumuskan tujuannya, yang akan memberi kita panduan yang akan berguna ketika mem-parsing file manifes penyebaran. Jadi inilah yang kami butuhkan:

1. Kami ingin dapat membuat dua perapian berdasarkan satu wadah rinormaloku/sentiment-analysis-frontend .
2. Kami membutuhkan sistem penyebaran aplikasi yang memungkinkannya bekerja tanpa gangguan saat diperbarui.
3. Kami ingin label app: sa-frontend ditugaskan app: sa-frontend , yang memungkinkan layanan sa-frontend-lb mendeteksi pod ini.

Kami sekarang akan menyatakan persyaratan ini sebagai deskripsi sumber daya Penempatan.

▍ Deskripsi Penerapan

Berikut ini adalah deskripsi YAML dari sumber daya tipe Penempatan, yang dibuat dengan mempertimbangkan persyaratan sistem di atas:

 apiVersion: extensions/v1beta1 kind: Deployment                                          # 1 metadata: name: sa-frontend spec: replicas: 2                                             # 2 minReadySeconds: 15 strategy:   type: RollingUpdate                                   # 3   rollingUpdate:     maxUnavailable: 1                                   # 4     maxSurge: 1                                         # 5 template:                                               # 6   metadata:     labels:       app: sa-frontend                                  # 7   spec:     containers:       - image: rinormaloku/sentiment-analysis-frontend         imagePullPolicy: Always                         # 8         name: sa-frontend         ports:           - containerPort: 80 

Mari kita analisis uraian ini:

1. Kind : dikatakan di sini bahwa kami sedang menggambarkan sumber daya dari tampilan Deployment .
2. Replicas : Properti objek spesifikasi penempatan yang menentukan berapa banyak instance (replika) perapian yang akan dijalankan.
3. Type : menjelaskan strategi yang digunakan dalam penyebaran ini ketika beralih dari versi saat ini ke yang baru. Strategi RollingUpdate memberikan nol waktu henti sistem selama peningkatan.
4. MaxUnavailable : ini adalah properti dari objek RollingUpdate , yang menetapkan jumlah maksimum perapian yang tidak tersedia (dibandingkan dengan jumlah perapian yang diinginkan) ketika melakukan pembaruan sistem berurutan. Dalam penerapan kami, yang menyiratkan adanya 2 replika, nilai properti ini menunjukkan bahwa setelah penyelesaian satu pod, pod lain akan dieksekusi, yang membuat aplikasi tersedia selama pembaruan.
5. MaxSurge : ini adalah properti dari objek RollingUpdate yang menggambarkan jumlah maksimum perapian yang dapat ditambahkan ke penyebaran (dibandingkan dengan jumlah perapian tertentu). Dalam kasus kami, nilainya, 1, berarti bahwa, ketika beralih ke versi baru dari program, kita dapat menambahkan sub lain ke kluster, yang akan mengarah pada fakta bahwa hingga tiga perapian dapat diluncurkan secara bersamaan.
6. Template : objek ini mendefinisikan templat perapian yang akan digunakan sumber daya Deployment dijelaskan untuk membuat perapian baru. Anda mungkin akan menemukan pengaturan ini akrab.
7. app: sa-frontend : label untuk perapian dibuat sesuai dengan pola yang diberikan.
8. ImagePullPolicy : mendefinisikan urutan kerja dengan gambar. Dalam kasus kami, properti ini diatur ke Always , yaitu, selama setiap penyebaran, gambar yang sesuai akan diunduh dari repositori.

Setelah memeriksa semua ini, mari kita lanjutkan ke latihan. Jalankan penyebaran:

 kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created 

Periksa status sistem:

 kubectl get pods NAME                           READY STATUS RESTARTS AGE sa-frontend                    1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4   1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg   1/1 Running 0 1m sa-frontend2                   1/1 Running 0 2d 

Seperti yang Anda lihat, sekarang kami memiliki 4 pod. Dua di antaranya dibuat menggunakan sumber daya Penempatan, dua lagi adalah yang kami buat sendiri. Sekarang Anda dapat menghapus pod-pod yang kami buat sendiri menggunakan perintah dari jenis berikut:

 kubectl delete pod <pod-name> 

Ngomong-ngomong, inilah tugas untuk pekerjaan independen. Hapus salah satu perapian yang dibuat menggunakan sumber daya Penempatan dan monitor sistem. Pikirkan alasan apa yang terjadi sebelum membaca lebih lanjut.

Saat menghapus satu perapian, sumber daya Penyebaran mengetahui bahwa kondisi sistem saat ini (1 sub) berbeda dari yang diinginkan (2 sub), jadi sub yang lain diluncurkan.

Apa gunanya sumber daya Penerapan, selain fakta bahwa ketika digunakan, sistem dipertahankan dalam keadaan yang benar? Pertimbangkan kekuatan sumber daya ini.

▍ Melakukan penyebaran dengan nol downtime sistem

Misalkan manajer produk mendatangi kami dan melaporkan bahwa klien yang kami buat produk ini ingin tombol hijau di aplikasi klien. Pengembang menerapkan persyaratan ini dan memberi kami satu-satunya yang kami butuhkan dari mereka - wadah gambar yang disebut rinormaloku/sentiment-analysis-frontend:green . Sekarang tiba saatnya kita. Kami, tim DevOps, perlu menggunakan sistem yang diperbarui dan memastikan tidak ada downtime. Sekarang mari kita lihat apakah upaya untuk mengembangkan dan mengkonfigurasi sumber daya Penempatan dibenarkan.

Edit file sa-frontend-deployment.yaml , ganti nama wadah gambar dengan yang baru, dengan rinormaloku/sentiment-analysis-frontend:green , lalu simpan file ini sebagai sa-frontend-deployment-green.yaml dan jalankan perintah berikut:

 kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured 

Periksa status sistem dengan perintah berikut:

 kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out 

Sesuai dengan data yang ditampilkan dalam menanggapi perintah ini, kita dapat menyimpulkan bahwa penyebaran pembaruan berhasil. Selama peningkatan, replika lama, satu per satu, diganti dengan yang baru. , , , . , , .

, , :

 minikube service sa-frontend-lb 

, .




, , — .

RollingUpdate

, kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , , rinormaloku/sentiment-analysis-frontend:green . , , .




RollingUpdate , , maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .

Deployment. , . .

▍

, , . «! ! !», — . . , , :

 kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION  CHANGE-CAUSE 1         <none>    2         kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true 

: «, , ?».

«. , ?», — .

, , :

 kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back 

. , .

.

.

!

, . Kubernetes , , . , !

. , . CHANGE-CAUSE <none> , — kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?

, -- record , .

, , , .

Kubernetes:

Kubernetes, , . , .




.

▍ sa-logic

resource-manifests :

 kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created 

sa-logic . Python-. app: sa-logic . sa-logic , . sa-logic-deployment.yaml .

-, , — sa-logic .

▍ sa-logic

, Service. , Java-, sa-webapp , , Python-. , , , Python-, . , , , .

, , , , . , sa-logic , sa-logic .

:

 kubectl apply -f service-sa-logic.yaml service "sa-logic" created 

, .




sa-logic , sa-webapp , , .

sa-webapp .

▍ sa-webapp

, Deployment - . , sa-web-app-deployment.yaml , :

 - image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env:   - name: SA_LOGIC_API_URL     value: "http://sa-logic" ports:   - containerPort: 8080 

env ? , , , SA_LOGIC_API_URL http://sa-logic . , , . ?

kube-dns.

▍DNS- Kubernetes

Kubernetes , kube-dns . DNS-. kube-dns , DNS- .

, sa-logic , IP-. kube-dns IP- . http://sa-logic IP-.

Deployment sa-webapp .

▍ sa-webapp

:

 kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created 

sa-webapp , . React- , sa-webapp .

▍ sa-webapp

service-sa-web-app-lb.yaml , , , , . , , :

 kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created 

. , , . , sa-frontend , Java- sa-webapp , http://localhost:8080/sentiment . , , sa-webapp , React- , Java-.

, . , — , , .

, :

1. IP- sa-webapp , :
   
   minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------|
2. IP- sa-frontend/src/App.js . , :
   
   

    analyzeSentence() {       fetch('http://192.168.99.100:31691/sentiment', { /*    */})           .then(response => response.json())           .then(data => this.setState(data));   } 

3. React-, sa-frontend npm run build .
4. :
   
   

    docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube. 

5. Docker Hub:
   
   

    docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube 

6. sa-frontend-deployment.yaml , .
7. :
   
   

    kubectl apply -f sa-frontend-deployment.yaml 

, , , , minikube service sa-frontend-lb . , - .

Ringkasan

Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.

, :

• , , React, Java Python.
• Docker, , Dockerfile .
• , , Docker Hub.

, Kubernetes:

• Layanan

, , Kubernetes.

Pembaca yang budiman! Kubernetes?