This article is a brief write-up about the work I did as a part of Google Summer of Code (2020) with Linkerd and my experience with working with the Linkerd team. Read more to find out!

What is Linkerd?

For those unfamiliar with Linkerd - it is a service mesh for Kubernetes.

Linkerd is a service mesh for Kubernetes. It makes running services easier and safer by giving you runtime debugging, observability, reliability, and security — all without requiring any changes to your code. [Source]

Linkerd uses a lightweight sidecar proxy powered by Rust (called “linkerd2-proxy”). These proxies sit next to each of your services and manage all the incoming and outgoing traffic. Together with the services, these make up the “data plane”. The other component of the Linkerd service mesh is the “control plane” written in Go . The control plane is used to manage the data plane and interact with it.

Architecture of Linkerd2. [Source]

I am not going to provide an in-depth explanation of Linkerd and service meshes in this post. However, if you’re interested in learning more, feel free to checkout this blog post by William Morgan.

Conformance Validation

While Linkerd has a great way of running pre-installation and post-installation checks using the linkerd check command, these checks are unfortunately static in nature. There’s many different ways to configure a Kubernetes cluster, with different kinds of providers (such as AKS or GKE). When a particular configuration causes Linkerd to behave unexpectedly, debugging your cluster may become somewhat difficult. The goal of this project is to build a tool that runs E2E tests against some sample workloads on a cluster and exercise many different features of Linkerd to verify if the cluster conforms with Linkerd.

You can find the project repository here.

Currently, the linkerd2-conformance project exercises the following features of Linkerd2:

• Proxy injection
• Control plane life-cycle (install, upgrade and uninstall)
• Ingress
• CLI operations such as tap , stat , edges and routes
• Retries and timeouts

These tests can be configured by providing a YAML file with the required specifications. These configurations include things like Linkerd version, control plane add-ons, skipping tests, clean-up options, etc. Here’s a sample configuration file:

linkerdVersion: stable-2.8.0
externalIssuer: false
controlPlane:
    # namespace: l5d-conformance
    config:   
        ha: false
        flags:
            - "--controller-log-level"
            - "debug"
            - "--proxy-log-level"
            - "warn,linkerd2_proxy=debug"
        addOns:
          tracing:
              enabled: true
              collector:
                  resources:
                      cpu:
                          limit: 100m
                          request: 10m
                      memory:
                          limit: 100Mi
                          request: 50Mi
testCase:
    lifecycle:
        skip: false
        reinstall: false 
        uninstall: true
        upgradeFromVersion: stable-2.7.1
    inject:
        skip: false
        clean: true
    tap:
        skip: false
        clean: true
    edges:
        skip: false
        clean: true
    stat:
skip: false
        clean: true
    ingress:
        skip: false
        config:
            controllers:
                - name: nginx
                  clean: true
                - name: ambassador
                  clean: true
                - name: traefik
                  clean: true
    routes:
        skip: false
        clean: true

Once you have configured your tests, you have 2 ways to run them.

1. Using Sonobuoy

Sonobuoy offers a reliable way to run diagnostic tests in a Kubernetes cluster. We leverage its plugin model to run conformance tests inside a Kubernetes pod.

To run the tests using Sonobuoy, you’d have to first mount the test configuration shown above as a ConfigMap object and simply run the Sonobuoy plugin provided with the project. Sonobuoy will take care of running these tests and will also provide neat reports of the tests.

2. Using go test

These E2E tests are written completely using Golang. We chose Ginkgo as our testing framework and Gomega as its matcher library. The reason for choosing Ginkgo was that it allowed us to neatly structure our tests , and also provided a way to have neat logging and reporting for the tests.

To learn more about the usage, feel free to checkout the documentation.

My experience with Linkerd

My journey with Linkerd started back in October 2019, prior to GSoC, when I was just getting started with Kubernetes and had nearly no experience with service meshes. By making small contributions such as minor bug fixes and addition of new features to the CLI, I have come a long way in learning about service meshes, to be able to work with the Linkerd community as a GSoC student — credits to the very friendly and welcoming community that made sure to answer even the silliest of my questions and help me along the way.

From drafting a project proposal, to getting PRs merged, I have always been able to learn something new from every interaction I have had with the Linkerd community. On the technical side of things I have learnt great coding ethics and practices, developed the ability to read code, understand new paradigms in software development, and most importantly learnt a great deal about service meshes and why must one use it. On the non-technical side, I have learnt how to express ideas and communicate effectively with a team.

Conclusion

GSoC and Linkerd have helped me grow as a software engineer, and the journey has been absolutely delightful for me. Special thanks to my mentors Tarun and Ivan who have been very supportive of my ideas and provided valuable feedback. I’m very excited to see how Linkerd users make effective use of my project, and I also hope to be able to continue making meaningful contributions to the project!