Istio网关端口的奇怪行为
我很难理解Istio网关端口到底是如何使用的。我指的是下面例子中的第14行
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 8169
name: http-test1
protocol: HTTP
hosts:
- '*'
从Istio文档中：
代理应在其上侦听传入连接的端口。因此，如果您应用上面的yaml文件并检查istio-ingress网关pod以监听TCP端口，您会发现实际上使用了端口8169（见下面的输出）
kubectl -n=istio-system exec istio-ingressgateway-8577c57fb6-p8zl5 -- ss -nl | grep 8169
tcp LISTEN 0 4096 0.0.0.0:8169 0.0.0.0:*
但棘手的部分来了。如果在应用Gateway之前更改istio-ingress网关服务如下：
apiVersion: v1
kind: Service
metadata:
name: istio-ingressgateway
...
- name: http5
nodePort: 31169
port: 8169
protocol: TCP
targetPort: 8069
...
然后应用网关，实际使用的端口不是8169，而是8069。网关资源似乎会首先在istio ingressgateway服务中检查匹配的端口，然后使用该服务的targetPort
kubectl -n=istio-system exec istio-ingressgateway-8577c57fb6-p8zl5 -- ss -nl | grep 8169
<empty result>
kubectl -n=istio-system exec istio-ingressgateway-8577c57fb6-p8zl5 -- ss -nl | grep 8069
tcp LISTEN 0 4096 0.0.0.0:8069 0.0.0.0:*
有人能解释为什么吗？提前感谢您的任何帮助
共有2个答案
据我所知，网关是虚拟的，您可以定义多个网关并公开不同的端口。但是，这些端口仍然需要在istio入口网关上打开
因此，当您在实际的ingressgateway上手动更改端口配置时，应用该端口后，只有该特定端口打开是有意义的。您正在检查入口网关上的开放端口，而不是虚拟网关上的开放端口。
此外，我认为不鼓励直接编辑istio-ingress网关服务。如果您想自定义ingress网关，您可以定义一个Istiooperator并在安装Istio时应用它。
您遇到了Istio的一个有趣的方面——如何配置Istio以使用Istio网关公开服务网格之外的服务。
首先，请注意，网关配置将应用于Pod上运行的代理（在您的示例中，Pod上的标签为istio:ingressgateway）。Istio负责将代理配置为在这些端口上侦听，但用户有责任确保这些端口的外部通信被允许进入mesh。
让我举个例子给你看。您遇到的是预期行为，因为这正是Istio的工作方式。
首先，我创建了一个简单的网关配置（为了简单起见，我省略了虚拟服务和目标规则配置），如下所示：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 9091
name: http-test-1
protocol: HTTP
hosts:
- '*'
然后：
$ kubectl apply -f gw.yaml
gateway.networking.istio.io/gateway created
让我们检查代理是否正在侦听端口9091。我们可以直接从istio ingresgateway-*pod中检查它，或者使用istioctl proxy config listener命令检索指定pod中特使实例的侦听器配置信息：
$ kubectl exec istio-ingressgateway-8c48d875-lzsng -n istio-system -- ss -tulpn | grep 9091
tcp LISTEN 0 1024 0.0.0.0:9091 0.0.0.0:* users:(("envoy",pid=14,fd=35))
$ istioctl proxy-config listener istio-ingressgateway-8c48d875-lzsng -n istio-system
ADDRESS PORT MATCH DESTINATION
0.0.0.0 9091 ALL Route: http.9091
将此端口暴露在pod上并不意味着我们可以从外部世界访问它，但可以从另一个pod内部访问此端口：
$ kubectl get pod -n istio-system -o wide
NAME READY STATUS RESTARTS AGE IP
istio-ingressgateway-8c48d875-lzsng 1/1 Running 0 43m 10.4.0.4
$ kubectl exec -it test -- curl 10.4.0.4:9091
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
为了使其可从外部访问，我们需要在istio ingressgateway服务上公开此端口：
...
ports:
- name: http-test-1
nodePort: 30017
port: 9091
protocol: TCP
targetPort: 9091
...
修改后，我们可以从外部世界到达端口9091：
$ curl http://<PUBLIC_IP>:9091
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
请注意，从Pod的角度来看，一切都没有改变：
$ kubectl exec istio-ingressgateway-8c48d875-lzsng -n istio-system -- ss -tulpn | grep 9091
tcp LISTEN 0 1024 0.0.0.0:9091 0.0.0.0:* users:(("envoy",pid=14,fd=35))
$ istioctl proxy-config listener istio-ingressgateway-8c48d875-lzsng -n istio-system
ADDRESS PORT MATCH DESTINATION
0.0.0.0 9091 ALL Route: http.9091
现在，让我们将istio-ingress网关服务配置中的Target etPort： 9091更改为Target etPort： 9092，看看会发生什么：
...
ports:
- name: http-test-1
nodePort: 30017
port: 9091
protocol: TCP
targetPort: 9092 <--- "9091" to "9092"
...
$ kubectl exec istio-ingressgateway-8c48d875-lzsng -n istio-system -- ss -tulpn | grep 9091
tcp LISTEN 0 1024 0.0.0.0:9091 0.0.0.0:* users:(("envoy",pid=14,fd=35))
$ istioctl proxy-config listener istio-ingressgateway-8c48d875-lzsng -n istio-system
ADDRESS PORT MATCH DESTINATION
0.0.0.0 9091 ALL Route: http.9091
正如您所见，从Pod的角度来看，目前似乎没有任何变化，但我们还需要重新应用网关配置：
$ kubectl delete -f gw.yaml && kubectl apply -f gw.yaml
gateway.networking.istio.io "gateway" deleted
gateway.networking.istio.io/gateway created
$ kubectl exec istio-ingressgateway-8c48d875-lzsng -n istio-system -- ss -tulpn | grep 9092
tcp LISTEN 0 1024 0.0.0.0:9092 0.0.0.0:* users:(("envoy",pid=14,fd=35))
$ istioctl proxy-config listener istio-ingressgateway-8c48d875-lzsng -n istio-system
ADDRESS PORT MATCH DESTINATION
0.0.0.0 9092 ALL Route: http.9092
我们的代理现在正在监听端口9092（Target etPort），但是我们仍然可以从outisde到达端口9091，只要我们的网关指定这个端口，并且它在istio-ingress网关上打开。服务。
$ kubectl describe gw gateway -n istio-system | grep -A 4 "Port"
Port:
Name: http-test-1
Number: 9091
Protocol: HTTP
$ kubectl get svc -n istio-system -oyaml | grep -C 2 9091
- name: http-test-1
nodePort: 30017
port: 9091
protocol: TCP
targetPort: 9092
$ curl http://<PUBLIC_IP>:9091
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
-
我有一个在kubernetes pod中运行的应用程序（在我的本地docker桌面上，启用kubernetes），监听端口8080。然后我有以下kubernetes配置 这个很好用。但我想把443端口改成其他端口，比如8443（因为我将有多个网关）。当我有这个，我不能再访问应用程序了。是否有一些配置我遗漏了？我猜我需要配置Istio来接受8443端口？我使用以下命令安装了istio： 编辑：我读了
-
这在我看来是一个罕见的问题，所以我不确定我会得到一个答案。我张贴的程序重现这个错误，希望你能帮助我。 您有没有尝试过在Jcef（Java-铬嵌入式框架）示例应用程序（简单或详细）中通过做获得的浏览器实例中执行打开新窗口并注意到奇怪的行为？每当在主窗口之外创建一个新窗口时，单击新窗口不会将其置于前面（或焦点）。主窗口（包含浏览器的UIComponent的JFrame）立即窃取焦点并将另一个窗口发回。
-
问题内容： 我有以下简单代码： 正如我的python知识所期望的那样，输出为3-整个列表将包含的最后一个值。但是，这在内部如何运作？ AFAIK，python变量只是对对象的引用，因此第一个闭包必须包含对象的第一个引用-并且此对象肯定是1，而不是3 O_O。python闭包如何将变量本身而不是对象作为变量引用的对象？它是否将变量名另存为纯文本，一些“对变量的引用”或什么？ 问题答案： 闭包不是指
-
这起作用了 这不是
-
我有以下代码来解析一个JSON文件: 要处理以下JSON文件： 如果我执行此代码，我将收到以下错误： 所以我开始一步一步地调试应用程序，看看part processing()中的哪个代码部分抛出了这个异常。令人惊讶的是，那里的所有代码都正常执行:没有抛出异常，也没有返回结果I except。 更让我惊讶的是，当我稍微改变第一种方法的代码时，它可以在不产生异常的情况下工作。 我不知道println方
-
我正在尝试在本地使用wsl2和docker desk运行bookinfo示例。由于连接被拒绝，我试图通过网关访问productpage服务时遇到问题。我不确定我是否错过了什么。以下是我在网上搜索了很多次后所做的事情 部署了bookinfo示例中的所有服务，并且所有服务都处于运行状态，我可以使用kubectl exec从其他服务中创建productpage 使用示例中的文件部署bookinfo网关，