You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<Body>-> Telepresence not only detects when the cluster's subnets are in conflict with subnets on the workstation, it will also avoid such conflicts by doing network address translations, placing a conflicting subnet in a virtual subnet.</Body>
13
+
<Body>Telepresence not only detects when the cluster's subnets are in conflict with subnets on the workstation, it will also avoid such conflicts by doing network address translations, placing a conflicting subnet in a virtual subnet.</Body>
<Body>-> It is now possible to use a virtual subnet without routing the affected IPs to a specific workload. A new `telepresence connect --vnat CIDR` flag was added that will perform virtual network address translation of cluster IPs. This flag is very similar to the `--proxy-via CIDR=WORKLOAD` introduced in 2.19, but without the need to specify a workload.</Body>
17
+
<Body>It is now possible to use a virtual subnet without routing the affected IPs to a specific workload. A new `telepresence connect --vnat CIDR` flag was added that will perform virtual network address translation of cluster IPs. This flag is very similar to the `--proxy-via CIDR=WORKLOAD` introduced in 2.19, but without the need to specify a workload.</Body>
18
18
</Note>
19
19
<Note>
20
20
<Titletype="feature"docs="reference/intercepts/container">Intercepts targeting a specific container</Title>
21
-
<Body>-> In certain scenarios, the container owning the intercepted port differs from the container the intercept targets. This port owner's sole purpose is to route traffic from the service to the intended container, often using a direct localhost connection.
21
+
<Body>In certain scenarios, the container owning the intercepted port differs from the container the intercept targets. This port owner's sole purpose is to route traffic from the service to the intended container, often using a direct localhost connection.
22
22
This update introduces a `--container <name>` option to the intercept command. While this option doesn't influence the port selection, it guarantees that the environment variables and mounts propagated to the client originate from the specified container. Additionally, if the `--replace` option is used, it ensures that this container is replaced.</Body>
<Body>The new `telepresence ingest` command, similar to `telepresence intercept`, provides local access to the volume mounts and environment variables of a targeted container. However, unlike `telepresence intercept`, `telepresence ingest` does not redirect traffic to the container and ensures that the mounted volumes are read-only.
27
27
An ingest requires a traffic-agent to be installed in the pods of the targeted workload. Beyond that, it's a client-side operation. This allows developers to have multiple simultaneous ingests on the same container.</Body>
<Body>The new `telepresence curl` command runs curl from within a container. The command requires that a connection has been established using `telepresence connect --docker`, and the container that runs `curl` will share the same network as the containerized telepresence daemon.</Body>
<Body>The new `telepresence docker-run <flags and arguments>` requires that a connection has been established using `telepresence connect --docker` It will perform a `docker run <flags and arguments>` and add the flag necessary to ensure that started container shares the same network as the containerized telepresence daemon.</Body>
36
36
</Note>
37
37
<Note>
@@ -54,15 +54,15 @@ See [Streaming Transitions from SPDY to WebSockets](https://kubernetes.io/blog/2
54
54
<Body>The OSS code-base will no longer report usage data to the proprietary collector at Ambassador Labs. The actual calls to the collector remain, but will be no-ops unless a proper collector client is installed using an extension point.</Body>
55
55
</Note>
56
56
<Note>
57
-
<Titletype="feature">Add deployments, statefulSets, replicaSets to workloads Helm chart value</Title>
57
+
<Titletype="feature"docs="reference/intecepts/sidecar#disable-workloads">Add deployments, statefulSets, replicaSets to workloads Helm chart value</Title>
58
58
<Body>The Helm chart value `workloads` now supports the kinds `deployments.enabled`, `statefulSets.enabled`, `replicaSets.enabled`. and `rollouts.enabled`. All except `rollouts` are enabled by default. The traffic-manager will ignore workloads, and Telepresence will not be able to intercept them, if the `enabled` of the corresponding kind is set to `false`.</Body>
<Body>The auto-completion of namespaces, services, and containers have been added where appropriate, and the default file auto completion has been removed from most commands.</Body>
63
63
</Note>
64
64
<Note>
65
-
<Titletype="feature">Docker run flags --publish, --expose, and --network now work with docker mode connections</Title>
65
+
<Titletype="feature"docs="reference/docker-run#the-telepresence-docker-run-command">Docker run flags --publish, --expose, and --network now work with docker mode connections</Title>
66
66
<Body>After establishing a connection to a cluster using `telepresence connect --docker`, you can run new containers that share the same network as the containerized daemon that maintains the connection. This enables seamless communication between your local development environment and the remote services.
67
67
Normally, Docker has a limitation that prevents combining a shared network configuration with custom networks and exposing ports. However, Telepresence now elegantly circumvents this limitation so that a container started with `telepresence docker-run`, `telepresence intercept --docker-run`, or `telepresence ingest --docker-run` can use flags like `--network`, `--publish`, or `--expose`.
68
68
To achieve this, Telepresence temporarily adds the necessary network to the containerized daemon. This allows the new container to join the same network. Additionally, Telepresence starts extra socat containers to handle port mapping, ensuring that the desired ports are exposed to the local environment.</Body>
@@ -74,7 +74,7 @@ These recursions can now be prevented by setting the client configuration proper
74
74
</Note>
75
75
<Note>
76
76
<Titletype="feature">Allow Helm chart to be included as a sub-chart</Title>
77
-
<Body>The Helm chart previously had the unnecessary restriction that the .Release.Name under which telepresence is installed is literally called "traffic-manager". This restriction was preventing telepresence from being included as a sub-chart in a parent chart called anything but "traffic-manager". This restriction has been lifted.</Body>
77
+
<Body>The Helm chart previously had the unnecessary restriction that the .Release.Name under which telepresence is installed is literally called "traffic-manager". This restriction was preventing telepresence from being included as a sub-chart in a parent chart called anything but "traffic-manager". This restriction has been lifted.</Body>
78
78
</Note>
79
79
<Note>
80
80
<Titletype="change">During an intercept, the local port defaults to the targeted port of the intercepted container instead of 8080.</Title>
@@ -119,15 +119,15 @@ If a user should require the pod-subnet to be mapped, it can be added to the `cl
119
119
<Body>Telepresence is now capable of easily find telepresence gather-logs by certain timestamp.</Body>
120
120
</Note>
121
121
<Note>
122
-
<Titletype="feature"docs="reference/intercepts/cli#intercepting-without-a-service">Enable intercepts of workloads that have no service.</Title>
122
+
<Titletype="feature"docs="https://telepresence.io/docs/reference/intercepts/cli#intercepting-without-a-service">Enable intercepts of workloads that have no service.</Title>
123
123
<Body>Telepresence is now capable of intercepting workloads that have no associated service. The intercept will then target container port instead of a service port. The new behavior is enabled by adding a <code>telepresence.getambassador.io/inject-container-ports</code> annotation where the value is a comma separated list of port identifiers consisting of either the name or the port number of a container port, optionally suffixed with `/TCP` or `/UDP`.</Body>
124
124
</Note>
125
125
<Note>
126
126
<Titletype="feature"docs="https://artifacthub.io/packages/helm/telepresence-oss/telepresence-oss">Publish the OSS version of the telepresence Helm chart</Title>
127
127
<Body>The OSS version of the telepresence helm chart is now available at ghcr.io/telepresenceio/telepresence-oss, and can be installed using the command:<br/> <code>helm install traffic-manager oci://ghcr.io/telepresenceio/telepresence-oss --namespace ambassador --version 2.20.0</code> The chart documentation is published at <ahref="https://artifacthub.io/packages/helm/telepresence-oss/telepresence-oss">ArtifactHUB</a>.</Body>
128
128
</Note>
129
129
<Note>
130
-
<Titletype="feature"docs="reference/environment">Control the syntax of the environment file created with the intercept flag --env-file</Title>
130
+
<Titletype="feature"docs="https://telepresence.io/docs/reference/environment">Control the syntax of the environment file created with the intercept flag --env-file</Title>
131
131
<Body>A new <code>--env-syntax <syntax></code> was introduced to allow control over the syntax of the file created when using the intercept flag <code>--env-file <file></code>. Valid syntaxes are "docker", "compose", "sh", "csh", "cmd", and "ps"; where "sh", "csh", and "ps" can be suffixed with ":export".</Body>
0 commit comments