-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Istio 0.8.0 VirtualService missmatch hosts when port is added #6469
Comments
cc @andraxylia |
i met the same problem ,but i canot make it work by add host "host:port" in virtualservice hosts section, when create virtual service, err message is
Environment |
@wansuiye please give the full virtualService Manifest. |
@prune998
when create it,the err msg is:
env: |
It's working with |
Hi everyone, I was also hit by this bug when following the httpbin tutorial... I ended up with this config that works for me (Also, I don't have a loadbalancer, so I'm accessing the ingress-gateway on the NodePort) apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: httpbin
spec:
replicas: 1
template:
metadata:
labels:
app: httpbin
version: v1
spec:
containers:
- image: docker.io/citizenstig/httpbin
imagePullPolicy: IfNotPresent
name: httpbin
ports:
- containerPort: 8000
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: httpbin-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "httpbin.example.no"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
gateways:
- httpbin-gateway
hosts:
- "httpbin.example.no"
- "httpbin.example.no:31380"
http:
- route:
- destination:
port:
number: 8000
host: httpbin
---
apiVersion: v1
kind: Service
metadata:
labels:
app: httpbin
name: httpbin
spec:
selector:
app: httpbin
ports:
- name: http
port: 8000
protocol: TCP
targetPort: 8000
type: NodePort Without the extra hosts I would receive this error in
(notice the requested hostname Edit: |
@andraxylia (as you were named for this bug), I'm just testing the latest release, using images What I see now is the exact same behaviour as the one described first in this issue.
BUT I can't add a host that contains a port number anymore ( So this does not work anymore :
The error is now :
So :
The conclusion is you can't use the |
I tried removing the We really need to investigate this issue |
I stumpled upon the same issue when playing around with Istio on my local machine. I am using minikube, so I access my ingress gateway via the node port With this local setup, any client that doesn't support specifying the host header (e.g. a web browser without extensions like Chrome Header Hacker) can not be used to access services in my service mesh. I am currently using the workaround mentioned by @prune998 which allows me to set an additional port in my gateway/virtualservice hosts configuration by using kubectl instead of istioctl. A fix would be much appreciated. |
@denniseffing can you please provide your K8s and Istio versions ? |
@prune998 I am currently using Istio 0.8.0 and K8s 1.10 I didn't try any snapshot version because of your comment that the latest snapshot release uses a new admission hook that also disables the currently used workaround with kubectl. Do you want me to try a current snapshot version regardless? |
ok thanks @denniseffing so there's nothing I can do more to help... waiting for Itio Team (@sakshigoel12 or @andraxylia ) to take over :) |
in istio 1.10, kubectl is also not work to set the host with a port... |
@ronakpandya7 Nothing you can do except waiting for the Istio team to respond to this issue. |
Hello @denniseffing , So how can we force them to make them look at this issue? |
Current milestone is v1.1, so I'd expect a fix in about a month if they keep up the monthly release schedule. |
Hello @denniseffing, Thanks for your help, we have to wait. |
@ronakpandya7 I replied to your other issue, which from my point of view is not an issue but a missconfiguration. |
I think I got it working with the 1.0.0 release, with a little twist... I added the gateway as :
and the
I'm still not 100% sure it's OK as my gRPC connexion keeps closing... but I have to ensure it's not my code... |
Ok, sounds everything is working AS LONG AS you don't deploy I'll try adding the ports in the |
I can confirm the |
Hello @prune998 , |
Hello @prune998 , I am worried that we removed one component from the istio mesh that is |
it seems that in istio 1.1 the problem is also existed. it can only be solved by disable galley, but the galley is more important such as mcp |
i met the same problem from istio 0.7, i used a 30080 nodeport which is mapped to 80 in istio-ingressgateway. the only solved way is to close galley, which i tested for every version of istio. |
Istio developer think this behavior is right, gateway is only support dns format host, so I think put a proxy at the front of the ingressgateway in you cluster can solve this problem. This also can help you make you ingressgateway more ha. You can use keeplive + lvs/haproxy/nginx/envoy and so on. |
however the http protocol's host header include port, and adding a gateway in front of ingressgateway just to convert header's host is much complicated. and the proxy need support multi protocols |
Your front proxy only need support TCP protocol, you can proxy port 80 and 443 to the ingressgateway port 30080 or other port. If your client call http service by proxy and not carry the port number in the host header this will work fine. |
@mgxian it's feasible. |
@wansuiye suppose you ingressgateway opened at nodeport 30080, there are two ways to deploy your proxy:
|
@wansuiye @mgxian This is actually how we got around the issue. We have a daemon set proxy deployment, that its only job is to accept port 80 and 443 traffic and pass it to the ingress gateway at the specific node port. While it would be nice to not have to deploy that extra piece, i guess its just how it has to be done for on-prem deployments. Its an interesting thing that the gateway/proxies only support DNS format. Have you ever tried to use Prometheus-operator in a istio deployment? We had to create specific regex changes so that Prometheus would scrap using DNS instead of IP, because istio could not route IP. But i think this is more of a issue with Prometheus then istio. |
Hi there. |
@prune998 Can you confirm that you are able to create a VirtualService with hosts that include a port when using Istio 1.1? I am asking because wansuiye said that this is still not possible and mgxian said that this is indeed intended by the Istio team and therefore won't be fixed. |
it's not possible, but it's not needed. |
Thanks for clearing that up! I guess that works fine too. |
@prune998 Is other port except port 80 and 443 supported ? If I create a virtualservice with hosts |
@mgxian your question is more "can I access the gateway using a nodeport". I would say yes, it should work, but I never tried it, so you've better check by yourself. As long as the |
I have confirmed that this is still an issue with non-standard ports(8443) on both 1.0.7 and 1.1.5. It's very easy for me to replicate with the following: (In this example, we'll just terminate SSL at the ELB) apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
namespace: foo
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http-80
protocol: HTTP
hosts:
- api.xxxx.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-virtual-service
namespace: foo
spec:
hosts:
- api.xxxx.com
gateways:
- gateway
http:
- route:
- destination:
host: my-service.foo.svc.cluster.local
subset: release
Next, change the "hosts" to "*" on the VirtualService: apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-virtual-service
namespace: foo
spec:
hosts:
- "*"
gateways:
- gateway
http:
- route:
- destination:
host: my-service.foo.svc.cluster.local
subset: release
|
@blaketastic2 I'm not sure I clearly understand your setup. |
As I mentioned, for this example, we're doing TLS termination on the ELB, so 8443 and 443 map to 80. |
Here's the config from the helm chart: gateways:
istio-ingressgateway:
enabled: true
ports:
- port: 80
name: http
targetPort: 80
- port: 443
name: https
targetPort: 80
- port: 8443
name: https-app
targetPort: 80 |
I am experiencing the same with envy-1.10.0 If I use the following
Then in my helloworld pod
But I cannot access the resource If i use the following
then no entry is generated in the pods config. I am using CloudFlare to proxy requests to my a development instance only accessible via port |
If I create an entry with
and entry via
and use
Still does not work if i use It is a workaround to my configuration use case. i,e port forward |
Describe the bug
When using the IngressGateway and defining a VirtualService, the
hosts
list makes difference between<host>
and<host>:<port>
Expected behavior
By RFC, the
Host:
header of HTTP can be the plain<host>
or<host>:<port>
. The VirtualService should consider the two as beeing the same.Steps to reproduce the bug
I started with the howto at https://istio.io/docs/tasks/traffic-management/ingress/
my domain name is
authd.test.run1.k8s.xx.ca
I defined a Gateway :
And a VirtualService :
Than try with curl :
while :
In the 2nd case, I see in the logs :
To make it work I had to change the
VirtualService
to :Either there is another way to match the hosts (like using
*
) or the documentation should warn about that.Note that Go http/gRPC seem to always send the port along the hostname.
Version
k8s 1.10.2
Istio 0.8.0
Is Istio Auth enabled or not?
No mTLS active
Environment
GKE
The text was updated successfully, but these errors were encountered: