Configuring Control Plane Components

See here for a complete list of available configuration options.

Control plane endpoint

The control plane endpoint is the address (IP or DNS), along with optional port, that represents the control plane. It it is effectively the API server address, however, it is internally used for a few other purposes, such as:

• Discovering other services using the host (e.g. bootstrap-server)
• Adding to the SAN for generated cluster certificates

It is specified in the config file like so:

apiVersion: crit.sh/v1alpha2
kind: ControlPlaneConfiguration
controlPlaneEndpoint: "example.com:6443"

Disable/Enable Kubernetes Feature Gates

Setting feature gates will be important if you need specific features that are not available by default or maybe to enable a feature that wasn't enabled by default for a particular version of Kubernetes.

For example, CSI-related features were only enabled by default starting with version 1.17, so for older versions of Kubernetes you will need to turn them on manually for the control plane:

apiVersion: crit.sh/v1alpha2
kind: ControlPlaneConfiguration
...
kubeAPIServer:
  featureGates:
    CSINodeInfo: true
    CSIDriverRegistry: true
    CSIBlockVolume: true
    VolumeSnapshotDataSource: true
node:
  kubelet:
    featureGates:
      CSINodeInfo: true
      CSIDriverRegistry: true
      CSIBlockVolume: true

and for the workers:

apiVersion: crit.sh/v1alpha2
kind: WorkerConfiguration
...
node:
  kubelet:
    featureGates:
      CSINodeInfo: true
      CSIDriverRegistry: true
      CSIBlockVolume: true

The kubeAPIServer, kubeControllerManager, kubeScheduler, and kubelet all have feature gates that can be configured. More info is available in the Kubernetes docs.

Configuring Pod/Service Subnets

apiVersion: crit.sh/v1alpha2
kind: ControlPlaneConfiguration
podSubnet: "10.153.0.0/16"
serviceSubnet: "10.154.0.0/16"

Configuring a Cloud Provider

A cloud provider can be specified to integrate with the underlying infrastructure provider. Note, the specified cloud will most likely require authentication/authorization to access their APIs.

Crit supports both In-tree and out-of-tree cloud providers.

In-tree Cloud Provider

In-tree cloud providers can be specified with the following:

apiVersion: crit.sh/v1alpha2
kind: ControlPlaneConfiguration
...
node:
  cloudProvider: aws

and for the workers:

apiVersion: crit.sh/v1alpha2
kind: WorkerConfiguration
...
node:
  cloudProvider: aws

Out-of-tree Cloud Provider

Out-of-tree cloud providers can be specified with the following:

apiVersion: crit.sh/v1alpha2
kind: ControlPlaneConfiguration
...
node:
  kubeletExtraArgs: 
    cloud-provider: external

and for the workers:

apiVersion: crit.sh/v1alpha2
kind: WorkerConfiguration
...
node:
  kubeletExtraArgs: 
    cloudProvider: external

A manifest specific to cloud environment must then be applied to run the external cloud controller manager.