Skip to main content

Kubernetes

CatalogDiscoveryScorecards

Summary​

Kubernetes provides deep visibility into static code analysis metrics. You can use the Kubernetes integration to:

  • Easily one-click import services from multiple k8s clusters into Cortex
  • Build scorecard rules to enforce your org's k8s best practices
  • View information from k8s in the service homepage, letting you easily access information such as active replicas, currently deployed versions, resource requirements, and more.

Setup​

In order to connect Cortex to your Kubernetes instance, you’ll need to install the Cortex K8s agent in your Kubernetes cluster. You can follow the instructions to do so in Settings β†’ Kubernetes.

Service Registration​

Discovery​

By default, Cortex will use the service identifier (e.g. my-service) as the "best guess" for the Kubernetes deployment or rollout. For example, if your service identifier is my-service, then the corresponding deployment or rollout in Kubernetes should also be my-service.

If your Kubernetes deployment or rollouts don’t cleanly match the Cortex service identifier, you can override this in the Cortex Service Descriptor.

Annotation​

Alternatively, you can link your Kubernetes deployment to a Cortex service by adding an annotation to your deployment metadata. Use cortex.io/tag as the key and use the value of x-cortex-tag in the Cortex service's cortex.yaml as the value.

For example, if the cortex.yaml file contains

openapi: 3.0.0
info:
title: My Service
x-cortex-tag: my-service
description: This is my cool service.

Then the deployment.yaml file should be configured as

apiVersion: apps/v1
kind: Deployment
metadata:
name: does-not-matter
namespace: does-not-matter-either
annotations:
cortex.io/tag: my-service

Service Descriptor​

If you need to override the automatic discovery, you can define the following block in your Cortex Service Descriptor.

Cortex accepts a list of K8s resources, which can be on different clusters or of different types.

Each Resource type has the same field definitions.

FieldDescriptionRequired
identifiernamespace/name as found in Kubernetestrue
clusterThe name of the cluster, which is set when deploying the agenttrue

Deployments​

x-cortex-k8s:
deployment:
- identifier: namespace/name
cluster: dev # optional
- identifier: experiment/scratch
cluster: dev
- identifier: default/cortex
cluster: prod

ArgoCD Rollout​

x-cortex-k8s:
argorollout:
- identifier: namespace/name
cluster: dev

StatefulSet​

x-cortex-k8s:
statefulset:
- identifier: namespace/name
cluster: dev

Cortex k8s Agent​

The k8s integration is powered by a lightweight, custom agent we've developed. The agent is deployed into your cluster, and periodically sends information back to Cortex.

Basics​

The k8s agent collects information from your cluster (such as the current list of deployments. Using a Cortex API key, it sends this information back to Cortex, where it's exposed through the dashboard.

The k8s agent is lightweight and adds negligible impact to your cluster. It's essentially a simple cron job that collects and sends information back to your Cortex account.

The agent collects information every five minutes, by default.

Deployment​

To deploy the agent, you can use our helm chart which allows for an easy installation. The helm chart is provided to you upon request.

Security​

Security of your cluster is extremely important to us (and to you!). The agent's push-model ensures that you do not need to expose your cluster to the public internet.

Additionally, the helm chart comes with a predefined ClusterRole that provides the correct RBACs, which are:

  • Permissions: ["get", "watch", "list"]
  • On resources: ["deployments", "services", "pods", "replicationcontrollers"]

Communication out of the cluster to Cortex happens over HTTPS. There is no inbound traffic to the agent.