Thanks, Joseph. You have rightly pointed out that GitOps is essential. And we do 100% support GitOps. IMESH Platform supports two deployment models- GitOps-based and direct deployment. For GitOps-based, the IMESH platform translates the UI form into YAML. After that, the usual GitOps-style delivery process is initiated with software like Argo CD. For startups and lower environments- where the concept of CI/CD or GitOps is not yet practiced, IMESH API gateway would be handy for them to easily create and manage north-south traffic in the cluster from the simple UI with direct deployment option. Reasons for our low-code platform are: 1. Many developer teams think it is a context switch to learn YAML. 2. Creating network resources and policies involves a high learning curve (as one must remember all configurations). 3. Creation/editing of manifests often leads to errors & debugging issues, which is counter-productive. 4. Enhance the visibility of all the network resources in a single pane of glass. 5. The DevOps and cloud team would know who created/managed what resources. 6. Real-time view of performance of network resources with just one click.

Regarding public IP concerns, the IMESH platform does not need any public IP to be exposed in the client cluster. It works in reverse.

Sure

Yes you can check this github link- github.com/imesh-ai/webinar/tree/main/Migrating%20from%20Ingress%20to%20K8s%20Gateway%20API

Hi, can you explain your use case a bit more. How are you planning to use mTLS?

The comparison is between the K8s ingress controller and the Istio ingress gateway

We'll think about it.

Grafana dashboards created in UI wont persist on restarts/updates. To make sure your dashboards are persistent you need to update the grafana.yaml file that you used to install grafana with istio. First make your dashboard in grafana and export it as json. Then make a copy of grafana.yaml file so you have a backup. Create a config map as follows with the json data of your dashboard as follows apiVersion: v1 kind: ConfigMap metadata: name: <your-dashboard-configmap-name> namespace: istio-system data: <your-dashboard-filename>.json: |- <jsoncontent> Then add the config map to the grafana deployment under spec.template.spec.volumes, below is an example: spec: ... template: ... spec: ... volumes: ... - name: <your-dashboard-volume-name> configMap: name: <your-dashboard-configmap-name> Then add the dashboard provider in grafana's serviceaccount under data.dashboardproviders.yaml.providers, below is an example dashboardproviders.yaml: | apiVersion: 1 providers: ... - disableDeletion: false folder: <dashboard folder name> name: <dashboard-name> options: path: /var/lib/grafana/dashboards/<your-dashboard> orgId: 1 type: file Lastly, update the volumeMounts in grafana container to use the above volume, below is an example containers: - name: grafana ... volumeMounts: .... - name: <your-dashboard-volume-name> mountPath: "/var/lib/grafana/dashboards/<your-dashboard>" Apply the yaml file and you should have your custom dashboard in the grafana accessible by istioctl dashboard grafana this is one of the most reliable way to add persistent dashboards with grafan in Istio

To rate limit based on cookies, the header-to-metadata filter can be used to generate metadata from cookies. Then, these metadata entries can be used in the rate limit actions in the virtualhost envoyfilter. An example of this envoyfilter setup with the header-to-metadata filter is on our blog imesh.ai/blog/istio-rate-limiting-global/ (under the heading "Advanced configurations with Istio global rate limiting")

As of now, there is no direct support for ALB in the gateway API. You can use ingress with annotations and connect to the Istio ingress service with changing LB type to nodeport

Hi, which cloud provider/cluster you are using?

@@imesh.ai_inc AWS/EKS

Hey @@imesh.ai_inc I'm using AWS/EKS

Which cluster you are using?

what is the best storage to use prometheus like s3,ELK etc

Ingress is not 'deprecated' but is 'frozen'. You can see that in the official Ingress doc: kubernetes.io/docs/concepts/services-networking/ingress/

Yes, If you have a controller that supports Gateway API then you don't need to create any GatewayClass for it, you can simply refer to it with the relevant name. If you have Istio installed you can refer to it in the Gateway resource. Here is a list of supported controllers that implement gateway API specification, you can pick any of them as the controller gateway-api.sigs.k8s.io/implementations

Please check this- github.com/imesh-ai/webinar/tree/main/Getting%20Started%20With%20Kubernetes%20Gateway%20API%20Using%20Istio

Thanks For your all answer, please watch this video-kzbin.info/www/bejne/bX7FhaSGndeEa80

@@imesh.ai_inc thank you! The video doesn't really answer my question. I was looking for any specific EKS settings that Ambient might be sensetive to, not a generic EKS cluster setup.

@@PetrMcAllister Same settings/setup will work with ambient mode as well. However, as a side note, ambient mode does not work with calico as of now.

You can access applications by their respective ClusterIP service from within the cluster. In this case, echoserver-service is the service to be used to access application internally.

@@imesh.ai_inc Hey hai here is one doubt where you deployed the application load balancer your not install or show how it happened

​@@ThecookBoy It is Istio ingress gateway working as application load balancer.

Yes, the ingress controller creates a service of type LoadBalancer which in turn spins off the cloud prover's LB and gets external IP, this applies to all cloud providers. This IP can be used by frontend to send requests, and if you have configured the right rules for traffic management this request will be taken to whatever service you want.

Installing Jaeger from the Istio sample addons will report trace spans for workload-to-workload communications in the mesh. However, the application itself still needs to propagate the trace context between incoming and outgoing requests. This can be done easily with autoinstrumentation libraries from OpenTelemetry, for example. For more, you can reach us- [email protected]

You need to create and deploy, Gateway and Virtual Service/HttpRoute resources to expose services to outside world.

@@imesh.ai_inc thanks for the time, as you mentioned I have created the service and gateway now I can able to access sample app from the browser Do you have book info deployments with canery deployments some traffic should be go one cluster 70 percentage traffic and other 30 should go another cluster where the new version is deployed

envoy-demo.yaml is copied into docker image and used by docker container directly.

Yes, it is still in alpha as of now.

Sorry Mikey, I think there was typo, we corrected it. But we have covered the multicluster topic for GKE as well 6 months ago. Please check this youtube video link: kzbin.info/www/bejne/kHPYepScjM9sr5Y and also the blog on the same topic: imesh.ai/blog/how-to-implement-istio-in-multicloud-and-multicluster/

helm install istio-ingressgateway istio/gateway -n istio-ingress --create-namespace

here's the command for the egress gateway-: helm install istio-egressgateway istio/gateway -n istio-egress --create-namespace --set service.type=ClusterIP