Cluster API Control Plane Provider Talos

repository·main·Indexed 41 days ago

https://github.com/siderolabs/cluster-api-control-plane-provider-talos

A Cluster API (CAPI) provider used to deploy Talos Linux-based Kubernetes nodes. It generates Talos control plane configurations and reconciles custom resources, supporting the TalosControlPlane API type with both automatic generation and custom machine configuration modes.

Tokens
1.8K
Snippets
7
Records
9
Agent score
50%

What's inside CACPPT

  1. How TalosControlPlane generation modes work

    main

    The TalosControlPlane resource uses the generateType field to determine how the Talos machine configuration is handled:

    1. controlplane: The provider automatically generates the Talos configuration. This is the recommended approach for most users as it allows the provider to expose the resulting talosconfig in the resource's .status.talosConfig field.
    2. none: The user provides a complete Talos machine configuration via the data field. The provider blindly copies this data to .status.controlPlaneData for upstream CAPI controllers to use. In this mode, the provider cannot generate a talosconfig for you.

    This generateType logic applies to both control plane and worker ("join") nodes.

  2. Build and install the provider from source

    main

    You can build the provider using make. This generates a component YAML file that can be applied directly to your management cluster via kubectl.

    1. Run make release from the root directory to create _out/control-plane-components.yaml.
    2. Apply the generated file to your management cluster:
    kubectl apply -f _out/control-plane-components.yaml
    make release
    kubectl apply -f _out/control-plane-components.yaml
  3. Workaround for clusterctl init error (target namespace can't be defaulted)

    main

    If you encounter the error failed to get provider components for the "talos" provider: target namespace can't be defaulted. Please specify a target namespace, it is due to the GitHub organization rename from talos-systems to siderolabs.

    To fix this, add the following provider definitions to your ~/.cluster-api/clusterctl.yaml file and rerun the clusterctl init command:

    providers:
      - name: "talos"
        url: "https://github.com/siderolabs/cluster-api-bootstrap-provider-talos/releases/latest/bootstrap-components.yaml"
        type: "BootstrapProvider"
      - name: "talos"
        url: "https://github.com/siderolabs/cluster-api-control-plane-provider-talos/releases/latest/control-plane-components.yaml"
        type: "ControlPlaneProvider"
      - name: "sidero"
        url: "https://github.com/siderolabs/sidero/releases/latest/infrastructure-components.yaml"
        type: "InfrastructureProvider"
  4. Configure a basic TalosControlPlane

    main

    The provider supports the TalosControlPlane API type. For a standard configuration where the provider generates the Talos configuration for you, set generateType to controlplane within the controlPlaneConfig section.

    Note: You must provide an infrastructureTemplate in the spec.

    After creation, you can retrieve the generated talosconfig using: kubectl get talosconfig -o yaml <name> -o jsonpath='{.status.talosConfig}'

    apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
    kind: TalosControlPlane
    metadata:
      name: talos-cp
    spec:
      version: v1.18.1
      replicas: 1
      infrastructureTemplate:
        kind: MetalMachineTemplate
        apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
        name: talos-cp
      controlPlaneConfig:
        controlplane:
          generateType: controlplane
  5. Configure a TalosControlPlane with custom machine configuration

    main

    If you need to provide a complete, pre-generated Talos machine configuration, set generateType to none and provide the configuration content in the data field.

    Warning: Using generateType: none prevents the provider from generating a talosconfig for you. You must manually manage the talosconfig used during the initial generation (e.g., via talosctl config generate).

    apiVersion: control-plane.cluster.x-k8s.io/v1alpha2
    kind: TalosControlPlane
    metadata:
      name: talos-0
      labels:
        cluster.x-k8s.io/cluster-name: talos
    spec:
      controlPlaneConfig:
        init:
            generateType: none
            data: |
                version: v1alpha1
                machine:
                type: controlplane
                token: xxxxxx
                ...
                ...
      ...
      ...
  6. Reference: Controller Manager CLI flags

    main

    The following flags are available for the controller manager:

    FlagTypeDefaultDescription
    --enable-leader-electionboolfalseEnable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
    --webhook-portint9443Webhook Server port. When enabled, the manager will only work as a webhook server, no reconcilers are installed.
    --webhook-cert-dirstring/tmp/k8s-webhook-server/serving-certs/Webhook cert dir, only used when --webhook-port is specified.
    --health-addrstring:9440The address the health endpoint binds to.
    # Example usage (conceptual)
    ./controller-manager --enable-leader-election --webhook-port 9443
  7. Initialize Talos Control Plane Provider flags

    main

    To integrate the provider's flags into a custom CLI or tool, call InitFlags passing a *pflag.FlagSet. This function also includes logging configuration flags via logsv1.AddFlags.

    import (
    	"github.com/spf13/pflag"
    	"github.com/siderolabs/cluster-api-control-plane-provider-talos"
    )
    
    func main() {
    	fs := pflag.NewFlagSet("my-provider", pflag.ContinueOnError)
    	controlplanev1alpha3.InitFlags(fs)
    	fs.Parse([]string{"--enable-leader-election"})
    }