linkerd install: Render Linkerd Manifests
linkerd install renders the Kubernetes YAML for the Linkerd control plane to stdout, which you pipe to kubectl apply.
Unlike a one-shot installer, linkerd install prints manifests so you can review or GitOps them. Modern Linkerd splits CRDs and the control plane into two applies.
What it does
linkerd install generates the control-plane manifests (identity, destination, proxy-injector, and their config) as YAML on stdout. You apply them with kubectl. Recent versions require installing CRDs first with linkerd install --crds, then the control plane.
Common usage
# 1) CRDs, 2) control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
# supply your own trust anchor and issuer
linkerd install \
--identity-trust-anchors-file ca.crt \
--identity-issuer-certificate-file issuer.crt \
--identity-issuer-key-file issuer.key | kubectl apply -f -Options
| Flag | What it does |
|---|---|
| --crds | Render only the CRDs (apply these first) |
| --identity-trust-anchors-file <f> | Provide the trust anchor cert |
| --identity-issuer-certificate-file <f> | Provide the issuer cert |
| --identity-issuer-key-file <f> | Provide the issuer key |
| --set <path=value> | Override a Helm value |
In CI
Apply --crds before the control plane or the control-plane apply fails on missing custom resources. For reproducible installs, supply your own identity certs from a secret store instead of letting install generate self-signed ones that rotate on every run.
Common errors in CI
"no matches for kind \"...\" in version \"policy.linkerd.io/...\"" means the CRDs were not applied first; run linkerd install --crds. "you need to install the linkerd CRDs first" is the explicit form. If identity flags are omitted on a re-install, proxies fail mTLS because the trust anchor changed; pin the certs.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes