Kubernetes AWS EKS 加载资源失败：net::ERR_NAME_NOT_RESOLVED

Question

我在使用以下 AWS EKS 部署时遇到问题，其中前端总是从后端获得加载资源失败：net::ERR_NAME_NOT_RESOLVED

Failed to load resource: net::ERR_NAME_NOT_RESOLVED

原因似乎是从浏览器运行的前端应用程序 无法从 Internet 访问 Kubernetes 中的后端 API http://restapi-auth-nginx/api/

（见附件浏览器图片）

这里是配置的详细信息

- file: restapi-auth-api.yaml
Description: Backend API using GUNICORN
Details: Correctly download the image and create the pods
I can do kubectl exec -it <popId> /bin/bash
Port 5000

- file: restapi-auth-nginx.yaml 
Description: NGINX proxy for the API 
Details: Correctly download the image and create the pods 
I can do kubectl exec -it <popId> /bin/bash I can also reach the api pod  from the nginx pod so this part is working fine

- file: frontend.yaml
Description: NGINX proxy plus Angular App in a multistage deployment
Details: Correctly download the image and create the pods
I can do kubectl exec -it <popId> /bin/ash
I can also reach the api pod  from the frontend pod so this part is working fine

但是，在浏览器中，即使所有组件看起来都工作正常，我仍然会收到上述错误

（查看在浏览器中运行的网站图像）

让我向您展示如何从前端 pod 通过其 NGINX pod 访问 api。这是我们的豆荚

kubectl get  pods
NAME                                  READY   STATUS    RESTARTS   AGE
frontend-7674f4d9bf-jbd2q             1/1     Running   0          35m
restapi-auth-857f94b669-j8m7t         1/1     Running   0          39m
restapi-auth-nginx-5d885c7b69-xt6hf   1/1     Running   0          38m
udagram-frontend-5fbc78956c-nvl8d     1/1     Running   0          41m

现在让我们登录到一个 pod 并获取前端 pod 并对切断 API 的 NGINX 代理进行 curl。

让我们试试这个 curl 请求直接从前端 pod 到 Nginx 后端

curl --location --request POST 'http://restapi-auth-nginx/api/users/auth/login' \
> --header 'Content-Type: application/json' \
> --data-raw '{
> "email":"david@me.com",
> "password":"SuperPass"
> }'

现在让我们登录前端 pod 看看它是否有效

kubectl exec -it frontend-7674f4d9bf-jbd2q /bin/ash
/usr/share/nginx/html # curl --location --request POST 'http://restapi-auth-nginx/api/users/auth/login' \
> --header 'Content-Type: application/json' \
> --data-raw '{
> "email":"david@me.com",
> "password":"SuperPass"
> }'
{
  "auth": true,
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiZGF2aWRAcHlta455aS5vcmciLCJleHAiOjE1OTYwNTk7896.OIkuwLsyLhrlCMTVlccg8524OUMnkJ2qJ5fkj-7J5W0",
  "user": "david@me.com"
}

完美运行意味着前端与 restapi-auth-Nginx API 反向代理正确通信

在这张图片中，您有多个命令的输出

这里是 .yaml 文件

负载平衡器和前端

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    app: udagram
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udagram
      tier: frontend
  template:
    metadata:
      labels:
        app : udagram
        tier: frontend 
    spec:
      containers:
        - name: udagram-frontend
          image: pythonss/frontend_udacity_app
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          imagePullPolicy: Always
          ports:
          - containerPort: 80
      imagePullSecrets:
        - name: regcred

---

apiVersion: v1
kind: Service
metadata:
  name: frontend-lb
  labels:
    app: udagram
    tier: frontend
  
spec:
  type: LoadBalancer
  ports:
  -  port: 80
  selector:
     app: udagram
     tier: frontend

API 后端的 Nginx 反向代理

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose convert
    kompose.version: 1.21.0 ()
  creationTimestamp: null
  labels:
    io.kompose.service: restapi-auth-nginx
  name: restapi-auth-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: restapi-auth-nginx
  strategy: {}
  template:
    metadata:
      annotations:
        kompose.cmd: kompose convert
        kompose.version: 1.21.0 ()
      creationTimestamp: null
      labels:
        io.kompose.service: restapi-auth-nginx
    spec:
      containers:
      - image:  pythonss/restapi_auth_microservice_nginx
        imagePullPolicy: Always
        name: restapi-auth-nginx-nginx
        ports:
        - containerPort: 80
        resources: {}
      imagePullSecrets: 
      - name: regcred
      restartPolicy: Always
      serviceAccountName: ""
      volumes: null
status: {}

---

apiVersion: v1
kind: Service
metadata:
  annotations:
    kompose.cmd: kompose convert
    kompose.version: 1.21.0 ()
  creationTimestamp: null
  labels:
    io.kompose.service: restapi-auth-nginx
  name: restapi-auth-nginx
spec:
  ports:
  - name: "80"
    port: 80
    targetPort: 80
  selector:
    io.kompose.service: restapi-auth-nginx
status:
  loadBalancer: {}

为简洁起见，我不会分享 API 应用服务器 .yaml 文件。

所以我的问题是：

如何在不向外界公开 API 的情况下授予从 Internet 访问后端 API 网关的权限？

或者我应该像这样通过 LB 公开 API：

apiVersion: v1
kind: Service
metadata:
  name: backend-lb
  labels:
    io.kompose.service: restapi-auth-nginx
spec:
  type: LoadBalancer
  ports:
  -  port: 80
  selector:
     io.kompose.service: restapi-auth-nginx

这将解决问题，因为它会暴露 API。 但是，我现在需要将 FrontEnd LB 添加到 API 中的 CORS，并将 BackEndLB 添加到 FrontEnd，以便它可以进行调用。

有人可以解释如何在不暴露 API 的情况下做其他事情吗？ 这种架构的常见模式是什么？

BR

Answer 1

解决方案是通过负载均衡器服务公开 NGINX pod（注意 docker-compose 创建 2 个图像）

我们需要另一个 yaml：

apiVersion: v1
kind: Service
metadata:
  name: backend-lb
  labels:
    io.kompose.service: restapi-auth-nginx
spec:
  type: LoadBalancer
  ports:
  -  port: 80
  selector:
     io.kompose.service: restapi-auth-nginx

现在我们将拥有 3 个服务和 2 个部署。这项最新服务将 API 公开给全世界

以下是此部署的图片

如您所见，全世界只能使用这项最新服务。 GNINX 和 GUNICORN 无法从 Internet 访问。

现在您的前端应用程序可以通过 Kubernetes 内部暴露的 LB（以黑色表示）访问 API