蔚來汽車的Kubernetes技術(shù)實(shí)踐

目錄1. 集群建設(shè)落地 42. Kubernetes數(shù)據(jù)備份恢復(fù) 53. 鏡像管理 104. 日志方案落地 145. 監(jiān)控方案落地 176. Q&A 20

Kubernetes已經(jīng)成為當(dāng)下最火熱的一門技術(shù)，未來一定也會有更好的發(fā)展，圍繞著云原生的周邊產(chǎn)物也越來越多，使得上云更加便利更加有意義，本文主要講解一些蔚來汽車從傳統(tǒng)應(yīng)用落地到Kubernetes集群的一些實(shí)踐經(jīng)驗(yàn)，提供給大家在落地之前的一些思考和注意點(diǎn)，并且讓大家在實(shí)施的時候能夠有一些借鑒，提供一些使用過程中的注意事項(xiàng)。

項(xiàng)目背景Docker誕生于2013年初，隨著時間的推移Docker項(xiàng)目也逐漸火熱起來，也形成了自己的生態(tài)，為了能夠靈活調(diào)度容器，編排技術(shù)也變得非常重要，Swarm，Mesos，Kubernetes屬于比較出眾的容器編排技術(shù)，然而不得不說Kubernetes絕對是當(dāng)下最火熱的技術(shù)。Kubernetes項(xiàng)目的基礎(chǔ)特性，并不是幾個工程師突然“拍腦袋”想出來的東西，而是Google公司在容器化基礎(chǔ)設(shè)施領(lǐng)域多年來實(shí)踐經(jīng)驗(yàn)的沉淀與升華，容器編排使得容器本身也有了生命，幾乎所有大公司都在使用Kubernetes，另外云原生周邊也發(fā)展的越來越好，這使得Kubernetes的功能越來越強(qiáng)大。我們從2017年開始調(diào)研Kubernetes，2018年開始小規(guī)模使用，當(dāng)時使用的是1.9版本，現(xiàn)在用的是1.11版本，最新已經(jīng)到了1.16，可謂版本更新之快，未來會考慮再升級到最新版本。

Kubernetes給我們帶來的一些好處：

解決資源利用率低的問題，原來是按照服務(wù)去單獨(dú)分配機(jī)器，資源得不到充分利用服務(wù)的資源管理、依賴管理等比較復(fù)雜，Docker的鏡像管理充分簡化了相關(guān)工作，使得DevOps理念能夠深入實(shí)施降低了服務(wù)擴(kuò)容的復(fù)雜性橫向擴(kuò)展功能也使得服務(wù)在應(yīng)對大流量場景更加靈活不再需要專門地寫腳本去監(jiān)控服務(wù)的健康狀態(tài)未來結(jié)合云原生中的ServiceMesh使服務(wù)之間的調(diào)用更加靈活，功能更加強(qiáng)大集群建設(shè)落地在落地之前我們對以下一些點(diǎn)做了相應(yīng)的考量，做好提前的選型及測試。

部署方式的選擇，在EKS、kops、kubeadm、Minikube、binary中我們選擇了binary的安裝方式，選擇二進(jìn)制的安裝方式是比較靈活的。Kubernetes版本選型：1.11.7，這個版本也是當(dāng)時官方提供的最新版本。網(wǎng)絡(luò)插件的選型：Flannel，F(xiàn)lannel官方說明會有一定的網(wǎng)絡(luò)性能損耗，但在我們使用的公有云上可以忽略這一點(diǎn)。隨著業(yè)務(wù)量增加及安全隔離需求，后續(xù)會考慮改用Calico，因?yàn)榘l(fā)現(xiàn)業(yè)務(wù)多了的話網(wǎng)絡(luò)隔離還是很有必要的，另外Canal插件其實(shí)也是跟Flannel結(jié)合實(shí)現(xiàn)網(wǎng)絡(luò)策略，但是官方對這個項(xiàng)目的維護(hù)貌似已經(jīng)不活躍就不太考慮了。Service實(shí)現(xiàn)的選型：IPVS，早期的Service都是iptables實(shí)現(xiàn)的，所以早期我們就用的iptables，但是當(dāng)集群節(jié)點(diǎn)數(shù)量到達(dá)幾千臺的話iptables性能應(yīng)該會有很大的衰減，于是在我們升級到1.11版本后果斷使用IPVS的方式實(shí)現(xiàn)Service。周邊工具選型：Harbor、Rancher、Prometheus、CoreDNS，以上這幾款工具都是云原生周邊產(chǎn)物，熱度都很高，也能夠快速簡單的支撐業(yè)務(wù)。集群優(yōu)化的考慮：網(wǎng)絡(luò)MTU、內(nèi)核版本、網(wǎng)段優(yōu)化、swap優(yōu)化等，在集群落地之前要把一些優(yōu)化點(diǎn)提前考慮好，內(nèi)核我們用的是4.18，當(dāng)時的一個最新版本，高版本支持了cgroup2，隔離性應(yīng)該會比cgroup1更加穩(wěn)定。日志方案的考慮：ELK，ELK一直是我們?nèi)罩痉桨附鉀Q的工具，所以服務(wù)上云之后我們依然沿用，其中Filebeat是以DaemonSet模式運(yùn)行，性能消耗目前來看還是可以接受的。監(jiān)控方案的考慮：Prometheus，隨著容器技術(shù)的迅速發(fā)展，Kubernetes已然成為大家追捧的容器集群管理系統(tǒng)。Prometheus作為生態(tài)圈CNCF中的重要一員，其活躍度僅次于Kubernetes，現(xiàn)已廣泛用于Kubernetes集群的監(jiān)控系統(tǒng)中，毋庸置疑監(jiān)控方面的選型非Prometheus莫屬。CI/CD的方案：自研的運(yùn)維平臺，相信各個公司都有自己的運(yùn)維平臺，我們的CI/CD也是與我們自己的平臺結(jié)合，有著一套完善的規(guī)范和流程，如果規(guī)模不大也可以考慮和Rancher的CI/CD結(jié)合，感覺也不錯。Namespace的劃分考慮，Namespace的劃分也比較重要，涉及到業(yè)務(wù)的隔離與劃分，通常要考慮到不同Namespace之間服務(wù)的調(diào)用問題，內(nèi)部域名調(diào)用問題，安全劃分問題，機(jī)器分配使用問題等等。Kubernetes數(shù)據(jù)備份恢復(fù)其實(shí)Kubernetes的數(shù)據(jù)也就是etcd中的數(shù)據(jù)，那么我們?nèi)粘＞托枰獋浞輊tcd中的數(shù)據(jù)，以及考慮數(shù)據(jù)的恢復(fù)，理論上etcd的數(shù)據(jù)恢復(fù)場景應(yīng)該很難用到，一切操作盡量都通過平臺規(guī)范化使用,但是針對災(zāi)難性的場景就可以用etcd數(shù)據(jù)備份來救場了。

這里給大家展示下etcd備份和恢復(fù)，具體細(xì)節(jié)大家根據(jù)自己環(huán)境再調(diào)整。

etcd數(shù)據(jù)備份

#!/bin/shsource/etc/profilenowtime=`date+%Y%m%d%H%M`#備份的數(shù)據(jù)目錄workdir="/data/etcd-bak"#etcd的數(shù)據(jù)目錄datadir="/data/etcd"ep=`/sbin/ipaddr|grepeth0|sed-nr's#^.*inet(.*)/22.*$#\1#gp'`capath="/etc/kubernetes/ssl/ca.pem"certpath="/etc/etcd/ssl/etcd.pem"keypath="/etc/etcd/ssl/etcd-key.pem"etcdctlpath="--endpoints"https://${ep}:2379"--cacert=$capath--cert=$certpath--key=$keypath"hostname=`hostname`alertcontent="$hostname-etcd-bak-is-false-please-check-etcd-${nowtime}"#備份數(shù)據(jù)保留天數(shù)delday=7s3path="s3://etcd/etcd-${ep}"s3alertcontent="$hostname-etcd-snapshot-to-s3-false-please-check"etcdctlcmd=`whereisetcdctl|awk'{print$NF}'`functiondeloldbak(){find$workdir-name"etcd-*.gz"-mtime+${delday}|xargsrm-f}if[!-f/data/etcd-bak/etcd-${nowtime}.tar.gz];thenmkdir-p/data/etcd-bak/etcd-${nowtime}/elseecho"needwaittonexttime"echo"needwaittonexttime">>$workdir/etcd-bak.logexit1fiecho"===================================begin$nowtime=================================="echo"===================================begin$nowtime==================================">>$workdir/etcd-bak.logexportETCDCTL_API=3echo"===================================runsnapshoting=================================">>$workdir/etcd-bak.log$etcdctlcmd$etcdctlpathsnapshotsave$workdir/etcd-${nowtime}/snap-${nowtime}.db>>$workdir/etcd-bak.logecho"===================================runsnapshoting=================================">>$workdir/etcd-bak.logif[$?-eq0]thenecho"etcdsnapshotetcd-${nowtime}/snap-${nowtime}.dbissuccessful"echo"etcdsnapshotetcd-${nowtime}/snap-${nowtime}.dbissuccessful">>$workdir/etcd-bak.logelseecho"etcdsnapshotetcd-${nowtime}/snap-${nowtime}.dbisfailed"echo"etcdsnapshotetcd-${nowtime}/snap-${nowtime}.dbisfailed">>$workdir/etcd-bak.logficp-fr$datadir/*$workdir/etcd-${nowtime}/if[$?-eq0]thenecho"etcdsnapshotetcd-${nowtime}/memberissuccessful"echo"etcdsnapshotetcd-${nowtime}/memberissuccessful">>$workdir/etcd-bak.logelseecho"etcdsnapshotetcd-${nowtime}/memberisfailed"echo"etcdsnapshotetcd-${nowtime}/memberisfailed">>$workdir/etcd-bak.logfi$etcdctlcmd$etcdctlpath--write-out=tableendpointstatus$etcdctlcmd$etcdctlpath--write-out=tableendpointstatus>>$workdir/etcd-bak.logcd$workdirtarzcf./etcd-${nowtime}.tar.gzetcd-${nowtime}rm-fretcd-${nowtime}awss3cp$workdir/etcd-${nowtime}.tar.gz$s3path/if[$?-eq0]thenecho"etcdsnapshots3issuccessful"echo"etcdsnapshots3issuccessful">>$workdir/etcd-bak.logelseecho"etcdsnapshots3isfailed"echo"etcdsnapshots3isfailed">>$workdir/etcd-bak.logfideloldbakecho"===================================end`date+%Y%m%d%H%M%S`=================================="echo"===================================end`date+%Y%m%d%H%M%S`==================================">>$workdir/etcd-bak.log

etcd數(shù)據(jù)恢復(fù)

#!/bin/bash#使用etcdctlsnapshotrestore生成各個節(jié)點(diǎn)的數(shù)據(jù)#比較關(guān)鍵的變量是#--data-dir需要是實(shí)際etcd運(yùn)行時的數(shù)據(jù)目錄#--name--initial-advertise-peer-urls需要用各個節(jié)點(diǎn)的配置#--initial-clusterinitial-cluster-token需要和原集群一致#注意http和https區(qū)別#無需更改workdir=/root#etcd1,2,3為節(jié)點(diǎn)名稱ETCD1,2,3為對應(yīng)節(jié)點(diǎn)ipETCD_1=ETCD_2=ETCD_3=etcd1=etcd1etcd2=etcd2etcd3=etcd3#同上面一樣需要對應(yīng)設(shè)置arra=()arrb=(etcd1etcd2etcd3)#etcd是否使用httpstls加密如果使用需要配置證書，若是http請置空此變量etcdkey="--cacert=/etc/kubernetes/ssl/ca.pem--cert=/etc/etcd/ssl/etcd.pem--key=/etc/etcd/ssl/etcd-key.pem"#恢復(fù)數(shù)據(jù)存放目錄，只是用于恢復(fù)存放數(shù)據(jù)，可以隨意設(shè)置，跟原有的路徑?jīng)]有關(guān)系etcddatapath="/root/etcd-recover-data/etcd"#備份數(shù)據(jù)根路徑bakdatapath="/data/etcd-bak"#備份數(shù)據(jù)完整路徑bakdbpath="$bakdatapath/etcd-201906161945/snap-201906161945.db"#ansiblesite執(zhí)行路徑ansiblepath="/root/etcd-bak-ansible"functionansibleoperate(){rm-fr$ansiblepath/roles/etcd-bak-ansible/files/*cp-fr$(echo$etcddatapath|awk-F"[/]"'{print"/"$2"/"$3}')/*$ansiblepath/roles/etcd-bak-ansible/files/cd$ansiblepathansible-playbook-ihostssite.yaml}if[!-d$(echo$etcddatapath|awk-F"[/]"'{print"/"$2"/"$3}')];thenmkdir-p$(echo$etcddatapath|awk-F"[/]"'{print"/"$2"/"$3}')fiforiin${arra[@]}doecho-e"\t$i\c">>$workdir/etcdiplist.log#echo-e"$i"doneforiin${arrb[@]}doecho-e"\t$i\c">>$workdir/etcdnamelist.log#echo-e"$i"donewhiletruedoletcnt++etcdiplist=`awk-vcolumn=$cnt'{print$column}'$workdir/etcdiplist.log`etcdnamelist=`awk-vcolumn=$cnt'{print$column}'$workdir/etcdnamelist.log`if["$etcdiplist"=""]thenecho"confisdownwilltobreak"breakfiecho$etcdiplist$etcdnamelistexportETCDCTL_API=3#如果用原有member中的db恢復(fù)，由于不存在完整的hash性，需要在下面添加--skip-hash-check\跳過hash檢查etcdctlsnapshot$etcdkeyrestore$bakdbpath\--data-dir=$etcddatapath\--name$etcdnamelist\--initial-cluster${etcd1}=https://${ETCD_1}:2380,${etcd2}=https://${ETCD_2}:2380,${etcd3}=https://${ETCD_3}:2380\--initial-cluster-tokenetcd-cluster-0\--initial-advertise-peer-urlshttps://$etcdiplist:2380&&\mv$etcddatapath$(echo$etcddatapath|awk-F"[/]"'{print"/"$2"/"$3}')/etcd_$etcdiplistecho"--initial-cluster${etcd1}=https://${ETCD_1}:2380,${etcd2}=https://${ETCD_2}:2380,${etcd3}=https://${ETCD_3}:2380"donerm-f$workdir/etcdiplist.logrm-f$workdir/etcdnamelist.log#如果不需要Ansible自動恢復(fù)集群，需要手動恢復(fù)的話請注釋以下操作ansibleoperate鏡像管理鏡像倉庫我們選擇的是Harbor，比較成熟并且社區(qū)維護(hù)更新也非?？?。我們最早使用1.2版本，現(xiàn)在使用1.6版本。目前Harbor最新是1.8版本，下面給大家展示下新舊版本功能上的差異，新版本還是有很多好功能的。

1.2版本和1.6版本功能對比

升級后具備的優(yōu)勢

存儲支持S3：鏡像從保存在本地改為存儲到S3，這樣可以節(jié)省存儲費(fèi)用，也不用考慮本地磁盤擴(kuò)容的事情。登錄接入LDAP：規(guī)范管理用戶，并且可以使用LDAP的組進(jìn)行用戶的劃分。用戶限制，用戶分組：這塊主要是結(jié)合LDAP組進(jìn)行劃分，在Harbor中建好各個對應(yīng)的項(xiàng)目，配置開發(fā)權(quán)限。漏洞掃描：每天定時掃描鏡像，不過想保證所有鏡像都不存在危險貌似不太容易，開發(fā)自定義等不規(guī)范鏡像會經(jīng)常出現(xiàn)。鏡像簽名：安全度高的鏡像會考慮開啟該功能。高可用負(fù)載：官方提供了HA的功能，主要就是訪問的HA，數(shù)據(jù)庫的HA，存儲的HA。證書認(rèn)證：訪問通過https，更加安全。數(shù)據(jù)庫更加簡單：原來是有MySQL、PostgreSQL，現(xiàn)在新版本全部統(tǒng)一使用PostgreSQL，管理更加方便。線上鏡像倉庫架構(gòu)圖

上面是我們的架構(gòu)圖，通過DNS解析將不同環(huán)境的訪問分流到對應(yīng)環(huán)境的鏡像倉庫，所有的鏡像倉庫都連接著后端數(shù)據(jù)庫集群，鏡像統(tǒng)一保存到了S3中，對于倉庫的擴(kuò)容也是十分方便的，拷貝一份配置啟動就可以了。

鏡像倉庫升級

備份之前先停止老的Harbor：

cdharbordocker-composedown

備份原來的Harbor目錄：

mvharbor/my_backup_dir/harbor

備份數(shù)據(jù)庫：

cp-r/data/database/my_backup_dir/

后續(xù)升級鏡像下載：

dockerpullgoharbor/harbor-migrator:[tag]

升級harbor.cfg或者h(yuǎn)arbor.yml文件：

dockerrun-it--rm-v${harbor_cfg}:/harbor-migration/harbor-cfg/harbor.cfg-v${harbor_yml}:/harbor-migration/harbor-cfg-out/harbor.ymlgoharbor/harbor-migrator:[tag]--cfgup

如果沒有yaml文件，低版本理論上只有cfg文件，那就升級cfg文件就可以了：

dockerrun-it--rm-v${harbor_cfg}:/harbor-migration/harbor-cfg/harbor.cfggoharbor/harbor-migrator:[tag]--cfgup

解壓新的版本離線包：

tar-zxvfharbor-offline-installer-v1.7.4.tgz

覆蓋harbor.cfg，把之前升級的harbor.cfg文件或者yml文件拷貝到新版本解壓的目錄里替換相應(yīng)的文件：

cdharbormvharbor.cfgharbor.bakcp/root/harbor-bak/harbor.cfg.

安裝Notary，Clair和HelmChart服務(wù)，安裝之前可以perpare腳本生成下配置文件：

./install.sh--with-notary--with-clair--with-chartmuseum

進(jìn)行查看：

docker-compose-f./docker-compose.yml-f./docker-compose.clair.ymlps

清除舊版本鏡像：

dockerimages|grep1.6.2|awk'{print$3}'|xargsdockerrmi日志方案落地日志落盤，DaemonSet部署Filebeat，采集進(jìn)Kafka，最終進(jìn)ES，落盤日志定期清理。

這個是基于Node級別的一種日志收集方案，我們大多使用這種方案進(jìn)行日志的收集，優(yōu)點(diǎn)就是可以和服務(wù)完全解耦，性能好，便于管理。

這種方式的一個弊端就是日志格式必須按照約定的方式配置輸出，對不能滿足約定格式的情況改用sidecar的方式進(jìn)行日志的收集。

這種方式就是擴(kuò)展性強(qiáng)，配置可以跟隨服務(wù)進(jìn)行制定的收集，弊端就是會浪費(fèi)資源，并且有一定耦合性，所以我們線上并未大面積采取這個方式的使用。監(jiān)控方案落地Prometheus想必在大家的公司中都已經(jīng)在使用了，是監(jiān)控領(lǐng)域里現(xiàn)在最火熱的一款監(jiān)控工具，在這里也不多贅述了，基本的使用大家應(yīng)該都比較了解，下面主要簡單展示下我們線上對于服務(wù)應(yīng)用是如何上報監(jiān)控，配置也并不復(fù)雜，大家看圖解讀。

Service里面增加配置：

prometheus.io/scrape:"true"

是否監(jiān)控就看是否在Service中開啟了這個開關(guān)。

以下是Prometheus配置過濾規(guī)則：

后續(xù)工作ServiceMesh使用：Istio調(diào)研及使用（灰度、限流、鏈路跟蹤、熔斷、降級）LXCFS解決容器CPU、內(nèi)存資源可見性問題有狀態(tài)應(yīng)用部署至Kubernetes：ES、Kafka等CRD在prometheus-operator的應(yīng)用Q&AQ：請問Kubernetes數(shù)據(jù)備份與恢復(fù)，這個是包括kubectl-proxy，etcd，網(wǎng)絡(luò)配置等嗎？如何進(jìn)行多集群下的數(shù)據(jù)備份？A：備份的其實(shí)就是etcd中的數(shù)據(jù)，我們網(wǎng)絡(luò)是用的Flannel，一些關(guān)鍵網(wǎng)段信息也是存在etcd中的，對于多集群來看的話，還是要針對數(shù)據(jù)存放對應(yīng)的etcd集群數(shù)據(jù)去進(jìn)行備份。

Q：請問一下業(yè)務(wù)日志太多，一天一個節(jié)點(diǎn)的業(yè)務(wù)日志有200G，怎么做日志收集及監(jiān)控告警？

A：一天一個節(jié)點(diǎn)200G的話，這個要看你們集群節(jié)點(diǎn)多不多，我們上百個節(jié)點(diǎn)，一個節(jié)點(diǎn)的量大概在100G左右，線上日志量都是幾十T的數(shù)據(jù)，用我分享的方案去落地應(yīng)該是沒問題的，ELK的整體性能還是非常不錯的，F(xiàn)ilebeat現(xiàn)在最高的性能分配是占用500MCPU，1G內(nèi)存，收集起來也是能應(yīng)對的，這個根據(jù)你的量再調(diào)整，監(jiān)控的話肯定就用Prometheus就好，官方都是有自動發(fā)現(xiàn)的配置，很便利，當(dāng)然如果你要對日志進(jìn)行分析，這塊就比較復(fù)雜了，可以通過ES接口去聚合數(shù)據(jù)，當(dāng)然日志的字段也要規(guī)范好。

Q：生產(chǎn)環(huán)境Kubernetes都用哪種網(wǎng)絡(luò)模式？

A：我們用的是Flannel，不過后續(xù)會考慮打算換成Calico，現(xiàn)在發(fā)現(xiàn)線上有一定網(wǎng)絡(luò)限制的需求，Calico的性能相對也會更好，但是維護(hù)的復(fù)雜度比較高，在集群節(jié)點(diǎn)多的情況下，要添加路由反射器，這個比較關(guān)鍵，而且網(wǎng)絡(luò)選型前一定對未來的規(guī)模有個規(guī)劃，規(guī)劃好使用的網(wǎng)段。

Q：請問生產(chǎn)環(huán)境中etcd的數(shù)據(jù)需要備份嗎？怎么備份？還有二進(jìn)制安裝etcd集群由3個節(jié)點(diǎn)增加到5個節(jié)點(diǎn)，需要重新生etcd證書后再重啟etcd服務(wù)嗎？增加節(jié)點(diǎn)重啟策略是一個一個節(jié)點(diǎn)依次重啟嗎？

A：建議備份，其實(shí)主要用到的就是etcd的snapshot功能，不復(fù)雜，看下我分享的腳本即可，擴(kuò)容etcd節(jié)點(diǎn)有證書的話需要修改server端證書host對應(yīng)的機(jī)器，官方的方法是要一臺一臺執(zhí)行的，線上etcd節(jié)點(diǎn)我做過測試，即使操作失誤都down掉的話也不會影響你現(xiàn)有服務(wù)的運(yùn)行，而且保證法定節(jié)點(diǎn)的存在就更好。

Q：你分享的Prometheus是Operator方式嗎？你的監(jiān)控數(shù)據(jù)是有經(jīng)過二次開發(fā)后作為標(biāo)準(zhǔn)格式輸出嗎？對于Nginx和Java監(jiān)控如何實(shí)現(xiàn)呀？

A：Prometheus沒有用Operator的方式，是用的官方的yaml文件創(chuàng)建的，我們線上Java服務(wù)居多，都是通過Spring官方的Prometheus插件就可以自定義監(jiān)控數(shù)據(jù)，Nginx的話我們還真的不多，這個估計你要用相應(yīng)的exporter就好，監(jiān)控數(shù)據(jù)是開發(fā)自定義上傳的，我們沒有做限制。

Q：Pod掛掉之后如何保留現(xiàn)場，比如做內(nèi)存Dump有什么好的方案沒？

A：我們這邊是這樣，對于健康檢查沒有添加Liveness的檢查，也是防止容器的重啟，尤其是在第一次項(xiàng)目上線，難免無法正常啟動，如果加了Liveness就會一直重啟，不太方便查問題，所以只加了Readiness，只是保證不影響線上訪問，對于生產(chǎn)中，Java項(xiàng)目遇到最多的就是OOM問題，這個我們也對Pod重啟的原因加了報警，至于Dump我們還沒這方面的操作，需要開發(fā)自行檢查了。

Q：傳統(tǒng)系統(tǒng)架構(gòu)如何改造成Kubernetes架構(gòu)？

A：這個問題有點(diǎn)寬泛呢，還是得看您這邊實(shí)際的場景，我覺得更多的也是得需要開發(fā)一起配合的，盡量保證服務(wù)模塊都能夠做到微服務(wù)話，不要耦合的太緊，您可以先搭建一個測試集群，然后從開發(fā)那邊找一個模塊進(jìn)行Docker化的轉(zhuǎn)換，然后一點(diǎn)一點(diǎn)再去試吧。

Q：是否有Ingresstcp/udp應(yīng)用的生產(chǎn)級網(wǎng)絡(luò)方案？

A：我們沒有用Ingress，我們的用法也算是一種比較簡單的用法，我們是把網(wǎng)關(guān)直接加入到Kubernetes集群中，這樣網(wǎng)關(guān)就可以調(diào)用到Kubernetes的Service，因?yàn)槲覀円跃W(wǎng)關(guān)為中心，做了一些安全及認(rèn)證功能，所以之前的網(wǎng)關(guān)必須要用到，而且加了Ingress相當(dāng)于多加了一層性能消耗，所以也沒有用，最后我們把之前部署在虛擬機(jī)上的網(wǎng)關(guān)也變成Docker化去部署到集群內(nèi)部。

Q：傳統(tǒng)數(shù)據(jù)庫負(fù)載過高時查詢緩慢，但是會有結(jié)果，Kubernetes架構(gòu)數(shù)據(jù)庫負(fù)載過高直接Pod重啟，導(dǎo)致沒有結(jié)果返回，請問應(yīng)該如何處理的？

A：我們集群還沒有跑數(shù)據(jù)庫這種有狀態(tài)的服務(wù)，但是聽您描述，還是得看看Pod重啟的具體原因，如果Pod都重啟了，理論上跑在機(jī)器上一定也會有問題，還是在上云之前做好充分的性能壓測，并且您可以考慮取消Liveness的健康檢查，只保留Readness訪問的檢查。

Q：采集日志過程中，fluentd或fluentbit通過讀取Node節(jié)點(diǎn)dockerlog目錄采集日志，該目錄包含了所有服務(wù)的日志。請問如何在output階段中根據(jù)Namespace和container_name創(chuàng)建Elasticsearch的index，并作為index的命名前綴？

A：首先不建議通過Docker目錄的方式采集，日志還是落盤到具體路徑為好，因?yàn)槲乙才龅竭^您這個困惑，因?yàn)镈ocker的目錄都是軟鏈接，而且當(dāng)Docker重啟后路徑會改變，當(dāng)然我們線上用的是Filebeat采集，不知道Fluentd能不能解決這個問題，由于是軟鏈接，很難用相對路徑，必須用絕對路徑采集到真正存放的那個目錄日志，我們對于esindex名稱的創(chuàng)建是通過日志提供的一個index名稱字段去匹配的，索引名稱會引用這個變量進(jìn)行區(qū)分不同的index。

Q：fileneatnode模式采集，多個相同Pod在同一節(jié)點(diǎn)情況下，如何映射日志目錄而不互相干擾，另外如何配置Filebeat做到Pod變動時的采集？

A：您這個情況我們也遇到過，多個Pod跑在同一個節(jié)點(diǎn)確實(shí)存在這個問題，因?yàn)槟愕膁eployyaml是定死的，很難處理這種情況，我們的解決方法是添加Pod的親和性，保證每個節(jié)點(diǎn)都盡量只跑一個Pod，當(dāng)然如果節(jié)點(diǎn)非常小的情況下，這種做法有一定問題，以生產(chǎn)使用上來看，我們最初多個Pod跑在一個節(jié)點(diǎn)同時寫一個文件的話也是還可接受。

Q：日志收集的sidectar模式具體是咋部署的。Filebeat和應(yīng)用部署在一個Pod里嗎？

A：對的，部署在一個Pod里，相當(dāng)于你的deployyaml里會有兩個image配置，一個是你的服務(wù)，另一個是Filebeat，具體的配置看下我的截圖，把這部分配置放到你的服務(wù)配置后面即可，但是就像我分享說的，這種方式可能會比較消耗資源，但是確實(shí)自定義比較方便，但也增加了yaml配置。

Q：我司測試環(huán)境搭建的Harbor版本是1.5，使用docker-compose來按照Harbor各個組件的依賴順序來啟動的，但是當(dāng)系統(tǒng)或者Docker重啟后，Harbor的容器就無法按照依賴順序來啟動，經(jīng)常會有容器啟動失敗。請問下這個該如何優(yōu)化呢？

A：其實(shí)你需要在Docker中注意一個參數(shù)，live-restore:true，這個參數(shù)很有用，你可能沒有添加，這個參數(shù)能保證在你維護(hù)重啟Docker的時候，還能保證不影響正在運(yùn)行的Docker容器，另外你可以對Harbor進(jìn)行監(jiān)控，如果down了的話大不了做個自動重啟的操作也不妨大礙。

Q：（1）Kubernetes平臺上線前有什么測試，如何測試？可以上線的依據(jù)？（2）常見互聯(lián)網(wǎng)架構(gòu)的業(yè)務(wù)，需要改造才可以在Kubernetes跑嗎，需要如何改造？有什么坑？（3）你們多個業(yè)務(wù)線都共用同一套Kubernetes？如何實(shí)現(xiàn)不會因?yàn)橐粋€業(yè)務(wù)的高峰影響其他業(yè)務(wù)？（4）有什么方案可以實(shí)現(xiàn)最大限度的不丟日志？

A：1.因?yàn)槲也皇菧y試，對于測試這塊可能干涉的不是很多，對于運(yùn)維來講可能更多的是比較關(guān)注上線之前的壓力測試，這塊會跟后續(xù)的穩(wěn)定性有很大關(guān)系；2.常見的架構(gòu)業(yè)務(wù)理論上改造應(yīng)該不需要很大，最主要的是解決Docker鏡像化，遇到的坑可能更多的是對于Dockerfile打鏡像理解的不好，導(dǎo)致一些啟動問題以及配置的丟失等等；3.我們是通過Namespace區(qū)分業(yè)務(wù)線，需要提前規(guī)劃好業(yè)務(wù)，指定的業(yè)務(wù)線只跑在對應(yīng)的機(jī)器上比較關(guān)鍵；4.我使用的ELK過程中還真的很少遇到過丟日志，只要你架構(gòu)足夠健壯應(yīng)該是沒什么問題的，另外ELK中一定要用消息隊(duì)列，降低你消息傳遞的壓力，保證每個組件都不要出現(xiàn)性能瓶頸，如果實(shí)在怕丟日志，可以讓Logstash在消費(fèi)的時候把消息落盤，ES也要合理配置好刷新的頻率以及內(nèi)存多大落盤等參數(shù)，提前做好各個組件的壓測是保障。

Q：你好，我是蔚來ES8車主，很高興看到蔚來的分享。我想了解下你們存儲的方案，之前聽說是用的Portworx，具體方案可以透露一下么？你們這個team在北京還是上海？用AWS的話有沒有考慮直接使用AWS的Kubernetes服務(wù)？ES也運(yùn)行在Kubernetes里嗎？

A：您好，我們team在北京，因?yàn)槲覀兊募哼€未上有狀態(tài)服務(wù)，所以暫時還未考慮分布式存儲的問題，這塊確實(shí)是很重要的一個環(huán)節(jié)，我們線上的服務(wù)基本也是通過S3去存儲一些數(shù)據(jù)使用，Portworx這個好像也出了很久了，當(dāng)時在還沒有Kubernetes的時候調(diào)研過，不過想大面積使用貌似是要花錢用商業(yè)版，建議還是用現(xiàn)在比較流行的Ceph可能會更好一些吧，我們還未用到AWS自己的Kubernetes服務(wù)，ES有運(yùn)行在Kubernetes里的業(yè)務(wù)，但是不是通過Operator部署，后端數(shù)據(jù)也沒用到分布式存儲，由于量不大，只是落在本地了，后期會進(jìn)一步調(diào)研Ceph以支持后期的有狀態(tài)服務(wù)的遷移。

Q：請問是否考慮過fluent-bit，目前Filebeat有沒有性能上的問題呢？

A：因?yàn)樵谔摂M機(jī)的時候我們就用的Filebeat，就沿用下去了，F(xiàn)il