摘要：如果在一個中部署使用，將地段設置為將會使使用人家提供的負載均衡。

kubernetes中pods是平凡的，可創(chuàng)建可銷毀而且不可再生。 ReplicationControllers可以動態(tài)的創(chuàng)建&銷毀pods（如擴容 or 縮容 or 更新）。雖然pods有他們多帶帶的ip，但是他們的ip并不能得到穩(wěn)定的保證，這將會導致一個問題，如果在kubernetes集群中，有一些pods（backends）為另一些pods（frontend）提供一些功能，如何能保證frontend能夠找到&鏈接到backends。

引入Services。

kubernetes services是一個抽象的概念，定義了如何和一組pods相關聯(lián)—— 有時候叫做“micro-service”。一個service通過Label Selector來篩選出一組pods（下文會說明什么情況下不需要selector）。

舉個栗子，設想一個擁有三個節(jié)點的圖片處理backend，這三個節(jié)點都可以隨時替代——frontend并不關系鏈接的是哪一個。即使組成backend的pods發(fā)生了變動，frontend也不必關心連接到哪個backend。services將frontend和backend的鏈接關系解耦。

對于kubernetes本身的應用來說，kubernetes提供了一個簡單的endpoint 的api，對于非kubernetes本身的應用，kubernetes為servicet提供了一個解決方案，通過一個設定vip的bridge來鏈接pods。

在kubernetes中，services和pods一樣都是一個REST對象。同其他的REST對象一樣，通過POST來創(chuàng)建一個service。比如，有一組pods，每個pod對外暴露9376端口 他們的label為“app=MyApp”：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ]
    }
}

上述的json將會做以下事情：創(chuàng)建一個叫“my-service”的service，它映射了label為“app=MyApp”的pods端口9376,這個service將會被分配一個ip（cluster ip），service用這個ip作為代理，service的selector將會一直對pods進行篩選，并將起pods結果放入一個也焦作“my-service”的Endpoints中。

注意，一個service可能將流量引入到任何一個targetPost，默認targetPort字段和port字段是相同的。有趣的是targetPort 也可以是一個string，可以設定為是一組pods所映射port的name。在每個pod中，這個name所對應的真實port都可以不同。這為部署& 升級service帶來了很大的靈活性，比如 可以在

kubernetes services支持TCP & UDP協(xié)議，默認為tcp。

kubernetes service通常是鏈接pods的一個抽象層，但是service也可以作用在其他類型的backend。比如：

在生產環(huán)境中你想使用一個外部的database集群，在測試環(huán)境中使用自己的database；

希望將一個service指向另一個namespace中的service 或者 指向另外一個集群；

希望將非kubernetes的工作代碼環(huán)境遷移到kubernetes中；

在以上任意一個情景中，都可以使用到不指定selector的service：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ]
    }
}

在這個例子中，因為沒有使用到selector，因此沒有一個明確的Endpoint對象被創(chuàng)建。 因此需要手動的將service映射到對應的endpoint：

{
    "kind": "Endpoints",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "subsets": [
        {
            "addresses": [
                { "IP": "1.2.3.4" }
            ],
            "ports": [
                { "port": 80 }
            ]
        }
    ]
}

無論有沒有selector都不會影響這個service，其router指向了這個endpoint（在本例中為1.2.3.4：80）。

kubernetes中的每個node都會運行一個kube-proxy。他為每個service都映射一個本地port，任何連接這個本地port的請求都會轉到backend后的隨機一個pod，service中的字段SessionAffinity決定了使用backend的哪個pod，最后在本地建立一些iptables規(guī)則，這樣訪問service的cluster ip以及對應的port時，就能將請求映射到后端的pod中。

最終的結果就是，任何對service的請求都能被映射到正確的pod中，而client不需要關心kubernetes、service或pod的其他信息。

默認情況下，請求會隨機選擇一個backend。可以將service.spec.sessionAffinity 設置為 "ClientIP" (the default is "None")，這樣可以根據client-ip來維持一個session關系來選擇pod。

在kubernetes中，service是基于三層（TCP/UDP over IP）的架構，目前還沒有提供專門作用于七層（http）的services。

在很多情況下，一個service需要對多個port做映射。下面舉個這樣的例子，注意，使用multi-port時，必須為每個port設定name，如：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "name": "http",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            },
            {
                "name": "https",
                "protocol": "TCP",
                "port": 443,
                "targetPort": 9377
            }
        ]
    }
}

用戶可以為service指定自己的cluster ip，通過字段spec.clusterIP來實現。用戶設定的ip必須是一個有效的ip，必須符合service_cluster_ip_range 范圍，如果ip不合符上述規(guī)定，apiserver將會返回422。

有一個問題會時不時的出現，為什么不用一個DNS輪詢來替換vip？有如下幾個理由：

已經擁有很長歷史的DNS庫不會太注意DNS TTL 并且會緩存name lookup的結果；

許多應用只做一次name lookup并且將結果緩存；

即使app和dns庫做了很好的解決，client對dns做一遍又一遍的輪詢將會增加管理的復雜度；

我們做這些避免用戶做哪些作死的行為，但是，如果真有那么多用戶要求，我們會提供這樣的選擇。

對于每個運行的pod，kubelet將為其添加現有service的全局變量，支持Docker links compatible變量 以及 簡單的{SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT變量。

比如，叫做”redis-master“的service，對外映射6379端口，已經被分配一個ip，10.0.0.11，那么將會產生如下的全局變量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

這意味著一個順序依賴——service要想被pod使用，必須比pod先建立，否則這些service環(huán)境變量不會構建在pod中。DNS沒有這些限制。

一個可選的擴展（強烈建議）是DNS server。DNS server通過kubernetes api server來觀測是否有新service建立，并為其建立對應的dns記錄。如果集群已經enable DNS，那么pod可以自動對service做name解析。

舉個栗子，有個叫做”my-service“的service，他對應的kubernetes namespace為”my-ns“，那么會有他對應的dns記錄，叫做”my-service.my-ns“。那么在my-ns的namespace中的pod都可以對my-service做name解析來輕松找到這個service。在其他namespace中的pod解析”my-service.my-ns“來找到他。解析出來的結果是這個service對應的cluster ip。

有時候你不想做負載均衡 或者 在意只有一個cluster ip。這時，你可以創(chuàng)建一個”headless“類型的service，將spec.clusterIP字段設置為”None“。對于這樣的service，不會為他們分配一個ip，也不會在pod中創(chuàng)建其對應的全局變量。DNS則會為service 的name添加一系列的A記錄，直接指向后端映射的pod。此外，kube proxy也不會處理這類service
，沒有負載均衡也沒有請求映射。endpoint controller則會依然創(chuàng)建對應的endpoint。

這個操作目的是為了用戶想減少對kubernetes系統(tǒng)的依賴，比如想自己實現自動發(fā)現機制等等。Application可以通過api輕松的結合其他自動發(fā)現系統(tǒng)。

對于你應用的某些部分（比如frontend），你可能希望將service開放到公網ip，kubernetes提供兩種方式來實現，NodePort and LoadBalancer。

每個service都有個type字段，值可以有以下幾種：

ClusterIP： 使用集群內的私有ip —— 這是默認值。

NodePort： 除了使用cluster ip外，也將service的port映射到每個node的一個指定內部port上，映射的每個node的內部port都一樣。

LoadBalancer： 使用一個ClusterIP & NodePort，但是會向cloud provider申請映射到service本身的負載均衡。

注意：NodePort支持TCP/UDP，LoadBalancer只支持TCP。

如果將type字段設置為NodePort，kubernetes master將會為service的每個對外映射的port分配一個”本地port“，這個本地port作用在每個node上，且必須符合定義在配置文件中的port范圍（為--service-node-port-range）。這個被分配的”本地port“定義在service配置中的spec.ports[*].nodePort字段，如果為這個字段設定了一個值，系統(tǒng)將會使用這個值作為分配的本地port 或者 提示你port不符合規(guī)范。

這樣就方便了開發(fā)者使用自己的負載均衡方案。

如果在一個cloud provider中部署使用service，將type地段設置為LoadBalancer將會使service使用人家提供的負載均衡。這樣會異步的來創(chuàng)建service的負載均衡，在service配置的status.loadBalancer字段中，描述了所使用被提供負載均衡的詳細信息，如：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376,
                "nodePort": 30061
            }
        ],
        "clusterIP": "10.0.171.239",
        "type": "LoadBalancer"
    },
    "status": {
        "loadBalancer": {
            "ingress": [
                {
                    "ip": "146.148.47.155"
                }
            ]
        }
    }
}

這樣外部的負載均衡方案將會直接作用在后端的pod上。

通過iptables和用戶控件映射可以很好的為中小型規(guī)模服務，但是并不適用于擁有數千個service的集群。詳情請看” the original design proposal for portals“。

使用kube-proxy不太可能看到訪問的源ip，這樣使得某些類型防火墻實效。

LoadBalancers 只支持TCP.

type字段被設計成嵌套的結構，每一層都被增加到了前一層。很多云方案提供商支持的并不是很好（如，gce沒有必要分配一個NodePort來使LoadBalancer正常工作，但是AWS需要），但是當前的API需要。

以上的信息應該足夠用戶來使用service。但是還是有許多東西值得大家來深入理解。
（懶得翻了，大家自己看吧，最后貼上最后一個圖）