Mainflux在Kubernetes结合ingress-nginx部署后访问域名出现404错误的技术求助

Let's walk through the key issues from your setup and tackle them one by one:

1. Fix IngressClass Mismatch (Critical Initial Issue) #

Your logs mention that Ingress resources in the mf namespace were initially ignored due to an invalid IngressClass. This means your ingress-nginx controller wasn't recognizing or processing those Ingress rules at all.

• Check your Mainflux Ingress configuration:
  Run this command to inspect the Ingress resource in mf namespace:

  kubectl describe ingress mainflux-nginx-ingress -n mf
  

  Look for the Ingress Class field. It should match the IngressClass used by your ingress-nginx controller (default is nginx).

• Resolve the mismatch:

  • If the IngressClass is missing or incorrect, edit the Ingress resource:

    kubectl edit ingress mainflux-nginx-ingress -n mf
    

    Add or update the spec.ingressClassName field to:

    spec:
      ingressClassName: nginx
    

  • Alternatively, re-deploy Mainflux with the correct Helm parameter to set this automatically:

    helm upgrade mainflux mainflux/mainflux -n mf --set ingress.ingressClassName=nginx
    

2. Check for Ingress Rule Conflicts & Port Mismatches #

You have two separate Ingress resources pointing to mainflux-ui:

• One in mf namespace routing example.com to port 3000

• Another in ingress-nginx namespace routing aqueglobal.dockerfix.ga to port 80

• Verify mainflux-ui service ports:
  Confirm which port the mainflux-ui service exposes:

  kubectl get svc mainflux-ui -n mf
  

  The TARGETPORT should match the port your UI container uses (typically 3000 for Mainflux UI). If the second Ingress uses port 80, it's forwarding to a non-existent port on the service, which would cause errors.

• Clean up conflicting rules:
  If you don't need the aqueglobal.dockerfix.ga routing, delete that Ingress resource to avoid confusion:

  kubectl delete ingress nginx-ingress-ingress-nginx-controller -n ingress-nginx
  

3. Resolve SSL Certificate & Handshake Errors #

Your logs show missing SSL certificates (falling back to default) and SSL handshake failures. This can cause 400 or 404 errors when accessing via HTTPS.

• Check Ingress TLS configuration:
  Inspect the TLS section of your Mainflux Ingress:

  kubectl get ingress mainflux-nginx-ingress -n mf -o yaml
  

  If you intended to use SSL for example.com, ensure you have:

  • A valid TLS secret in the mf namespace containing your certificate and key
  • The tls block in the Ingress references the correct secret name:

    tls:
    - hosts:
      - example.com
      secretName: your-example-com-tls-secret
    

  If you don't need SSL yet, remove the tls block from the Ingress to allow HTTP access.

• Test HTTP vs HTTPS:
  If you're accessing http://example.com but the Ingress expects HTTPS, you'll get a 400 error. Try accessing via https://example.com (note: you'll get a warning with the default certificate) or adjust the Ingress to allow HTTP.

4. Address etcd Request Timeouts #

Etcd timeouts can break Mainflux backend services (like mainflux-things), which might indirectly affect UI accessibility or API endpoints like /version.

• Check etcd pod health:
  Verify if etcd is running properly:

  kubectl get pods -n mf | grep etcd
  

  If the pod is crashing or in a pending state, check its logs for issues:

  kubectl logs <etcd-pod-name> -n mf
  

• Resource allocation:
  Etcd requires sufficient memory and CPU. Check if the pod has enough resources allocated (you can adjust this via Helm values if needed).

5. Validate Internal Service Access #

To rule out issues with the mainflux-ui service itself, test access from within the cluster:

kubectl run -it --rm curl-test --image=curlimages/curl -- curl mainflux-ui.mf.svc.cluster.local:3000

If this returns the UI HTML content, the service is working, and the problem is definitely in the Ingress layer. If not, check the mainflux-ui pod logs for startup errors:

kubectl logs <mainflux-ui-pod-name> -n mf

内容的提问来源于stack exchange，提问作者Sami Hassan