Platform Red Hat OpenShift Container Platform 4 memungkinkan Anda untuk mengalirkan pembuatan
host untuk penyebaran kontainer , termasuk dalam infrastruktur penyedia layanan cloud, pada platform virtualisasi atau dalam sistem bare-metal. Untuk membuat platform cloud dalam arti penuh, kami harus mengambil kendali ketat dari semua elemen yang digunakan dan dengan demikian meningkatkan keandalan proses otomasi yang kompleks.
Solusi yang jelas adalah menggunakan Red Hat Enterprise Linux CoreOS (variasi dari Red Hat Enterprise Linux) dan CRI-O sebagai standar, dan inilah sebabnya ...
Karena topik navigasi sangat berhasil untuk menemukan analogi dalam menjelaskan operasi Kubernet dan wadah, mari kita coba untuk membicarakan masalah-masalah bisnis yang dipecahkan oleh CoreOS dan CRI-O, dengan menggunakan contoh
penemuan Brunel untuk produksi blok-blok rigging . Pada tahun 1803, Mark Brunel ditugaskan untuk membuat 100.000 blok rigging untuk kebutuhan angkatan laut Inggris yang sedang tumbuh. Blok pengangkat adalah jenis rig yang digunakan untuk memasang tali pada layar. Hingga awal abad ke-19, balok-balok ini dibuat dengan tangan, tetapi Brunel mampu mengotomatisasi produksi dan mulai memproduksi balok standar dengan menggunakan mesin. Otomatisasi proses ini berarti bahwa, semua blok hampir sama, dapat dengan mudah diganti jika terjadi kerusakan, dan dapat dibuat dalam jumlah besar.
Sekarang bayangkan Brunel harus melakukan pekerjaan ini untuk 20 model kapal yang berbeda (versi Kubernetes) dan untuk lima planet berbeda dengan arus dan angin laut yang sangat berbeda (penyedia cloud). Selain itu, semua kapal (klaster OpenShift) diharuskan, terlepas dari planet mana pun yang dinavigasi, dari sudut pandang kapten (operator yang mengendalikan operasi kluster) berperilaku identik. Melanjutkan analogi kelautan, kapten kapal benar-benar tidak peduli blok rigging (CRI-O) apa yang digunakan pada kapal mereka - hal utama bagi mereka adalah bahwa blok ini kuat dan dapat diandalkan.
OpenShift 4, sebagai platform cloud, menghadapi tantangan bisnis yang sangat mirip. Node baru harus dibuat pada saat pembuatan cluster, dalam hal terjadi kegagalan di salah satu node, atau ketika scaling cluster. Saat membuat dan menginisialisasi node baru, komponen host kritis, termasuk CRI-O, harus dikonfigurasi dengan tepat. Seperti dalam produksi lain, "bahan baku" harus dipasok di awal. Dalam kasus kapal, logam dan kayu bertindak sebagai bahan baku. Namun, jika Anda membuat host untuk menggunakan kontainer di cluster OpenShift 4, Anda harus memiliki file konfigurasi dan server API yang disediakan di input. Setelah itu, OpenShift akan memberikan tingkat otomatisasi yang diperlukan sepanjang siklus hidup, menawarkan dukungan produk yang diperlukan untuk pengguna akhir dan dengan demikian membayar investasi dalam platform.
OpenShift 4 dibuat sedemikian rupa untuk memberikan kemampuan untuk memperbarui sistem dengan nyaman sepanjang siklus hidup platform (untuk versi 4.X) untuk semua pemasok utama komputasi awan, platform virtualisasi, dan bahkan sistem logam telanjang. Untuk ini, node harus dibuat berdasarkan elemen yang dapat dipertukarkan. Ketika sebuah cluster membutuhkan versi baru Kubernetes, itu juga menerima versi CRI-O yang sesuai pada CoreOS. Karena versi CRI-O terkait langsung dengan Kubernetes, semua ini sangat menyederhanakan permutasi untuk pengujian, pemecahan masalah atau dukungan. Selain itu, pendekatan ini mengurangi biaya untuk pengguna akhir dan Red Hat.
Ini adalah tampilan fundamental baru pada kluster Kubernetes, yang meletakkan dasar untuk perencanaan fitur baru yang sangat berguna dan menarik. CRI-O (proyek kontainer terbuka Interface Runtime Interface - Open Container Initiative, disingkat CRI-OCI) adalah pilihan paling sukses untuk pembuatan massal node, yang diperlukan untuk bekerja dengan OpenShift. CRI-O akan menggantikan mesin Docker yang sebelumnya digunakan, menawarkan pengguna OpenShift yang
ekonomis, stabil, sederhana, dan membosankan - ya, Anda mendengarnya dengan benar - mesin kontainer membosankan yang dirancang khusus untuk bekerja dengan Kubernetes.
Dunia wadah terbuka
Dunia telah lama bergerak menuju wadah terbuka. Baik di Kubernetes, atau di tingkat yang lebih rendah,
pengembangan standar wadah mengarah pada ekosistem inovasi di setiap tingkat.
Semuanya dimulai dengan penciptaan Open Containers Initiative
pada Juni 2015 . Pada tahap awal pekerjaan ini, spesifikasi untuk
gambar kontainer
(gambar) dan
runtime terbentuk. Ini memungkinkan jaminan bahwa alat dapat menggunakan standar tunggal
gambar wadah dan format tunggal untuk bekerja dengannya. Spesifikasi
distribusi kemudian ditambahkan, yang memungkinkan pengguna untuk dengan mudah bertukar
gambar kontainer .
Komunitas Kubernetes kemudian mengembangkan standar antarmuka tunggal pluggable yang disebut
Container Runtime Interface (CRI) . Berkat ini, pengguna Kubernetes dapat menghubungkan berbagai mesin untuk bekerja dengan kontainer selain Docker.
Insinyur Red Hat dan Google melihat permintaan pasar untuk mesin kontainer yang dapat menerima permintaan dari Kubelet menggunakan protokol CRI dan memperkenalkan kontainer yang kompatibel dengan spesifikasi OCI yang disebutkan di atas. Jadi
ada OCID . Tetapi permisi, karena kami mengatakan bahwa materi ini akan dikhususkan untuk CRI-O? Faktanya, hanya dengan merilis
versi 1.0, proyek ini berganti nama menjadi CRI-O.
Fig. 1.Inovasi dengan CRI-O dan CoreOS
Dengan peluncuran platform OpenShift 4,
mesin kontainer yang digunakan di platform default diubah, dan Docker digantikan oleh CRI-O, yang menawarkan lingkungan peluncuran kontainer yang ekonomis, stabil, sederhana dan membosankan, yang berkembang secara paralel dengan Kubernetes. Ini sangat menyederhanakan dukungan dan konfigurasi cluster. Mengkonfigurasi mesin wadah dan host, serta mengelolanya, menjadi otomatis dalam OpenShift 4.
Berhenti, bagaimana?
Itu benar, dengan munculnya OpenShift 4, sekarang tidak ada lagi kebutuhan untuk terhubung ke host individu dan menginstal mesin kontainer, mengkonfigurasi penyimpanan, mengkonfigurasi server untuk pencarian, atau mengkonfigurasi jaringan. Platform OpenShift 4 telah sepenuhnya dirancang ulang untuk menggunakan
Kerangka Operator tidak hanya dalam hal aplikasi pengguna akhir, tetapi juga dalam hal operasi tingkat platform dasar, seperti menyebarkan gambar, mengkonfigurasi sistem, atau menginstal pembaruan.
Kubernetes selalu memungkinkan pengguna untuk mengelola aplikasi dengan menentukan status yang diinginkan dan menggunakan
Pengontrol untuk memastikan bahwa kondisi aktual sedekat mungkin dengan keadaan yang diberikan.
Pendekatan ini
menggunakan keadaan tertentu dan keadaan aktual membuka peluang besar baik dari sudut pandang pengembangan maupun dari sudut pandang operasi. Pengembang dapat menentukan status yang diperlukan,
mentransfernya ke operator dalam bentuk file YAML atau JSON, dan kemudian operator dapat membuat instance aplikasi yang diperlukan dalam lingkungan operasi, sedangkan status operasional instance ini sepenuhnya sesuai dengan yang ditentukan.
Menggunakan Operator di platform, OpenShift 4 membawa paradigma baru ini (menggunakan konsep set dan state aktual) ke manajemen RHEL CoreOS dan CRI-O. Tugas-tugas untuk mengkonfigurasi dan membuat versi sistem operasi dan mesin kontainer diotomatisasi menggunakan apa yang disebut
Machine Config Operator (MCO) . MCO sangat menyederhanakan pekerjaan administrator cluster, pada dasarnya mengotomatiskan tahap terakhir instalasi, serta operasi selanjutnya setelah instalasi (hari kedua operasi). Semua ini menjadikan OpenShift 4 platform cloud sejati. Kita akan membahasnya nanti.
Peluncuran kontainer
Pengguna memiliki kesempatan untuk menggunakan mesin CRI-O di platform OpenShift mulai dari versi 3.7 dalam status Tech Preview dan dari versi 3.9 dalam status Tersedia Secara Umum (saat ini didukung). Selain itu, Red Hat menggunakan
CRI-O secara ekstensif untuk meluncurkan beban kerja produksi di OpenShift Online sejak versi 3.10. Semua ini memungkinkan tim yang bekerja pada CRI-O untuk mendapatkan pengalaman luas dalam peluncuran massal kontainer pada kelompok Kubernet besar. Untuk mendapatkan pemahaman dasar tentang bagaimana Kubernet menggunakan CRI-O, mari kita lihat ilustrasi berikut, yang menunjukkan cara kerja arsitektur.
Fig. 2. Bagaimana wadah bekerja di kluster KubernetesCRI-O menyederhanakan pembuatan host kontainer baru dengan menyinkronkan seluruh level teratas ketika menginisialisasi node baru, dan ketika merilis versi baru platform OpenShift. Seluruh audit platform memungkinkan pembaruan / rollback transaksional, dan juga mencegah kebuntuan dalam dependensi antara kernel ekor kontainer, mesin kontainer, Kubelets, dan Kubernetes Master. Dengan manajemen terpusat dari semua komponen platform, dengan kontrol dan manajemen versi, Anda selalu dapat melacak jalur yang jelas dari negara A ke negara B. Ini menyederhanakan proses pembaruan, meningkatkan keamanan, meningkatkan pelaporan kinerja dan membantu mengurangi biaya memperbarui dan menginstal versi baru.
Demonstrasi kekuatan elemen yang dapat dipertukarkan
Seperti yang disebutkan sebelumnya, menggunakan Operator Konfigurasi Mesin untuk mengelola host kontainer dan mesin kontainer di OpenShift 4 memberikan tingkat otomatisasi baru yang sebelumnya tidak mungkin terjadi pada platform Kubernetes. Untuk mendemonstrasikan fitur-fitur baru, kami menunjukkan bagaimana Anda dapat membuat perubahan pada file crio.conf. Agar tidak bingung dalam terminologi, cobalah untuk fokus pada hasilnya.
Pertama, mari kita buat apa yang disebut konfigurasi runtime kontainer - Container Runtime Config. Pertimbangkan ini sumber daya Kubernetes yang mewakili konfigurasi untuk CRI-O. Pada kenyataannya, ini adalah versi khusus dari apa yang disebut MachineConfig, yang merupakan konfigurasi apa pun yang digunakan pada mesin RHEL CoreOS di dalam cluster OpenShift.
Sumber daya kustom ini, disebut ContainerRuntimeConfig, diciptakan untuk memudahkan administrator klaster untuk mengkonfigurasi CRI-O. Ini adalah alat yang cukup kuat yang hanya bisa diterapkan ke node tertentu tergantung pada pengaturan MachineConfigPool. Pertimbangkan ini sekelompok mesin yang memiliki tujuan yang sama.
Perhatikan dua baris terakhir yang akan kita ubah di file /etc/crio/crio.conf. Dua baris ini sangat mirip dengan baris dalam file crio.conf, ini adalah:
vi ContainerRuntimeConfig.yaml
Kesimpulan:
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug
Sekarang kirim file ini ke kluster Kubernetes dan verifikasi bahwa itu sebenarnya dibuat. Harap dicatat bahwa operasi dilakukan dengan cara yang sama dengan sumber daya Kubernet lainnya:
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
Kesimpulan:
NAME AGE set-log-and-pid 22h
Setelah kami membuat ContainerRuntimeConfig, kami perlu memodifikasi salah satu dari MachineConfigPools untuk membuat Kubernet memahami bahwa kami ingin menerapkan konfigurasi ini ke grup mesin tertentu di cluster. Dalam hal ini, kami akan mengubah MachineConfigPool untuk node master:
oc edit MachineConfigPool/master
Kesimpulan (untuk kejelasan, poin utama tersisa):
... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ...
Pada titik ini, MCO mulai membuat file crio.conf baru untuk cluster. Dalam hal ini, file konfigurasi yang sudah selesai dapat dilihat menggunakan Kubernetes API. Ingat, ContainerRuntimeConfig hanyalah versi khusus dari MachineConfig, jadi kita bisa melihat hasilnya dengan melihat baris-baris di MachineConfigs:
oc get MachineConfigs | grep rendered
Kesimpulan:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Harap perhatikan bahwa file konfigurasi yang dihasilkan untuk node master ternyata merupakan versi yang lebih baru daripada konfigurasi asli. Untuk melihatnya, jalankan perintah berikut. Secara sepintas, kami mencatat bahwa ini mungkin salah satu skrip baris tunggal terbaik dalam sejarah Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Kesimpulan:
pids_limit = 2048
Sekarang pastikan bahwa konfigurasi telah diterapkan ke semua node master. Pertama kita mendapatkan daftar node di cluster:
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Sekarang lihat file yang diinstal. Anda akan melihat bahwa file telah diperbarui dengan arahan pid dan debug baru yang kami tentukan dalam sumber daya ContainerRuntimeConfig. Keanggunan itu sendiri:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
Kesimpulan:
... pids_limit = 2048 ... log_level = "debug" ...
Semua perubahan ini di cluster dibuat bahkan tanpa memulai SSH. Semua pekerjaan dilakukan dengan menghubungi simpul utama Kuberentes. Artinya, parameter baru ini hanya dikonfigurasikan pada node master. Pada saat yang sama, node yang bekerja tidak berubah, yang menunjukkan kelebihan metodologi Kubernetes menggunakan set dan kondisi saat ini sebagaimana diterapkan pada host kontainer dan mesin kontainer dengan elemen yang dapat dipertukarkan.
Contoh di atas menunjukkan kemampuan untuk membuat perubahan pada klaster OpenShift Platform Platform 4 kecil dengan tiga simpul kerja atau ke kluster produksi besar dengan 3000 simpul. Bagaimanapun, jumlah pekerjaan akan sama - dan sangat kecil - cukup konfigurasikan file ContainerRuntimeConfig, dan ubah satu label di MachineConfigPool. Dan Anda dapat melakukan ini dengan versi apa pun dari platform OpenShift Container Platform 4.X yang digunakan oleh Kubernetes sepanjang siklus hidupnya.
Seringkali, perusahaan teknologi berkembang sangat cepat sehingga kami tidak dapat menjelaskan mengapa kami memilih teknologi tertentu untuk komponen dasar. Mesin kontainer secara historis merupakan komponen yang digunakan pengguna untuk berinteraksi secara langsung. Karena popularitas kontainer secara alami dimulai dengan munculnya mesin kontainer, pengguna sering menunjukkan minat terhadapnya. Ini adalah alasan lain mengapa Red Hat memilih untuk CRI-O. Kontainer sedang berkembang, dengan fokus pada orkestrasi hari ini, dan kami sampai pada kesimpulan bahwa CRI-O memberikan pengalaman terbaik ketika bekerja dengan OpenShift 4.