kubernetes Service:讓客戶端發(fā)現(xiàn)pod并與之通信

5.1.Service介紹
5.1.1.Serice簡介
5.1.1.1什么是Service
　　service是k8s中的一個重要概念，主要是提供負載均衡和服務(wù)自動發(fā)現(xiàn)。

　　Service 是由 kube-proxy 組件，加上 iptables 來共同實現(xiàn)的。

5.1.1.2.Service的創(chuàng)建
　　創(chuàng)建Service的方法有兩種：

　　1.通過kubectl expose創(chuàng)建
#kubectl expose deployment nginx --port=88 --type=NodePort --target-port=80
--name=nginx-service
這一步說是將服務(wù)暴露出去，實際上是在服務(wù)前面加一個負載均衡，因為pod可能分布在不同的結(jié)點上。
–port：暴露出去的端口
–type=NodePort：使用結(jié)點+端口方式訪問服務(wù)
–target-port：容器的端口
–name：創(chuàng)建service指定的名稱
　　2.通過yaml文件創(chuàng)建


　　創(chuàng)建一個名為hostnames-yaohong的服務(wù)，將在端口80接收請求并將鏈接路由到具有標簽選擇器是app=hostnames的pod的9376端口上。

　　使用kubectl creat來創(chuàng)建serivice
apiVersion: v1 kind: Service metadata: name: hostnames-yaohong spec: selector:
app: hostnames ports: - name: default protocol: TCP port: 80 //該服務(wù)的可用端口
targetPort: 9376 //具有app=hostnames標簽的pod都屬于該服務(wù)
5.1.1.3.檢測服務(wù)
　　使用如下命令來檢查服務(wù)：
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes
ClusterIP 10.187.0.1 <none> 443/TCP 18d
5.1.1.4.在運行的容器中遠程執(zhí)行命令
　　使用kubectl exec 命令來遠程執(zhí)行容器中命令
$ kubectl -n kube-system exec coredns-7b8dbb87dd-pb9hk -- ls / bin coredns dev
etc home lib media mnt proc root run sbin srv sys tmp usr var
雙橫杠（--）代表kubectl命令項的結(jié)束，在雙橫杠后面的內(nèi)容是指pod內(nèi)部需要執(zhí)行的命令。
　　

5.2.連接集群外部的服務(wù)
5.2.1.介紹服務(wù)endpoint
服務(wù)并不是和pod直接相連的，介于他們之間的就是Endpoint資源。

Endpoint資源就是暴露一個服務(wù)的IP地址和端口列表。

通過service查看endpoint方法如下：
$ kubectl -n kube-system get svc kube-dns NAME TYPE CLUSTER-IP EXTERNAL-IP
PORT(S) AGE kube-dns ClusterI P 10.187.0.2 <none> 53/UDP,53/TCP 19d $ kubectl
-n kube-system describe svc kube-dns Name: kube-dns Namespace: kube-system
Labels: addonmanager.kubernetes.io/mode=Reconcile k8s-app=kube-dns
kubernetes.io/cluster-service=true kubernetes.io/name=CoreDNS Annotations:
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"prometheus.io/scrape":"true"},"labels":{"addonmanager.kubernetes.io/mode":...
prometheus.io/scrape: true Selector: k8s-app=kube-dns Type: ClusterIP IP:
10.187.0.2 Port: dns 53/UDP TargetPort: 53/UDP Endpoints:
10.186.0.2:53,10.186.0.3:53 //代表服務(wù)endpoint的pod的ip和端口列表 Port: dns-tcp 53/TCP
TargetPort: 53/TCP Endpoints: 10.186.0.2:53,10.186.0.3:53 Session Affinity:
None Events: <none>
　　

直接查看endpoint信息方法如下：
#kubectl -n kube-system get endpoints kube-dns NAME ENDPOINTS AGE kube-dns
10.186.0.2:53,10.186.0.3:53,10.186.0.2:53 + 1 more... 19d #kubectl -n
kube-system describe endpoints kube-dns Name: kube-dns Namespace: kube-system
Labels: addonmanager.kubernetes.io/mode=Reconcile k8s-app=kube-dns
kubernetes.io/cluster-service=true kubernetes.io/name=CoreDNS Annotations:
<none> Subsets: Addresses: 10.186.0.2,10.186.0.3 NotReadyAddresses: <none>
Ports: Name Port Protocol ---- ---- -------- dns 53 UDP dns-tcp 53 TCP Events:
<none>
　　

5.2.2.手動配置服務(wù)的endpoint
如果創(chuàng)建pod時不包含選擇器，則k8s將不會創(chuàng)建endpoint資源。這樣就需要創(chuàng)建endpoint來指的服務(wù)的對應(yīng)的endpoint列表。

service中創(chuàng)建endpoint資源，其中一個作用就是用于service知道包含哪些pod。


5.2.3.為外部服務(wù)創(chuàng)建別名
除了手動配置來訪問外部服務(wù)外，還可以使用完全限定域名（FQDN）訪問外部服務(wù)。

apiVersion: v1
kind: Service
metadata:
name: Service-yaohong
spec:
type: ExternalName //代碼的type被設(shè)置成了ExternalName
externalName: someapi.somecompany.com // 實際服務(wù)的完全限定域名（FQDN）
port: - port: 80

　　服務(wù)創(chuàng)建完成后，pod可以通過external-service.default.svc.cluster.local域名（甚至是external-service）連接外部服務(wù)。

5.3.將服務(wù)暴露給外部客戶端
有3種方式在外部訪問服務(wù)：

　　1.將服務(wù)的類型設(shè)置成NodePort；

　　2.將服務(wù)的類型設(shè)置成LoadBalance；

　　3.創(chuàng)建一個Ingress資源。

5.3.1.使用nodeport類型的服務(wù)
NodePort
服務(wù)是引導(dǎo)外部流量到你的服務(wù)的最原始方式。NodePort，正如這個名字所示，在所有節(jié)點（虛擬機）上開放一個特定端口，任何發(fā)送到該端口的流量都被轉(zhuǎn)發(fā)到對應(yīng)服務(wù)。


YAML 文件類似如下：
apiVersion: v1 kind: Service metadata: name: Service-yaohong spec: type:
NodePort //為NodePort設(shè)置服務(wù)類型 ports: - port: 80 targetPort: 8080 nodeport: 30123
//通過集群節(jié)點的30123端口可以訪問服務(wù) selector: app: yh
這種方法有許多缺點：

　　1.每個端口只能是一種服務(wù)

　　2.端口范圍只能是 30000-32767

如果節(jié)點/VM 的 IP 地址發(fā)生變化，你需要能處理這種情況

基于以上原因，我不建議在生產(chǎn)環(huán)境上用這種方式暴露服務(wù)。如果你運行的服務(wù)不要求一直可用，或者對成本比較敏感，你可以使用這種方法。這樣的應(yīng)用的最佳例子是
demo 應(yīng)用，或者某些臨時應(yīng)用。

5.3.2.通過Loadbalance將服務(wù)暴露出來
LoadBalancer 服務(wù)是暴露服務(wù)到 internet 的標準方式。在 GKE 上，這種方式會啟動一個 Network Load
Balancer[2]，它將給你一個單獨的 IP 地址，轉(zhuǎn)發(fā)所有流量到你的服務(wù)。


通過如下方法來定義服務(wù)使用負載均衡
apiVersion: v1 kind: Service metadata: name: loadBalancer-yaohong spec: type:
LoadBalancer //該服務(wù)從k8s集群的基礎(chǔ)架構(gòu)獲取負載均衡器 ports: - port: 80 targetPort: 8080
selector: app: yh
何時使用這種方式？


如果你想要直接暴露服務(wù)，這就是默認方式。所有通往你指定的端口的流量都會被轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)。它沒有過濾條件，沒有路由等。這意味著你幾乎可以發(fā)送任何種類的流量到該服務(wù)，像
HTTP，TCP，UDP，Websocket，gRPC 或其它任意種類。

這個方式的最大缺點是每一個用 LoadBalancer 暴露的服務(wù)都會有它自己的 IP 地址，每個用到的 LoadBalancer
都需要付費，這將是非常昂貴的。

5.4.通過Ingress暴露服務(wù)

為什么使用Ingress，一個重要的原因是LoadBalancer服務(wù)都需要創(chuàng)建自己的負載均衡器，以及獨有的公有Ip地址，而Ingress只需要一個公網(wǎng)Ip就能為許多服務(wù)提供訪問。


5.4.1.創(chuàng)建Ingress資源
Ingress 事實上不是一種服務(wù)類型。相反，它處于多個服務(wù)的前端，扮演著“智能路由”或者集群入口的角色。

你可以用 Ingress 來做許多不同的事情，各種不同類型的 Ingress 控制器也有不同的能力。


編寫如下ingress.yml文件
kind: Ingress metadata: name: ingressyaohong spec: rules: - host:
kubia.example.com http: paths: - path: / backend: serviceName: kubia-nodeport
servicePort: 80
通過如下命令進行查看ingress
# kubectl create -f ingress.yml
5.4.2.通過Ingress訪問服務(wù)
通過kubectl get ing命令進行查看ingress
# kubectl get ing NAME HOSTS ADDRESS PORTS AGE ingressyaohong
kubia.example.com 80 2m
了解Ingress的工作原理


何時使用這種方式？

Ingress 可能是暴露服務(wù)的最強大方式，但同時也是最復(fù)雜的。Ingress 控制器有各種類型，包括 Google Cloud Load
Balancer， Nginx，Contour，Istio，等等。它還有各種插件，比如 cert-manager[5]，它可以為你的服務(wù)自動提供 SSL 證書。

如果你想要使用同一個 IP 暴露多個服務(wù)，這些服務(wù)都是使用相同的七層協(xié)議（典型如 HTTP），那么Ingress 就是最有用的。如果你使用本地的 GCP
集成，你只需要為一個負載均衡器付費，且由于 Ingress是“智能”的，你還可以獲取各種開箱即用的特性（比如 SSL、認證、路由等等）。

5.4.3.通過相同的Ingress暴露多少服務(wù)
1.將不同的服務(wù)映射到相同的主機不同的路徑
apiVersion: v1 kind: Ingress metadata: name: Ingress-yaohong spec: rules: -
host: kubia.example.com http: paths: - path: /yh
//對kubia.example.com/yh請求轉(zhuǎn)發(fā)至kubai服務(wù) backend: serviceName: kubia servicePort：80
- path: /foo //對kubia.example.com/foo請求轉(zhuǎn)發(fā)至bar服務(wù) backend: serviceName: bar
servicePort：80
　　

2.將不同的服務(wù)映射到不同的主機上
apiVersion: v1 kind: Ingress metadata: name: Ingress-yaohong spec: rules: -
host: yh.example.com http: paths: - path: / //對yh.example.com請求轉(zhuǎn)發(fā)至kubai服務(wù)
backend: serviceName: kubia servicePort：80 - host: bar.example.com http: paths:
- path: / //對bar.example.com請求轉(zhuǎn)發(fā)至bar服務(wù) backend: serviceName: bar servicePort：80
5.4.4.配置Ingress處理TLS傳輸
客戶端和控制器之間的通信是加密的，而控制器和后端pod之間的通信則不是。
apiVersion: v1 kind: Ingress metadata: name: Ingress-yaohong spec: tls:
//在這個屬性中包含所有的TLS配置 - hosts: - yh.example.com //將接收來自yh.example.com的TLS連接
serviceName: tls-secret //從tls-secret中獲得之前創(chuàng)立的私鑰和證書 rules: - host:
yh.example.com http: paths: - path: / //對yh.example.com請求轉(zhuǎn)發(fā)至kubai服務(wù) backend:
serviceName: kubia servicePort：80
5.5.pod就緒后發(fā)出信號
5.5.1.介紹就緒探針
就緒探針有三種類型：

1.Exec探針，執(zhí)行進程的地方。容器的狀態(tài)由進程的退出狀態(tài)代碼確定。

2.HTTP GET探針，向容器發(fā)送HTTP GET請求，通過響應(yīng)http狀態(tài)碼判斷容器是否準備好。

3.TCP socket探針，它打開一個TCP連接到容器的指定端口，如果連接建立，則認為容器已經(jīng)準備就緒。

啟動容器時，k8s設(shè)置了一個等待時間，等待時間后才會執(zhí)行一次準備就緒檢查。之后就會周期性的進行調(diào)用探針，并根據(jù)就緒探針的結(jié)果采取行動。

如果某個pod未就緒成功，則會從該服務(wù)中刪除該pod，如果pod再次就緒成功，則從新添加pod。

與存活探針區(qū)別：

就緒探針如果容器未準備就緒，則不會終止或者重啟啟動。

存活探針通過殺死異常容器，并用新的正常的容器來替代他保證pod正常工作。

就緒探針只有準備好處理請求pod才會接收他的請求。

重要性;

確保客戶端只與正常的pod進行交互，并且永遠不會知道系統(tǒng)存在問題。

5.5.2.向pod添加就緒探針
添加的yml文件如下
apiVersion: v1 kind: deployment ... spec: ... port: containers: - name:
kubia-yh imgress: luksa/kubia readinessProbe: failureThreshold: 2 httpGet:
path: /ping port: 80 scheme: HTTP initialDelaySeconds: 30 periodSeconds: 5
successThreshold: 1 timeoutSeconds: 3
相關(guān)參數(shù)解釋如下：

initialDelaySeconds：容器啟動和探針啟動之間的秒數(shù)。
periodSeconds：檢查的頻率（以秒為單位）。默認為10秒。最小值為1。
timeoutSeconds：檢查超時的秒數(shù)。默認為1秒。最小值為1。
successThreshold：失敗后檢查成功的最小連續(xù)成功次數(shù)。默認為1.活躍度必須為1。最小值為1。

failureThreshold：當Pod成功啟動且檢查失敗時，Kubernetes將在放棄之前嘗試failureThreshold次。放棄生存檢查意味著重新啟動Pod。而放棄就緒檢查，Pod將被標記為未就緒。默認為3.最小值為1。
HTTP探針在httpGet上的配置項：

host：主機名，默認為pod的IP。
scheme：用于連接主機的方案（HTTP或HTTPS）。默認為HTTP。
path：探針的路徑。
httpHeaders：在HTTP請求中設(shè)置的自定義標頭。 HTTP允許重復(fù)的請求頭。
port：端口的名稱或編號。數(shù)字必須在1到65535的范圍內(nèi)

模擬就緒探針
# kubectl exec <pod_name> -- curl http://10.187.0.139:80/ping % Total %
Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent
Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
5.6.使用headless服務(wù)發(fā)現(xiàn)獨立的pod
5.6.1.創(chuàng)建headless服務(wù)
Headless Service也是一種Service，但不同的是會定義spec:clusterIP: None，也就是不需要Cluster
IP的Service。

顧名思義，Headless Service就是沒頭的Service。有什么使用場景呢？

第一種：自主選擇權(quán)，有時候client想自己來決定使用哪個Real Server，可以通過查詢DNS來獲取Real Server的信息。

第二種：Headless Services還有一個用處（PS：也就是我們需要的那個特性）。Headless
Service的對應(yīng)的每一個Endpoints，即每一個Pod，都會有對應(yīng)的DNS域名；這樣Pod之間就可以互相訪問。

　　

• ? 上一篇： 詳解：淘寶大秒殺系統(tǒng)是如何設(shè)計的？
• ? 下一篇：從零開始入門 K8s| 阿里技術(shù)專家詳解 K8s 核心概念