Buoyant Cloud

Buoyant Cloud

Installing Managed Linkerd

Managed Linkerd provides in-cluster, automatic upgrades of both the Linkerd control plane and data plane, and it’s available for all Buoyant Cloud Business and Enterprise customers.

Before getting started you will need the following:

Linkerd management is handled by two Kubernetes operators (one for the control plane and one for the data plane) that run on your cluster. These operators are installed as part of the standard Buoyant Cloud agent install. To install the Buoyant Cloud agent on your cluster:

  1. Visit the Buoyant Cloud Clusters page
  2. Click the “Add cluster” button and give your cluster a name; click “Continue”
  3. Follow the instructions on the next screen for installing the agent on your cluster via Helm

You can also use Helm to install agents on multiple clusters without needing to visit the Clusters page for each install. See Programmatically install Buoyant Cloud agent for more information.

If you need to customize the agent install, see the full list of agent Helm chart values.

Run post-install agent health checks Link

# Download the linkerd-buoyant CLI client
curl -sL https://buoyant.cloud/install | sh

# Run healthcheck
linkerd-buoyant check

Now that you’ve setup your cluster in Buoyant Cloud it’s time to tell the Linkerd control plane operator to begin managing the Linkerd core control plane installation on your cluster. You’ll do this by creating a new instance of Buoyant’s ControlPlane resource on your cluster.

linkerd-buoyant controlplane import-helm-config | sh

# save your ControlPlane Custom Resource
kubectl get ControlPlane/cp-update -oyaml > controlplane.yaml

Use the Linkerd Trust Root CA & Identity Certificates & Keys to create a Kubernetes Secret that will be used by Helm at runtime. You will need ca.crt, issuer.crt, and issuer.key files.

cat <<EOF > linkerd-identity-secret.yaml
apiVersion: v1
  ca.crt: $(cat ca.crt | base64 --wrap=0)
  tls.crt: $(cat issuer.crt | base64 --wrap=0)
  tls.key: $(cat issuer.key | base64 --wrap=0)
kind: Secret
  name: linkerd-identity-issuer
  namespace: linkerd
type: kubernetes.io/tls

kubectl apply -f linkerd-identity-secret.yaml

Create a CRD config that will be used by the Linkerd control plane operator to install and manage the Linkerd control plane. You will need ca.crt.

cat <<EOF > controlplane.yaml
apiVersion: linkerd.buoyant.io/v1alpha1
kind: ControlPlane
  name: cp-update
      version: stable-2.14.5
        identityTrustAnchorsPEM: |
$(cat ca.crt | sed 's/^/          /')
            scheme: kubernetes.io/tls

kubectl apply -f controlplane.yaml

linkerd check

Once created, you can see the new resource on the ControlPlane resources page. You’ll also see a managed icon appear beside your cluster on the Overview page. Your cluster’s control plane is now being managed by the control plane operator.

Once the Linkerd control plane is managed, you can move on to configuring the data plane. By default the data plane operator won’t upgrade any proxies outside of the core control plane; you have to create an instance of Buoyant’s DataPlane resource in each namespace where you want pods to be automatically restarted to pick up new proxy versions.

As a starting point, you can create a  DataPlane resource to manage all proxies in the linkerd-buoyant namespace, where the agent is running. For instance:

cat <<EOF > dataplane.yaml
apiVersion: linkerd.buoyant.io/v1alpha1
kind: DataPlane
  name: dp-update
  namespace: linkerd-buoyant
    matchLabels: {}

kubectl apply -f dataplane.yaml

Once created, you can see the new resource on the DataPlane resources page. You can add a similar resource to all namespaces that you want managed by the data plane operator.

With the ControlPlane and DataPlane configs in place, it’s easy to change the version of Linkerd that’s running on your cluster. Simply change the Linkerd version specified in the ControlPlane resource, by running:

kubectl edit controlplane/cp-update

The control plane operator will first upgrade the Linkerd core control plane, and once that successfully completes, the data plane operator will restart each managed workload so that its pods will pick up a new version of the Linkerd proxy.