- Quick Start
- Custom Filters
- Deploying to Kubernetes from GitHub
- Knative Serverless Framework
- Prometheus monitoring
- The Mapping Resource
- Automatic Retries
- Canary Releases
- Circuit Breakers
- Cross-Origin Resource Sharing
- Method-Based Routing
- Prefix Regex
- Query Parameter-Based Routing
- Traffic Shadowing
- The Ambassador Module
- Custom Error Responses
- Gzip Compression
- Host CRD, ACME Support, and External Load Balancer Configuration
- Ingress Controller
- Scaling Ambassador
- Developer Portal
While preview URLs are a powerful feature, there are other options to use Telepresence for proxying traffic between your laptop and the cluster.
It is assumed that you have the demo web app from the tutorial running in your cluster, but deployment names used below can be substituted for any other running deployment.
Connecting to the cluster instead of running an intercept will allow you to access cluster deployments as if your laptop was another pod in the cluster. You will be able to access other Kubernetes services using
<servicename>.<namespace>, for example by curling a service from your terminal. A service running on your laptop will also be able to interact with other services on the cluster by name.
Connecting to the cluster starts the background daemon on your machine and installs the Traffic Manager pod into the cluster of your current
kubectl context. The Traffic Manager handles the service proxying.
telepresence connect, you will be prompted for your password to run the daemon.$ telepresence connectLaunching Telepresence Daemon v2.0.0 (api v3)Need root privileges to run "/usr/local/bin/telepresence daemon-foreground"Password:Connecting to traffic manager...Connected to context default (https://<cluster-public-IP>)
telepresence statusto confirm that you are connected to your cluster and are proxying traffic to it.$ telepresence statusConnectedContext: default (https://<cluster-public-IP>)Proxy: ON (networking to the cluster is enabled)Intercepts: 0 total
Now try to access your service by name with
curl verylargejavaservice.default:8080. Telepresence will route the request to the cluster, as if your laptop is actually running in the cluster.$ curl verylargejavaservice.default:8080<!DOCTYPE HTML><html><head><title>Welcome to the EdgyCorp WebApp</title>...
Terminate the client with
telepresence quitand try to access the service again, it will fail because traffic is no longer being proxied from your laptop.$ telepresence quitTelepresence Daemon quitting...done
By default, Telepresence will provide access to all Services found in all namespaces in the connected cluster. This might lead to problems if the user does not have access permissions to all namespaces via RBAC. The
--mapped-namespaces <comma separated list of namespaces> flag was added to give the user control over exactly which namespaces will be accessible.
When using this option, it is important to include all namespaces containing services to be accessed and also all namespaces that contain services that those intercepted services might use.
An intercept with the flag
--local-only can be used to control outbound connectivity to specific namespaces.
When developing services that have not yet been deployed to the cluster, it can be necessary to provide outbound connectivity to the namespace where the service is intended to be deployed so that it can access other services in that namespace without using qualified names.
$ telepresence intercept [name of intercept] --namespace [name of namespace] --local-only
The resources in the given namespace can now be accessed using unqualified names as long as the intercept is active. The intercept is deactivated just like any other intercept.
$ telepresence leave [name of intercept]
The unqualified name access is now removed provided that no other intercept is active and using the same namespace.