The feast-operator defines custom Kubernetes API types (FeatureStore CRD) in infra/feast-operator/api/v1/ and infra/feast-operator/api/v1alpha1/, but currently does not lint these types against the Kubernetes API Conventions. The kube-api-linter (KAL) from kubernetes-sigs can catch common mistakes and enforce best practices for Kubernetes API types automatically.

The feast-operator already uses golangci-lint (configured in infra/feast-operator/.golangci.yml), but none of the enabled linters are specific to Kubernetes API conventions.

KAL checks for issues like:

• Required/optional field markers
• Status subresource conventions
• Condition and phase best practices
• Proper use of metav1.Condition types
• JSON tag and marker validation

Integrating KAL would catch API design issues early and reduce the manual review burden for API changes.

Proposed Changes

• Add kube-api-linter as a golangci-lint module or plugin in the feast-operator.
• Create a .custom-gcl.yml configuration to build a custom golangci-lint binary with KAL included.
• Update infra/feast-operator/.golangci.yml to enable and configure kubeapilinter, scoped to the api/ directory.
• Fix any existing violations surfaced by the linter.
• Integrate the linter into CI to prevent future regressions.

References
kube-api-linter repository: https://github.com/kubernetes-sigs/kube-api-linter