k0s configuration management
Applies to management clusters only
This section describes the configuration specifics of a k0s-based cluster deployed using MOSK. For the configuration of MKE-based clusters, see MKE configuration management.
Configuration model
Unlike MKE, k0s has no configuration API that you can call directly. The Kubernetes underlay configuration of a k0s-based cluster is fully declarative and is managed as follows:
MOSK composes the cluster-wide k0s configuration from its own defaults and the parameters set in the
Clusterobject of the cluster.The resulting configuration is stored in the
spec.k0sConfigsection of theLCMClusterobject of the cluster.The LCM Agent renders this configuration into a static k0s configuration file on every control plane node.
Important
Editing the k0s configuration on a node or through the k0s cluster configuration object has no persistent effect: any local modification is reverted on the next reconciliation of the cluster.
Use the Cluster object as the only supported way of changing the
Kubernetes underlay configuration.
Warning
Any change in the k0s configuration on a management cluster
restarts the k0scontroller systemd service, which supervises all
Kubernetes control plane components. MOSK cordons and drains one control
plane node at a time, so the pods running on it are rescheduled. Therefore,
plan the change as a maintenance operation and make sure that all cluster
nodes are Ready before applying it.
Parameters managed by MOSK
MOSK sets the following k0s parameters and reapplies them on every reconciliation. The values in the tables are the MOSK defaults for a management cluster.
You can adjust the parameters marked with the
icon through the generic
extraArgs and spec.providerSpec.value.workerProfile.config parameters
described in Parameters exposed in the Cluster object. When the Comments column names a
dedicated Cluster object parameter, that parameter is the only supported
way of changing the default value.
Warning
Mirantis does not recommend changing any of the defaults listed
below. Since the values from the Cluster object take precedence, the
generic extraArgs parameters can also override the unmarked
extraArgs:* defaults. This can break the cluster or make it less secure.
Contact Mirantis support before overriding an unmarked parameter.
spec:api
k0s parameter |
Default value in MOSK |
Comments |
|---|---|---|
|
|
Local port of the Kubernetes API server. External clients reach the
cluster API through the load balancer on port |
|
|
|
|
|
|
|
|
Set through the |
|
Auditing enabled |
Set through the |
|
Derived from the Keycloak configuration of the cluster |
Managed by MOSK. Do not override. |
|
|
|
|
Derived from the Kubernetes version set in |
For details about admission plugins, see Kubernetes documentation: Admission Control in Kubernetes. For the list of admission plugins supported by a specific Kubernetes version, see the corresponding Kubernetes release documentation. |
|
|
Makes the Kubernetes API server verify that a ServiceAccount token still has its backing object in etcd, so that deleting the object revokes the token immediately. Disabling it makes token revocation less secure. |
|
|
|
|
Derived from the cluster load balancer and node addresses |
Managed by MOSK. To add a custom host name to the Kubernetes API endpoint, use a custom TLS certificate instead. See Configure TLS certificates for cluster applications. |
spec:controllerManager and spec:scheduler
k0s parameter |
Default value in MOSK |
Comments |
|---|---|---|
|
|
Set for both components. |
|
|
Set for both components. |
|
|
Set through the |
|
|
Applies to |
spec:storage
k0s parameter |
Default value in MOSK |
Comments |
|---|---|---|
|
|
|
|
|
Managed by MOSK for automated migration from v2 to v3 of the etcd cluster. Do not override. |
|
Unset (etcd default of 2 GB) |
Set through the |
spec:network
k0s parameter |
Default value in MOSK |
Comments |
|---|---|---|
|
|
|
|
|
Set in |
|
|
Set in |
|
|
|
|
|
|
|
|
Set through the |
|
|
|
|
|
|
|
|
Set through the |
spec:workerProfiles
k0s parameter |
Default value in MOSK |
Comments |
|---|---|---|
|
Configuration of kubelet aligned with the MKE defaults, including the
reserved resources, |
MOSK manages two worker profiles. A common kubelet
configuration that you define in
|
Parameters exposed in the Cluster object
To adjust the Kubernetes underlay configuration of a k0s-based cluster, use
the spec.providerSpec.value section of its Cluster object. The
following parameters are exposed:
api.extraArgscontrollerManager.extraArgsscheduler.extraArgsetcd.extraArgsworkerProfile.configfeatureGates
For the detailed description of these parameters, see API Reference: Cluster resource.
Configuration example:
spec:
...
providerSpec:
value:
...
api:
extraArgs:
max-requests-inflight: "600"
controllerManager:
extraArgs:
concurrent-deployment-syncs: "10"
scheduler:
extraArgs:
kube-api-qps: "100"
etcd:
extraArgs:
snapshot-count: "20000"
workerProfile:
config:
imageGCHighThresholdPercent: 80
imageGCLowThresholdPercent: 70
featureGates:
- name: ContainerStopSignals
enabled: true
components:
- kube-apiserver
- kubelet
For the detailed description of these parameters, see API Reference: Cluster resource.
The values that you define are merged on top of the
MOSK defaults, and the values from the Cluster object
take precedence over the defaults. Feature gates are appended after the
MOSK-managed ones, so a user-defined entry overrides a
managed one with the same name.
Important
Mirantis cannot guarantee the expected behavior of the functionality configured through these parameters as long as the customer-specific configuration does not undergo testing within MOSK. Therefore, Mirantis recommends that you test custom settings on a staging environment before applying them to production.
The parameters that MOSK requires for the correct operation of the cluster, such as the OIDC and encryption provider settings, must not be overridden.