このページは、まだ日本語ではご利用いただけません。翻訳中です。
Custom Resources
Custom Resources in Kubernetes allow controllers to extend Kubernetes-style declarative APIs that are specific to certain applications.
A few custom resources are bundled with the Kong Ingress Controller to configure settings that are specific to Kong and provide fine-grained control over the proxying behavior.
The Kong Ingress Controller uses the configuration.konghq.com
API group
for storing configuration specific to Kong.
These CRDs allow users to declaratively configure all aspects of Kong:
KongIngress
Note: Many fields available on KongIngress are also available as annotations. You can add these annotations directly to Service and Ingress resources without creating a separate KongIngress resource. When an annotation is available, it is the preferred means of configuring that setting, and the annotation value takes precedence over a KongIngress value if both set the same value.
The standard Ingress and Service Kubernetes resources can’t express the full range of Kong’s routing capabilities. You can use KongIngress to extend these resources.
KongIngress is a custom resource that attaches to Ingresses and Services and allows them to control all settings on the Kong routes, services, and upstreams generated for them. KongIngress is not an alternative to Ingress. It can’t be used independently and only functions when attached to another resource.
Once a KongIngress resource is created, you can use the konghq.com/override
annotation to associate the KongIngress resource with an Ingress or a Service
resource.
-
Annotated Ingress resource: All routes associated with the annotated
Ingress are updated to use the values defined in the KongIngress’s
route
section. -
Annotated Service resource: The
corresponding service and upstream in Kong are updated to use the
proxy
andupstream
blocks as defined in the associated KongIngress resource.
Don’t attach a KongIngress that sets values in the proxy
and
upstream
sections to an Ingress, as it won’t have any effect. These
sections are only honored when a KongIngress is attached to a Service.
Similarly, the route
section has no effect when attached to a Service, only
when attached to an Ingress.
This diagram shows how the resources are linked with one another.
flowchart TD A(apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
name: demo-kong-ingress
route:
# various route properties can be overridden):::left -->|konghq.com/override annotation-based association| B(apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: demo-api
annotations:
konghq.com/override: demo-kong-ingress):::left B --> C(apiVersion: v1
kind: Service
metadata:
name: echo-svc
annotations:
konghq.com/override: https-upstream):::left D(apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
name: https-upstream
proxy:
protocol: https
upstream:
# load-balancing and health-check behaviors can be tuned):::left --> C classDef left text-align:left; classDef lightBlue fill:#cce7ff; classDef lightGreen fill:#c4e1c4; class B lightGreen; class C lightBlue;
KongPlugin
Kong is designed around an extensible plugin architecture and comes with a wide variety of plugins already bundled inside it. These plugins can be used to modify the request or impose restrictions on the traffic.
Once this resource is created, the resource needs to be associated with an Ingress, Service, HTTPRoute, KongConsumer or KongConsumerGroup resource in Kubernetes.
This diagram shows how you can link a KongPlugin resource to an Ingress, Service, or KongConsumer.
flowchart TD subgraph Link to consumer direction TB E(apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: custom-api-limit
plugin: rate-limiting
config:
minute: 10):::left F(apiVersion: configuration.konghq.com
kind: KongConsumer
metadata:
name: demo-api
annotations:
konghq.com/plugins: custom-api-limit
username: special-client):::left end subgraph Link to Ingress and service direction TB A(apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: reports-api-limit
plugin: rate-limiting
config:
minute: 5):::left B(apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: demo-api
annotations:
konghq.com/plugins: reports-api-limit):::left C(apiVersion: v1
kind: Service
metadata:
name: billing-api
annotations:
konghq.com/plugins: billing-auth):::left D(apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: billing-auth
plugin: basic auth):::left end A --> |execute the plugin for any request that matches a rule in the following ingress resource|B B --> C D --> |execute the plugin for any request that is forwarded to the billing-api service in k8s|C E --> |Associated using konghq.com/plugins annotation|F classDef left text-align:left; classDef lightBlue fill:#cce7ff; classDef lightGreen fill:#c4e1c4; classDef lightPurple fill:#e6d8eb; class B lightGreen; class C lightBlue; class F lightPurple;
KongClusterPlugin
This resource requires the kubernetes.io/ingress.class
annotation.
KongClusterPlugin resource is exactly same as KongPlugin, except that it is a Kubernetes cluster-level resources rather than a namespaced resource. This can help when the configuration of the plugin needs to be centralized and the permissions to add or update plugin configuration rests with a different persona other than the application owners.
This resource can be associated with an Ingress, Service, or KongConsumer, and can be used in the exact same way as KongPlugin.
A namespaced KongPlugin resource takes priority over a KongClusterPlugin with the same name.
KongConsumer
This resource requires the kubernetes.io/ingress.class
annotation. Its value
must match the value of the controller’s --ingress-class
argument, which is
kong
by default.
This custom resource configures consumers in Kong. Every KongConsumer resource in Kubernetes directly translates to a Consumer object in Kong.
TCPIngress
This resource requires the kubernetes.io/ingress.class
annotation. Its value
must match the value of the controller’s --ingress-class
argument, which is
kong
by default.
This Custom Resource is used for exposing non-HTTP and non-GRPC services running inside Kubernetes to the outside world through Kong. This proves to be useful when you want to use a single cloud LoadBalancer for all kinds of traffic into your Kubernetes cluster.
It is very similar to the Ingress resource that ships with Kubernetes.
UDPIngress
This resource requires the kubernetes.io/ingress.class
annotation. Its value
must match the value of the controller’s --ingress-class
argument, which is
kong
by default.
This Custom Resource is used for exposing UDP services running inside Kubernetes to the outside world through Kong.
This is useful for services such as DNS servers, Game Servers, VPN software and a variety of other applications.
KongConsumerGroup
This feature requires Kong Gateway Enterprise 3.4 or higher. It is not compatible with the older consumer groups implementation introduced in Kong Gateway Enterprise 2.7.
This resource requires the kubernetes.io/ingress.class
annotation. Its value
must match the value of the controller’s --ingress-class
argument, which is
kong
by default.
KongConsumerGroup creates a consumer group, which associates KongPlugin resources with a collection of KongConsumers.
KongConsumers have a consumerGroups
array. Adding a KongConsumerGroup’s name
to that array adds that consumer to that consumer group.
Applying a konghq.com/plugins: <KongPlugin name>
annotation to a KongConsumerGroup
then executes that plugin on every consumer in the consumer group.