To deploy your application to a Kubernetes cluster, you need Octopus Deploy to know that the cluster exists and how to access it. The cluster is your deployment destination. To represent deployment destinations, Octopus uses deployment targets (a virtual entity).
There are two different deployment targets for deploying to Kubernetes, the Kubernetes Agent and the Kubernetes API targets.
The Kubernetes API target allows the Octopus Server to connect to a cluster via the API. In this scenario, your deployment tasks run outside of a cluster, typically on a worker.
The Kubernetes agent target requires the installation of a small executable in a cluster (agent). Octopus Server connects to the agent for deployments. In this scenario, your deployment tasks run inside the cluster.
The following table summarizes the key differences between the two targets.
| Kubernetes Agent | Kubernetes API | |
|---|---|---|
| Connection method | Polling agent in cluster | Direct API communication |
| Setup complexity | Generally simpler | Requires more setup |
| Security | No need to configure firewall No need to provide external access to cluster |
Depends on the cluster configuration |
| Requires workers | No | Yes |
| Requires public IP | No | Yes |
| Requires service account in Octopus | No | Yes |
| Limit deployments to a namespace | Yes | No |
| Planned support for upcoming observability features | Yes | No |
| Recommended usage scenario |
|
If you cannot install an agent on a cluster |
| Step configuration | Simple (you need to specify target tag) | More complex (requires target tags, workers, execution container images) |
| Maintenance |
|
|