search

kubernetes / ingress-nginx

Ingress-NGINX Controller for Kubernetes
https://kubernetes.github.io/ingress-nginx/
Apache License 2.0
17.23k stars 8.2k forks source link

Support grpc and http requests through one domain name #10818

Open snail2sky opened 8 months ago

snail2sky commented 8 months ago

It is expected that the listen configuration can be added to the annotation, and do not merge configurations with different ports but the same server_name. I hope to add these parameter annotations:

  1. nginx.ingress.kubernetes.io/listen-address: string
  2. nginx.ingress.kubernetes.io/listen-port: number
  3. nginx.ingress.kubernetes.io/listen-protocol: string [http2 | quic]
  4. ... 
    
# for example
upstream http_upstream {
server 192.168.0.1:80;
server 192.168.1.1:80;
}

upstream grpc_upstream { server 192.168.0.1:10080; server 192.168.1.1:10080; }

server { listen 80; server_name api.test.com; location /api { proxy_set_header Host $host; proxy_pass http://http_upstream; } }

server { listen 10080 http2; server_name api.test.com; location /api { grpc_set_header Host $host; grpc_pass grpc://grpc_upstream; } }

but the nginx ingress will be generate the following configuration

There is no way for me to use a domain name to proxy http1.1 and http2.0 traffic,

but nginx itself supports this function.

upstream http_upstream { server 192.168.0.1:80; server 192.168.1.1:80; }

upstream grpc_upstream { server 192.168.0.1:10080; server 192.168.1.1:10080; } server { listen 80; listen 443 ssl http2; server_name api.test.com;

# server snipet start
listen 10080 http2;
# server snipet end

location / {
    # may be http_pass , but only one location configuration may take effect~~
    grpc_set_header Host $host;
    grpc_pass grpc://grpc_upstream;
}

}



Is there currently another issue associated with this?
And you cannot arbitrarily specify nginx ingress to listen to any port unless you use the server configuration segment, but ports 80 and 443 will definitely appear in the server configuration segment, even if we don't need it.

Does it require a particular kubernetes version?
No

If this is actually about documentation, uncomment the following block
No
k8s-ci-robot commented 8 months ago

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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
strongjz commented 8 months ago

looks like it is supported?

https://github.com/kubernetes/ingress-nginx/issues/6269#issuecomment-702927790

strongjz commented 8 months ago

/triage needs-information

snail2sky commented 8 months ago

looks like it is supported?

#6269 (comment)

Maybe it’s not supported I have two services, http service A and GRPC service B. Both services will be called through the domain name api.test.com However, according to the generation rules of the ingress nginx configuration file, both services will be generated in the same nginx server configuration section. If the uri of the http service and the grpc service are the same, the later configured ingress rules will not take effect. https://kubernetes.github.io/ingress-nginx/how-it-works/#building-the-nginx-model image

# for example
kubectl create ingress test-grpc --rule=api.test.com/api=grpc-svc:80
kubectl create ingress test-http --rule=api.test.com/api=http-svc:80

# The above code will definitely not work
# Therefore, I hope to solve this problem by changing the port

server { listen 10080 http2; server_name api.test.com;

location /api {
    grpc_pass ??;
}

}

strongjz commented 8 months ago

On the same path no, ingress needs to know where to send traffic. It does this with a combination of host and path. This is in the Ingress API, which we have to conform too. So you'll need to add a different GRPC endpoint on the host or a different path.

gpcr.test.com and api.test.com or api.test.com/api and api.test.com/grpc.

https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-rules

longwuyuan commented 8 months ago

I think one factor could be that the same socket will have to multiplex for different protocols or something like that. I could be wrong but a similar issue exists, AFAIK. I don't know the other issue number.

On Mon, 8 Jan, 2024, 6:02 pm snail, @.***> wrote:

looks like it is supported?

6269 (comment)

https://github.com/kubernetes/ingress-nginx/issues/6269#issuecomment-702927790

Maybe it’s not supported I have two services, http service A and GRPC service B. Both services will be called through the domain name api.test.com However, according to the generation rules of the ingress nginx configuration file, both services will be generated in the same nginx server configuration section. If the uri of the http service and the grpc service are the same, the later configured ingress rules will not take effect.

https://kubernetes.github.io/ingress-nginx/how-it-works/#building-the-nginx-model image.png (view on web) https://github.com/kubernetes/ingress-nginx/assets/49757958/c4e97f7a-5e33-40ac-a4aa-004d49756dbe

for example

kubectl create ingress test-grpc --rule=api.test.com/api=grpc-svc:80 kubectl create ingress test-http --rule=api.test.com/api=http-svc:80

The above code will definitely not work# Therefore, I hope to solve this problem by changing the port

  • But the final generated nginx.conf is like this

server { listen 80; listen 443 ssl; server_name api.test.com;

start server snipet

listen 10080 http2;
# end server snipet

location /api {
    proxy_pass ??
}

}

  • The nginx.conf I expect is like this

server { listen 80; listen 443 ssl; server_name api.test.com;

location /api {
    proxy_pass ??;
}

} server { listen 10080 http2; server_name api.test.com;

location /api {
    grpc_pass ??;
}

}

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/10818#issuecomment-1880920637, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZVWUTMTYXHMXROUTQNRLYNPRN7AVCNFSM6AAAAABBKJLHAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQHEZDANRTG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

snail2sky commented 8 months ago

On the same path no, ingress needs to know where to send traffic. It does this with a combination of host and path. This is in the Ingress API, which we have to conform too. So you'll need to add a different GRPC endpoint on the host or a different path.

gpcr.test.com and api.test.com or api.test.com/api and api.test.com/grpc.

https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-rules

Yes, k8s official said that if server_name and path are the same, only one Ingress will take effect, but ingress does not say that if the ports are different, they must be generated in an nginx server configuration section, and the current configuration section generated by nginx ingress is relatively Fixed, as long as it is an Ingress rule, it will definitely listen 80 and listen 443; this is a bit bad, the user cannot customize the port at all, even if it is a universal port in the future, it will be difficult to do so It would be great if it could be configured like this

# this command will be generate
kubectl create ingress test-ingress1 --rule=api.test.com:80/api-uri=api-svc:8080

server {
    listen 80;
    server_name api.test.com;
    locaiton /api-uri {
        proxy_pass ???;
    }
}
# And this command will be generate 
kubectl create ingress test-ingress2 --rule=api.test.com:10080/api-uri=api-svc:9090
server {
    listen 10080;
    server_name api.test.com;
    locaiton /api-uri {
        proxy_pass ???;
    }
}
strongjz commented 7 months ago

/assign @tao12345666333

github-actions[bot] commented 6 months ago

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.