Kubernetes：将传入流量路由到特定 Pod

Question

我想在 Google Kubernetes Engine 中部署许多 Pod，然后通过像 pod-name-or-label.mydomain.com 这样的子域或像 protocol://mydomain.com:7878/pod- 这样的路径路由建立到每个特定 Pod 的 TCP 连接名称或标签。

我看过不同的方向，比如 Istio 或 nginx-ingress，但在我看来这太复杂了。

没有一个简单的解决方案吗？

Answer 1

对于Istio ，您可以使用VirtualService通过DestinationRules定义来控制到目标子集的路由规则。

该DestinationRule将路由至指定标签荚荚目标。

请求流将希望：

+--------------------+
|                    |
|    Istio Gateway   |
|                    |
|                    |
+---------+----------+
          |traffic incoming
          |
+---------v----------+
|                    |
|   VirtualService   |
|                    |
|                    |
+---------+----------+
          |route to subset by the routing rules
          v

+--------------------+
|                    |
|  DestinationRules  |
|                    |
|                    |
+---------+----------+
          |route traffic to target pods
          v

+--------------------+
|                    |
|                    |
|       Pods         |
|                    |
+--------------------+

所以正如@ericstaples 所说，您应该使用不同的pod 标签创建不同的部署，以实现将流量分离到目标 pod ，例如：

1. 创建一个带有 pod 标签的部署：t1
2. 在DestinationRule 中创建一个子集：选择 t1 标签 pod 作为子集 s1
3. 控制路由到s1子集的VirtualService中的流量
4. 到目标 Pod 的s1路由

同样对于公开Gateway ，您可以像 ** Kubernetes** 其他服务一样使用ClusterIP或NodePort ，请参阅Istio Traffic 的更多信息。

有一些参考资料也许有帮助：

https://istio.io/docs/concepts/traffic-management/

https://istio.io/docs/tasks/traffic-management/request-routing/

Answer 2

这个问题有点老了，但在当前的 Kubernetes 版本中，您可以使用Nginx Ingress轻松完成。

如果您想从集群外部访问您的应用程序，您需要使用Services公开它。 最简单的方法是当您将相同的选择器放在Deployment/Pod和Service时，将 Service 与选择器一起使用。 下面的例子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test1
spec:
  replicas: 1
  selector:
    matchLabels:
      key: test1
  template:
    metadata:
      labels:
        key: test1
    spec:
      containers:
      - name: hello1
        image: gcr.io/google-samples/hello-app:1.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: test1
spec:
  selector:
    key: test1
  ports:
    - port: 80
      targetPort: 8080

路径路由将在Ingress 中配置。 如下例所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: my.pod.svc 
    http:
      paths:
      - path: /pod
        backend:
          serviceName: my-pod
          servicePort: 80
  - host: nginx.test.svc
    http:
      paths:
      - path: /abc
        backend:
          serviceName: nginx1
          servicePort: 80

有关更多详细信息，您可以查看此线程。

Answer 3

现在我在集群上安装了 istio 的解决方案：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: echo-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "dev.sample.com"

使用该网关，我可以应用该部署、服务、虚拟服务

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-echo-1000-deployment
  labels:
    echoservice: echo-1000
spec:
  replicas: 1
  selector:
    matchLabels:
      echoservice: echo-1000
  template:
    metadata:
      labels:
        echoservice: echo-1000
    spec:
      containers:
      - image: gcr.io/google-containers/echoserver:1.10
        imagePullPolicy: IfNotPresent
        name: my-echo-run-container
        ports:
        - containerPort: 8080
          protocol: TCP

---

apiVersion: v1
kind: Service
metadata:
  name: my-echo-1000-service
  labels:
    echoservice: echo-1000
spec:
  ports:
  - port: 8080
    name: http
  selector:
    echoservice: echo-1000

---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-echo-1000-vservice
spec:
  hosts:
  - "dev.sample.com"
  gateways:
  - echo-gateway
  http:
  - match:
    - uri:
        exact: /echo-1000
    route:
    - destination:
        host: my-echo-1000-service
        port:
          number: 8080

从 istio-ingressgateway 获取 LoadbalancerIP 并在 /etc/hosts 中为 dev.sample.com 创建一个条目

现在我可以使用http://dev.sample.com/echo-1000在特定 Pod 中获取 echoserver

这是一个很好的解决方案还是有更好的解决方案？