update NetFoundry -> Ziti in surgical places
# Kubernetes Sidecar Client
-This guide shows you how to access a NetFoundry service from a pre-existing (or third party) application that's running
-in a Kubernetes Pod. To provide access to the service, we will deploy the `ziti-tunnel` NetFoundry client in a sidecar
+This guide shows you how to access a Ziti service from a pre-existing (or third party) application that's running
+in a Kubernetes Pod. To provide access to the service, we will deploy the `ziti-tunnel` client in a sidecar
container.
## Overview
@@ -11,7 +11,7 @@ walked you through standing up a Ziti instance and accessing a Ziti service from
`ziti-tunnel`. In this guide we'll deploy the same `ziti-tunnel` client, but instead of running it from the
command line we will deploy it in a sidecar container in a Kubernetes Pod.
-This guide also demonstrates `ziti-tunnel`'s internal DNS server, which allows us to access NetFoundry services
+This guide also demonstrates `ziti-tunnel`'s internal DNS server, which allows us to access Ziti services
by hostname instead of IP address.
[Here's some detail on how the various intercept modes work on Linux](https://netfoundry.github.io/ziti-doc/ziti/clients/linux.html)
@@ -53,7 +53,7 @@ We can mount the JWT as a secret like this:
Deploy a Pod that runs a client application and `ziti-tunnel` as a sidecar container. For this
demonstration, the client application is `wget`. Our Pod runs `wget` in a loop so we can see content
-from our NetFoundry service in the Pod's logs.
+from our Ziti service in the Pod's logs.
Save the following yaml to a file named tunnel-sidecar-demo.yaml
