Change:
/kind bug What happened: Attempting to start kubelet on CoreOS machine with latest stable (). I have many other blades which are PXE booting where the commands work. For some reason on this box where CoreOS is installed to disk, it is not working. I have checked every possible setting and file and they are all identical ( permissions and values ). What you expected to happen: Kubelet to start and start up manifests ( api, proxy, controller ). How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet never actually starts a docker container. Doing doesn't show anything exited. I can docker pull the images from google. I've tried almost every setting I can change over the past 2 days. Environment: Kubernetes version (use ): I've tried both: v1.8.5 and v1.9.0 Cloud provider or hardware configuration: Dell R720XD. 24core 64gb ram, 22 SSDs. Most are ceph OSDs, sda is raid 1 SSDs for the OS and ideally kubernetes master. Bonded 10G cards for private network ( flannel ) and bonded 1g cards for public network. OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools: Baremetal plain install. No tools used. Others: Downloaded the bins into /opt/bin/ as described in kubernetes docs. The node is a member of etcd cluster. Manifests files are the usual, but kubelet doesn't get that far so I dont want to clutter and post configs. Systemd Kubelet Config: master- Logs from kubelet: After days of debugging, I believe it has to do with these lines in the logs: When it tries to connect to the docker-shim which it creates, on the other machines it looks like this: The success message never gets printed on the failing node. Both are identical. Flannel is up and running and can ping other flannel IPs on the network. Both docker infos are: The running containers are the OSDs.
/sig node /sig cluster-lifecycle
what are the contents of your file? looks like at least a few logs think that you are running on GCE example the log from here -
VERY interesting contents actually. The actual device is a second hand Dell R720XD, GSA ( Google Search Appliance ) ! The contents of the file are: Yes, and even when I put it still looked for it. I spent 3 days on the issue but eventually gave up - which is rare. I tried running the kubelet in rkt, docker and just the bin on coreOS itself. No matter what it could never actually start a manifest container. It never actually reached the "kubelet started". The http port never responded either. I'd be happy to attempt it again if you think this is the cause.
wow!!! yes, if you can fix the product_name somehow, i'll help you move along :) cross my fingers
Good sir, Go0o0o0o0oood sir - after literally almost 72hrs of little to no sleep, trying every possible thing I could imagine, your simple suggestion has fixed it... You have no idea how grateful I am! lol Since rebranding the BIOS back to dell from google is a pain ( ) I am running the kubelet in rkt, and just mounting a file to that path. The just contains . Everything is up and running as expected when I started this journey lol. THANK YOU for taking the time to help.

Discussion:
metadataEmail            = metadataUrl + "instance/service-accounts/default/email" storageScopePrefix       = "https://www.googleapis.com/auth/devstorage" cloudPlatformScopePrefix = "https://www.googleapis.com/auth/cloud-platform" <del> googleProductName        = "Google" </del> defaultServiceAccount    = "default/" )

glog.V(2).Infof("Error while reading product_name: %v", err) return false } <del> return strings.Contains(string(data), googleProductName) </del> <ins> name := strings.TrimSpace(string(data)) return name == "Google" || name == "Google Compute Engine" </ins> } // Enabled implements DockerConfigProvider for all of the Google implementations.