I looked into this matter and I have found solution to your issue. To achieve sticky session for both paths you will need two definitions of ingress. I created example configuration to show you the whole process: Steps to reproduce: Apply Ingress definitions Create deployments Create services Create Ingresses Test I assume that the cluster … Read more
Your ingress definition creates rules that proxy traffic from the {path} to the {backend.serviceName}{path}. In your case, I believe the reason it’s not working is that /app is proxied to app-service:80/app but you’re intending on serving traffic at the / root. Try adding this annotation to your ingress resource: nginx.ingress.kubernetes.io/rewrite-target: / Source: https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/rewrite
I discovered what I was doing wrong. In my application definition I was using name as my selector selector: matchLabels: name: hello-world template: metadata: labels: name: hello-world Whereas in my service I was using app selector: app: hello-world After updating my service to use app, it worked selector: matchLabels: app: hello-world template: metadata: labels: app: … Read more
To fix the error error: unable to recognize “ingress.yaml”: no matches for kind “Ingress” in version “extensions/v1beta1 you need to set apiVersion to the networking.k8s.io/v1. From the Kubernetes v1.16 article about deprecated APIs: NetworkPolicy in the extensions/v1beta1 API version is no longer served – Migrate to use the networking.k8s.io/v1 API version, available since v1.8. Existing … Read more
I’ve managed to display what YAML gets executed by Helm using the: –dry-run –debug options at the end of helm install command. Then I’ve noticed that there controller is executed with the: –configmap={namespace-where-the-nginx-ingress-is-deployed}/{name-of-the-helm-chart}-nginx-ingress-controller. In order to load your ConfigMap you need to override it with your own (check out the namespace). kind: ConfigMap apiVersion: v1 … Read more
I don’t know if this is still an issue, but since version 0.22 it seems you need to use capture groups to pass values to the rewrite-target value From the nginx example available here Starting in Version 0.22.0, ingress definitions using the annotation nginx.ingress.kubernetes.io/rewrite-target are not backwards compatible with previous versions. In Version 0.22.0 and … Read more
You can use the annotation nginx.ingress.kubernetes.io/proxy-body-size to set the max-body-size option right in your Ingress object instead of changing a base ConfigMap. Here is the example of usage: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: my-app annotations: nginx.ingress.kubernetes.io/proxy-body-size: “50m” …
Another option you have is to remove the Validating Webhook entirely: kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission I found I had to do that on another issue, but the workaround/solution works here as well. This isn’t the best answer; the best answer is to figure out why this doesn’t work. But at some point, you live … Read more
I had the same problem and found a solution from another SO thread. I had previously installed nginx-ingress using the manifests. I deleted the namespace it created, and the clusterrole and clusterrolebinding as noted in the documentation, but that does not remove the ValidatingWebhookConfiguration that is installed in the manifests, but NOT when using helm … Read more
I would like to simplify the answer a bit further for those who are reletively new to Kubernetes and its ingress options in particular. There are 2 separate things that need to be present for ingress to work: Ingress Controller(essentially a separate Pod/Deployment along with a Service that can be used to utilize routing and … Read more