[GitHub] [camel-k] nicolaferraro commented on issue #1059: camel-k installation struggles

[GitBox <gi...@apache.org>]

nicolaferraro commented on issue #1059: camel-k installation struggles
URL: https://github.com/apache/camel-k/issues/1059#issuecomment-561709089
 
 
   @davesargrad looking at the first image, the kit is in status "Error", not "ErrImagePull", so it means that it has run the build part and started the docker image packaging part and the logs that you posted are printed by the Kaniko builder.
   
   Docker packaging is done by Kaniko at user level in the container, so my guess is that it does not change a lot if you configure the node docker daemon correctly. And I also don't think that the PROXY settings on the host have any effect on the container.
   
   In these cases on OpenShift I use `oc debug pod-name` to start an identical pod to the one that failed and try to do some debugging to check the network. You can do a similar thing with Kubernetes. 
   I'd use a `busybox` first to to some connectivity checks: the final destination or the proxy should be reachable, depending on your config.
   
   Then if the config is ok and (if needed) your camel k is configured with the --http-proxy-secret as in the messages above, I'd check with the Kaniko image that went in error. Kaniko images have a `-debug` variant, which in our case should be `gcr.io/kaniko-project/executor:debug-v0.9.0`. From that container you can try to build a random Dockerfile from an image of your choice and see what happens.
   
   Hope that some suggestions can help your investigations.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services