Insight and reliability through continuous synthetic testing in Kubernetes

Summary

Kubernetes has become the de facto standard for cloud-based applications. As companies migrate more and more workloads, ensuring reliable connectivity and performance are critical not just for user applications but also for the cluster itself.

Kubernetes has become the de facto standard for cloud-based applications. As companies migrate more and more workloads, ensuring reliable connectivity and performance are critical not just for user applications but also for the cluster itself. In this article, we will discuss how augmenting your system monitoring with in-cluster synthetic testing can give you proactive indicators that something might be headed for trouble.

Synthetic testing with Kubernetes

Synthetic tests provide a way of simulating real user actions in a variety of ways. They give insight into real-world usage of your applications and services, whether it be network availability, DNS resolution, or server response times to name a few.

Kubernetes is intended to streamline deployment and application management. By design, it enables faster delivery by hiding the complexity of the underlying infrastructure allowing teams to deploy using common patterns. This gives teams more control over their application development and lifecycle, but also means the responsibility for ensuring application health is largely on them. In an ideal scenario, the team would instrument applications and services to both observe and continuously check health, but in reality, we know that is only sometimes the case. By giving teams the ability to integrate synthetic tests directly into their current development workflow, they can quickly gain insight into how their applications are performing.

At Kentik, we provide synthetic testing to monitor the digital experience across network infrastructure, multiple clouds, SaaS applications, and page transaction testing. We maintain a network of hundreds of agents around the world that continuously monitor designated targets using a range of tests, including page response, DNS lookup times, BGP monitoring, and more. We wanted to bring this same level of synthetic testing to Kubernetes, enabling developers to easily add checks for their applications, so we created Odyssey: an open source Kubernetes operator for synthetic testing.

Odyssey: An open source Kubernetes operator

Odyssey is an open source Kubernetes operator that automates agent provisioning and configuration for a synthetic test framework in a Kubernetes cluster. The operator pattern enables developers to extend Kubernetes for their own applications and still follow the Kubernetes principles. When used with Kentik Synthetics, this gives a number of benefits:

• A standard synthetic platform for all teams
• Operator-controlled base framework
• The operator, not the team, manages cloud provider access
• Developers focus on writing checks, not managing infrastructure

Once the Odyssey operator is deployed, teams can leverage their existing Kubernetes knowledge by having a familiar and simpler method to add synthetic checks to their applications. Let’s look at an example deployment with a service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  labels:
    app: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: docker.io/ehazlett/sysinfo:latest
        ports:
          - containerPort: 8080
            name: app

---
apiVersion: v1
kind: Service
metadata:
  name: demo
  labels:
    app: demo
spec:
  selector:
    app: demo
  ports:
    - name: app
      port: 8080
      targetPort: app
      protocol: TCP

In this example, we have a deployment that exposes a service on port 8080 and a service that also provides access to the deployment on port 8080. Let’s look at adding an Odyssey check to the application that performs an HTTP GET request on the service.

Odyssey provides a custom resource to define a synthetic task. This can be a variety of checks, including ping and fetch, that will ping a host and perform an HTTP request. In the following example it shows how to create an HTTP check with the Odyssey fetch task:

apiVersion: synthetics.kentiklabs.com/v1
kind: SyntheticTask
metadata:
  name: demo
spec:
  fetch:
    - service: demo
      target: /
      port: 8080
      method: GET
      period: 10s
      expiry: 5s

This test will perform an HTTP GET against the Kubernetes service every ten seconds. The operator takes care of resolving the service address and backends allowing the developer to only have to define the application target and not the underlying infrastructure pieces. Once deployed, the Kentik synthetic agent will be provisioned and configured to run the task. When paired with the Kentik Synthetic Dashboard, it gives a great view into both current and historical performance.

With more and more applications moving to Kubernetes, having an easy way to integrate continuous synthetic testing into your cluster brings the necessary insight and operational reliability needed for production services. When coupled with Kentik Synthetics, it gives teams a complete view of their environment from network to application endpoint.

Kentik Kube

We’re excited to announce our beta launch of Kentik Kube, an industry-first solution that reveals how K8s traffic routes through an organization’s data center, cloud, and the internet.

With this launch, Kentik can observe the entire network — on-prem, in the cloud, on physical hardware or virtual machines, and anywhere in between. Kentik Kube enables network, infrastructure, platform, and DevOps engineers to gain full visibility of network traffic within the context of their Kubernetes deployments — so they can quickly detect and solve network problems and surface traffic costs from pods to external services.