Skip to content
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

ssl_certificate_info metrics shows fake certificate though the host is served with the correct certificate #12647

Closed
Melvin-Antony opened this issue Jan 9, 2025 · 7 comments
Labels
needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@Melvin-Antony
Copy link

What happened:

We have observed that the nginx_ingress_controller_ssl_certificate_info metric is reporting the 'Kubernetes Ingress Controller Fake Certificate' for certain ingresses, despite the fact that the correct certificate is being served for the corresponding host by the same controller. This inconsistency complicates the effective use of this metric for alerting purposes. Additionally, we have noted that other controllers within the same deployment are providing accurate data, while the erroneous value appears intermittently in only some controller(s).

What you expected to happen:

All the controllers/pods under the deployment show the correct certificate info in the metrics that they produce.

NGINX Ingress controller version (exec into the pod and run /nginx-ingress-controller --version):

NGINX Ingress controller
Release: v1.11.3
Build: 0106de6
Repository: https://github.com/kubernetes/ingress-nginx
nginx version: nginx/1.25.5

Kubernetes version (use kubectl version):
Server Version: v1.31.4-eks-2d5f260

Environment:
Production

  • Cloud provider or hardware configuration: AWS / EKS

How to reproduce this issue:
Not exactly sure how to reproduce this behaviour. Restarting the controllers fix the problem temporarily but the problem creeps up after sometime.

@Melvin-Antony Melvin-Antony added the kind/bug Categorizes issue or PR as related to a bug. label Jan 9, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jan 9, 2025
@k8s-ci-robot
Copy link
Contributor

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.

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-sigs/prow repository.

@longwuyuan
Copy link
Contributor

Since not all instances of the controller report the wrong info, there is not enough info here to call it a bug.

Please edit the issue description, and copy/paste all possible small tiny details, that a reader will require to reproduce the problem at will on a kind cluster.

/remove-kind bug

@k8s-ci-robot k8s-ci-robot added needs-kind Indicates a PR lacks a `kind/foo` label and requires one. and removed kind/bug Categorizes issue or PR as related to a bug. labels Jan 12, 2025
@RLutsch
Copy link

RLutsch commented Jan 14, 2025

I've got the same issue only one controller pod running and after update it serves self signed certs from my local but the correct certs when I ssh into the node running and run the same lookup.

helm chart version: "4.12.0"

@RLutsch
Copy link

RLutsch commented Jan 14, 2025

found the issue, the svc loadbalancer pod in kube-system didn't run, got it scheduled and problem solved

@elitistphoenix
Copy link

Anyone else seeing this issue this helped me fix the default ingress cert being shown instead:
#12655 (comment)

@longwuyuan
Copy link
Contributor

Since there is no action item for the project on this issue being tracked, I will close the issue for now. Feel free to reopen after editing the issue descrption with enough reason for the project to allocate resources.

thanks

/close

@k8s-ci-robot
Copy link
Contributor

@longwuyuan: Closing this issue.

In response to this:

Since there is no action item for the project on this issue being tracked, I will close the issue for now. Feel free to reopen after editing the issue descrption with enough reason for the project to allocate resources.

thanks

/close

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-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
Development

No branches or pull requests

5 participants