hull
hull-demo-1.31.2
Dieses Repository enthält das Hull Helm Library -Diagramm. Es ist so konzipiert, dass die Erstellung, die Verwaltung und Konfiguration von Kubernetes -Objekten in Helm -Diagrammen erleichtert wird, und kann in jedem Helm -Diagramm als Addon hinzugefügt werden, um die Funktionalität zu verbessern, ohne dass das Risiko für das Brechen vorhandener Helm -Diagrammkonfigurationen verstärkt wird.
Das Diagramm selbst und die gesamte Dokumentation, die sich darauf bezieht, finden Sie im hull , der der Stammordner des Hull Library Helm -Diagramms ist.
Die Kubernetes-API-JSON-Schemas werden im Ordner kubernetes-json-schema gespeichert.
Unten finden Sie die Rumpfdiagramme README.md :
Abstraktionen müssen aufrechterhalten werden - Kelsey Hightower
Ein wichtiger Konstruktionsaspekt von Helm ist, dass er den Benutzer dazu zwingt, einzelne Abstraktionen der Kubernetes -Konfiguration von Anwendungen zu erstellen. Für jedes einzelne Helmdiagramm, das in Form von YAML -Vorlagen in einem Ordner Helm -Diagramme /templates realisiert wird. Diese Vorlagendateien, die einerseits Boilerplate Kubernetes values.yaml -Codeblöcke enthalten . Dieser Ansatz der Abstraktion von Per-Anwendung ist wohl gut geeignet, um maßgeschneiderte Konfigurationspakete für selbst für die spezialisiertesten Anwendungen zu erstellen. Das Erstellen, Aufrechterhalten und (oft) das Erstellen der durch Helm -Diagramme eingeführten Abstraktionen - insbesondere bei einer hohen Anzahl einzelner Helm -Diagramme aus verschiedenen Quellen - kann mühsam und herausfordernd werden.
Die primäre Funktion der Hull -Bibliothek ist die Möglichkeit, angepasste YAML -Vorlagendateien vollständig aus Helm -Diagramm -Workflows zu entfernen und damit eine Abstraktionsebene zu entfernen. Unter Verwendung des Hull Library -Diagramms können Kubernetes -Objekte einschließlich aller ihrer Eigenschaften vollständig und transparent in den values.yaml angegeben werden. Das Hull -Bibliothek -Diagramm selbst bietet die einheitliche Ebene zur Stromleitung, Konfiguration und Rendering von Helmdiagrammen, um dies zu erreichen. Sie können es auch als eine dünne Schicht oben auf der Kubernetes -API betrachten, um den Mittelsmann zwischen dem Helm -Diagramm und der Kubernetes -API -Objektkonfiguration zu vermeiden. Wenn Sie jedoch Flexibilität bieten, müssen Sie einzelne Konfigurationsoptionen anpassen, anstatt Sie jeden Konfigurationsschalter hinzuzufügen müssen manuell zu den Vorlagen. JSON -Schema -Validierung basierend auf der Helm JSON -Validierungsfunktion (über values.schema.json ) hilft beim Schreiben von Kubernetes -API -API -Objekten von Anfang an, wenn eine IDE verwendet wird, die das Live -JSON -Schema -Validierung unterstützt. Zusätzliche Vorteile (einheitliche vererbbare Objektmetadaten, vereinfachte Einbeziehung von configMaps/Geheimnissen, Querverweiswerte innerhalb der values.yaml Yaml, ...) sind mit Rumpf erhältlich, über die Sie unten im Überblick über die wichtigsten Funktionen lesen können. Am wichtigsten ist jedoch, dass die Hull-Bibliothek als Abhängigkeit zu jedem vorhandenen Helm-Diagramm hinzugefügt werden kann und nebeneinander verwendet werden kann, ohne vorhandenen Helm-Diagrammenfunktionen zu brechen. Weitere Informationen finden Sie in einem Helm-Diagramm in ein Helm-Diagramm. Und schließlich funktioniert alles, indem er selbst ein Bibliotheksdiagramm ist, alles zu 100% innerhalb der Funktionalität, die einfach Helm bietet - es werden keine zusätzlichen Werkzeuge eingeführt oder involviert.
Ihr Feedback zu diesem Projekt wird bewertet. Daher kommentieren Sie eine Diskussion im Abschnitt Issues oder erstellen Sie Feature -Wünsche und Fehlerberichte. Danke schön!
Die Idee der Hull Library -Diagramm -Idee ist teilweise vom gemeinsamen Helm -Diagramm -Konzept und zum Testen inspiriert
.
hull-demo -Diagramm Bevor Sie in die Details von Hull eintauchen, gibt es einen ersten Einblick in die Funktionsweise. Sie können einfach die neueste Version des hull-demo Helm-Diagramms aus dem Abschnitt "Releases" dieser Seite herunterladen. Es hat alles, was Rumpf getestet hat oder ein neues Helm-Diagramm auf der Grundlage von Hull mit minimalem Aufwand eingerichtet wird.
Das hull-demo Diagramm wickelt eine fiktive Anwendungs myapp mit einem frontend und backend Bereitstellungs- und -dienstpaar ein. Es gibt eine Konfigurationsdatei für die Serverkonfiguration, die an den backend Pods montiert ist. Die frontend -Pods müssen über die backend -Serviceadresse über Umgebungsvariablen informiert werden. Darüber hinaus sollte das Setup standardmäßig leicht von einem debug -Setup (mit einem Nodeport zum Zugriff auf das Frontend) auf ein produktionsähnliches Setup (mit einem Clusterip-Service und einer Einschaltung) umschaltbar sein.
Eine bloße Standardstruktur, um diese Aspekte zu erfassen, kann so aussehen (mit zusätzlichen Zeilenkommentaren zur Erläuterung):
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 Dies ist das Beispiel, das als hull-demo hull-demo values.yaml darstellt.
helm template hull-demo-<version>.tgz
Es macht eine Reihe von Objekten, die auf den obigen values.yaml basieren. Yaml enthält:
myapp-frontend mit einem zentral konfigurierten Bild- tag Set (standardmäßig v23.1 ) und Umgebungsvariablen, die auf den Service-In-Cluster-Service des myapp-backend zeigenmyapp-backend mit einem zentral konfigurierten Bild- tag Set (standardmäßig v23.1 ) und eine Konfiguration, die aus der myappconfig -Konfiguration montiert istmyappconfig -Konfiguration mit einer JSON -Datei, die dynamisch erstellt wird, indem Templating -Ausdrücke und Werte an anderer Stelle in values.yaml definiert werden.YAMLmyapp-backend Bereitstellungdebug Service-Fronting myapp-frontend ClusterIP , myapp Typ- und Portkonfiguration vom zentralen debug Switch abhängt NodePortmyapp , der nur gerendert/erstellt wird, falls das debug: false festgelegt wird Jeder Aspekt dieser Konfiguration kann mithilfe zusätzlicher values.yaml geändert oder überschrieben werden.
debug -Modus nach Einstellungen debug: true oder debug: falsemyapp configMaps ( rate_limit und max_connections ) oder überschreiben Sie sie vollständig Alle Objekte und Logik wurden mit unter hundert Zeilen des Gesamtkonfigurationscodes in den values.yaml des hull-demo erstellt.yaml. Sie können alle oben genannten Aspekte testen oder einfach experimentieren, indem Sie zusätzliche values.yaml hinzufügen. Yaml -Overlay -Dateien zum Befehl helm template oben. Um Ihr eigenes Helm -Diagramm zu starten, leeren Sie einfach die values.yaml Yaml -Konfiguration, benennen Sie den Ordner der Diagramme und name in Chart.yaml um. Yaml in alles, was Sie wollen, und Sie sind bereit zu gehen.
Dies ist eine erste Demo, wie Hull verwendet werden könnte, aber es gibt viel mehr Funktionen und unterstützte Anwendungsfälle. Weitere Informationen finden Sie in den wichtigsten Funktionen und der detaillierten Dokumentation.
Wie oben hervorgehoben, kann das Hull -Bibliotheksdiagramm bei Einbeziehung in ein Helm -Diagramm die Aufgabe der dynamischen Rendern von Kubernetes -Objekten aus ihren angegebenen Spezifikationen aus den values.yaml übernehmen.YAML -Datei allein. Mit YAML -Objektkonstruktion, die in die GO -Vorlagenfunktionen der Hull Library anstelle von benutzerdefinierten YAML -Vorlagen im Ordner /templates -Ordner aufgeschoben werden, können Sie die Best Practices zentral durchsetzen:
Konzentrieren Sie sich auf das, was benötigt wird, um Kubernetes -Objekte anzugeben, ohne Ihrem Diagramm einzelne YAML -Vorlagen mit Kesselplatten hinzufügen zu müssen. Dadurch wird eine gemeinsame Quelle für Fehler und Wartung aus dem regulären Helm -Workflow entfernt. Damit der Rumpf aus der Kubernetes -API -Spezifikation entspricht, bestätigt eine große Anzahl von Unit -Tests den rendernden Ausgang gegen das Kubernetes -API -JSON -Schema.
Weitere Informationen finden Sie in der Dokumentation zur JSON -Schema -Validierung.
Für alle von Hull unterstützten Kubernetes -Objekttypen ist der vollständige Konfigurationszugriff auf die Eigenschaften von Kubernetes -Objekttypen direkt verfügbar . Dadurch wird die Chart -Wardierer von den Karten von fehlenden Konfigurationsoptionen nacheinander und den Helm -Diagramm -Benutzern aus dem Helm -Diagramm hinzugefügt, um nur die Eigenschaften hinzuzufügen, die sie für ihre Konfiguration benötigen. Das Aktualisieren des Hull -Diagramms in einer neueren Version mit passender Kubernetes -API -Version ist erforderlich, um die Konfiguration von Eigenschaften zu aktivieren, die Kubernetes -Objekten in neueren API -Versionen hinzugefügt werden. Die Rumpfdiagramme werden versioniert, um die von ihnen unterstützten minimalen Kubernetes -API -Versionen widerzuspiegeln.
Weitere Informationen finden Sie in der Dokumentation zum Überblick über die Architektur.
Die einzelne Schnittstelle der Hull -Bibliothek wird verwendet, um Objekte in Diagrammen für die Bereitstellung zu erstellen und zu konfigurieren. Dies fördert das gegenseitige Verständnis von Chart -Erstellern/-institatoren und Verbrauchern darüber, wie das Diagramm tatsächlich funktioniert und was es enthält. Das Graben in den Ordner /templates , um die Auswirkungen der Helmdiagramme zu verstehen, ist nicht mehr erforderlich. Um eine Misskonfiguration zu vermeiden, ist die Schnittstelle zur Bibliothek - die values.yaml der Hull -Bibliothek - vollständig validiert. Wenn Sie eine IDE verwenden, die eine Live -JSON -Schema -Validierung (z. B. VSCODE) unterstützt, können Sie beim Erstellen der Rumpfobjekte eine IDE -Anleitung erhalten. Vor der Rendern wird die JSON -Schema -Konformität durch die Hull -Bibliothek validiert.
Weitere Informationen finden Sie in der Dokumentation zur JSON -Schema -Validierung.
Einheitliche und reichhaltige Metadaten werden automatisch an alle von der Rumpfbibliothek erstellten Objekte angeschlossen.
Weitere Informationen zum Metadaten -Überschreiben finden Sie im folgenden erweiterten Beispiel.
Flexible Handhabung von configMap und geheimen Eingaben durch Auswahl zwischen Inline -Inhaltspezifikation in values.yaml . Beim Importieren von Daten aus Dateien können die Daten entweder über die Templating-Engine ausgeführt oder nicht geschaltet "wie" ist ", wenn sie bereits Vorlagenausdrücke enthält, die an die konsumierende Anwendung weitergegeben werden müssen. Mit einem Fokus auf bequeme Handhabung von Standardszenarien können Sie auch Dateiinhalte als reguläre YAML -Struktur in den values.yaml definieren. YAML und lassen sie sich automatisch mit JSON oder YAML nach der Dateierweiterung oder zu einer Erklärung Ihrer Wahl serialisieren. Hull kümmert sich um die Basis64 -Codierung von Geheimnissen, sodass das Schreiben von ConfigMaps und Geheimnissen genauso funktioniert, und das Hinzufügen von Konfigurationen oder Geheimnissen zu Ihrer Bereitstellung erfordert nur wenige Codezeilen.
Weitere Informationen finden Sie in der Dokumentation zu ConfigMaps und Geheimnissen.
Umfangreiche Verwerfungsfähigkeiten für die Instanziierung von Objektinstanzen. Unabhängig davon, ob alle Ihre Objektinstanzen oder Gruppen von Instanzen bestimmte Aspekte wie Beschriftungen oder Anmerkungen, Containerumgebungsvariablen oder montierte Volumina teilen möchten, bietet Hull Unterstützung, um Standardwerte für Objektinstanzfelder effizient zu definieren, die unnötige Konfigurationsrepetitionen vermeiden.
Weitere Informationen finden Sie in den Ratschlägen zur Diagrammdesign.
Für komplexere Szenarien, in denen die tatsächlichen Werte in der Ziel -YAML -Konfigurationen in den values.yaml unterliegen. Yaml. Es wird unterstützt, dass die Werte dynamisch bevölkern, indem GO -Templating -Ausdrücke anstelle des Wertes in den values.yaml definiert werden.YAML . Wenn beispielsweise Ihre Argumente für konkrete Container von verschiedenen anderen Einstellungen in values.yaml abhängen. Yaml Sie können die Bedingungen in die Berechnung der Argumente injizieren oder einfach auf andere Felder in den values.yaml verweisen.YAML.
Weitere Informationen finden Sie in der Dokumentation zu Transformationen.
Aktivieren Sie das automatische Hashing von ReferenzconfigMaps und Geheimnissen, um den POD -Neustart bei Änderungen der Konfiguration bei Bedarf zu erleichtern.
Weitere Informationen finden Sie in der Dokumentation zu Pods.
Weitere Informationen über die allgemeine Architektur und Merkmale der Hull Library finden Sie in der Architekturübersicht
Einige wichtige Dinge zuerst zu erwähnen, bevor Sie sich die Bibliothek genauer ansehen:
/templates wird durch die Integration des Hull -Bibliotheks -Diagramms völlig unberührt. Manchmal haben Sie möglicherweise sehr spezifische Anforderungen an Ihre Konfiguration oder Objektspezifikation, die sich die Rumpfbibliothek nicht erfüllt, sodass Sie den regulären Helm -Workflow für sie und die Hull -Bibliothek für Ihre Standardanforderungen verwenden können - problemlos im selben Helm -Diagramm.
hull.yaml , ohne Änderung von einem eingebetteten Hull-Diagramm-Root-Ordner zu den übergeordneten Diagrammen /templates -Ordnern kopiert werden muss, um YAML über Hull zu rendern. Es enthält den Code, der die Render -Rendering -Pipeline initiiert. Weitere Informationen finden Sie in einem Helm -Diagramm in ein Helm -Diagramm!
3.0.x nicht mit Rumpf kompatibel sind, alle anderen derzeit vorhandenen Nicht-Beta- und Nicht-Alpha-Versionen kompatibel sind.
1.29 und 1.30 und 1.31 eine passende und aufrechterhaltene Hull -Version.
Wenn Sie einen praktischen Ansatz mögen, sind Sie eingeladen, sich die New Hull Tutorials -Serie bei Dev.TO zu werfen! Das Tutorial des Eigenteils beginnt von Anfang an, um Helm einzurichten und ein Hull -basiertes Diagramm zu erstellen, um ein reales Helm -basierter Helm -Diagramm von Helm -Basis Schritt für Schritt zu füllen. Um die Unterschiede zum regulären Helm-Diagramm-Workflow hervorzuheben, nehmen die Tutorials das beliebte kubernetes-dashboard Helm-Diagramm als Quelle und transportieren es zu einem funktional äquivalenten Helm-Basis-Diagramm. Am Ende zeigt es, dass die Reduzierung der Konfigurationslinien für das Erstellen und Warteln um mehr als 50% reduziert werden kann, wenn ein rumpfbasierter Ansatz anstelle des regulären Helmstils des Schreibens von Diagrammen verwendet wird!
Die Aufgaben zum Erstellen und Konfigurieren eines Helm -Basis -Helm -Diagramms können als zwei Seiten derselben Münze angesehen werden. Beide Seiten interagieren mit derselben Schnittstelle (der Rumpfbibliothek), um die erstellten Objekte anzugeben. Die Aufgabe aus der Perspektive der Schöpfer/Wartenden besteht in erster Linie darin, die Bodenstruktur für die Objekte bereitzustellen, aus denen die jeweilige Anwendung aus besteht, die in ein Helmdiagramm eingewickelt werden soll. Der Verbraucher des Diagramms ist beauftragt, seinen systemspezifischen Kontext angemessen in die Bodenstruktur hinzuzufügen, in der er die Freiheit hat, Objekte zu ändern und sogar hinzuzufügen oder zu löschen, um seine Ziele zu erreichen. Zum Zeitpunkt der Bereitstellung der Erstellungsbasisstruktur wird mit der systemspezifischen YAML-Datei der Verbraucher zusammengeführt, um die vollständige Konfiguration zu erstellen. Das Interagieren über dieselbe Bibliotheksschnittstelle fördert das gemeinsame Verständnis der Arbeit mit der Bibliothek auf beiden Seiten und kann die meisten mühsamen Kopier- und Einfügen der Erstellung und Prüfung schwerer Konfigurationsprozesse beseitigen.
Alles, was benötigt wird, um ein Helm -Diagramm zu erstellen, das auf Rumpf basiert, ist eine Standard -Verzeichnisstruktur für das Helm -Diagramm. Fügen Sie das Hull Library-Diagramm als Unterchart hinzu, kopieren Sie den hull.yaml aus dem Hull Library-Diagramm in Ihre übergeordneten Helm-Diagramme /templates . Konfigurieren Sie dann einfach die Standardobjekte für die Bereitstellung über die values.yaml und Sie sind fertig. Es gibt keine Begrenzung, wie viele Objekte von welchem Typ Sie für Ihr Bereitstellungspaket erstellen.
Neben der Definition komplexerer Anwendungen mit Rumpf können Sie sie auch verwenden, um einfache Kubernetes-Objekte einzuwickeln, die Sie sonst entweder über Kubectl bereitstellen würden (ohne die Managementperspektive mit Helm-Releases aus dem Management) oder eine erhebliche Menge an schreiben müssen Helm -Kesselplattenvorlagen, um dies zu erreichen.
Die Basisstruktur der values.yaml Yaml wird hier im nächsten Abschnitt angegeben. Dies bildet im Wesentlichen die einzelne Schnittstelle zum Erstellen und Verbrauch von Hull -basierten Diagrammen. Jedes Objekt wird nur erstellt, falls es in den values.yaml definiert und aktiviert ist. Yaml. Dies bedeutet, dass Sie möglicherweise Objekte für Verbraucher vorkonfigurieren möchten, die sie nur aktivieren müssten, wenn sie sie verwenden möchten.
Auf der oberen Ebene der YAML -Struktur unterscheidet Hull zwischen config und objects . Während die config mit spezifischen Einstellungen für Diagramme wie Metadaten und Produkteinstellungen abwickelt, werden die zu verwendeten Beton Kubernetes-Objekte unter dem Schlüsselschlüssel objects angegeben. Eine zusätzliche Taste der dritten Top -Ebene mit dem Namen version ist ebenfalls zulässig. Wenn diese auf die Hull -Diagramm -Version festgelegt wird vidispine.hull/version z. Das wurde verwendet, um die Objekte zu rendern.
config Innerhalb des config können Sie allgemeine Einstellungen für Ihr Helm -Diagramm konfigurieren. Es ist in zwei Unterabschnitte unterteilt, config.general und config.specific .
config.general Im Gegensatz zum Bereich config.specific , der mit willkürlichen Daten gefüllt werden sollte, die nur für ein einzelnes Helmdiagramm spezifisch sind, sollte der config.general Abschnitt verwendet werden, um alles zu definieren, was für eine eindeutige Anwendung nicht spezifisch ist. Einerseits enthält es Konfigurationsoptionen, die für alle Hull -basierten Diagramme relevant sind, aber auch Platz unter der config.general.data Eintrag, um Ihre eigenen Datenfelder zu definieren, die idealerweise in anderen Helm -Diagrammen auf die gleiche Weise modelliert werden. Wenn beispielsweise mehrere Anwendungen in einer Produktsuite von denselben Endpunkten abhängen, können Sie diese Endpunkte unter der general.data -Eigenschaft in allen relevanten Diagrammen einheitlich modellieren und damit Ihre Helm -Diagramm -Schnittstelle mit z. B. einer kontinuierlichen Bereitstellungspipeline auf die gleiche Weise haben.
config.general hat nur die folgenden Unterfelder:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| Parameter | Beschreibung | Standard | Beispiel |
|---|---|---|---|
nameOverride | Der Name Override wird auf Werte von metadata label app.kubernetes.io/name angewendet. Wenn festgelegt wird, ersetzt dies den Diagrammnamen hier. | ||
fullnameOverride | Wenn ein Wert auf einen Wert gesetzt ist, wird der Vollname-Überschreibung als Präfix auf alle Objektnamen angewendet und das Standard <release>-<chart> Präfix-Muster in den Objektnamen ersetzt. | myapp | |
namespaceOverride | Wenn auf einen Wert festgelegt wird, wird der Namespace aller erstellten Objekte auf diesen Wert festgelegt. Wenn dies nicht definiert ist, wird der Namespace aller Objektinstanzen in den Release -Namespace standardmäßig dem jeweiligen Helm -Befehl bereitgestellt. | my-namespace | |
noObjectNamePrefixes | Wenn die Objektinstanzschlüssel direkt als Namen für die erstellten Kubernetes -Objekte dienen und niemals vorangestellt werden. Dies entspricht technisch dem Einstellen staticName true in jedem Objekt. Beachten Sie, dass durch die true des Werts von config.general.fullnameOverride irrelevant wird. | false | true |
createImagePullSecretsFromRegistries | Wenn es wahr ist, werden Bild -Pull -Geheimnisse aus allen in diesem Helm -Diagramm definierten Registrierungen erstellt und zu allen Pods hinzugefügt. | true | false |
globalImageRegistryServer | Wenn dies nicht leer ist, wird das registry aller image auf den hier angegebenen Wert eingestellt. Die Einstellung von config.general.globalImageRegistryToFirstRegistrySecretServer wird ignoriert, wenn dieses Feld nicht leer ist. Alle definierten explizite registry für ein image werden mit diesem Wert überschrieben.Die beabsichtigte Verwendung davon besteht darin, alle Bilder bequem aus einer zentralen Docker-Registrierung im Falle von luftunterschiede Bereitstellungsszenarien gezogen zu haben. Entgegen der Festlegung von globalImageRegistryToFirstRegistrySecretServer auf true wird das Registrierungsgeheimnis in diesem Fall typischerweise außerhalb dieses Helm -Diagramms definiert, und der Server des Registrierungsgeheimnisses wird mit seinem Namen direkt verwiesen. Wenn Sie diese Funktion verwenden und das Geheimnis der Docker -Registrierung außerhalb dieses Helm -Diagramms definieren, müssen Sie Ihren Schoten zusätzlich imagePullSecrets hinzufügen, falls die referenzierte Docker -Registrierung nicht unsicher ist. | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | Wenn wahr und globalImageRegistryServer leer sind, wird das registry aller image auf das server des ersten gefundenen registry eingestellt. Beachten Sie, dass dies die Registrierung mit dem niedrigsten alphanumerischen Schlüsselnamen ist, wenn Sie mehrere registry angeben. Sollte normalerweise zusammen mit der Einstellung createImagePullSecretsFromRegistries von der Einstellung von true verwendet werden, um von autopopulierten imagePullSecrets zu profitieren und registry entsprechend festzulegen. Explizite registry für ein image werden mit diesem Wert überschrieben.Die beabsichtigte Nutzung dieser Einstellung besteht darin, alle Bilder bequem aus einer zentralen Docker-Registrierung im Falle von luftverletzungsähnlichen Bereitstellungsszenarien gezogen zu haben. | false | true |
errorChecks | Optionen, die feststellen, in welchem Fällen Rumpf einen Fehler bei helm install oder helm template erzeugt. Weitere Informationen finden Sie auch in der detaillierten Dokumentation zum Konfigurieren von FehlerprüfungenHat nur die folgenden Unterfelder: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | Bestätigen Sie, dass kein gebrochener Yaml gerendert wird | true | |
errorChecks.hullGetTransformationReferenceValid | _HT* values.yaml | true | |
errorChecks.containerImageValid | containers initContainers pod image repository | true | |
errorChecks.virtualFolderDataPathExists | path Sie data | true | |
errorChecks.virtualFolderDataInlineValid | null data inline | false | |
debug | Optionen, die beim Debuggen von Diagrammproblemen helfen können. Meistens veraltet und ersetzt durch sprechende Standardfehlermeldungen, die unter errorChecks konfiguriert sind.Hat nur die folgenden Unterfelder: renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | Global Switch, der bei aktivierter Ausdruck eine Zeichenfolge ausdruckt:HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not foundeinschließlich der _HT*/hull.util.transformation.get Referenz ( xyz ) und des fehlenden Schlüssels ( y ), wenn die Transformation auf einen nicht vorhandenen Wörterbuchschlüssel verweist. Dies ist nützlich, um das Rendering von Diagrammen zu debuggen und die Suche nach kaputten Referenzen zu reduzieren, da die Installation normalerweise einen Fehler bei zerbrochenen Referenzen abbricht (was es schwierig macht, die problematischen Referenzen (en) zu pinieren).NOTIZ: Inzwischen wird eine kaputte GET -Referenz durch einen sprechenden Helmfehler standardmäßig signalisiert, sodass dieser Switch für die Debugie von kaputten Referenzen hauptsächlich veraltet ist. Es ist empfohlen, diese Option zu deaktivieren und stattdessen schwer bei den fördernden Auftragsreferenzen zu scheitern und Probleme direkt aus der Fehlermeldung zu analysieren. | false | true |
debug.renderNilWhenInlineIsNil | Global Switch, der bei aktivierter Ausdruck eine Zeichenfolge ausdruckt:<nil>als data Wert, wenn auf eine inline -Spezifikation einen nil in einer Konfiguration oder einem Geheimnis verweist. Wenn auf False festgelegt wird, wird der nil -Wert als leerer Zeichenfolge im Feld configMap oder geheime data gedruckt.NOTIZ: Inzwischen werden alle ungültigen Inline -Felder standardmäßig durch einen sprechenden Helmfehler signalisiert (was hull.config.general.errorChecks.virtualFolderDataInlineValid ist true ). Das Aktivieren dieses Switch ist größtenteils veraltet für das Debuggen und wird empfohlen, diese Option zu deaktivieren und auf ungültigen Inline -Feldern zu fehlschlagen. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | Global Switch, der bei aktivierter Ausdruck eine Zeichenfolge ausdruckt:<path missing: the_missing_path>In einer Konfigurations- oder geheimen data , einschließlich des Werts the_missing_path , der nicht in eine Datei auflöst. Wenn falsch, wird der Wert data in einer leeren Zeichenfolge gelöst.NOTIZ: Inzwischen wird jede nicht existierende Datei, auf die in einem Pfadfeld verwiesen wird, durch einen standardmäßigen Sprech-Helmfehler signalisiert (dh hull.config.general.errorChecks.virtualFolderDataPathExists IST true ). Das Aktivieren dieses Switch ist größtenteils veraltet für das Debuggen und wird empfohlen, diese Option zu deaktivieren und bei nicht existierenden Dateipfadreferenzen hart zu fehlschlagen. | false | true |
render | Optionen, um zu beeinflussen, wie Rumpf Objekte als Yaml herausbringt. Hat nur die folgenden Unterfelder: emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | Wenn true , rendert Hull annotations: {} Wenn keine Annotationen für ein Objekt vorhanden sind, annotations false . | false | true |
render.emptyLabels | Wenn true , rendert Hull labels: {} Wenn keine Beschriftungen für ein Objekt vorhanden sind, wird der false der labels weggelassen. | false | true |
render.emptyTemplateAnnotations | Wenn true , rendert Hull annotations: {} in der template eines POD, wenn keine Anmerkungen für ein Objekt vorhanden sind, wenn false der annotations weggelassen wird. | false | true |
render.emptyTemplateLabels | Wenn true , rendert Hull labels: {} in der template von Pods if no labels exist for an object, if falsch the Taste "Labels" weggelassen wird. | false | true |
render.emptyHullObjects | Wenn true , rendert Hull Arrays als leere Arrays heraus, wenn für einige von Hull verarbeitete Felder keine Elemente vorhanden sind. Wenn falsch, wird das Schlüsselwertpaar verboten.Dies wirkt sich auf Felder aus, die von einem Wörterbuch in der Rumpfkonfiguration auf ein Kubernetes -Array in der gerenderten YAML abgebildet werden. Im Folgenden finden Sie eine Liste der betroffenen Felder in der Objektkonfiguration von Hull:
| false | true |
postRender | Nachdem Hull ein Objekt vollständig gemacht hat, ist es möglich, die resultierende YAML -Zeichenfolge zu manipulieren. Möglichkeiten, dies zu tun, werden hier als postRender bereitgestellt.WARNUNG: Verwenden Sie mit Vorsicht, da dies die YAML -Struktur verderben kann! | ||
postRender.globalStringReplacements | Ein Wörterbuch von Ersatzmöglichkeiten, die auf das YAML des gerenderten Objekts angewendet werden können. Der Hauptanwendungsfall hierfür ist in Kombination mit umfangreichem Aufwand in _HULL_OBJECT_TYPE_DEFAULT_ und sources Objektinstanzen, in denen es ermöglicht, Instanz spezifische Zeichenfolgen in die standardmäßige YAML zu injizieren. Die vorhandenen vorkonfigurierten Mappings können enabled: true On Demand. Jede Zuordnung besteht aus folgenden Feldern:
| ||
postRender.globalStringReplacements.instanceKey | Wenn enabled , wird der string durch den tatsächlichen Objekt instance_key wie in hull.objects.<object_type>.<instance_key> Der Wert des replacement ist OBJECT_INSTANCE_KEY für diese Zuordnung. | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | Wenn enabled , wird der string durch das tatsächliche Objekt instance_key wie in hull.objects.<object_type>.<instance_key> Oder von hull.objects.<object_type>.<instance_key>.metadataNameOverride Der Wert des replacement ist für diese Zuordnung OBJECT_INSTANCE_KEY_RESOLVED . | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | Wenn enabled , wird der string durch die rendernden metadata.name des tatsächlichen Objekts ersetzt. Der Wert des replacement ist OBJECT_INSTANCE_NAME für diese Zuordnung. | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | Allgemeine Serialisierungsoptionen. | ||
serialization.configmap.enabled | Wenn enabled , werden die zugeordneten Dateierweiterungen unter fileExtensions standardmäßig mit der angegebenen Serialisierungsmethode serialisiert. Wenn der data mit einer der zugeordneten Erweiterungen endet, wird die Serialisierungsmethode im Wert zum Schreiben des Inhalts in die Zeichenfolge verwendet. Ein spezifisches serialization in einem data überschreibt alle Standardeinstellungen. | true | |
serialization.configmap.fileExtensions | Ein Wörterbuch von Zuordnungen von Dateierweiterungen zu Serialisierungsmethoden. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | Wenn enabled , werden die zugeordneten Dateierweiterungen unter fileExtensions standardmäßig mit der angegebenen Serialisierungsmethode serialisiert. Wenn der data mit einer der zugeordneten Erweiterungen endet, wird die Serialisierungsmethode im Wert zum Schreiben des Inhalts in die Zeichenfolge verwendet. Ein spezifisches serialization für die data von Secrets überschreibt alle Standardeinstellungen. | true | |
serialization.secret.fileExtensions | Ein Wörterbuch von Zuordnungen von Dateierweiterungen zu Serialisierungsmethoden. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | Globaler Schalter, der RBAC -Objekte für die Installation ermöglicht. Wenn true alle aktivierten RBAC -Objekte im Cluster bereitgestellt werden, werden false keine RBAC -Objekte erstellt.RBAC -Objekte, die bereitgestellt werden können, sind: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | Freiformfeld, während Unterfelder dieses Feldes im Kontext Ihrer Produktsuite eine klar definierte Bedeutung haben sollten. Nehmen wir beispielsweise an, dass alle Ihre Produkte oder Microservices (jeweils als separates Helmdiagramm) von denselben gegebenen Endpunkten abhängt (Authentifizierung, Konfiguration, ...). Möglicherweise haben Sie einen gemeinsamen Kubernetes -Job, der von jedem Helm -Diagramm ausgeführt wird, das auf diese Endpunkte abzielt. Jetzt können Sie eine externe values.yaml angeben. Yaml, die die Jobspezifikation und die Endpunktdefinition hier enthalten, in einer Weise, die Sie für Anpassung sehen und eine Overlay values.yaml konstruieren. | {} | |
config.general.metadata | Definierte Metadatenfelder hier werden automatisch zu allen Objektmetadaten hinzugefügt. Hat nur die folgenden Unterfelder: labelsannotations | ||
config.general.metadata.labels | Etiketten, die zu allen Objekten hinzugefügt werden. Die common Beschriftungen beziehen sich auf die kubernetischen und helm gemeinsamen Etiketten und custom Beschriftungen können frei angegeben werden.Hat nur die folgenden Unterfelder: commoncustom | ||
config.general.metadata.labels.common | Gemeinsame Labels Spezifikation wie definiert in https://helm.sh/docs/chart_best_practices/labels/ und https://klubernetes.io/docs/concepts/overview/working-with-objects/common-labels/. Sofern nicht ausdrücklich mit leeren Werten ( '' ) überschrieben wird, werden alle Metadatenbezeichnungen nach ihrer Standarddefinition automatisch zu allen Objekten hinzugefügt. Es sollte in Betracht gezogen werden, um einen Wert für config.general.metadata.labels.common.'app.kubernetes.io/part-of' setzen, wenn das Helm-Diagramm Teil einer Produktsuite ist. | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | Von Metadaten verwaltet. | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | Versionsmetadaten. | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | Teil der Metadaten. | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | Nennen Sie Metadaten. | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | Instanzmetadaten. | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | Komponentenmetadaten. | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | Helmmetadaten. | `{{(printf"%S-%S ".Chart.Name .Chart.Version) | Ersetzen Sie "+" "_"}} ` |
config.general.metadata.labels.custom | Alle angegebenen benutzerdefinierten Beschriftungen werden automatisch zu allen Objekten dieses Helm -Diagramms hinzugefügt. | {} | |
config.general.metadata.annotations | Anmerkungen, die zu allen Objekten hinzugefügt werden. Die custom Beschriftungen können frei angegeben werden.Hat nur die folgenden Unterfelder: custom . | ||
config.general.metadata.annotations.custom | Alle angegebenen benutzerdefinierten Anmerkungen werden automatisch zu allen Objekten dieses Helm -Diagramms hinzugefügt. | {} | |
config.specific | Das Feld freier Formular, das Konfigurationsoptionen enthält, die für das im Helm -Diagramm enthaltene spezifische Produkt spezifisch sind. In der Regel sollten die hier angegebenen Werte verwendet werden, um den Inhalt von Konfigurationsdateien zu füllen, von denen eine bestimmte Anwendungen ihre Konfiguration ab dem Start lesen. Daher werden die config.specific Felder in der Regel in configMaps oder Geheimnissen verbraucht. | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects Die Objekttypen der obersten Ebene unter hull.objects stellen die unterstützten Kubernetes-Objekttypen dar, von denen Sie möglicherweise Instanzen erstellen möchten. Jeder Objekttyp ist ein Wörterbuch, bei dem die Einträge die Objekteigenschaften sind, und jedes Objekt hat seinen eigenen Schlüssel, der für den Objekttyp einzigartig ist, zu dem er gehört. Weitere K8S -Objekttypen können nach Bedarf in die Bibliothek hinzugefügt werden, damit sie leicht erweitert werden können.
Ein wichtiger Aspekt ist, dass für alle Objekttypen auf höchstem Niveau immer durch einen Schlüssel identifiziert werden, der für die Kombination aus Instanz und Objekttyp eindeutig ist. Der gleiche Schlüssel kann jedoch für Instanzen verschiedener Objekttypen verwendet werden.
Durch Schlüssel, die Instanzen identifizieren, können Sie:
Führen Sie mehrschichtige Verschmelzung von Objekteigenschaften durch Stapeln von values.yaml . Yaml-Dateien übereinander. Sie können mit der Definition der Standardobjektstruktur der Anwendung oder des Mikrodienstes beginnen, die im angegebenen Helm -Diagramm definiert sind. Dann können Sie eine values.yaml hinzufügen. Yaml -Schicht für eine bestimmte Umgebung wie Inszenierung oder Produktion. Dann können Sie eine values.yaml hinzufügen. Yaml -Schicht für Anmeldeinformationen. Und so weiter. 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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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
| RUMPF Object Type | RUMPF Eigenschaften | Kubernetes/External Eigenschaften |
|---|---|---|
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.
