Kong Helm Charts

Kong Ingress Controller v2.9+ supports Gateway Discovery, which allows the controller to dynamically discover Gateway instances via a Kubernetes Admin API service. This requires a split release installation where Gateways and the Ingress Controller are deployed separately.

Configuration Options

Enable or disable the feature using ingressController.gatewayDiscovery.enabled:

• false (default): The controller manages a pre-determined set of Gateways using the CONTROLLER_KONG_ADMIN_URL environment variable.
• true: The controller dynamically locates Gateways by watching a specified Kubernetes service via the CONTROLLER_KONG_ADMIN_SVC environment variable.

Required Service Flags

If enabled is true, you must specify the Admin API Service details:

• ingressController.gatewayDiscovery.adminApiService.name: The name of the service.
• ingressController.gatewayDiscovery.adminApiService.namespace: The namespace of the service.
• ingressController.gatewayDiscovery.generateAdminApiService: If set to true, the chart automatically generates the name and namespace based on the current Helm release name and namespace. This is recommended when using the kong chart as a subchart.

DNS Strategy for Gateway Addresses

You can control how Gateway addresses are generated using the CONTROLLER_GATEWAY_DISCOVERY_DNS_STRATEGY environment variable (or the --gateway-discovery-dns-strategy CLI flag).

Supported values:

• service: Uses service-scoped pod DNS names (pod-ip-address.service-name.my-namespace.svc.cluster-domain.example).
• pod: Uses namespace-scoped pod DNS names (pod-ip-address.my-namespace.pod.cluster-domain.example).
• ip (default): Uses regular IP addresses.

ingressController:
  gatewayDiscovery:
    enabled: true
    adminApiService:
      name: my-admin-service
      namespace: kong-namespace
    generateAdminApiService: false

The Kong chart automates migrations using a specific lifecycle during helm upgrade:

1. An initial job runs kong migrations up.
2. New Kong pods with the updated version are spawned.
3. Once new pods are ready and processing traffic, old pods are terminated.
4. A final job runs kong migrations finish.

Important Considerations:

• Split Deployments: If you separate proxy and admin nodes into different Helm releases, you must manually set which migration jobs run based on your upgrade order.
• Hybrid Mode: For hybrid mode, you must upgrade the control plane version first to maintain compatibility.
• Upgrade Path: The chart automates migrations but does not enforce the recommended Kong upgrade path. If skipping multiple minor versions, consult the official Kong Open Source or Enterprise upgrade guides.
• Independent Upgrades: It is recommended to upgrade the Helm chart version and the Kong container version independently to isolate issues between Kubernetes resources and Kong itself.

Kong Manager and the Developer Portal use the Kong Sessions plugin. Because this requires an HMAC key, configuration must be stored in Kubernetes Secrets.

1. Create two JSON files: admin_gui_session_conf and portal_session_conf.
2. Create a single secret containing both files: kubectl create secret generic kong-session-config --from-file=admin_gui_session_conf --from-file=portal_session_conf
3. In values.yaml, set .enterprise.rbac.session_conf_secret to the name of this secret.
4. For the Developer Portal, add env.portal_session_conf using a secretKeyRef to the same secret.

Warning: Always change the secret value in your JSON configuration files before deployment.

// Example admin_gui_session_conf
{
  "cookie_name": "admin_session",
  "cookie_samesite": "off",
  "secret": "admin-secret-CHANGEME",
  "cookie_secure": true,
  "storage": "kong"
}

kubectl create secret generic kong-session-config --from-file=admin_gui_session_conf --from-file=portal_session_conf