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負載配置：

添加一個負載

注意它的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本身可以擴容，目前來看不會有什麼瓶頸而且用起來也比較順手。

現在看起來一切都可以正常使用了，那還差什麼呢？ 想一想在併發壓力大的情況下如何彈性擴容是個問題，這將在下文中講解。