What happened:
Example status on v1.14.1: chartmuseum chartmuseum-chartmuseum-696d8d5bc4-xkntr 1/1 Running
After upgrading to v1.14.2: chartmuseum chartmuseum-chartmuseum-696d8d5bc4-wk7kl 0/1 CreateContainerConfigError

Reverting to 1.14.1 brings the container back to running state.

kubectl describe shows Error: container has runAsNonRoot and image will run as root on 1.14.2

Same thing for the ingress-nginx default-backend pods. Controllers kept running, defaultbackends went to CreateContainerConfigError.

What you expected to happen:
Pods should keep on running without issues.

How to reproduce it (as minimally and precisely as possible):
helm install stable/chartmuseum on a cluster with pod security policies enabled.

Anything else we need to know?:

Environment: Bare metal, installed with kubespray 2.10

• Kubernetes version (use kubectl version):

Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:14:56Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration: VMware
• OS (e.g: cat /etc/os-release):
  NAME="Container Linux by CoreOS"
  ID=coreos
  VERSION=2079.4.0
  VERSION_ID=2079.4.0
  BUILD_ID=2019-05-15-0808
  PRETTY_NAME="Container Linux by CoreOS 2079.4.0 (Rhyolite)"
  ANSI_COLOR="38;5;75"
  HOME_URL="https://coreos.com/"
  BUG_REPORT_URL="https://issues.coreos.com"
  COREOS_BOARD="amd64-usr"
• Kernel (e.g. uname -a):
  Linux k8s001-api001 4.19.43-coreos Unit test coverage in Kubelet is lousy. (~30%) #1 SMP Wed May 15 07:18:39 -00 2019 x86_64 Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz GenuineIntel GNU/Linux
• Install tools: Kubespray 2.10
• Network plugin and version (if this is a network-related bug): calico 3.4
• Others: