hull
hull-demo-1.31.2
Repositori ini berisi bagan perpustakaan Hull Helm. Ini dirancang untuk memudahkan membangun, memelihara, dan mengkonfigurasi objek Kubernetes dalam grafik helm dan dapat ditambahkan ke grafik helm sebagai addon untuk meningkatkan fungsionalitas tanpa risiko melanggar konfigurasi grafik helm yang ada.
Bagan itu sendiri dan semua dokumentasi yang terkait dengannya dapat ditemukan di folder hull yang merupakan folder root dari bagan helm perpustakaan lambung.
Skema Kubernetes API JSON disimpan di folder kubernetes-json-schema .
Di bawah ini adalah grafik lambung README.md :
Abstraksi perlu dipertahankan - Kelsey Hightower
Salah satu aspek desain utama dari Helm adalah memaksa pengguna untuk membuat abstraksi individu dari konfigurasi aplikasi Kubernetes. Untuk setiap grafik helm individu yang direalisasikan dalam bentuk templat YAML dalam folder grafik /templates helm. File templat ini, yang berisi blok kode boilerplate kubernetes yaml di satu sisi dan pemetaan konfigurasi khusus yang menggunakan ekspresi templating go di sisi lain, memberikan lem antara konfigurasi aplikasi melalui values.yaml pusat. . Bisa dibilang pendekatan abstraksi per-aplikasi ini cocok untuk membuat paket konfigurasi tailormade bahkan untuk aplikasi yang paling khusus tetapi datang dengan biaya memiliki overhead besar untuk kasus penggunaan kemasan aplikasi aplikasi yang lebih sederhana, berulang dan di luar rak. Membuat, memelihara dan (sering) memahami abstraksi yang diperkenalkan oleh grafik helm - terutama ketika menghadapi sejumlah besar grafik helm individu dari berbagai sumber - dapat menjadi membosankan dan menantang.
Fitur utama dari pustaka Hull adalah kemampuan untuk menghapus file template YAML yang disesuaikan sepenuhnya dari alur kerja grafik Helm dan dengan demikian memungkinkan untuk menghapus tingkat abstraksi. Menggunakan bagan pustaka Hull, objek Kubernetes termasuk semua propertinya dapat sepenuhnya dan transparan ditentukan dalam values.yaml . Bagan pustaka Hull itu sendiri menyediakan lapisan seragam untuk merampingkan spesifikasi, konfigurasi, dan rendering grafik helm untuk mencapai hal ini. Anda juga dapat menganggapnya sebagai lapisan tipis di atas API Kubernetes untuk menghindari perantara antara grafik Helm dan konfigurasi objek API Kubernetes, namun memberikan fleksibilitas ketika diperlukan untuk menyesuaikan opsi konfigurasi individu alih -alih mengharuskan Anda untuk menambahkan setiap sakelar konfigurasi konfigurasi secara manual ke template. Validasi skema JSON berdasarkan fitur validasi Helm JSON (via values.schema.json ) membantu secara tertulis API Kubernetes API yang menyesuaikan objek sejak awal saat menggunakan IDE yang mendukung validasi skema JSON langsung. Manfaat tambahan (metadata objek yang diwariskan yang seragam, dimasukkannya disederhanakan dari configmaps/rahasia, nilai referensi silang dalam values.yaml , ...) tersedia dengan lambung yang dapat Anda baca di bawah ini dalam ikhtisar fitur utama . Tapi mungkin yang paling penting, perpustakaan lambung dapat ditambahkan sebagai ketergantungan pada grafik helm yang ada dan digunakan berdampingan tanpa melanggar fungsi grafik helm yang ada, lihat Menambahkan Bagan Perpustakaan Hull ke bagan Helm untuk informasi lebih lanjut. Dan terakhir, dengan menjadi bagan perpustakaan itu sendiri, semuanya bekerja 100% dalam fungsi yang ditawarkan Helm polos - tidak ada perkakas tambahan yang diperkenalkan atau terlibat.
Umpan balik Anda tentang proyek ini dinilai, maka silakan berkomentar atau mulai diskusi di bagian Issues atau buat keinginan fitur dan laporan bug. Terima kasih!
Ide Bagan Perpustakaan Hull sebagian terinspirasi oleh konsep grafik Helm Umum dan untuk pengujian
.
hull-demo Sebelum menyelam ke detail Hull, berikut adalah pandangan pertama tentang cara kerjanya. Anda cukup mengunduh versi terbaru dari bagan helm hull-demo dari bagian rilis halaman ini, ia memiliki semua bootstrap untuk menguji Hull atau menyiapkan grafik helm baru berdasarkan Hull dengan upaya minimal.
Bagan hull-demo membungkus aplikasi fiksi myapp dengan frontend dan pemasangan dan pasangan layanan backend . Ada file konfigurasi untuk konfigurasi server yang dipasang ke pod backend . Pod frontend perlu tahu tentang alamat layanan backend melalui variabel lingkungan. Selain itu, pengaturan harus secara default mudah dialihkan dari pengaturan debug (menggunakan nodeport untuk mengakses frontend) ke pengaturan seperti produksi (menggunakan layanan clusterip dan masuknya).
Struktur default telanjang untuk menangkap aspek -aspek ini mungkin terlihat seperti ini (dengan komentar garis tambahan untuk penjelasan):
hull : # HULL is configured via subchart key 'hull'
config : # chart setup takes place here for everything besides object definitions
specific : # central place for shared values specific to this chart
debug : true # a switch influencing creation of objects in this chart
application_version : v23.1 # a shared image tag for multiple container
myapp : # some exemplary configuration settings for the app, exposed here for transparency
rate_limit : 100
max_connections : 5
objects : # all objects to create are defined here
deployment : # create deployments
myapp-frontend : # the base part of the object name for frontend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # provide image reference
repository : mycompany/myapp-frontend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 80 # the port number
env : # environment variables
SERVER_HOSTNAME : # name of variable
value : _HT^myapp-backend # value is dynamically rendered reference to myapp-backend service name
SERVER_PORT : # name of variable
value : " 8080 " # backend service port
myapp-backend : # the base part of the object name for backend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # image reference
repository : mycompany/myapp-backend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 8080 # the port number
volumeMounts : # mounts of the container
appconfig : # context key is appconfig
name : myappconfig # the name needs to match a volume
mountPath : /etc/config/appconfig.json # mountPath
subPath : backend-appconfig.json # subPath
volumes : # volumes that may be mounted
myappconfig : # key matching a volumeMounts name
configMap : # configmap reference
name : myappconfig # the configmap to load, simply referenced by key name
configmap : # create configmaps
myappconfig : # the backend configuration
data : # data section
backend-appconfig.json : # key name is file name
serialization : toPrettyJson # serialize the dictionary content of inline to pretty Json
inline : # define the contents of the file as a dictionary for convenience
rate-limit : _HT*hull.config.specific.myapp.rate_limit
max-connections : _HT*hull.config.specific.myapp.max_connections
debug-log : _HT!{{ if _HT*hull.config.specific.debug }}true{{ else }}false{{ end }}
service : # create services
myapp-frontend : # frontend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port for type=ClusterIP
enabled : _HT?not _HT*hull.config.specific.debug # bind rendering to debug: false condition, use embedded transformation to reference field
port : 80 # regular port
targetPort : http # targetPort setting
http_nodeport : # http port for type=NodePort
enabled : _HT?_HT*hull.config.specific.debug # bind rendering to debug: true condition
port : 80 # regular port
nodePort : 31111 # the node port
targetPort : http # targetPort setting
type : |- # dynamically switch type based on hull.config.specific.debug setting
_HT!
{{- if _HT*hull.config.specific.debug -}}
NodePort
{{- else -}}
ClusterIP
{{- end -}}
myapp-backend : # backend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port
port : 8080 # regular port
targetPort : http # targetPort setting
type : ClusterIP # in cluster service
ingress : # create ingresses
myapp : # the central frontend ingress
enabled : _HT?not _HT*hull.config.specific.debug # rendering bound to debug: false
rules : # the ingress rules
myapp : # key-value dictionary of rules
host : SET_HOSTNAME_HERE # change the host at deployment time to actual one
http : # http settings
paths : # paths definition
standard : # a standard path definition
path : / # could be changed at deployment time
pathType : ImplementationSpecific # path type
backend : # backend config
service : # service targeted
name : myapp-frontend # key name suffices to reference service created in this chart
port : # target port
name : http # target port name Ini adalah contoh yang merupakan values.yaml hull-demo hull-demo
helm template hull-demo-<version>.tgz
itu membuat satu set objek berdasarkan values.yaml di atas.yaml berisi:
myapp-frontend yang memiliki set tag gambar yang dikonfigurasi secara terpusat (secara default v23.1 ), dan variabel lingkungan yang menunjuk ke alamat dalam layanan myapp-backendmyapp-backend yang memiliki set tag gambar yang dikonfigurasi secara terpusat (secara default v23.1 ) dan konfigurasi yang dipasang dari myappconfig configMapmyappconfig ConfigMap dengan file JSON yang secara dinamis dibangun dengan menggabungkan ekspresi templating dan merujuk nilai yang ditentukan di tempat lain dalam values.yamlmyapp-backendmyapp-frontend yang jenis dan konfigurasi portnya bergantung pada sakelar debug pusat-baik tipe NodePort dalam mode pengaturan debug atau tipe ClusterIP dalam kombinasi dengan masuk myapp dalam pengaturan non-debugsmyapp yang hanya diterjemahkan/dibuat jika debug: false ditetapkan Setiap aspek dari konfigurasi ini dapat diubah atau ditimpa pada waktu penyebaran menggunakan values.yaml overlay tambahan.YAML, misalnya:
debug dengan pengaturan debug: true atau debug: falsemyapp ConfigMaps ( rate_limit dan max_connections ) atau ditimpa sepenuhnya Semua objek dan logika dibuat dengan di bawah seratus baris kode konfigurasi keseluruhan dalam values.yaml hull-demo . Anda dapat menguji semua aspek yang disebutkan di atas atau hanya bereksperimen dengan menambahkan values.yaml tambahan helm template Untuk bootstrap grafik helm Anda name , cukup kosongkan values.yaml Chart.yaml
Ini adalah demo pertama tentang bagaimana Hull dapat digunakan tetapi ada lebih banyak fungsionalitas dan kasus penggunaan yang didukung. Periksa fitur utama dan dokumentasi terperinci untuk informasi lebih lanjut.
Seperti yang disorot di atas, ketika dimasukkan dalam bagan pimpinan, grafik perpustakaan Hull dapat mengambil alih pekerjaan objek Kubernetes yang dinamis dari spesifikasi yang diberikan dari file values.yaml saja. Dengan Konstruksi Objek YAML Ditangguhkan ke Fungsi GO Templating Perpustakaan Hull alih -alih Templat YAML Kustom di folder /templates Anda dapat secara terpusat menegakkan praktik terbaik:
Berkonsentrasi pada apa yang diperlukan untuk menentukan objek Kubernetes tanpa harus menambahkan templat YAML boilerplate individu ke dalam bagan Anda. Ini menghilangkan sumber kesalahan dan pemeliharaan yang umum dari alur kerja Helm biasa. Agar lambung yang diberikan output sesuai dengan spesifikasi API Kubernetes, sejumlah besar tes unit memvalidasi output lambung yang diberikan terhadap skema Kubernetes API JSON.
Untuk detail lebih lanjut, lihat dokumentasi tentang validasi skema JSON.
Untuk semua jenis objek Kubernetes yang didukung oleh Hull, akses konfigurasi penuh ke properti tipe objek Kubernetes tersedia secara langsung . Ini meringankan pengelola bagan dari keharusan menambahkan opsi konfigurasi yang hilang satu per satu dan pengguna grafik helm dari forking grafik helm untuk menambahkan hanya properti yang mereka butuhkan untuk konfigurasi mereka. Hanya memperbarui bagan lambung ke versi yang lebih baru dengan versi API Kubernetes yang cocok diperlukan untuk memungkinkan konfigurasi properti yang ditambahkan ke objek Kubernetes sementara dalam versi API yang lebih baru. Bagan lambung diversi untuk mencerminkan versi API Kubernetes minimal yang didukung oleh mereka.
Untuk detail lebih lanjut, lihat dokumentasi tentang ikhtisar arsitektur.
Antarmuka tunggal pustaka Hull digunakan untuk membuat dan mengkonfigurasi objek dalam bagan untuk penyebaran. Ini menumbuhkan pemahaman timbal balik tentang pembuat grafik/pemelihara dan konsumen tentang bagaimana bagan itu benar -benar bekerja dan apa yang dikandungnya. Menggali ke dalam folder /templates untuk memahami implikasi grafik helm tidak diperlukan lagi. Untuk menghindari kesalahan konfigurasi, antarmuka ke perpustakaan - values.yaml dari pustaka lambung - sepenuhnya divalidasi JSON. Saat menggunakan IDE yang mendukung validasi skema JSON langsung (misalnya vscode) Anda bisa mendapatkan panduan IDE saat membuat objek lambung. Sebelum rendering, kesesuaian skema JSON divalidasi oleh Perpustakaan Hull.
Untuk detail lebih lanjut, lihat dokumentasi tentang validasi skema JSON.
Metadata yang seragam dan kaya secara otomatis dilampirkan ke semua objek yang dibuat oleh perpustakaan Hull.
Untuk detail lebih lanjut tentang timpa metadata, lihat contoh lanjutan di bawah ini.
Penanganan ConfigMap dan input rahasia yang fleksibel dengan memilih antara spesifikasi inline konten dalam values.yaml atau impor dari file eksternal untuk konten ukuran yang lebih besar. Saat mengimpor data dari file, data dapat dijalankan melalui mesin templating atau diimpor tidak ditempel 'sebagaimana adanya' jika sudah berisi ekspresi templating yang harus diteruskan ke aplikasi yang memakan. Dengan fokus pada penanganan skenario standar yang nyaman, Anda juga dapat mendefinisikan konten file sebagai struktur YAML biasa dalam values.yaml . Hull menangani pengkodean base64 dari rahasia sehingga menulis ConfigMaps dan Secrets bekerja dengan cara yang sama persis dan menambahkan ConfigMap atau rahasia ke penyebaran Anda hanya memerlukan beberapa baris kode.
Untuk detail lebih lanjut, lihat dokumentasi di ConfigMaps and Secrets.
Kemampuan default yang luas untuk instantiasi instance objek. Apakah Anda ingin memiliki semua instance objek atau kelompok instance Anda berbagi aspek -aspek tertentu seperti label atau anotasi, variabel lingkungan kontainer atau volume yang dipasang, Hull memberikan dukungan untuk secara efisien menentukan nilai default untuk bidang instance objek yang menghindari pengulangan konfigurasi yang tidak perlu.
Untuk detail lebih lanjut, lihat saran desain bagan.
Untuk skenario yang lebih kompleks di mana nilai aktual dalam target YAML tunduk pada konfigurasi dalam values.yaml values.yaml Misalnya, jika argumen kontainer konkret Anda bergantung pada berbagai pengaturan lain dalam values.yaml values.yaml
Untuk detail lebih lanjut, lihat dokumentasi tentang transformasi.
Aktifkan Hashing Otomatis dari Configmaps dan Rahasia yang Direferensikan untuk memfasilitasi restart POD pada perubahan konfigurasi saat diperlukan.
Untuk detail lebih lanjut, lihat dokumentasi di pod.
Untuk mempelajari lebih lanjut tentang arsitektur umum dan fitur perpustakaan Hull, lihat Tinjauan Arsitektur
Beberapa hal penting untuk disebutkan terlebih dahulu sebelum melihat perpustakaan secara lebih rinci:
/templates sama sekali tidak terpengaruh oleh integrasi bagan perpustakaan Hull. Kadang -kadang Anda mungkin memiliki persyaratan yang sangat spesifik tentang konfigurasi atau spesifikasi objek yang tidak dipenuhi oleh pustaka Hull sehingga Anda dapat menggunakan alur kerja Helm biasa untuk mereka dan perpustakaan lambung untuk kebutuhan standar Anda - dengan mudah secara paralel dalam bagan Helm yang sama.
hull.yaml , harus disalin 'apa adanya' tanpa modifikasi dari folder root grafik lambung tertanam ke folder grafik /templates induk untuk dapat membuat yaml apa pun melalui hull. Ini berisi kode yang memulai pipa rendering lambung, lihat Menambahkan Bagan Perpustakaan Hull ke bagan Helm untuk detail lebih lanjut!
3.0.x tidak kompatibel dengan lambung, semua versi non-beta dan non-alpha yang ada saat ini kompatibel.
1.29 dan 1.30 dan 1.31 memiliki rilis lambung yang cocok dan dipelihara.
Jika Anda menyukai pendekatan langsung, Anda diundang untuk melihat seri tutorial Hull yang baru di dev.to! Tutorial Bagian Eigth akan dimulai dari awal pengaturan Helm dan membuat bagan berbasis lambung untuk menyelesaikan bagan Helm berbasis lambung kehidupan nyata langkah demi langkah. Untuk menyoroti perbedaan ke alur kerja grafik helm reguler, tutorial mengambil grafik helm kubernetes-dashboard yang populer sebagai sumber dan mengangkutnya ke grafik helm berbasis lambung yang setara secara fungsional. Pada akhirnya itu menunjukkan bahwa mengurangi garis konfigurasi untuk membuat dan mempertahankan dapat dikurangi lebih dari 50% saat menggunakan pendekatan berbasis lambung alih -alih gaya grafik penulisan helm reguler!
Tugas membuat dan mengonfigurasi grafik helm berbasis lambung dapat dianggap sebagai dua sisi dari koin yang sama. Kedua belah pihak berinteraksi dengan antarmuka yang sama (pustaka lambung) untuk menentukan objek yang harus dibuat. Tugas dari perspektif pencipta/pengelola adalah yang terpenting untuk menyediakan struktur tanah untuk benda -benda yang membentuk aplikasi tertentu yang harus dibungkus dalam bagan pimpinan. Konsumen bagan ditugaskan untuk menambahkan konteks spesifik sistemnya dengan tepat ke struktur tanah di mana ia memiliki kebebasan untuk berubah dan bahkan menambah atau menghapus objek yang diperlukan untuk mencapai tujuannya. Pada waktu penyebaran, struktur dasar pembuatan digabungkan dengan file YAML khusus sistem konsumen untuk membangun konfigurasi lengkap. Berinteraksi melalui antarmuka perpustakaan yang sama mendorong pemahaman umum tentang cara bekerja dengan perpustakaan di kedua sisi dan dapat menghilangkan sebagian besar copy & pasta yang membosankan dan memeriksa proses konfigurasi yang berat.
Jadi semua yang diperlukan untuk membuat grafik helm berdasarkan Hull adalah struktur direktori grafik helm yang dipersilangan standar. Tambahkan grafik Library Hull sebagai sub-chart, salin hull.yaml dari grafik pustaka Hull ke folder grafik /templates induk Anda. Kemudian cukup konfigurasikan objek default untuk digunakan melalui values.yaml dan Anda selesai. Tidak ada batasan berapa banyak objek dari jenis yang Anda buat untuk paket penyebaran Anda.
Tetapi selain memungkinkan untuk mendefinisikan aplikasi yang lebih kompleks dengan Hull, Anda juga dapat menggunakannya untuk membungkus objek Kubernetes sederhana yang seharusnya Anda gunakan melalui Kubectl (berada di luar garis dari perspektif manajemen dengan pelepasan helm) atau harus menulis sejumlah besar yang signifikan Helm Templat Boilerplate untuk mencapai ini.
Struktur dasar values.yaml Yl dipahami oleh Hull diberikan di sini di bagian selanjutnya. Ini pada dasarnya membentuk antarmuka tunggal untuk memproduksi dan mengonsumsi grafik berbasis lambung. Objek apa pun hanya dibuat jika didefinisikan dan diaktifkan dalam values.yaml .
Di tingkat atas struktur YAML, Hull membedakan antara config dan objects . Sementara sub-konfigurasi config dimaksudkan untuk menangani pengaturan spesifik grafik seperti metadata dan pengaturan produk, objek Kubernetes beton yang akan diberikan ditentukan di bawah kunci objects . version nama kunci tingkat atas ketiga tambahan juga diizinkan, ketika ini sedang diatur ke versi grafik lambung misalnya selama pipa rilis grafik helm induk itu akan secara otomatis mengisi label vidispine.hull/version pada semua objek yang menunjukkan versi hull Itu digunakan untuk membuat objek.
config Di dalam bagian config Anda dapat mengonfigurasi pengaturan umum untuk grafik helm Anda. Ini dibagi menjadi dua subbagian, config.general dan config.specific .
config.general Berbeda dengan bagian config.specific , yang harus diisi dengan data sewenang -wenang yang khusus hanya untuk satu bagan helm, bagian config.general harus digunakan untuk menentukan segala sesuatu yang tidak khusus untuk aplikasi yang unik. Di satu sisi ia memiliki opsi konfigurasi yang relevan untuk semua grafik berbasis lambung tetapi juga menyisakan ruang di bawah config.general.data entri untuk menentukan bidang data Anda sendiri yang idealnya dimodelkan dengan cara yang sama di grafik kemudi lainnya. Misalnya, jika beberapa aplikasi dalam rangkaian produk tergantung pada titik akhir yang sama, Anda dapat memodelkan titik akhir ini secara seragam di bawah properti general.data di semua grafik yang relevan dan dengan demikian memiliki antarmuka grafik helm Anda dengan cara yang sama dengan EG pipa penyebaran yang berkelanjutan.
config.general hanya memiliki sub-bidang berikut:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| Parameter | Keterangan | Bawaan | Contoh |
|---|---|---|---|
nameOverride | Name Override diterapkan pada nilai label metadata app.kubernetes.io/name . Jika atur ini secara efektif menggantikan nama grafik di sini. | ||
fullnameOverride | Jika diatur ke nilai, override nama penuh diterapkan sebagai awalan untuk semua nama objek dan menggantikan pola prefix <release>-<chart> standar dalam nama objek. | myapp | |
namespaceOverride | Jika diatur ke nilai, namespace dari semua objek yang dibuat diatur ke nilai ini. Jika ini tidak ditentukan, namespace dari semua instance objek default ke rilis namespace yang disediakan untuk perintah helm masing -masing. | my-namespace | |
noObjectNamePrefixes | Jika diatur, tombol instance objek langsung berfungsi sebagai nama untuk objek Kubernetes yang dibuat dan tidak pernah diawali. Ini secara teknis setara dengan pengaturan staticName benar pada setiap objek. Perhatikan bahwa dengan mengatur ini ke true nilai config.general.fullnameOverride menjadi tidak relevan. | false | true |
createImagePullSecretsFromRegistries | Jika benar, rahasia tarik gambar dibuat dari semua pendaftar yang ditentukan dalam grafik helm ini dan ditambahkan ke semua pod. | true | false |
globalImageRegistryServer | Jika tidak mengosongkan bidang registry dari semua bidang image kontainer diatur ke nilai yang diberikan di sini. Pengaturan config.general.globalImageRegistryToFirstRegistrySecretServer diabaikan jika bidang ini tidak kosong. Semua pengaturan registry eksplisit yang ditentukan untuk suatu image ditimpa dengan nilai ini.Penggunaan yang dimaksudkan dari ini adalah untuk dengan mudah semua gambar ditarik dari registri Docker pusat jika ada skenario penempatan seperti celah udara. Berlawanan dengan pengaturan globalImageRegistryToFirstRegistrySecretServer ke true , dalam hal ini rahasia registri biasanya didefinisikan di luar bagan pimpinan ini dan server Registry Secret direferensikan dengan namanya secara langsung. Jika Anda menggunakan fitur ini dan mendefinisikan Docker Registry Secret di luar grafik Helm ini, Anda juga perlu menambahkan imagePullSecrets ke pod Anda jika Reference Docker Registry tidak aman. | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | Jika True dan globalImageRegistryServer kosong, bidang registry dari semua bidang image kontainer diatur ke bidang server dari objek registry pertama yang ditemukan. Perhatikan bahwa ini adalah registri dengan nama kunci alfanumerik terendah jika Anda memberikan banyak obeJct registry . Biasanya harus digunakan bersama dengan pengaturan createImagePullSecretsFromRegistries menjadi true untuk mendapatkan manfaat dari imagePullSecrets autopopulasi dan karenanya menetapkan registry . Pengaturan registry eksplisit untuk suatu image ditimpa dengan nilai ini.Penggunaan yang dimaksudkan dari pengaturan ini adalah dengan mudah membuat semua gambar ditarik dari registri Docker pusat jika ada celah udara seperti skenario penyebaran. | false | true |
errorChecks | Opsi yang menentukan dalam kasus mana Hull akan menghasilkan kesalahan pada helm install atau helm template . Untuk detail lebih lanjut, lihat juga dokumentasi terperinci tentang Mengkonfigurasi Pemeriksaan KesalahanHanya memiliki sub-bidang berikut: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | Validasi bahwa tidak ada YAML yang rusak yang diberikan | true | |
errorChecks.hullGetTransformationReferenceValid | Validasi bahwa semua _HT* referensi menunjuk ke kunci yang ada di values.yaml | true | |
errorChecks.containerImageValid | Validasi bahwa semua containers pod dan bagian image initContainers ada dan memiliki setidaknya satu set repository | true | |
errorChecks.virtualFolderDataPathExists | Validasi bahwa semua file yang dirujuk dalam bidang konfigurasi dan bidang path data rahasia secara fisik ada | true | |
errorChecks.virtualFolderDataInlineValid | Validasi bahwa tidak ada nilai null atau nilai yang hilang (yang dikonversi menjadi string kosong) ditetapkan untuk bidang konfigurasi dan data inline data rahasia | false | |
debug | Opsi yang dapat membantu dengan masalah bagan debugging. Sebagian besar usang dan digantikan dengan berbicara pesan kesalahan default yang dikonfigurasi di bawah errorChecks .Hanya memiliki sub-bidang berikut: renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | Global Switch yang jika diaktifkan akan mencetak string:HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not foundtermasuk _HT*/hull.util.transformation.get referensi ( xyz ) dan kunci yang hilang ( y ) Jika transformasi merujuk pada kunci kamus yang tidak ada. Ini berguna untuk debug chart rendering dan mengurangi pencarian referensi yang rusak karena biasanya instalasi dibatalkan dengan kesalahan pada referensi yang rusak (yang mungkin membuat sulit untuk menunjukkan referensi bermasalah).CATATAN: Sekarang referensi GET yang rusak akan ditandai oleh kesalahan helm berbicara secara default sehingga sakelar ini sebagian besar sudah usang untuk men -debug referensi yang rusak. Ini direkomendasikan untuk menonaktifkan opsi ini dan gagal pada referensi GET yang rusak dan menganalisis masalah langsung dari pesan kesalahan. | false | true |
debug.renderNilWhenInlineIsNil | Global Switch yang jika diaktifkan akan mencetak string:<nil>Sebagai nilai bidang data ketika spesifikasi inline merujuk pointer nil dalam configMap atau rahasia. Jika diatur ke FALSE, nilai nil akan dicetak sebagai string kosong di bidang ConfigMap atau Secret data .CATATAN: Sekarang bidang inline yang tidak valid akan ditandai oleh kesalahan helm yang berbicara secara default (artinya hull.config.general.errorChecks.virtualFolderDataInlineValid adalah true ). Mengaktifkan sakelar ini sebagian besar usang untuk debugging dan direkomendasikan untuk menonaktifkan opsi ini dan gagal keras pada bidang inline yang tidak valid. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | Global Switch yang jika diaktifkan akan mencetak string:<path missing: the_missing_path>Dalam nilai bidang konfigurasi atau data rahasia termasuk nilai the_missing_path yang tidak diselesaikan ke file. Jika false, nilai bidang data akan diselesaikan ke string kosong.CATATAN: Sekarang file yang tidak ada yang direferensikan dalam bidang jalur akan ditandai oleh kesalahan helm yang berbicara secara default (artinya hull.config.general.errorChecks.virtualFolderDataPathExists adalah true ). Mengaktifkan sakelar ini sebagian besar sudah usang untuk debugging dan direkomendasikan untuk menonaktifkan opsi ini dan gagal keras pada referensi jalur file yang tidak ada. | false | true |
render | Opsi untuk mempengaruhi bagaimana lambung membuat objek sebagai YAML. Hanya memiliki sub-bidang berikut: emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | Jika true , Hull membuat annotations: {} Jika tidak ada anotasi untuk suatu objek, jika false kunci annotations dihilangkan. | false | true |
render.emptyLabels | Jika true , Hull membuat labels: {} Jika tidak ada label untuk suatu objek, jika false kunci labels dihilangkan. | false | true |
render.emptyTemplateAnnotations | Jika true , Hull membuat annotations: {} dalam template pod jika tidak ada anotasi untuk suatu objek, jika false kunci annotations dihilangkan. | false | true |
render.emptyTemplateLabels | Jika true , Hull membuat labels: {} dalam template pod if no labels exist for an object, if false the kunci dihilangkan. | false | true |
render.emptyHullObjects | Jika true , Hull membuat array keluar sebagai array kosong jika tidak ada elemen untuk beberapa bidang yang diproses oleh Hull. Jika false, pasangan nilai kunci adalah Ommited.Ini mempengaruhi bidang yang dipetakan dari kamus dalam konfigurasi lambung ke array Kubernetes di YAML yang diberikan. Berikut ini adalah daftar bidang yang terpengaruh dalam konfigurasi objek Hull:
| false | true |
postRender | Setelah Hull sepenuhnya membuat objek, dimungkinkan untuk memanipulasi string YAML yang dihasilkan. Kemungkinan untuk melakukannya disediakan sebagai tindakan postRender di sini.Peringatan: Gunakan dengan hati -hati karena ini dapat merusak struktur YAML! | ||
postRender.globalStringReplacements | Kamus kemungkinan penggantian yang dapat diterapkan pada YAML objek yang diberikan. Kasing penggunaan utama untuk ini adalah dalam kombinasi dengan default ekstensif di _HULL_OBJECT_TYPE_DEFAULT_ dan sources objek instance di mana ia memungkinkan untuk menyuntikkan string spesifik instance ke YAML yang default. Pemetaan yang telah dikonfigurasikan sebelumnya dapat enabled: true sesuai permintaan. Setiap pemetaan terdiri dari bidang berikut:
| ||
postRender.globalStringReplacements.instanceKey | Jika enabled , nilai string akan diganti dengan instance_key objek aktual seperti di hull.objects.<object_type>.<instance_key> . Nilai replacement adalah OBJECT_INSTANCE_KEY untuk pemetaan ini. | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | Jika enabled , nilai string akan diganti dengan instance_key objek aktual seperti di hull.objects.<object_type>.<instance_key> atau oleh hull.objects.<object_type>.<instance_key>.metadataNameOverride jika ini ditentukan. Nilai replacement adalah OBJECT_INSTANCE_KEY_RESOLVED untuk pemetaan ini. | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | Jika enabled , nilai string akan diganti dengan metadata.name yang diberikan objek yang sebenarnya. Nilai replacement adalah OBJECT_INSTANCE_NAME untuk pemetaan ini. | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | Opsi Serialisasi Umum. | ||
serialization.configmap.enabled | Jika enabled , ekstensi file yang dipetakan di bawah fileExtensions diserialisasi dengan metode serialisasi yang diberikan secara default. Jika kunci data berakhir dengan salah satu ekstensi yang dipetakan, metode serialisasi dalam nilai digunakan untuk menulis konten ke string. Bidang serialization spesifik pada entri data ConfigMaps menimpa pengaturan default apa pun. | true | |
serialization.configmap.fileExtensions | Kamus pemetaan dari ekstensi file ke metode serialisasi. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | Jika enabled , ekstensi file yang dipetakan di bawah fileExtensions diserialisasi dengan metode serialisasi yang diberikan secara default. Jika kunci data berakhir dengan salah satu ekstensi yang dipetakan, metode serialisasi dalam nilai digunakan untuk menulis konten ke string. Bidang serialization spesifik pada entri data rahasia menimpa pengaturan default apa pun. | true | |
serialization.secret.fileExtensions | Kamus pemetaan dari ekstensi file ke metode serialisasi. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | Global Switch yang memungkinkan objek RBAC untuk instalasi. Jika true semua objek RBAC yang diaktifkan digunakan ke cluster, jika false tidak ada objek RBAC yang dibuat sama sekali.Objek RBAC yang dapat digunakan adalah: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | Bidang bentuk bebas sedangkan subbidang bidang ini harus memiliki makna yang jelas dalam konteks rangkaian produk Anda. Misalnya, asumsikan semua produk atau layanan mikro Anda (masing -masing datang sebagai grafik helm yang terpisah) tergantung pada titik akhir yang diberikan yang sama (otentikasi, konfigurasi, ...). Anda mungkin memiliki pekerjaan bersama Kubernetes yang dieksekusi oleh setiap grafik Helm yang menargetkan titik akhir tersebut. Sekarang Anda dapat menentukan values.yaml lambung eksternal. Yl yang berisi spesifikasi pekerjaan dan definisi titik akhir di sini dengan cara yang Anda inginkan dan membangun values.yaml overlay.yAML yang diberikan di atas setiap penyebaran dan memiliki mekanisme terpadu di tempatnya. | {} | |
config.general.metadata | Bidang metadata yang ditentukan di sini akan secara otomatis ditambahkan ke semua objek metadata. Hanya memiliki sub-bidang berikut: labelsannotations | ||
config.general.metadata.labels | Label yang ditambahkan ke semua objek. Label common mengacu pada kubernet dan helm label umum dan label custom dapat ditentukan secara bebas.Hanya memiliki sub-bidang berikut: commoncustom | ||
config.general.metadata.labels.common | Spesifikasi label umum sebagaimana didefinisikan dalam https://helm.sh/docs/chart_best_practices/labels/ dan https://kubernetes.io/docs/concepts/overview/working-with-Objects/common-labels/. Kecuali secara khusus ditimpa dengan nilai kosong ( '' ) semua label metadata ditambahkan secara otomatis ke semua objek sesuai dengan definisi default mereka. Ini harus dipertimbangkan untuk menetapkan nilai untuk config.general.metadata.labels.common.'app.kubernetes.io/part-of' jika grafik helm merupakan bagian dari rangkaian produk. | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | Dikelola oleh metadata. | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | Versi metadata. | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | Bagian metadata. | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | Nama metadata. | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | Contoh metadata. | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | Metadata Komponen. | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | Helm Metadata. | `{{(printf"%s-%s ".chart.name .chart.version) | Ganti "+" "_"}} ` |
config.general.metadata.labels.custom | Semua label khusus yang ditentukan secara otomatis ditambahkan ke semua objek bagan helm ini. | {} | |
config.general.metadata.annotations | Anotasi yang ditambahkan ke semua objek. Label custom dapat ditentukan secara bebas.Hanya memiliki sub-bidang berikut: custom . | ||
config.general.metadata.annotations.custom | Semua anotasi khusus yang ditentukan secara otomatis ditambahkan ke semua objek bagan helm ini. | {} | |
config.specific | Bidang formulir gratis yang memiliki opsi konfigurasi yang spesifik untuk produk spesifik yang terkandung dalam grafik helm. Biasanya nilai -nilai yang ditentukan di sini harus digunakan untuk mengisi konten file konfigurasi yang dibaca oleh aplikasi tertentu konfigurasinya dari saat startup. Oleh karena itu bidang config.specific . Spesifik biasanya dikonsumsi dalam configmaps atau rahasia. | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects Jenis objek tingkat atas di bawah hull.objects mewakili tipe objek Kubernetes yang didukung yang mungkin ingin Anda buat contoh. Setiap jenis objek adalah kamus di mana nilai entri adalah properti objek dan setiap objek memiliki kunci sendiri yang unik untuk jenis objek yang dimiliki. Jenis objek K8S lebih lanjut dapat ditambahkan sesuai kebutuhan ke perpustakaan sehingga dapat dengan mudah diperpanjang.
Salah satu aspek penting adalah bahwa untuk semua jenis objek tingkat atas, instance dari jenis tertentu selalu diidentifikasi oleh kunci yang unik untuk instance dan kombinasi tipe objek. Namun kunci yang sama dapat digunakan untuk contoh jenis objek yang berbeda.
Dengan memiliki kunci yang mengidentifikasi contoh yang Anda bisa:
Lakukan penggabungan berlapis-lapis dari properti objek dengan menumpuk values.yaml file di atas satu sama lain. Anda mungkin mulai dengan mendefinisikan struktur objek default aplikasi atau layanan mikro yang ditentukan dalam bagan Helm yang diberikan. Maka Anda dapat menambahkan values.yaml lapisan untuk lingkungan tertentu seperti pementasan atau produksi. Maka Anda dapat menambahkan lapisan values.yaml untuk kredensial. Dan sebagainya. By uniquely identifying the instances of a particular K8s object type it becomes easy to adjust the objects properties through a multitude of layers.
use the key of an instance for naming the instance. All instance names are constructed by the following ground rule: {{ printf "%s-%s-%s" .Release.Name .Chart.Name key }} . This generates unique, dynamic names per object type and release + instance key combination.
For example, assuming the parent Helm chart is named my_webservice and the release named staging and given this specification in values.yaml :
hull :
objects :
deployment :
nginx :
pod :
containers :
nginx :
repository : nginx
tag : 1.14.2 a Kubernetes deployment object with the following metadata.name is created:
my_webservice-staging-nginx
Note that you can opt to define a static name for instances you create by adding a property
staticName: trueto your objects definition. If you do so the objects name will exactly match the key name you chose.
each particular instance can have an enabled sub-field set to true or false . This way you can predefine instances of object types in your helm charts values.yaml but not deploy them in a default scenario. Or enable them by default and refrain from deploying them in a particular environment by disabling them in an superimposed system specific values.yaml . Note that unless you explicitly specify enabled: false each instance you define will be created by default, a missing enabled key is equivalent to enabled: true .
cross-referencing objects within a helm chart by the instance key is a useful feature of the HULL library. This is possible in these contexts:
Note that you can in these cases opt to refer to a static name instead too. Adding a property
staticName: trueto the dictionary with your reference will force the referenced objects name to exactly match the name you entered.
The values of object instance keys reflects the Kubernetes objects to create for the chart. To specify these objects efficiently, the available properties for configuration can be split into three groups:
Basic HULL object configuration with hull.ObjectBase.v1 whose properties are available for all object types and instances. These are enabled , staticName , annotations and labels .
Given the example of a deployment named nginx you can add the following properties of hull.ObjectBase.v1 to the object instance:
hull :
objects :
deployment :
nginx : # unique key/identifier of the deployment to create
staticName : true # property of hull.ObjectBase.v1
# forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
enabled : true # property of hull.ObjectBase.v1
# this deployment will be rendered to a YAML object if enabled
labels :
demo_label : " demo " # property of hull.ObjectBase.v1
# add all labels here that shall be added
# to the object instance metadata section
annotations :
demo_annotation : " demo " # property of hull.ObjectBase.v1
# add all annotations here that shall be added
# to the object instance metadata section
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see below for details
Specialized HULL object properties for some object types. Below is a reference of which object type supports which special properties in addition to the basic object configuration.
Again given the example of a deployment named nginx you would want to add properties of the HULL hull.PodTemplate.v1 to the instance. With them you set the pod property to define the pod template (initContainers, containers, volumes, ...) and can add templateLabels and templateAnnotations just to the pods created metadata and not the deployment objects metadata section:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
templateLabels : # property of hull.PodTemplate.v1 to define
# labels only added to the pod
demo_pod_label : " demo pod "
templateAnnotations : # property of hull.PodTemplate.v1 to define
# annotations only added to the pod
demo_pod_annotation : " demo pod "
pod : # property of hull.PodTemplate.v1 to define the pod template
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx # specify repository and tag
# separately with HULL for easier composability
tag : 1.14.2
... # further properties (volumeMounts, affinities, ...)
Kubernetes object properties. For each object type it is basically possible to specify all existing Kubernetes properties. In case a HULL property overwrites a identically named Kubernetes property the HULL property has precedence. Even if a HULL property overrides a Kubernetes property it is intended to provide the same complete configuration options, even if sometimes handled differently by HULL.
Some of the typical top-level Kubernetes object properties and fields don't require setting them with HULL based objects because they can be deducted automatically:
apiVersion and kind are determined by the HULL object type and Kubernetes API version and don't require to be explicitly set (except for objects of type customresource ).metadata dictionary on objects is handled by HULL via the annotations and labels fields and the naming rules explained above. So the metadata field does not require configuration and is hence not configurable for any object.Some lower level structures are also converted from the Kubernetes API array form to a dictionary form or are modified to improve working with them. This also enables more sophisticated merging of layers since arrays don't merge well, they only can be overwritten completely. Overwriting arrays however can make it hard to forget about elements that are contained in the default form of the array (you would need to know that they existed in the first place). In short, for a layered configuration approach without an endless amount of elements the dictionary is preferable for representing data since it offers a much better merging support.
So again using the example of a deployment named nginx you can add the remaining available Kubernetes properties to the object instance which are not handled by HULL as shown below. For a deployment specifically you can add all the remaining properties defined in the deploymentspec API schema from deploymentspec-v1-apps which are minReadySeconds , paused , progressDeadlineSeconds , replicas , revisionHistoryLimit and strategy . If properties are marked as mandatory in the Kubernetes JSON schema you must provide them otherwise the rendering process will fail:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see above for details
replicas : 3 # property from the Kubernetes API deploymentspec
strategy : # property from the Kubernetes API deploymentspec
type : Recreate
... # further Kubernetes API deploymentspec options
Here is an overview of which top level properties are available for which object type in HULL. The HULL properties are grouped by the respective HULL JSON schema group they belong to. A detailed description of these groups and their properties is found in the documentation of this helm chart and the respective linked documents.
Workloads APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
deployment | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | deploymentspec-v1-appsminReadySecondspausedprogressDeadlineSecondsreplicasrevisionHistoryLimitstrategy |
job | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | jobspec-v1-batchactiveDeadlineSecondsbackoffLimitcompletionModecompletionsmanualSelectorparallelismselectorsuspendttlSecondsAfterFinished |
daemonset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | daemonsetspec-v1-appsminReadySecondsrevisionHistoryLimitupdateStrategy |
statefulset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | statefulsetspec-v1-appspodManagementPolicyreplicasrevisionHistoryLimitserviceNameupdateStrategyserviceNamevolumeClaimTemplates |
cronjob | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Job.v1 job | cronjobspec-v1-batchconcurrencyPolicyfailedJobsHistoryLimitschedulestartingDeadlineSecondssuccessfulJobsHistoryLimitsuspend |
Service APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
endpoints | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpoints-v1-coresubsets |
endpointslice | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpointslice-v1-discovery-k8s-ioaddressTypeendpointsports |
service | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Service.v1 ports | servicespec-v1-coreallocateLoadBalancerNodePortsclusterIPclusterIPsexternalIPsexternalNameexternalTrafficPolicyhealthCheckNodePortinternalTrafficPolicyipFamiliesipFamilyPolicyloadBalancerClassloadBalancerIPloadBalancerSourceRangespublishNotReadyAddressesselectorsessionAffinitysessionAffinityConfigtopologyKeystype |
ingress | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Ingress.v1 tlsrules | ingressspec-v1-networking-k8s-iodefaultBackendingressClassName |
ingressclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | ingressclassspec-v1-networking-k8s-iocontrollerparameters |
Config and Storage APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
configmap | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | configmap-v1-corebinaryDataimmutable |
secret | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | secret-v1-coreimmutablestringDatatype |
registry | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Registry.v1 serverusernamepassword | secret-v1-core |
persistentvolumeclaim | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumeclaimspec-v1-coreaccessModesdataSourceresourcesselectorstorageClassNamevolumeModevolumeName |
storageclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | storageclass-v1-storage-k8s-ioallowVolumeExpansionallowedTopologiesmountOptionsparametersprovisionerreclaimPolicyvolumeBindingMode |
Metadata APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
customresource | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.CustomResource.v1 apiVersionkindspec | |
limitrange | hull.ObjectBase.v1enabledannotationslabelsstaticName | limitrange-v1-corelimits |
horizontalpodautoscaler | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.HorizontalPodAutoscaler.v1 scaleTargetRef | horizontalpodautoscalerspec-v2-autoscalingbehaviormaxReplicasmetricsminReplicas |
mutatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.MutatingWebhook.v1 webhooks | |
poddisruptionbudget | hull.ObjectBase.v1enabledannotationslabelsstaticName | poddisruptionbudgetspec-v1-policymaxUnavailableminAvailableselector |
validatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.ValidatingWebhook.v1 webhooks | |
priorityclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | priorityclass-v1-scheduling-k8s-iodescriptionglobalDefaultpreemptionPolicyvalue |
Cluster APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
clusterrole | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | clusterrole-v1-rbac-authorization-k8s-ioaggregationRule |
clusterrolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | clusterrolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
namespace | hull.ObjectBase.v1enabledannotationslabelsstaticName | namespace-v1-corespecstatus |
persistentvolume | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumespec-v1-coreaccessModesawsElasticBlockStoreazureDiskazureFilecapacitycephfscinderclaimRefcsifcflexVolumeflockergcePersistentDiskglusterfshostPathiscsilocalmountOptionsnfsnodeAffinitypersistentVolumeReclaimPolicyphotonPersistentDiskportworxVolumequobyterbdscaleIOstorageClassNamestorageosvolumeModevsphereVolume |
role | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | role-v1-rbac-authorization-k8s-io |
rolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | rolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
serviceaccount | hull.ObjectBase.v1enabledannotationslabelsstaticName | serviceaccount-v1-coreautomountServiceAccountTokenimagePullSecretssecrets |
resourcequota | hull.ObjectBase.v1enabledannotationslabelsstaticName | resourcequotaspec-v1-corehardscopeSelectorscopes |
networkpolicy | hull.ObjectBase.v1enabledannotationslabelsstaticName | networkpolicyspec-v1-networking-k8s-ioegressingresspodSelectorpolicyTypes |
Other APIs
| LAMBUNG KAPAL Object Type | LAMBUNG KAPAL Properti | Kubernetes/External Properti |
|---|---|---|
servicemonitor | hull.ObjectBase.v1enabledannotationslabelsstaticName | ServiceMonitor CRDspec |
To test or install a chart based on HULL the standard Helm v3 tooling is usable. See also the Helm documentation at the Helm website.
To inspect the outcome of a specific values.yaml configuration you can simply render the templates which would be deployed to Kubernetes and inspect them with the below command adapted to your needs:
<PATH_TO_HELM_V3_BINARY> template --debug --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> --output-dir <PATH_TO_OUTPUT_DIRECTORY> <PATH_TO_CHART_DIRECTORY>
Installing or upgrading a chart using HULL follows the standard procedures for every Helm chart:
<PATH_TO_HELM_V3_BINARY> upgrade --install --debug --create-namespace --atomic --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> <RELEASE_NAME> <PATH_TO_CHART_DIRECTORY>
Using the nginx deployment example from the Kubernetes documentation https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment as something we want to create with our HULL based Helm chart:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx
labels :
app : nginx
spec :
replicas : 3
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
containers :
- name : nginx
image : nginx:1.14.2
ports :
- containerPort : 80 To render this analogously using the HULL library your chart needs to be setup for using HULL. In the following section we assume the parent Helm chart is named hull-test and we use the helm template command to test render the values.yaml 's.
A minimal example of creating the expected result from above would be to create a values.yaml like below in your parent chart (commented with some explanations). Note that some default features of HULL such as RBAC and dynamic naming are explicitly disabled here to obtain the output matching the above example closely:
hull :
config :
general :
rbac : false # Don't render RBAC objects. By default HULL would provide
# a 'default' Role and 'default' RoleBinding associated with
# a 'default' ServiceAccount to use for all pods.
# You can modify this as needed. Here we turn it off to not
# render the default RBAC objects.
objects :
serviceaccount :
default :
enabled : false # The release specific 'default' ServiceAccount created
# for a release by default is disabled here. In this case
# it will not be rendered out and automatically used as
# 'serviceAccountName' in the pod templates.
deployment :
nginx : # all object instances have a key used for naming the objects and
# allowing to overwrite properties in multiple values.yaml layers
staticName : true # forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : 1.14.2
ports :
http : # unique key per container here too. All key-value structures
# which are finally arrays in the K8S objects are converted to
# arrays on rendering the chart.
containerPort : 80 This produces the following rendered deployment when running the helm template command (commented with some brief explanations):
apiVersion : apps/v1 # derived from object type 'deployment'
kind : Deployment # derived from object type 'deployment'
metadata :
annotations : {}
labels : # standard Kubernetes metadata is created always automatically.
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
name : nginx # default name would be 'release-name-hull-test-nginx'
# but with staticName: true in the HULL spec it is just the key name
spec :
replicas : 3
selector : # selector is auto-created to match the unique metadata combination
# found also in the in the object's metadata labels.
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations : {}
labels : # auto-created metadata is added to pod template
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http # name 'http' derived from the key of the port
# object defined in the values.yaml
volumeMounts : []
imagePullSecrets : {}
initContainers : []
volumes : [] Now to render the nginx deployment example showcasing extra features of the HULL library you can could create the below values.yaml file in your parent chart. Note that this is a very advanced example of what is possible using this library chart.
This example highlights:
hull :
config :
general : # This time we are not setting rbac: false
# so RBAC default objects are created.
# If the default objects don't match the use-case
# you can tweak all aspects individually if needed
metadata :
labels :
custom : # Additional labels added to all K8S objects
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
annotations :
custom : # Additional annotations added to all K8S objects
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
specific : # Put configuration options specific to this chart here
nginx_tag : 1.14.2 # You can also use entries here to globally
# define values that are referenced in multiple
# places in your chart. See how this field
# is accessed below in the deployment.
objects :
deployment :
_HULL_OBJECT_TYPE_DEFAULT_ : # A special object key available for
# all object types allowing defining
# defaults for properties of all object
# type instances created.
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Default Annotation 2
general_custom_annotation_2 : Default Annotation 2 # overwriting this
# general annotation for
# all deployments
labels :
default_label_1 : Default Label 1
default_label_2 : Default Label 2
general_custom_label_2 : Default Label 2 # overwriting this
# general label for
# all deployments
nginx : # specify the nginx deployment under key 'nginx'
# This time we're not setting the metadata.name to be static so
# name will be created dynamically and will be unique
annotations :
general_custom_annotation_3 : Specific Object Annotation 3 # overwrite a
# general annotation
default_annotation_2 : Specific Object Annotation 2 # overwrite a default annotation
specific_annotation_1 : Specific Object Annotation 1 # add a specific annotation
# to the all this object's metadata
labels :
general_custom_label_3 : Specific Object Label 3 # overwrite a
# general label
default_label_2 : Specific Object Label 2 # overwrite a default label
specific_label_1 : Specific Object Label 1 # add a specific label
# to the all this object's metadata
templateAnnotations :
specific_annotation_2 : Specific Template Annotation 2 # this annotation will only appear
# in the pod template metadata
templateLabels :
specific_label_2 : Specific Template Label 2 # this label will only appear
# in the pod template metadata
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : _HT!{{ (index . "$").Values.hull.config.specific.nginx_tag }}
# Applies a tpl transformation allowing to inject dynamic data based
# on values in this values.yaml into the resulting field (here the tag
# field of this container).
# _HT! is the short form of the transformation that applies tpl to
# a given value. This example just references the value of the field
# which is specified further above in the values.yaml and will
# produce 'image: nginx:1.14.2' when rendered in the resulting
# deployment YAML but complex conditional Go templating logic is
# applicable too.
# There are some limitations to using this approach which are
# detailed in the transformation.md in the doc section.
ports :
http : # unique key per container here too. All key-value structures
# which are array in the K8S objects are converted to arrays
# on rendering the chart.
containerPort : 80
configmap : # this is to highlight the secret/configmap inclusion feature
nginx_configmap : # configmap objects have keys too
data : # specify for which contents a data entry shall be created
# within only a few lines of configuration. Contents can come from ...
an_inline_configmap.txt : # ... an inline specified content or ...
inline : |-
Top secret contents
spread over
multiple lines...
contents_from_an_external_file.txt : # ... something from an external file.
path : files/my_secret.txt
This produces the following rendered objects when running the helm template command (commented with some brief explanations):
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
kind : ServiceAccount
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # This is the default ServiceAccount created for this chart.
# As all object instances by default it will be assigned a
# dynamically created unique name in context of this object type.
# In the simple example we disabled this rendering by
# setting enabled: false for this object's key.
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # A default Role for RBAC.
rules : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : RoleBinding
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default
roleRef :
apiGroup : rbac.authorization.k8s.io/v1
kind : Role
name : release-name-hull-test-default
subjects :
- apiGroup : rbac.authorization.k8s.io/v1
kind : ServiceAccount
name : release-name-hull-test-default # A default RoleBinding for RBAC. It connects the
# default ServiceAccount with the default Role.
# By default RBAC is enabled in charts.
---
# Source: hull-test/templates/hull.yaml
apiVersion : apps/v1
kind : Deployment
metadata :
annotations :
default_annotation_1 : Default Annotation 1 # non-overwritten default_annotation
default_annotation_2 : Specific Object Annotation 2 # overwritten default_annotation by instance
general_custom_annotation_1 : General Custom Annotation 1 # non-overwritten general_custom_annotation
general_custom_annotation_2 : Default Annotation 2 # overwritten general_custom_annotation
# by default_annotation
general_custom_annotation_3 : Specific Object Annotation 3 # overwritten general_custom_annotation
# by specific_annotation
specific_annotation_1 : Specific Object Annotation 1 # added annotation for instance metadata only
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1 # non-overwritten default_label
default_label_2 : Specific Object Label 2 # overwritten default_label by instance
general_custom_label_1 : General Custom Label 1 # non-overwritten general_custom_label
general_custom_label_2 : Default Label 2 # overwritten general_custom_label by default_label
general_custom_label_3 : Specific Object Label 3 # overwritten general_custom_label
# by specific_label
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1 # added label for instance metadata only
name : release-name-hull-test-nginx
spec :
replicas : 3
selector :
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Specific Object Annotation 2
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : Default Annotation 2
general_custom_annotation_3 : Specific Object Annotation 3
specific_annotation_1 : Specific Object Annotation 1
specific_annotation_2 : Specific Template Annotation 2 # this annotation was added only
# for the pod template's metadata
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1
default_label_2 : Specific Object Label 2
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : Default Label 2
general_custom_label_3 : Specific Object Label 3
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1
specific_label_2 : Specific Template Label 2 # this label was added only
# for the pod template's metadata
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http
volumeMounts : []
imagePullSecrets : {}
initContainers : []
serviceAccountName : release-name-hull-test-default # the dynamically created name
volumes : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
data :
an_inline_configmap.txt : " Top secret contents n spread over n multiple lines... "
contents_from_an_external_file.txt : " Whatever was in this file ... "
kind : ConfigMap
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : nginx_configmap
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-nginx_configmapRead the additional documentation in the documentation folder on how to utilize the features of the HULL library to the full effect.
