Setting up Routing Rules using CRDs

Custom Resource Definitions (CRDs) are used to extend the Kubernetes APIs server with additional schemas.
For more information on CRDs, see CRDs.
The
Avi Kubernetes Operator
(
AKO
) supports some CRD objects (installed through helm). The CRDs are relevant to:
  • Operators:
    Users of this category:
    • Are aware of the semantics related to
      VMware Avi Load Balancer
    • Have access to the
      Avi Load Balancer Controller
    • Manage the lifecycle of
      AKO
  • Developers:
    Users of this category:
    • Are owners of microservices deployed in Kubernetes
    • Are assumed to know basic routing principles but might not know the specifics of
      VMware Avi Load Balancer
      attributes

Advantages of CRDs

Some load balancers allow configuration options through annotations.
The following are the advantages of using CRDs:
  • Versioning: CRDs allow
    AKO
    to version fields appropriately due to the dependency on the
    Avi Load Balancer Controller
    versions. In general, this helps preserve unique states across various deployment versions.
  • Syntactical Validations: CRDs can be used to verify syntax at the time of creation of the CRD object. This saves API cost and facilitates quicker feedback using a combination of field constraints and effective status messages.
  • Role segregation: CRDs can benefit from the Role-based access control (RBAC) policies of Kubernetes and allow stricter access to a group of users.

Types of CRDs Supported in
AKO

AKO
categorizes the CRDs into:
  • Layer 4: These CRD objects are used to express layer 4 traffic routing rules.
  • Layer 7: These CRD objects are used to express layer 7 traffic routing rules.
  • Infrastructure: These CRD objects are used to control infrastructure components like Ingress class, SE group properties, and so on.

Layer 7 CRDs

The Layer 7 CRDs currently available in
AKO
are HostRule, HTTPRule, and SSORule.