Skip to content
Kong Docs are moving soon! Our docs are migrating to a new home. You'll be automatically redirected to the new site in the future. In the meantime, view this page on the new site!
Kong Logo | Kong Docs Logo
  • Docs
    • Explore the API Specs
      View all API Specs View all API Specs View all API Specs arrow image
    • Documentation
      API Specs
      Kong Gateway
      Lightweight, fast, and flexible cloud-native API gateway
      Kong Konnect
      Single platform for SaaS end-to-end connectivity
      Kong AI Gateway
      Multi-LLM AI Gateway for GenAI infrastructure
      Kong Mesh
      Enterprise service mesh based on Kuma and Envoy
      decK
      Helps manage Kong’s configuration in a declarative fashion
      Kong Ingress Controller
      Works inside a Kubernetes cluster and configures Kong to proxy traffic
      Kong Gateway Operator
      Manage your Kong deployments on Kubernetes using YAML Manifests
      Insomnia
      Collaborative API development platform
  • Plugin Hub
    • Explore the Plugin Hub
      View all plugins View all plugins View all plugins arrow image
    • Functionality View all View all arrow image
      View all plugins
      AI's icon
      AI
      Govern, secure, and control AI traffic with multi-LLM AI Gateway plugins
      Authentication's icon
      Authentication
      Protect your services with an authentication layer
      Security's icon
      Security
      Protect your services with additional security layer
      Traffic Control's icon
      Traffic Control
      Manage, throttle and restrict inbound and outbound API traffic
      Serverless's icon
      Serverless
      Invoke serverless functions in combination with other plugins
      Analytics & Monitoring's icon
      Analytics & Monitoring
      Visualize, inspect and monitor APIs and microservices traffic
      Transformations's icon
      Transformations
      Transform request and responses on the fly on Kong
      Logging's icon
      Logging
      Log request and response data using the best transport for your infrastructure
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
Kong Ingress Controller
3.4.x (latest) LTS
  • Home icon
  • Kong Ingress Controller
  • Reference
  • Failure Modes and Processing in KIC
github-edit-pageEdit this page
report-issueReport an issue
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • unreleased
  • 3.4.x (latest) (LTS)
  • 3.3.x
  • 3.2.x
  • 3.1.x
  • 3.0.x
  • 2.12.x (LTS)
  • 2.11.x
  • 2.10.x
  • 2.9.x
  • 2.8.x
  • 2.7.x
  • 2.6.x
  • 2.5.x (LTS)
  • Introduction
    • Overview
    • Kubernetes Gateway API
    • Version Support Policy
    • Changelog
  • How KIC Works
    • Architecture
    • Gateway API
    • Ingress
    • Custom Resources
    • Using Annotations
    • Admission Webhook
  • Get Started
    • Install KIC
    • Services and Routes
    • Rate Limiting
    • Proxy Caching
    • Key Authentication
  • KIC in Production
    • Deployment Topologies
      • Overview
      • Gateway Discovery
      • Database Backed
      • Traditional (sidecar)
    • Installation Methods
      • Helm
      • Kong Gateway Operator
    • Cloud Deployment
      • Azure
      • Amazon
      • Google
    • Enterprise License
    • Observability
      • Prometheus Metrics
      • Configuring Prometheus and Grafana
      • Kubernetes Events
    • Upgrading
      • Kong Gateway
      • Ingress Controller
  • Guides
    • Service Configuration
      • HTTP Service
      • TCP Service
      • UDP Service
      • gRPC Service
      • TLS
      • External Service
      • HTTPS Redirects
      • Multiple Backend Services
      • Configuring Gateway API resources across namespaces
      • Configuring Custom Kong Entities
    • Request Manipulation
      • Rewriting Hosts and Paths
      • Rewrite Annotation
      • Customizing load-balancing behavior
    • High Availability
      • KIC High Availability
      • Service Health Checks
      • Last Known Good Config
      • Fallback Configuration
    • Security
      • Kong Vaults
      • Using Workspaces
      • Preserving Client IP
      • Kubernetes Secrets in Plugins
      • Verifying Upstream TLS
    • Migrate
      • KongIngress to KongUpstreamPolicy
      • Migrating from Ingress to Gateway
      • Credential Type Labels
    • Customize Deployments
      • Images
    • Custom Ingress Class
      • Internal / External Traffic
  • Plugins
    • Custom Plugins
    • Authentication
    • ACL
    • Rate Limiting
    • mTLS
    • OIDC
  • Reference
    • Troubleshooting
    • Version Compatibility
    • Annotations
    • Configuration Options
    • Feature Gates
    • FAQ
      • Plugin Compatibility
      • Kong Router
      • Custom nginx.conf
    • Custom Resource Definitions
    • Resources Requiring Setting Ingress Class
    • Gateway API migration
    • Required Permissions for Installation
    • Categories of Failures
    • Combining Services From Different HTTPRoutes
enterprise-switcher-icon Switch to OSS
On this pageOn this page
  • Errors in reconciling Kubernetes resources
  • Failures in translating configuration
  • Failures in applying configuration to Kong Gateway
    • Debugging configuration failures
  • Failures in uploading configuration to Konnect

Failure Modes and Processing in KIC

This reference describes the different types of Kong Ingress Controller failure modes and how it processes them.

When you run Kong Ingress Controller, you can encounter the following failures:

Error Example Failure Mode
Reconciler error in logs Errors in reconciling Kubernetes resources
Non-existent service referenced by an Ingress.
Example: Ingress with a non-existent backend service
Failures in translating configuration
Kong Gateway rejected configuration
Example: Ingress with invalid regex in the path
Failures in applying configuration to Kong Gateway
Errors when sending configuration to Kong Konnect
Example: Failed request logs
Failures in uploading configuration to Konnect

Kong Ingress Controller uses different methods to process each failure type, and creates error logs or other evidence, like Prometheus metrics and Kubernetes events, so you can observe and track the failures.

Errors in reconciling Kubernetes resources

When the controllers reconciling a specific kind of Kubernetes resource run into errors in reconciling the resource, a Reconciler error log line is recorded and the resource is re-queued for another round of reconciliation.

Thee Prometheus metric controller_runtime_reconcile_errors_total stores the total number of reconcile errors per controller from the start of Kong Ingress Controller. Search for the Reconciler error keyword in the Kong Ingress Controller container logs to see detailed errors.

Failures in translating configuration

When Kong Ingress Controller finds Kubernetes resources that can’t be correctly translated to Kong Gateway configuration (for example, an Ingress is using a non-existent Service as its backend), a translation failure is generated with the namespace and name of the objects causing the failure.

The Kubernetes objects causing translation failures are not translated to Kong Gateway configuration in the translation process. You can use Kubernetes events and Prometheus metrics to observe the translation failures. If Kong Ingress Controller is integrated with Kong Konnect, it will report that a translation error happened in the uploading node status.

Kong Ingress Controller collects all translation failures and generates a Kubernetes Event with the Warning type and the KongConfigurationTranslationFailed reason for each causing object in a translation failure. Prometheus metrics could also reflect the statistics of translation failures:

  • ingress_controller_translation_broken_resource_count is the number of translation failures that happened in the latest translation
  • ingress_controller_translation_count with the success=false label is the total number of translation procedures where translation failures happened

You can use kubectl get events -n <namespace> --field-selector reason="KongConfigurationTranslationFailed" to fetch events generated for translation failures. For example, if an Ingress named ing-1 in the namespace test used a non-existent Service as its backend, you could get the event with the following command:

kubectl get events -n test --field-selector reason="KongConfigurationTranslationFailed"

LAST SEEN   TYPE      REASON                               OBJECT                    MESSAGE
18m         Warning   KongConfigurationTranslationFailed   ingress/ing-1   failed to resolve Kubernetes Service for backend: failed to fetch Service test/httpbin-deployment-1: Service test/httpbin-deployment-1 not found

Failures in applying configuration to Kong Gateway

When Kong Ingress Controller fails to apply translated Kong Gateway configuration to Kong Gateway, Kong Ingress Controller will try to recover from the failure and record the failure into logs, Kubernetes events, and Prometheus metrics. Recovery usually fails because the translated configuration is rejected by Kong Gateway.

If Kong Ingress Controller fails to apply the translated configuration, it then tries to apply the last successful Kong Gateway configuration to new instances of Kong Gateway to attempt a best effort at making them available. If the FallbackConfiguration feature gate is enabled, Kong Ingress Controller discovers the Kubernetes objects that caused the invalid configuration, and tries to build a fallback configuration from valid objects and parts of the last valid configuration that are built from the broken objects. See fallback configuration for more information.

Debugging configuration failures

You can observe failures in applying configuration from Kubernetes events and Prometheus metrics:

  • Kong Ingress Controller generates an event with the Warning type and the KongConfigurationApplyFailed reason attached to the pod itself when it fails to apply the configuration.
  • For each object that causes the invalid configuration, Kong Ingress Controller generates a Warning event type and the KongConfigurationApplyFailed reason attached to the object.
  • The Prometheus metric ingress_controller_configuration_push_count with the success=false label shows the total number of failures from applying the configuration by reason and URL of Kong Gateway admin API.
  • The Prometheus metric ingress_controller_configuration_push_broken_resource_count reflects the number of Kubernetes resources that caused the error in the last configuration push.

If the CLI flag --dump-config is enabled, then the /debug/config/raw-error endpoint is enabled on the debug server port of Kong Ingress Controller, which will fetch the raw error returned from Kong Gateway if applying the configuration fails.

For example, let’s say you create an Ingress with the ImplementationSpecific path type and an invalid regex in Path (which can only be only be done when the validating webhook is disabled, otherwise it will be rejected by the webhook):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    konghq.com/strip-path: "true"
  name: ingress-invalid-regex
  namespace: default
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - backend:
          service:
            name: httpbin-deployment
            port:
              number: 80
        path: /~^^/a$
        pathType: ImplementationSpecific

You can get the Kubernetes events:

kubectl get events --all-namespaces --field-selector reason=KongConfigurationApplyFailed
NAMESPACE   LAST SEEN   TYPE      REASON                         OBJECT                                 MESSAGE
default     2m9s        Warning   KongConfigurationApplyFailed   ingress/ingress-invalid-regex          invalid paths.1: should start with: / (fixed path) or ~/ (regex path)
kong        15s         Warning   KongConfigurationApplyFailed   pod/kong-controller-779cb796f4-7q7c2   failed to apply Kong configuration to https://10.244.1.43:8444: HTTP status 400 (message: "failed posting new config to /config")

Both the events attached to the invalid ingress and attached to the Kong Ingress Controller pod are recorded.

Failures in uploading configuration to Konnect

When Kong Ingress Controller is integrated with Konnect and it fails to send configuration to Konnect, it generates error logs for failed requests, records the failures to Prometheus metrics, and updates the node status of itself in Konnect:

  • Kong Ingress Controller parses errors returned from Konnect when uploading the configuration fails. It logs a line at the error level for each Kong Gateway entity that failed to create/update/delete, with the message Failed to send request to Konnect.
  • The Prometheus metrics ingress_controller_configuration_push_count and ingress_controller_configuration_push_duration_milliseconds_bucket can also reflect configuration upload failures to Konnect, where the dataplane label is the URL of Konnect and success=false APIs.
Thank you for your feedback.
Was this page useful?
Too much on your plate? close cta icon
More features, less infrastructure with Kong Konnect. 1M requests per month for free.
Try it for Free
  • Kong
    Powering the API world

    Increase developer productivity, security, and performance at scale with the unified platform for API management, service mesh, and ingress controller.

    • Products
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • Product Updates
      • Get Started
    • Documentation
      • Kong Konnect Docs
      • Kong Gateway Docs
      • Kong Mesh Docs
      • Kong Insomnia Docs
      • Kong Konnect Plugin Hub
    • Open Source
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kong Community
    • Company
      • About Kong
      • Customers
      • Careers
      • Press
      • Events
      • Contact
  • Terms• Privacy• Trust and Compliance
© Kong Inc. 2025