Openstack+Kubernetes+Docker微服务实践之路–服务发布

释放双眼,带上耳机,听听看~!

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

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

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

整体拓扑图

Openstack+Kubernetes+Docker微服务实践之路--服务发布

具体的配置

OpenStack负载配置:

添加一个负载
Openstack+Kubernetes+Docker微服务实践之路--服务发布

注意它的IP地址,需要给它分配一个浮动IP,这样外部才能访问到
Openstack+Kubernetes+Docker微服务实践之路--服务发布

负载均衡池

Openstack+Kubernetes+Docker微服务实践之路--服务发布

30008 是Haproxy Service配置的NodePort

Haproxy配置

通过Kubernetes来运行Haproxy

haproxy-service.yml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
1{
2    "kind": "Service",
3    "apiVersion": "v1",
4    "metadata": {
5        "name": "haproxy-service"
6    },
7    "spec": {
8        "type": "NodePort",
9        "selector": {
10            "app": "haproxy"
11        },
12        "ports": [
13            {
14                "name": "proxy",
15                "protocol": "TCP",
16                "port": 80,
17                "nodePort": 30008,
18                "targetPort": 80
19            },
20            {
21                "name": "admin",
22                "protocol": "TCP",
23                "port": 8888,
24                "targetPort": 8888,
25                "nodePort": 30001
26            }
27        ]
28    }
29}
30

haproxy.cfg


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
1global
2    maxconn 51200
3    chroot /usr/local/haproxy
4    uid 99
5    gid 99
6    daemon
7    nbproc 1
8    pidfile /var/run/haproxy-private.pid
9defaults
10    mode http
11    option redispatch
12    option abortonclose
13    timeout connect 5000ms
14    timeout client 30000ms
15    timeout server 30000ms
16    log 127.0.0.1 local0 err
17    balance roundrobin
18listen admin_stats
19    bind 0.0.0.0:8888
20    option httplog
21    stats refresh 30s
22    stats uri /stats
23    stats realm Haproxy Manager
24    stats auth admin:1
25frontend thrift-app
26    bind *:80
27    option forwardfor
28    maxconn 1000
29    acl dashboard hdr(host) -i dashboard.k8s.io
30    acl scope hdr(host) -i scope.k8s.io
31    acl thrift_test hdr(host) -i test.k8s.io
32    use_backend dashboard_app if dashboard
33    use_backend scope_app if scope
34    use_backend thrift_app_1 if thrift_test
35backend dashboard_app
36    balance roundrobin
37    option forwardfor
38    option httpclose
39    retries 3
40    server s1 10.12.48.203:80
41backend scope_app
42    balance roundrobin
43    option forwardfor
44    option httpclose
45    retries 3
46    server s2 10.1.125.203:80
47
48backend thrift_app_1
49    balance roundrobin
50    option forwardfor
51    option httpclose
52    retries 3
53    server s3 10.0.100.1:9091
54

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


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

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

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

Openstack+Kubernetes+Docker微服务实践之路--服务发布

测试

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


1
2
3
4
1192.196.1.156 dashboard.k8s.io
2192.196.1.156 scope.k8s.io
3192.196.1.156 test.k8s.io
4

然后访问域名,如dashboard.k8s.io
Openstack+Kubernetes+Docker微服务实践之路--服务发布

还有我们的测试服务
Openstack+Kubernetes+Docker微服务实践之路--服务发布

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

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

转载于:https://www.cnblogs.com/xguo/p/6093212.html

给TA打赏
共{{data.count}}人
人已打赏
安全网络

CDN安全市场到2022年价值76.3亿美元

2018-2-1 18:02:50

安全经验

3天学会Jenkins_8_Jenkins vs Travis-CI, 有何区别

2021-10-11 16:36:11

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索