服务发布

服务发布

结合上文,我们的服务已经可以正常运行了,但它的访问方式只能通过服务器IP加上端口来访问,如何通过域名的方式来访问到我们服务,本来想使用Kubernetes的Ingress来做,折腾一天感觉比较麻烦,Ingress还得搭配Nginx使用,而且目前还是Beta版,就打算另辟蹊径,想到了之前用的Haproxy。

本文就结合OpenStack的负载和Haproxy来实现通过域名的方式访问K8s内部要发布的服务,用到的组件有OpenStack的负载均衡和Haproxy。

OpenStack负载配置到所有的K8s云主机上的一个端口,这个端口由Haproxy的K8s Service来监听,有请求过来时Haproxy根据不同的域名转发到对应的H8s Servie的Cluster IP。

整体拓扑图

具体的配置

OpenStack负载配置:

添加一个负载

注意它的IP地址,需要给它分配一个浮动IP,这样外部才能访问到

负载均衡池

30008 是Haproxy Service配置的NodePort

Haproxy配置

通过Kubernetes来运行Haproxy

haproxy-service.yml

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "haproxy-service"
    },
    "spec": {
        "type": "NodePort",
        "selector": {
            "app": "haproxy"
        },
        "ports": [
            {
                "name": "proxy",
                "protocol": "TCP",
                "port": 80,
                "nodePort": 30008,
                "targetPort": 80
            },
            {
                "name": "admin",
                "protocol": "TCP",
                "port": 8888,
                "targetPort": 8888,
                "nodePort": 30001
            }
        ]
    }
}

haproxy.cfg

global
    maxconn 51200
    chroot /usr/local/haproxy
    uid 99
    gid 99
    daemon
    nbproc 1
    pidfile /var/run/haproxy-private.pid
defaults
    mode http
    option redispatch
    option abortonclose
    timeout connect 5000ms
    timeout client 30000ms
    timeout server 30000ms
    log 127.0.0.1 local0 err
    balance roundrobin
listen admin_stats
    bind 0.0.0.0:8888
    option httplog
    stats refresh 30s
    stats uri /stats
    stats realm Haproxy Manager
    stats auth admin:1
frontend thrift-app
    bind *:80
    option forwardfor
    maxconn 1000
    acl dashboard hdr(host) -i dashboard.k8s.io
    acl scope hdr(host) -i scope.k8s.io
    acl thrift_test hdr(host) -i test.k8s.io
    use_backend dashboard_app if dashboard
    use_backend scope_app if scope
    use_backend thrift_app_1 if thrift_test
backend dashboard_app
    balance roundrobin
    option forwardfor
    option httpclose
    retries 3
    server s1 10.12.48.203:80
backend scope_app
    balance roundrobin
    option forwardfor
    option httpclose
    retries 3
    server s2 10.1.125.203:80

backend thrift_app_1
    balance roundrobin
    option forwardfor
    option httpclose
    retries 3
    server s3 10.0.100.1:9091

需要注意的是backend的server后面的ip可以是集群服务的cluster ip也可以通过dns来访问,如thrift-c-app,如果是跨namespace需要完整的domain,如:

thrift-c-app.thrift-demo.svc.cluster.local:9091

Haproxy运行在K8s集群,所以不用担心haproxy的压力,可以随时扩容Pods来解决。这里有一个问题是如何把 haproxy.cfg 配置文件做成动态的,不用每次修改后还要生成Image重新启动服务,解决办法可以参考https://hub.docker.com/_/haproxy/ 的 Reloading config.

我们来看一下Haproxy的管理界面,访问http://192.196.1.160:30267/stats

测试

先配置本地的Hosts,将所有的域名都指向负载的浮动IP上

192.196.1.156 dashboard.k8s.io
192.196.1.156 scope.k8s.io
192.196.1.156 test.k8s.io

然后访问域名,如dashboard.k8s.io

还有我们的测试服务

如预期一样,正常返回。这样所有要发布的WEB应用都通过一个端口来对外提供服务,所有集群里的云主机都可以做为负载资源,而且Haproxy本身可以扩容,目前来看不会有什么瓶颈而且用起来也比较顺手。

现在看起来一切都可以正常使用了,那还差什么呢? 想一想在并发压力大的情况下如何弹性扩容是个问题,这将在下文中讲解。

时间: 11-26

服务发布的相关文章

8. Dubbo原理解析-代理之服务发布

服务发布是服务提供方向注册中注册服务过程,以便服务消费者从注册中心查阅并调用服务. 服务发布方在spring的配置文件中配置如下: <bean id="demoService"class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" /> 上面是在spring中配置的服务的具体实现,是spring中的一个普通的bean <dubbo:serviceinterface="com.alib

arcgis server之路网服务发布

路网服务发布首先需要建立好道路的网络集,为了保证道路网络分析的准确性,建立网络集之前,要对道路图层进行拓扑差错,确保道路的连通性.具体操作流程为:道路拓扑差错-建立几何网络集-路网服务发布. 1.道路拓扑差错: (1)通过Arccatalog建立个人地理数据库以及要素集,如图: (2)    在要素集右键菜单,导入道路图层,如图: (3)    在要素集右键菜单 新建-拓扑,弹出界面: (4)最后把拓扑的道路图层拖拽进去ArcMap进行拓扑差错,利用ArcGIS拓扑工具消除线条错误之处. 2.建

多线程端点服务发布程序(摘)

多线程端点服务发布程序 摘自:JAVA WEB服务:构建与运行 任增刚 <Java Web服务:构建与运行>以示例驱动的方式详尽地介绍了XML Web服务和RESTful Web服务所涵盖的Java相关API,以清晰.务实的方法讲述Web服务相关技术,第1章讲述Java Web服务快速入门.本节说的是多线程端点服务发布程序. AD: 2014WOT全球软件技术峰会北京站 课程视频发布 1.10  多线程端点服务发布程序 Multithreading the Endpoint Publisher

Geoserver基本使用、WMS服务发布与OpenLayers测试

1.Geoserver与OpenLayers的下载 Geoserver:http://geoserver.org/ OpenLayers:http://openlayers.org/ 2.安装部署Geoserver 环境:jdk 1.7,geoserver-2.5 配置:修改geoserver-2.5/ect/jetty.xml 的端口为8089,避免端口冲突. <Call name="addConnector"> <Arg> <New class=&qu

Dubbo源码分析(十):服务发布

服务发布是服务提供方向注册中注册服务过程,以便服务消费者从注册中心查阅并调用服务. 服务发布方在spring的配置文件中配置如下: <bean id="demoService"class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" /> 上面是在spring中配置的服务的具体实现,是spring中的一个普通的bean <dubbo:serviceinterface="com.alib

dubbo源码之四——dubbo服务发布

dubbo版本:2.5.4 服务发布是服务提供方向注册中心注册服务过程,以便服务消费者从注册中心查阅并调用服务. 服务发布方在spring的配置文件中配置如下: <bean id="demoService"class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" /> 上面是在spring中配置的服务的具体实现,是spring中的一个普通的bean. <dubbo:serviceinterfac

Geoserver的ImageMosaic数据源添加以及服务发布

概述: Geoserver中的ImageMosaic插件可以实现将两个或者两个以上的多幅影像进行镶嵌,并使坐标相同的多幅影像重叠成一个连续图象. 问题提出: 最近在做的项目中,涉及到了大量的影像数据,在做影像数据的服务发布时,现操作流程是先将该区域的影像拼接好,再通过Arcgis Server发布成为wms服务,再用GWC去切片.虽然这样的方式可以完成工作的需要,但是存在以下几个问题:1.影像拼接工作量大:2.拼接完成的数据较大:3.切片速度慢.为了解决这一问题,就查阅了些资料,提出了用Imag

Dubbo源码学习--服务发布(ProxyFactory、Invoker)

上文分析了Dubbo服务发布的整体流程,但服务代理生成的具体细节介绍得还不是很详细.下面将会接着上文继续分析.上文介绍了服务代理生成的切入点,如下: Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url); 这里的proxyFactory是在ServiceConfig中定义的,是final类型静态变量,赋值后无法进行修改.如下: private static final ProxyFactor

SOFA 源码分析 —— 服务发布过程

前言 SOFA 包含了 RPC 框架,底层通信框架是 bolt ,基于 Netty 4,今天将通过 SOFA-RPC 源码中的例子,看看他是如何发布一个服务的. 示例代码 下面的代码在 com.alipay.sofa.rpc.quickstart.QuickStartServer 类下. ServerConfig serverConfig = new ServerConfig() .setProtocol("bolt") // 设置一个协议,默认bolt .setPort(9696)