diff --git a/.circleci/config.yml b/.circleci/config.yml index 768644f33..23dd08c88 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -33,7 +33,7 @@ jobs: - run: name: deploy command: | - export CUSTOM_COMMIT_MESSAGE="[ci skip] Deploy website - based on $(git rev-parse HEAD) " + export CUSTOM_COMMIT_MESSAGE="[ci skip] Deploy website - based on $(git rev-parse HEAD)" yarn deploy no_output_timeout: 2m diff --git a/docs/main/03-reference/19-kratix-config/kratix-config.md b/docs/main/03-reference/19-kratix-config/kratix-config.md index 370ed9e0c..962398c05 100644 --- a/docs/main/03-reference/19-kratix-config/kratix-config.md +++ b/docs/main/03-reference/19-kratix-config/kratix-config.md @@ -1,9 +1,13 @@ --- -description: Configuring Kratix via the Config -title: Kratix Config +description: Configuring Kratix +title: Configuring Kratix id: config --- +Kratix can be configured and customised via two ConfigMaps; Kratix Config and Kratix Pipeline Adapter Config. + +## Kratix Config + When Kratix starts, it reads the `kratix` `ConfigMap` from the `kratix-platform-system` namespace. This `ConfigMap` allow you to configure various parts of Kratix and follows the format outlined below. It is loaded when @@ -12,8 +16,6 @@ the `kratix-platform-controller-manager` pod starts within the same namespace. If any changes are made to the `ConfigMap`, you will need to restart the `kratix-platform-controller-manager` pod to apply the updated configuration. - - ```yaml apiVersion: v1 kind: ConfigMap @@ -22,38 +24,22 @@ metadata: namespace: kratix-platform-system data: config: | - - # Number of old successful pipeline pods to keep. Default is 5 - numberOfJobsToKeep: 1 - - # Selective cache for Secrets to limit memory usage. Please ensure Secrets used by Kratix are - # created with label: app.kubernetes.io/part-of=kratix. Default is false. + numberOfJobsToKeep: 5 selectiveCache: false - - # interval in which the Kratix runs the Promises/Resources workflows reconciliationInterval: "10h" - # Timeout configuration of controller's leader election. - controllerLeaderElection: leaseDuration: 15s renewDeadline: 10s retryPeriod: 2s - workflows: jobOptions: - # Number of times Kubernetes retries a failing workflow Job before marking it failed. - # Kratix does not set a default for this field, so Kubernetes uses its own - # Job default (6) if it is omitted. - defaultBackoffLimit: 4 - defaultImagePullPolicy: # can be `IfNotPresent`, `Always`, or `Never` + defaultBackoffLimit: 6 + defaultImagePullPolicy: IfNotPresent # can be `IfNotPresent`, `Always`, or `Never` defaultContainerSecurityContext: - # Security context fields, e.g.: runAsNonRoot: false - logging: level: "info" # one of info, warning, debug, trace structured: false # if true, emit logs as json - telemetry: enabled: false endpoint: grafana-k8s-monitoring-alloy-receiver.default.svc.cluster.local:4317 # exporter endpoint @@ -61,11 +47,74 @@ data: insecure: true headers: # additional headers if required authorization: "Bearer " - featureFlags: promiseUpgrade: false # enable/disable promise revisions ``` +### numberOfJobsToKeep (default: 5) + +The total number of completed Kratix workflow jobs to keep in the cluster. The oldest jobs will be deleted as new jobs are created. + +### selectiveCache (default: false) + +Enable label selector caching of Secrets on the cluster to optimise memory usage. Secrets used by Kratix must be labelled with app.`kubernetes.io/part-of=kratix`. + +### reconciliationInterval (default: 10h) + +The interval on which Kratix will re-run the Workflows for both Promises and Resources. + +### controllerLeaderElection + +Timeouts for the kratix controller's leader election. Defaults: + +- leaseDuration: 15s +- renewDeadline: 10s +- retryPeriod: 2s + +### Workflows + +Default configurations for Kratix Workflows. Any options configured within individual workflows will take precedence over those in the Kratix Config. + +#### jobOptions + +Options for the Jobs that are created by Kratix Workflows. + +##### defaultBackoffLimit + +The number of times to retry a failing workflow Job before marking it failed. This configures the [backoffLimit](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) in Workflow Jobs. This will default to the Kubernetes Job default of 6. + +#### defaultImagePullPolicy + +When to pull the images specified in Workflows. This configures the [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#updating-images) in Workflow Jobs. Can be `IfNotPresent`, `Always`, or `Never` + +#### defaultContainerSecurityContext + +The [Security Context](/main/reference/workflows#security-context) to apply to all Workflow Pods. + +### logging + +Logging configuration for the Kratix Controller Manager pod logs. + +#### level (default: "info") + +The log level. Can be "info", "warning", "debug" or "trace" + +#### structured (default: false) + +Set to true to emit logs as json. + +### telemetry + +Telemetry configuration for Kratix. + +### featureFlags + +Enable Kratix features. These are disabled by default. + +#### promiseUpgrade (default: false) + +Enable the use of Promise Revision and Resource Bindings to manage Resource upgrades. + ## Kratix Pipeline Adapter Config When Kratix schedules work as part of either Promise or Resource workflows, diff --git a/docs/main/05-learn-more/02-kratix-resources.mdx b/docs/main/05-learn-more/02-kratix-resources.mdx index 0a2aed55e..c424a9f95 100644 --- a/docs/main/05-learn-more/02-kratix-resources.mdx +++ b/docs/main/05-learn-more/02-kratix-resources.mdx @@ -11,7 +11,7 @@ In this page, we explore what those objects are. There are two categories of Objects that Kratix creates: 1. The Objects it needs to execute the Workflows. -1. The Objects that represent the Workflows output. +1. The Objects that represent the Workflows' output. The diagram below shows all of the Objects Kratix creates. We dive deeper into what they are used for later. @@ -80,7 +80,7 @@ Apart from the `status-writer`, all containers are actually set as `initContaine ::: -Kratix creates a new Job every time a new workflow needs to be executed. You can control the number of Jobs that Kratix keeps by setting `numberOfJobsToKeep` in the [Kratix Config](/main/reference/kratix-config/config) document. +Kratix creates a new Job every time a new workflow needs to be executed. You can control the number of Jobs that Kratix keeps by setting `numberOfJobsToKeep` in the [Kratix Config](/main/reference/kratix-config/config). You can also configure how many times a failing workflow Job is retried by setting `backoffLimit` in the same ConfigMap. Kratix does not provide a default value for this field. ## Output Objects