-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
geoip2 enabling causes crash of controller v1.10 #11320
Comments
/remove-kind bug Lets add the bug label after triaging is completed
/triage needs-information |
Noted same issue - bump from helm-chart 4.6.1 to 4.10.0. controller:
kind: DaemonSet
maxmindLicenseKey: change-me
config:
use-geoip2: "true"
log-format-escape-json: "true"
log-format-upstream: '{
....
"geoip_country_code": "$geoip_country_code"}' It's appear that
|
Any chance you can try to reproduce this problem on a minikube cluster or a kind cluster but only with geoip2 enabled and no other customization |
Hi @longwuyuan |
Thanks. Can you ping me on slack. I am trying to figure out if it can also be reproduced only and only with geop2 enabled and no other customization. |
/remove-kind support |
@ducnm0711 I don't have a licence to test so can you change the variable name and test leev/ngx_http_geoip2_module#92 (comment) We have removed the non geoip2 components but it will be a least effort test to do this. thanks |
/assign |
/retitle geoip2 enabling causes crash of controller v1.10 |
i saw that there is a lite database for free so I will attempt to reproduce on minikube. meanwhile if you can also confirm that no variable no daemonset and no other customization, just enable geoip2, crashes the controller. If you have to use variable, then at least I will try to reproduce with var name as |
cc @rikatz |
|
|
So please change the variable name /remove-kind bug |
@jlm0x017 Please re-open the issue if you find a problem with the controller. For now I will close the issue as there is no problem found in the controller. Problem is just the variable name is invalid /close |
@longwuyuan: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@longwuyuan Thanks for diving into this. You're exactly right, the variable name was being used in 'log-format-upstream:'; it was an artifact sticking around from prior versions. I identified where this was being set and removed it. 4.10.0+ are running just fine. |
Resolved the issue by updating maxmind license key |
Hello everyone. I faced same issue during upgrading to chart 4.11.2. |
@Pilotindream You may recreate maxmindLicesnsekey(https://support.maxmind.com/hc/en-us/articles/4407111582235-Generate-a-License-Key) Here is my config, for example: |
tl;dr: nginx fails to start in controller:
What happened:
Using helm-chart 4.9.1 we experience no issues.
In updating to helm-chart 4.10.0 (and in 4.10.1) we have failures. The deployment for ingress-nginx-controller pods fail with these events:
What you expected to happen:
I expect helm-chart versions to upgrade cleanly, or with well-advertised required configuration changes.
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
version from running 4.9.1 helm chart:
$ /nginx-ingress-controller --version
NGINX Ingress controller
Release: v1.9.6
Build: 6a73aa3
Repository: https://github.com/kubernetes/ingress-nginx
nginx version: nginx/1.21.6
From failing 4.10.0 helm chart:
*Kubernetes version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.8-eks-adc7111
Environment:
AWS EKS 1.28
Bottlerocket OS 1.19.4 (aws-k8s-1.28)
Kernel 6.1.82
Install tools:
Basic cluster related info:
kubectl get nodes -o wide
How was the ingress-nginx-controller installed:
Current State of the controller:
Current state of ingress object, if applicable:
Others:
pod logs
logs from a failing pod:
How to reproduce this issue:
These should suffice to install working and non-working versions:
Anything else we need to know:
Checking recent issues, this appears to be the only close complaint: #11254. That said, the versions are different. They're on controller-1.9.4 and a bump to 1.9.6 fixes their issue. I did not try providing an emptydir for geoip configuration, or other stub files, as he did.
** attempted work-arounds **
I tried to alternate specifcations:
the chart still failed with crashloopbackoff
the chart still failed with crashloopbackoff
The text was updated successfully, but these errors were encountered: