github.com/openshift/installer@v1.4.17/docs/dev/cluster-api.md (about)

     1  # Cluster API
     2  
     3  The installer uses Cluster API controllers through a local control plane powered by `kube-apiserver` and `etcd` running locally.
     4  
     5  ### Local control plane
     6  
     7  The local control plane is setup using the previously available work done in Controller Runtime through [envtest](https://github.com/kubernetes-sigs/controller-runtime/tree/main/tools/setup-envtest). Envtest was born due to a necessity to run integration tests for controllers against a real API server, register webhooks (conversion, admission, validation), and managing the lifecycle of Custom Resource Definitions.
     8  
     9  Over time, `envtest` matured in a way that now can be used to run controllers in a local environment, reducing or eliminating the need for a full Kubernetes cluster to run controllers.
    10  
    11  At a high level, the local control plane is responsible for:
    12  - Setting up certificates for the apiserver and etcd.
    13  - Running (and cleaning up, on shutdown) the local control plane components.
    14  - Installing any required component, like Custom Resource Definitions (CRDs)
    15      - For Cluster API core the CRDs are stored in `data/data/cluster-api/core-components.yaml`.
    16      - Infrastructure providers are expected to store their components in `data/data/cluster-api/<name>-infrastructure-components.yaml`
    17  - Upon install, the local control plane takes care of modifying any webhook (conversion, admission, validation) to point to the `host:post` combination assigned.
    18      - Each controller manager will have its own `host:port` combination assigned.
    19      - Certificates are generated and injected in the server, and the client certs in the api-server webhook configuration.
    20  - For each process that the local control plane manages, a health check (ping to `/healthz`) is required to pass similarly how, when running in a Deployment, a health probe is configured.
    21  
    22  ### Build and packaging
    23  
    24  The Cluster API system is formed of a set of binaries. The core Cluster API manager, and the infrastructure providers are built using Go Modules in the `cluster-api` folder.
    25  
    26  The binaries are built and packaged during the standard installer build process, `hack/build.sh`. Cluster API specific build flow is contained in the `hack/build-cluster-api.sh` script:
    27  - Builds (as needed) every binary listed as a Go Module in  the `cluster-api` folder.
    28  - Downloads (as needed) the specified version of `envtest` to package `kube-apiserver` and `etcd`.
    29  - Produces a single `cluster-api.zip` file which is then copied in `pkg/clusterapi/mirror`.
    30  
    31  To build an `openshift-install` binary with Cluster API bundled:
    32  - Optionally `export SKIP_TERRAFORM=y` if you don't need to use Terraform.
    33  - Run `./hack/build.sh`, the binary is then produced in `bin/openshift-install`.