Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
    • Overview of Konnect
    • Architecture
    • Network Resiliency and Availability
    • Port and Network Requirements
    • Compatibility
    • Stages of Software Availability
    • Release Notes
      • Control Plane Upgrades FAQ
      • Supported Installation Options
    • Overview
    • Access a Konnect Account
    • Set up a Runtime
    • Configure a Service
    • Implement and Test the Service
      • Publish and Consume Services
      • Register Applications
    • Import Kong Gateway Entities into Konnect
    • Overview
      • Overview
      • Dashboard
      • Manage Runtime Groups with UI
      • Manage Runtime Groups with decK
      • Installation Options
      • Install with Docker
      • Install on Kubernetes
      • Install on Linux
      • Install on AWS
      • Install on Azure
      • Upgrade a Runtime Instance to a New Version
      • Renew Certificates
      • Runtime Parameter Reference
    • Create Consumer Groups
      • Overview
      • Set Up and Use a Vault in Konnect
    • Kong Gateway Configuration in Konnect
    • Plugin Ordering Reference
    • Troubleshoot
    • Overview
    • Manage Service Documentation
      • Overview
      • Configure a Plugin on a Service
      • Configure a Plugin on a Route
    • Overview
    • Access the Dev Portal
    • Sign Up for a Dev Portal Account
      • Manage Developer Access
      • Manage Application Registration Requests
      • Manage Application Connections
      • Auto Approve Dev and App Registrations
      • Azure OIDC
      • Application Overview
      • Enable and Disable App Registration
        • Overview
        • Okta
        • Curity
        • Auth0
      • Create, Edit, and Delete an Application
      • Register an Application with a Service
      • Generate Credentials for an Application
    • Customize Dev Portal
    • Troubleshoot
    • Introduction to Analytics
    • Summary Dashboard
    • Analyze Services and Routes
    • Generate Reports
    • Troubleshoot
      • Manage a Konnect Account or Plan
      • Change to a Different Plan
      • Manage Payment Methods and Invoices
      • Overview
        • Overview
        • Manage Teams
        • Teams Reference
        • Roles Reference
      • Manage Users
      • Manage System Accounts
      • Set up SSO with OIDC
      • Set up SSO with Okta
      • Login Sessions Reference
    • Account and Org Deactivation
    • Troubleshoot
    • Overview
      • API Documentation
      • Identity Integration Guide
      • API Documentation
      • API Documentation
      • Portal RBAC Guide
      • Overview
      • Nodes
      • Data Plane Certificiates
        • Services
        • Routes
        • Consumers
        • Plugins
        • Upstreams
        • Certificates
        • CA Certificates
        • SNIs
        • Targets
        • Vaults
      • API Spec
      • Filtering
    • Labels

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

Kong Konnect
  • Home
  • Kong Konnect
  • Network Resiliency and Availability

Network Resiliency and Availability

Kong Konnect deployments run in hybrid mode, which means that there is a separate control plane attached to one or more data plane nodes. These planes must communicate with each other to receive and send configuration. If communication is interrupted and either side can’t send or receive config, data plane nodes still continue proxying traffic to clients.

Whenever a data plane node receives new configuration from the control plane, it immediately loads that config into memory. At the same time, it caches the config as config.json.gz into /usr/local/kong by default.

Communication

How do the control plane and data planes communicate?

Data traveling between control planes and data planes is secured through a mutual TLS handshake. Data planes initiate the connection to the Konnect control plane. Once the connection is established, the control plane can send configuration data to the connected data planes.

Normally, the data plane maintains a persistent connection with the control plane. The data plane sends a heartbeat to the control plane every 30 seconds to keep the connection alive. If it receives no answer, it tries to reconnect to the control plane node after a 5-10 second random delay.

What types of data travel between the Kong Konnect control plane and the data planes, and how?

There are two types of data that travel between the planes: configuration and telemetry. Both use the secure TCP port 443.

  • Configuration: the control plane sends configuration data to any connected data planes in the cluster.

  • Telemetry: data plane nodes send usage information to the control plane for Analytics and for account billing. Analytics tracks aggregate traffic by service, route, and the consuming application. For billing, Kong tracks the number of services, API calls, and active dev portals.

Telemetry data does not include any customer information or any data processed by the data plane. All telemetry data is encrypted using mTLS.

How frequently does data travel between the control plane and data planes?

When you make a configuration change on the control plane, that change is immediately pushed to any connected data plane nodes.

Connection behavior and incident recovery

What happens if Kong Konnect goes down?

If the Kong-hosted control plane goes down, the control plane/data plane connection gets interrupted. You can’t access the control plane or change any configuration during this time.

A connection interruption has no negative effect on the function of your data plane proxies. They continue to proxy and route traffic normally, and any services implemented through the Service Hub continue to work as before.

What happens if the control plane and data plane disconnect?

If the control plane and data plane become disconnected, configuration can’t travel between them. In that situation, the data plane continues to use cached configuration until it reconnects to the control plane and receives new configuration.

Whenever a connection is re-established with the CP node, the control plane always pushes the latest configuration to the data plane. It doesn’t queue up or try to apply older changes.

How long can data plane nodes remain disconnected from the control plane?

A data plane node will keep pinging the control plane forever, until the connection is re-established or the data plane is stopped.

The data plane proxy needs to connect to the control plane at least once. The control plane pushes configuration to the data plane, and each data plane node caches that configuration in-memory. It continues to use this cached configuration until it receives new instructions from the control plane.

There are situations that can cause further problems:

  • If the license that the data plane received from the control plane expires, the data plane stops working.
  • If the data plane node’s configuration cache file (config.json.gz) gets deleted, it loses access to the last known configuration and starts up empty.

Can I restart a data plane node if the control plane is down or disconnected?

Yes. If you restart a data plane, it uses a cached configuration to continue functioning the same as before the restart.

Can I create a new data plane node when the connection is down?

No.

Backups and alternative options

Can I create a backup configuration to use in case the cache fails?

You can set the declarative_config option to load a fallback YAML config.

Can I change a data plane node’s configuration when it’s disconnected from the control plane?

Yes, if necessary, though any manual configuration will be overwritten the next time the control plane connects to the node.

You can load configuration manually in one of the following ways:

  • Copy the configuration cache file (config.json.gz) from another data plane node with a working connection and overwrite the cache file on disk for the disconnected node.
  • Remove the cache file, then start the data plane node with declarative_config to load a fallback YAML config.
Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023