CRD and aggregation - future and pain points

crd-and-aggregation-future-and-pain-points.md

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.