search

readersclub / linkerd-lf

Introduction to Service Mesh with Linkerd by Linux Foundation - MOOC, EdX
Apache License 2.0
0 stars 0 forks source link

Chapter 6. Deploying Linkerd to a Kubernetes Cluster #7

Open anitsh opened 3 years ago

anitsh commented 3 years ago

Chapter Overview

Up until now, this course has focused primarily on the service mesh concepts and architectural makeup of Linkerd. With these foundations in place, we'll now focus on the hands-on, practical use of Linkerd.

We'll start by learning how to deploy Linkerd to a Kubernetes cluster. The basic requirements for this (and all the hands-on exercises in this course) are administrator-level access to a Kubernetes cluster which can pull images from the public Internet. If you don't have a Kubernetes cluster already, there are many options for creating one. For a cluster that runs in your local environment, you can use minikube, Kubernetes in Docker (kind), or K3s. For a hosted cluster, you could use a managed offering from a cloud like DigitalOcean, GKE, EKS, or AKS.

All the examples and exercises in this course will use kind, and in the first section, we'll include a walkthrough to set kind up on your local machine. Note that Linkerd is designed to work with all modern Kubernetes distributions, so everything you learn here should be applicable no matter how your cluster is created or where it is hosted.

anitsh commented 3 years ago

Learning Objectives

By the end of this chapter, you should be able to:

anitsh commented 3 years ago

Setting up kind, kubectl, and Linkerd

The basic setup for the labs in this course requires a Kubernetes cluster, the kubectl CLI, and the Linkerd CLI. This section contains the links to install each of them, with KinD as the Kubernetes cluster.

Install kubectl

The instructions to install the kubectl CLI for all operating systems are available in the Kubernetes documentation.

Set Up the kind Cluster

If you already have access to a Kubernetes cluster, you can skip this section.

Once you have followed the instructions to install kind, you can create a cluster with this command:

kind create cluster --name lfs143

When the create command completes, confirm that kubectl can access the cluster with this command:

kubectl version --short

During the development of this course, we used kind v0.9.0 to deploy Kubernetes version 1.18 and Linkerd 2.8.1.

Install the Linkerd CLI

In Chapter 3: "Linkerd Architecture" we installed the Linkerd CLI in preparation for the rest of the course. You can skip this section if the CLI is currently installed on your computer. To confirm whether the CLI is installed, run the command linkerd version. If the command returns successfully, then you're all set. Otherwise, run this command to install the Linkerd CLI in a *Nix (including OS X) environment:

curl -sL https://run.linkerd.io/install | sh

Windows users should download the Windows executable from the Linkerd releases page on GitHub. Linkerd has "stable" and "edge" release channels, which you can learn about here. The latest release may be an "edge" release and you can get the latest stable version number in the Linkerd documentation.

anitsh commented 3 years ago

Executing the Linkerd check and install Commands

In Chapter 3, when we installed the Linkerd CLI, you ran linkerd --help to see all the commands available to the Linkerd CLI. This section covers the check and install commands.

Use the check Command

We'll start with the check command which is used in two contexts.

        The first is before the Linkerd control plane is deployed to the cluster (run the Linkerd pre-flight check): linkerd check --pre. The purpose of this command is to make sure that the user who is installing Linkerd has the appropriate permissions to install the Linkerd control plane and that the Linkerd control plane has not already been installed.
        The second context is where the Linkerd check command is most frequently used: after the install command. Running linkerd check after deploying the Linkerd control plane will check that all the control plane components have been successfully installed and are healthy. In addition, it will warn if it detects any conditions that could prevent Linkerd from working as expected, such as:
        - TLS certificates which are expired or expiring soon. 
        - Any components which are out of date and need to be upgraded.

If any of these checks fail, they will display errors or warnings, and links to help so that they can be addressed immediately. If everything looks good, the command will return successfully.

Let's get started by simply running linkerd install. When you run this command, you'll see a lot of output—this is the YAML for the Kubernetes resources that are used to install Linkerd.

Use the install Command

The install command doesn't deploy Linkerd to the Kubernetes cluster directly. In order to deploy the Linkerd control plane, we need to pipe the output from the linkerd install command to kubectl apply -f - like this:

linkerd install | kubectl apply -f -

The kubectl command will send the YAML to the kubernetes API server which will parse the YAML and create the Linkerd control plane.

At this point, you've instructed your cluster to install the control plane. We can use linkerd check to validate how that process is going.

If the Linkerd control plane is still starting up, the check command will inform you that it is waiting for components to start. Once the control plane is successfully installed, check should tell you that you're ready for action (and if it doesn't -- follow the links it provides to correct any issues, and try again).

Congratulations! You've successfully deployed the Linkerd control plane to your cluster!

List Pods in the Linkerd Namespace

For good measure, let's look at the Kubernetes Pods running the Linkerd control plane components: kubectl get po -n linkerd.

You should recognize many of the names here from our architectural overview in previous chapters.

In the upcoming sections, you'll learn more Linkerd CLI commands, how to use the Linkerd dashboard, and deploy a sample application to add to the Linkerd service data plane.

anitsh commented 3 years ago

Production Checkpoint: High Availability Mode

In the last section, you learned how to use the Linkerd CLI to deploy the Linkerd control plane to your Kubernetes cluster. In this section, we'll discuss deploying Linkerd using High Availability (HA) mode, which is a best practice for deploying Linkerd to a production environment.

When deploying the Linkerd control plane, you can optionally pass the --ha flag to the linkerd install command to receive a "high availability" variant of the control plane manifest. This mode will change the control plane deployment in several ways to allow for resilience to many types of failure, including loss of nodes on the cluster. For example, it will:

        Deploy three replicas of critical Linkerd control plane components.
        Set the resource requests and limits on the Linkerd proxy containers.
        Set anti-affinity policies on critical control plane components so that they are scheduled on different nodes.

Note that HA mode requires additional resources and imposes some strict requirements on the cluster. Thus, it is less suitable for experimentation.

Note also that this mode won't actually work on the kind cluster we set up before, as HA mode requires three separate nodes in the cluster! If you want to experiment with HA mode, you will need to create a multi-node kind cluster first.

anitsh commented 3 years ago

Running the Linkerd Dashboard

The linkerd-web component of the control plane is a React application which displays the Linkerd dashboard in a browser. The dashboard is a web interface for the metrics and application information that the control plane has collected. The easiest way to access the dashboard is with the Linkerd dashboard CLI command: linkerd dashboard.

When this command is run, the CLI runs kubectl port-forward to the linkerd-web service using the current kubeconfig file, then opens a browser to http://localhost:50750, where the underlying kubectl port-forward command routes requests.

In the dashboard, you should see all the namespaces in your cluster with the number of pods in each and the number of pods that are meshed. At this point, only the pods in the linkerd namespace (i.e. the control plane pods) should be meshed.

When you click the linkerd namespace, you will see a graph that shows how each of the services in the Linkerd control plane relate to each other through network connections. When we deploy the sample application, you will see a similar relationship between the services in the sample application.

image "Octopus" graph showing how each of the services in the Linkerd control plane relate to each other

The dashboard shows the "Golden Metrics" for each of the services which are part of the mesh, including success/error rates, requests per second, and latencies. In the next chapter, you'll learn more about these metrics and how to get them from Linkerd via the dashboard or the CLI.

Looking closely at the Linkerd control plane components in the dashboard, you will notice that there is a component named linkerd-grafana. Linkerd deploys an instance of Grafana with custom dashboards so that you can view graphs of the metrics collected by Linkerd over time. You can access the Grafana dashboards in a couple of ways:

        Click any Grafana icon in the dashboard ().
        Navigate to http://localhost:50750/grafana in your browser after running the linkerd dashboard command.

A Grafana dashboard is created for every Kubernetes deployment that is injected with the Linkerd proxy. You can review the dashboard definitions in the Linkerd repository.

Feel free to explore the Linkerd and Grafana dashboards for the Linkerd control plane components. We'll revisit both of these dashboards in an upcoming chapter after we deploy the demo application.

anitsh commented 3 years ago

Running the Linkerd tap Command

Before we move on to the next chapter, let's take a look at one of the most useful Linkerd commands: tap.

Use the tap Command

If you've ever used tcpdump, then the Linkerd tap command will be familiar. tap is used to display the real-time traffic between Kubernetes resources which are part of the Linkerd service mesh and this is facilitated by the linkerd-tap component of the control plane. Let's take a look at the traffic between the linkerd-prometheus component and the other components in the control plane: linkerd tap -n linkerd deploy/linkerd-prometheus.

req id=0:11 proxy=out src=10.244.0.73:36452 dst=10.244.0.72:4191 tls=true :method=GET :authority=10.244.0.72:4191 :path=/metrics rsp id=0:11 proxy=out src=10.244.0.73:36452 dst=10.244.0.72:4191 tls=true :status=200 latency=2501µs end id=0:11 proxy=out src=10.244.0.73:36452 dst=10.244.0.72:4191 tls=true duration=89µs response-length=3253B req id=0:12 proxy=out src=10.244.0.73:38892 dst=10.244.0.72:3000 tls=true :method=GET :authority=10.244.0.72:3000 :path=/metrics rsp id=0:12 proxy=out src=10.244.0.73:38892 dst=10.244.0.72:3000 tls=true :status=200 latency=3440µs end id=0:12 proxy=out src=10.244.0.73:38892 dst=10.244.0.72:3000 tls=true duration=109µs response-length=2769B req id=0:13 proxy=out src=10.244.0.73:34282 dst=10.244.0.80:4191 tls=true :method=GET :authority=10.244.0.80:4191 :path=/metrics req id=0:14 proxy=out src=10.244.0.73:38374 dst=10.244.0.71:9995 tls=true :method=GET :authority=10.244.0.71:9995 :path=/metrics rsp id=0:13 proxy=out src=10.244.0.73:34282 dst=10.244.0.80:4191 tls=true :status=200 latency=10480µs end id=0:13 proxy=out src=10.244.0.73:34282 dst=10.244.0.80:4191 tls=true duration=132µs response-length=19973B rsp id=0:14 proxy=out src=10.244.0.73:38374 dst=10.244.0.71:9995 tls=true :status=200 latency=3275µs end id=0:14 proxy=out src=10.244.0.73:38374 dst=10.244.0.71:9995 tls=true duration=296µs response-length=2338B req id=0:15 proxy=out src=10.244.0.73:55786 dst=10.244.0.70:9996 tls=true :method=GET :authority=10.244.0.70:9996 :path=/metrics rsp id=0:15 proxy=out src=10.244.0.73:55786 dst=10.244.0.70:9996 tls=true :status=200 latency=3539µs end id=0:15 proxy=out src=10.244.0.73:55786 dst=10.244.0.70:9996 tls=true duration=248µs response-length=3052B req id=0:16 proxy=out src=10.244.0.73:56668 dst=10.244.0.77:9994 tls=true :method=GET :authority=10.244.0.77:9994 :path=/metrics rsp id=0:16 proxy=out src=10.244.0.73:56668 dst=10.244.0.77:9994 tls=true :status=200 latency=2610µs end id=0:16 proxy=out src=10.244.0.73:56668 dst=10.244.0.77:9994 tls=true duration=41µs response-length=1703B req id=0:17 proxy=out src=10.244.0.73:38064 dst=10.244.0.76:9998 tls=true :method=GET :authority=10.244.0.76:9998 :path=/metrics rsp id=0:17 proxy=out src=10.244.0.73:38064 dst=10.244.0.76:9998 tls=true :status=200 latency=4215µs end id=0:17 proxy=out src=10.244.0.73:38064 dst=10.244.0.76:9998 tls=true duration=426µs response-length=2104B req id=0:18 proxy=out src=10.244.0.73:52920 dst=10.244.0.75:9995 tls=true :method=GET :authority=10.244.0.75:9995 :path=/metrics rsp id=0:18 proxy=out src=10.244.0.73:52920 dst=10.244.0.75:9995 tls=true :status=200 latency=4362µs end id=0:18 proxy=out src=10.244.0.73:52920 dst=10.244.0.75:9995 tls=true duration=444µs response-length=2171B

Each line of output represents an event emitted by the linkerd-prometheus pod's sidecar proxy. These events contain:

        The type of event:
        - HTTP request (req), HTTP response (res), end of HTTP response (end)
        The direction of the traffic, relative to the proxy:
        - in (i.e. a request sent to this pod), out (i.e. a request sent from this pod)
        The source IP address
        The destination IP address
        Whether the traffic is encrypted with Linkerd mTLS
        tls=true
        Other request specific information:
        - HTTP method
        - Request duration
        - Latency
        - Response latency

If you want to dig deeper into the traffic, you can see request and response headers by using the -o json flag to write the output as JSON. The output is more verbose, and is intended for debugging traffic between services at a very low level.

anitsh commented 3 years ago

Summary

In this chapter, you started your hands-on experience with the Linkerd service mesh. You used four of the Linkerd CLI commands:

        check, along with the --pre flag
        install
        dashboard
        tap

We used the check command to verify that the Linkerd control plane components could be deployed to the Kubernetes cluster, and then to verify the health of the Linkerd control plane once it had been deployed with the install command. We also looked briefly at the high availability, or HA, mode of Linkerd installation.

We ran the linkerd dashboard command to access the Linkerd Web UI or "dashboard", and saw how the the Linkerd dashboard is a single pane of glass into the Kubernetes cluster to determine the status of the Linkerd control plane components as well as any applications which are part of the service mesh.

Finally, we used linkerd tap to see the live traffic between the linkerd-prometheus component and the other components in the Linkerd control plane.

In the next chapter, you'll deploy a sample gRPC-based application and add it to the Linkerd service mesh.

anitsh commented 3 years ago

https://phoenixnap.com/kb/how-to-install-kubernetes-on-a-bare-metal-server