Ports and pod counts as strings about kubeval

[garethr]

So, looking further into this, based on my reading of the OpenAPI 2.0 specification, the Kubernetes spec might not actually be valid. Or the implementation has a bug. This is something of a rabbit hole.

Kubernetes introduces a format of int-or-string to the String type (which is part of the spec). The text in the spec states that format "can have any value to support documentation needs" but in this case Kubernetes will pass integers to the String type, relying on parsing rules in the format.

The spec specifies a mechanism for vendor extensions. I think rather than int-or-string being a Format on the String type, this should actually be a type of x-int-or-string.

I'll post something to API Machinery to see what folks think.

In the meantime I'll see if I can spot a local work around.

[garethr]

@elblivion would you be able to provide a sample config file which throws these errors?

I'm pretty sure this is due to the addition of int-or-string in OpenAPI which is not in JSON Schema.

I have a workaround for this but looking at the code now I think the fact this function https://github.com/garethr/kubeval/blob/master/cmd/root.go#L30 takes a string might be the issue. If you could provide a failing config I'll get this fixed and add that to the acceptance tests. Thanks for trying it out and reporting the issue.

[elblivion]

Sure, this one is from an official Kubernetes add-on and has this issue:

$ cat ./heapster/heapster-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    # For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)
    # If you are NOT using this as an addon, you should comment out this line.
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: Heapster
  name: heapster
  namespace: kube-system
spec:
  ports:
  - port: 80
    targetPort: 8082
  selector:
    k8s-app: heapster

$ kubeval ./heapster/heapster-service.yaml
The document ./heapster/heapster-service.yaml is not a valid Service
--> spec.ports.0.targetPort: Invalid type. Expected: string, given: integer

[garethr]

So, I think their is a workaround to this that can be implemented in kubeval before any changes that might happen upstream.

For each error in Validate
If Type() is invalid_type and
Value() is an integer and
Field() has a format of int-or-string
then don't raise the error

The implementation needs to grab the Field() value from the error, then look in the raw schema to see if that field has a format of int-or-string.

The other option is to convert at the schema level. ie. make the files published in kubernetes-json-schema actually valid according to the spec.

I'm going to investigate both when I get a moment.

[garethr]

@elblivion so, I have a blunt workaround in #2

If you have a moment to test that out I'd appreciate feedback. I've added the sample you provided to the acceptance tests and the done now passes. It should provide you with a warning about the field in question as the code doesn't yet determine with 100% certainty that it's correct. I'll be working on improving that when I get a moment.

[elblivion]

Hi @garethr, tested this and it does what it says on the tin. The thing is, there is at least one case where we absolutely do need an error to be raised - whenever any desc.Field() containsenv.%d.value is an integer, since this breaks horribly a create or apply operation. Sorry if I didn't make that clearer.

Here's a sample spec that should break with env but not other integers:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: INTEGER_VAR
          value: 80
        ports:
        - containerPort: 80
          name: http
          protocol: UDP

Current kubeval master:

The document /tmp/yaml.yml is not a valid Deployment
--> spec.template.spec.containers.0.env.0.value: Invalid type. Expected: string, given: integer
--> spec.strategy.rollingUpdate.maxSurge: Invalid type. Expected: string, given: integer
--> spec.strategy.rollingUpdate.maxUnavailable: Invalid type. Expected: string, given: integer

kubeval from #2:

---> spec.template.spec.containers.0.env.0.value is an integer, but might be an int_or_string property
---> spec.strategy.rollingUpdate.maxSurge is an integer, but might be an int_or_string property
---> spec.strategy.rollingUpdate.maxUnavailable is an integer, but might be an int_or_string property
The document /tmp/yaml.yml is a valid Deployment

[garethr]

I've just tried a much better approach in #3 which passes both of the two test cases you provided. ie. the first one passes as valid and the second one fails like so.

The document fixtures/int_or_string_false.yaml is not a valid Deployment
--> spec.template.spec.containers.0.env.0.value: Invalid type. Expected: string, given: integer

@elblivion If you could try that out it would be much appreciated, and if it works out I'll merge and release a new versions.

[elblivion]

Works beautifully :-) Much obliged!

The only catch for us is that the Go YAML library does not support document separators (multiple specs in the same file) but that's a different issue I can open if you wish - you might want a big warning about that.

I was planning on proposing sticking to one spec per file anyway for clarity.

[garethr]

@elblivion excellent, thanks.

Yes, I'd like to support document separators. If you could open a new issue that would be great.

[garethr]

@elblivion thanks for your help with this. I've merged #3 and released 0.1.1 with the fix. Much appreciated.

[elblivion]

👍