Merge commit '9b8a53f621148710b01dea86c8d85627d8f6f9ad' into rel/tele…

…presence/v2.4.4

install/helm.md

@@ -4,6 +4,8 @@
 
 **Note** that installing the Traffic Manager through Helm will prevent `telepresence connect` from ever upgrading it. If you wish to upgrade a Traffic Manager that was installed via the Helm chart, please see the steps [below](#upgrading-the-traffic-manager)
 
+For more details on what the Helm chart installs and what can be configured, see the Helm chart [README](https://github.com/telepresenceio/telepresence/tree/release/v2/charts/telepresence).
+
 ## Before you begin
 
 The Telepresence Helm chart is hosted by Ambassador Labs and published at `https://app.getambassador.io`.
@@ -31,8 +33,6 @@ When you run the Helm chart, it installs all the components required for the Tel
    helm install traffic-manager --namespace ambassador datawire/telepresence
    ```
 
-For more details on what the Helm chart installs and what can be configured, take a look at the Helm chart [README](https://github.com/telepresenceio/telepresence/tree/release/v2/charts/telepresence).
-
 ### Install into custom namespace
 
 The Helm chart supports being installed into any namespace, not necessarily `ambassador`. Simply pass a different `namespace` argument to `helm install`.
@@ -57,7 +57,7 @@ clusters:
   name: example-cluster
 ```
 
-See [the kubeconfig documentation](../reference/config#manager) for more information.
+See [the kubeconfig documentation](../../reference/config#manager) for more information.
 
 ### Upgrading the Traffic Manager.
 
@@ -156,7 +156,7 @@ clientRbac:
 
 #### Namespace-scoped webhook
 
-If you wish to use the traffic-manager's [mutating webhook](../reference/cluster-config#mutating-webhook) with a namespace-scoped traffic manager, you will have to ensure that each namespace has an `app.kubernetes.io/name` label that is identical to its name:
+If you wish to use the traffic-manager's [mutating webhook](../../reference/cluster-config#mutating-webhook) with a namespace-scoped traffic manager, you will have to ensure that each namespace has an `app.kubernetes.io/name` label that is identical to its name:
 
 ```yaml
 apiVersion: v1

install/index.md

@@ -65,7 +65,7 @@ Follow one of our [quick start guides](../quick-start/) to start using Teleprese
 ## Installing nightly versions of Telepresence
 
 We build and publish the contents of the default branch, [release/v2](https://github.com/telepresenceio/telepresence), of Telepresence
-nightly, Monday through Friday.
+nightly, Monday through Friday, for macOS (Intel and M1 chips), Linux, and Windows.
 
 The tags are formatted like so: `vX.Y.Z-nightly-$gitShortHash`.
 

reference/client.md

@@ -9,17 +9,23 @@ The [Telepresence CLI client](../../quick-start) is used to connect Telepresence
 ## Commands
 
 A list of all CLI commands and flags is available by running `telepresence help`, but here is more detail on the most common ones.
+You can append `--help` to each command below to get even more information about its usage.
 
 | Command | Description |
 | --- | --- |
 | `connect` | Starts the local daemon and connects Telepresence to your cluster and installs the Traffic Manager if it is missing.  After connecting, outbound traffic is routed to the cluster so that you can interact with services as if your laptop was another pod (for example, curling a service by it's name) |
 | [`login`](login) | Authenticates you to Ambassador Cloud to create, manage, and share [preview URLs](../../howtos/preview-urls/)
 | `logout` | Logs out out of Ambassador Cloud |
-| `dashboard` | Reopens the Ambassador Cloud dashboard in your browser |
-| `preview` | Create or remove [preview URLs](../../howtos/preview-urls) for existing intercepts: `telepresence preview create <currently intercepted service name>` |
+| `license` | Formats a license from Ambassdor Cloud into a secret that can be [applied to your cluster](../cluster-config#add-license-to-cluster) if you require features of the extension in an air-gapped environment|
 | `status` | Shows the current connectivity status |
-| `quit` | Quits the local daemon, stopping all intercepts and outbound traffic to the cluster|
+| `quit` | Tell Telepresence daemons to quit |
 | `list` | Lists the current active intercepts |
 | `intercept` | Intercepts a service, run followed by the service name to be intercepted and what port to proxy to your laptop: `telepresence intercept <service name> --port <TCP port>`. This command can also start a process so you can run a local instance of the service you are intercepting. For example the following will intercept the hello service on port 8000 and start a Python web server: `telepresence intercept hello --port 8000 -- python3 -m http.server 8000`. A special flag `--docker-run` can be used to run the local instance [in a docker container](../docker-run). |
 | `leave` | Stops an active intercept: `telepresence leave hello` |
+| `preview` | Create or remove [preview URLs](../../howtos/preview-urls) for existing intercepts: `telepresence preview create <currently intercepted service name>` |
+| `loglevel` | Temporarily change the log-level of the traffic-manager, traffic-agents, and user and root daemons |
+| `gather-logs` | Gather logs from traffic-manager, traffic-agents, user, and root daemons, and export them into a zip file that can be shared with others or included with a github issue |
+| `version` | Show version of Telepresence CLI + Traffic-Manager (if connected) |
 | `uninstall` | Uninstalls Telepresence from your cluster, using the `--agent` flag to target the Traffic Agent for a specific workload, the `--all-agents` flag to remove all Traffic Agents from all workloads, or the `--everything` flag to remove all Traffic Agents and the Traffic Manager.
+| `dashboard` | Reopens the Ambassador Cloud dashboard in your browser |
+| `current-cluster-id` | Get cluster ID for your kubernetes cluster, used for [configuring license](../cluster-config#add-license-to-cluster) in an air-gapped environment |

reference/cluster-config.md

@@ -201,11 +201,6 @@ To solve this issue, you can use Telepresence's Mutating Webhook alternative mec
 workloads will then stay untouched and only the underlying pods will be modified to inject the Traffic
 Agent sidecar container and update the port definitions.
 
-<Alert severity="info">
-A current limitation of the Mutating Webhook mechanism is that the <code>targetPort</code> of your intercepted
-Service needs to point to the <strong>name</strong> of a port on your container, not the port number itself.
-</Alert>
-
 Simply add the `telepresence.getambassador.io/inject-traffic-agent: enabled` annotation to your
 workload template's annotations:
 
@@ -238,3 +233,53 @@ in the service. This is necessary when the service has multiple ports.
      spec:
        containers:
 ```
+
+### Note on Numeric Ports
+
+If the <code>targetPort</code> of your intercepted service is pointing at a port number, in addition to
+injecting the Traffic Agent sidecar, Telepresence will also inject an <code>initContainer</code> that will
+reconfigure the pod's firewall rules to redirect traffic to the Traffic Agent.
+
+<Alert severity="info">
+Note that this <code>initContainer</code> requires `NET_ADMIN` capabilities.
+If your cluster administrator has disabled them, you will be unable to use numeric ports with the agent injector.
+</Alert>
+
+For example, the following service is using a numeric port, so Telepresence would inject an initContainer into it:
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: your-service
+spec:
+  type: ClusterIP
+  selector:
+    service: your-service
+  ports:
+    - port: 80
+      targetPort: 8080
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: your-service
+  labels:
+    service: your-service
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      service: your-service
+  template:
+    metadata:
+      annotations:
+        telepresence.getambassador.io/inject-traffic-agent: enabled
+      labels:
+        service: your-service
+    spec:
+      containers:
+        - name: your-container
+          image: jmalloc/echo-server
+          ports:
+            - containerPort: 8080
+```

reference/routing.md

@@ -21,7 +21,7 @@ Linux systems that aren't configured with `systemd-resolved` will use this resol
 ### Routing
 
 #### Subnets
-The Telepresence `traffic-manager` service is responsible for discovering the cluster's Service subnet and all subnets used by the pods. In order to do this, it needs permission to create a dummy service[<sup>[2](#servicesubnet)</sup>] in its own namespace, and the ability to list, get, and watch nodes and pods. Some clusters will expose the pod subnets as `podCIDR` in the `Node` but some, like Amazon EKS, typically don't. Telepresence will then fall back to deriving the subnets from the IPs of all pods.
+The Telepresence `traffic-manager` service is responsible for discovering the cluster's service subnet and all subnets used by the pods. In order to do this, it needs permission to create a dummy service[<sup>[2](#servicesubnet)</sup>] in its own namespace, and the ability to list, get, and watch nodes and pods. Most clusters will expose the pod subnets as `podCIDR` in the `Node` while others, like Amazon EKS, don't. Telepresence will then fall back to deriving the subnets from the IPs of all pods. If you'd like to choose a specific method for discovering subnets, or want to provide the list yourself, you can use the `podCIDRStrategy` configuration value in the [helm](../install/helm) chart to do that.
 
 The complete set of subnets that the [VIF](../tun-device) will be configured with is dynamic and may change during a connection's life cycle as new nodes arrive or disappear from the cluster. The set consists of what that the traffic-manager finds in the cluster, and the subnets configured using the [also-proxy](../config#alsoproxy) configuration option. Telepresence will remove subnets that are equal to, or completely covered by, other subnets.
 

releaseNotes.yml

@@ -38,6 +38,84 @@ docDescription: >-
 changelog: https://github.com/telepresenceio/telepresence/blob/$branch$/CHANGELOG.md
 
 items:
+  - version: 2.4.4
+    date: '2021-09-27'
+    notes:
+      - type: feature
+        title: Numeric ports in agent injector
+        body: >-
+          The agent injector now supports injecting Traffic Agents into pods that have unnamed ports.
+        docs: reference/cluster-config/#note-on-numeric-ports
+
+      - type: feature
+        title: New subcommand to gather logs and export into zip file
+        body: >-
+          Telepresence has logs for various components (the <code>
+          traffic-manager</code>, <code>traffic-agents</code>, the root and
+          user daemons), which are integral for understanding and debugging
+          Telepresence behavior.  We have added the <code>telepresence
+          gather-logs</code> 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 <code>telepresence gather-logs --help
+          </code>.
+        docs: reference/client
+        image: telepresence-2.4.4-gather-logs.png
+
+      - type: feature
+        title: Pod CIDR strategy is configurable in Helm chart
+        body: >-
+          Telepresence now enables you to directly configure how to get
+          pod CIDRs when deploying Telepresence with the Helm chart.
+          The default behavior remains the same. We've also introduced
+          the ability to explicitly set what the pod CIDRs should be.
+        docs: install/helm
+
+      - type: bugfix
+        title: Compute pod CIDRs more efficiently
+        body: >-
+          When computing subnets using the pod CIDRs, the traffic-manager
+          now uses less CPU cycles.
+        docs: reference/routing/#subnets
+
+      - type: bugfix
+        title: Prevent busy loop in traffic-manager
+        body: >-
+          In some circumstances, the <code>traffic-manager</code>'s CPU
+          would max out and get pinned at its limit. This required a
+          shutdown or pod restart to fix. We've added some fixes
+          to prevent the traffic-manager from getting into this state.
+
+      - type: bugfix
+        title: Added a fixed buffer size to TUN-device
+        body: >-
+          The TUN-device now has a max buffer size of 64K. This prevents the
+          buffer from growing limitlessly until it receies a PSH, which could
+          be a blocking operation when receiving lots of TCP-packets.
+        docs: reference/tun-device
+
+      - type: bugfix
+        title: Fix hanging user daemon
+        body: >-
+          When Telepresence encountered an issue connecting to the cluster or
+          the root daemon, it could hang indefintely. It now will error correctly
+          when it encounters that situation.
+
+      - type: bugfix
+        title: Improved proprietary agent connectivity
+        body: >-
+          To determine whether the environment cluster is air-gapped, the
+          proprietary agent attempts to connect to the cloud during startup.
+          To deal with a possible initial failure, the agent backs off
+          and retries the connection with an increasing backoff duration.
+
+      - type: bugfix
+        title: Telepresence correctly reports intercept port conflict
+        body: >-
+          When creating a second intercept targetting the same local port,
+          it now gives the user an informative error message. Additionally,
+          it tells them which intercept is currently using that port to make
+          it easier to remedy.
 
   - version: 2.4.3
     date: '2021-09-15'

versions.yml

@@ -1,4 +1,4 @@
-version: "2.4.0"
+version: "2.4.3"
 dlVersion: "latest"
 docsVersion: "pre-release"
 branch: release/v2