中文字幕精品亚洲无线码二区,国产黄a三级三级三级看三级,亚洲七七久久桃花影院,丰满少妇被猛烈进入,国产小视频在线观看网站

Kubernetes學習之路(十四(si))之服(fu)務發現Service

一、Service的概念

  運行在(zai)Pod中的(de)(de)應用(yong)是向客(ke)戶(hu)端(duan)提(ti)供服(fu)務的(de)(de)守護進程(cheng),比如,nginx、tomcat、etcd等(deng)等(deng),它們都是受控于控制器的(de)(de)資源對象,存在(zai)生(sheng)命周期,我們知道Pod資源對象在(zai)自(zi)愿或非自(zi)愿終端(duan)后,只能被(bei)重構(gou)的(de)(de)Pod對象所替代(dai),屬于不(bu)可(ke)再生(sheng)類(lei)組件。而在(zai)動態和(he)彈性的(de)(de)管理模式下,Service為(wei)該類(lei)Pod對象提(ti)供了(le)一(yi)(yi)個固定、統一(yi)(yi)的(de)(de)訪(fang)問接口和(he)負(fu)載均(jun)衡能力。是不(bu)是覺得一(yi)(yi)堆(dui)話都沒聽明(ming)白呢????

  其實,就(jiu)是說Pod存在生命周期,有銷毀(hui),有重建,無法提(ti)供一個固定(ding)的(de)訪問(wen)接口給客戶端。并且為了同類的(de)Pod都能夠實現工作(zuo)負載的(de)價值,由此Service資源出現了,可(ke)以為一類Pod資源對象提(ti)供一個固定(ding)的(de)訪問(wen)接口和負載均衡,類似于阿里云的(de)負載均衡或(huo)者是LVS的(de)功能。

  但(dan)是(shi)要知(zhi)道(dao)的(de)(de)是(shi),Service和Pod對象(xiang)的(de)(de)IP地址(zhi),一個是(shi)虛(xu)擬(ni)地址(zhi),一個是(shi)Pod IP地址(zhi),都僅(jin)僅(jin)在集群內部可以(yi)(yi)進(jin)行訪問,無法接入集群外部流量。而為了解決該類問題的(de)(de)辦法可以(yi)(yi)是(shi)在單一的(de)(de)節點上做端口暴露(lu)(hostPort)以(yi)(yi)及讓Pod資(zi)源(yuan)共享工(gong)作節點的(de)(de)網絡(luo)名(ming)稱空(kong)間(jian)(hostNetwork)以(yi)(yi)外,還可以(yi)(yi)使用NodePort或者(zhe)是(shi)LoadBalancer類型的(de)(de)Service資(zi)源(yuan),或者(zhe)是(shi)有7層負載均衡能力的(de)(de)Ingress資(zi)源(yuan)。

  Service是Kubernetes的(de)核心資源類型之一(yi)(yi),Service資源基于標簽選擇(ze)器將一(yi)(yi)組(zu)Pod定義成一(yi)(yi)個(ge)邏輯(ji)組(zu)合(he),并通過(guo)自己(ji)的(de)IP地址和端口調(diao)度代理請求到組(zu)內的(de)Pod對象,如(ru)下圖所示,它向客戶端隱藏了真是的(de),處理用戶請求的(de)Pod資源,使得從客戶端上看,就像是由Service直接處理并響應一(yi)(yi)樣,是不是很像負載均衡器呢!

  Service對象的(de)(de)(de)(de)IP地址也稱(cheng)為Cluster IP,它(ta)位于(yu)為Kubernetes集群(qun)配置指(zhi)定專用(yong)的(de)(de)(de)(de)IP地址范(fan)圍之(zhi)內(nei),是(shi)一種虛(xu)擬的(de)(de)(de)(de)IP地址,它(ta)在Service對象創建之(zhi)后保持(chi)不(bu)變,并且能(neng)夠被同一集群(qun)中的(de)(de)(de)(de)Pod資源所訪問。Service端口(kou)(kou)(kou)用(yong)于(yu)接受客戶(hu)端請(qing)求,并將請(qing)求轉(zhuan)發至后端的(de)(de)(de)(de)Pod應用(yong)的(de)(de)(de)(de)相應端口(kou)(kou)(kou),這樣(yang)的(de)(de)(de)(de)代理機制,也稱(cheng)為端口(kou)(kou)(kou)代理,它(ta)是(shi)基于(yu)TCP/IP 協議棧的(de)(de)(de)(de)傳輸層。

二、Service的實現模型

  在 Kubernetes 集群中,每個 Node 運行一個 kube-proxy 進程。kube-proxy 負責為 Service 實現了一種 VIP(虛擬 IP)的形式,而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本,代理完全在 userspace。在 Kubernetes v1.1 版本,新增了 iptables 代理,但并不是默認的運行模式。 從 Kubernetes v1.2 起,默認就是 iptables 代理。在Kubernetes v1.8.0-beta.0中,添加了ipvs代理。在 Kubernetes v1.0 版本,Service 是 “4層”(TCP/UDP over IP)概念。 在 Kubernetes v1.1 版本,新增了 Ingress API(beta 版),用來表示 “7層”(HTTP)服務。

kube-proxy 這個組件始終(zhong)監(jian)視(shi)著apiserver中(zhong)有關service的變動信息,獲(huo)取(qu)任何一(yi)(yi)個與service資源(yuan)相關的變動狀(zhuang)態,通過watch監(jian)視(shi),一(yi)(yi)旦(dan)有service資源(yuan)相關的變動和創建,kube-proxy都(dou)要轉換為(wei)當(dang)前節點上(shang)的能(neng)夠實現資源(yuan)調度規則(例如(ru):iptables、ipvs)

2.1、userspace代理模式

  這種模式,當客戶端Pod請(qing)求內(nei)核空(kong)間(jian)的service iptables后(hou),把請(qing)求轉到給用戶空(kong)間(jian)監聽的kube-proxy 的端口,由kube-proxy來(lai)處(chu)理后(hou),再由kube-proxy將請(qing)求轉給內(nei)核空(kong)間(jian)的 service ip,再由service iptalbes根據請(qing)求轉給各節點(dian)中的的service pod。

  由(you)此可(ke)見這(zhe)個(ge)模式有很大的(de)(de)(de)問(wen)題(ti),由(you)客戶(hu)端請(qing)求先進(jin)入內(nei)核(he)(he)空(kong)間(jian)的(de)(de)(de),又進(jin)去用(yong)戶(hu)空(kong)間(jian)訪問(wen)kube-proxy,由(you)kube-proxy封裝完成后再進(jin)去內(nei)核(he)(he)空(kong)間(jian)的(de)(de)(de)iptables,再根據iptables的(de)(de)(de)規則分發給(gei)各節(jie)點的(de)(de)(de)用(yong)戶(hu)空(kong)間(jian)的(de)(de)(de)pod。這(zhe)樣(yang)流(liu)量從(cong)用(yong)戶(hu)空(kong)間(jian)進(jin)出(chu)內(nei)核(he)(he)帶來的(de)(de)(de)性能損耗是(shi)不可(ke)接受(shou)的(de)(de)(de)。在Kubernetes 1.1版本(ben)之前,userspace是(shi)默認的(de)(de)(de)代(dai)理(li)模型。

2.2、 iptables代理模式

  客戶端IP請(qing)求時,直接請(qing)求本地內(nei)核service ip,根據iptables的(de)規則直接將請(qing)求轉(zhuan)發(fa)到(dao)到(dao)各pod上(shang),因(yin)為使用iptable NAT來完成轉(zhuan)發(fa),也存在(zai)(zai)不可(ke)忽視的(de)性(xing)能損耗。另(ling)外,如果(guo)集群中存在(zai)(zai)上(shang)萬(wan)的(de)Service/Endpoint,那么Node上(shang)的(de)iptables rules將會非常(chang)龐大,性(xing)能還會再打折扣。iptables代理模式由Kubernetes 1.1版(ban)本引入,自(zi)1.2版(ban)本開始成為默認類(lei)型(xing)。

 2.3、ipvs代理模式

  Kubernetes自1.9-alpha版本引入了ipvs代理模式,自1.11版本開始成為默認設置。客戶端IP請求時到達內核空間時,根據ipvs的規則直接分發到各pod上。kube-proxy會監視Kubernetes Service對象和Endpoints,調用netlink接口以相應地創建ipvs規則并定期與Kubernetes Service對象和Endpoints對象(xiang)同步ipvs規(gui)則,以確(que)保ipvs狀態與期望(wang)一致(zhi)。訪問服務時,流量將被(bei)重定向到其中(zhong)一個后端Pod。

與(yu)iptables類似,ipvs基于(yu)netfilter 的(de) hook 功能(neng),但使用哈(ha)希表作為底層數據結構(gou)并在內核空間中工作。這意味著(zhu)ipvs可以更(geng)(geng)快地重定向流量(liang),并且在同步代理(li)規則時具有(you)更(geng)(geng)好的(de)性能(neng)。此(ci)外(wai),ipvs為負載均(jun)衡算(suan)法提(ti)供了(le)更(geng)(geng)多選(xuan)項,例(li)如:

  • rr:輪詢調度
  • lc:最小連接數
  • dh:目標哈希
  • sh:源哈希
  • sed:最短期望延遲
  • nq:不排隊調度

注意: ipvs模式假定在運行kube-proxy之前在節點上都已經安裝了IPVS內核模塊。當kube-proxy以ipvs代理模式啟動時,kube-proxy將驗證節點上是否安裝了IPVS模塊,如果未安裝,則kube-proxy將回退到iptables代理模式。

 如果某(mou)個(ge)服務后端pod發生變化,標(biao)簽選擇器適應的pod有多(duo)一(yi)個(ge),適應的信息會(hui)立(li)即(ji)反映到(dao)apiserver上,而kube-proxy一(yi)定可以watch到(dao)etc中的信息變化,而將它立(li)即(ji)轉為ipvs或者iptables中的規則,這一(yi)切(qie)都是動態和實時(shi)的,刪除(chu)一(yi)個(ge)pod也是同樣的原理。如圖:

三、Service的定義

3.1、清單創建Service

 1 [root@k8s-master ~]# kubectl explain svc
 2 KIND:     Service
 3 VERSION:  v1
 4 
 5 DESCRIPTION:
 6      Service is a named abstraction of software service (for example, mysql)
 7      consisting of local port (for example 3306) that the proxy listens on, and
 8      the selector that determines which pods will answer requests sent through
 9      the proxy.
10 
11 FIELDS:
12    apiVersion    <string>
13      APIVersion defines the versioned schema of this representation of an
14      object. Servers should convert recognized schemas to the latest internal
15      value, and may reject unrecognized values. More info:
16      https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
17 
18    kind    <string>
19      Kind is a string value representing the REST resource this object
20      represents. Servers may infer this from the endpoint the client submits
21      requests to. Cannot be updated. In CamelCase. More info:
22      https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
23 
24    metadata    <Object>
25      Standard object's metadata. More info:
26      https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
27 
28    spec    <Object>
29      Spec defines the behavior of a service.
30      https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
31 
32    status    <Object>
33      Most recently observed status of the service. Populated by the system.
34      Read-only. More info:
35      https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
View Code

其中重要的4個字段:
apiVersion:
kind:
metadata:
spec:
  clusterIP: 可以自定義,也可以動態分配
  ports:(與后端容器端口關聯)
  selector:(關聯到哪些pod資源上)
  type:服務(wu)類型

3.2、service的類型

對一(yi)些(xie)應用(如 Frontend)的(de)某些(xie)部(bu)分(fen),可能希(xi)望(wang)通過(guo)外部(bu)(Kubernetes 集群(qun)外部(bu))IP 地址(zhi)暴(bao)露(lu) Service。

Kubernetes ServiceTypes 允許指定一個需要的類型的 Service,默認是 ClusterIP 類型。

Type 的(de)取(qu)值以及行為(wei)如(ru)下:

  • ClusterIP通過集群的內部 IP 暴露服務,選擇該值,服務只能夠在集群內部可以訪問,這也是默認的 ServiceType
  • NodePort通過每個 Node 上的 IP 和靜態端口(NodePort)暴露服務。NodePort 服務會路由到 ClusterIP 服務,這個 ClusterIP 服務會自動創建。通過請求 <NodeIP>:<NodePort>,可以從集群的外部訪問一個 NodePort 服務。
  • LoadBalancer使用云提供商的負載均衡器,可以向外部暴露服務。外部的負載均衡器可以路由到 NodePort 服務和 ClusterIP 服務。
  • ExternalName通過返回 CNAME 和它的值,可以將服務映射到 externalName 字段的內容(例如, foo.bar.example.com)。 沒有任何類型代理被創建,這只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

 3.2.1、ClusterIP的service類型演示:

[root@k8s-master mainfests]# cat redis-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: default
spec:
  selector:  #標簽選擇器,必須指(zhi)定pod資源本身的標簽
    app: redis
    role: logstor
  type: ClusterIP  #指定服務類型為ClusterIP
  ports:   #指定端口
  - port: 6379  #暴露給服務的端口
  - targetPort: 6379  #容器的端口
[root@k8s-master mainfests]# kubectl apply -f redis-svc.yaml 
service/redis created
[root@k8s-master mainfests]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP    36d
redis        ClusterIP   10.107.238.182   <none>        6379/TCP   1m

[root@k8s-master mainfests]# kubectl describe svc redis
Name:              redis
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"redis","namespace":"default"},"spec":{"ports":[{"port":6379,"targetPort":6379}...
Selector:          app=redis,role=logstor
Type:              ClusterIP
IP:                10.107.238.182  #service ip
Port:              <unset>  6379/TCP
TargetPort:        6379/TCP
Endpoints:         10.244.1.16:6379  #此處的ip+端口就是pod的ip+端口
Session Affinity:  None
Events:            <none>

[root@k8s-master mainfests]# kubectl get pod redis-5b5d6fbbbd-v82pw -o wide
NAME                     READY     STATUS    RESTARTS   AGE       IP            NODE
redis-5b5d6fbbbd-v82pw   1/1       Running   0          20d       10.244.1.16   k8s-node01

從上(shang)演示(shi)可以總結出:service不會直接(jie)到pod,service是直接(jie)到endpoint資源,就是地址(zhi)加端口,再由(you)endpoint再關聯到pod。

service只要創建完,就會在dns中添加一個資源記錄進行解析,添加完成即可進行解析。資源記錄的格式為:SVC_NAME.NS_NAME.DOMAIN.LTD.

默認的集群service 的A記錄:svc.cluster.local.

redis服務創建(jian)的A記錄:redis.default.svc.cluster.local.

3.2.2、NodePort的service類型演示: 

  NodePort即節點(dian)Port,通常在部署Kubernetes集群系統時(shi)會(hui)預留一個端(duan)口范圍用(yong)于(yu)NodePort,其范圍默認(ren)為:30000~32767之(zhi)間的(de)端(duan)口。定義NodePort類(lei)型(xing)的(de)Service資(zi)源時(shi),需要使(shi)用(yong).spec.type進行明(ming)確指定。

[root@k8s-master mainfests]# kubectl get pods --show-labels |grep myapp-deploy
myapp-deploy-69b47bc96d-4hxxw   1/1       Running   0          12m       app=myapp,pod-template-hash=2560367528,release=canary
myapp-deploy-69b47bc96d-95bc4   1/1       Running   0          12m       app=myapp,pod-template-hash=2560367528,release=canary
myapp-deploy-69b47bc96d-hwbzt   1/1       Running   0          12m       app=myapp,pod-template-hash=2560367528,release=canary
myapp-deploy-69b47bc96d-pjv74   1/1       Running   0          12m       app=myapp,pod-template-hash=2560367528,release=canary
myapp-deploy-69b47bc96d-rf7bs   1/1       Running   0          12m       app=myapp,pod-template-hash=2560367528,release=canary

[root@k8s-master mainfests]# cat myapp-svc.yaml #為myapp創建service
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
    release: canary
  type: NodePort
  ports: 
  - port: 80
    targetPort: 80
    nodePort: 30080
[root@k8s-master mainfests]# kubectl apply -f myapp-svc.yaml 
service/myapp created
[root@k8s-master mainfests]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        36d
myapp        NodePort    10.101.245.119   <none>        80:30080/TCP   5s
redis        ClusterIP   10.107.238.182   <none>        6379/TCP       28m

[root@k8s-master mainfests]# while true;do curl http://192.168.56.11:30080/hostname.html;sleep 1;done
myapp-deploy-69b47bc96d-95bc4
myapp-deploy-69b47bc96d-4hxxw
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-rf7bs
myapp-deploy-69b47bc96d-95bc4
myapp-deploy-69b47bc96d-rf7bs
myapp-deploy-69b47bc96d-95bc4
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-4hxxw
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-4hxxw
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-pjv74
myapp-deploy-69b47bc96d-95bc4
myapp-deploy-69b47bc96d-hwbzt

[root@k8s-master mainfests]# while true;do curl //192.168.56.11:30080/;sleep 1;done

  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
  Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name<;/a>

從(cong)(cong)以上(shang)例子,可以看到通過NodePort方式已經實現(xian)了(le)從(cong)(cong)集群外部端口進行訪問,訪問鏈接如下://192.168.56.11:30080/。實踐中(zhong)并不鼓勵用戶自(zi)定義使用節點的(de)端口,因為容易和其(qi)他現(xian)存的(de)Service沖突(tu),建(jian)議留給系統自(zi)動配置。

 3.2.3、Pod的會話保持

  Service資源還支持Session affinity(粘性會(hui)話)機(ji)制(zhi),可以將(jiang)來自同(tong)一個客(ke)戶端的(de)(de)請求始終轉發至同(tong)一個后端的(de)(de)Pod對象,這(zhe)意味著它會(hui)影(ying)響調度算法的(de)(de)流量分發功用(yong),進(jin)而降低其(qi)負載均衡的(de)(de)效(xiao)果。因(yin)此,當客(ke)戶端訪問Pod中的(de)(de)應用(yong)程序時,如果有基于客(ke)戶端身份(fen)保存某些私(si)有信(xin)息,并基于這(zhe)些私(si)有信(xin)息追蹤(zong)用(yong)戶的(de)(de)活動(dong)等一類的(de)(de)需求時,那(nei)么應該啟用(yong)session affinity機(ji)制(zhi)。

  Service affinity的效果僅(jin)僅(jin)在(zai)一(yi)(yi)段時間內生效,默認值為10800秒,超(chao)出時長,客(ke)戶(hu)(hu)(hu)端(duan)再次訪問會重(zhong)新調度(du)。該機制僅(jin)能(neng)基(ji)于(yu)(yu)客(ke)戶(hu)(hu)(hu)端(duan)IP地址(zhi)識別(bie)客(ke)戶(hu)(hu)(hu)端(duan)身份,它會將經由同(tong)一(yi)(yi)個NAT服務器進行原地址(zhi)轉換的所有客(ke)戶(hu)(hu)(hu)端(duan)識別(bie)為同(tong)一(yi)(yi)個客(ke)戶(hu)(hu)(hu)端(duan),由此可知,其調度(du)的效果并不理想。Service 資(zi)源 通過(guo). spec. sessionAffinity 和. spec. sessionAffinityConfig 兩個字段配置粘(zhan)(zhan)性會話。 spec. sessionAffinity 字段用(yong)于(yu)(yu)定(ding)義要使(shi)(shi)用(yong)的粘(zhan)(zhan)性會話的類型,它僅(jin)支(zhi)持(chi)使(shi)(shi)用(yong)“ None” 和“ ClientIP” 兩種(zhong)屬(shu)性值。如下(xia):

[root@k8s-master mainfests]# kubectl explain svc.spec.sessionAffinity
KIND:     Service
VERSION:  v1

FIELD:    sessionAffinity <string>

DESCRIPTION:
     Supports "ClientIP" and "None". Used to maintain session affinity. Enable
     client IP based session affinity. Must be ClientIP or None. Defaults to
     None. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

sessionAffinity支持ClientIP和None 兩種方式,默(mo)認是None(隨(sui)機調度) ClientIP是來自于(yu)同(tong)一(yi)個客戶端(duan)的請求調度到(dao)同(tong)一(yi)個pod中

[root@k8s-master mainfests]# vim myapp-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
    release: canary
  sessionAffinity: ClientIP
  type: NodePort
  ports: 
  - port: 80
    targetPort: 80
    nodePort: 30080
[root@k8s-master mainfests]# kubectl apply -f myapp-svc.yaml 
service/myapp configured
[root@k8s-master mainfests]# kubectl describe svc myapp
Name:                     myapp
Namespace:                default
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"ports":[{"nodePort":30080,"port":80,"ta...
Selector:                 app=myapp,release=canary
Type:                     NodePort
IP:                       10.101.245.119
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30080/TCP
Endpoints:                10.244.1.18:80,10.244.1.19:80,10.244.2.15:80 + 2 more...
Session Affinity:         ClientIP
External Traffic Policy:  Cluster
Events:                   <none>
[root@k8s-master mainfests]# while true;do curl http://192.168.56.11:30080/hostname.html;sleep 1;done
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt
myapp-deploy-69b47bc96d-hwbzt

也可以使用打補丁的(de)方式(shi)進(jin)行修改yaml內的(de)內容,如下:

kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"ClusterIP"}}'  #session保持,同一ip訪問同一個pod

kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"None"}}'    #取消session 

四、Headless Service 

有時不需要或不想要負載均衡,以及單獨的 Service IP。 遇到這種情況,可以通過指定 Cluster IP(spec.clusterIP)的值為 "None" 來創建 Headless Service。

這個(ge)選項允許開發人(ren)員(yuan)自(zi)由尋找他們自(zi)己的(de)方式,從而(er)降低與(yu) Kubernetes 系統(tong)的(de)耦合性。 應(ying)用(yong)仍然(ran)可以使用(yong)一種自(zi)注(zhu)冊的(de)模式和適配器,對其它(ta)需要(yao)發現機(ji)制的(de)系統(tong)能(neng)夠很容易地(di)基(ji)于這個(ge) API 來構建。

對這類 Service 并不會分配 Cluster IP,kube-proxy 不會處理它們,而且平臺也不會為它們進行負載均衡和路由。 DNS 如何實現自動配置,依賴于 Service 是(shi)否(fou)定義了 selector。

(1)編寫headless service配置清單
[root@k8s-master mainfests]# cp myapp-svc.yaml myapp-svc-headless.yaml [root@k8s-master mainfests]# vim myapp-svc-headless.yaml apiVersion: v1 kind: Service metadata: name: myapp-headless namespace: default spec: selector: app: myapp release: canary clusterIP: "None"  #headless的clusterIP值為None ports: - port: 80 targetPort: 80
(2)創建headless service [root@k8s
-master mainfests]# kubectl apply -f myapp-svc-headless.yaml service/myapp-headless created [root@k8s-master mainfests]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)  AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 36d myapp NodePort 10.101.245.119 <none> 80:30080/TCP 1h myapp-headless ClusterIP None <none> 80/TCP 5s redis ClusterIP 10.107.238.182 <none> 6379/TCP 2h
(3)使用coredns進行解析驗證 [root@k8s
-master mainfests]# dig -t A myapp-headless.default.svc.cluster.local. @10.96.0.10 ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -t A myapp-headless.default.svc.cluster.local. @10.96.0.10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62028 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;myapp-headless.default.svc.cluster.local. IN A ;; ANSWER SECTION: myapp-headless.default.svc.cluster.local. 5 IN A 10.244.1.18 myapp-headless.default.svc.cluster.local. 5 IN A 10.244.1.19 myapp-headless.default.svc.cluster.local. 5 IN A 10.244.2.15 myapp-headless.default.svc.cluster.local. 5 IN A 10.244.2.16 myapp-headless.default.svc.cluster.local. 5 IN A 10.244.2.17 ;; Query time: 4 msec ;; SERVER: 10.96.0.10#53(10.96.0.10) ;; WHEN: Thu Sep 27 04:27:15 EDT 2018 ;; MSG SIZE rcvd: 349 [root@k8s-master mainfests]# kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 36d [root@k8s-master mainfests]# kubectl get pods -o wide -l app=myapp NAME  READY STATUS RESTARTS AGE IP NODE myapp-deploy-69b47bc96d-4hxxw 1/1 Running 0 1h 10.244.1.18 k8s-node01 myapp-deploy-69b47bc96d-95bc4 1/1 Running 0 1h 10.244.2.16 k8s-node02 myapp-deploy-69b47bc96d-hwbzt 1/1 Running 0 1h 10.244.1.19 k8s-node01 myapp-deploy-69b47bc96d-pjv74 1/1 Running 0 1h 10.244.2.15 k8s-node02 myapp-deploy-69b47bc96d-rf7bs 1/1 Running 0 1h 10.244.2.17 k8s-node02
(4)對比含有ClusterIP的service解析 [root@k8s
-master mainfests]# dig -t A myapp.default.svc.cluster.local. @10.96.0.10 ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -t A myapp.default.svc.cluster.local. @10.96.0.10 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50445 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;myapp.default.svc.cluster.local. IN A ;; ANSWER SECTION: myapp.default.svc.cluster.local. 5 IN A 10.101.245.119 ;; Query time: 1 msec ;; SERVER: 10.96.0.10#53(10.96.0.10) ;; WHEN: Thu Sep 27 04:31:16 EDT 2018 ;; MSG SIZE rcvd: 107 [root@k8s-master mainfests]# kubectl get svc NAME  TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP  10.96.0.1 <none> 443/TCP 36d myapp NodePort 10.101.245.119 <none> 80:30080/TCP 1h myapp-headless ClusterIP None <none> 80/TCP 11m redis ClusterIP 10.107.238.182 <none> 6379/TCP 2h

從以(yi)上的(de)演示可(ke)以(yi)看到對(dui)比普(pu)通的(de)service和headless service,headless service做(zuo)dns解(jie)析是直接解(jie)析到pod的(de),而servcie是解(jie)析到ClusterIP的(de),那么(me)headless有(you)什(shen)么(me)用(yong)(yong)呢(ni)???這將(jiang)在statefulset中應用(yong)(yong)到,這里暫時僅僅做(zuo)了(le)解(jie)什(shen)么(me)是headless service和創建方法(fa)。

 

posted @ 2018-09-07 17:07  煙雨浮華  閱讀(17659)  評論(3)    收藏  舉報