Remove usages of curl inside istio-proxy (#5073)

* Remove usages of curl inside istio-proxy

Distroless builds of Istio do not contain curl, so we should not tell
users to use it. Pilot-agent handles this functionality for us

* Fix lint error

content/en/docs/ops/security/root-transition/index.md

@@ -130,7 +130,7 @@ please follow the procedure and check whether you will be affected.
     The following command shows an example to check the Envoy’s certificate for pod _foo_ running in namespace _bar_.
 
     {{< text bash>}}
-    $ kubectl exec -it foo -c istio-proxy -n bar -- curl http://localhost:15000/certs | head -c 1000
+    $ kubectl exec -foo -c istio-proxy -n bar -- pilot-agent request GET certs | head -c 1000
     {
      "certificates": [
       {

content/en/docs/ops/telemetry/envoy-stats/index.md

@@ -15,7 +15,7 @@ statistics the Envoy proxies record can provide more information about specific
 To see the statistics for a pod:
 
 {{< text bash >}}
-$ kubectl exec -it $POD  -c istio-proxy  -- sh -c 'curl localhost:15000/stats'
+$ kubectl exec $POD -c istio-proxy -- pilot-agent request GET stats
 {{< /text >}}
 
 See [the Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats)

content/en/docs/ops/troubleshooting/proxy-cmd/index.md

@@ -351,14 +351,8 @@ You should receive a response listing the "service-key" and "hosts" for each ser
 To find out the Envoy version used in deployment, you can `exec` into the container and query the `server_info` endpoint:
 
 {{< text bash >}}
-$ kubectl exec -it PODNAME -c istio-proxy -n NAMESPACE /bin/bash
-root@5c7e9d3a4b67:/# curl localhost:15000/server_info
-envoy 0/1.9.0-dev//RELEASE live 57964 57964 0
-{{< /text >}}
-
-In addition, the `Envoy` and `istio-api` repository versions are stored as labels on the image:
-
-{{< text bash >}}
-$ docker inspect -f '{{json .Config.Labels }}' ISTIO-PROXY-IMAGE
-{"envoy-vcs-ref":"b3be5713f2100ab5c40316e73ce34581245bd26a","istio-api-vcs-ref":"825044c7e15f6723d558b7b878855670663c2e1e"}
+$ kubectl exec -it PODNAME -c istio-proxy -n NAMESPACE pilot-agent request GET server_info
+{
+ "version": "48bc83d8f0582fc060ef76d5aa3d75400e739d9e/1.12.0-dev/Clean/RELEASE/BoringSSL"
+}
 {{< /text >}}

content/en/docs/ops/troubleshooting/security-issues/index.md

@@ -195,7 +195,7 @@ otherwise you should replace `"-l app=productpage"` with your actual pod.
 1. Run the following command to get the proxy configuration dump for the `productpage` service:
 
     {{< text bash >}}
-    $ kubectl exec  $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl localhost:15000/config_dump -s
+    $ kubectl exec  $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- pilot-agent request GET config_dump
     {{< /text >}}
 
 1. Check the log and verify:
@@ -268,7 +268,7 @@ otherwise you should replace `"-l app=productpage"` with your actual pod.
 1. Turn on the authorization debug logging in proxy with the following command:
 
     {{< text bash >}}
-    $ kubectl exec  $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -X POST localhost:15000/logging?rbac=debug -s
+    $ kubectl exec $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
     {{< /text >}}
 
 1. Verify you see the following output:

content/en/docs/tasks/traffic-management/circuit-breaking/index.md

@@ -230,7 +230,7 @@ one connection and request concurrently, you should see some failures when the
 1. Query the `istio-proxy` stats to see more:
 
     {{< text bash >}}
-    $ kubectl exec -it $FORTIO_POD  -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep httpbin | grep pending
+    $ kubectl exec $FORTIO_POD -c istio-proxy -- pilot-agent request GET stats | grep httpbin | grep pending
     cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_active: 0
     cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_failure_eject: 0
     cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_overflow: 12

content/en/docs/tasks/traffic-management/egress/egress-gateway/index.md

@@ -727,7 +727,7 @@ external service.
     counter is:
 
     {{< text bash >}}
-    $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/stats | grep edition.cnn.com.upstream_cx_total
+    $ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total
     cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
     {{< /text >}}
 
@@ -783,7 +783,7 @@ external service.
     If you get the certificate as in the output above, your traffic is routed correctly. Check the statistics of the egress gateway's proxy and see a counter that corresponds to your requests (sent by _openssl_ and _curl_) to _edition.cnn.com_.
 
     {{< text bash >}}
-    $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/stats | grep edition.cnn.com.upstream_cx_total
+    $ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total
     cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
     {{< /text >}}
 

content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md

@@ -210,7 +210,7 @@ the set of domains.
     counter is:
 
     {{< text bash >}}
-    $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
+    $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
     outbound|443||www.wikipedia.org::208.80.154.224:443::cx_total::2
     {{< /text >}}
 

content/en/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md

@@ -521,7 +521,7 @@ only this time for host `bookinfo.com` instead of `httpbin.example.com`.
 *   Verify that the proxy of the ingress gateway is aware of the certificates:
 
     {{< text bash >}}
-    $ kubectl exec -ti $(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -n istio-system -- curl  127.0.0.1:15000/certs
+    $ kubectl exec -ti $(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -n istio-system -- pilot-agent request GET certs
     {
       "ca_cert": "",
       "cert_chain": "Certificate Path: /etc/istio/ingressgateway-certs/tls.crt, Serial Number: 100212, Days until Expiration: 370"