2. 程式人生 > >Kubernetes 控制器之 Service 講解(七)

Kubernetes 控制器之 Service 講解(七)

阿新 • • 發佈：2018-12-22
rep 期望 控制器 3.0 mar contain 探討 onf connect

一、背景介紹

我們這裏準備三臺機器，一臺master，兩臺node，采用kubeadm的方式進行安裝的，安裝過程大家可以參照我之前的博文。

IP 角色 版本
192.168.1.200 master kubeadm v1.13.0
192.168.1.201 node01 kubeadm v1.13.0
192.168.1.202 node02 kubeadm v1.13.0

我們不應該期望 Kubernetes Pod 是健壯的，而是要假設 Pod 中的容器很可能因為各種原因發生故障而死掉。Deployment 等 controller 會通過動態創建和銷毀 Pod 來保證應用整體的健壯性。換句話說，Pod 是脆弱的，但應用是健壯的。

每個 Pod 都有自己的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題：

如果一組 Pod 對外提供服務（比如 HTTP），它們的 IP 很有可能發生變化，那麽客戶端如何找到並訪問這個服務呢？

Kubernetes 給出的解決方案是 Service。

二、創建 Service

Kubernetes Service 從邏輯上代表了一組 Pod，具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP，而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP，Kubernetes 則負責建立和維護 Service 與 Pod 的映射關系。無論後端 Pod 如何變化，對客戶端不會有任何影響，因為 Service 沒有變。

1、創建 Deployment

創建文件mytest-deploy.yaml文件，增加如下內容：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mytest
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: mytest
    spec:
      containers:
      - name: mytest
        image: wangzan18/mytest:v1
        ports:
        - containerPort: 80

創建我們的 Pod。

[root@master ~]# kubectl apply -f mytest-deploy.yaml 
deployment.extensions/mytest created
[root@master ~]# 
[root@master ~]# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mytest-88d46bf99-cd4zk   1/1     Running   0          70s   10.244.2.2   node02   <none>           <none>
mytest-88d46bf99-fsmcj   1/1     Running   0          70s   10.244.1.3   node01   <none>           <none>
mytest-88d46bf99-ntd5n   1/1     Running   0          70s   10.244.1.2   node01   <none>           <none>

Pod 分配了各自的 IP，這些 IP 只能被 Kubernetes Cluster 中的容器和節點訪問。

2、創建 Service

創建文件mytest-svc.yaml，新增如下內容：

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  selector:
    run: mytest
  ports:
  - port: 80
    targetPort: 8080

創建service。

[root@master ~]# kubectl apply -f mytest-svc.yaml 
service/mytest-svc created
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   33m
mytest-svc   ClusterIP   10.100.77.149   <none>        80/TCP    8s

mytest-svc 分配到一個 CLUSTER-IP 10.100.77.149。可以通過該 IP 訪問後端的 mytest Pod。

[root@master ~]# curl 10.100.77.149
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-ntd5n | v=1

通過 kubectl describe 可以查看 mytest-svc 與 Pod 的對應關系。

[root@master ~]# kubectl describe svc mytest-svc
Name:              mytest-svc
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"mytest-svc","namespace":"default"},"spec":{"ports":[{"port":80,"t...
Selector:          run=mytest
Type:              ClusterIP
IP:                10.100.77.149
Port:              <unset>  80/TCP
TargetPort:        8080/TCP
Endpoints:         10.244.1.2:8080,10.244.1.3:8080,10.244.2.2:8080
Session Affinity:  None
Events:            <none>

Endpoints 羅列了三個 Pod 的 IP 和端口。我們知道 Pod 的 IP 是在容器中配置的，那麽 Service 的 Cluster IP 又是配置在哪裏的呢？CLUSTER-IP 又是如何映射到 Pod IP 的呢？

三、Cluster IP 底層實現

1、開啟 iptables

Service Cluster IP 是一個虛擬 IP，是由 Kubernetes 節點上的 iptables 規則管理的。

可以通過 iptables-save 命令打印出當前節點的 iptables 規則，因為輸出較多，這裏只截取與 httpd-svc Cluster IP 10.100.77.149 相關的信息：

[root@master ~]# iptables-save |grep 10.100.77.149
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-XKNZ3BN47GCYFIPJ

這兩條規則的含義是：

  1. 如果 Cluster 內的 Pod（源地址來自 10.244.0.0/16）要訪問 mytest-svc，則允許。
  2. 其他源地址訪問 mytest-svc，跳轉到規則 KUBE-SVC-XKNZ3BN47GCYFIPJ。

那我們查看一下KUBE-SVC-XKNZ3BN47GCYFIPJ規則是什麽，內容如下：

-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3
  1. 1/3 的概率跳轉到規則 KUBE-SEP-6VUP2B3YLPPLYJJV。
  2. 1/3 的概率（剩下 2/3 的一半）跳轉到規則 KUBE-SEP-ENVKJLELDEHDNVGK。
  3. 1/3 的概率跳轉到規則 KUBE-SEP-IZPSUB6K7QCCEPS3。

上面的三條規則內容分別如下：
轉發到Pod 10.244.1.2。

-A KUBE-SEP-6VUP2B3YLPPLYJJV -s 10.244.1.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-6VUP2B3YLPPLYJJV -p tcp -m tcp -j DNAT --to-destination 10.244.1.2:8080

轉發到Pod 10.244.1.3。

-A KUBE-SEP-ENVKJLELDEHDNVGK -s 10.244.1.3/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-ENVKJLELDEHDNVGK -p tcp -m tcp -j DNAT --to-destination 10.244.1.3:8080

轉發到Pod 10.244.2.2。

-A KUBE-SEP-IZPSUB6K7QCCEPS3 -s 10.244.2.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-IZPSUB6K7QCCEPS3 -p tcp -m tcp -j DNAT --to-destination 10.244.2.2:8080

可以看到講請求分別轉發到了後端的三個 Pod。由此我們可以看出 iptables將訪問 Service 的流量轉發到後端 Pod，而且使用類似輪詢的負載均衡策略。

Cluster 的每一個節點都配置了相同的 iptables 規則，這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。

開啟 ipvs

默認缺省使用的是iptables，如果kube-proxy使用ipvs進行轉發的話，需要我們開啟ipvs，具體可以查看我之前的部署博文。
開啟ipvs之後的規則如下，看起來更加直觀，建議大家啟用ipvs。

[root@master ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.17.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  192.168.1.200:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.96.0.1:443 rr
  -> 192.168.1.200:6443           Masq    1      0          0         
TCP  10.96.0.10:53 rr
  -> 10.244.0.4:53                Masq    1      0          0         
  -> 10.244.0.5:53                Masq    1      0          0         
TCP  10.99.143.93:80 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.244.0.0:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.244.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  127.0.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
UDP  10.96.0.10:53 rr
  -> 10.244.0.4:53                Masq    1      0          0         
  -> 10.244.0.5:53                Masq    1      0          0

四、DNS 訪問 Service

在 Cluster 中，除了可以通過 Cluster IP 訪問 Service，Kubernetes 還提供了更為方便的 DNS 訪問。

kubeadm 部署時會默認安裝 coredns 組件。

[root@master ~]# kubectl get deploy -n kube-system
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           84m

coredns 是一個 DNS 服務器。每當有新的 Service 被創建，coredns 會添加該 Service 的 DNS 記錄。Cluster 中的 Pod 可以通過 <SERVICE_NAME>.<NAMESPACE_NAME> 訪問 Service。

比如可以用 mytest-svc.default 訪問 Service mytest-svc。

[root@master ~]# kubectl run busybox --rm -it --image=busybox /bin/sh
If you don‘t see a command prompt, try pressing enter.
/ # wget mytest-svc.default
Connecting to mytest-svc.default (10.100.77.149:80)
index.html           100% |*********************************************************|    70  0:00:00 ETA
/ #

如上所示，我們在一個臨時的 busybox Pod 中驗證了 DNS 的有效性。另外，由於這個 Pod 與 mytest-svc 同屬於 default namespace，可以省略 default 直接用 mytest-svc 訪問 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 mytest-svc.yaml 的配置文件修改如下：

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  type: NodePort
  selector:
    run: mytest
  ports:
  - port: 80
    targetPort: 8080

添加 type: NodePort，重新創建 mytest-svc。

[root@master ~]# kubectl apply -f mytest-svc.yaml 
service/mytest-svc configured
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        98m
mytest-svc   NodePort    10.100.77.149   <none>        80:31298/TCP   65m

Kubernetes 依然會為 mytest-svc 分配一個 ClusterIP，不同的是：PORT(S) 為 80:31298。80 是 ClusterIP 監聽的端口，31298 則是節點上監聽的端口，我們可以使用節點的 IP:PORT 訪問 Pod。Kubernetes 會從 30000-32767 中分配一個可用的端口，每個節點都會監聽此端口並將請求轉發給 Service。

[root@master ~]# curl 192.168.1.200:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.201:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.202:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1

接下來我們深入探討一個問題：Kubernetes 是如何將 <NodeIP>:<NodePort> 映射到 Pod 的呢？

與 ClusterIP 一樣，也是借助了 iptables。與 ClusterIP 相比，每個節點的 iptables 中都增加了下面兩條規則：

-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-SVC-XKNZ3BN47GCYFIPJ

規則的含義是：訪問當前節點 31298 端口的請求會應用規則 KUBE-SVC-XKNZ3BN47GCYFIPJ，內容為：

-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3

其作用就是負載均衡到每一個 Pod。NodePort 默認是的隨機選擇，不過我們可以用 nodePort 指定某個特定端口。

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  type: NodePort
  selector:
    run: mytest
  ports:
  - port: 80
    nodePort: 30000
    targetPort: 8080
  • nodePort 是節點上監聽的端口。
  • port 是 ClusterIP 上監聽的端口。
  • targetPort 是 Pod 監聽的端口。

最終，Node 和 ClusterIP 在各自端口上接收到的請求都會通過 iptables 轉發到 Pod 的 targetPort。

Kubernetes 控制器之 Service 講解(七)

相關推薦

Kubernetes 控制器之 Service 講解(七)

rep 期望 控制器 3.0 mar contain 探討 onf connect 一、背景介紹 我們這裏準備三臺機器，一臺master，兩臺node，采用kubeadm的方式進行安裝的，安裝過程大家可以參照我之前的博文。 IP 角色 版本 192.168.1

Kubernetes 實踐之 service

請求分發 tps spec eat 直接 sele 服務 節點 emp service是k8s最核心的概念。通過創建service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求負載分發到後端的各個容器應用上去 service定義詳解 ymal

kubernetes控制器之DaemonSet

什麼是 DaemonSet？ DaemonSet 確保全部（或者一些）Node 上執行一個 Pod 的副本。當有 Node 加入叢集時，也會為他們新增一個 Pod 。當有 Node 從叢集移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它建立的所有 Po

Kubernetes 控制器之 Deployment 介紹(六)

一、Deployment、ReplicaSet、Pod之間的關係 我們接著前面的文章說，如果不清楚的請檢視之前的博文：http://blog.51cto.com/wzlinux/2322616 前面我們已經瞭解到，Kubernetes 通過各種 Controller 來管理 Pod 的生命週期。為了滿足不

【微服務】Kubernetes物件之Service（重要）

Kubernetes Service： Kubernetes Service 定義了這樣一種抽象：一個 Pod 的邏輯分組，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 Pod 能夠被 Service 訪問到，通常是通過 Label Selector實現的

Kubernetes K8S之Service服務詳解與示例

  K8S之Service概述與代理說明，並詳解所有的service服務型別與示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.11

Kubernetes核心概念之Service詳解

clusterip ips aml 開放 lan font led IT 架構 Service是k8s中非常重要的組成單元，作用是作為代理把在POD中容器內的服務發布出去，提供一套簡單的發現機制和服務代理，也就是運維常說的‘前端’概念，那麽它如何實現代理功能以及自動

分散式系統監視zabbix講解七之分散式監控--技術流ken

  分散式監控 概述 Zabbix通過Zabbix proxy為IT基礎設施提供有效和可用的分散式監控 代理(proxy)可用於代替Zabbix server本地收集資料，然後將資料報告給伺服器。 Proxy 特徵 當選擇使用/不使用proxy時，必須考慮幾個注意事項。

Kubernetes系列之五：使用yaml檔案建立service向外暴露服務

Service和Pod的理論介紹，方便繼續下去 Pod是有生命週期的，使用凡人皆有一死來描述pod很貼切，當一個工作節點(node)銷燬時，節點上執行的pods也會被銷燬， ReplicationController會動態地在其他節點上建立Pod來保持應用程式的執行，每一個Pod都有一個

Android 8.0 系統啟動流程之init.rc解析與service流程(七)

1、概述     上一篇文章中我們介紹了一下init.rc檔案中的語法規則，而本文將分析如何解析rc檔案，並對rc檔案中的某一service啟動過程進行分析。 2、解析.rc檔案 之前我們在文件中看到.rc檔案主要有根目錄下的 /init.rc ，以及

kubernetes系列之七：一些將legacy應用遷移到kubernetes的經驗

一、前言基於kubernetes的應用實際上是微服務在container方向的例項，所以很多微服務的設計原則在kubernetes框架內依然具有參考價值，比如The Twelve Factors。在legacy應用從基於VM的部署向基於kubernetes部署的遷移過程中，需

Kubernetes之（十七）網絡模型和網絡策略

bin rip 通信 二進制文件 back rod 上進 安全性 nod 目錄 Kubernetes之（十七）網絡模型和網絡策略 Kubernetes網絡模型和CNI插件 Docker網絡

Kubernetes K8S之資源控制器RC、RS、Deployment詳解

  Kubernetes的資源控制器ReplicationController（RC）、ReplicaSet（RS）、Deployment（Deploy）詳解與示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master C

Kubernetes K8S之資源控制器StatefulSets詳解

  Kubernetes的資源控制器StatefulSet詳解與示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s

Kubernetes K8S之資源控制器Daemonset詳解

  Kubernetes的資源控制器Daemonset詳解與示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-n

Kubernetes K8S之資源控制器Job和CronJob詳解

  Kubernetes的資源控制器Job和CronJob詳解與示例   主機配置規劃 伺服器名稱(hostname)系統版本配置內網IP外網IP(模擬) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s

Kubernetes的資源控制器和Service(四)

一、定義和分類 1，定義 　　k8s 中內建了很多控制器（controller ），這些相當於一個狀態機，用來控制 Pod 的具體狀態和行為。 2，型別 　　ReplicationController、ReplicaSet、DaemonSet、StatefulSet、Job/CronJob和Horizonta

構建之法第七章學習心得

思想 studio 開發 咨詢服務 生活 int bsp partner har 構建之法第七章學習心得 這周我學習了構建之法第七章MSF的介紹。MSF有9個基本原則，針對信息共享，團隊內部運營，市場，還有客戶。同樣是強調效率，人性，靈活，還有前景。 MSF對信息共享和溝通

kubernetes部署之創建TLS證書(2)

efault control sage 啟用 簽名證書 sched amd .json 進行 研究過kubernetes的同事們都知道，kubernetes如果需要啟用TLS認證，那麽制作證書是必不可少的一步。然而，很多人在制作證書上遇到了很多的麻煩。今天主要記錄一次我在部

構建之法 第七次心得

滿足 cal 修復 使用 情況 構建 軟件 進行 方法 構建之法14、15章總結 第14章 這一章講的是質量保障。在我們做軟件的時候，最重要的是質量，如果做成功的軟件質量不過關，那無疑是白費心血，浪費時間。程序的質量體現在軟件外在功能的質量，用戶體驗的質量，國際化的質量，安