Configuration Examples
APISIX Ingress Controller supports both Ingress resources and Gateway API for traffic management in Kubernetes. While both are supported, the Gateway API provides greater flexibility and extensibility. New users are encouraged to adopt Gateway API for future deployments.
In addition to these standard Kubernetes APIs, the APISIX Ingress Controller also supports a set of CRDs (Custom Resource Definitions) designed specifically for APISIX-native functionality.
This document provides examples of common configurations covering how and when to use these resources. You should adjust custom values such as namespaces, route URIs, and credentials to match your environment.
Currently there are no differences between APISIX Ingress Controller and API7 Ingress Controller.
Configure CP Endpoint and Admin Key
To update the Control Plane endpoint and admin key for connectivity between APISIX Ingress Controller and Control Plane at runtime:
apiVersion: apisix.apache.org/v1alpha1
kind: GatewayProxy
metadata:
namespace: ingress-apisix
name: apisix-config
spec:
provider:
type: ControlPlane
controlPlane:
endpoints:
- http://127.0.0.1:9180
auth:
type: AdminKey
adminKey:
value: replace-with-your-admin-key
Define Controller and Gateway
To specify the controller responsible for handling resources before applying further configurations:
- Gateway API
- Ingress
- APISIX CRD
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: apisix
spec:
controllerName: "apisix.apache.org/apisix-ingress-controller"
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
namespace: ingress-apisix
name: apisix
spec:
gatewayClassName: apisix
listeners:
- name: http
protocol: HTTP
port: 80
infrastructure:
parametersRef:
group: apisix.apache.org
kind: GatewayProxy
name: apisix-config
❶ The controllerName field in GatewayClass needs to be customized if you are running multiple distinct instances of the APISIX Ingress Controller in the same cluster (not a single instance with multiple replicas). Each ingress controller instance must use a unique controllerName in its configuration file, and the corresponding GatewayClass should reference that value.
❷ API group of the referenced resource.
❸ Kind of the referenced resource.
❹ Name of the referenced resource. Should match the metadata.name
of the GatewayProxy resource.
The port
in the Gateway listener is required but ignored. This is due to limitations in the data plane: it cannot dynamically open new ports. Since the Ingress Controller does not manage the data plane deployment, it cannot automatically update the configuration or restart the data plane to apply port changes.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: apisix
spec:
controller: apisix.apache.org/apisix-ingress-controller
parameters:
apiGroup: apisix.apache.org
kind: GatewayProxy
name: apisix-config
namespace: ingress-apisix
scope: Namespace
❶ API group of the referenced resource.
❷ Kind of the referenced resource.
❸ Name of the referenced resource. Should match the metadata.name
of the GatewayProxy resource.
❹ Namespace where the referenced resource is defined.
❺ Scope of the referenced resource.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: apisix
spec:
controller: apisix.apache.org/apisix-ingress-controller
parameters:
apiGroup: apisix.apache.org
kind: GatewayProxy
name: apisix-config
namespace: ingress-apisix
scope: Namespace