# Linkerd + Cluster Bootstrapping

**URL:** <https://linkerd.buoyant.io/t/linkerd-cluster-bootstrapping/473>\
**Category:** Linkerd General Discussion\
**Created:** [May 22, 2024, 10:14pm UTC](https://linkerd.buoyant.io/t/linkerd-cluster-bootstrapping/473 "2024-05-22T22:14:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![itsbenlol](https://yyz1.discourse-cdn.com/flex029/user_avatar/linkerd.buoyant.io/itsbenlol/32/169_2.png) [@itsbenlol](https://linkerd.buoyant.io/u/itsbenlol)\
**Post date:** [May 22, 2024, 10:14pm UTC](https://linkerd.buoyant.io/t/linkerd-cluster-bootstrapping/473/1 "2024-05-22T22:14:33Z")

</div>

I initially posted this on the linkerd slack - it was recommended that I post my questions here instead.

Is there a best-practice regarding bootstrapping a cluster with linkerd? it seems like there will always be workloads that need to exist _prior_ to deploying linkerd and the only way to add these workloads to linkerd’s service mesh is to redeploy them after linkerd has been deployed.

An example:

- I’m using the `linkerd-control-plane` helm chart to render my manifests.
- Because i want to use GitOps, I’m going to use `cert-manager` and `trust-manager` custom resources to create the identity trust anchors - and so i’ll need to deploy both of these alongside `linkerd-control-plane`.
- Eventually, I want to connect everything to Prometheus - so i’ll set `podMonitor.enabled=true` for the `linkerd-control-plane` helm chart.
- Because this depends on custom resources provided from the Prometheus Operator - i need to deploy the Prometheus Operator alongside linkerd.
- However, I’m using `kube-prometheus-stack` to deploy the Prometheus Operator. Consequently, I’m also deploying Prometheus, Grafana _and_ Alertmanager alongside linkerd.
- Unfortunately, i want to set up persistence for Prometheus - so I’ll want to deploy a CSI before deploying `kube-prometheus-stack` - I’ll end up deploying OpenEBS’ `dynamic-localpv-provisioner` alongside linkerd.

In my case, deploying linkerd requires deploying several pre-requisites - and no matter how you tackle deployments (all-at-once with eventual consistenty vs. gated in dependency order) - you’ll always end up with a set of workloads that need to be restarted once linkerd is deployed.

Any ideas for a ‘feels right’ solution to this problem? Could/should linkerd ship with some sort of job that can restart workloads that are annotated with automatic proxy injection that aren’t currently proxy injected?

---

<div class="post-metadata">

**Author:** ![william](https://yyz1.discourse-cdn.com/flex029/user_avatar/linkerd.buoyant.io/william/32/5_2.png) [@william](https://linkerd.buoyant.io/u/william)\
**Post date:** [July 10, 2024, 11:40pm UTC](https://linkerd.buoyant.io/t/linkerd-cluster-bootstrapping/473/2 "2024-07-10T23:40:43Z")

</div>

I’m probably the one who suggested posting here, so apologies for the crickets.

Restarting the pods as part of a bootstrap script doesn’t strike me as the end of the world. It’s not super elegant but it’s one of the consequences of Kubernetes’s immutable pod model and not the worst such consequence.

The closest to an automated solution that we have for this is on the Linkerd Enterprise side where we have a [dataplane operator](https://docs.buoyant.io/buoyant-enterprise-linkerd/latest/tasks/configuring-bel-lifecycle-automation/#data-plane-configuration) that can restart workloads to insert the proxy. But I don’t know if it really simplifies things for you since you have to create the CRs pointing it to the relevant workloads after Linkerd installation anyways, so it’s just another step you’d have to take. I supposed we could make this look at an annotation rather than a custom resource…