Clusterkonfiguration

Kf verwendet eine Kubernetes-Configmap namens config-defaults im Namespace kf zum Speichern der clusterweiten Konfigurationseinstellungen. In diesem Dokument werden Ihre Struktur und Felder erläutert.

Struktur der Configmap "config-defaults"

Die Configmap enthält im Feld .data drei Arten von Schlüssel/Wert-Paaren:

  • Kommentarschlüssel mit dem Präfix _ enthalten Beispiele, Hinweise und Warnungen.
  • Stringschlüssel enthalten Nur-Text-Werte.
  • Objektschlüssel enthalten einen JSON- oder YAML-Wert, der als String codiert wurde.

Beispiel:

_note: "This is some note"
stringKey: "This is a string key that's not encoded as JSON or YAML."
objectKey: |
  - "These keys contain nested YAML or JSON."
  - true
  - 123.45

Beispiel-Abschnitt:

Der Beispielabschnitt unter dem Schlüssel _example enthält Erläuterungen für andere Felder und Beispiele. Änderungen an diesem Abschnitt haben keine Auswirkungen.

Space-Container Registry

Das Attribut spaceContainerRegistry ist ein reiner Textwert, der die Standard-Container Registry angibt, die jeder Bereich zum Speichern von erstellten Images verwendet.

Beispiel:

spaceContainerRegistry: gcr.io/my-project

Space-Cluster-Domains

Das Attribut spaceClusterDomains ist ein stringcodiertes YAML-Array von Domainobjekten.

Durch jeden Space im Cluster werden alle Elemente im Array der Liste der Domains hinzugefügt, an die Entwickler ihre Anwendungen binden können.

Felder
domain

string

Der bereitzustellende Domainname. Kann eine der folgenden Substitutionen enthalten:

  • $(SPACE_NAME) – In jedem Bereich ersetzt durch den Namen des Bereichs.
  • $(CLUSTER_INGRESS_IP) – Ist die IP-Adresse des Ingress-Gateways des Clusters.
gatewayName

string

Optional

Überschreibt die Istio-Gateway-Routen, an die gebunden wird. Die Standardeinstellung ist kf/external-gateway, aber es kann auch jedes andere Gateway im Namespace kf verwendet werden.

Beispiel:

spaceClusterDomains: |
  # Support canonical and vanity domains
  - domain: $(SPACE_NAME).prod.example.com
  - domain: $(SPACE_NAME).kf.us-east1.prod.example.com

  # Using a dynamic DNS resolver
  - domain: $(SPACE_NAME).$(CLUSTER_INGRESS_IP).nip.io

  # Creating an internal domain only visible within the cluster
  - domain: $(SPACE_NAME)-apps.internal
    gatewayName: kf/internal-gateway

Buildpacks V2-Lebenszyklus-Builder

Das Attribut buildpacksV2LifecycleBuilder enthält die Version der verwendeten Cloud Foundry-Binärdatei builder, die zum Ausführen von Buildpack v2-Builds verwendet wird.

Der Wert ist eine Git-Referenz. Wenn Sie eine bestimmte Version verwenden möchten, hängen Sie an das Ende ein @-Symbol gefolgt von einem Git-SHA an.

Beispiel:

buildpacksV2LifecycleBuilder: "code.cloudfoundry.org/buildpackapplifecycle/builder@GIT_SHA"

Buildpacks V2-Lebenszyklus-Launcher

Das Attribut buildpacksV2LifecycleLauncher enthält die Version der Cloud Foundry-Binärdatei launcher, die in jede Buildpack V2-Anwendung eingebaut ist.

Der Wert ist eine Git-Referenz. Wenn Sie eine bestimmte Version verwenden möchten, hängen Sie an das Ende ein @-Symbol gefolgt von einem Git-SHA an.

Beispiel:

buildpacksV2LifecycleLauncher: "code.cloudfoundry.org/buildpackapplifecycle/launcher@GIT_SHA"

Buildpacks V2-Liste

Das Attribut spaceBuildpacksV2 ist ein stringcodiertes YAML-Array, das eine geordnete Liste von Standard-Buildpacks enthält, mit denen Anwendungen erstellt werden können, die mit dem V2-Buildpacks-Ablauf kompatibel sind.

Felder
name

string

Short Name-Entwickler können in ihren Anwendungsmanifesten auf das Buildpack verweisen.

url

string

Die URL, die zum Abrufen des Buildpacks verwendet wird.

disabled

boolean

Wird verwendet, um zu verhindern, dass dieses Buildpack ausgeführt wird.

Stacks V2-Liste

Das Attribut spaceBuildpacksV2 ist ein stringcodiertes YAML-Array, das eine geordnete Liste von Stacks enthält, die mit Cloud Foundry-kompatiblen Builds verwendet werden können.

Felder
name

string

Short Name-Entwickler können in ihren Anwendungsmanifesten auf das Stack verweisen.

image

string

URL des Container-Images, das als Stack verwendet werden soll. Weitere Informationen finden Sie unter https://kubernetes.io/docs/concepts/containers/images.

Stacks V3-Liste

Das Attribut spaceStacksV3 ist ein stringcodiertes YAML-Array, das eine geordnete Liste von Stacks enthält, die mit cloud-nativen Buildpack-Builds verwendet werden können.

Felder
name

string

Short Name-Entwickler können in ihren Anwendungsmanifesten auf das Stack verweisen.

description

string

Eine kurze Beschreibung des Stacks, der beim Ausführen von kf stacks angezeigt wird.

buildImage

string

URL des Container-Images, das als Builder verwendet werden soll. Weitere Informationen finden Sie unter https://kubernetes.io/docs/concepts/containers/images.

runImage

string

URL des Container-Images, das als Basis für alle erstellten Anwendungen verwendet werden soll. Weitere Informationen finden Sie unter https://kubernetes.io/docs/concepts/containers/images.

nodeSelector

map (key: string, value: string)

Optional

Ein NodeSelector, mit dem angegeben wird, auf welchen Knoten mit diesem Stack erstellte Anwendungen ausgeführt werden können.

Beispiel:

spaceStacksV3: |
  - name: heroku-18
    description: The official Heroku stack based on Ubuntu 18.04
    buildImage: heroku/pack:18-build
    runImage: heroku/pack:18
    nodeSelector:
       kubernetes.io/os: windows

Standardeinstellung ist V3 Stack

Das Attribut spaceDefaultToV3Stack enthält einen in Anführungszeichen gesetzten Wert true oder false, der angibt, ob Bereiche bei der Verwendung von V3-Stacks verwendet werden sollen, wenn ein Nutzer keinen Wert angibt.

Funktions-Flags

Das Attribut featureFlags enthält eine stringcodierte YAML-Zuordnung mit Funktions-Flags, mit denen Funktionen von Kf aktiviert und deaktiviert werden können.

Von Kf nicht unterstützte Flag-Namen werden ignoriert.

Flag-Name Standard Zweck
disable_custom_builds false Deaktivieren Sie den Entwicklerzugriff auf beliebige Tekton-Build-Pipelines.
enable_dockerfile_builds true Entwicklern erlauben, Quellcode aus Docker-Dateien zu erstellen.
enable_custom_buildpacks true Entwicklern erlauben, externe Buildpacks in ihren Anwendungen anzugeben.
enable_custom_stacks true Entwicklern erlauben, in ihren Anwendungen benutzerdefinierte Stacks anzugeben.

Beispiel:

featureFlags: |
  disable_custom_builds: false
  enable_dockerfile_builds: true
  enable_some_feature: true