Nginx Question posted in
The official documentation can be found here.

kubernetes ingress service doesn't fwd in http or https – Nginx

I’m using on W10 dockerHub 20.10.2 and the embedded kubernetes cluster.
I have installed the ingress-nginx controller, without any additional configuration.
Then created an ingress service in my namespace following the below yaml. The port is 443 in ingress, but also in the service, deployment, as the docker image is listening to 443.

[EDIT] see below issue is also in HTTP listening to port 4000

budget-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: budget-ingress
  labels:
    app: budget
  namespace: budget-namespace
spec:
  rules:
    - host: "dwpbudget.com"
      http:
        paths:
          - path: "/"
            pathType: Prefix
            backend:
              service:
                name: budget-service
                
                port:
                  number: 443

However, as shown in the image below, the port remains 80, whereas it should be 443.
port mismatch

the result is of course a 502 error when I’m visiting my page

the describe gives the following
describe of the service

Note that when forwarding the 443 port using kubectl port-forward budget-deployment-59cdb8898d-2zhr4 443:443 -n budget-namespace, everything is fine.

What am I missing here ?

here is the service yaml file

budget-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: budget-service
  namespace: budget-namespace
  labels:
    app: budget
spec:
  selector:
    app: budget
  ports:
    - protocol: TCP
      port: 443
      targetPort: 443
Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    update of logs when switching to HTTP, listening to port 4000, same issue, on browser http://dwpbudget.com:4000 or http://dwpbudget.com:80 failed. Or course forwarding the port to the containers makes things ok

    logs inside the container logs inside the container

    ingress describe describe of ingress

    enter image description here


  2. 0

    There are some concepts in this question and the answer provided by original poster that I think should be addressed:

    • Nginx-ingress installation on Docker Desktop:

    By default Docker Desktop spawned Kubernetes cluster does not come with out of the box Ingress controller. It needs to be deployed via various measures. One is located here:

    A link used here:

    I’m using on W10 dockerHub 20.10.2 and the embedded kubernetes cluster.
    I have installed the ingress-nginx controller, without any additional configuration.

    Is a link to install a kubectl plugin to have certain features built-in into kubectl related to nginx-ingress. This is not a link to deploy Ingress nginx controller which is necessary to support setup like in question.

    A side note!

    Example of a "feature" this kubectl plugin provides:

    • $ kubectl ingress-nginx ingresses
    INGRESS NAME    HOST+PATH   ADDRESSES   TLS   SERVICE   SERVICE PORT   ENDPOINTS
nginx-ingress   /                       NO    nginx     80             1

    I’ve already explained how the communication between your client, nginx-ingress controller and your Pod behaves here. I encourage everyone to check it:

    By default NGINX Ingress controller comes with self signed certificate:

    • Kubernetes Ingress Controller Fake Certificate

    You can connect to your Ingress controller with HTTPS (when it’s not specified in Ingress definition) but this certificate will not be valid and won’t be included in the Ingress manifest.

    To have the connection between client and Ingress controller with your own certificate you will need to have (in your Ingress resource manifest) following section:

      tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls

    If your Pod is expecting HTTPS traffic you’ll need to configure your Ingress manifest to send the HTTPS requests to your backend with following annotation (by default it’s: HTTP):

    • nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

    A side note!

    As an alternative you can use SSL Passthrough

    Additional resources:

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search