-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to pick up health check from readiness probe #241
Comments
There are several caveats. The health check should not already exist as it won't overwrite settings. Furthermore, the pods need to exist at the time of ingress creation. |
@nicksardo Yes I know that it will not overwrite settings of the ingress. I created a deployment and service, and waiting for the Pods to go green in GKE (when the readiness probes are passing) and then I created the ingress, and it just uses the default Anything else I can provide to prove this is a bug? |
@sonu27 In my experience for it to work the podspec must also include containerPort. e.g. spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80 |
@briansneddon dude! Thanks so much. That did the trick. Unless I'm mistaken, it doesn't say this anywhere, so I think the docs should really be updated. |
Feel free to send a quick PR. |
@sonu27 should that documentation say
? |
hitting the same. my ingress: apiVersion: extensions/v1beta1 my service: apiVersion: v1
my deployment: (DS) apiVersion: extensions/v1beta1 |
Import limitations from examples/health-checks/README.md and add new limitation mentioned in kubernetes#241.
@iftachsc did you find a solution? I am also having trouble understanding how that would work in practice. |
@psalaberria002 Please if you get a work around on this it would be helpful to share as this is getting confusing by the day. |
Agree with @cloudgrimm and @psalaberria002.. having trouble understanding how this exactly works. |
nop |
GCE Ingress Controllers require HTTP 200 to be served from '/' kubernetes/ingress-gce#241 (comment)
GCE Ingress Controllers require HTTP 200 to be served from '/' kubernetes/ingress-gce#241 (comment)
GCE Ingress Controllers require HTTP 200 to be served from '/' kubernetes/ingress-gce#241 (comment)
* /heathz and /readyz endpoints * Configure k8 to use readinessProbes * Use readyz in docker_compose * Use readyz in docker_compose * Use readyz in k8 test * add parallel build * add parallel build * Add '/' handler to metrics addr * Serve http 200 at '/' GCE Ingress Controllers require HTTP 200 to be served from '/' kubernetes/ingress-gce#241 (comment) * Set k8 probe scheme to https * Monitor dial logs * Set monitor's KT url
@iftachsc I have the exact use case and I've faced the exact same issue. Did you find a way to have the http traffic deployed to the istio-ingressgateway when the healthchecks are in a different port than the application port? I've recreated everything from scratch and the healthchecks are pointing to the default / |
Didn't work for me. I've got the following
the
and the
|
@gvko If I recall correctly, I only managed to fix this issue in my cluster after I went to https://console.cloud.google.com/compute/healthChecks, manually deleted some wrong check, and run |
@jpbochi , I tried that already before I wrote here, but it didn't help. I tried both deleting the root HC (pointing to |
thanks for the tip. I had the same issue and defined a readiness and liveness probe and redeployed the ingress but it didn't work. Since it worked perfectly with following this: https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress without any additional firewall or loadblanacing config, I figured that it must be the /healthz and / not giving 200. Fixed that end everything started to work, including certificates. |
This saves my life too, thank you!!!!!!!!! |
When I create a GCE ingress, Google Load Balancer does not set the health check from the readiness probe. According to the docs (Ingress GCE health checks) it should pick it up.
Any ideas why?
Deployment:
Service:
Ingress:
The text was updated successfully, but these errors were encountered: