On Tuesday, August 8, 2017 at 6:58:29 AM UTC-7, Greg Baltzer wrote: > Here are a few things that we have tried so far in our attempt to use windows > containers with spinnaker on GCP. > > > 1) We created a docker image on windows of a simple asp.net application then > pushed that image up to our container registry on GCP. The image was then > grabbed by spinnaker, but every step after that failed. Here is the error > output we got via Spinnaker: > > > > > Failed to pull image "gcr.io/btinterns-168014/hello-node2:v1": [rpc error: > code = 2 desc = unknown blob, rpc error: code = 2 desc = unknown blob] > > Error syncing pod, skipping: failed to "StartContainer" for > "btinterns-168014-hello-node2" with ErrImagePull: "[rpc error: code = 2 desc > = unknown blob, rpc error: code = 2 desc = unknown blob]" > > Error syncing pod, skipping: failed to "StartContainer" for > "btinterns-168014-hello-node2" with ImagePullBackOff: "Back-off pulling image > \"gcr.io/btinterns-168014/hello-node2:v1\"" > > > > > 2) Since then, we started following this tutorial and were able to seemingly > setup the two windows server nodes outlined in the tutorial. Problems arose > when we started to setup the linux node where the Kubernetes control plane is > supposed to reside. While we were working on this, we discovered the checkbox > to enable Kubernetes-alpha features when creating a new container cluster on > Google Container Engine. We imagine that the reason we were getting errors > while following the tutorial listed above was because that Kubernetes-alpha > checkbox was not checked. > > > One concern that we have is whether or not we will be able to hook the > container cluster that we create (which has 1 linux node and 2 windows nodes) > up with spinnaker. Should we continue deploying spinnaker via the GCP > Launcher, or would we be better off & gain more functionality if we deployed > it ourselves in a new VM on the compute engine? > > > We are curious to see if anyone has any experience running a asp.net > container on google cloud platform.
Hey Greg, I'm on the GCR team. Sorry for your trouble. I believe this has to do with non-distributable (aka foreign) layers. For licensing reasons, these kind of layers cannot be pushed to registries and must be fetched from an external source. It looks like support for this was added in 1.12.0: https://github.com/moby/moby/pull/22866 Your image was pushed with a newer version of docker that supports foreign layers, so it skipped pushing them. However, whatever is trying to pull your image (I believe kubernetes based on the logs you shared) is using docker 1.11.2. That version of docker doesn't support foreign layers, so it sees those missing layers as an error. If possible, I'd recommend using a new version of docker (which would probably require a newer kubernetes version). Another possibility (please note the many legal warnings) is here: https://docs.docker.com/registry/deploying/#considerations-for-air-gapped-registries FWIW, the missing foreign layers are: sha256:3889bb8d808bbae6fa5a33e07093e65c31371bcf9e4c38c21be6b9af52ad1548 sha256:e29afd68a947fc566b71a432a6df352eea9e59eb221c3cb9f6bf5a4df206571e These are pretty large (4.1GB and 1.2GB, respectively) and part of the microsoft/windowsservercore image. Hope this helps, Jon -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
