You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.
Is your feature request related to a problem? Please describe.
There are no examples or instructions using purely Helm Charts and Kubernetes manifests. Currently, the one tutorial uses Terraform,, https://learn.hashicorp.com/tutorials/consul/kubernetes-api-gateway that uses a mixture of cloud resources (for EKS), helm chart, and kustomize. Terraform, though popular for cloud resources, it is not as popular for Kubernetes resources, as Kubernetes manifests and Helm charts are by far more popular. It would be nice to have a tutorial and instructions that use only manifests and helm charts (no kustomize), as the current instructions adds further complexity and friction, especially compared to the complexity of underlying Consul Connect Service Mesh.
Right now I am looking for a solution that can integrate with Consul Connect SM with upstream support, i.e. no-transparent proxy as I have a multi-port solution that is further restricted to localhost. I would like to have API Gateway that can connect the mesh service, with the traffic between the gateway and meshed service using strict MutualTLS and also ACLs (so using a token).
Feature Description
Ultimately I would want to tutorial that uses Helm charts + Kubernetes manifests, without Terraform and without Kustomize. Customers should should standup whatever cluster, AKS, GKE, EKS, and be able to use this, not have a tutorial locked to a particular cloud Kubernetes, and shouldn't have to wade through another layer of complexity (Terraform + Kustomize) on top of complexity of working with API Gateway and Consul Connect Service Mesh.
Use Case(s)
I developed a solution on GKE using documentation from Consul Connect Service Mesh, which uses Helm charts and Kubernetes manifests. This guide uses Terraform + Kustomize, which is inconsistent with current documentation from Consul Connect Service Mesh. I am looking for clear documentation that uses just Helm charts and Kubernetes manifests, and something that will integrate to my existing GKE cluster.
Also the current example, within the scope of Terraform should be two separate modules, one for the EKS/VPC alone, and another one for just Kubernetes. The later should be able to run against any Kubernetes cluster. The current implementation adds layers of unnecessary complexity, which will send potential customers/users to other solutions.
Contributions
I can help test the solution and further documentation for accuracy. I can test it against GKE, AKS, and EKS.
The text was updated successfully, but these errors were encountered:
The naming doesn't imply this - I'll look into improving it - but the "local" set of tabs in the tutorial that you linked above can be used for targeting any K8s cluster you may have set up already in EKS, AKS, GKE, etc. Assuming you already have your own Kubernetes cluster and your kube context is targeting it, you can follow the "local" instructions and just skip the $ kind create cluster ... command.
You will have to install the Gateway CRDs using a single $ kubectl apply --kustomize "<url>" command, but otherwise are using Helm install for Consul and just applying kube resources to create Gateways, Routes, etc. with the kubectl tool.
I’m specifically trying this with k3s as a replacement for Traefik however the consul api gateway LB is not accessible. I’ve tested the cluster with things like a simple nginx LB and all is working fine. Is there something different about how consul api gateway creates an LB?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
There are no examples or instructions using purely Helm Charts and Kubernetes manifests. Currently, the one tutorial uses Terraform,, https://learn.hashicorp.com/tutorials/consul/kubernetes-api-gateway that uses a mixture of cloud resources (for EKS), helm chart, and kustomize. Terraform, though popular for cloud resources, it is not as popular for Kubernetes resources, as Kubernetes manifests and Helm charts are by far more popular. It would be nice to have a tutorial and instructions that use only manifests and helm charts (no kustomize), as the current instructions adds further complexity and friction, especially compared to the complexity of underlying Consul Connect Service Mesh.
Right now I am looking for a solution that can integrate with Consul Connect SM with upstream support, i.e. no-transparent proxy as I have a multi-port solution that is further restricted to localhost. I would like to have API Gateway that can connect the mesh service, with the traffic between the gateway and meshed service using strict MutualTLS and also ACLs (so using a token).
Feature Description
Ultimately I would want to tutorial that uses Helm charts + Kubernetes manifests, without Terraform and without Kustomize. Customers should should standup whatever cluster, AKS, GKE, EKS, and be able to use this, not have a tutorial locked to a particular cloud Kubernetes, and shouldn't have to wade through another layer of complexity (Terraform + Kustomize) on top of complexity of working with API Gateway and Consul Connect Service Mesh.
Use Case(s)
I developed a solution on GKE using documentation from Consul Connect Service Mesh, which uses Helm charts and Kubernetes manifests. This guide uses Terraform + Kustomize, which is inconsistent with current documentation from Consul Connect Service Mesh. I am looking for clear documentation that uses just Helm charts and Kubernetes manifests, and something that will integrate to my existing GKE cluster.
Also the current example, within the scope of Terraform should be two separate modules, one for the EKS/VPC alone, and another one for just Kubernetes. The later should be able to run against any Kubernetes cluster. The current implementation adds layers of unnecessary complexity, which will send potential customers/users to other solutions.
Contributions
I can help test the solution and further documentation for accuracy. I can test it against GKE, AKS, and EKS.
The text was updated successfully, but these errors were encountered: