【问题标题】:Openshift 3.X - communication between backend and frontendOpenshift 3.X - 后端和前端之间的通信
【发布时间】:2021-01-04 00:11:07
【问题描述】:

我有两个 docker 镜像,一个是网络服务器,另一个是后端 Rest 应用程序。我将这些图像部署在 Openshift 集群中。我想配置运行网络服务器的 pod 以访问运行后端 Rest 应用程序的 pod,但我不知道如何向前端 pod 指定它们必须与我的后端服务通信.我只能访问 pod ip,但这不是我想要的,因为我想保持可扩展性优势。

我尝试这样访问它:

  1. 通过定义的路由:svc-backend.router.default.svc.cluster.local
  2. 通过他的服务名称:svc-backend.environment.svc.cluster.local
  3. 通过他的 ip 地址(内部):172.30.214.192
  4. 通过master主机+服务名:master.svc-backend.environment.svc.cluster.local

没有什么可悲的。谁能向我解释如何在 pod 和服务之间在 openshift 中进行通信?

【问题讨论】:

    标签: networking kubernetes openshift


    【解决方案1】:

    您可以做的最好的事情是在同一个项目中部署这 2 个 pod,这样您就可以在内部保持通信:

    $ oc new-project test
    $ oc new-app registry:5000/frontend-image
    $ oc new-app registry:5000/backend-image
    

    这将自动创建一个部署配置并创建您的 pod + 容器 + 一个复制控制器(为了高可用性,它会检查 pod 是否仍在运行)+ 一个服务。

    服务是一个重要方面。这实际上是一个负载均衡器,它将在多个 Pod 之间分配流量。 oc new-app 将检查暴露了哪些端口并在端口上方创建服务。 因此,例如,您可以将前端 pod 扩展到 3 个,然后服务会将访问者 1 分配到 pod1 并将另一个访问者分配到 pod2 等。服务是稳定的,因此其 IP 不会改变。服务 IP 以 172.30.xx.xx 开头。因此发送到此 IP 的流量将被转发到您的 Pod。因此,为了节省内部网络,最好连接服务。您可以连接到将转换为服务 IP 的服务名称。 (如果有一些奇怪的情况你必须重新创建你的服务,你可以使用相同的名称创建它,这样你就不必更改你的 appconfigs)。

    例如 我有一个与 mysql 数据库连接的应用程序。 在我的应用程序的conf中,我指向连接主机:mysql。这是我的 MySQL 服务的名称。

                 connection: {
                     host: 'mysql',
                     user: 'xx-user',
                     password: 'xx',
                     database: 'db',
    charset: 'utf8'
    

    您可以查看您的服务:

    $ oc get svc
    

    或在网络控制台中

    因此,对于您的应用程序,您必须指向后端的服务名称。 (我首先必须启动数据库,否则我的应用程序的部署将失败,因为它找不到数据库)。因此,您首先必须部署后端 + 创建服务并在前端的配置中指向该服务名称。

    有时您无法在内部保留所有内容。比你必须在你的服务上创建路线。这会将您的服务暴露给外部,您可以通过路由进行通信。 比你必须在你的配置中指向那些路由。路由将由 OpenShift 路由器转换,路由器会将其转发到正确的服务。 如果有不清楚的地方,请提供一些反馈。

    编辑 1:

    nslookup mysql                                                          
    Server:         172.30.0.1                                                      
    Address:        172.30.0.1#53                                                   
    
    Name:   mysql.test.svc.cluster.local                                       
    Address: 172.30.195.xx   
    

    编辑 2: 在 OpenShift 中启动 mysql(使用临时模板:user=test,password=test,database=test. 进入您的容器并尝试通过以下方式进行身份验证: 您将定义您的用户、密码和主机(主机 = 服务名称)。这也适用于您的服务 IP:172.30.xxx)

    sh-4.2$ mysql -utest -ptest -hmysql                                     
    Warning: Using a password on the command line interface can be insecure.        
    Welcome to the MySQL monitor.  Commands end with ; or \g.                       
    Your MySQL connection id is 48880                                               
    Server version: 5.6.26 MySQL Community Server (GPL)                             
    
    Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.    
    
    Oracle is a registered trademark of Oracle Corporation and/or its               
    affiliates. Other names may be trademarks of their respective                   
    owners.                                                                         
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.  
    
    mysql> 
    

    【讨论】:

    • 您好,非常感谢您的回答。这也是我的想法,但是当我尝试从一个 pod 使用服务名称或 ip 访问另一个 pod 时,我总是得到一个 no route to host 错误:wget backend:8080 --2016-07-29 09:35:22-- backend:8080 正在解析后端(后端)... 172.30.148.197 连接到后端(后端)|172.30.148.197|:8080... 失败:没有到主机的路由。
    • 哦,太好了,非常感谢,要理解所有机制并不容易这是一个非常复杂的产品,我在这个沟通问题上卡了一段时间:)
    • 当你尝试 ping 你的服务时发生了什么(所以从前端 ping 服务名前端和 ping 服务名后端:通常 icmp 端口在你的容器上是关闭的,但它必须能够将你的服务名解析为一个 ip: 所以我 ping mysql ---> PING mysql.dev-proj.svc.cluster.local (172.30.137.144): 56 data bytes 92 bytes from 10.1.2.1: Destination Host Unreachable (它将我的服务名 mysql 解析为服务 IP)(当然从你的容器内部 ping)
    • 我有同样的行为:PING backend.development.svc.cluster.local (172.30.148.197) 56(84) 字节的数据。从网关 (10.128.1.1) icmp_seq=1 目标主机不可达
    • 我看到了两件事。首先我的默认项目中有一个 Kubernetes 服务没有启动 pod(不知道是否正常)。其次,我的前端服务消失了,我现在只运行了一个 pod,我在这个上有一条路由,但在后端没有。
    猜你喜欢
    • 2017-12-23
    • 2022-01-20
    • 1970-01-01
    • 1970-01-01
    • 2017-11-22
    • 2014-07-20
    • 1970-01-01
    • 1970-01-01
    • 2020-01-06
    相关资源
    最近更新 更多