Closed tamalsaha closed 6 years ago
Hi Tamalsaha,
First of all, thanks for working on this ingress controller.
I've got the same problem reported by the haproxy-controller
voyager haproxy-controller --analytics=true --burst=1000000 --cloud-provider=azure --ingress-api-version=voyager.appscode.com/v1beta1 --ingress-name=fsdca-mqtt-deployment-ingress --qps=1e+06 --reload-cmd=/etc/sv/haproxy/reload --logtostderr=false --alsologtostderr=false --v=100 --stderrthreshold=0
That debug level shows the following request:
curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: voyager/v0.0.0 (linux/amd64) kubernetes/$Format" -H "Authorization: Bearer eyJhbGciOiJSAdqKo..." https://10.0.0.1:443/apis/voyager.appscode.com/v1beta1/namespaces/fsdca/ingresses?fieldSelector=metadata.name%3Dfsdca-deployment-ingress&limit=500&resourceVersion=0
Curling just the https://10.0.0.1:443/apis/voyager.appscode.com/v1beta1/namespaces/fsdca/ingresses
without the URL parameters the API
returns the list of the Ingresses
without an error.
As the result the haproxy-controller
doesn't seem to reflect the changes in the haproxy.conf
I am also seeing a tons of I0301 11:55:53.872636 1 logs.go:19] http: TLS handshake error from 10.244.0.6:33384: remote error: tls: bad certificate
messages in the operator
logs, not sure if these are related.
Thanks
I think this is what is going on. In Kubernetes 1.8.x, CRDs did not support field labels. This was added https://github.com/kubernetes/apiextensions-apiserver/commit/f10f6d006980b99166963064196be2428ce1b413
This works ok in 1.9. https://github.com/kubernetes/apiextensions-apiserver/blob/release-1.9/pkg/apiserver/customresource_handler.go#L406
My understanding was that it was added in later version of kube 1.8.x (port 1.8.32) In 6.0.0-rc.x, we have started using field labels. So, I am going to remove the field selector this for now.
This has been fixed in 6.0.0 .