Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save mrbobbytables/8da0489d9a7b83a3287b31ea2d993b87 to your computer and use it in GitHub Desktop.
Save mrbobbytables/8da0489d9a7b83a3287b31ea2d993b87 to your computer and use it in GitHub Desktop.
CRD and aggregation - future and pain points

CRD and aggregation - future and pain points

outlook - aggregation

  • API stable since 1.10

  • GSoC project with @xmudrii: share etcd storage

    • kubectl create etcdstorage your api-server
  • Store custom data in etcd

outlook custom resources

1.11:

  • a: multiplier versions with conversion
  • a: pruning - blocker for GA - unspecified fields ar removed
  • a: defaulting - defaults from openapi validation schema are applied
  • a: graceful deletion - (maybe? PR exists)
  • a: server side printing columns for kubectl get customization
  • b: subresources - alpha in 1.10
  • will have additionaProperties with extensible string map
    • nutually exclusive with properties

1.12

  • multiple versions with declarative field renames
  • strict create mode

outlook be prepared for pruning

  • keep change of semantics for of custom resources
  • From JSON blob store to schema based store
  • current everything is allowed if its not specified

The Future: Versioning

  • Most asked feature, coming..but slowly

  • two types, "noConversion" and "Declarative Conversion"

  • "NoConversion" versioning

    • maybe in 1.11
    • ONLY change is apiGroup
    • Run multiple versions at same time, they are not converted
  • "Declarative Conversion" 1.12

  • declarative rename e.g

spec:
  group: kubecon.io
  version: v1
  conversions:
    declarative:
      renames:
        from: v1pha1
        to: v1
        old: spec.foo
        new: bar
  • Support for webhook?
    • not currently, very hard to implement
    • complex problem
    • current need is really only changing for single fields
  • Trying to avoid complexity by adding alot of conversions

Questions:

  • When should someone move to their own API Server
    • At the moment, telling people to start with CRDs. If you need an aggregated API server for custom versioning or other specific use-cases.
  • How do I update everything to a new object version?
    • Have to touch every object.
  • are protobuf support in the future?
    • possibly, likely yes
  • update on resource quotas for CRDS
    • PoC PR current out, its doable just not quite done
  • Is validation field going to be required?
    • Eventually, yes? Some work being done to make CRDs work well with kubectl apply
  • Can CRDs be cluster wide but viewable to only some users.
    • It's been discussed, but hasn't been tackled.
  • Is there support for CRDs in kubectl output?
    • server side printing columns will make things easier for client tooling output. Versioning is important for client vs server versioning.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment