hull
hull-demo-1.31.2
يحتوي هذا المستودع على مخطط مكتبة Hull Helm. إنه مصمم لتخفيف بناء كائنات Kubernetes وصيانتها في مخططات Helm ويمكن إضافتها إلى أي مخطط هيلم كملحق لتعزيز الوظائف دون أي خطر من تكوينات مخططات Helm الحالية.
يمكن العثور على الرسم البياني نفسه وجميع الوثائق المتعلقة به في مجلد hull وهو المجلد الجذري لمخطط Hull Library Helm.
يتم تخزين مخططات Kubernetes API JSON في مجلد kubernetes-json-schema .
فيما يلي مخططات الهيكل README.md :
يجب الحفاظ على التجريدات - Kelsey Hightower
يتمثل أحد جوانب التصميم الرئيسية في HELM في أنه يجبر المستخدم على إنشاء تجريدات فردية لتكوين التطبيقات Kubernetes. لكل مخطط هيلم فردي يتحقق في شكل قوالب YAML في مجلد مخططات /templates HELM. ملفات القالب هذه ، التي تحتوي على boilerplate kubernetes كتل رمز yaml من جهة وتخصيصات التكوين المخصصة باستخدام تعبيرات GO Templating من ناحية أخرى ، ووفر الغراء بين تكوين التطبيق عبر ملف values.yaml المركزي. . يمكن القول إن هذا النهج من تجريد التطبيقات لكل تطبيق مناسب لإنشاء حزم تكوين ذي لاعبين حتى لتطبيقات أكثر تخصصًا ، ولكنها تأتي بتكلفة من وجود تكاليف كبيرة لحالات استخدام تطبيقات التطبيقات الأكثر بساطة ومتكررة والقدرة على الجرف. يمكن أن يصبح إنشاء وصيانة (في كثير من الأحيان) فهم التجريدات التي أدخلتها مخططات Helm - خاصة عند مواجهة عدد كبير من مخططات القيادة الفردية من مصادر مختلفة - مملة وصعبة.
الميزة الأساسية لمكتبة بدن هي القدرة على إزالة ملفات قالب YAML المخصصة بالكامل من مهام سير عمل Helm Chart وبالتالي السماح بإزالة مستوى التجريد. باستخدام مخطط مكتبة Hull ، يمكن تحديد كائنات Kubernetes بما في ذلك جميع خصائصها تمامًا وشفافية في values.yaml . يوفر مخطط مكتبة Hull نفسه الطبقة الموحدة لتبسيط المواصفات والتكوين وتقديم مخططات Helm لتحقيق ذلك. يمكنك أيضًا التفكير في الأمر كطبقة رقيقة أعلى واجهة برمجة تطبيقات Kubernetes لتجنب الوسيط بين Chart Chart و Kubernetes تكوين كائن API ، ومع ذلك توفير المرونة عندما يكون مطلوبًا لتخصيص خيارات التكوين الفردية بدلاً من مطالبةك بإضافة كل مفتاح تكوين يدويًا إلى القوالب. التحقق من صحة مخطط JSON استنادًا إلى ميزة التحقق من صحة Helm JSON (عبر values.schema.json . تتوفر فوائد إضافية (بيانات تعريف كائن موحدة موحدة ، وإدراج مبسط للتكوين/الأسرار ، وقيم المرجع المتبادل ضمن values.yaml ، ...) مع بدن يمكنك قراءتها أدناه في نظرة عامة على الميزات الرئيسية . ولكن ربما الأهم من ذلك ، يمكن إضافة مكتبة بدن كاعتماد على أي مخطط هيلم موجود ويتم استخدامه جنبًا إلى جنب دون كسر أي وظائف مخططات هيلم موجودة ، راجع إضافة مخطط مكتبة بدن إلى مخطط هيل لمزيد من المعلومات. وأخيرًا ، من خلال كونه مخططًا للمكتبة نفسه ، يعمل كل شيء بنسبة 100 ٪ ضمن الوظائف التي توفرها Helm Plain - لا يتم تقديم أو مشاركة أدوات إضافية.
يتم تقييم ملاحظاتك على هذا المشروع ، وبالتالي يرجى التعليق أو بدء مناقشة في قسم Issues أو إنشاء رغبات الميزة وتقارير الأخطاء. شكرًا لك!
فكرة مخطط مكتبة Hull مستوحاة جزئيًا من مفهوم مخطط Helm المشترك ولاختبار
.
hull-demo قبل الغوص في تفاصيل هال ، إليك نظرة أولى على كيفية عملها. يمكنك ببساطة تنزيل أحدث إصدار من مخطط hull-demo Helm من قسم الإصدارات في هذه الصفحة ، ويحتوي على كل شيء تم تجميعه لاختبار Hull أو إعداد مخطط هيلم جديد يعتمد على بدن بأقل جهد.
يلف مخطط hull-demo تطبيقًا خياليًا myapp مع وجود frontend وزوج من النشر وخدمة الخدمة backend . يوجد ملف تكوين لتكوين الخادم الذي يتم تركيبه على قرون backend . تحتاج قرون frontend إلى معرفة عنوان خدمة backend عبر متغيرات البيئة. علاوة على ذلك ، يجب أن يكون الإعداد بشكل افتراضي قابلاً للتبديل بسهولة من إعداد debug (باستخدام NodePort للوصول إلى الواجهة الأمامية) إلى إعداد يشبه الإنتاج (باستخدام خدمة مجموعة وإدخال).
قد يبدو هذا الهيكل الافتراضي العاري لالتقاط هذه الجوانب مثل هذا (مع تعليقات الخط المضافة للتوضيح):
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 هذا هو المثال الذي يشكل values.yaml hull-demo hull-demo .
helm template hull-demo-<version>.tgz
يطرح مجموعة من الكائنات على أساس values.yaml المذكورة أعلاه. yaml تحتوي على:
myapp-frontend myapp-backend يحتوي على مجموعة صور tag مركزية (افتراضيًا v23.1 ) ، ومتغيرات البيئة تشيرmyapp-backend يحتوي على tag صور مصابة مركزية (افتراضيًا v23.1 ) وتكوين مثبت من myappconfig configmapmyappconfig مع ملف JSON الذي تم تصميمه ديناميكيًا عن طريق دمج تعبيرات التحول والإشارة إلى القيم المحددة في مكان آخر في values.yamlmyapp-backendmyapp-frontend النشر التي يعتمد تكوين نوعها ومنفذها على مفتاح debug المركزي-إما أن يكون NodePort في وضع إعداد debug أو نوع ClusterIP مع دخول myapp في إعدادات غير Debugmyapp الذي يتم تقديمه/إنشاؤه فقط في حالة debug: false يمكن تغيير كل جانب من جوانب هذا التكوين أو الكتابة في وقت النشر باستخدام values.yaml إضافية. ملفات تراكب yaml ، على سبيل المثال:
debug من خلال الإعدادات debug: true أو debug: falsemyapp ConfigMaps ( rate_limit و max_connections ) أو الكتابة فوقها بالكامل تم إنشاء جميع الكائنات والمنطق تحت مائة سطر من رمز التكوين العام في values.yaml hull-demo . يمكنك اختبار جميع الجوانب المذكورة أعلاه أو ببساطة التجربة عن طريق إضافة values.yaml helm template . من أجل bootstrapping مخطط هيلم الخاص بك ، فقط تفريغ values.yaml تكوين yaml ، أعد تسمية مجلد المخططات name في Chart.yaml إلى كل ما تريد وأنت مستعد للذهاب.
هذا عرض أول لكيفية استخدام بدن ولكن هناك الكثير من الوظائف ودعم حالات الاستخدام. تحقق من الميزات الرئيسية والوثائق التفصيلية لمزيد من المعلومات.
كما هو موضح أعلاه ، عند تضمينه في مخطط Helm ، يمكن أن يتولى مخطط مكتبة Hull مهمة تقديم كائنات Kubernetes ديناميكيًا من مواصفاتها المحددة من ملف values.yaml وحده. مع تأجيل إنشاء كائن Yaml إلى وظائف Go Templating لمكتبة Hull بدلاً من قوالب YAML المخصصة في مجلد /templates ، يمكنك فرض أفضل الممارسات مركزيًا:
ركز على ما هو مطلوب لتحديد كائنات kubernetes دون الحاجة إلى إضافة قوالب yaml من فرد boilerplate إلى الرسم البياني الخاص بك. هذا يزيل مصدرا مشتركا للأخطاء والصيانة من سير العمل العادي. للحصول على إخراج الهيكل المقدم يتوافق مع مواصفات API Kubernetes ، يقوم عدد كبير من اختبارات الوحدة بالتحقق من صحة الهيكل المقدم ضد مخطط Kubernetes API JSON.
لمزيد من التفاصيل ، راجع الوثائق المتعلقة بالتحقق من مخطط JSON.
بالنسبة لجميع أنواع كائنات Kubernetes المدعومة بواسطة Hull ، تتوفر وصول تكوين كامل إلى خصائص أنواع كائنات Kubernetes مباشرة . هذا يخفف من مخططات المخططات من الاضطرار إلى إضافة خيارات التكوين المفقودة واحداً تلو الآخر ومستخدمي الرسم البياني من وضع الرسم البياني لإضافة الخصائص التي يحتاجونها فقط لتكوينهم. مطلوب فقط تحديث الرسم البياني للبدن إلى إصدار أحدث مع مطابقة إصدار API Kubernetes لتمكين تكوين الخصائص المضافة إلى كائنات Kubernetes وفي الوقت نفسه في إصدارات API الأحدث. يتم إصدار النسخة المخططات بدن لتعكس إصدارات API في Kubernetes الأدنى التي تدعمها.
لمزيد من التفاصيل ، ارجع إلى الوثائق المتعلقة بعرض العمارة.
يتم استخدام الواجهة الفردية لمكتبة بدن لإنشاء وتكوين كائنات في المخططات للنشر. هذا يعزز الفهم المتبادل لمبدعو المخططات/المشرفين والمستهلكين عن كيفية عمل المخطط فعليًا وما يحتويه. إن البحث في مجلد /templates لفهم آثار مخططات Helm لم يعد مطلوبًا. لتجنب أي تهيئة سوء التكوين ، تم التحقق من صحة values.yaml تمامًا. عند استخدام IDE لدعم التحقق من مخطط JSON Live (مثل VSCODE) ، يمكنك الحصول على إرشادات IDE عند إنشاء كائنات بدن. قبل تقديم ، تم التحقق من صحة مطابقة مخطط JSON بواسطة مكتبة بدن.
لمزيد من التفاصيل ، راجع الوثائق المتعلقة بالتحقق من مخطط JSON.
يتم إرفاق البيانات الوصفية الموحدة والغنية تلقائيًا بجميع الكائنات التي أنشأتها مكتبة بدن.
لمزيد من التفاصيل حول الكتابة الفوقية ، ارجع إلى المثال المتقدم أدناه.
معالجة مرنة لـ ConfigMap والإدخال السري من خلال الاختيار بين مواصفات المحتويات المضمّنة في values.yaml yaml أو الاستيراد من الملفات الخارجية لمحتويات أحجام أكبر. عند استيراد البيانات من الملفات ، يمكن إما تشغيل البيانات من خلال محرك templating أو غير معروف "كما هي" إذا كانت تحتوي بالفعل على تعبيرات ترامب يتم نقلها إلى التطبيق المستهلك. مع التركيز على التعامل المريح للسيناريوهات القياسية ، يمكنك أيضًا تحديد محتويات الملفات كهيكل YAML عادي في values.yaml yaml وقم بتسلسلها تلقائيًا إلى JSON أو YAML بواسطة امتداد الملف أو بشكل واضح إلى أي تمثيل لاختيارك. يهتم Hull بترميز أسرار BASE64 ، لذا فإن كتابة خرائط التكوين والأسرار تعمل بنفس الطريقة بالضبط وإضافة خرائط التكوين أو الأسرار إلى نشرك لا تتطلب سوى بضعة أسطر من التعليمات البرمجية.
لمزيد من التفاصيل ، ارجع إلى الوثائق على ConfigMaps والأسرار.
إمكانيات الإعاقة الواسعة لتأسيس مثيلات الكائن. سواء كنت ترغب في الحصول على جميع مثيلات الكائنات أو مجموعات الحالات ، تشترك في جوانب معينة مثل الملصقات أو التعليقات التوضيحية أو متغيرات بيئة الحاويات أو أحجامها المثبتة ، توفر Hull الدعم لتحديد القيم الافتراضية بكفاءة لحقول مثيل الكائن لتجنب تكرار التكوين غير الضروري.
لمزيد من التفاصيل ، يرجى الرجوع إلى نصائح تصميم المخططات.
بالنسبة للسيناريوهات الأكثر تعقيدًا حيث تخضع القيم الفعلية في الهدف YAML لتكوينات في values.yaml YAML ، هناك دعم لملء القيم ديناميكيًا عن طريق حقن تعبيرات GO المحددة بدلاً من القيمة في values.yaml . على سبيل المثال ، إذا كانت وسيطات الحاوية الخرسانية الخاصة بك تعتمد على إعدادات أخرى مختلفة في values.yaml يمكنك ضخ الشروط في حساب الوسيطات أو ببساطة الرجوع إلى الحقول الأخرى في values.yaml .
لمزيد من التفاصيل ، الرجوع إلى الوثائق حول التحولات.
تمكين التجزئة التلقائية من الخرائط والأسرار المشار إليها لتسهيل إعادة تشغيل POD على تغييرات التكوين عند الحاجة.
لمزيد من التفاصيل ، ارجع إلى الوثائق على القرون.
لمعرفة المزيد حول العمارة العامة وميزات مكتبة هال ، انظر نظرة عامة على الهندسة المعمارية
بعض الأشياء المهمة التي يجب ذكرها أولاً قبل النظر إلى المكتبة بمزيد من التفصيل:
/templates تمامًا عن طريق تكامل مخطط مكتبة Hull. في بعض الأحيان ، قد يكون لديك متطلبات محددة للغاية في تكوينك أو مواصفات الكائن التي لا تلبيها مكتبة بدن حتى تتمكن من استخدام سير عمل Helm المعتاد لهم ومكتبة بدن لتلبية احتياجاتك القياسية - بسهولة بالتوازي مع نفس مخطط الدفعة.
hull.yaml ، "AS-IS" دون أي تعديل من مجلد جذر مخططات الهيكل المدمجة إلى مجلد المخططات /templates الأصل ليكون قادرًا على تقديم أي YAML عبر الهيكل. أنه يحتوي على الكود الذي يبدأ خط أنابيب تقديم الهيكل ، راجع إضافة مخطط مكتبة Hull إلى مخطط هيلم لمزيد من التفاصيل!
3.0.x غير متوافقة مع Hull ، فإن جميع إصدارات Beta وغير Alpha الموجودة حاليًا متوافقة.
1.29 و 1.30 و 1.31 لديها إصدار بدن مطابق ومحافظة عليه.
إذا كنت تحب النهج ، فأنت مدعو إلى إلقاء نظرة على سلسلة الدروس الجديدة في Dev.to! سيبدأ البرنامج التعليمي في الجزء eigth من بداية إعداد Helm وإنشاء مخطط قائم على الهيكل لإنهاء مخطط Hull Hull القائم على Hull Life خطوة بخطوة. لتسليط الضوء على الاختلافات في سير عمل مخطط Helm العادي ، تأخذ البرامج التعليمية مخطط Helm kubernetes-dashboard الشهير كمصدر ونقله إلى مخطط هالم معادل وظيفيًا. في النهاية ، يوضح أن تقليل خطوط التكوين لإنشاء وصيانة يمكن تقليله بأكثر من 50 ٪ عند استخدام نهج يستند إلى بدن بدلاً من نمط الدفاع العادي في مخططات الكتابة!
يمكن اعتبار مهام إنشاء وتكوين مخطط هالم على أساس بدن الجانبين من نفس العملة. يتفاعل كلا الجانبين مع نفس الواجهة (مكتبة بدن) لتحديد الكائنات التي يجب إنشاؤها. تتمثل المهمة من منظور المبدعين/المشرفين في تقديم البنية الأرضية للكائنات التي تشكل التطبيق المعين الذي سيتم لفه في مخطط هيلم. يتم تكليف مستهلك الرسم البياني بإضافة سياق محدد لنظامه بشكل مناسب إلى الهيكل الأرضي حيث يتمتع بحرية التغيير وحتى إضافة أو حذف الأشياء حسب الحاجة لتحقيق أهدافه. في وقت النشر ، يتم دمج البنية الأساسية للمبدعين مع ملف YAML الخاص بنظام المستهلكين لإنشاء التكوين الكامل. التفاعل عبر واجهة المكتبة نفسها يعزز الفهم المشترك لكيفية العمل مع المكتبة على كلا الجانبين ويمكنه القضاء على معظم عمليات إنشاء النسخ واللصق الشاقة والفحص.
لذلك كل ما هو مطلوب لإنشاء مخطط هيلم على أساس بدن هو هيكل دليل مخطط هيلم سقالة. أضف مخطط مكتبة Hull كخطط فرعية ، انسخ hull.yaml من مخطط مكتبة Hull إلى مجلد /templates Helm Helm. ثم فقط قم بتكوين الكائنات الافتراضية للنشر عبر values.yaml . لا يوجد حد لعدد الكائنات التي تقوم بإنشائها لحزمة النشر الخاصة بك.
ولكن إلى جانب السماح بتحديد تطبيقات أكثر تعقيدًا باستخدام Hull ، يمكنك أيضًا استخدامها لالتفاف كائنات Kubernetes البسيطة التي يمكنك نشرها إما عبر KUBECTL (كونها خارج عن منظور الإدارة مع إصدارات HELM) أو يجب أن تكتب كمية كبيرة من قوالب Helm Boilerplate لتحقيق ذلك.
يتم إعطاء الهيكل الأساسي values.yaml . هذا يشكل بشكل أساسي الواجهة الفردية لإنتاج الرسوم البيانية المستندة إلى بدن الاستهلاك. يتم إنشاء أي كائن فقط في حالة تعريفه وتمكينه في values.yaml ، وهذا يعني أنك قد ترغب في تكوين كائنات مسبقة للمستهلكين الذين سيحتاجون فقط إلى تمكينهم إذا أرادوا استخدامها.
في المستوى العلوي من بنية YAML ، يميز Hull بين config objects . في حين أن التكوين الفرعي config يهدف إلى التعامل مع إعدادات مخطط محددة مثل البيانات الوصفية وإعدادات المنتج ، يتم تحديد كائنات Kubernetes الخرسانية المراد تقديمها ضمن مفتاح objects . يُسمح أيضًا version مفتاح إضافي للمستوى العليا الثالث المسماة ، عندما يتم تعيين ذلك على إصدار Hull Charts على سبيل المثال أثناء خط أنابيب Parent Helm Charts ، فإنه سيقوم تلقائيًا بتعبئة التسمية vidispine.hull/version على جميع الكائنات التي تشير إلى إصدار الهيكل تم استخدامه لتقديم الكائنات.
config ضمن قسم config ، يمكنك تكوين الإعدادات العامة لرسم هيلم الخاص بك. وهي مقسمة إلى قسمين فرعيين ، config.general و config.specific .
config.general على عكس القسم config.specific config.general من ناحية ، يحمل خيارات التكوين ذات الصلة بجميع المخططات القائمة على الهيكل ، ولكنها تترك أيضًا مساحة تحت config.general.data إدخال لتحديد حقول البيانات الخاصة بك والتي يتم تصميمها بشكل مثالي بنفس الطريقة في الرسوم البيانية الأخرى. على سبيل المثال ، إذا كانت العديد من التطبيقات في مجموعة المنتجات تعتمد على نفس نقاط النهاية ، فيمكنك تصميم نقاط النهاية هذه بشكل موحد تحت خاصية general.data في جميع المخططات ذات الصلة ، وبالتالي وجود واجهة مخططات Helm الخاصة بك بنفس الطريقة مع خط أنابيب النشر المستمر.
يحتوي config.general على الحقول الفرعية التالية فقط:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| المعلمة | وصف | تقصير | مثال |
|---|---|---|---|
nameOverride | يتم تطبيق تجاوز الاسم على قيم metadata label app.kubernetes.io/name . إذا تم تعيين هذا بشكل فعال يحل محل اسم الرسم البياني هنا. | ||
fullnameOverride | إذا تم ضبطه على قيمة ، يتم تطبيق تجاوز الاسم الكامل كبادئة لجميع أسماء الكائنات ويحل محل نمط البادئة <release>-<chart> في أسماء الكائنات. | myapp | |
namespaceOverride | إذا تم ضبطها على قيمة ، يتم تعيين مساحة الاسم لجميع الكائنات التي تم إنشاؤها على هذه القيمة. إذا لم يتم تعريف ذلك ، فإن مساحة اسم جميع مثيلات الكائنات تتخلف عن مساحة اسم الإصدار المقدمة إلى أمر HELM المعني. | my-namespace | |
noObjectNamePrefixes | إذا تم تعيينها ، فإن مفاتيح مثيل الكائن تعمل مباشرة كأسماء لكائنات Kubernetes التي تم إنشاؤها ولا يتم تسبقها أبدًا. هذا يعادل تقنيًا تعيين staticName True على كل كائن. لاحظ أنه من خلال تعيين هذا إلى true تصبح قيمة config.general.fullnameOverride غير ذي صلة. | false | true |
createImagePullSecretsFromRegistries | إذا كان ذلك صحيحًا ، يتم إنشاء أسرار سحب الصورة من جميع السجلات المحددة في مخطط القيادة هذا ويتم إضافته إلى جميع القرون. | true | false |
globalImageRegistryServer | إذا لم يكن فارغًا ، يتم تعيين حقل registry لجميع حقول image الحاوية على القيمة الواردة هنا. يتم تجاهل إعداد config.general.globalImageRegistryToFirstRegistrySecretServer إذا كان هذا الحقل غير فارغ. يتم كتابة جميع إعدادات registry الصريحة المحددة image مع هذه القيمة.الاستخدام المقصود لهذا هو أن يتم سحب جميع الصور من سجل Docker المركزي في حالة وجود فجوة الهواء مثل سيناريوهات النشر. على عكس تعيين globalImageRegistryToFirstRegistrySecretServer إلى true ، في هذه الحالة ، يتم تعريف سر التسجيل عادة خارج مخطط القيادة هذا ويتم الرجوع إلى خادم Secret في التسجيل باسمه مباشرة. إذا كنت تستخدم هذه الميزة وتحديد سر سجل Docker خارج مخطط Helm هذا ، فقد تحتاج بالإضافة إلى ذلك إلى إضافة imagePullSecrets إلى قرونك في حالة عدم وجود سجل Docker المشار إليه. | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | إذا كان True و globalImageRegistryServer فارغًا ، فسيتم تعيين حقل registry لجميع حقول image الحاوية على حقل server لكائن registry الذي تم العثور عليه الأول. لاحظ أن هذا هو السجل مع أدنى اسم مفتاح أبجدي رقمي إذا قمت بتقديم العديد registry obejcts. يجب استخدامها عادةً مع إعداد createImagePullSecretsFromRegistries إلى true للاستفادة من imagePullSecrets ومن ثم تعيين registry . يتم كتابة إعدادات registry الصريحة image مع هذه القيمة.الاستخدام المقصود لهذا الإعداد هو أن يتم سحب جميع الصور بسهولة من سجل Docker المركزي في حالة وجود فجوة الهواء مثل سيناريوهات النشر. | false | true |
errorChecks | الخيارات التي تحدد في الحالات التي ستنشئ Hull خطأً على helm install أو helm template . لمزيد من التفاصيل ، راجع أيضًا الوثائق التفصيلية حول تكوين اختبارات الأخطاءيحتوي فقط على الحقول الفرعية التالية: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | التحقق من عدم تقديم أية مكسورة يامل | true | |
errorChecks.hullGetTransformationReferenceValid | التحقق من صحة أن جميع المراجع _HT* تشير إلى مفتاح موجود في values.yaml | true | |
errorChecks.containerImageValid | التحقق من صحة أن جميع containers pod وأقسام image initContainers موجودة ولها على الأقل مجموعة repository | true | |
errorChecks.virtualFolderDataPathExists | التحقق من صحة أن جميع الملفات التي يتم الإشارة إليها في حقل path data ConfigMap و Secret موجود جسديًا | true | |
errorChecks.virtualFolderDataInlineValid | تم التحقق من صحة أنه لا توجد قيم null inline قيم مفقودة data والتي يتم تحويلها إلى سلاسل فارغة) | false | |
debug | الخيارات التي يمكن أن تساعد في مشاكل مخطط الأخطاء. في الغالب عفا عليها الزمن واستبدالها برسائل الخطأ الافتراضية التي تم تكوينها ضمن errorChecks .يحتوي فقط على الحقول الفرعية التالية: renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | التبديل العالمي الذي إذا تم تمكينه سيقوم بطباعة سلسلة:HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not foundبما في ذلك _HT*/hull.util.transformation.get المرجع ( xyz ) والمفتاح المفقود ( y ) إذا كان التحول يشير إلى مفتاح القاموس غير الموجود. يعد هذا مفيدًا لتصحيح تقديم مخططات المخططات ويقلل من البحث عن المراجع المكسورة لأن التثبيت عادة ما يجهض مع خطأ في المراجع المكسورة (مما قد يجعل من الصعب تحديد المرجع (S) الإشكالي.ملحوظة: الآن ، سيتم الإشارة إلى أي مرجع GET Broken بواسطة خطأ في المدارس بشكل افتراضي ، بحيث يكون هذا المفتاح قديمًا في الغالب لتصحيح الأخطاء المراجع المكسورة. يتم توضيح ذلك لتعطيل هذا الخيار والفشل بجد في Broken Get Get References بدلاً من ذلك وتحليل المشكلات مباشرة من رسالة الخطأ. | false | true |
debug.renderNilWhenInlineIsNil | التبديل العالمي الذي إذا تم تمكينه سيقوم بطباعة سلسلة:<nil>كقمة حقول data عندما تشير المواصفات inline إلى مؤشر nil في configmap أو السر. إذا تم ضبطها على خطأ ، فسيتم طباعة قيمة nil كسلسلة فارغة في حقل ConfigMap أو Secret data .ملحوظة: الآن ، سيتم الإشارة إلى أي حقول مضمنة غير صالحة بواسطة خطأ في المتحدث بشكل افتراضي (بمعنى hull.config.general.errorChecks.virtualFolderDataInlineValid true ). إن تمكين هذا المفتاح عفا عليه الزمن في الغالب لتصحيح الأخطاء ، ويوافق على تعطيل هذا الخيار والفشل بجد في الحقول المضمنة غير الصالحة. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | التبديل العالمي الذي إذا تم تمكينه سيقوم بطباعة سلسلة:<path missing: the_missing_path>في قيمة ConfigMap أو Secret data Fields بما في ذلك قيمة the_missing_path التي لا يتم حلها إلى ملف. إذا كان خطأ ، سيتم حل قيمة حقول data إلى سلسلة فارغة.ملحوظة: الآن ، سيتم الإشارة إلى أي ملف غير موجود في حقل المسار بواسطة خطأ في طرف التحدث افتراضيًا (بمعنى hull.config.general.errorChecks.virtualFolderDataPathExists true ). إن تمكين هذا المفتاح عفا عليه الزمن في الغالب لتصحيح الأخطاء ، ويوافق على تعطيل هذا الخيار والفشل بجد على مراجع مسار الملف غير الموجود. | false | true |
render | خيارات للتأثير على كيفية قيام بدن بإحضار الأشياء مثل YAML. يحتوي فقط على الحقول الفرعية التالية: emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | إذا كان true ، فإن هال يطرح annotations: {} إذا لم تكن هناك تعليقات توضيحية لكائن ، إذا false حذف مفتاح annotations . | false | true |
render.emptyLabels | إذا كان true ، فإن Hull يقوم بإخراج labels: {} إذا لم تكن هناك علامات لكائن ، إذا تم حذف labels false | false | true |
render.emptyTemplateAnnotations | إذا كان true ، فإن Hull تطرح annotations: {} في template جراب في حالة عدم وجود تعليقات على كائن ، إذا تم false مفتاح annotations . | false | true |
render.emptyTemplateLabels | إذا كان true ، فإن Hull يقوم بإخراج labels: {} في template القرون if no labels exist for an object, if تم حذف مفتاح the . | false | true |
render.emptyHullObjects | إذا كان true ، فإن هال يطرح صفائف كصفائف فارغة في حالة عدم وجود عناصر لبعض الحقول التي تتم معالجتها بواسطة هال. إذا كان خطأ ، فإن زوج القيمة المفتاح هو ammited.يؤثر هذا على الحقول التي يتم تعيينها من قاموس في تكوين الهيكل إلى صفيف Kubernetes في YAML المقدمة. فيما يلي قائمة بالحقول المتأثرة في تكوين كائن Hull:
| false | true |
postRender | بعد أن جعل Hull كائنًا بالكامل ، من الممكن معالجة سلسلة YAML الناتجة. يتم توفير إمكانيات للقيام بذلك كإجراءات postRender هنا.تحذير: توخي الحذر لأن هذا قد يفسد بنية YAML! | ||
postRender.globalStringReplacements | قاموس إمكانيات الاستبدال التي يمكن تطبيقها على YAML الكائن المقدم. تتمثل حالة الاستخدام الرئيسية لهذا في تركيبة مع التخلف الواسع في _HULL_OBJECT_TYPE_DEFAULT_ مثيلات كائن sources حيث يسمح بحقن الأوتار المحددة للمثيل في yaml الافتراضي. قد يتم enabled: true عند الطلب. يتكون كل تعيين من الحقول التالية:
| ||
postRender.globalStringReplacements.instanceKey | إذا enabled ، فسيتم استبدال قيمة string بمثابة instance_key الفعلي كما في hull.objects.<object_type>.<instance_key> . قيمة replacement هي OBJECT_INSTANCE_KEY لهذا التعيين. | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | إذا enabled ، فسيتم استبدال قيمة string بـ instance_key الفعلي كما في hull.objects.<object_type>.<instance_key> أو بواسطة hull.objects.<object_type>.<instance_key>.metadataNameOverride إذا تم تحديد ذلك. قيمة replacement هي OBJECT_INSTANCE_KEY_RESOLVED لهذا التعيين. | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | إذا enabled ، فسيتم استبدال قيمة string بالبيانات metadata.name التي تم تقديمها للكائن الفعلي. قيمة replacement هي OBJECT_INSTANCE_NAME لهذا التعيين. | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | خيارات التسلسل العام. | ||
serialization.configmap.enabled | إذا enabled ، يتم تسلسل ملحقات الملف المعينة تحت fileExtensions مع طريقة التسلسل المعطى بشكل افتراضي. إذا انتهى مفتاح data بأحد الامتدادات المعينة ، فسيتم استخدام طريقة التسلسل في القيمة لكتابة المحتوى إلى السلسلة. يقوم حقل serialization معين على إدخال data ConfigMaps في الكتابة فوق أي إعدادات افتراضية. | true | |
serialization.configmap.fileExtensions | قاموس التعيينات من ملحقات الملف إلى طرق التسلسل. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | إذا enabled ، يتم تسلسل ملحقات الملف المعينة تحت fileExtensions مع طريقة التسلسل المعطى بشكل افتراضي. إذا انتهى مفتاح data بأحد الامتدادات المعينة ، فسيتم استخدام طريقة التسلسل في القيمة لكتابة المحتوى إلى السلسلة. يقوم حقل serialization محدد على إدخال data الأسرار في الكتابة فوق أي إعدادات افتراضية. | true | |
serialization.secret.fileExtensions | قاموس التعيينات من ملحقات الملف إلى طرق التسلسل. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | التبديل العالمي الذي يمكّن كائنات RBAC للتثبيت.false true الإطلاق.كائنات RBAC التي يمكن نشرها هي: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | حقل النموذج المجاني في حين أن الحقول الفرعية لهذا الحقل يجب أن يكون لها معنى محدد بوضوح في سياق جناح المنتج الخاص بك. على سبيل المثال ، افترض أن جميع منتجاتك أو الخدمات الدقيقة (كل منها قادم كخطط هائلة منفصلة) يعتمد على نفس نقاط النهاية المحددة (المصادقة ، التكوين ، ...). قد يكون لديك وظيفة kubernetes مشتركة تنفذها كل مخطط هيلم يستهدف نقاط النهاية هذه. يمكنك الآن تحديد values.yaml بدن خارجية. yaml تحتوي على مواصفات الوظيفة وتعريف نقطة النهاية هنا بطريقة ترى values.yaml تراكبًا وإنشاءها. | {} | |
config.general.metadata | ستتم إضافة حقول البيانات الوصفية المحددة هنا تلقائيًا إلى جميع الكائنات البيانات الوصفية. يحتوي فقط على الحقول الفرعية التالية: labelsannotations | ||
config.general.metadata.labels | الملصقات التي تتم إضافتها إلى جميع الكائنات. تشير الملصقات common إلى Kubernetes و Helm Common Labels والعلامات custom يمكن تحديدها بحرية.يحتوي فقط على الحقول الفرعية التالية: commoncustom | ||
config.general.metadata.labels.common | مواصفات الملصقات الشائعة على النحو المحدد في https://helm.sh/docs/chart_best_practices/labels/ و https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/. ما لم يتم الكتابة بشكل خاص مع القيم الفارغة ( '' ) يتم إضافة جميع ملصقات البيانات الوصفية تلقائيًا إلى جميع الكائنات وفقًا لتعريفها الافتراضي. يجب مراعاة ذلك لتعيين قيمة لـ config.general.metadata.labels.common.'app.kubernetes.io/part-of' إذا كان مخطط Helm جزءًا من مجموعة منتجات. | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | تديرها البيانات الوصفية. | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | نسخة بيانات التعريف. | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | جزء من البيانات الوصفية. | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | اسم البيانات الوصفية. | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | بيانات البيانات الوصفية. | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | بيانات البيانات الوصفية. | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | قيادة القياس. | `{{(printf" ٪ s- ٪ s ".chart.name .Chart.Version) | استبدال "+" "_"}} ` |
config.general.metadata.labels.custom | تتم إضافة جميع الملصقات المخصصة المحددة تلقائيًا إلى جميع الكائنات من مخطط القمامة هذا. | {} | |
config.general.metadata.annotations | التعليقات التوضيحية التي تتم إضافتها إلى جميع الكائنات. يمكن تحديد الملصقات custom بحرية.يحتوي فقط على الحقول الفرعية التالية: custom . | ||
config.general.metadata.annotations.custom | تتم إضافة جميع التعليقات التوضيحية المخصصة المحددة تلقائيًا إلى جميع كائنات الرسم البياني لهذا القمامة. | {} | |
config.specific | حقل النموذج المجاني الذي يحمل خيارات التكوين المخصصة للمنتج المحدد الموجود في مخطط Helm. عادةً ما يجب استخدام القيم المحددة هنا لملء محتويات ملفات التكوين التي تقرأها تطبيقات معينة من تكوينها عند بدء التشغيل. وبالتالي ، يتم عادةً استهلاك الحقول config.specific بالتكوين. | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects تمثل أنواع الكائنات ذات المستوى الأعلى أسفل hull.objects أنواع كائنات Kubernetes المدعومة التي قد ترغب في إنشاء مثيلات منها. كل نوع كائن هو قاموس حيث تكون قيم الإدخالات هي خصائص الكائنات وكل كائن يحتوي على مفتاح خاص به وهو فريد من نوعه لنوع الكائن الذي ينتمي إليه. يمكن إضافة المزيد من أنواع كائنات K8S حسب الحاجة إلى المكتبة حتى يمكن تمديدها بسهولة.
أحد الجوانب المهمة هو أنه بالنسبة لجميع أنواع الكائنات ذات المستوى الأعلى ، يتم دائمًا تحديد مثيلات نوع معين بواسطة مفتاح فريد من نوعه لمجموعة مثيل نوع الكائن. ومع ذلك ، يمكن استخدام نفس المفتاح لحالات أنواع الكائنات المختلفة.
من خلال وجود مفاتيح تحدد الحالات التي يمكنك:
قم بدمج خصائص الكائنات متعددة الطبقات عن طريق تكديس values.yaml . ملفات yaml فوق بعضها البعض. قد تبدأ بتحديد بنية الكائن الافتراضية للتطبيق أو الخدمة الصغيرة المحددة في مخطط Helm المحدد. ثم يمكنك إضافة values.yaml طبقة yaml لبيئة معينة مثل التدريج أو الإنتاج. ثم يمكنك إضافة values.yaml طبقة yaml لبيانات الاعتماد. وهلم جرا. 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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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
| HULL Object Type | HULL ملكيات | Kubernetes/External ملكيات |
|---|---|---|
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.
