add diagram

Author: ranbel

src/assets/images/cloudflare-one/connections/connect-apps/kubernetes-tunnel.png

@@ -11,12 +11,12 @@ This tutorial will cover how to expose a Kubernetes service to the public Intern
 
 ## Architecture
 
-![placeholder](~/assets/images/cloudflare-one/connections/connect-apps/handshake.jpg)
+![Diagram showing how a user connects to Kubernetes services through Cloudflare Tunnel](~/assets/images/cloudflare-one/connections/connect-apps/kubernetes-tunnel.png)
 
 As shown in the diagram, we recommend setting up `cloudflared` as an adjacent deployment to the application deployments. Having a separate Kubernetes deployment for `cloudflared` allows you to scale `cloudflared` independently of the application. In the `cloudflared` deployment, you can spin up [multiple replicas](/cloudflare-one/connections/connect-networks/configure-tunnels/tunnel-availability/) running the same Cloudflare Tunnel -- there is no need to build a dedicated tunnel for each pod. Each `cloudflared` replica / pod can reach all Kubernetes services in the cluster.
 
 :::note
-We do not recommend using `cloudflared` in autoscaling setups because downscaling (removing replicas) will break any existing user connections to that replica. Additionally, `cloudflared` does not load balance across replicas; replicas are strictly for high availability. To load balance traffic to your nodes, you can use [Cloudflare Load Balancer](/load-balancing/private-network/) or a third-party load balancer.
+We do not recommend using `cloudflared` in autoscaling setups because downscaling (removing replicas) will break existing user connections to that replica. Additionally, `cloudflared` does not load balance across replicas; replicas are strictly for high availability. To load balance traffic to your nodes, you can use [Cloudflare Load Balancer](/load-balancing/private-network/) or a third-party load balancer.
 :::
 
 Once the cluster is connected to Cloudflare, you can configure Cloudflare Tunnel routes to control how `cloudflared` will proxy traffic to services within the cluster. For example, you may wish to publish certain Kubernetes application to the Internet and restrict other applications to internal WARP client users.