Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
69 lines (37 sloc) 4.2 KB

What's the difference from KubeBuilder?

KubeBuilder is also a good helper to extend your own workload based on Kube-APIServer. By contrast with this project, KubeBuilder is constructing your workload basing on CRD (CustomResourceDefinitions) which is the recommended light-wighted approach to extend your API resources instead of AA (Aggregated APIServer). So in case you are hesitating whether to adopt AA or not, we will briefly introduce the differences between AA and CRD from several aspects. And hopefully you would see which approach might be more suitable to your use case:

API Access Control

Authentication
  • CR: All strategies supported. Configured by root apiserver.
  • AA: Supporting all root apiserver's authenticating strategies but it has to be done via authentication token review api except for authentication proxy which will cause an extra cost of network RTT.
Authorization
  • CR: All strategies supported. Configured by root apiserver.
  • AA: Delegating authorization requests to root apiserver via SubjectAccessReview api. Note that this approach will also cost a network RTT.
Admission Control
  • CR: You could extend via dynamic admission control webhook (which is costing network RTT).
  • AA: While You can develop and customize your own admission controller which is dedicated to your AA. While You can't reuse root-apiserver's built-in admission controllers nomore.

API Schema

Note: CR's integration with OpenAPI schema is being enhanced in the future releases and it will have a stronger integration with OpenAPI mechanism.

Validating
  • CR: (landed in 1.12) Defined via OpenAPIv3 Schema grammar. more
  • AA: You can customize any validating flow you want.
Conversion
  • CR: (landed in 1.13) The CR conversioning (basically from storage version to requested version) could be done via conversioning webhook.
  • AA: Develop any conversion you want.
SubResource
  • CR: Currently only status and scale sub-resource supported.
  • AA: You can customize any sub-resouce you want.
OpenAPI Schema
  • CR: (landed in 1.13) The corresponding CRD's OpenAPI schema will be automatically synced to root-apiserver's openapi doc api.
  • AA: OpenAPI doc has to be manually generated by code-generating tools.
Other
Functionalities AA (Aggregated APIServer) CR (Custom Resource)
SMP(Strategic Merge Patch) Supported Not yet. Will be replaced via server-side apply instead
Informative Kubectl Printing Not supported, unless you develop your own with server-side printing. By AdditionalPrinterColumns
Websocket/(Other non-HTTP transport) Supported No
metadata.Generation Auto Increment Supported Nope, and this is designed
Use Another Backend/Secondary Storage Supported For now, ETCD3 only

More Comparision here

Conclusion

CRD/CR is the recommended approach to extend your workloads, while AA will still stand out under specific use cases because it keeps the possibility that Kube-APIServer could integrate with your heterogeneous systems. Note that developing and maintaining an AA extension would be much more costy than CR so consider it again unless you are sure to continue on with it. Also, any customization based on AA has to follow kubernetes API convension. In a word, everything is under your control with AA, it would be beautiful but challenging.

You can’t perform that action at this time.