Change:
This is happening consistently across all GKE 1.4-1.6 master upgrade jobs. It is not occurring for full-cluster upgrades. Example log: https://k8s-
Config map is failing to mount for some reason.
Could you take a look. It seems like the dns pod wants a config map, but for the life of me, I can't find where this config map is created.
optional: true for the configmap means that if the configmap does not exist, then the configmap directory should be empty
the optional configmap feature was in 1.6
Ah. The kubelet here is 1.4 and doesn't understand optional configmaps. This causes the pod to error and never become ready.
cc
thanks, just saw this. glad to know the add-on manager support for ensureexists made it in 1.6
Glad to see addon-manager could help out instead of causing problems :)
merged, is this resolved now?
Seems like it is still failing in the latest run for the same reason: https://k8s- Checked the log and found the upgrade is using the beta release binary: So I assume the test will keep failing until that PR got cherry picked into 1.6 branch and released?
at least that, possibly until a new tag is cut
This issue appears to be .
we are now seeing similar-looking errors in the GKE cluster upgrade suites. Can you please take a look ASAP to help triage? Note that this time it is occurring in the full-cluster upgrades, not the master-only upgrades. Example: https://k8s-
Sure, looking into it.
FYI is looking at another issue related to GKE upgrades - not sure if they're related or not (they're reporting different errors)
I'm looking into an issue of the master not starting. This looks separate.
Don't have a theory yet, but saw couple strange errors: Which likely indicates Apiserver on master was not in a proper state. And seems like this happened before and after upgrade --- both old version and new version kubedns crashed with this error.
Found kube-proxy hit similar failure (seems like a permission error):
related to your ABAC work?
I just found this in a healthy master when trying to reproduce my problem. API server is definitely RBAC denying kube_proxy on cluster wide endpoint lists.
Was this an upgrade or a new install?
Almost certainly related to what I did. I checked a 1.5-1.6 upgrade, but didn't check 1.4-1.6
It was an upgrade.

Discussion:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"admin", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"{{kube_user}}", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"kubelet", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} <ins> {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"kube_proxy", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} </ins> {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"kubecfg", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"client", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group":"system:serviceaccounts", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}}  No newline at end of file