摘要：?在容器服務(wù)的客戶群中，一個(gè)經(jīng)常被問(wèn)起的問(wèn)題就是如何處理服務(wù)間依賴。本文介紹了常見(jiàn)的解決方法來(lái)實(shí)現(xiàn)服務(wù)的依賴檢查，還進(jìn)一步用示例展示了如何利用init container， liveness/readiness探針等技術(shù)實(shí)現(xiàn)服務(wù)健康檢查，依賴檢查等等功能。

本系列文章記錄了企業(yè)客戶在應(yīng)用Kubernetes時(shí)的一些常見(jiàn)問(wèn)題

• 第一篇：Java應(yīng)用資源限制的迷思
• 第二篇：利用LXCFS提升容器資源可見(jiàn)性
• 第三篇：解決服務(wù)依賴

在容器服務(wù)的客戶群中，一個(gè)經(jīng)常被問(wèn)起的問(wèn)題就是如何處理服務(wù)間依賴。

在應(yīng)用中，一個(gè)組件依賴指定的中間件服務(wù)和業(yè)務(wù)服務(wù)。在傳統(tǒng)的軟件部署方式中，應(yīng)用啟動(dòng)、停止都要依照特定的順序完成。

當(dāng)采用 Kubernetes/Docker Swarm等容器編排技術(shù)在分布式環(huán)境下部署應(yīng)用時(shí)，一方面不同組件之間并行啟動(dòng)無(wú)法保證其啟動(dòng)順序，另一方面在應(yīng)用運(yùn)行時(shí)，其所依賴的服務(wù)實(shí)現(xiàn)有可能發(fā)生失敗和遷移。如何解決容器之間的服務(wù)依賴就是一個(gè)非常常見(jiàn)的問(wèn)題。

方法1 - 應(yīng)用端服務(wù)依賴檢查

我們可以在應(yīng)用的啟動(dòng)邏輯中添加服務(wù)依賴檢查邏輯，如果應(yīng)用依賴的服務(wù)不可訪問(wèn)就重試，當(dāng)錯(cuò)誤超過(guò)一定次數(shù)后就自動(dòng)退出。Kubernetes/Docker會(huì)根據(jù)所容器的重啟策略(Restart Policy)在等待一段時(shí)間之后自動(dòng)拉起。

下面就是一個(gè)簡(jiǎn)單的Golang應(yīng)用示例，來(lái)檢測(cè)所依賴的MySQL服務(wù)是否就緒。

...// Connect to database.hostPort := net.JoinHostPort(config.Host, config.Port)log.Println("Connecting to database at", hostPort)dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?timeout=30s",config.Username, config.Password, hostPort, config.Database)db, err = sql.Open("mysql", dsn)if err != nil {log.Println(err)}var dbError errormaxAttempts := 20for attempts := 1; attempts <= maxAttempts; attempts++ {dbError = db.Ping()if dbError == nil {break}log.Println(dbError)time.Sleep(time.Duration(attempts) * time.Second)}if dbError != nil {log.Fatal(dbError)}log.Println("Application started successfully.")...

注：?
"Fail Fast" (快速失敗)，是Design by Contract契約式設(shè)計(jì)的一種重要的原則，可以很好地保障系統(tǒng)的健壯性和可預(yù)測(cè)性。比如上文代碼中，如果重試失敗，就會(huì)由log.Fatal(dbError)?退出執(zhí)行。而K8S/Docker的容器重啟的回退機(jī)制可以保障不會(huì)因頻繁拉起失敗應(yīng)用導(dǎo)致系統(tǒng)資源耗盡。

方法2 - 獨(dú)立的服務(wù)依賴檢查邏輯

在現(xiàn)實(shí)世界里，有些遺留應(yīng)用或者框架無(wú)法進(jìn)行調(diào)整。我們就會(huì)希望將依賴檢查策略和應(yīng)用邏輯進(jìn)行解耦。

一個(gè)常見(jiàn)的方法是在容器的Dockerfile的啟動(dòng)腳本里加入相應(yīng)的服務(wù)依賴檢查邏輯，可以參見(jiàn)Docker文檔獲得更多信息。另一種方法是利用Kubernetes Pod自身機(jī)制添加依賴檢查邏輯。

首先我們需要對(duì)Pod的生命周期有一定的理解，下圖來(lái)自于?https://blog.openshift.com/kubernetes-pods-life/?一文

首先在Pod中有三類容器

• infra container: 這就是著名的pause容器
• init container:?初始化容器?通常用于應(yīng)用的初始化準(zhǔn)備，只有等所有的初始化容器正常執(zhí)行完畢之后，才會(huì)啟動(dòng)應(yīng)用容器
• main container: 應(yīng)用容器

Kubernetes的最佳實(shí)踐中，通常是利用初始化容器來(lái)進(jìn)行依賴服務(wù)的檢查。下面我們通過(guò)一個(gè)Wordpress的實(shí)例來(lái)展示其使用方法。

apiVersion: v1 kind: Service metadata:name: mysql spec:clusterIP: Noneports:- name: mysqlport: 3306selector:app: mysql --- apiVersion: v1 kind: Service metadata:name: wordpress spec:ports:- name: wordpressport: 80targetPort: 80selector:app: wordpresstype: NodePort --- apiVersion: apps/v1 kind: StatefulSet metadata:name: mysql spec:selector:matchLabels:app: mysqlserviceName: mysql replicas: 1template:metadata:labels:app: mysqlspec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ALLOW_EMPTY_PASSWORDvalue: "true"livenessProbe:exec:command: ["mysqladmin", "ping"]initialDelaySeconds: 30periodSeconds: 10timeoutSeconds: 5readinessProbe:exec:# Check we can execute queries over TCP (skip-networking is off).command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]initialDelaySeconds: 5periodSeconds: 2timeoutSeconds: 1 --- apiVersion: apps/v1 kind: Deployment metadata:name: wordpress spec:replicas: 1selector:matchLabels:app: wordpresstemplate:metadata:labels:app: wordpressspec:containers:- name: wordpressimage: wordpress:4ports:- containerPort: 80env:- name: WORDPRESS_DB_HOSTvalue: mysql- name: WORDPRESS_DB_PASSWORDvalue: ""initContainers:- name: init-mysqlimage: busyboxcommand: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2; done;']

我們?cè)赪ordpress Deployment的Pod定義中添加了initContainers，它會(huì)通過(guò)檢查?mysql?域名是否可以解析來(lái)判斷所依賴的mysql服務(wù)是否就緒。

同時(shí)，在MySQL StatefulSet中我們也引入了readinessProbe?和?livenessProbe探針，它們會(huì)判定是否MySQL進(jìn)程已經(jīng)業(yè)務(wù)就緒。在K8S中，只有健康的Pod才可以通過(guò)ClusterIP訪問(wèn)或者DNS解析。

$ kubectl create -f wordpress.yaml service "mysql" created service "wordpress" created statefulset "mysql" created deployment "wordpress" created $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-0 0/1 Running 0 5s wordpress-797655cf44-w4p87 0/1 Init:0/1 0 5s $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-0 1/1 Running 0 11s wordpress-797655cf44-w4p87 0/1 Init:0/1 0 11s $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-0 1/1 Running 0 14s wordpress-797655cf44-w4p87 0/1 PodInitializing 0 14s $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-0 1/1 Running 0 17s wordpress-797655cf44-w4p87 1/1 Running 0 17s $ kubectl describe pods wordpress-797655cf44-w4p87 ...

注：

• Liveness探針：主要用于判斷Container是否處于運(yùn)行狀態(tài)，比如當(dāng)服務(wù)死鎖或者響應(yīng)緩慢等情況。
• Readiness探針：主要用于判斷服務(wù)是否已經(jīng)正常工作。
• 在init container中不允許使用readiness探針。
• 如果Pod重啟了，其所有init Container都需重新運(yùn)行。

總結(jié)

本文介紹了常見(jiàn)的解決方法來(lái)實(shí)現(xiàn)服務(wù)的依賴檢查，還進(jìn)一步用示例展示了如何利用init container， liveness/readiness探針等技術(shù)實(shí)現(xiàn)服務(wù)健康檢查，依賴檢查等等功能。

Kubernetes提供了非常靈活的Pod生命周期管理機(jī)制，由于篇幅有限我們就不再展開(kāi)介紹 postStart/preStop等生命周期鉤子方法。

阿里云Kubernetes服務(wù)?全球首批通過(guò)Kubernetes一致性認(rèn)證，簡(jiǎn)化了Kubernetes集群生命周期管理，內(nèi)置了與阿里云產(chǎn)品集成，也將進(jìn)一步簡(jiǎn)化Kubernetes的開(kāi)發(fā)者體驗(yàn)，幫助用戶關(guān)注云端應(yīng)用價(jià)值創(chuàng)新。

原文鏈接

干貨好文，請(qǐng)關(guān)注掃描以下二維碼：

總結(jié)

以上是生活随笔為你收集整理的Kubernetes之路 3 - 解决服务依赖的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。