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.

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.

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.

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.

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.

Beispiel:

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