结合上文，我们的服务已经可以正常运行了，但它的访问方式只能通过服务器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
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
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
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
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，如：
2
2
Haproxy运行在K8s集群，所以不用担心haproxy的压力，可以随时扩容Pods来解决。这里有一个问题是如何把 haproxy.cfg 配置文件做成动态的，不用每次修改后还要生成Image重新启动服务，解决办法可以参考https://hub.docker.com/_/haproxy/ 的 Reloading config.
我们来看一下Haproxy的管理界面，访问http://192.196.1.160:30267/stats
测试
先配置本地的Hosts，将所有的域名都指向负载的浮动IP上
2
3
4
2192.196.1.156 scope.k8s.io
3192.196.1.156 test.k8s.io
4
然后访问域名，如dashboard.k8s.io
还有我们的测试服务
如预期一样，正常返回。这样所有要发布的WEB应用都通过一个端口来对外提供服务，所有集群里的云主机都可以做为负载资源，而且Haproxy本身可以扩容，目前来看不会有什么瓶颈而且用起来也比较顺手。
现在看起来一切都可以正常使用了，那还差什么呢？ 想一想在并发压力大的情况下如何弹性扩容是个问题，这将在下文中讲解。
