url - Kubernetes 中的端点 URL 管理

Question

我是 Kubernetes 的 super 初学者，我正在尝试想象如何在不同的微服务中拆分我的单体应用程序。
假设我正在 Flask 中编写我的微服务应用程序，并且每个应用程序都公开了一些端点，例如:

微服务一:

/v1/user-accounts

微服务2:

/v1/储蓄

微服务3:

/v1/auth

如果所有这些都作为整体应用程序中的蓝图运行，那么所有这些都将以相同的 IP 为前缀，即我的应用程序运行所在的主机服务器的 IP，例如 10.12.234.69，例如。

http://10.12.234.69:5000/v1/user-accounts

现在，在 Kubernetes 的 3 个不同的 POD/节点上部署这 3 个“蓝图”将改变每个端点的 IP 地址，可能是 10.12.234.69，而不是 10.12.234.70 或 10.12.234.75

我如何编写一个即使 IP 地址更改也能保持 URL 引用不变的应用程序？

负载均衡器服务能解决问题吗？

也许 Kubernetes 的服务注册功能为我做了“DNS”部分？

我知道这听起来很明显的问题，但我仍然找不到这个简单问题的任何引用/示例。

提前致谢!

编辑: (作为对西蒙回答的跟进)

问题:

鉴于 Ingress 服务产生了一个负载均衡器，并且可以从以负载均衡器的 IP( http://<ADDRESS>/v1/savings )为前缀的 http/path 访问所有路由，我如何将 IP 关联到负载均衡器以匹配运行在哪个 Flask Web 服务器上的 pod 的 ip？

如果我将其他子路由添加到相同的路径，例如 /v1/savings/get和 /v1/savings/get/id/<var_id> ，我应该更新入口 http 路径中的所有这些，以便负载均衡器可以访问它们吗？

Answer 1

负载均衡器正是您所需要的。

Kubernetes 服务将使您的 pod 可以在给定的主机名集群内部访问。

如果您想让您的服务在单个 IP 和不同路径下从集群外部访问，您可以使用负载均衡器和 Kubernetes HTTP Ingresses .它们定义服务应该映射到哪个域和路径下，并且可以由负载均衡器获取以构建其配置。

基于您的微服务架构的示例:

模拟应用

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: user-accounts
spec:
  template:
    metadata:
      labels:
        app: user-accounts
    spec:
      containers:
      - name: server
        image: nginx
        ports:
        - containerPort: 80
        args: 
        - /bin/bash
        - "-c" 
        - echo 'server { location /v1/user-accounts { return 200 "user-accounts"; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: savings
spec:
  template:
    metadata:
      labels:
        app: savings
    spec:
      containers:
      - name: server
        image: nginx
        ports:
        - containerPort: 80
        command: 
        - /bin/bash 
        - "-c" 
        - echo 'server { location /v1/savings { return 200 "savings"; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: auth
spec:
  template:
    metadata:
      labels:
        app: auth
    spec:
      containers:
      - name: server
        image: nginx
        ports:
        - containerPort: 80
        command: 
        - /bin/bash 
        - "-c" 
        - echo 'server { location /v1/auth { return 200 "auth"; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'

这些部署代表您的服务，只需在 /v1/name 下通过 HTTP 返回它们的名称。 .

将应用程序映射到服务

---
kind: Service
apiVersion: v1
metadata:
  name: user-accounts
spec:
  type: NodePort
  selector:
    app: user-accounts
  ports:
  - protocol: TCP
    port: 80
---
kind: Service
apiVersion: v1
metadata:
  name: savings
spec:
  type: NodePort
  selector:
    app: savings
  ports:
  - protocol: TCP
    port: 80
---
kind: Service
apiVersion: v1
metadata:
  name: auth
spec:
  type: NodePort
  selector:
    app: auth
  ports:
  - protocol: TCP
    port: 80

这些服务创建一个内部 IP 和一个基于它们的名称解析到它的域，将它们映射到给定选择器找到的 pod。在同一集群命名空间中运行的应用程序将能够通过 user-accounts 访问它们。 , savings和 auth .

通过负载均衡器使服务可访问

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example
spec:
  rules:
  - http:
      paths:
      - path: /v1/user-accounts
        backend:
          serviceName: user-accounts
          servicePort: 80
      - path: /v1/savings
        backend:
          serviceName: savings
          servicePort: 80
      - path: /v1/auth
        backend:
          serviceName: auth
          servicePort: 80

这个 Ingress 定义了不同服务应该在哪些路径下可达。通过 kubectl get ingress 验证您的 Ingress :

# kubectl get ingress
NAME      HOSTS     ADDRESS   PORTS     AGE
example   *                   80        1m

如果您在 Google Container Engine 上运行，则有一个 Ingress controller running in your cluster当您创建一个新的 Ingress 对象时，它将产生一个 Google Cloud Load Balancer。下 ADDRESS在上述输出的列中，将显示一个 IP，您可以在该 IP 下访问您的应用程序:

# curl http://<ADDRESS>/v1/user-accounts
user-accounts⏎
# curl http://<ADDRESS>/v1/savings
savings⏎
# curl http://<ADDRESS>/v1/auth
auth⏎