Linkerd 2.10 (Step by Step)—Install Multi-Cluster Components

[[406693]]

The Linkerd 2.10 Chinese manual is being continuously revised and updated:

• https://linkerd.hacker-linner.com

Multicluster support in Linkerd requires additional installation and configuration on top of the default control plane installation. This guide will cover this installation and configuration as well as common issues you might encounter.

Require

• Two clusters.
• The control plane installations in each cluster share a common trust anchor.
• Each of these clusters should be configured as kubectl contexts.
• Elevated permissions on both clusters. We will be creating the service account and granting extended permissions, so you need to be able to do this on the test cluster.
• Support for LoadBalancer type services in the east cluster. See the documentation for your cluster provider or look at inlets. This is what the west cluster will use to communicate with east through the gateway.

Step 1: Install the multicluster control plane

On each cluster, run:

 linkerd multicluster install | \
 kubectl apply -f -

To verify that everything started successfully, run:

 linkerd multicluster check  

Step 2: Link Cluster

Each cluster must be linked. This involves installing several resources in the source cluster, including a secret containing a kubeconfig that allows access to the target cluster's Kubernetes API, a service mirror control for mirroring services, and a Link custom resource to hold the configuration. To connect cluster west to cluster east, you would run:

 linkerd --context=east multicluster link --cluster-name east |  
  kubectl --context=west apply -f -  

To verify that the credentials were successfully created and the clusters can access each other, run:

 linkerd --context=west multicluster check  

You should also see a list of gateways by running the following command. Note that you need to install Linkerd's Viz extension in your source cluster to get the list of gateways:

 linkerd --context=west multicluster gateways  

For detailed instructions on this step, see the Linking Clusters section.

Step 3: Expose services

Services are not automatically mirrored in linked clusters. By default, only services with the mirror.linkerd.io/exported label are mirrored. For each service you want to mirror to the linked cluster, run:

 kubectl label svc foobar mirror.linkerd.io/exported= true  

You can configure a different label selector by using the --selector flag on the linkerd multicluster link command or by editing the link resource created by the linkerd multicluster link command.

Leverage Ambassador

The bundled Linkerd gateway is not required. In fact, if you have an existing Ambassador installation, it's easy to use it! By using your existing Ambassador installation, you don't need to manage multiple ingress gateways and pay for additional cloud load balancers. This guide assumes that Ambassador has already been installed into the ambassador namespace.

First, you need to inject the ambassador deployment with Linkerd:

 kubectl -n ambassador get deploy ambassador -o yaml | \
 linkerd inject \
 --skip-inbound-ports 80,443 \  
 --require-identity-on-inbound-ports 4183 - | \  
 kubectl apply -f -

This will add the Linkerd proxy, skipping the port that Ambassador handles for public traffic and requiring identity on the gateway port. Next, you need to add some configuration so that Ambassador knows how to handle the request:

 cat <<EOF | kubectl --context=${ctx} apply -f -  
 ---  
 apiVersion: getambassador.io/v2
 kind: Module
 metadata:
 name : ambassador
 namespace: ambassador
 spec:
 config:
 add_linkerd_headers: true  
 ---  
 apiVersion: getambassador.io/v2
 kind: Host
 metadata:
 name : wildcard
 namespace: ambassador
 spec:
 hostname: "*"  
 selector:
 matchLabels:
 nothing: nothing
 acmeProvider:
 authority: none
 requestPolicy:
 insecure:
 action : Route
 ---  
 apiVersion: getambassador.io/v2
 kind: Mapping
 metadata:
 name : public -health- check  
 namespace: ambassador
 spec:
 prefix: /-/ambassador/ready
  rewrite: /ambassador/v0/check_ready
 service: localhost:8877
 bypass_auth: true  
 EOF 

The Ambassador service and deployment definitions require some minor patching. This will add the metadata required by the service mirror controller. To patch these resources, run:

 kubectl --context=${ctx} -n ambassador patch deploy ambassador -p='  
 spec:
 template:
 metadata:
 annotations:
                config.linkerd.io/enable-gateway: "true"  
 '
 kubectl --context=${ctx} -n ambassador patch svc ambassador --type='json' -p='[  
        { "op" : "add" , "path" : "/spec/ports/-" , "value" :{ "name" : "mc-gateway" , "port" : 4143}},
        { "op" : "replace" , "path" : "/spec/ports/0" , "value" :{ "name" : "mc-probe" , "port" : 80, "targetPort" : 8080}}
 ]'
 kubectl --context=${ctx} -n ambassador patch svc ambassador -p='  
 metadata:
 annotations:
        mirror.linkerd.io/gateway-identity: ambassador.ambassador.serviceaccount.identity.linkerd.cluster.local  
        mirror.linkerd.io/multicluster-gateway: "true"  
        mirror.linkerd.io/probe-path: /-/ambassador/ready
        mirror.linkerd.io/probe-period: "3"  
 '

Now you can install the Linkerd multicluster components onto your target cluster. Since we are using Ambassador as our gateway, we need to skip installing the Linkerd gateway using the --gateway=false flag:

 linkerd --context=${ctx} multicluster install --gateway=false | kubectl --context=${ctx} apply -f -  

Once all setup and configuration is complete, you can link your source cluster to the Ambassador gateway. Run the link command, specifying the name and namespace of the Ambassador service:

 linkerd --context=${ctx} multicluster link --cluster-name=${ctx} --gateway-name=ambassador --gateway-namespace=ambassador \  
    | kubectl --context=${src_ctx} apply -f -  

From the source cluster (the one not running Ambassador), you can verify that everything is working correctly by running:

 linkerd multicluster check  

Additionally, the ambassador gateway is shown when listing active gateways:

 Linkerd multicluster gateways

Trust Anchor Bundle

To secure connections between clusters, Linkerd needs to have a shared trust anchor. This allows the control plane to encrypt requests passing between clusters and verify the identity of those requests. This identity is used to control access to the cluster, so a shared trust anchor is critical.

The simplest approach is to share a single trust anchor certificate between multiple clusters. If you have an existing Linkerd installation and discarded your trust anchor key, you may not be able to provide a single certificate for the trust anchor. Fortunately, a trust anchor can also be a bunch of certificates!

To get the trust anchor for an existing cluster, run:

 kubectl -n linkerd get cm linkerd-config -ojsonpath= "{.data.values}" | \
  yq e .identityTrustAnchorsPEM -> trustAnchor.crt

This command requires yq. If you don't have yq, feel free to use the tool of your choice to extract the certificate from the identityTrustAnchorsPEM field.`

Now you need to create a new trust anchor and issuer for the new cluster:

 step certificate create root.linkerd.cluster. local root.crt root. key \
 --profile root-ca --no-password --insecure  
 step certificate create identity.linkerd.cluster. local issuer.crt issuer. key \
 --profile intermediate-ca --not-after 8760h --no-password --insecure \  
 --ca root.crt --ca-key root.key  

We used step cli to generate the certificates. openssl should work just as well!

Using the trust anchor of the old cluster and the trust anchor of the new cluster, you can create a bundle by running the following command:

 cat trustAnchor.crt root.crt > bundle.crt

You need to upgrade your existing cluster with the new bundle. Make sure every pod that you want to communicate with the new cluster is restarted so that it can use this bundle. To upgrade your existing cluster with this new trust anchor bundle, run:

 linkerd upgrade --identity-trust-anchors-file=./bundle.crt | \  
 kubectl apply -f -

Finally, you’ll be able to install Linkerd on a new cluster using the trust anchor bundle you just created, along with the issuer certificate and key.

 linkerd install \
 --identity-trust-anchors-file bundle.crt \  
 --identity-issuer-certificate-file issuer.crt \  
 --identity-issuer-key-file issuer.key | \  
 kubectl apply -f -

Make sure to verify that the clusters started successfully by running check on each cluster.

 linkerd check  

Installing multi-cluster control plane components via Helm

Linkerd's multicluster components, namely Gateway and Service Mirror, can be installed via Helm instead of the linkerd multicluster install command.

Not only does this allow for advanced configuration, it also lets users bundle multi-cluster installations as part of their existing Helm-based installation pipelines.

Add Linkerd's Helm repository

First, let's add the Linkerd Helm repo by running

 # To   add the repo for Linkerd2 stable releases:
 helm repo add linkerd https://helm.linkerd.io/stable

Helm multi-cluster installation process

 helm install linkerd2-multicluster linkerd/linkerd2-multicluster

Chart values ​​will be picked from the chart's values.yaml file.

You can override values ​​in your own values.yaml file by providing it and using the -f option, or override specific values ​​using the --set series of flags.

The full set of configuration options can be found here

The installation can be verified by running the following command

 linkerd multicluster check  

The installation of a gateway can be disabled via the gateway setting. By default, this value is true.

Installing Additional Access Credentials

When you install multicluster components onto a target cluster using linkerd multicluster install, a service account is created that the source cluster will use to mirror services. Using a different service account for each source cluster can be beneficial because it enables you to revoke service mirroring access from a specific source cluster. Additional service accounts and associated RBAC can be generated through the CLI using the linkerd multicluster allow command.

The same functionality can also be accomplished through Helm by setting the remoteMirrorServiceAccountName value to list.

 helm install linkerd2-mc-source linkerd/linkerd2-multicluster --set remoteMirrorServiceAccountName={source1\,source2\,source3} --kube-context target  

【Editor's recommendation】

1. Remote desktop developed by Chinese programmers is popular! Available for Mac, only 9MB, supports self-built repeaters
2. 3 minutes to help you understand Kafka thoroughly
3. How big is the bandwidth of Tik Tok's server to accommodate hundreds of millions of people watching at the same time?
4. Github is hot! Can this so-called postmodern editor surpass Vim?
5. The seven most dangerous attack techniques in 2021