Closed Stono closed 2 years ago
@Stono: This issue is currently awaiting triage.
If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
/remove-kind bug /kind support /triage needs-information
Please upgrade to a recent release (prefer the latest) and check if the problem happens
@longwuyuan Upgrading is a bit tricky due to https://github.com/kubernetes/ingress-nginx/issues/7753
There have been many checkins/fixes since the version you are using, so unsure how much progress can be made and at what speed on this
I'm seeing a similar issue with an ingress-nginx
pod installed via this repo's helm chart with the following helm commands:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install nginx-ingress ingress-nginx/ingress-nginx --namespace ingress --set controller.replicaCount=2 --values helm/nginx-values.yaml
where helm/nginx-values.yaml
contains the following to workaround the fargate privilege escalation / port issue:
controller:
extraArgs:
http-port: 8080
https-port: 8443
containerPort:
http: 8080
https: 8443
service:
ports:
http: 80
https: 443
targetPorts:
http: 8080
https: 8443
image:
allowPrivilegeEscalation: false
# https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes
livenessProbe:
initialDelaySeconds: 1200 # 30
readinessProbe:
initialDelaySeconds: 1200 # 0
service:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
..and the apparent chart versions:
> helm list -n ingress
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
nginx-ingress ingress 1 2021-11-12 19:55:30.921251692 +0000 UTC deployed ingress-nginx-4.0.6 1.0.4
and:
> kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-0389ca3", GitCommit:"8a4e27b9d88142bbdd21b997b532eb6d493df6d2", GitTreeState:"clean", BuildDate:"2021-07-31T01:34:46Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
Environment is a fresh Fargate-only EKS cluster that was created with 3 public and 3 private subnets.
Regardless of my probe initialDelay settings, I encounter perpetual "CrashLoopBackOff" and my pod/container logs are littered with:
2021/11/12 20:06:19 [emerg] 28#28: bind() to 0.0.0.0:8443 failed (98: Address in use)
2021/11/12 20:06:19 [emerg] 28#28: bind() to [::]:8443 failed (98: Address in use)
As I describe here I'm able to kubectl exec
into the running container and use netstat
to confirm that indeed 0/INADDR_ANY:8443 is already bound, but bc I can't get in as root, I cannot see what the process is that's doing it.
Can someone shed some light on why the applications in my ingress-nginx
containers are failing to do the most basic requirement, binding to port 8443?
I linked to the fargate privilege escalation / port issue bc it feels related. Thanks.
EDIT: I ended up creating this new issue for what I describe above, but it has been resolved due to another cause.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closing this issue.
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Kubernetes version (use
kubectl version
):Environment: GKE We have around 1000 ingress resources on the cluster.
What happened:
During a regular rolling restart of ingress-nginx controller, during initial startup it seemed to get stuck in some sort of configuration loop, repeating until the liveness probe killed it.
Once the liveness probe killed it, it came back up fine.
There are 6 pods, and this only happened on one of them, so it's an ephemeral failure that I am struggling to recreate.
Here are the logs:
What you expected to happen:
Not to crash
How to reproduce it: Unable to reproduce unfortunately!
Anything else we need to know: Noticed this issue: https://github.com/kubernetes/ingress-nginx/issues/4616 - but we don't use hostNetwork
/kind bug