You are browsing documentation for an outdated version.
See the latest documentation here.
Kubernetes API allows creating events to notify users about changes in the cluster. Events are treated as informative,
best-effort, supplemental data which might be helpful in debugging issues. Some of the built-in events users might be
familiar with are
Every event has a set of fields defined in the Event
API object schema. The most relevant of those in the context of Kong Ingress Controller are:
Reason - a short, machine-friendly string that describes the reason for emitting an event, can be treated
as a category (e.g.
Message - a human-readable description of the event with a detailed explanation of what happened (e.g.
invalid methods: cannot set 'methods' when 'protocols' is 'grpc' or 'grpcs').
Type - a string that describes the type of the event (e.g.
InvolvedObject - a reference to the object(s) that the event is about (e.g.
All the events that are emitted by Kong Ingress Controller are listed in the table below.
||During the translation of Kubernetes resources into a Kong state, a conflict was detected. The involved object(s) were skipped to unblock building the Kong state without them.
||Any of the supported resources (e.g.
||A Kong state built from Kubernetes resources was rejected by the Kong Gateway Admin API. The update of the configuration was not effective.
||In the case of a failure caused by a specific object - any of the supported resources (e.g.
HTTPRoute, etc.). When a specific causing object couldn’t be identified, the event is attached to the Kong Ingress Controller Pod.
||A Kong state built from Kubernetes resources was successfully applied to the Kong Gateway Admin API.
||Kong Ingress Controller Pod.
Although Kong Ingress Controller provides Prometheus metrics to monitor the current state of the configuration translation and application
see Prometheus Metrics for details), it’s recommended to use the events to get more information
about the root cause of the issue when the metrics indicate that something went wrong.
Events can be inspected using the
kubectl get events command. Their
reason field might be used to filter a specific
kind of events (e.g.
The output of the command will look similar to this:
kubectl get events --field-selector='reason=KongConfigurationApplyFailed'
LAST SEEN TYPE REASON OBJECT MESSAGE
1m Warning KongConfigurationApplyFailed KongPlugin/my-plugin Plugin schema validation failed: invalid value "foo" for field "config"