Installing the Akita agent using Kubernetes
Getting started with Akita is as simple as dropping our Agent into your cluster. Once we’re in, we gather all the data you need and surface it in the Akita app so you can easily see what your system is doing.
To use Akita with applications hosted in a Kubernetes cluster, we support:
- AWS EKS
- Sidecars for Single-Service Kubernetes
- Kubernetes Host Networking, and
- Kubernetes with Istio/Envoy
If you want to test Akita out, we recommend that you install the Akita Agent as a sidecar in one of your services. This approach will work in the largest variety of environments, but it has some downsides:
- Each service that you want to monitor will have to be reconfigured.
- Each pod runs its own sidecar, so there are many instances of the Akita agent running, each consuming CPU and memory.
The advantage of this approach is that your service's API traffic might only appear unencrypted within the boundaries of a pod. For example, you might be using Istio or Envoy as a sidecar, or Nginx as a reverse proxy. In this case the traffic to and from the pod is encrypted, but the traffic between the proxy and the application is unencrypted.
For longer-term use in production and staging environment, we suggest using Kubernetes Host Networking. This configuration allow one Akita Agent to monitor all pods on a single host, which is a more efficient mode of operation, but only if the communication between pods is unencrypted.
If your HTTPS traffic terminates at your application (for example, the application is configured with your site certificates), then neither approach will allow Akita to see unencrypted traffic. But, it is common in Kubernetes environments to terminate TLS at a service mesh, reverse proxy, or load balancer.
Want to try Akita without installing the Agent?
If you want to see Akita map out an API spec from one of your favorite websites, check out our OpenAPI Spec Generator Chrome extension.
Updated 22 days ago