-
Notifications
You must be signed in to change notification settings - Fork 591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KongClusterPlugin can not be found #2090
Comments
Hi @Panzki thanks for the report. There appears to be some problems with the versioning reported here:
These are not versions of the Kong Kubernetes Ingress Controller (KIC) but instead would appear to be versions of the Kong Gateway (packaged with KIC). The latest version of KIC currently is |
Hi, |
Thanks for the update. So using the I used this deployment: apiVersion: apps/v1
kind: Deployment
metadata:
name: httpbin-deployment
labels:
app: httpbin
spec:
selector:
matchLabels:
app: httpbin
template:
metadata:
labels:
app: httpbin
spec:
containers:
- name: httpbin
image: kennethreitz/httpbin
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
labels:
app: httpbin
name: httpbin-deployment
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: httpbin
type: ClusterIP With this apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: httpbin-ingress
annotations:
httpbin.ingress.kubernetes.io/rewrite-target: /
kubernetes.io/ingress.class: "kong"
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: httpbin-deployment
port:
number: 80 The initial result was: $ curl -vvv http://172.18.0.240/status/200
* Trying 172.18.0.240:80...
* Connected to 172.18.0.240 (172.18.0.240) port 80 (#0)
> GET /status/200 HTTP/1.1
> Host: 172.18.0.240
> User-Agent: curl/7.80.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Date: Mon, 13 Dec 2021 16:09:33 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< demo: injected-by-kong
< X-Kong-Upstream-Latency: 3
< X-Kong-Proxy-Latency: 1
< Via: kong/2.6.0
<
* Connection #0 to host 172.18.0.240 left intact Then I created this apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
name: add-response-header
annotations:
kubernetes.io/ingress.class: kong
config:
add:
headers:
- "demo: injected-by-kong"
plugin: response-transformer and applied it to my $ kubectl patch ingress httpbin-ingress -p '{"metadata":{"annotations":{"konghq.com/plugins":"add-response-header"}}}'
ingress.networking.k8s.io/httpbin-ingress patched After which: $ curl -vvv http://172.18.0.240/status/200
* Trying 172.18.0.240:80...
* Connected to 172.18.0.240 (172.18.0.240) port 80 (#0)
> GET /status/200 HTTP/1.1
> Host: 172.18.0.240
> User-Agent: curl/7.80.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Date: Mon, 13 Dec 2021 16:09:33 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< demo: injected-by-kong
< X-Kong-Upstream-Latency: 3
< X-Kong-Proxy-Latency: 1
< Via: kong/2.6.0
<
* Connection #0 to host 172.18.0.240 left intact And as we can see So it appears that given the versions you're using I'm not able to reproduce this problem at least with a simple example, do you have any more details you can provide? Can you please put together an example of manifests that don't work properly (you can use mine as a basis)? Also double check that your annotations:
kubernetes.io/ingress.class: kong If memory serves, some older versions of the KIC would GET |
Hi,
The missing annotation to the ingress resource was indeed the cause of the issue. Adding the annotation fixed the problem. I was not aware that this annotation was necessary. With version v2.2.0 of the Helm Chart it was working without the annotation, so the behavior must have changed. Is there any documentation or change log that can help me understand why the annotation is necessary with never version? |
No problem, glad that got your situation sorted out 👍
After digging into this it seems this was was present in the documentation for the type from What version did you upgrade from? |
This limitation has always been in place for global KongClusterPlugins: https:/Kong/kubernetes-ingress-controller/pull/520/files#diff-36de13ddfa1690d7bef40e3c6e8d05adfe4bb49493b54dce77829dc288906df7R258-R260 Referenced KongClusterPlugins maybe not. I think our advice was to include the class annotation anyway as a simplification ("just add it to all of these" rather than "add this annotation if you're making a global plugin, but omit it if not"), but it's possible we supported un-annotated referenced plugins. kubernetes-ingress-controller/internal/controllers/configuration/zz_generated_controllers.go Line 585 in 994fa04
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Is there an existing issue for this?
Current Behavior
I created a
KongClusterPlugin
and I want to use it with an ingress. The ingress is created in a different namespace. The plugin is not applied to my route and the log of the ingress-controller pod contains the following error message.However when I get all
KongClusterPlugin
resources using kubectl I can see that aKongClusterPlugin
resources with the name 'jwt' exists.Backgroud
The issue started to occur after upgrading to Kong Ingress Controller v2.4.0 in combination with Kubernetes v1.22.x. Prior to the upgrade we used KIC v2.2.0 and K8s v1.19.x and hand no issues.
KongPlugin
resource, instead of aKongClusterPlugin
resource, and it worked.The issue might be related to updates to the KIC CRDs.
Expected Behavior
The plugin is applied to the route. KIC is able to use the
KongClusterPlugin
resource across namespaces.Steps To Reproduce
Kong Ingress Controller version
Kubernetes version
Anything else?
I use some other plugins (basic-auth and response-transformer) as
KongPlugin
resources with several different ingress resources and in several different namespace. AllKongPlugin
resources work fine, the issue seems to be related to theKongClusterPlugin
resource.Thanks for looking into the issue. :smile
The text was updated successfully, but these errors were encountered: