cluster-api-provider-agent

README

cluster-api-provider-agent

Kubernetes-native declarative infrastructure for agent-based installation.

cluster-api-provider-agent serves as infrastructure provider for Kubernetes cluster-api

How to install cluster-api-provider-agent

cluster-api-provider-agent is deployed into an existing OpenShift / Kubernetes cluster.

Prerequisites:

• Admin access to the OpenShift / Kubernetes cluster specified by the KUBECONFIG environment variable

Installing with clusterctl

Add the agent provider to clusterctl configuration file (located at $HOME/.cluster-api/clusterctl.yaml).

providers:
  - name: "agent"
    url: "https://github.com/eranco74/cluster-api-provider-agent/releases/latest/infrastructure-components.yaml"
    type: "InfrastructureProvider"

Set up the provider:

clusterctl init --infrastructure agent

Installing from source

Build the cluster-api-provider-agent image and push it to a container image repository:

make docker-build docker-push IMG=<your docker repository>:`git log -1 --short`

Deploy cluster-api-provider-agent to your cluster:

make deploy IMG=<your docker repository>:`git log -1 --short`

Design

cluster-api-provider-agent utilizes the Infrastructure Operator for adjusting the amount of workers in an OpenShift cluster. The CRDs that it manages are:

• AgentCluster
• AgentMachine
• AgentMachineTemplate

High-level flow

1. Using the Infrastructure Operator, create an InfraEnv suitable for your environment.
2. Download the Discovery ISO from the InfraEnv's download URL and use it to boot one or more hosts. Each booted host will automatically run an agent process which will create an Agent CR in the InfraEnv's namespace.
3. Approve Agents that you recognize and set any necessary properties (e.g., hostname, installation disk).
4. When a new Machine is created, the CAPI provider will find an available Agent to associate with the Machine, and trigger its installation via the Infrastructure Operator.

Status

Until now this CAPI provider has been tested for resizing HyperShift Hosted Clusters. It also has the following limitations:

• The cluster machine approver currently won't approve the kubelet-serving CSRs until you take the ProviderID from the appropriate Machine and add it to the Node's Spec.
• The reprovisioning flow currently requires manually rebooting the host with the Discovery ISO.
• The CAPI provider does not yet have cluster lifecycle features - it adds and removes nodes from an existing cluster.
• The CAPI provider currently selects the first free Agent that is approved and whose validations are passing. It will be smarter in the future.