Manager Flags¶

The CAPTF manager is the manager binary in the manager container of the captf-controller-manager Deployment. It takes every setting as a command-line flag; it has no configuration file, and it reads only two settings from the environment (see Environment variables). The flags follow the conventions of kube-controller-manager and the CAPI core providers. A flag accepts --name=value or --name value, and underscores in place of dashes (--leader_elect is --leader-elect). Durations are Go duration strings such as 30m, 90s or 1h30m.

For what each group of flags changes in practice, see Configuration. This page is the complete list.

Set a flag¶

The shipped Deployment sets its arguments in config/manager/manager.yaml in the provider repository. clusterctl init installs that manifest, and there are no clusterctl variables for the manager’s arguments, so you change a flag by editing the args of the manager container on the live Deployment, or in a kustomize overlay over the released manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: captf-controller-manager
  namespace: captf-system
spec:
  template:
    spec:
      containers:
      - name: manager
        args:
        - --leader-elect
        - --diagnostics-address=:8443
        - --insecure-diagnostics=false
        - --webhook-port=9443
        - --terraformcluster-concurrency=20
        - --drift-default-interval=1h

The first four arguments are the shipped ones; the highlighted two are additions. The manager logs every parsed flag once at start, one FLAG: --name="value" line each, and refuses to start on a value it cannot run with: a concurrency below 1, a --sync-period or --drift-default-interval that is not positive, a negative --state-backups, or no valid runner image.

The flags you are most likely to change¶

CAPTF¶

These flags set how the manager runs Jobs and what it keeps around them.

Controllers and concurrency¶

These flags choose what the manager watches and how many objects it reconciles at once.

A reconcile is a handful of API reads and a status patch, and mostly waits on a Job, so a higher concurrency rarely costs much CPU. Lower it to soften bursts against a small API server. The admission webhooks serve every namespace whatever --namespace and --watch-filter say, so an object the manager does not watch is admitted and then never reconciled. Namespace scoping and --watch-filter explains the trade-offs.

Leader election¶

Leader election makes sure one manager reconciles at a time. The Lease is named controller-leader-election-captf and is not parameterized.

The defaults match kube-controller-manager and rarely need changing. Lower them to replace a crashed leader faster, at the cost of more Lease traffic.

Webhooks¶

The webhook server hosts the validating webhooks. cert-manager issues its serving certificate, and the Deployment mounts the Secret into the manager pod.

The shipped manifests wire these together. You change them only for a custom certificate layout.

Diagnostics and TLS (CAPI)¶

These flags come from Cluster API’s shared manager options and behave as they do in the CAPI core providers. The diagnostics endpoint serves Prometheus metrics over HTTPS, authenticated and authorized against the API server. See Observability for what it serves.

Logging¶

The logging flags are the Kubernetes component-base set. The manager runs at verbosity 2, where the usual reconcile flow is visible. Credentials, bootstrap data, tfvars content and output values are never logged, whatever the level.

To change the level of a running manager without a restart, use the authenticated diagnostics endpoint; see Logs and verbosity.

Other flags¶

manager version prints the same line as manager --version and exits.

Feature gates¶

--feature-gates takes a comma-separated Key=value list, for example --feature-gates=LoggingAlphaOptions=true. CAPTF registers no feature gate of its own. The gates that exist are the component-base logging gates.

Environment variables¶

The manager reads these from its own environment. A custom Deployment or an overlay that replaces the container’s env must keep them.

The manager also reads POD_NAMESPACE and SERVICE_ACCOUNT_NAME, which the shipped Deployment sets through the downward API. Without them the webhook cannot tell which ServiceAccount is the manager and refuses its providerID writes. See Manager environment.

Shipped arguments¶

config/manager/manager.yaml sets these arguments on the manager container. Every other flag keeps its default.