Kubernetes App Discovery Architecture
- Version 15.x
- Version 14.x
- Version 13.x
- Version 12.x
- Older Versions
- Available for:
Kubernetes application auto-discovery consists of two parts:
- Periodically polling list of services in a Kubernetes cluster
- Creating Teleport apps based on that list and proxying requests to them.
This will only work when the Teleport agent runs inside the target Kubernetes cluster
The Discovery Service running in a Kubernetes cluster will periodically list services and filter them out
according to the matchers specified in
kubernetes filed of the service config. You can filter services based on
types, namespaces and service labels. All services by default currently
are considered of an "app" type, but it can be changed for a service by Kubernetes annotation
If type of a service doesn't equal the one specified in the matcher, service is ignored.
By default name of the created Teleport app will consist of Kubernetes service name, namespace and
Kubernetes cluster name:
$SERVICE_NAME-$NAMESPACE-$KUBE_CLUSTER_NAME. That name can be changed by Kubernetes annotation
Every port that is exposed by the service is considered separately, so one Kubernetes service can result in creation of multiple Teleport app resources, if more than one port is exposed on the service. In that case port name will be added to the app name.
By default, the Discovery Service will only try to expose ports that serve HTTP/HTTPS. To understand if this port serves HTTP, discovery will use several heuristics or will try to probe exposed port with a HEAD HTTP request.
Heuristics for determining if port serves HTTP/HTTPS are:
- if Kubernetes service port definition has
appProtocolfield, and it contains values
httpsit will be used in the URI.
- if exposed port's name is
httpsor it has numeric value 443,
httpswill be used.
- Teleport will perform HTTP request to the port to see if it serves HTTP/HTTPS requests
- if exposed port's name is
httpor it has numeric value 80 or 8080,
httpwill be used.
Otherwise, this port is ignored. But if annotation
teleport.dev/protocol is used on the service and its value is
"tcp", then this port will be exposed as a TCP app.
After relevant Kubernetes services were listed and filtered, the Discovery Service will create Teleport apps, reconciling existing and new ones:
- If a discovered app was not present at the Teleport backend, it will be created
- If a discovered app was already present at the backend, it will be updated
- If a discovered app was already present at the backend, but it was not found in the Kubernetes cluster anymore, it will be deleted.
App service runs on the Kubernetes cluster and proxies apps based on labels specified in the
resources field. All apps created by the
Discovery Service will have labels copied from the service of origin. In addition, label
teleport.dev/kubernetes-cluster will be set for
the app and it will be equal to the name of the Kubernetes cluster of origin. Discovery service uses
discovery_group property to get Kubernetes