diff --git a/content/en/docs/concepts/api-extension/custom-resources.md b/content/en/docs/concepts/api-extension/custom-resources.md index 44efe01a71..f65985e474 100644 --- a/content/en/docs/concepts/api-extension/custom-resources.md +++ b/content/en/docs/concepts/api-extension/custom-resources.md @@ -37,7 +37,7 @@ A *custom controller* is a controller that users can deploy and update on a runn When creating a new API, consider whether to [aggregate your API with the Kubernetes cluster APIs](/docs/concepts/api-extension/apiserver-aggregation/) or let your API stand alone. | Consider API aggregation if: | Prefer a stand-alone API if: | -|-|-| +| ---------------------------- | ---------------------------- | | Your API is [Declarative](#declarative-apis). | Your API does not fit the [Declarative](#declarative-apis) model. | | You want your new types to be readable and writable using `kubectl`.| `kubectl` support is not required | | You want to view your new types in a Kubernetes UI, such as dashboard, alongside built-in types. | Kubernetes UI support is not required. | @@ -49,6 +49,7 @@ When creating a new API, consider whether to [aggregate your API with the Kubern #### Declarative APIs In a Declarative API, typically: + - Your API consists of a relatively small number of relatively small objects (resources). - The objects define configuration of applications or infrastructure. - The objects are updated relatively infrequently. @@ -58,6 +59,7 @@ In a Declarative API, typically: Imperative APIs are not declarative. Signs that your API might not be declarative include: + - The client says "do this", and then gets a synchronous response back when it is done. - The client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request. - You talk about Remote Procedure Calls (RPCs). @@ -145,7 +147,7 @@ Typically, CRDs are a good fit if: CRDs are easier to create than Aggregated APIs. | Custom Resource Definitions | Aggregated API | -|-|-| +| --------------------------- | -------------- | | Do not require programming. Users can choose any language for a CRD controller. | Requires programming in Go and building binary and image. Users can choose any language for a CRD controller. | | No additional service to run; CRs are handled by API Server. | An additional service to create and that could fail. | | No ongoing support once the CRD is created. Any bug fixes are picked up as part of normal Kubernetes Master upgrades. | May need to periodically pickup bug fixes from upstream and rebuild and update the Aggregated APIserver. | @@ -156,13 +158,13 @@ CRDs are easier to create than Aggregated APIs. Aggregated APIs offer more advanced API features and customization of other features, for example: the storage layer. | Feature | Description | CRDs | Aggregated API | -|-|-|-|-| +| ------- | ----------- | ---- | -------------- | | Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Beta feature of CRDs in v1.9. Checks limited to what is supported by OpenAPI v3.0. | Yes, arbitrary validation checks | | Defaulting | See above | No, but can achieve the same effect with an Initializer (requires programming) | Yes | | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | No | Yes | | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | No, but can get some of the same effects with Initializers or Finalizers (requires programming) | Yes | -| Subresources | {::nomarkdown}