Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
142 changes: 141 additions & 1 deletion docs/gko/4.9/overview/custom-resource-definitions/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,4 +25,144 @@ The `Application` custom resource represents the configuration for an applicatio

Finally, the purpose of the `ManagementContext` is to provide a connection from GKO to your Gravitee API Management installation. GKO uses this connection to synchronize the resources it manages (APIs, applications, ...) with the Gravitee Console, Developer Portal, and Gateway.

In the following sections, we run through each CRD one by one.
# Custom Resource Definition (CRD) Status
When you deploy Custom Resources (CRDs) with the Gravitee Kubernetes Operator (GKO), the `status` field is populated with the latest information about the resource's state within the cluster. The 4.9 version of GKO introduces enhancements to the CRD status fields, providing clearer insights, streamlined troubleshooting, and improved support for GitOps workflows.

These enhancements include more structured, descriptive status information that aligns with best practices and offers consistent conventions across CRDs. This enables tighter integration with tools like ArgoCD and simplifies operational management for platform teams.


Prerequisites
- Gravitee Kubernetes Operator version 4.9.0 or above
- A Kubernetes cluster with the GKO installed. For more information about installing GKO, see [https://documentation.gravitee.io/gravitee-kubernetes-operator-gko/getting-started/quickstart-guide](Quick Start Guide)
- Access to view CRDs with `kubectl get` commands

## Viewing CRD Status
1. Get a list of deployed V4 APIs using the following command:

```bash
kubectl get apiv4definitions.gravitee.io
```

2. Inspect the `status` section of an API V4 CRD using the following command:

```bash
kubectl get apiv4definitions.gravitee.io <api-name> -o yaml
```

There is an organized `status` section with the following fields:

```yaml
status:
conditions:
- lastTransitionTime: "2025-10-03T09:20:04Z"
message: Successfully reconciled
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2025-10-03T09:20:04Z"
message: All References successfully resolved
observedGeneration: 1
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
crossId: 8905ba8d-79b9-c446-5cee-71ab8c6ea6f9
environmentId: DEFAULT
errors: {}
id: 3872738b-0aa6-ed7e-1f7b-386d80125412
organizationId: DEFAULT
plans:
KeyLess: d50628d2-cb86-01bc-0393-cdc0a0ce32e4
processingStatus: Completed
state: STARTED
```
The `conditions` array captures key lifecycle states and potential issues, while top-level fields like `state` and `environmentId` provide an operational summary.


Also, the Application's status is organized with the following fields:

```bash
kubectl get applications.gravitee.io <app-name> -o yaml
```

```yaml
status:
conditions:
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: Successfully reconciled
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: All References successfully resolved
observedGeneration: 1
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
environmentId: DEFAULT
errors: {}
id: 011b0a6b-59d8-452b-95a4-30db51783b83
organizationId: DEFAULT
processingStatus: Completed
```
## Possible CRD conditions
When a Custom Resource Definition (CRD) is successfully applied without issues, your CRD's status section displays conditions like the following example:
```yaml
status:
conditions:
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: Successfully reconciled
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: All References successfully resolved
observedGeneration: 1
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
```

If GKO encounters issues resolving resources referenced within your CRD such as ManagementContext, Secrets, Groups, andAPIs, the conditions reflect a failure like the following example:
```yaml
status:
conditions:
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: ReconcileFailed
observedGeneration: 1
reason: Accepted
status: "False"
type: Accepted
- lastTransitionTime: "2025-10-03T09:25:22Z"
message: "can not find Management Context [dev-ctx]"
observedGeneration: 1
reason: ResolvedRefs
status: "False"
type: ResolvedRefs
```

Common Causes of Unaccepted CRDs
- ResolveRefError (Unresolved References): GKO is unable to resolve references within your CRD, such as Management Contexts, Shared Policy Groups, or APIs.
- IllegalStateError: It indicates that there is inconsistency in the CRD. For example in the case of a V2 API CRD, you set local=true, but you didn't specify a Management Context.
- CompileTemplateError: This error might happen when our template engine can't compile the CRD (due to invalid characters or other reasons)
- ControlPlaneError: Errors occurring during runtime, such as invalid values or misconfigurations passed when importing your API into APIM.

## Leveraging Status with GitOps

The improved structured status output allows for tighter integration with GitOps tools that watch Kubernetes events.

For example, when using ArgoCD:

1. Define an ArgoCD Application that monitors the GKO namespace.
2. ArgoCD detects any drifts between the desired state (Git repo) and the current status fields.
3. Based on the CRD status messages, ArgoCD takes the appropriate actions:
- Apply resources if creation failed (`*Accepted` condition false)
- Set the resource as "Degraded" if operations failed (`*ResolvedRefs` false)
- Trigger notifications based on configured events

The standardized schema lets you create cleaner, more automated GitOps workflows around the full API lifecycle on Kubernetes.


The following sections explain each CRD