mitzen

This is an example of a rust http test client that i used to run test periodically.  use clap ::{ Parser , ValueEnum }; use indicatif ::{ ProgressBar , ProgressStyle }; use reqwest ::{ Client , Method }; use std :: collections :: HashMap ; use tokio :: time ::{ sleep , Duration }; // Added tokio sleep use serde_json :: Value ; #[ derive ( Copy , Clone , PartialEq , Eq , PartialOrd , Ord , ValueEnum , Debug )] enum HttpMethod {     Get ,     Post ,     Put , } #[ derive ( Parser , Debug )] #[ command ( author , version , about = " A simple HTTP load tester " )] struct Config {     /// HTTP Method to use     #[ arg ( short , long , value_enum , default_value_t = HttpMethod :: Get )]     method : HttpMethod ,     /// Target URL endpoint     #[ arg ( short , long )]     url : String ,     /// Number of tests to run     #[ arg ( short , long , ...

          It become important to understand envoy mechanics and this is an awesome illustration of it and how these listeners and cluster and endpoints are linked together. 1. Listener (Where traffic enters) A Listener is a named network location (an IP address and a port) that Envoy opens up to accept incoming connections from clients. What it does: It's the "front door." It listens for incoming traffic, handles TLS decryption (if configured), and passes the request down the chain. In Istio: When you create an Istio Gateway resource and specify port 80 or 443 , Istio tells Envoy to open a Listener on that port. Real-world analogy: The receptionist desk at a building entrance. 2. Route (How traffic is matched) Once a request enters through a Listener, Envoy needs to decide what to do with it. This is where the Route comes in. What it does: It inspects the request details—like the URI path ( /html vs /status/200 ), HTTP methods ( GET , POST ), or he...

When trying to hit your Kubernetes with istio enabled clustered, you might need to do some troubleshooting to ensure traffic flowing in correctly. Here are some of the steps that I used To check if traffic or request is coming in. This can be alot but you can narrow it down. For example, in my setup, I have httpbin configure and if there's a request coming into the pod, it will be logged here :-  Turn on logging on the istio pod level too  istioctl proxy-config log POD --level=debug And then turn on logging in the ingress as well.  k logs -l app.kubernetes.io/name=istio-ingressgateway  -n istio-system -f Let's look at the logs for ingress gateway in details :-  You can see that in the red circle, I am getting 503 error and this means  1. Traffic or the request is coming in 2. You're getting a 503 error is because your virtual service not configure correctly 3. 503 error can also means that your service has been deleted (not configure correctly) or your pod ...