Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: Kubelet panics after registering node What you expected to happen: Kubelet should not panic How to reproduce it (as minimally and precisely as possible): Use kubelet on an ARM64 machine (i'm on Scaleway provider) Anything else we need to know?: I upgraded from 1.12.3 to 1.13.0 here is the statup log (only the end): Environment: Kubernetes version (use ): 1.13.0 Cloud provider or hardware configuration: Scaleway OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): 4.15.11-mainline-rev1 Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig node
a few questions: can you provide full output of , including the server version? did you upgrade kube-apiserver to 1.13.0? are you running static pod manifests on the kubelet?
hello i had rollbacked this node cannot currently no i didn't. I just upgraded on one server kube-proxy and kubelet. Kube-proxy works fine. i don't have static pods, just daemonsets on this node (metrology)
kubelet must not be newer than kube-apiserver be sure to upgrade kube-apiserver to 1.13 before upgrading kubelet
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i understand but why not just have a proper error instead of a ugly stack trace then ? it's more proper than an unhandled error. Here it's a memory error, a memory error is a grave error.
/reopen cc for disposition
Reopened this issue. <detailsIn response to : /reopen cc for disposition Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
code in question is here: note that this is an unsupported configuration
Refer the discussion here:
Solved using 1.13.0 api server. But i really think we need to handle this more properly than a stack
Should kubelet mark the node NotReady if it sees an older apiserver?
it sounds reasonable, and if we can have a description on the node saying: not compatible can be better

Discussion:
// Make the environment variables for a pod in the given namespace. func (kl *Kubelet) makeEnvironmentVariables(pod *v1.Pod, container *v1.Container, podIP string) ([]kubecontainer.EnvVar, error) { var result []kubecontainer.EnvVar <ins> enableServiceLinks := v1.DefaultEnableServiceLinks if pod.Spec.EnableServiceLinks != nil { enableServiceLinks = *pod.Spec.EnableServiceLinks } </ins> // Note:  These are added to the docker Config, but are not included in the checksum computed // by kubecontainer.HashContainer(...).  That way, we can still determine whether an // v1.Container is already running by its hash. (We don't want to restart a container just

// To avoid this users can: (1) wait between starting a service and starting; or (2) detect // missing service env var and exit and be restarted; or (3) use DNS instead of env vars // and keep trying to resolve the DNS name of the service (recommended). <del> serviceEnv, err := kl.getServiceEnvVarMap(pod.Namespace, *pod.Spec.EnableServiceLinks) </del> <ins> serviceEnv, err := kl.getServiceEnvVarMap(pod.Namespace, enableServiceLinks) </ins> if err != nil { return result, err }