This document outlines the use of AKO specific CRD objects that allows the users to express Avi related properties.
Custom Resource Definitions or CRDs are used to extend the Kubernetes APIs server with additional schemas. More about CRDs can be read here
AKO ships a bunch of CRD objects (installed through helm). The CRDs are envisioned for two types of audiences:
Operators: Users of this category are aware of Avi related semantics, have access to the Avi controller. They manage the lifecycle of AKO.
Developers: They are owners of microservices deployed in Kubernetes. They are assumed to know basic routing principles but don’t know specifics of Avi atributes.
Some loadbalancers allow configuration options via annotations. The following reasons were considered to choose CRDs:
Versioning: CRDs, allow AKO to version fields appropriately due it’s the dependency on the Avi Controller Versions. In general this allows users to preserve unique states across various deployment versions.
Syntactical Validations: CRDs can be used to verify syntax at the time of creation of the CR object. This saves a lot of API cost
and allows quicker feedback to the user using a combination of field constraints and effective status messages.
Role segregation: CRDs can benefit from the RBAC policies of Kubernetes and allow stricter access to a group of users.
AKO categorizes the CRDs in the following buckets:
Layer 7: These CRD objects are used to express layer 7 traffic routing rules. Following are the list of CRDs currently available:
Layer 4: These CRD objects are used to express layer 4 trafffic routing rules. (Unreleased)
Infrastructure: These CRD objects are used to control Avi’s infrastructure components like Ingress Class, SE group properties etc. (Unreleased)