Improve Annotation Format

[alexhersh]

I am working on implementing network policy rules in Kubernetes annotations and am hitting a limitation in how Kubernetes parses dictionary values in the pod spec.

I would like to put nested lists within annotation values, but annotations are expected to be single "key": "value" string pairs. To get around this I am tokenizing my data as a single string and then marshaling it separately in my code, but the result is unreadable and not intuitive.

For example, I would like to format my pod config like:

"annotations": {
    "rule1": [
        {
            "labels": {
                "name": "pod1"
            }
        },
        {
            "protocol": "tcp"
        }
    ]
}

but my workaround looks like:

"annotations": {
    "rule1": "[{\"labels\": {\"name\": \"pod1\"}},{\"protocol\": \"tcp\"}]"
}

One line solutions are cool and all, but this design is not very easy to program or debug, nor is it suitable for larger annotations. I would much prefer to have more robust annotation support natively in the Kubernetes pod spec.

If you agree that this feature is worth implementing, I can go ahead and try to build it in myself.

[nikhiljindal]

cc @bgrant0607

[bgrant0607]

This was on my list of features to consider for "v2" APIs: #8190.

If changed in the v1 API we'd need to retain backward compatibility. Do you think that's feasible?

We've discussing "subobject plugins" a number of times. Some standardized schema metadata (apiVersion, kind) would be necessary for interpreting them, much as our top-level API resources.

cc @smarterclayton @thockin

[bgrant0607]

cc @brendandburns

[bgrant0607]

cc @lavalamp

[bgrant0607]

@alexhersh I do think this is worthwhile, if you'd like to give it a try. The main requirement that needs to be satisfied is backward compatibility -- strings need to continue to work.