一、通過 Service 訪問 Pod：
我們不應該期望 Kubernetes Pod 是健壯的，而是要假設 Pod 中的容器很可能因為各種原因發生故障而死掉。Deployment 等 controller 會通過動態建立和銷燬 Pod 來保證應用整體的健壯性。換句話說，Pod 是脆弱的，但應用是健壯的。
每個 Pod 都有自己的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題：
如果一組 Pod 對外提供服務（比如 HTTP），它們的 IP 很有可能發生變化，那麼客戶端如何找到並訪問這個服務呢？
Kubernetes 給出的解決方案是 Service。
在k8s裡面，比如我們執行了一個服務，這個服務是啟動了3副本，客戶端要訪問這個服務的時候，不是直接訪問你的pod，而是訪問pod對外提供的代表，service，service會固定一個IP地址，即使你的pod怎麼去銷燬重新建立，沒關係，我service對外提供服務，你只要訪問我service這個固定IP就好。（你訪問service的時候，不是說三個pod同時對外提供服務，它會把你請求呢根據一定的演算法，轉發到你後端的三個pod裡面，有可能你這個訪問的是第一個pod給你提供的實際服務，有可能第二次就是第二個pod給你提供的服務，那
建立 Service（也需要通過編排檔案建立出來）
Kubernetes Service 從邏輯上代表了一組 Pod，具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP，而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP，Kubernetes 則負責建立和維護 Service 與 Pod 的對映關係。無論後端 Pod 如何變化，對客戶端不會有任何影響，因為 Service 沒有變。
來看個例子，建立下面的這個 Deployment：
我們啟動了兩個 Pod，執行 httpd 映象，label 是 run: httpd，Service 將會用這個 label 來挑選 Pod，怎麼說，下圖假如是一臺主機，它裡面執行了很多很多的pod，如上圖的yml檔案，我們只起了兩個httpd的pod，另外三個pod執行的假如是nginx，那麼service怎麼去選擇啟動的httpd的pod呢？就是因為這兩個pod裡定義了label，run:httpd，在我service的yml檔案中selector（選擇器）也會有一個label，挑選run:httpd的pod。
Pod 分配了各自的 IP，這些 IP 只能被 Kubernetes Cluster 中的容器和節點訪問（這個IP是私有的IP，只能在我叢集當中的節點來訪問）。
接下來建立 Service，其配置檔案如下：
① v1 是 Service 的 apiVersion。
② 指明當前資源的型別為 Service。
③ Service 的名字為 httpd-svc。
④ selector 指明挑選那些 label 為 run: httpd 的 Pod 作為 Service 的後端。
⑤ 將 Service 的 8080 埠對映到 Pod 的 80 埠，使用 TCP 協議。
執行 kubectl apply 建立 Service httpd-svc。
httpd-svc 分配到一個 CLUSTER-IP 10.68.236.129。為什麼是這個IP呢，因為當初我們部署的時候配置檔案定義了service的IP,我們看一下，可以通過該 IP 訪問後端的 httpd Pod。
根據前面的埠對映，這裡要使用 8080 埠。另外，除了我們建立的 httpd-svc，還有一個 Service kubernetes，Cluster 內部通過這個 Service 訪問 kubernetes API Server。
通過 kubectl describe 可以檢視 httpd-svc 與 Pod 的對應關係。
kubectl describe service httpd-svc kubectl get pod -o wide
Endpoints 羅列了兩個 Pod 的 IP 和埠。我們知道 Pod 的 IP 是在容器中配置的，那麼 Service 的 Cluster IP 又是配置在哪裡的呢？CLUSTER-IP 又是如何對映到 Pod IP 的呢？
答案是 iptables
二、Service IP 原理：
Service IP 原理
Service Cluster IP 是一個虛擬 IP，是由 Kubernetes 節點上的 iptables 規則管理的。
可以通過 iptables-save 命令列印出當前節點的 iptables 規則，因為輸出較多，這裡只擷取與 httpd-svc Cluster IP 10.68.236.129 相關的資訊：
這條規則的含義是：
如果 Cluster 內的 Pod要訪問 httpd-svc，跳轉到規則 KUBE-SVC-LLMSFKRLGJ6BVN7Z
KUBE-SVC-LLMSFKRLGJ6BVN7Z 規則如下：
上面兩個跳轉的規則如下：
即將請求分別轉發到後端的兩個 Pod。通過上面的分析，我們得到如下結論：
iptables 將訪問 Service 的流量轉發到後端 Pod，而且使用類似輪詢的負載均衡策略。
另外需要補充一點：Cluster 的每一個節點都配置了相同的 iptables 規則，這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。
一個客戶端要訪問你的服務的時候，它先轉發給了一條規則（Cluster_IP的規則），這條規則又分別轉發給了兩條規則（這兩條規則分別是pod_ip的規則），這兩條規則裡具體寫了pod的地址。
DNS 訪問 Service：
在 Cluster 中，除了可以通過 Cluster IP 訪問 Service，Kubernetes 還提供了更為方便的 DNS 訪問。
DNS元件
kubeadm 部署時會預設安裝 kube-dns 元件。
coredns 是一個 DNS 伺服器。每當有新的 Service 被建立，coredns 會新增該 Service 的 DNS 記錄。Cluster 中的 Pod 可以通過 <SERVICE_NAME>.<NAMESPACE_NAME> 訪問 Service。
比如可以用 httpd-svc.default 訪問 Service httpd-svc。
kubectl run busybox --rm -ti --image=reg.yunwei.edu/learn/busybox:latest /bin/sh wget httpd-svc:8080
三、外網訪問 Service：
外網如何訪問 Service？
除了 Cluster 內部可以訪問 Service，很多情況我們也希望應用的 Service 能夠暴露給 Cluster 外部。Kubernetes 提供了多種型別的 Service，預設是 ClusterIP。
ClusterIP
Service 通過 Cluster 內部的 IP 對外提供服務，只有 Cluster 內的節點和 Pod 可訪問，這是預設的 Service 型別，前面實驗中的 Service 都是 ClusterIP。
NodePort
Service 通過 Cluster 節點的靜態埠對外提供服務。Cluster 外部可以通過 <NodeIP>:<NodePort> 訪問 Service。
LoadBalancer
Service 利用 cloud provider 特有的 load balancer 對外提供服務，cloud provider 負責將 load balancer 的流量導向 Service。目前支援的 cloud provider 有 GCP、AWS、Azur 等。
下面我們來實踐 NodePort，Service httpd-svc 的配置檔案修改如下：
新增 type: NodePort，重新建立 httpd-svc。
Kubernetes 依然會為 httpd-svc 分配一個 ClusterIP，不同的是：
1、EXTERNAL-IP 為 none，表示可通過 Cluster 每個節點自身的 IP 訪問 Service。
2、PORT(S) 為 8080:27449。8080 是 ClusterIP 監聽的埠，27449 則是節點上監聽的埠。Kubernetes 會從 30000-32767 中分配一個可用的埠，每個節點都會監聽此埠並將請求轉發給 Service。
下面測試 NodePort 是否正常工作。
通過節點 IP +20801 埠都能夠訪問 httpd-svc。
NodePort 預設是的隨機選擇，不過我們可以用 nodePort 指定某個特定埠。
現在配置檔案中就有三個 Port 了：
1、nodePort 是節點上監聽的埠。
2、port 是 ClusterIP 上監聽的埠。
3、targetPort 是 Pod 監聽的埠。
看一下type型別，原來是ClusterIP,現在變成了NodePort，在叢集之內，我們訪問的是cluster-ip加8080埠。現在8080埠又對映給了node的20801埠，現在我們可以在叢集之外的節點任意訪問nodeIP加20801埠，這樣也就訪問到了pod提供的http服務了。
