Kubernetes Host Networking Customization

This page will walk you through various options for customizing your Akita Agent on a host network in Kubernetes.

If you are just getting started with Kubernetes host networking, check out our getting started instructions.

If you are looking to install the Akita Agent on a single staging or production Kubernetes service, check out our Single-Service Kubernetes page.

Below you will find instructions for:

  1. Rate limiting the Akita Agent
  2. Tagging your Akita Agents
  3. Removing Kubernetes APIs
  4. Creating a pod definition to run the Akita Agent

This guide assumes that you:

Rate limiting

If you would like to rate limit the Akita Agent, set a per-node rate limit by using the --rate-limit flag in your daemonset.yaml file.

In the below example, we set a rate limit of 200 requests/minute. If the rate of packet captures is higher than this, the Akita Agent will start performing statistical sampling of the packets it sees.

spec:
      containers:
        - image: akitasoftware/cli:latest
          imagePullPolicy: Always
          name: akita
          args:
          - apidump
          - --project
          - <your project name here>
          - --rate-limit
          - "200"

Tagging

You can add tags to help you identify the source of the incoming data. Use the --tags argument with akita apidump and include a comma-separated list of key=value pairs.

args:
   ...
   - --tags
   - owner=mark,namespace=staging

For tagging deployments, use separate projects to separate data from test, staging, and production into different models. See Tag Your Traffic with Versions.

Tagging traces and specs with Kubernetes information

You can use the --tags argument with akita apispec to specify key-value pairs that help you identify the source of a trace. The Akita Agent (in versions 0.16.1 and later) also recognizes the following environment variables and converts them into reserved tags. You can make this information available to the Akita container via the downward API.
All of the following tags are optional, and some have support in the Akita web console.

Environment variable

Tag

Suggested use

AKITA_DEPLOYMENT

x-akita-deployment

Identify the Kubernetes cluster, for example as "staging" or "deployment".

DEPRECATED: use a separate project instead.

AKITA_DEPLOYMENT_COMMIT

x-akita-git-commit

Records a Git commit hash; can be used to record the deployed version for a monorepo, or the last Terraform commit.

AKITA_AWS_REGION

x-akita-aws-region

Amazon Web Services region in which the cluster is running, if applicable.

AKITA_K8S_NAMESPACE

x-akita-kubernetes-namespace

Kubernetes namespace in which the capture agent is running.

AKITA_K8S_NODE

x-akita-kubernetes-node

Identifier of the node on which the capture agent is running.

AKITA_K8S_HOST_IP

x-akita-kubernetes-host-ip

Host IP of the node.

AKITA_K8S_POD

x-akita-kubernetes-pod

Name of the pod which captured the trace.

AKITA_K8S_POD_IP

x-akita-kubernetes-pod-ip

IP address of the pod.

AKITA_K8S_DAEMONSET

x-akita-kubernetes-daemonset

Name of the Daemonset used to create the pod.

Adding the following code in the env section of the Daemonset or pod definition will extract all the available information from the Kubernetes Downward API. The other variables listed in the table would need to be configured to static values, or filled at creation time by a Terraform module.

env:
        - name: AKITA_K8S_NODE
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: AKITA_K8S_POD
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: AKITA_K8S_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: AKITA_K8S_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: AKITA_K8S_HOST_IP
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP

Remove APIs

You may want to filter out the Kubernetes control traffic itself, which you can do by adding --filter "not port 80" to the akita learn command line:

args:
   ...
   - --filter
   - not port 80

Create pod definition

If you want to look at only a particular service or a particular node, directly create a single pod using the example shown below. This YAML file creates a single pod named akita-capture, which collects API traces from a service running on port 50100, for 10 minutes:

apiVersion: v1
kind: Pod
metadata:
  name: akita-capture
spec:
  containers:
  - image: akitasoftware/cli:latest
    name: akita
    args:
    - learn
    - --filter
    - dst port 50100
    - -c
    - sleep 600
    - -u
    - root
    - --project
    - my-project-name
    env:
    - name: AKITA_API_KEY_ID
      valueFrom:
        secretKeyRef:
          name: akita-secrets
          key: api-key-id
    - name: AKITA_API_KEY_SECRET
      valueFrom:
        secretKeyRef:
          name: akita-secrets
          key: api-key-secret
  dnsPolicy: ClusterFirst
  hostNetwork: true
  restartPolicy: Never

This example uses normal Kubernetes scheduling to decide where to run the new pod. To control which host is used add a node selector to the rule, like this:

spec:
  nodeName: your-node-name

or use a pod affinity rule.

Once the collection has finished, you will have to delete the pod manually.


Did this page help you?