(from getambassador.io) Sometimes use workloads instead of Deployments

Since we are adding the ability to intercept ReplicaSets (and future
workloads in the future), I've changed some of the wording in some
places to say "workloads" so it doesn't sound like we are only talking
about deployments.  I have left a lot of specific mentions of
intercepting deployments because I think that's still valid and what
most people will be using telepresence for

faqs.md

@@ -12,7 +12,7 @@ Telepresence enables you to connect your local development machine seamlessly to
 
 Ultimately, this empowers you to develop services locally and still test integrations with dependent services or data stores running in the remote cluster. 
 
-You can “intercept” any requests made to a target Kubernetes deployment, and code and debug your associated service locally using your favourite local IDE and in-process debugger. You can test your integrations by making requests against the remote cluster’s ingress and watching how the resulting internal traffic is handled by your service running locally.
+You can “intercept” any requests made to a target Kubernetes workload, and code and debug your associated service locally using your favourite local IDE and in-process debugger. You can test your integrations by making requests against the remote cluster’s ingress and watching how the resulting internal traffic is handled by your service running locally.
 
 By using the preview URL functionality you can share access with additional developers or stakeholders to the application via an entry point associated with your intercept and locally developed service. You can make changes that are visible in near real-time to all of the participants authenticated and viewing the preview URL. All other viewers of the application entrypoint will not see the results of your changes.
 
@@ -63,7 +63,7 @@ You can connect to databases or middleware running in the cluster, such as MySQL
 
 Telepresence will discover/prompt during first use for this info and make its best guess at figuring this out and ask you to confirm or update this. 
 
-** Will Telepresence be able to intercept deployments running on a private cluster or cluster running within a virtual private cloud (VPC)?**
+** Will Telepresence be able to intercept workloads running on a private cluster or cluster running within a virtual private cloud (VPC)?**
 
  Yes. The cluster has to have outbound access to the internet for the preview URLs to function correctly, but it doesn’t need to have a publicly accessible IP address. 
 
@@ -79,7 +79,7 @@ On Fedora, Telepresence also creates a virtual network device (a TUN network) fo
 
  A single Traffic Manager service is deployed in the `ambassador` namespace within your cluster, and this manages resilient intercepts and connections between your local machine and the cluster.
 
-A Traffic Agent container is injected per pod that is being intercepted. The first time a deployment is intercepted all pods associated with this deployment will be restarted with the Traffic Agent automatically injected.
+A Traffic Agent container is injected per pod that is being intercepted. The first time a workload is intercepted all pods associated with this workload will be restarted with the Traffic Agent automatically injected.
 
 ** How can I remove all of the Telepresence components installed within my cluster?**
 

howtos/outbound.md

@@ -12,7 +12,7 @@ While preview URLs are a powerful feature, there are other options to use Telepr
 
 ## Proxying Outbound Traffic
 
-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 `<service name>.<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 instead of running an intercept will allow you to access cluster workloads as if your laptop was another pod in the cluster. You will be able to access other Kubernetes services using `<service name>.<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](../../reference/architecture/) into the cluster of your current `kubectl` context.  The Traffic Manager handles the service proxying.
 

reference/architecture.md

@@ -36,7 +36,7 @@ URL, it forwards the request to the ingress service specified at the Preview URL
 ## Traffic Agent
 
 The Traffic Agent is a sidecar container that facilitates intercepts. When an intercept is started, the Traffic Agent
-container is injected into the deployment's pod(s). You can see the Traffic Agent's status by running `kubectl describe
+container is injected into the workload's pod(s). You can see the Traffic Agent's status by running `kubectl describe
 pod <pod-name>`.
 
 Depending on the type of intercept that gets created, the Traffic Agent will either route the incoming request to the

reference/client.md

@@ -22,4 +22,4 @@ A list of all CLI commands and flags is available by running `telepresence help`
 | `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` |
 | `leave` | Stops an active intercept: `telepresence leave hello` | 
-| `uninstall` | Uninstalls Telepresence from your cluster, using the `--agent` flag to target the Traffic Agent for a specific deployment, the `--all-agents` flag to remove all Traffic Agents from all deployments, or the `--everything` flag to remove all Traffic Agents and the Traffic Manager.
+| `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.

reference/intercepts.md

@@ -8,26 +8,30 @@ In order to do this, it will prompt you for four options.  For the first, `Ingre
 
 Also because you're logged in, Telepresence will default to `--mechanism=http --http-match=auto` (or just `--http-match=auto`; `--http-match` implies `--mechanism=http`). If you hadn't been logged in it would have defaulted to `--mechanism=tcp`.  This tells it to do smart intercepts and only intercept a subset of HTTP requests, rather than just intercepting the entirety of all TCP connections.  This is important for working in a shared cluster with teammates, and is important for the preview URL functionality.  See `telepresence intercept --help` for information on using `--http-match` to customize which requests it intercepts.
 
+## Supported Workloads
+Kubernetes has various [workloads](https://kubernetes.io/docs/concepts/workloads/). Currently, telepresence supports intercepting Deployments and ReplicaSets.
+<Alert severity="info"> While many of our examples may use Deployments, they would also work on ReplicaSets </Alert>
+
 ## Specifying a namespace for an intercept
 
-The namespace of the intercepted deployment is specified using the `--namespace` option. When this option is used, and `--deployment` is not used, then the given name is interpreted as the name of the deployment and the name of the intercept will be constructed from that name and the namespace.
+The namespace of the intercepted workload is specified using the `--namespace` option. When this option is used, and `--workload` is not used, then the given name is interpreted as the name of the workload and the name of the intercept will be constructed from that name and the namespace.
 
 ```
 telepresence intercept hello --namespace myns --port 9000
 ```
 
-This will intercept a Deployment named "hello" and name the intercept
+This will intercept a workload named "hello" and name the intercept
 "hello-myns".  In order to remove the intercept, you will need to run
 `telepresence leave hello-mydns` instead of just `telepresence leave
 hello`.
 
-The name of the intercept will be left unchanged if the deployment is specified.
+The name of the intercept will be left unchanged if the workload is specified.
 
 ```
-telepresence intercept myhello --namespace myns --deployment hello --port 9000
+telepresence intercept myhello --namespace myns --workload hello --port 9000
 ```
 
-This will intercept a deployment named "hello" and name the intercept "myhello".
+This will intercept a workload named "hello" and name the intercept "myhello".
 
 ## Importing Environment Variables
 
@@ -52,7 +56,7 @@ This will output a header that you can set on your request for that traffic to b
 ```
 $ telepresence intercept <deployment name>  --port=<TCP port> --preview-url=false
   
-  Using deployment <deployment name> 
+  Using Deployment <deployment name>
   intercepted
       Intercept name: <full name of intercept>
       State         : ACTIVE
@@ -81,7 +85,7 @@ If you are trying to intercept a service that has multiple ports, you need to te
 
 ```
 telepresence intercept <base name of intercept> --port=<local TCP port>:<servicePortName>
-  Using deployment <name of deployment>
+  Using Deployment <name of deployment>
   intercepted
       Intercept name   : <full name of intercept>
       State            : ACTIVE