hull
hull-demo-1.31.2
พื้นที่เก็บข้อมูลนี้มีแผนภูมิห้องสมุด Hull Helm มันถูกออกแบบมาเพื่อความสะดวกในการสร้างการบำรุงรักษาและกำหนดค่าวัตถุ Kubernetes ในชาร์ต Helm และสามารถเพิ่มลงในแผนภูมิ Helm ใด ๆ เป็นส่วนเสริมเพื่อเพิ่มฟังก์ชั่นการทำงานโดยไม่เสี่ยงต่อการกำหนดค่าแผนภูมิ Helm ที่มีอยู่
แผนภูมิตัวเองและเอกสารทั้งหมดที่เกี่ยวข้องสามารถพบได้ในโฟลเดอร์ hull ซึ่งเป็นโฟลเดอร์รูทของแผนภูมิ Hull Library Helm
Schemas Kubernetes API JSON ถูกเก็บไว้ในโฟลเดอร์ kubernetes-json-schema
ด้านล่างนี้คือ Hull Charts README.md :
abstractions จำเป็นต้องได้รับการดูแล - Kelsey Hightower
การออกแบบที่สำคัญอย่างหนึ่งของหางเสือคือมันบังคับให้ผู้ใช้สร้าง abstractions แต่ละตัวของการกำหนดค่า Kubernetes ของแอปพลิเคชัน สำหรับแผนภูมิ Helm แต่ละตัวที่รับรู้ในรูปแบบของแม่แบบ Yaml ในโฟลเดอร์ชาร์ต /templates Helm ไฟล์เทมเพลตเหล่านี้ที่มี boilerplate kubernetes บล็อกรหัส YAML ในมือข้างหนึ่งและการแมปการกำหนดค่าที่กำหนดเองโดยใช้การแสดงออกของเทมเพลต GO ในทางกลับกันให้กาวระหว่างการกำหนดค่าของแอปพลิเคชันผ่าน values.yaml กลาง . วิธีการที่เป็นนามธรรมต่อแอปพลิเคชันนี้เหมาะอย่างยิ่งในการสร้างแพ็คเกจการกำหนดค่า tailormade สำหรับแอพพลิเคชั่นที่มีความเชี่ยวชาญมากที่สุด แต่มีค่าใช้จ่ายในการมีค่าใช้จ่ายขนาดใหญ่สำหรับกรณีการใช้บรรจุภัณฑ์ที่ง่ายขึ้น การสร้างการบำรุงรักษาและ (บ่อยครั้ง) ทำความเข้าใจกับ abstractions ที่แนะนำโดยชาร์ต Helm - โดยเฉพาะอย่างยิ่งเมื่อเผชิญกับแผนภูมิหางเสือจำนวนมากจากแหล่งต่าง ๆ - อาจกลายเป็นเรื่องน่าเบื่อและท้าทาย
คุณสมบัติหลักของไลบรารีตัวถังคือความสามารถในการลบไฟล์เทมเพลต Yaml ที่กำหนดเองทั้งหมดออกจากเวิร์กโฟลว์แผนภูมิ Helm และช่วยให้สามารถลบระดับของนามธรรมได้ การใช้แผนภูมิห้องสมุดฮัลล์วัตถุ Kubernetes รวมถึงคุณสมบัติทั้งหมดของพวกเขาสามารถระบุได้อย่างสมบูรณ์และโปร่งใสใน values.yaml แผนภูมิไลบรารีฮัลล์นั้นมีเลเยอร์เครื่องแบบเพื่อปรับปรุงข้อกำหนดการกำหนดค่าและการแสดงผลของแผนภูมิ Helm เพื่อให้ได้สิ่งนี้ นอกจากนี้คุณยังสามารถคิดว่ามันเป็นเลเยอร์บาง ๆ ที่ด้านบนของ Kubernetes API เพื่อหลีกเลี่ยง middleman ระหว่างแผนภูมิ Helm และการกำหนดค่าวัตถุ Kubernetes API แต่ให้ความยืดหยุ่นเมื่อจำเป็นต้องปรับแต่งตัวเลือกการกำหนดค่าแต่ละตัว ด้วยตนเองกับเทมเพลต การตรวจสอบความถูกต้องของ JSON Schema ตามคุณสมบัติการตรวจสอบความถูกต้องของ Helm JSON (ผ่าน values.schema.json ) ช่วยในการเขียน Kubernetes API ที่สอดคล้องกับวัตถุตั้งแต่ต้นเมื่อใช้ IDE ที่รองรับการตรวจสอบสคีมา JSON สด ประโยชน์เพิ่มเติม (ข้อมูลเมตาวัตถุที่สืบทอดมาได้แบบสม่ำเสมอการรวมการกำหนดค่า/ความลับที่ง่ายขึ้นค่าการอ้างอิงข้ามภายใน values.yaml , ... ) มีให้บริการกับฮัลล์ซึ่งคุณสามารถอ่านเกี่ยวกับด้านล่างใน ภาพรวมคุณสมบัติคีย์ แต่บางทีที่สำคัญที่สุดคือห้องสมุดตัวถังสามารถเพิ่มขึ้นเป็นแบบพึ่งพาแผนภูมิหางเสือที่มีอยู่และใช้แบบเคียงข้างกันโดยไม่ทำลายฟังก์ชันการทำงานของ Helm ที่มีอยู่ใด ๆ ดูที่การเพิ่มแผนภูมิ Hull Library ลงในแผนภูมิ Helm สำหรับข้อมูลเพิ่มเติม และสุดท้ายโดยการเป็นแผนภูมิห้องสมุดเองทุกอย่างทำงานได้ 100% ภายในฟังก์ชั่นที่ Helm ธรรมดาเสนอ - ไม่มีการแนะนำเครื่องมือเพิ่มเติมหรือเกี่ยวข้อง
ความคิดเห็นของคุณเกี่ยวกับโครงการนี้มีมูลค่าดังนั้นโปรดแสดงความคิดเห็นหรือเริ่มการสนทนาในส่วน Issues หรือสร้างความปรารถนาและรายงานข้อผิดพลาด ขอบคุณ!
แนวคิดแผนภูมิห้องสมุดฮัลล์ได้รับแรงบันดาลใจจากแนวคิดแผนภูมิ Helm ทั่วไปและสำหรับการทดสอบ
-
hull-demo ก่อนที่จะดำน้ำในรายละเอียดของฮัลล์นี่คือแวบแรกในการทำงาน คุณสามารถดาวน์โหลดแผนภูมิ hull-demo Helm เวอร์ชันล่าสุดได้จากส่วนเผยแพร่ของหน้านี้มันมีทุกอย่างที่บูตสำหรับการทดสอบฮัลล์หรือตั้งค่าแผนภูมิ Helm ใหม่ตามฮัลล์ด้วยความพยายามน้อยที่สุด
แผนภูมิ hull-demo ห่อแอปพลิเคชั่นตัวละครของ myapp ด้วยการปรับ frontend และแบ็ก backend และคู่บริการ มีไฟล์กำหนดค่าสำหรับการกำหนดค่าเซิร์ฟเวอร์ที่ติดตั้งกับพ็ backend ด์ ฝัก frontend จำเป็นต้องรู้เกี่ยวกับที่อยู่บริการ backend ผ่านตัวแปรสภาพแวดล้อม ยิ่งไปกว่านั้นการตั้งค่าควรสลับได้อย่างง่ายดายจากการตั้งค่า debug (โดยใช้ nodeport สำหรับการเข้าถึงส่วนหน้า) ไปยังการตั้งค่าแบบผลิต (โดยใช้บริการ Clusterip และ Ingress)
โครงสร้างเริ่มต้นที่เปลือยเปล่าเพื่อจับภาพด้านเหล่านี้อาจมีลักษณะเช่นนี้ (พร้อมความคิดเห็นบรรทัดเพิ่มเติมสำหรับคำอธิบาย):
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 Release และ Execute ล่าสุด:
helm template hull-demo-<version>.tgz
มันแสดงชุดวัตถุตาม values.yaml ข้างต้น yaMl ที่มี:
myapp-frontend ที่มีชุด tag รูปภาพที่กำหนดค่าไว้จากส่วนกลาง (โดยค่าเริ่มต้น v23.1 ) และตัวแปรสภาพแวดล้อมที่ชี้ไปที่บริการของ myapp-backend ที่อยู่ในคลัสเตอร์myapp-backend ที่มีชุด tag รูปภาพที่กำหนดค่าไว้จากส่วนกลาง (โดยค่าเริ่มต้น v23.1 ) และการกำหนดค่าที่ติดตั้งจาก myappconfig configmapmyappconfig configmap พร้อมไฟล์ JSON ที่สร้างขึ้นแบบไดนามิกโดยการรวมการแสดงออกของเทมเพลตและค่าการอ้างอิงที่กำหนดไว้ที่อื่นใน values.yamlmyapp-backendmyapp-frontend ซึ่งมีประเภทและการกำหนดค่าพอร์ตขึ้นอยู่กับสวิตช์ debug กลาง-ประเภท NodePort ในโหมดการตั้งค่า debug หรือประเภท ClusterIP ร่วมกับ myapp ingress ในการตั้งค่าที่ไม่ใช่การถอดmyapp ซึ่งแสดงผล/สร้างขึ้นในกรณีที่มีการตั้งค่าค่า debug: false ทุกแง่มุมของการกำหนดค่านี้สามารถเปลี่ยนแปลงหรือเขียนทับเมื่อเวลาการปรับใช้โดยใช้ values.yaml เพิ่มเติมไฟล์ซ้อนทับไฟล์เช่น:
debug โดยการตั้งค่า debug: true หรือ debug: falsemyapp configmaps ( rate_limit และ max_connections ) หรือเขียนทับอย่างสมบูรณ์ วัตถุและตรรกะทั้งหมดถูกสร้างขึ้นด้วยรหัสการกำหนดค่าโดยรวมภายใต้ร้อยบรรทัดใน values.yaml ของ hull-demo คุณสามารถทดสอบทุกแง่มุมที่กล่าวถึงข้างต้นหรือเพียงแค่ทดสอบโดยการเพิ่ม values.yaml เพิ่มเติมไฟล์ซ้อนทับไฟล์ไปยังคำสั่ง helm template ด้านบน สำหรับ bootstrapping แผนภูมิ Helm ของคุณเองเพียงแค่ล้างค่าการกำหนด values.yaml เปลี่ยนชื่อโฟลเดอร์และ name ใน Chart.yaml เป็นสิ่งที่คุณต้องการและคุณพร้อมที่จะไป
นี่เป็นตัวอย่างแรกของวิธีการใช้ฮัลล์ แต่มีฟังก์ชันการใช้งานมากขึ้นและใช้กรณีการใช้งานที่รองรับ ตรวจสอบคุณสมบัติที่สำคัญและเอกสารรายละเอียดสำหรับข้อมูลเพิ่มเติม
ดังที่ได้กล่าวไว้ข้างต้นเมื่อรวมอยู่ในแผนภูมิหางเสือแผนภูมิฮัลล์ไลบรารีสามารถเข้ามามีส่วนร่วมในการแสดงผลของวัตถุ Kubernetes แบบไดนามิกจากข้อกำหนดที่กำหนดจากไฟล์ values.yaml . yaml เพียงอย่างเดียว ด้วยการก่อสร้างวัตถุ Yaml รอการตัดบัญชีไปยังฟังก์ชั่นเทมเพลต GO ของ Hull Library แทนเทมเพลต Yaml ที่กำหนดเองในโฟลเดอร์ /templates คุณสามารถบังคับใช้แนวทางปฏิบัติที่ดีที่สุดได้จากส่วนกลาง:
มุ่งเน้นไปที่สิ่งที่จำเป็นในการระบุวัตถุ Kubernetes โดยไม่ต้องเพิ่มเทมเพลต Yaml Boilerplate แต่ละตัวลงในแผนภูมิของคุณ สิ่งนี้จะลบแหล่งที่มาของข้อผิดพลาดและการบำรุงรักษาจากเวิร์กโฟลว์ Helm ปกติ หากต้องการให้ฮัลล์แสดงผลออกตามข้อกำหนดของ Kubernetes API การทดสอบหน่วยจำนวนมากตรวจสอบความถูกต้องของฮัลล์ที่แสดงผลต่อ Kubernetes API JSON Schema
สำหรับรายละเอียดเพิ่มเติมอ้างอิงเอกสารเกี่ยวกับการตรวจสอบความถูกต้องของ JSON Schema
สำหรับประเภทวัตถุ Kubernetes ทั้งหมดที่รองรับโดย Hull การเข้าถึงการกำหนดค่าแบบเต็มรูปแบบคุณสมบัติประเภทวัตถุ Kubernetes จะพร้อมใช้งานโดยตรง สิ่งนี้จะช่วยบรรเทาผู้ดูแลแผนภูมิไม่ต้องเพิ่มตัวเลือกการกำหนดค่าที่ขาดหายไปทีละคนและผู้ใช้แผนภูมิ Helm จากการออกแผนภูมิ Helm เพื่อเพิ่มคุณสมบัติที่พวกเขาต้องการสำหรับการกำหนดค่าของพวกเขา การอัปเดตแผนภูมิตัวถังเป็นเวอร์ชันใหม่ที่มีรุ่น Kubernetes API ที่ตรงกันจะต้องเปิดใช้งานการกำหนดค่าคุณสมบัติที่เพิ่มลงในวัตถุ Kubernetes ในขณะเดียวกันในรุ่น API รุ่นใหม่ ชาร์ตฮัลล์มีรูปแบบเพื่อสะท้อนให้เห็นถึงรุ่น Kubernetes API ที่รองรับโดยพวกเขา
สำหรับรายละเอียดเพิ่มเติมอ้างอิงเอกสารเกี่ยวกับภาพรวมสถาปัตยกรรม
อินเทอร์เฟซเดียวของไลบรารีตัวถังใช้ในการสร้างและกำหนดค่าวัตถุในแผนภูมิสำหรับการปรับใช้ สิ่งนี้ส่งเสริมความเข้าใจร่วมกันของผู้สร้างแผนภูมิ/ผู้ดูแลและผู้บริโภคว่าแผนภูมิทำงานอย่างไรและมีสิ่งที่มีอยู่ การขุดลงในโฟลเดอร์ /templates เพื่อทำความเข้าใจกับความหมายของแผนภูมิ Helm ไม่จำเป็นอีกต่อไป เพื่อหลีกเลี่ยงการกำหนดค่าผิดพลาดใด ๆ อินเทอร์เฟซไปยังไลบรารี - values.yaml ของไลบรารีฮัลล์ - ได้รับการตรวจสอบอย่างสมบูรณ์ JSON เมื่อใช้ IDE ที่รองรับการตรวจสอบความถูกต้องของ JSON Schema (เช่น VSCODE) คุณจะได้รับคำแนะนำ IDE เมื่อสร้างวัตถุฮัลล์ ก่อนการเรนเดอร์ JSON Schema Conformance จะได้รับการตรวจสอบโดย Hull Library
สำหรับรายละเอียดเพิ่มเติมอ้างอิงเอกสารเกี่ยวกับการตรวจสอบความถูกต้องของ JSON Schema
เมตาดาต้าที่สม่ำเสมอและเข้มข้นจะถูกแนบมาโดยอัตโนมัติกับวัตถุทั้งหมดที่สร้างโดยไลบรารีตัวถัง
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการเขียนทับข้อมูลเมตาอ้างอิงตัวอย่างขั้นสูงด้านล่าง
การจัดการที่ยืดหยุ่นของ configmap และอินพุตลับโดยเลือกระหว่างข้อกำหนดอินไลน์ของเนื้อหาใน values.yaml หรือนำเข้าจากไฟล์ภายนอกสำหรับเนื้อหาที่มีขนาดใหญ่ขึ้น เมื่อนำเข้าข้อมูลจากไฟล์ข้อมูลสามารถเรียกใช้ผ่านเอ็นจิ้นเทมเพลตหรือนำเข้า un-templated 'เช่นเดียวกับ' ถ้ามันมีการแสดงออกของ templating ที่จะถูกส่งต่อไปยังแอปพลิเคชันที่บริโภค ด้วยการมุ่งเน้นไปที่การจัดการสถานการณ์มาตรฐานที่สะดวกคุณยังสามารถกำหนดเนื้อหาไฟล์เป็นโครงสร้าง YAML ปกติใน values.yaml และให้ตัวถังเป็นอนุกรมโดยอัตโนมัติไปยัง JSON หรือ YAML โดยส่วนขยายไฟล์หรืออธิบายการเป็นตัวแทนของคุณ ฮัลล์ดูแลการเข้ารหัส Base64 ของความลับดังนั้นการเขียน configmaps และความลับทำงานในลักษณะเดียวกันและ เพิ่ม configmaps หรือความลับในการปรับใช้ของคุณต้องใช้รหัสเพียงไม่กี่บรรทัด
สำหรับรายละเอียดเพิ่มเติมอ้างอิงเอกสารเกี่ยวกับ configmaps และความลับ
ความสามารถในการเริ่มต้นที่กว้างขวางสำหรับอินสแตนซ์วัตถุอินสแตนซ์ ไม่ว่าคุณต้องการมีอินสแตนซ์วัตถุทั้งหมดของคุณหรือกลุ่มของอินสแตนซ์แบ่งปันบางแง่มุมเช่นป้ายกำกับหรือคำอธิบายประกอบตัวแปรสภาพแวดล้อมคอนเทนเนอร์หรือปริมาณที่ติดตั้งฮัลล์ให้การสนับสนุนเพื่อกำหนดค่าเริ่มต้นอย่างมีประสิทธิภาพสำหรับฟิลด์อินสแตนซ์วัตถุเพื่อหลีกเลี่ยงการกำหนดค่าการกำหนดค่าที่ไม่จำเป็น
สำหรับรายละเอียดเพิ่มเติมอ้างถึงคำแนะนำการออกแบบแผนภูมิ
สำหรับสถานการณ์ที่ซับซ้อนมากขึ้นซึ่งค่าที่แท้จริงในเป้าหมาย YAML นั้นอยู่ภายใต้การกำหนดค่าใน values.yaml มี การสนับสนุนค่าที่เติมแบบไดนามิกโดยการฉีด GO templating นิพจน์ที่กำหนดไว้ในสถานที่ของค่าในค่า. values.yaml ตัวอย่างเช่นหากอาร์กิวเมนต์คอนกรีตคอนกรีตของคุณขึ้นอยู่กับการตั้งค่าอื่น ๆ ใน values.yaml คุณสามารถฉีดเงื่อนไขลงในการคำนวณอาร์กิวเมนต์หรือเพียงอ้างอิงฟิลด์อื่น ๆ ใน values.yaml
สำหรับรายละเอียดเพิ่มเติมอ้างถึงเอกสารเกี่ยวกับการแปลง
เปิดใช้งานการแฮชอัตโนมัติของการกำหนดค่าและความลับที่อ้างอิงเพื่ออำนวยความสะดวกในการรีสตาร์ท POD ในการเปลี่ยนแปลงการกำหนดค่าเมื่อจำเป็น
สำหรับรายละเอียดเพิ่มเติมอ้างถึงเอกสารเกี่ยวกับพ็อด
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับสถาปัตยกรรมทั่วไปและคุณสมบัติของห้องสมุดฮัลล์ดูภาพรวมสถาปัตยกรรม
บางสิ่งสำคัญที่จะพูดถึงก่อนที่จะดูห้องสมุดโดยละเอียดเพิ่มเติม:
/templates นั้นไม่ได้รับผลกระทบอย่างสมบูรณ์โดยการรวมแผนภูมิของฮัลล์ไลบรารี บางครั้งคุณอาจมีข้อกำหนดเฉพาะเกี่ยวกับการกำหนดค่าหรือข้อมูลจำเพาะวัตถุของคุณซึ่งไลบรารีตัวถังไม่ตรงตามดังนั้นคุณสามารถใช้เวิร์กโฟลว์หางเสือปกติสำหรับพวกเขาและไลบรารีฮัลล์สำหรับความต้องการมาตรฐานมากขึ้น - ง่ายในแผนภูมิหางเสือเดียวกัน
hull.yaml จะต้องคัดลอก 'as-is' โดยไม่ต้องดัดแปลงใด ๆ จากโฟลเดอร์รากฮัลล์ที่ฝังตัวไปยังโฟลเดอร์ชาร์ต /templates หลักเพื่อให้สามารถแสดง Yaml ผ่านฮัลล์ มันมีรหัสที่เริ่มต้นไปป์ไลน์การเรนเดอร์ฮัลล์ดูการเพิ่มแผนภูมิห้องสมุดตัวถังลงในแผนภูมิหางเสือเพื่อดูรายละเอียดเพิ่มเติม!
3.0.x ไม่สามารถใช้งานได้กับฮัลล์ซึ่งเป็นรุ่นอื่น ๆ ที่ไม่ใช่เบต้าและไม่ใช่อัลฟ่าในปัจจุบันทั้งหมดที่มีอยู่ในปัจจุบันนั้นเข้ากันได้
1.29 และ 1.30 และ 1.31 มีการจับคู่และบำรุงรักษาฮัลล์
ถ้าคุณชอบวิธีการที่คุณได้รับเชิญให้ดูซีรี่ส์บทช่วยสอนฮัลล์ใหม่ที่ dev.to! บทช่วยสอนส่วน Eigth จะเริ่มต้นจากจุดเริ่มต้นของการตั้งค่าหางเสือและสร้างแผนภูมิที่ใช้ตัวถังเพื่อสรุปการทำแผนภูมิฮัลล์ในชีวิตจริงทีละขั้นตอน เพื่อเน้นความแตกต่างของเวิร์กโฟลว์แผนภูมิ Helm ปกติบทช่วยสอนนำแผนภูมิ Helm kubernetes-dashboard ยอดนิยมเป็นแหล่งที่มาและส่งไปยังแผนภูมิหางเสือที่ใช้ฟังก์ชันฮัลล์ ในที่สุดมันก็แสดงให้เห็นว่าการลดบรรทัดของการกำหนดค่าเพื่อสร้างและบำรุงรักษาสามารถลดลงได้มากกว่า 50% เมื่อใช้วิธีการที่ใช้ตัวถังแทนรูปแบบการเขียนแผนภูมิปกติ!
งานของการสร้างและกำหนดค่าแผนภูมิหางเสือที่ใช้ฮัลล์ถือเป็นสองด้านของเหรียญเดียวกัน ทั้งสองฝ่ายโต้ตอบกับอินเทอร์เฟซเดียวกัน (ไลบรารีฮัลล์) เพื่อระบุวัตถุที่ควรสร้าง ภารกิจจากมุมมองของผู้สร้าง/ผู้ดูแลเป็นสิ่งสำคัญที่สุดในการจัดทำโครงสร้างพื้นดินสำหรับวัตถุที่ประกอบขึ้นเป็นแอปพลิเคชันเฉพาะซึ่งจะถูกห่อหุ้มในแผนภูมิหางเสือ ผู้บริโภคของแผนภูมิได้รับมอบหมายให้เพิ่มบริบทเฉพาะระบบของเขาลงในโครงสร้างภาคพื้นดินอย่างเหมาะสมซึ่งเขามีอิสระในการเปลี่ยนแปลงและเพิ่มหรือลบวัตถุตามความจำเป็นเพื่อให้บรรลุเป้าหมายของเขา เมื่อเวลาปรับใช้โครงสร้างฐานผู้สร้างจะถูกรวมเข้ากับไฟล์ YAML เฉพาะระบบของผู้บริโภคเพื่อสร้างการกำหนดค่าที่สมบูรณ์ การโต้ตอบผ่านอินเตอร์เฟสห้องสมุดเดียวกันช่วยส่งเสริมความเข้าใจร่วมกันเกี่ยวกับวิธีการทำงานกับห้องสมุดทั้งสองด้านและสามารถกำจัดการสร้างสำเนาและการสร้างที่น่าเบื่อและการตรวจสอบและการตรวจสอบกระบวนการกำหนดค่าหนัก
ดังนั้นสิ่งที่จำเป็นในการสร้างแผนภูมิหางเสือตามฮัลล์คือโครงสร้างไดเรกทอรี Helm Starded Standard เพิ่มแผนภูมิไลบรารีฮัลล์เป็นแผนภูมิย่อยคัดลอก hull.yaml จากแผนภูมิ Hull Library ไปยังโฟลเดอร์ Helm /templates ของคุณ จากนั้นเพียงกำหนดค่าวัตถุเริ่มต้นเพื่อปรับใช้ผ่าน values.yaml และคุณทำเสร็จแล้ว ไม่มีการ จำกัด จำนวนวัตถุที่คุณสร้างขึ้นสำหรับแพ็คเกจการปรับใช้ของคุณ
แต่นอกเหนือจากการอนุญาตให้กำหนดแอพพลิเคชั่นที่ซับซ้อนมากขึ้นด้วยฮัลล์แล้วคุณยังสามารถใช้มันเพื่อห่อวัตถุ Kubernetes อย่างง่ายที่คุณจะใช้งานผ่าน Kubectl เทมเพลต Helm Boilerplate เพื่อให้ได้สิ่งนี้
โครงสร้างพื้นฐานของ values.yaml ที่เข้าใจโดยฮัลล์จะได้รับที่นี่ในส่วนถัดไป สิ่งนี้เป็นส่วนหนึ่งของอินเทอร์เฟซเดียวสำหรับการผลิตและการบริโภคแผนภูมิที่ใช้ตัวถัง วัตถุใด ๆ ถูกสร้างขึ้นเฉพาะในกรณีที่มีการกำหนดและเปิดใช้งานใน values.yaml ซึ่งหมายความว่าคุณอาจต้องการกำหนดค่าวัตถุล่วงหน้าสำหรับผู้บริโภคที่ต้องการเปิดใช้งานหากพวกเขาต้องการใช้
ที่ระดับบนสุดของโครงสร้าง YAML ฮัลล์แยกความแตกต่างระหว่าง config และ objects ในขณะที่การกำหนดค่าย่อยการ config มีวัตถุประสงค์เพื่อจัดการกับการตั้งค่าเฉพาะของแผนภูมิเช่นเมตาดาต้าและการตั้งค่าผลิตภัณฑ์วัตถุคอนกรีต Kubernetes ที่จะแสดงผลจะถูกระบุภายใต้คีย์ objects อนุญาตให้ใช้ version ระดับสูงสุดที่สามที่ชื่อได้เช่นกันเมื่อตั้งค่าเป็นรุ่น Hull vidispine.hull/version เช่นระหว่างการเปิดตัวแผนภูมิการเปิดตัวของผู้ปกครอง ที่ใช้เพื่อแสดงผลวัตถุ
config ภายในส่วน config คุณสามารถกำหนดค่าการตั้งค่าทั่วไปสำหรับแผนภูมิ Helm ของคุณ มันถูกแบ่งออกเป็นสองส่วนย่อย config.general และ config.specific
config.general ในทางตรงกันข้ามกับส่วน config.specific ซึ่งควรมีการเติมข้อมูลโดยพลการซึ่งเฉพาะเจาะจงเฉพาะกับแผนภูมิ Helm เดียวส่วน config.general ควรใช้เพื่อกำหนดทุกอย่างที่ไม่เฉพาะเจาะจงสำหรับแอปพลิเคชันที่ไม่ซ้ำกัน ในอีกด้านหนึ่งมันมีตัวเลือกการกำหนดค่าซึ่งเกี่ยวข้องกับแผนภูมิที่ใช้ฮัลล์ทั้งหมด แต่ยังออกจากห้องภายใต้ config.general.data รายการเพื่อกำหนดเขตข้อมูลข้อมูลของคุณเอง ตัวอย่างเช่นหากแอพพลิเคชั่นหลายรายการในชุดผลิตภัณฑ์ขึ้นอยู่กับจุดสิ้นสุดเดียวกันคุณสามารถจำลองจุดสิ้นสุดเหล่านี้ได้อย่างสม่ำเสมอภายใต้คุณสมบัติ general.data ในแผนภูมิที่เกี่ยวข้องทั้งหมด
config.general มีเพียงฟิลด์ย่อยต่อไปนี้:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| พารามิเตอร์ | คำอธิบาย | ค่าเริ่มต้น | ตัวอย่าง |
|---|---|---|---|
nameOverride | การแทนที่ชื่อถูกนำไปใช้กับค่าของเมทาดาทาฉลาก app.kubernetes.io/name หากตั้งค่านี้ได้อย่างมีประสิทธิภาพแทนที่ชื่อแผนภูมิที่นี่ | ||
fullnameOverride | หากตั้งค่าเป็นค่าการแทนที่ FullName จะถูกนำไปใช้เป็นคำนำหน้ากับชื่อวัตถุทั้งหมดและแทนที่มาตรฐาน <release>-<chart> รูปแบบคำนำหน้าในชื่อวัตถุ | myapp | |
namespaceOverride | หากตั้งค่าเป็นค่าเนมสเปซของวัตถุที่สร้างขึ้นทั้งหมดจะถูกตั้งค่าเป็นค่านี้ หากสิ่งนี้ไม่ได้กำหนดไว้เนมสเปซของอินสแตนซ์วัตถุทั้งหมดจะเริ่มต้นไปยังเนมสเปซรีลีสที่ให้ไว้กับคำสั่ง HELM ที่เกี่ยวข้อง | my-namespace | |
noObjectNamePrefixes | หากตั้งค่าปุ่มอินสแตนซ์ของวัตถุจะทำหน้าที่โดยตรงเป็นชื่อสำหรับวัตถุ Kubernetes ที่สร้างขึ้นและไม่เคยถูกนำหน้า นี่คือเทคนิคเทียบเท่ากับการตั้งค่า staticName จริงในแต่ละวัตถุ โปรดทราบว่าโดยการตั้งค่าสิ่งนี้เป็น true ค่าของ config.general.fullnameOverride จะไม่เกี่ยวข้อง | false | true |
createImagePullSecretsFromRegistries | หากเป็นจริงความลับของการดึงภาพจะถูกสร้างขึ้นจากการลงทะเบียนทั้งหมดที่กำหนดไว้ในแผนภูมิ Helm นี้และถูกเพิ่มเข้าไปในพ็อดทั้งหมด | true | false |
globalImageRegistryServer | หากไม่ล้างฟิลด์ registry ของฟิลด์ image คอนเทนเนอร์ทั้งหมดจะถูกตั้งค่าเป็นค่าที่กำหนดไว้ที่นี่ การตั้งค่าของ config.general.globalImageRegistryToFirstRegistrySecretServer จะถูกละเว้นหากฟิลด์นี้ไม่ว่างเปล่า การตั้ง registry ที่ชัดเจนทั้งหมดที่กำหนดไว้สำหรับ image จะถูกเขียนทับด้วยค่านี้การใช้งานที่ตั้งใจไว้คือการดึงรูปภาพทั้งหมดออกจากรีจิสทรีนักเทียบท่ากลางในกรณีที่มีช่องว่างทางอากาศเช่นสถานการณ์การปรับใช้ ตรงกันข้ามกับการตั้งค่า globalImageRegistryToFirstRegistrySecretServer เป็น true ในกรณีนี้โดยทั่วไปแล้วรีจิสทรีความลับจะถูกกำหนดไว้นอกแผนภูมิ Helm นี้และเซิร์ฟเวอร์ของ Registry Secret ถูกอ้างอิงโดยชื่อโดยตรง หากคุณใช้คุณลักษณะนี้และกำหนดความลับของ Docker Registry นอกแผนภูมิ Helm นี้คุณอาจต้องเพิ่ม imagePullSecrets ให้กับ POD ของคุณในกรณีที่รีจิสทรี Docker ที่อ้างอิงไม่ปลอดภัย | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | หากจริงและ globalImageRegistryServer ว่างเปล่าฟิลด์ registry ของฟิลด์ image คอนเทนเนอร์ทั้งหมดจะถูกตั้งค่าเป็นฟิลด์ server ของวัตถุ registry แรกที่พบ โปรดทราบว่านี่คือรีจิสทรีที่มีชื่อคีย์ตัวอักษรและตัวเลขต่ำสุดหากคุณมี OBEJCT registry หลายรายการ โดยปกติควรใช้ร่วมกับการตั้งค่า createImagePullSecretsFromRegistries เพื่อ true ประโยชน์จาก Autopopulated imagePullSecrets และการตั้งค่า registry การตั้ง registry ที่ชัดเจนสำหรับ image ถูกเขียนทับด้วยค่านี้การใช้งานที่ตั้งใจไว้ของการตั้งค่านี้คือการดึงรูปภาพทั้งหมดออกมาจากรีจิสทรีนักเทียบท่ากลางในกรณีที่มีช่องว่างทางอากาศเช่นสถานการณ์การปรับใช้ | false | true |
errorChecks | ตัวเลือกที่กำหนดในกรณีใดที่ฮัลล์จะสร้างข้อผิดพลาดใน helm install หรือ helm template สำหรับรายละเอียดเพิ่มเติมโปรดดูเอกสารรายละเอียดเกี่ยวกับการกำหนดค่าการตรวจสอบข้อผิดพลาดมีเพียงฟิลด์ย่อยต่อไปนี้: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | ตรวจสอบว่าไม่มี Yaml เสียแล้ว | true | |
errorChecks.hullGetTransformationReferenceValid | ตรวจสอบว่าการอ้างอิง _HT* ทั้งหมดชี้ไปที่คีย์ที่มีอยู่ใน values.yaml | true | |
errorChecks.containerImageValid | ตรวจสอบว่า containers ของ pod และส่วน image initContainers ทั้งหมดมีอยู่และมีชุด repository อย่างน้อย | true | |
errorChecks.virtualFolderDataPathExists | ตรวจสอบว่าไฟล์ทั้งหมดที่ถูกอ้างถึงในฟิลด์ configmap และ data path ของ Secret นั้นมีอยู่จริง | true | |
errorChecks.virtualFolderDataInlineValid | ตรวจสอบว่าไม่มีค่า null หรือค่าที่ขาดหายไป (ซึ่งถูกแปลงเป็นสตริงว่าง) ถูกตั้งค่าสำหรับฟิลด์ข้อมูล inline data ของ CONFIGMAP และ Secret | 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 Reference ( xyz ) และคีย์ที่หายไป ( y ) หากการแปลงอ้างอิงถึงคีย์พจนานุกรมที่ไม่มีอยู่ สิ่งนี้มีประโยชน์ในการดีบักแผนภูมิการแสดงผลและลดการค้นหาการอ้างอิงที่ขาดเนื่องจากการติดตั้งโดยปกติจะยกเลิกการอ้างอิงที่มีการอ้างอิงที่ขาด (ซึ่งอาจทำให้ยากที่จะระบุจุดอ้างอิงที่เป็นปัญหา)บันทึก: เมื่อถึงตอนนี้การอ้างอิง Get Broken ใด ๆ จะถูกส่งสัญญาณโดยข้อผิดพลาดในการพูดโดยค่าเริ่มต้นดังนั้นสวิตช์นี้ส่วนใหญ่ล้าสมัยสำหรับการดีบักการอ้างอิงที่เสีย มีการแนะนำให้ปิดการใช้งานตัวเลือกนี้และล้มเหลวอย่างหนักในการอ้างอิงรับข้อมูลแทนและวิเคราะห์ปัญหาโดยตรงจากข้อความแสดงข้อผิดพลาด | false | true |
debug.renderNilWhenInlineIsNil | สวิตช์โกลบอลซึ่งหากเปิดใช้งานจะพิมพ์สตริง:<nil>เป็นค่าฟิลด์ data เมื่อสเป็ค inline อ้างอิงตัวชี้ nil ใน configmap หรือความลับ หากตั้งค่าเป็น FALSE ค่า nil จะถูกพิมพ์เป็นสตริงว่างในฟิลด์ configMap หรือ Secret dataบันทึก: ตอนนี้ฟิลด์อินไลน์ที่ไม่ถูกต้องจะถูกส่งสัญญาณโดยข้อผิดพลาดในการพูดโดยค่าเริ่มต้น (หมายถึง hull.config.general.errorChecks.virtualFolderDataInlineValid เป็น true ) การเปิดใช้งานสวิตช์นี้ส่วนใหญ่ล้าสมัยสำหรับการดีบักและได้รับการแนะนำเพื่อปิดการใช้งานตัวเลือกนี้และล้มเหลวอย่างหนักในฟิลด์อินไลน์ที่ไม่ถูกต้อง | false | true |
debug.renderPathMissingWhenPathIsNonExistent | สวิตช์โกลบอลซึ่งหากเปิดใช้งานจะพิมพ์สตริง:<path missing: the_missing_path>ในค่า configmap หรือฟิลด์ data ลับรวมถึงค่า 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 ฮัลล์จะแสดง labels: {} หากไม่มีป้ายกำกับสำหรับวัตถุถ้า false labels จะถูกละเว้น | false | true |
render.emptyTemplateAnnotations | ถ้า true ฮัลล์จะแสดง annotations: {} ใน template ของพ็อดหากไม่มีคำอธิบายประกอบสำหรับวัตถุหาก false annotations จะถูกละไว้ | false | true |
render.emptyTemplateLabels | ถ้า true ฮัลล์จะแสดง labels: {} ใน template ของพ็อด if no labels exist for an object, if the เท็จจะถูกละไว้ | false | true |
render.emptyHullObjects | ถ้า true ฮัลล์จะแสดงอาร์เรย์เป็นอาร์เรย์ที่ว่างเปล่าหากไม่มีองค์ประกอบสำหรับบางฟิลด์ที่ดำเนินการโดยฮัลล์ หากเป็นเท็จคู่คีย์-ค่าจะถูก ommitedสิ่งนี้มีผลต่อฟิลด์ที่แมปจากพจนานุกรมในการกำหนดค่าตัวถังไปยังอาร์เรย์ Kubernetes ใน Yaml ที่แสดงผล ต่อไปนี้เป็นรายการของฟิลด์ที่ได้รับผลกระทบในการกำหนดค่าวัตถุของฮัลล์:
| false | true |
postRender | หลังจากฮัลล์แสดงวัตถุอย่างเต็มที่แล้วก็เป็นไปได้ที่จะจัดการกับสตริง 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 สำหรับการติดตั้ง หาก true วัตถุ RBAC ที่เปิดใช้งานทั้งหมดจะถูกปรับใช้กับคลัสเตอร์หากไม่มีการสร้างวัตถุ RBAC false เลยวัตถุ RBAC ที่สามารถใช้งานได้คือ: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | ฟิลด์ฟอร์มฟรีในขณะที่ฟิลด์ย่อยของฟิลด์นี้ควรมีความหมายที่กำหนดไว้อย่างชัดเจนในบริบทของชุดผลิตภัณฑ์ของคุณ ตัวอย่างเช่นสมมติว่าผลิตภัณฑ์หรือ microservices ทั้งหมดของคุณ (แต่ละครั้งที่มาเป็นแผนภูมิหางเสือแยกต่างหาก) ขึ้นอยู่กับจุดสิ้นสุดเดียวกัน (การตรวจสอบการกำหนดค่า, ... ) คุณอาจมีงาน Kubernetes ที่ใช้ร่วมกันซึ่งดำเนินการโดยแต่ละแผนภูมิ Helm ซึ่งกำหนดเป้าหมายจุดสิ้นสุดเหล่านั้น ตอนนี้คุณสามารถระบุ values.yaml ฮัลล์ภายนอก YAML ที่มีข้อมูลจำเพาะของงานและคำจำกัดความจุดสิ้นสุดที่นี่ในแบบที่คุณเห็นว่าเหมาะสมและสร้าง values.yaml การซ้อนทับ YAML ที่แสดงผลด้านบนของการปรับใช้แต่ละครั้งและมีกลไกแบบครบวงจร | {} | |
config.general.metadata | ฟิลด์ข้อมูลเมตาที่กำหนดไว้ที่นี่จะถูกเพิ่มเข้าไปในข้อมูลเมตาของวัตถุทั้งหมดโดยอัตโนมัติ มีเพียงฟิลด์ย่อยต่อไปนี้: labelsannotations | ||
config.general.metadata.labels | ป้ายกำกับที่เพิ่มเข้ากับวัตถุทั้งหมด ฉลาก common อ้างถึง Kubernetes และ Helm ทั่วไปฉลากและฉลาก 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' | เมตาดาต้า Helm | `{{(printf"%s-%s ". chart.name .chart.version) | แทนที่ "+" "_"}} ` |
config.general.metadata.labels.custom | ป้ายกำกับที่กำหนดเองที่ระบุทั้งหมดจะถูกเพิ่มเข้าไปในวัตถุทั้งหมดของแผนภูมิ Helm นี้โดยอัตโนมัติ | {} | |
config.general.metadata.annotations | คำอธิบายประกอบที่เพิ่มเข้าไปในวัตถุทั้งหมด ฉลาก custom สามารถระบุได้อย่างอิสระมีเพียงฟิลด์ย่อยต่อไปนี้: custom . | ||
config.general.metadata.annotations.custom | คำอธิบายประกอบที่กำหนดเองที่ระบุทั้งหมดจะถูกเพิ่มเข้าไปในวัตถุทั้งหมดของแผนภูมิ Helm นี้โดยอัตโนมัติ | {} | |
config.specific | ฟิลด์ฟอร์มฟรีที่มีตัวเลือกการกำหนดค่าที่เฉพาะเจาะจงกับผลิตภัณฑ์เฉพาะที่มีอยู่ในแผนภูมิ Helm โดยทั่วไปค่าที่ระบุไว้ที่นี่ควรใช้เพื่อเติมเนื้อหาของไฟล์การกำหนดค่าที่แอปพลิเคชันเฉพาะอ่านการกำหนดค่าของพวกเขาจากที่เริ่มต้น ดังนั้นโดยทั่วไปแล้วฟิลด์ config.specific จะถูกใช้ใน configmaps หรือความลับ | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects ประเภทวัตถุระดับบนสุดภายใต้ hull.objects แสดงถึงประเภทวัตถุ Kubernetes ที่รองรับที่คุณอาจต้องการสร้างอินสแตนซ์จาก แต่ละประเภทวัตถุเป็นพจนานุกรมที่ค่ารายการเป็นคุณสมบัติของวัตถุและแต่ละวัตถุมีคีย์ของตัวเองซึ่งไม่ซ้ำกับประเภทวัตถุที่เป็นของ สามารถเพิ่มประเภทวัตถุ K8S เพิ่มเติมได้ตามต้องการไปยังไลบรารีเพื่อให้สามารถขยายได้อย่างง่ายดาย
สิ่งสำคัญอย่างหนึ่งคือสำหรับวัตถุประเภทชั้นบนทั้งหมดอินสแตนซ์ของประเภทใดประเภทหนึ่งจะถูกระบุโดยคีย์ซึ่งไม่ซ้ำกับการรวมกันของอินสแตนซ์และประเภทวัตถุ อย่างไรก็ตามคีย์เดียวกันสามารถใช้สำหรับอินสแตนซ์ของประเภทวัตถุที่แตกต่างกัน
โดยมีคีย์ที่ระบุอินสแตนซ์ที่คุณสามารถ:
ทำการรวมคุณสมบัติของวัตถุหลายชั้นโดยการซ้อน values.yaml ที่อยู่ด้านบนของกันและกัน คุณอาจเริ่มต้นด้วยการกำหนดโครงสร้างวัตถุเริ่มต้นของแอปพลิเคชันหรือบริการไมโครที่กำหนดไว้ในแผนภูมิ Helm ที่กำหนด จากนั้นคุณอาจเพิ่มค่า Layer values.yaml สำหรับสภาพแวดล้อมเฉพาะเช่นการจัดเตรียมหรือการผลิต จากนั้นคุณอาจเพิ่ม values.yaml Layer.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.
