Pelantar membolehkan anda menyelaraskan penciptaan , termasuk dalam infrastruktur penyedia perkhidmatan awan, pada platform virtualisasi atau dalam sistem bare-metal. Untuk mencipta platform berasaskan awan yang benar-benar, kami perlu mengawal ketat semua elemen yang digunakan dan dengan itu meningkatkan kebolehpercayaan proses automasi yang kompleks.
Penyelesaian yang jelas ialah menggunakan Red Hat Enterprise Linux CoreOS (varian Red Hat Enterprise Linux) dan CRI-O sebagai standard, dan inilah sebabnya...
Memandangkan topik pelayaran adalah topik yang sangat baik untuk mencari analogi apabila menerangkan kerja Kubernetes dan kontena, mari cuba bercakap tentang masalah perniagaan yang diselesaikan oleh CoreOS dan CRI-O, menggunakan contoh . Pada tahun 1803, Marc Brunel telah diberi tugas untuk menghasilkan 100 blok rigging untuk keperluan tentera laut British yang semakin meningkat. Blok rigging ialah sejenis rigging yang digunakan untuk memasang tali pada layar. Sehingga awal abad ke-19, blok ini dibuat dengan tangan, tetapi Brunel berjaya mengautomasikan pengeluaran dan mula menghasilkan blok piawai menggunakan peralatan mesin. Automasi proses ini bermakna bahawa blok yang terhasil pada dasarnya adalah sama, boleh diganti dengan mudah jika pecah, dan boleh dihasilkan dalam kuantiti yang banyak.
Sekarang bayangkan jika Brunel terpaksa melakukan kerja ini untuk 20 model kapal yang berbeza (versi Kubernetes) dan untuk lima planet berbeza dengan arus laut dan angin yang berbeza sama sekali (penyedia awan). Di samping itu, semua kapal (kluster OpenShift), tanpa mengira planet di mana navigasi dijalankan, dari sudut pandangan kapten (pengendali yang menguruskan operasi kluster) berkelakuan sama. Untuk meneruskan analogi maritim, kapten kapal tidak peduli sama sekali jenis blok rigging (CRI-O) yang digunakan pada kapal mereka - perkara utama bagi mereka ialah blok ini kuat dan boleh dipercayai.
OpenShift 4, sebagai platform awan, menghadapi cabaran perniagaan yang hampir sama. Nod baharu mesti dibuat pada masa pembuatan kluster, sekiranya berlaku kegagalan dalam salah satu nod, atau semasa menskala kluster. Apabila nod baharu dicipta dan dimulakan, komponen hos kritikal, termasuk CRI-O, mesti dikonfigurasikan dengan sewajarnya. Seperti dalam mana-mana pengeluaran lain, "bahan mentah" mesti dibekalkan pada permulaan. Dalam kes kapal, bahan mentah adalah logam dan kayu. Walau bagaimanapun, dalam hal mencipta hos untuk menggunakan bekas dalam kelompok OpenShift 4, anda perlu mempunyai fail konfigurasi dan pelayan yang disediakan API sebagai input. OpenShift kemudiannya akan menyediakan tahap automasi yang diperlukan sepanjang keseluruhan kitaran hayat, menawarkan sokongan produk yang diperlukan kepada pengguna akhir dan dengan itu mendapatkan balik pelaburan dalam platform.
OpenShift 4 dicipta sedemikian rupa untuk menyediakan keupayaan untuk mengemas kini sistem dengan mudah sepanjang keseluruhan kitaran hayat platform (untuk versi 4.X) untuk semua penyedia pengkomputeran awan utama, platform virtualisasi dan juga sistem logam kosong. Untuk melakukan ini, nod mesti dibuat berdasarkan elemen yang boleh ditukar ganti. Apabila kluster memerlukan versi baharu Kubernetes, ia juga menerima versi CRI-O yang sepadan pada CoreOS. Memandangkan versi CRI-O terikat terus dengan Kubernetes, ini sangat memudahkan sebarang pilih atur untuk ujian, penyelesaian masalah atau tujuan sokongan. Di samping itu, pendekatan ini mengurangkan kos untuk pengguna akhir dan Red Hat.
Ini adalah cara pemikiran yang asasnya baharu tentang kluster Kubernetes dan meletakkan asas untuk merancang beberapa ciri baharu yang sangat berguna dan menarik. CRI-O (Container Runtime Interface - Open Container Initiative, disingkat CRI-OCI) ternyata menjadi pilihan yang paling berjaya untuk penciptaan besar-besaran nod yang diperlukan untuk berfungsi dengan OpenShift. CRI-O akan menggantikan enjin Docker yang digunakan sebelum ini, menawarkan pengguna OpenShift β ya, anda dengar betul β enjin kontena membosankan yang dicipta khusus untuk bekerja dengan Kubernetes.
Dunia bekas terbuka
Dunia telah lama bergerak ke arah bekas terbuka. Sama ada dalam Kubernetes, atau pada tahap yang lebih rendah, menghasilkan ekosistem inovasi pada setiap peringkat.
Semuanya bermula dengan penciptaan Inisiatif Kontena Terbuka . Pada peringkat awal kerja ini, spesifikasi kontena telah dibentuk ΠΈ . Ini memastikan bahawa alat boleh menggunakan satu standard dan format bersatu untuk bekerja dengan mereka. Spesifikasi kemudiannya ditambah , membolehkan pengguna berkongsi dengan mudah .
Komuniti Kubernetes kemudiannya membangunkan satu standard untuk antara muka boleh pasang, dipanggil . Terima kasih kepada ini, pengguna Kubernetes dapat menyambungkan pelbagai enjin untuk berfungsi dengan bekas sebagai tambahan kepada Docker.
Jurutera di Red Hat dan Google melihat keperluan pasaran untuk enjin kontena yang boleh menerima permintaan Kubelet melalui protokol CRI dan memperkenalkan bekas yang serasi dengan spesifikasi OCI yang dinyatakan di atas. Jadi . Tetapi maaf, bukankah kami telah mengatakan bahawa bahan ini akan didedikasikan untuk CRI-O? Sebenarnya ia, hanya dengan pelepasan projek itu dinamakan semula sebagai CRI-O.
Rajah 1.
Inovasi dengan CRI-O dan CoreOS
Dengan pelancaran platform OpenShift 4, ia telah diubah , digunakan secara lalai dalam platform, dan Docker telah digantikan oleh CRI-O, menawarkan persekitaran kos efektif, stabil, mudah dan membosankan untuk menjalankan kontena yang berkembang selari dengan Kubernetes. Ini sangat memudahkan sokongan dan konfigurasi kelompok. Konfigurasi enjin kontena dan hos, serta pengurusannya, menjadi automatik dalam OpenShift 4.
Tunggu, bagaimana ini?
Betul, dengan kemunculan OpenShift 4, tiada lagi keperluan untuk menyambung ke hos individu dan memasang enjin kontena, mengkonfigurasi storan, mengkonfigurasi pelayan carian atau mengkonfigurasi rangkaian. Platform OpenShift 4 telah direka bentuk semula sepenuhnya untuk menggunakan bukan sahaja dari segi aplikasi pengguna akhir, tetapi juga dari segi operasi peringkat platform asas seperti mengatur imej, mengkonfigurasi sistem atau memasang kemas kini.
Kubernetes sentiasa membenarkan pengguna mengurus aplikasi dengan menentukan keadaan dan penggunaan yang dikehendaki , untuk memastikan bahawa keadaan sebenar sepadan dengan keadaan sasaran sedekat mungkin. ini membuka peluang besar dari sudut pembangunan dan operasi. Pembangun boleh menentukan keadaan yang diperlukan dengan kepada pengendali dalam bentuk fail YAML atau JSON, dan kemudian pengendali boleh mencipta contoh aplikasi yang diperlukan dalam persekitaran pengeluaran, dan keadaan operasi contoh ini akan sepadan sepenuhnya dengan yang ditentukan.
Dengan menggunakan Operator dalam platform, OpenShift 4 membawa paradigma baharu ini (menggunakan konsep set dan keadaan sebenar) kepada pengurusan RHEL CoreOS dan CRI-O. Tugas mengkonfigurasi dan mengurus versi sistem pengendalian dan enjin kontena diautomasikan menggunakan apa yang dipanggil . MCO sangat memudahkan kerja pentadbir kluster, pada asasnya mengautomasikan peringkat terakhir pemasangan, serta operasi pasca pemasangan berikutnya (operasi hari kedua). Semua ini menjadikan OpenShift 4 platform awan yang sebenar. Kami akan membincangkan perkara ini sedikit kemudian.
Bekas berjalan
Pengguna telah berpeluang menggunakan enjin CRI-O dalam platform OpenShift sejak versi 3.7 dalam status Pratonton Teknologi dan daripada versi 3.9 dalam status Tersedia Secara Umum (disokong pada masa ini). Di samping itu, Red Hat menggunakan secara besar-besaran dalam OpenShift Online sejak versi 3.10. Semua ini membolehkan pasukan yang bekerja pada CRI-O memperoleh pengalaman yang luas dalam kontena pelancaran besar-besaran pada gugusan Kubernetes yang besar. Untuk mendapatkan pemahaman asas tentang cara Kubernetes menggunakan CRI-O, mari lihat ilustrasi berikut, yang menunjukkan cara seni bina berfungsi.
nasi. 2. Cara bekas berfungsi dalam kelompok Kubernetes
CRI-O memudahkan penciptaan hos kontena baharu dengan menyegerakkan keseluruhan tahap teratas apabila memulakan nod baharu dan apabila mengeluarkan versi baharu platform OpenShift. Semakan keseluruhan platform membolehkan kemas kini transaksi/pemulangan semula, dan juga menghalang kebuntuan dalam kebergantungan antara teras ekor kontena, enjin kontena, nod (Kubelets) dan nod Master Kubernetes. Dengan mengurus semua komponen platform secara berpusat, dengan kawalan dan versi, sentiasa ada laluan yang jelas dari keadaan A ke keadaan B. Ini memudahkan proses kemas kini, meningkatkan keselamatan, meningkatkan pelaporan prestasi dan membantu mengurangkan kos kemas kini dan pemasangan versi baharu .
Menunjukkan kuasa elemen penggantian
Seperti yang dinyatakan sebelum ini, menggunakan Operator Konfigurasi Mesin untuk mengurus hos kontena dan enjin kontena dalam OpenShift 4 menyediakan tahap automasi baharu yang tidak mungkin dilakukan pada platform Kubernetes sebelum ini. Untuk menunjukkan ciri baharu, kami akan menunjukkan cara anda boleh membuat perubahan pada fail crio.conf. Untuk mengelakkan kekeliruan dengan istilah, cuba fokus pada hasilnya.
Mula-mula, mari kita buat apa yang dipanggil konfigurasi masa jalan kontena - Container Runtime Config. Anggap ia sebagai sumber Kubernetes yang mewakili konfigurasi untuk CRI-O. Pada hakikatnya, ia adalah versi khusus sesuatu yang dipanggil MachineConfig, iaitu sebarang konfigurasi yang digunakan pada mesin RHEL CoreOS sebagai sebahagian daripada kluster OpenShift.
Sumber tersuai ini, dipanggil ContainerRuntimeConfig, dicipta untuk memudahkan pentadbir kluster mengkonfigurasi CRI-O. Alat ini cukup berkuasa sehingga ia hanya boleh digunakan pada nod tertentu bergantung pada tetapan MachineConfigPool. Fikirkan ia sebagai sekumpulan mesin yang mempunyai tujuan yang sama.
Perhatikan dua baris terakhir yang akan kita ubah dalam fail /etc/crio/crio.conf. Kedua-dua baris ini sangat serupa dengan baris dalam fail crio.conf, ia 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 mari kita tolak fail ini ke gugusan Kubernetes dan semak sama ada ia sebenarnya telah dibuat. Sila ambil perhatian bahawa operasi adalah sama seperti mana-mana sumber Kubernetes lain:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Kesimpulan:
NAME AGE
set-log-and-pid 22h
Setelah kami mencipta ContainerRuntimeConfig, kami perlu mengubah suai salah satu daripada MachineConfigPools untuk memberi isyarat kepada Kubernetes bahawa kami ingin menggunakan konfigurasi ini pada kumpulan mesin tertentu dalam kelompok. Dalam kes ini, kami akan menukar MachineConfigPool untuk nod induk:
oc edit MachineConfigPool/master
Kesimpulan (untuk kejelasan, intipati utama ditinggalkan):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Pada ketika ini, MCO mula mencipta fail crio.conf baharu untuk kluster. Dalam kes ini, fail konfigurasi yang telah siap sepenuhnya boleh dilihat menggunakan API Kubernetes. Ingat, ContainerRuntimeConfig hanyalah versi khusus MachineConfig, jadi kita boleh melihat hasilnya dengan melihat baris yang berkaitan dalam 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
Sila ambil perhatian bahawa fail konfigurasi yang terhasil untuk nod induk adalah versi yang lebih baharu daripada konfigurasi asal. Untuk melihatnya, jalankan arahan berikut. Secara sepintas lalu, kami ambil perhatian bahawa ini mungkin salah satu barisan 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 bahawa konfigurasi telah digunakan pada semua nod induk. Mula-mula kita mendapat senarai nod dalam kelompok:
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 fail yang dipasang. Anda akan melihat bahawa fail telah dikemas kini dengan nilai baharu untuk arahan pid dan nyahpepijat yang kami tentukan dalam sumber 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 kluster ini dibuat tanpa menjalankan SSH. Semua kerja dilakukan dengan mengakses nod induk Kuberentes. Iaitu, parameter baharu ini dikonfigurasikan hanya pada nod induk. Nod pekerja tidak berubah, yang menunjukkan faedah metodologi Kubernetes menggunakan keadaan tertentu dan sebenar berhubung dengan hos kontena dan enjin kontena dengan elemen boleh tukar ganti.
Contoh di atas menunjukkan keupayaan untuk membuat perubahan pada kluster OpenShift Container Platform 4 yang kecil dengan tiga nod pengeluaran atau kluster pengeluaran besar dengan 3000 nod. Walau apa pun, jumlah kerja akan sama - dan sangat kecil - cuma konfigurasikan fail ContainerRuntimeConfig dan tukar satu label dalam MachineConfigPool. Dan anda boleh melakukan ini dengan mana-mana versi OpenShift Container Platform 4.X yang menjalankan Kubernetes sepanjang kitaran hayatnya.
Selalunya syarikat teknologi berkembang dengan pantas sehingga kami tidak dapat menjelaskan sebab kami memilih teknologi tertentu untuk komponen asas. Enjin kontena secara historis merupakan komponen yang berinteraksi dengan pengguna secara langsung. Memandangkan populariti kontena secara semula jadi bermula dengan kemunculan enjin kontena, pengguna sering menunjukkan minat terhadapnya. Ini adalah satu lagi sebab mengapa Red Hat memilih CRI-O. Bekas sedang berkembang dengan tumpuan kini pada orkestrasi, dan kami telah mendapati bahawa CRI-O memberikan pengalaman terbaik apabila bekerja dengan OpenShift 4.
Sumber: www.habr.com