結合上文，我們的服務已經可以正常運行了，但它的訪問方式只能通過服務器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本身可以擴容，目前來看不會有什么瓶頸而且用起來也比較順手。
現在看起來一切都可以正常使用了，那還差什么呢？ 想一想在並發壓力大的情況下如何彈性擴容是個問題，這將在下文中講解。