Dont fallback from HTTPS to HTTP as kubelet does
evgkrsk opened this issue · 1 comments
evgkrsk commented
Unlike kubelet, k8s-iae dont try to fallback from HTTPS to HTTP. As result, it mark all images in insecure private registries as unavailable with following log (obfuscated):
time="2020-09-27T00:32:20Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar-web-pusher:0.1.2"
time="2020-09-27T00:33:21Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/document-renderer:0.1.3"
time="2020-09-27T00:40:30Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/document-renderer:0.1.7"
time="2020-09-27T00:50:40Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar:rails-release"
time="2020-09-27T00:51:41Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/s3-runner:master"
time="2020-09-27T00:55:44Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar-ui:1.0.52"
time="2020-09-27T00:57:46Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/cron-runner:master"
time="2020-09-27T00:59:48Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar-web-pusher:master"
time="2020-09-27T01:03:54Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar:rails-master"
time="2020-09-27T01:05:58Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar-ui:release"
time="2020-09-27T01:06:59Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/foobar-web-pusher:0.1.2"
time="2020-09-27T01:08:00Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/document-renderer:0.1.3"
time="2020-09-27T01:15:14Z" level=error msg="Get \"https://192.168.1.10:1234/v2/\": http: server gave HTTP response to HTTPS client" availability_mode=unknown_error image_name="192.168.1.10:1234/document-renderer:0.1.7"
meanwhile, this images IS accessible.
nabokihms commented
The CRI is in charge of pulling container images, and each CRI may act differently. For example, the contained knows the scheme it should use for removing in advance.
However, from Kubernetes pod definitions, it is impossible to know the schema, but falling back by default may need to be more accurate.
Anyway, I added a flag for allowing HTTP fallback if that is required. It looks like a nice feature to have.