本文介绍了如何使用Istio创建内部网关?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当前,我们已成功设置Istio来创建几个入口网关,例如api.example.com和app.example.com,这些网关将流量路由到具有目标规则等的各种服务.除此以外,我们还将我喜欢将Istio的功能用于仅供内部使用的API,但是我们不确定如何设置类似的设置.是否可以使用Istio的网关和VirtualServices CRD在不退出群集的情况下路由流量?如果是这样,我们将如何进行设置?

解决方案

我会在Arghya Sadhu答案中添加一些内容.

我认为我在另一个帖子中的示例是您问题的答案,特别是虚拟服务网关和主机.此示例需要附加的目标规则",因为我们有一些子集,这些子集在此处标记了到nginx正确子集的路由,并且它们是在目标规则中定义的.

我做了类似的事情

2个Nginx Pod-> 2个服务->虚拟服务

部署1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx1
spec:
  selector:
    matchLabels:
      run: nginx1
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx1
        app: frontend
    spec:
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx1 > /usr/share/nginx/html/index.html"]

部署2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx2
spec:
  selector:
    matchLabels:
      run: nginx2
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx2
        app: frontend2
    spec:
      containers:
      - name: nginx2
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx2 > /usr/share/nginx/html/index.html"]

服务1

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend

服务2

apiVersion: v1
kind: Service
metadata:
  name: nginx2
  labels:
    app: frontend2
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend2

虚拟服务

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginxvirt
spec:
  hosts:
  - nginx.default.svc.cluster.local
  - nginx2.default.svc.cluster.local
  http:
  - name: a
    match:
    - uri:
        prefix: /a
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx.default.svc.cluster.local
        port:
          number: 80
  - name: b
    match:
    - uri:
        prefix: /b
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx2.default.svc.cluster.local
        port:
          number: 80

以上虚拟服务仅在网状网关中内部起作用.. >

您有2个匹配项可供2个Nginx服务使用.

root@ubu1:/# curl nginx/a
Hello nginx1

root@ubu1:/# curl nginx/b
Hello nginx2

我建议检查istio文档并阅读有关的信息:

以及istio示例:

我认为您误会了它,它必须存在,但不能存在于网格中.例如,某些不在网格中但您仍可以使用的数据库,例如服务条目,将其连接到网格.

istio文档和整个外部服务文档.

我希望它能对您有所帮助.让我知道您是否还有其他问题.

Currently, we successfully setup Istio to create a couple ingress-gateways like api.example.com and app.example.com, that route traffic to a variety of services with destination rules, etc. In addition to this, we would love to use Istio's features for internal-only APIs, but we are unsure of how to set something like this up. Is it possible to use Istio's Gateway and VirtualServices CRDs to route traffic without exiting the cluster? If so, how would we go about setting that up?

解决方案

I would add some things to Arghya Sadhu answer.

I think my example in another post is the answer to your question, specifically virtual service gateways and hosts. This example need additional Destination Rule since we have subsets which mark the route to proper subset of nginx here and they're defined in destination rule.

I made something like that

2 nginx pods -> 2 services -> virtual service

Deployment1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx1
spec:
  selector:
    matchLabels:
      run: nginx1
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx1
        app: frontend
    spec:
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx1 > /usr/share/nginx/html/index.html"]

Deployment2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx2
spec:
  selector:
    matchLabels:
      run: nginx2
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx2
        app: frontend2
    spec:
      containers:
      - name: nginx2
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx2 > /usr/share/nginx/html/index.html"]

Service1

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend

Service2

apiVersion: v1
kind: Service
metadata:
  name: nginx2
  labels:
    app: frontend2
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend2

Virtual Service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginxvirt
spec:
  hosts:
  - nginx.default.svc.cluster.local
  - nginx2.default.svc.cluster.local
  http:
  - name: a
    match:
    - uri:
        prefix: /a
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx.default.svc.cluster.local
        port:
          number: 80
  - name: b
    match:
    - uri:
        prefix: /b
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx2.default.svc.cluster.local
        port:
          number: 80

Above virtual service works only internal in mesh gateway.

You have 2 matches for 2 nginx services.

root@ubu1:/# curl nginx/a
Hello nginx1

root@ubu1:/# curl nginx/b
Hello nginx2

I would recommend to check istio documentation and read about :

And istio examples:

I think You misunderstood, it must exist, but not in the mesh. For example some database which is not in the mesh but You still can use, for example service entry to connect it to the mesh.

There is example with wikipedia in istio documentation and whole external services documentation.

I hope it will help You. Let me know if You have any more questions.

这篇关于如何使用Istio创建内部网关?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-24 12:55