为 Istio Mesh 中 pod 的传出请求重写主机和端口
Rewrite host and port for outgoing request of a pod in an Istio Mesh
我必须获取现有的微服务 运行。它们以 docker 图像的形式给出。
他们通过配置的主机名和端口相互交谈。
我开始使用 Istio 来查看和配置每个微服务的呼出。
现在我需要重写/重定向主机和从一个容器发出的请求的端口。
我如何使用 Istio 做到这一点?
我会尽量举一个最简单的例子。
有两个服务,service-a和service-b。
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-b
spec:
selector:
matchLabels:
run: service-b
replicas: 1
template:
metadata:
labels:
run: service-b
spec:
containers:
- name: service-b
image: nginx
ports:
- containerPort: 80
name: web
---
apiVersion: v1
kind: Service
metadata:
name: service-b
labels:
run: service-b
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 80
name: service-b
selector:
run: service-b
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-a
spec:
selector:
matchLabels:
run: service-a
replicas: 1
template:
metadata:
labels:
run: service-a
spec:
containers:
- name: service-a
image: nginx
ports:
- containerPort: 80
name: web
---
apiVersion: v1
kind: Service
metadata:
name: service-a
labels:
run: service-a
spec:
ports:
- port: 8081
protocol: TCP
targetPort: 80
name: service-a
selector:
run: service-a
我可以docker执行到service-a并成功执行:
root@service-a-d44f55d8c-8cp8m:/# curl -v service-b:8080
< HTTP/1.1 200 OK
< server: envoy
现在,为了模拟我的问题,我想使用另一个主机名和端口访问服务 b。我想按照此调用的方式配置 Istio:
root@service-a-d44f55d8c-8cp8m:/# curl -v service-x:7777
此致,
克里斯蒂安
根据使用 istio
功能的必要性,可以使用两种解决方案。
如果没有istio
特性打算使用,可以使用原生kubernetes解决。反过来,如果打算使用某些istio
特性,则可以使用istio virtual service
来解决。以下是两个选项:
1.原生 kubernetes
Service-x
应该指向 service-b
部署的后端。下面是 selector
指向 deployment: service-b
:
apiVersion: v1
kind: Service
metadata:
name: service-x
labels:
run: service-x
spec:
ports:
- port: 7777
protocol: TCP
targetPort: 80
name: service-x
selector:
run: service-b
无论如何请求都会通过 istio
,因为注入了 sidecar 容器。
# curl -vI service-b:8080
* Trying xx.xx.xx.xx:8080...
* Connected to service-b (xx.xx.xx.xx) port 8080 (#0)
> Host: service-b:8080
< HTTP/1.1 200 OK
< server: envoy
和
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy
2。 Istio 虚拟服务
在此示例中使用 virtual service。服务 service-x
仍然需要创建,但现在我们不指定任何选择器:
apiVersion: v1
kind: Service
metadata:
name: service-x
labels:
run: service-x
spec:
ports:
- port: 7777
protocol: TCP
targetPort: 80
name: service-x
从另一个 pod 测试它:
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 503 Service Unavailable
< server: envoy
503
预期的错误。现在创建 virtual service
,它将在 port: 8080
:
上将请求路由到 service-b
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: service-x-to-b
spec:
hosts:
- service-x
http:
- route:
- destination:
host: service-b
port:
number: 8080
从 pod 测试:
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy
看到它按预期工作。
有用的链接:
我必须获取现有的微服务 运行。它们以 docker 图像的形式给出。 他们通过配置的主机名和端口相互交谈。 我开始使用 Istio 来查看和配置每个微服务的呼出。 现在我需要重写/重定向主机和从一个容器发出的请求的端口。 我如何使用 Istio 做到这一点?
我会尽量举一个最简单的例子。 有两个服务,service-a和service-b。
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-b
spec:
selector:
matchLabels:
run: service-b
replicas: 1
template:
metadata:
labels:
run: service-b
spec:
containers:
- name: service-b
image: nginx
ports:
- containerPort: 80
name: web
---
apiVersion: v1
kind: Service
metadata:
name: service-b
labels:
run: service-b
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 80
name: service-b
selector:
run: service-b
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: service-a
spec:
selector:
matchLabels:
run: service-a
replicas: 1
template:
metadata:
labels:
run: service-a
spec:
containers:
- name: service-a
image: nginx
ports:
- containerPort: 80
name: web
---
apiVersion: v1
kind: Service
metadata:
name: service-a
labels:
run: service-a
spec:
ports:
- port: 8081
protocol: TCP
targetPort: 80
name: service-a
selector:
run: service-a
我可以docker执行到service-a并成功执行:
root@service-a-d44f55d8c-8cp8m:/# curl -v service-b:8080
< HTTP/1.1 200 OK
< server: envoy
现在,为了模拟我的问题,我想使用另一个主机名和端口访问服务 b。我想按照此调用的方式配置 Istio:
root@service-a-d44f55d8c-8cp8m:/# curl -v service-x:7777
此致, 克里斯蒂安
根据使用 istio
功能的必要性,可以使用两种解决方案。
如果没有istio
特性打算使用,可以使用原生kubernetes解决。反过来,如果打算使用某些istio
特性,则可以使用istio virtual service
来解决。以下是两个选项:
1.原生 kubernetes
Service-x
应该指向 service-b
部署的后端。下面是 selector
指向 deployment: service-b
:
apiVersion: v1
kind: Service
metadata:
name: service-x
labels:
run: service-x
spec:
ports:
- port: 7777
protocol: TCP
targetPort: 80
name: service-x
selector:
run: service-b
无论如何请求都会通过 istio
,因为注入了 sidecar 容器。
# curl -vI service-b:8080
* Trying xx.xx.xx.xx:8080...
* Connected to service-b (xx.xx.xx.xx) port 8080 (#0)
> Host: service-b:8080
< HTTP/1.1 200 OK
< server: envoy
和
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy
2。 Istio 虚拟服务
在此示例中使用 virtual service。服务 service-x
仍然需要创建,但现在我们不指定任何选择器:
apiVersion: v1
kind: Service
metadata:
name: service-x
labels:
run: service-x
spec:
ports:
- port: 7777
protocol: TCP
targetPort: 80
name: service-x
从另一个 pod 测试它:
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 503 Service Unavailable
< server: envoy
503
预期的错误。现在创建 virtual service
,它将在 port: 8080
:
service-b
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: service-x-to-b
spec:
hosts:
- service-x
http:
- route:
- destination:
host: service-b
port:
number: 8080
从 pod 测试:
# curl -vI service-x:7777
* Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy
看到它按预期工作。
有用的链接: