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

原因似乎是来自浏览器的前端应用运行无法从互联网访问 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。这是我们的 pods

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

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

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"
}

它工作完美意味着前端与其余部分正确通信api-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 pods（注意 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

下面是此部署的图像

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

现在您的前端应用程序可以通过 Kubernetes

中公开的 LB（以黑色表示）访问 API

Kubernetes AWS EKS 无法加载资源：net::ERR_NAME_NOT_RESOLVED

Kubernetes AWS EKS Failed to load resource: net::ERR_NAME_NOT_RESOLVED

kubernetes

nginx-reverse-proxy

kubernetes-ingress

kubernetes-pod

amazon-eks