The introduction of bootstrap parameters in KubeVela controller are listed as below
|Use Admission Webhook
|The directory of Admission Webhook cert/secret
|The address of Admission Webhook
|The address of Prometheus metrics
|Enable Leader Election for Controller Manager and ensure that only one replica is active
|The namespace of Leader Election ConfigMap
|The log file path
|The maximum size (MBi) of log files
|Set the logging level to DEBUG, used in develop environment
|The maximum number of application revisions to keep. When the number of revisions exceeeds this number, older version will be discarded
|The maximum number of definition revisions to keep
|Generate WorkloadDefinition for ComponentDefinition automatically
|The address of health check
|Disable internal capabilities
|The storage driver for applications
|Re-sync period for application to re-sync, also known as the state-keep interval.
|The re-sync period for informer in controller-runtime. This is a system-level configuration.
|The timeout for controller reconcile.
|The namespace for storing system definitions
|The number of threads that controller uses to process requests
|The QPS for controller to access apiserver
|The burst for controller to access apiserver
|The version of OAM spec to use
|The address of pprof, default to be emtpy to disable pprof
|Enable performance logging, working with monitoring tools like Loki and Grafana to discover performance bottleneck
|Enable multi cluster feature
|the maximal backoff interval for workflow to retry when workflow step is waiting (unit: second)
|the maximal backoff interval for workflow to retry when workflow step fails (unit: second)
|the maximal retry times for workflow to retry when workflow step fails
|the timeout for controller reconcile
|graceful period for terminating reconcile
Other parameters not listed in the table are old parameters used in previous versions, the latest version ( v1.1 ) does not use them.
- application-re-sync-period: The resync time of applications when no changes were made. A short time may cause controller to reconcile frequently but uselessly. The regular reconciles of applications can help ensure that application and its components keep up-to-date in case some unexpected differences.
- concurrent-reconciles: The number of threads to use for controller to handle requests. When rich CPU resources are available, a small number of working threads may lead to insufficient usage of CPU resources.
- kube-api-qps / kube-api-burst: The rate limit for KubeVela controller to access apiserver. When managed applications are complex (containing multiple components and resources), if the access rate of apiserver is limited, it will be hard to increase the concurrency of KubeVela controller. However, high access rate may cause huge burden to apiserver. It is critical to keep a balance when handling massive applications.
- pprof-addr: The pprof address to enable controller performance debugging.
- perf-enabled: Use this flag if you would like to check time costs for different stages when reconciling applications. Switch it off to simplify loggings.
Several sets of recommended parameter configurations are enclosed in section Performance Fine-tuning.
You can use
--feature-gates=XXX=true to enable feature
XXX. There are a list of feature gates allow you to enable advanced features or alpha features.
- AuthenticateApplication: enable the authentication for application.
- ZstdResourceTracker: enables the zstd compression for ResourceTracker. It can be useful if you have large application that needs to dispatch lots of resources or large resources (like CRD or huge ConfigMap), which at the cost of slower processing speed due to the extra overhead for compression and decompression. Default to true.
- ZstdApplicationRevision: enables the zstd compression for ApplicationRevision. Similar to ZstdResourceTracker, this can help save the storage space greatly. Default to true.
- ApplyOnce: enable the apply-once feature for all applications. If enabled, no StateKeep will be run, ResourceTracker will also disable the storage of all resource data, only metadata will be kept.
- MultiStageComponentApply: enable multi-stage feature for component. If enabled, the dispatch of manifests is performed in batches according to the stage.
- ApplyResourceByUpdate: enforces the modification of resource through update requests. If not set, the resource modification will use patch requests (three-way-strategy-merge-patch). The side effect of enabling this feature is that the request traffic will increase due to the increase of bytes transferred and the more frequent resource mutation failure due to the potential conflicts. If set, KubeVela controller will enforce strong restriction on the managed resource that external system would be unable to make modifications to the KubeVela managed resource. In other words, no merge for modifications from multiple sources. Only KubeVela keeps the Source-of-Truth for the resource.
- PreDispatchDryRun: enable dryrun before dispatching resources. Enable this flag can help prevent unsuccessful dispatch resources entering resourcetracker and improve the user experiences of gc but at the cost of increasing network requests. This flag is set to true by default.