Service 服務發現的兩種方式-通過案例來理解
1.環境變量
在創建一個Pod時，kubelet在該Pod的所有容器中為當前所有Service添加一系列環境變量。
例如，已存在名稱為“redis-master”的Service，它對外暴露6379的TCP端口，且集群IP為10.0.0.11。kubelet會為新建的容器添加以下環境變量：
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
通過環境變量來創建Service會帶來一個不好的結果，即任何被某個Pod所訪問的Service，必須先於該Pod創建，否則和這個後創建的Service相關的環境變量，
將不會被加入該Pod的容器中
2.DNS
DNS服務器通過Kubernetes API Server監控與Service相關的活動。當監控到添加Service的時，DNS服務器為每個Service創建一系列DNS記錄。
例如：有個叫做”my-service“的service，他對應的kubernetesnamespace為”my-ns“，那麽會有他對應的dns記錄，叫做”my-service.my-ns“。
那麽在my-ns的namespace中的pod都可以對my-service做name解析來輕松找到這個service。在其他namespace中的pod解析”my-service.my-ns“來找到他。
解析出來的結果是這個service對應的cluster ip。
3.集群外部的用戶希望Service能夠提供一個供集群外用戶訪問的IP地址。
一個是“NodePort”，另一個是“LoadBalancer”。
每個service都有個type字段，值可以有以下幾種：
· ClusterIP：使用集群內的私有ip —— 這是默認值。
· NodePort：除了使用cluster ip外，也將service的port映射到每個node的一個指定內部port上，映射的每個node的內部port都一樣。（端口30000以上）
· LoadBalancer：使用一個ClusterIP & NodePort，但是會向cloud provider申請映射到service本身的負載均衡。
如果將type字段設置為NodePort，kubernetes master將會為service的每個對外映射的port分配一個”本地port“，這個本地port作用在每個node上，且必須符合定義在配置文件中的port範圍（為–service-node-port-range）。這個被分配的”本地port“定義在service配置中的spec.ports[*].nodePort字段，如果為這個字段設定了一個值，系統將會使用這個值作為分配的本地port 或者 提示你port不符合規範。
Service 服務發現的兩種方式-通過案例來理解