-
Notifications
You must be signed in to change notification settings - Fork 70
Backward compatibility regarding new parameters in Kubernetes 1.2 #674
Description
Kubernetes 1.2 added new configuration parameters for liveness and readiness probes: periodSeconds, successThreshold, failureThreshold.
If you define object with any of those parameters for example like this:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- args:
- /bin/sh
- -c
- echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
image: gcr.io/google_containers/busybox
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 15
timeoutSeconds: 1
periodSeconds: 15
name: liveness
Now if you want to deploy this to using kubectl older then 1.2 it fails on error validating "test.yaml": error validating data: found invalid field periodSeconds for v1.Probe; if you choose to ignore these errors, turn validation off with --validate=false
This is problem for Atomic App as we are currently using kubectl to deploy kubernetes artifacts.
When Nulecule artifacts contains one of the new parameters Atomic App fails:
AtomicAppUtilsException: cmd: ['/host/usr/bin/kubectl', 'create', '-f', u'/host/var/lib/atomicapp/10.1.2.1-5000-mlbparks-mlbparks1-7b82edcaa7fb/artifacts/kubernetes/.mlbparks-1-ReplicationController.json', '--namespace=default'] failed:
error validating "/host/var/lib/atomicapp/10.1.2.1-5000-mlbparks-mlbparks1-7b82edcaa7fb/artifacts/kubernetes/.mlbparks-1-ReplicationController.json": error validating data: [found invalid field successThreshold for v1.Probe, found invalid field periodSeconds for v1.Probe, found invalid field failureThreshold for v1.Probe]; if you choose to ignore these errors, turn validation off with --validate=false
Only solution for this is to add --validate=false
to kubectl. This turns client side validations off. Whole object is than pass down to server. Kubernetes api-server validation is apparently less strict and it ignores unknown parameters.
When using api directly this problems doesn't exist. Because it is not going thought kubectl validation.
I don't know how far is @cdrage with new kubernetes provider, it is going to fix this.
But until then I propose to add --validate=false
to all kubectl crate
calls.