Telepresence Release Notes

The strategy used when selecting the application protocol for personal intercepts can now be configured using the intercept.appProtocolStrategy in the config.yml file.

Telepresence now uses Github Actions for doing unit and integration testing. It is now easier for contributors to run tests on PRs since maintainers can add an "ok to test" label to PRs (including from forks) to run integration tests.

There is a new subcommand, test-vpn, that can be used to diagnose connectivity issues with a VPN. See the VPN docs for more information on how to use it.

A RESTful service was added to Telepresence, both locally to the client and to the traffic-agent to help determine if messages with a set of headers should be consumed or not from a message queue where the intercept headers are added to the messages.

Adding the flag --get-pod-yaml to your request will get the pod yaml manifest for all kubernetes components you are getting logs for ( traffic-manager and/or pods containing a traffic-agent container). This flag is set to false by default.

Adding the flag --anonymize to your command will anonymize your pod names + namespaces in the output file. We replace the sensitive names with simple names (e.g. pod-1, namespace-2) to maintain relationships between the objects without exposing the real names of your objects. This flag is set to false by default.

Previously, we referred to OSI model layers when asking these questions, but this terminology is not commonly used. The questions now provide a clearer context for the user, along with a default answer as an example.

Telepresence has logs for various components (the traffic-manager, traffic-agents, the root and user daemons), which are integral for understanding and debugging Telepresence behavior. We have added the telepresence gather-logs command to make it simple to compile logs for all Telepresence components and export them in a zip file that can be shared to others and/or included in a github issue. For more information on usage, run telepresence gather-logs --help .

We now support configuring the host and port for the cloud in your config.yml. These are used when logging in to utilize features provided by an extension, and are also passed along as environment variables when installing the `traffic-manager`. Additionally, we now run our testsuite with these variables set to localhost to continue to ensure Telepresence is fully fuctional without depeneding on an external service. The SYSTEMA_HOST and SYSTEMA_PORT environment variables are no longer used.

There is now a native Windows client for Telepresence that is being released as a Developer Preview. All the same features supported by the MacOS and Linux client are available on Windows.

Telepresence can now receive messages from Ambassador Cloud and raise them to the user when they perform certain commands. This enables us to send you messages that may enhance your Telepresence experience when using certain commands. Frequency of messages can be configured in your config.yml.

telepresence login now has an --apikey=KEY flag that allows for non-interactive logins. This is useful for headless environments where launching a web-browser is impossible, such as cloud shells, Docker containers, or CI.

We now support installing multiple traffic managers in the same cluster. This will allow operators to install deployments of telepresence that are limited to certain namespaces.

We now support configuring which agent image + registry to use in the config. This enables users whose laptop is an air-gapped environment to create personal intercepts without requiring a login. It also makes it easier for those who are developing on Telepresence to specify which agent image should be used. Env vars TELEPRESENCE_AGENT_IMAGE and TELEPRESENCE_REGISTRY are no longer used.

The default max size of messages received through gRPC (4 MB) is sometimes insufficient. It can now be configured.

While Telepresence will auto-detect if your cluster is in an air-gapped environment, we've added an option users can add to their config.yml to ensure the cli acts like it is in an air-gapped environment. Air-gapped environments require a manually installed licence.

Some log statements were printing incorrect characters, when they should have been IP addresses. This has been resolved to include more accurate and useful logging.

If multiple services matched a workload when performing an intercept, Telepresence would crash. It now gives the correct error message, instructing the user on how to specify which service the intercept should use.

Telepresence now supports installing the Traffic Manager via Helm. This will make it easy for operators to install and configure the server-side components of Telepresence separately from the CLI (which in turn allows for better separation of permissions).

As the traffic-manager can now be installed in any namespace via Helm, Telepresence can now be configured to look for the Traffic Manager in a namespace other than ambassador. This can be configured on a per-cluster basis.

telepresence intercept now supports a --to-pod flag that can be used to port-forward sidecars' ports from an intercepted pod.

The mutator webhook for injecting traffic-agents now recognizes a telepresence.getambassador.io/inject-service-port annotation to specify which port to intercept; bringing the functionality of the --port flag to users who use the mutator webook in order to control Telepresence via GitOps.

Telepresence will now detect the Pod CIDR ranges even if they are not listed in the Nodes.

Telepresence now supports per-cluster configuration for custom dns behavior, which will enable users to determine which local + remote resolver to use and which suffixes should be ignored + included. These can be configured on a per-cluster basis.

Telepresence now supports also proxying user-specified subnets so that they can access external services only accessible to the cluster while connected to Telepresence. These can be configured on a per-cluster basis and each subnet is added to the TUN device so that requests are routed to the cluster for IPs that fall within that subnet.

The Traffic Manager now contains a mutating webhook to automatically add an agent to pods that have the telepresence.getambassador.io/traffic-agent: enabled annotation. This enables Telepresence to work well with GitOps CD platforms that rely on higher level kubernetes objects matching what is stored in git. For workloads without the annotation, Telepresence will add the agent the way it has in the past

The trafficManagerConnect timeout default has changed from 20 seconds to 60 seconds, in order to facilitate the extended time it takes to apply everything needed for the mutator webhook.

Fix a tun-device bug where sometimes large transfers from services on the cluster would hang indefinitely

Now that the Telepresence rewrite is the main version of Telepresence, you can install it via Brew like so: brew install datawire/blackbird/telepresence.

Telepresence can now be installed via brew on macOS, which makes it easier for users to stay up-to-date with the latest telepresence version. To install via brew, you can use the following command: brew install datawire/blackbird/telepresence2.

Telepresence will now perform routing of outbound TCP and UDP traffic via a Virtual Network Interface (VIF). The VIF is a layer 3 TUN-device that exists while Telepresence is connected. It makes the subnets in the cluster available to the workstation and will also route DNS requests to the cluster and forward them to intercepted pods. This means that pods with custom DNS configuration will work as expected. Prior versions of Telepresence would use firewall rules and were only capable of routing TCP.

All traffic between the client and the cluster is now tunneled via the traffic manager gRPC API. This means that Telepresence no longer uses ssh tunnels and that the manager no longer have an sshd installed. Volume mounts are still established using sshfs but it is now configured to communicate using the sftp-protocol directly, which means that the traffic agent also runs without sshd. A desired side effect of this is that the manager and agent containers no longer need a special user configuration.

Telepresence can now be run inside a Docker container. This can be useful for avoiding side effects on a workstation's network, establishing multiple sessions with the traffic manager, or working with different clusters simultaneously.

Telepresence now supports configuring the log level for Root Daemon and User Daemon logs. This provides control over the nature and volume of information that Telepresence generates in daemon.log and connector.log.

Telepresence is now able to translate common legacy Telepresence commands into native Telepresence commands. So if you want to get started quickly, you can just use the same legacy Telepresence commands you are used to with the new Telepresence binary.