Phenquestions
Dalam artikel sebelumnya kami menerapkan Cluster Kubernetes dengan satu master dan satu node pekerja. Cluster Kubernetes terutama tentang dua hal; Node dan Pod. Pod adalah aplikasi dalam container yang ingin Anda terapkan pada cluster dan node adalah server komputasi individual yang bertanggung jawab untuk mengelola cluster atau menjalankan aplikasi. Untuk mempermudah, kita mulai dengan aplikasi stateless dan memperkenalkan berbagai konsep seperti label dan selektor yang digunakan untuk mengikat pod satu sama lain.
Ada konsep penting lainnya seperti set replika, layanan, dan penerapan yang semuanya akan kita pelajari di artikel ini.
Penerapan aplikasi tradisional
Jika Anda melihat pendekatan tradisional untuk menerapkan aplikasi web, skalabilitas adalah sesuatu yang harus Anda pertimbangkan sebelum memulai. Jika Anda memerlukan database yang terpisah dari front-end web Anda, lebih baik Anda melakukannya sekarang daripada melakukannya nanti. Apakah Anda berencana menjalankan lebih dari satu aplikasi web?? Lebih baik konfigurasikan server Proxy Terbalik sebelumnya.
Dengan Kubernetes, pendekatannya telah berubah. Deployment dapat dilakukan dengan mempertimbangkan kebutuhan saat ini dan nantinya dapat ditingkatkan seiring pertumbuhan bisnis Anda. Containerization memungkinkan Anda untuk memisahkan komponen penting dari layanan web Anda, bahkan ketika mereka berjalan pada satu node. Kemudian ketika Anda menskalakan secara horizontal (yang berarti Anda menambahkan lebih banyak server ke lingkungan Anda), Anda hanya perlu memutar lebih banyak container, dan Kubernetes akan menjadwalkannya pada node yang sesuai untuk Anda. Proksi terbalik? Layanan Kubernetes akan datang untuk menyelesaikan masalah itu.
Polong
Sebagai langkah pertama, mari kita putar pod. Untuk melakukan itu kita memerlukan file YAML yang mendefinisikan berbagai atribut pod.
apiVersi: v1jenis: Pod
metadata:
nama : nginx
spesifikasi:
wadah:
- nama : nginx
gambar: nginx: 1.7.9
port:
- containerPort: 80
Tambahkan konten di atas dalam a polong.yaml file dan simpan. Melihat teks di atas, Anda dapat melihat bahwa jenis sumber daya yang kami buat adalah polong. Kami menamakannya nginx, dan gambarnya adalah nginx: 1.7.9 yang, secara default, berarti Kubernetes akan mengambil gambar nginx yang sesuai dari gambar hub Docker yang tersedia untuk umum.
Dalam organisasi skala besar, K8 sering dikonfigurasi untuk menunjuk ke registri pribadi dari mana ia dapat menarik gambar kontainer yang sesuai.
Sekarang untuk memulai menjalankan pod:
$kubectl create -f pod.yamlAnda tidak dapat mengakses pod dari luar cluster. Itu belum terungkap, dan itu hanya ada sebagai pod soliter. Untuk memastikan bahwa itu memang digunakan, jalankan:
$kubectl dapatkan pod
Untuk menyingkirkan pod bernama nginx, jalankan perintah:
$kubectl hapus pod nginxDeployment
Mendapatkan hanya satu pod yang berfungsi bukanlah inti dari Kubernetes, yang kita inginkan, idealnya, adalah beberapa replika dari sebuah pod, sering kali dijadwalkan pada node yang berbeda sehingga jika satu atau lebih node gagal, sisa pod akan tetap ada untuk diambil meningkatkan beban kerja tambahan.
Selain itu, dari sudut pandang pengembangan, kita perlu memiliki beberapa cara untuk meluncurkan pod dengan versi perangkat lunak yang lebih baru dan membuat pod yang lebih lama tidak aktif. Jika ada masalah dengan pod yang lebih baru, kami dapat mengembalikannya dengan mengembalikan pod yang lebih lama dan menghapus versi yang gagal. Deployment memungkinkan kami melakukan itu.
Berikut ini adalah cara yang sangat umum untuk mendefinisikan penerapan:
apiVersi: apps/v1beta1jenis: Penyebaran
metadata:
nama: nginx-deployment
spesifikasi:
replika: 2
pola:
metadata:
label:
aplikasi: nginx
spesifikasi:
wadah:
- nama : nginx
gambar: nginx: 1.7.9
port:
- containerPort: 80
Anda akan melihat, antara lain, pasangan nilai kunci yaitu:
label:
aplikasi: nginx
Label penting untuk manajemen cluster karena membantu melacak sejumlah besar pod dengan tugas yang sama. Pod dibuat atas perintah master node, dan mereka berkomunikasi dengan master node. Namun, kami masih membutuhkan cara yang efektif bagi mereka untuk berbicara satu sama lain dan bekerja sama sebagai sebuah tim.
Jasa
Setiap pod memiliki alamat IP internalnya sendiri dan lapisan komunikasi seperti Flanel membantu pod untuk berkomunikasi satu sama lain. Alamat IP ini, bagaimanapun, sedikit berubah dan, bagaimanapun juga, inti dari memiliki banyak pod adalah membiarkannya sekali pakai. Pod sering dibunuh dan dibangkitkan.
Pertanyaan yang sekarang muncul adalah - Bagaimana pod front-end akan berbicara dengan pod back-end ketika hal-hal begitu dinamis di cluster?
Layanan datang ke dalam gambar untuk menyelesaikan kompleksitas ini. Service adalah pod lain yang bertindak seperti penyeimbang beban antara subset pod dan cluster Kubernetes lainnya. Itu mengikat dirinya sendiri ke semua pod yang memiliki label khusus yang melekat padanya, misalnya, database, dan kemudian mengekspos mereka untuk sisa cluster.
Misalnya jika kita memiliki layanan database dengan 10 pod database, beberapa pod database dapat muncul, atau terbunuh, tetapi layanan tersebut akan memastikan bahwa cluster lainnya mendapatkan 'layanan' yang merupakan database. Layanan juga dapat digunakan untuk mengekspos front-end ke seluruh Internet.
Berikut adalah definisi khas dari layanan.
apiVersi: v1jenis: Layanan
metadata:
nama: wordpress-mysql
label:
aplikasi: wordpress
spesifikasi:
port:
- pelabuhan: 3306
pemilih:
aplikasi: wordpress
tingkat: mysql
clusterIP: Tidak ada
Pod berlabel WordPress dengan tier mysql yang ditentukan adalah yang akan diambil oleh layanan ini dan diekspos ke pod server web untuk pengaturan WordPress biasa yang dilakukan di Kubernetes.
Kata Hati-hati
Saat menerapkan aplikasi multi-tingkat raksasa yang ditargetkan ke basis konsumen yang besar, menjadi sangat tergoda untuk menulis banyak layanan (atau layanan mikro, seperti yang dikenal). Meskipun ini adalah solusi elegan untuk sebagian besar kasus penggunaan, banyak hal dapat dengan cepat menjadi tidak terkendali.
Layanan, seperti pod, rentan terhadap kegagalan. Satu-satunya perbedaan adalah ketika sebuah layanan gagal, banyak pod yang berfungsi sempurna, menjadi tidak berguna. Akibatnya, jika Anda memiliki interkoneksi layanan yang besar (baik internal maupun eksternal) dan ada sesuatu yang gagal, mencari tahu titik kegagalan menjadi tidak mungkin.
Sebagai aturan praktis, jika Anda memiliki visualisasi kasar dari cluster, atau jika Anda dapat menggunakan perangkat lunak seperti kokpit untuk melihat cluster dan memahaminya, pengaturan Anda baik-baik saja. Kubernetes, pada akhirnya, dirancang untuk mengurangi kompleksitas, bukan meningkatkannya.
