Panggung memungkinkan Anda menyederhanakan pembuatan , termasuk dalam infrastruktur penyedia layanan cloud, pada platform virtualisasi, atau dalam sistem bare-metal. Untuk menciptakan platform yang benar-benar berbasis cloud, kami harus mengontrol secara ketat semua elemen yang digunakan sehingga meningkatkan keandalan proses otomatisasi yang kompleks.
Solusi yang jelas adalah menggunakan Red Hat Enterprise Linux CoreOS (varian dari Red Hat Enterprise Linux) dan CRI-O sebagai standar, dan inilah alasannya...
Karena topik pelayaran adalah topik yang sangat bagus untuk menemukan analogi ketika menjelaskan cara kerja Kubernetes dan container, mari kita coba membahas masalah bisnis yang dipecahkan oleh CoreOS dan CRI-O, dengan menggunakan sebuah contoh. . Pada tahun 1803, Marc Brunel ditugaskan memproduksi 100 blok tali-temali untuk kebutuhan angkatan laut Inggris yang sedang berkembang. Blok tali-temali adalah jenis tali-temali yang digunakan untuk memasang tali pada layar. Hingga awal abad ke-19, balok-balok ini dibuat dengan tangan, tetapi Brunel berhasil mengotomatisasi produksi dan mulai memproduksi balok-balok standar menggunakan peralatan mesin. Otomatisasi proses ini berarti bahwa balok-balok yang dihasilkan hampir sama, dapat dengan mudah diganti jika rusak, dan dapat diproduksi dalam jumlah besar.
Sekarang bayangkan jika Brunel harus melakukan pekerjaan ini untuk 20 model kapal berbeda (versi Kubernetes) dan untuk lima planet berbeda dengan arus laut dan angin yang sangat berbeda (penyedia cloud). Selain itu, semua kapal (kluster OpenShift), terlepas dari planet tempat navigasi dilakukan, diwajibkan, dari sudut pandang kapten (operator yang mengelola pengoperasian kluster) berperilaku sama. Untuk melanjutkan analogi maritim, kapten kapal sama sekali tidak peduli jenis rigging block (CRI-O) apa yang digunakan di kapalnya - yang utama bagi mereka adalah blok tersebut kuat dan dapat diandalkan.
OpenShift 4, sebagai platform cloud, menghadapi tantangan bisnis yang sangat mirip. Node baru harus dibuat pada saat pembuatan cluster, jika terjadi kegagalan pada salah satu node, atau saat penskalaan cluster. Ketika node baru dibuat dan diinisialisasi, komponen host penting, termasuk CRI-O, harus dikonfigurasikan sesuai dengan itu. Seperti dalam produksi lainnya, βbahan mentahβ harus dipasok di awal. Untuk kapal, bahan bakunya adalah logam dan kayu. Namun, jika membuat host untuk menyebarkan container di cluster OpenShift 4, Anda harus memiliki file konfigurasi dan server yang disediakan API sebagai input. OpenShift kemudian akan memberikan tingkat otomatisasi yang diperlukan di seluruh siklus hidup, menawarkan dukungan produk yang diperlukan kepada pengguna akhir dan dengan demikian mengembalikan investasi pada platform.
OpenShift 4 dibuat sedemikian rupa untuk memberikan kemampuan memperbarui sistem dengan mudah di seluruh siklus hidup platform (untuk versi 4.X) untuk semua penyedia komputasi awan utama, platform virtualisasi, dan bahkan sistem bare metal. Untuk melakukan ini, node harus dibuat berdasarkan elemen yang dapat dipertukarkan. Ketika sebuah cluster memerlukan versi baru Kubernetes, cluster tersebut juga menerima versi CRI-O yang sesuai di CoreOS. Karena versi CRI-O terikat langsung dengan Kubernetes, hal ini sangat menyederhanakan permutasi apa pun untuk tujuan pengujian, pemecahan masalah, atau dukungan. Selain itu, pendekatan ini mengurangi biaya bagi pengguna akhir dan Red Hat.
Ini adalah cara berpikir baru yang mendasar tentang klaster Kubernetes dan meletakkan dasar untuk merencanakan beberapa fitur baru yang sangat berguna dan menarik. CRI-O (Container Runtime Interface - Open Container Initiative, disingkat CRI-OCI) ternyata menjadi pilihan paling sukses untuk pembuatan massal node yang diperlukan untuk bekerja dengan OpenShift. CRI-O akan menggantikan mesin Docker yang digunakan sebelumnya, menawarkan OpenShift kepada pengguna β ya, Anda tidak salah dengar β mesin container membosankan yang dibuat khusus untuk bekerja dengan Kubernetes.
Dunia kontainer terbuka
Dunia sudah lama beralih ke kontainer terbuka. Baik di Kubernetes, atau di level yang lebih rendah, menghasilkan ekosistem inovasi di setiap tingkat.
Semuanya dimulai dengan penciptaan Open Containers Initiative . Pada tahap awal pengerjaan ini, spesifikasi kontainer telah dibentuk ΠΈ . Hal ini memastikan bahwa alat tersebut dapat menggunakan standar tunggal dan format terpadu untuk bekerja dengannya. Spesifikasi kemudian ditambahkan , memungkinkan pengguna untuk berbagi dengan mudah .
Komunitas Kubernetes kemudian mengembangkan standar tunggal untuk antarmuka pluggable, yang disebut . Berkat ini, pengguna Kubernetes dapat menghubungkan berbagai mesin untuk bekerja dengan container selain Docker.
Insinyur di Red Hat dan Google melihat kebutuhan pasar akan mesin container yang dapat menerima permintaan Kubelet melalui protokol CRI dan memperkenalkan container yang kompatibel dengan spesifikasi OCI yang disebutkan di atas. Jadi . Tapi maaf, bukankah kami mengatakan bahwa materi ini akan didedikasikan untuk CRI-O? Sebenarnya iya, baru saja dirilis proyek ini berganti nama menjadi CRI-O.
Gambar. 1.
Inovasi dengan CRI-O dan CoreOS
Dengan diluncurkannya platform OpenShift 4, hal itu berubah , digunakan secara default di platform, dan Docker digantikan oleh CRI-O, menawarkan lingkungan yang hemat biaya, stabil, sederhana dan membosankan untuk menjalankan container yang berkembang secara paralel dengan Kubernetes. Ini sangat menyederhanakan dukungan dan konfigurasi cluster. Konfigurasi mesin kontainer dan host, serta manajemennya, menjadi otomatis dalam OpenShift 4.
Tunggu, bagaimana ini?
Benar sekali, dengan hadirnya OpenShift 4, tidak ada lagi kebutuhan untuk terhubung ke masing-masing host dan memasang mesin kontainer, mengonfigurasi penyimpanan, mengonfigurasi server pencarian, atau mengonfigurasi jaringan. Platform OpenShift 4 telah didesain ulang sepenuhnya untuk menggunakan 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 mengizinkan pengguna untuk mengelola aplikasi dengan menentukan keadaan yang diinginkan dan menggunakannya , untuk memastikan bahwa keadaan sebenarnya sedekat mungkin dengan keadaan target. Ini membuka peluang besar baik dari perspektif pengembangan maupun operasi. Pengembang dapat menentukan status yang diperlukan dengan ke operator dalam bentuk file YAML atau JSON, dan kemudian operator dapat membuat instance aplikasi yang diperlukan di lingkungan produksi, dan status pengoperasian instance ini akan sepenuhnya sesuai dengan yang ditentukan.
Dengan menggunakan Operator di platform, OpenShift 4 menghadirkan paradigma baru ini (menggunakan konsep himpunan dan keadaan aktual) ke dalam pengelolaan RHEL CoreOS dan CRI-O. Tugas mengonfigurasi dan mengelola versi sistem operasi dan mesin kontainer diotomatisasi menggunakan apa yang disebut . MCO sangat menyederhanakan pekerjaan administrator cluster, pada dasarnya mengotomatiskan tahap terakhir instalasi, serta operasi pasca instalasi berikutnya (operasi hari kedua). Semua ini menjadikan OpenShift 4 platform cloud sejati. Kita akan membahasnya nanti.
Menjalankan kontainer
Pengguna mempunyai kesempatan untuk menggunakan mesin CRI-O di platform OpenShift sejak versi 3.7 dalam status Pratinjau Teknologi dan dari versi 3.9 dalam status Tersedia Secara Umum (saat ini didukung). Selain itu, Red Hat banyak digunakan di OpenShift Online sejak versi 3.10. Semua ini memungkinkan tim yang mengerjakan CRI-O memperoleh pengalaman luas dalam meluncurkan kontainer secara massal di cluster Kubernetes yang besar. Untuk mendapatkan pemahaman dasar tentang bagaimana Kubernetes menggunakan CRI-O, mari kita lihat ilustrasi berikut, yang menunjukkan cara kerja arsitekturnya.
Beras. 2. Cara kerja container di cluster Kubernetes
CRI-O menyederhanakan pembuatan host kontainer baru dengan menyinkronkan seluruh level teratas saat menginisialisasi node baru, dan saat merilis versi baru platform OpenShift. Revisi seluruh platform memungkinkan pembaruan/pengembalian transaksional, dan juga mencegah kebuntuan dalam ketergantungan antara inti ekor kontainer, mesin kontainer, node (Kubelets) dan node Master Kubernetes. Dengan mengelola semua komponen platform secara terpusat, dengan kontrol dan pembuatan versi, selalu ada jalur yang jelas dari status A ke status B. Hal ini menyederhanakan proses pembaruan, meningkatkan keamanan, meningkatkan pelaporan kinerja, dan membantu mengurangi biaya pembaruan dan pemasangan versi baru .
Mendemonstrasikan kekuatan elemen pengganti
Seperti disebutkan sebelumnya, penggunaan Operator Konfigurasi Mesin untuk mengelola host container dan mesin container di OpenShift 4 memberikan tingkat otomatisasi baru yang sebelumnya tidak mungkin dilakukan pada platform Kubernetes. Untuk mendemonstrasikan fitur-fitur baru, kami akan menunjukkan bagaimana Anda dapat membuat perubahan pada file crio.conf. Untuk menghindari kebingungan dengan terminologi, cobalah fokus pada hasilnya.
Pertama, mari buat apa yang disebut konfigurasi runtime container - Konfigurasi Runtime Container. Anggap saja sebagai sumber daya Kubernetes yang mewakili konfigurasi untuk CRI-O. Pada kenyataannya, ini adalah versi khusus dari sesuatu yang disebut MachineConfig, yaitu konfigurasi apa pun yang diterapkan ke mesin RHEL CoreOS sebagai bagian dari cluster OpenShift.
Sumber daya khusus ini, yang disebut ContainerRuntimeConfig, dibuat untuk memudahkan administrator klaster dalam mengonfigurasi CRI-O. Alat ini cukup kuat sehingga hanya dapat diterapkan pada node tertentu tergantung pada pengaturan MachineConfigPool. Anggap saja sebagai sekelompok mesin yang memiliki tujuan yang sama.
Perhatikan dua baris terakhir yang akan kita ubah pada file /etc/crio/crio.conf. Kedua baris ini sangat mirip dengan baris pada file crio.conf, yaitu:
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 mari kita dorong file ini ke cluster Kubernetes dan periksa apakah file tersebut benar-benar dibuat. Harap diperhatikan bahwa pengoperasiannya sama persis dengan sumber daya Kubernetes lainnya:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Kesimpulan:
NAME AGE
set-log-and-pid 22h
Setelah kita membuat ContainerRuntimeConfig, kita perlu memodifikasi salah satu MachineConfigPools untuk memberi sinyal kepada Kubernetes bahwa kita ingin menerapkan konfigurasi ini ke sekelompok mesin tertentu di cluster. Dalam hal ini kita akan mengubah MachineConfigPool untuk node master:
oc edit MachineConfigPool/master
Kesimpulan (untuk lebih jelasnya, intisari utamanya dibiarkan):
...
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 telah selesai dapat dilihat menggunakan Kubernetes API. Ingat, ContainerRuntimeConfig hanyalah versi khusus dari MachineConfig, jadi kita dapat melihat hasilnya dengan melihat baris yang relevan 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 dicatat bahwa file konfigurasi yang dihasilkan untuk node master adalah versi yang lebih baru daripada konfigurasi aslinya. Untuk melihatnya, jalankan perintah berikut. Secara sepintas, kami mencatat bahwa ini mungkin salah satu kalimat 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 mari kita 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 mari kita lihat file yang diinstal. Anda akan melihat bahwa file tersebut telah diperbarui dengan nilai baru untuk arahan pid dan debug yang kami tentukan di 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 pada cluster ini dilakukan bahkan tanpa menjalankan SSH. Semua pekerjaan dilakukan dengan mengakses node master Kuberentes. Artinya, parameter baru ini dikonfigurasi hanya pada node master. Node pekerja tidak berubah, yang menunjukkan manfaat metodologi Kubernetes dalam menggunakan status tertentu dan aktual dalam kaitannya dengan host container dan mesin container dengan elemen yang dapat dipertukarkan.
Contoh di atas menunjukkan kemampuan untuk membuat perubahan pada klaster OpenShift Container Platform 4 kecil dengan tiga node produksi atau klaster produksi besar dengan 3000 node. Bagaimanapun, jumlah pekerjaannya akan sama - dan sangat kecil - cukup konfigurasikan file ContainerRuntimeConfig, dan ubah satu label di MachineConfigPool. Dan Anda dapat melakukan ini dengan versi OpenShift Container Platform 4.X apa pun yang menjalankan Kubernetes sepanjang siklus hidupnya.
Seringkali perusahaan teknologi berkembang begitu cepat sehingga kami tidak dapat menjelaskan mengapa kami memilih teknologi tertentu untuk komponen dasarnya. Mesin kontainer secara historis menjadi komponen yang berinteraksi langsung dengan pengguna. Karena popularitas container secara alami dimulai dengan munculnya mesin container, pengguna sering kali menunjukkan minat terhadapnya. Ini adalah alasan lain mengapa Red Hat memilih CRI-O. Kontainer kini berkembang dengan fokus pada orkestrasi, dan kami menemukan bahwa CRI-O memberikan pengalaman terbaik saat bekerja dengan OpenShift 4.
Sumber: www.habr.com