本文由1月19日晚36Kr運(yùn)維開發(fā)工程師田翰明在Rancher技術(shù)交流群的技術(shù)分享整理而成乌询。微信搜索rancher2榜贴，添加Rancher小助手為好友，加入技術(shù)群妹田，實(shí)時(shí)參加下一次分享~
田翰明唬党，36Kr 運(yùn)維開發(fā)工程師，在 36Kr 主要負(fù)責(zé)運(yùn)維自動(dòng)化鬼佣，CI/CD 的建設(shè)驶拱，以及應(yīng)用容器化的推動(dòng)。
背景
36Kr是一家創(chuàng)立于2010年晶衷，專注于科技創(chuàng)投領(lǐng)域的媒體公司蓝纲，業(yè)務(wù)場(chǎng)景并不復(fù)雜，前端主要使用NodeJS進(jìn)行Render晌纫，移動(dòng)端有Android也有iOS税迷，后端服務(wù)幾乎全都由PHP來(lái)支持。使用PHP的主要原因是在最初進(jìn)行技術(shù)選型的時(shí)候發(fā)現(xiàn)锹漱，PHP進(jìn)行Web開發(fā)效率比較高箭养，后來(lái)就一直這樣延續(xù)下來(lái)了。
但是在后期哥牍，隨著業(yè)務(wù)的突飛猛漲毕泌，在程序設(shè)計(jì)中又沒(méi)能進(jìn)行解耦，就導(dǎo)致了許多服務(wù)耦合成了一個(gè)很臃腫的單體應(yīng)用砂心，邏輯耦合嚴(yán)重懈词，進(jìn)而導(dǎo)致了很多的性能問(wèn)題蛇耀，隨著問(wèn)題越來(lái)越難改辩诞，開發(fā)任務(wù)又越來(lái)越緊，就不得不往后拖纺涤，越往后拖留下的問(wèn)題就更難改译暂，形成了一個(gè)惡性循環(huán)，留下了很多的技術(shù)債撩炊，很不利于后續(xù)的開發(fā)任務(wù)外永，并且一旦出現(xiàn)了問(wèn)題，也很難追溯具體原因拧咳，所以在那時(shí)候經(jīng)常聽到一句話 “這是歷史遺留問(wèn)題” 伯顶。
B/S、C/S、單體應(yīng)用祭衩，這是一種很傳統(tǒng) 也很簡(jiǎn)單的架構(gòu)灶体，但是缺點(diǎn)也暴露無(wú)遺，所以經(jīng)常因?yàn)橐粋€(gè)業(yè)務(wù)邏輯的性能問(wèn)題掐暮，進(jìn)而影響到所有的業(yè)務(wù)蝎抽。在運(yùn)維側(cè)，運(yùn)維只能夠通過(guò)堆機(jī)器路克，升配置等策略來(lái)應(yīng)對(duì)樟结，投入了很多的機(jī)器成本和人力成本，但是收效甚微精算，很是被動(dòng)瓢宦。
這種情況已經(jīng)是迫在眉睫了，終于技術(shù)團(tuán)隊(duì)決定使用 Java 語(yǔ)言進(jìn)行重構(gòu)灰羽，將單體應(yīng)用進(jìn)行微服務(wù)化拆解刁笙，徹底改變這種因?yàn)閱误w應(yīng)用故障而導(dǎo)致生產(chǎn)環(huán)境出現(xiàn)大范圍的故障。
需求分析 + 選型
在重構(gòu)計(jì)劃開始一段時(shí)間后谦趣，為了節(jié)省虛機(jī)資源疲吸，我們一臺(tái)虛機(jī)上運(yùn)行了多個(gè) Java 程序，但是因?yàn)闆](méi)有資源隔離和靈活的調(diào)度系統(tǒng)前鹅，其實(shí)也會(huì)導(dǎo)致一些資源的浪費(fèi)摘悴。并且在高并發(fā)場(chǎng)景下，偶爾會(huì)有資源搶占導(dǎo)致一個(gè)應(yīng)用影響另一個(gè)應(yīng)用的情況舰绘。為此蹂喻，我們運(yùn)維專門開發(fā)了一套自動(dòng)化部署系統(tǒng)，系統(tǒng)內(nèi)包括部署捂寿、監(jiān)控檢測(cè)口四、部署失敗回滾、重啟等基礎(chǔ)功能秦陋。
隨著當(dāng)時(shí) K8s 的風(fēng)靡蔓彩，還有 Rancher 2.x 的發(fā)布，我們逐漸發(fā)現(xiàn)驳概，我們所面臨的這些問(wèn)題赤嚼，它們基本都能解決，比如資源隔離顺又、deployment 的控制器模型更卒、靈活的調(diào)度系統(tǒng)，這些都有稚照，這就是最好的自動(dòng)化部署系統(tǒng)啊蹂空，于是我們運(yùn)維側(cè)俯萌，也開始決定向容器化進(jìn)軍。
在選型上上枕，因?yàn)槲覀兊姆?wù)基本都在阿里云上面绳瘟，所以第一個(gè)想到的是阿里云。時(shí)因?yàn)槲覀兒腿A為有一些業(yè)務(wù)的往來(lái)姿骏，所以華為的 CCE 也作為了備選糖声，但是考慮到我們的服務(wù)資源全部在阿里云上，這個(gè)遷移成本實(shí)在太大了分瘦，所以就沒(méi)再考慮華為云蘸泻。
我們一開始使用過(guò)Rancher 1.6，但是只是用來(lái)管理主機(jī)上部署的原生 Docker嘲玫。也因此對(duì)Rancher的產(chǎn)品產(chǎn)生了很大的好感悦施。
需求方面，因?yàn)橐档臀覀冄邪l(fā)人員的學(xué)習(xí)成本去团，容器管理平臺(tái)的易用性十分重要抡诞。此外，K8s 的基礎(chǔ)功能是必須的土陪，因?yàn)?K8s 還在高速發(fā)展階段昼汗，所以能需要夠隨時(shí)跟上更新，有安全漏洞后也需要第一時(shí)間進(jìn)行更新打補(bǔ)丁鬼雀，同時(shí)還要有基本的權(quán)限控制顷窒。而且我們公司內(nèi)部沒(méi)有專門的K8S團(tuán)隊(duì)，運(yùn)維人員也只有2位源哩，所以如果能夠有專業(yè)人員進(jìn)行技術(shù)上的交流鞋吉，發(fā)生了問(wèn)題可以有專業(yè)的服務(wù)團(tuán)隊(duì)來(lái)協(xié)助也十分重要。
綜上励烦，基本上就是 Rancher 完勝谓着，UI 做得非常友好，開發(fā)人員能夠很快上手坛掠，更新迭代速度也非成廾快，發(fā)現(xiàn)漏洞后也會(huì)有詳細(xì)的補(bǔ)丁方案却音，認(rèn)證策略也完美支持我們的 OpenLDAP 協(xié)議改抡，能夠?qū)﹂_發(fā)矢炼、測(cè)試系瓢、運(yùn)維人員進(jìn)行不同權(quán)限控制，并且也是第一家做到支持多云環(huán)境的句灌，方便以后我們做跨云的方案夷陋。
我們這次容器化的過(guò)程欠拾，主要經(jīng)歷了以下幾個(gè)因素的考慮，今天我就來(lái)和大家分享我們?cè)?Rancher 上的一些實(shí)踐骗绕，希望能給大家?guī)?lái)幫助：
應(yīng)用的容器化改造
Rancher 的高可用性
容器的運(yùn)維
多租戶隔離
應(yīng)用的容器化改造
因?yàn)槲覀兊拈_發(fā)人員藐窄，有相當(dāng)一部分是沒(méi)有接觸過(guò)容器的，為了能對(duì)開發(fā)人員更友好一些酬土，我們的鏡像分成了兩層荆忍，主要的 Dockerfile 編寫是由我們運(yùn)維人員來(lái)編寫的，而開發(fā)人員代碼倉(cāng)庫(kù)里的 Dockerfile 是最簡(jiǎn)單的撤缴，基本上只有代碼拷貝的過(guò)程和一些必傳的變量刹枉，具體可以參考以下示例：
## 這是運(yùn)維人員維護(hù)的 Dockerfile 示例
## 本示例僅做參考
FROM alpine:3.8
MAINTAINER yunwei <yunwei@36kr.com>
WORKDIR /www
RUN mv /etc/apk/repositories /etc/apk/repositories.bak \
&& echo "http://mirrors.aliyun.com/alpine/v3.8/main/" >> /etc/apk/repositories \
&& apk update && apk upgrade
RUN apk --no-cache add ca-certificates wget && \
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub && \
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.29-r0/glibc-2.29-r0.apk && \
apk add glibc-2.29-r0.apk && rm -f glibc-2.29-r0.apk
RUN apk add -U --no-cache \
bash \
sudo \
tzdata \
drill \
iputils \
curl \
busybox-extras \
&& rm -rf /var/cache/apk/* \
&& ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
COPY java-jar/jdk1.8.0_131 /usr/local/jdk1.8.0_131
ENV TZ="Asia/Shanghai"
ENV JAVA_HOME=/usr/local/jdk1.8.0_131
ENV CLASSPATH=$JAVA_HOME/bin
ENV PATH=.:$JAVA_HOME/bin:$PATH
ENV JAVA_OPTS="-server -Xms1024m -Xmx1024m"
CMD java -jar $JAVA_OPTS -Dserver.port=8080 server.jar
=======================================
## 這是開發(fā)人員維護(hù)的 Dockerfile 的示例
FROM harbor.36kr.com/java:v1.1.1
MAINTAINER developer <developer@36kr.com>
ADD web.jar ./server.jar
可以看到，開發(fā)人員所維護(hù)的 Dockerfile 可以說(shuō)相當(dāng)簡(jiǎn)單了屈呕，這大大的降低了開發(fā)人員維護(hù)的難度微宝。
另外，因?yàn)闃?gòu)建產(chǎn)物的大小虎眨，很大程度上決定了部署時(shí)間的長(zhǎng)短蟋软，所以我們使用了號(hào)稱最小的鏡像——alpine，alpine 有很多的優(yōu)點(diǎn)：
體積小
有包管理器嗽桩、有豐富的依賴
大廠的支持岳守，包含 Docker 公司在內(nèi)的多家大廠官方使用
但是他有一個(gè)缺點(diǎn)，alpine 上并沒(méi)有 glibc 庫(kù)碌冶，他所使用的是一個(gè) musl libc 的小體積替代版棺耍，但是 Java 是必須依賴的 glibc 的，不過(guò)早就有大神了解了這點(diǎn)种樱，在 GitHub 上已經(jīng)提供了預(yù)編譯的 glibc 庫(kù)蒙袍，名字為alpine-pkg-glibc，裝上這個(gè)庫(kù)就可以完美支持 Java嫩挤，同時(shí)還能夠保持體積很小害幅。
Rancher 的高可用性
安裝 Rancher 的方式有兩種：?jiǎn)喂?jié)點(diǎn)安裝和高可用集群安裝。一般單節(jié)點(diǎn)安裝僅適用于測(cè)試或者 demo 環(huán)境岂昭，所以要正式投入使用的話以现，還是推薦高可用集群的安裝方式。
我們一開始測(cè)試環(huán)境就使用了單節(jié)點(diǎn)安裝的方式约啊，后來(lái)因?yàn)?Rancher Server 那臺(tái)機(jī)器出現(xiàn)過(guò)一次重啟邑遏，就導(dǎo)致了測(cè)試環(huán)境故障，雖然備份了恰矩，但是還是丟失了少量數(shù)據(jù)记盒，最后我們測(cè)試環(huán)境也采用了 HA 高可用部署，整個(gè)架構(gòu)如下圖所示外傅。
Rancher Server 我是采用的 RKE 安裝纪吮，并且為了防止阿里云出現(xiàn)區(qū)域性的故障俩檬，我們將 Rancher Server 的三臺(tái)機(jī)器，部署在了兩個(gè)可用區(qū)碾盟，Rancher Server-001棚辽、003 在北京的 H 區(qū)、Rancher Server-002 在北京的 G 區(qū)冰肴。
負(fù)載均衡屈藐，我們采用的是阿里云的 SLB，也是采購(gòu)的主備型實(shí)例熙尉，防止單點(diǎn)故障耳鸯，因?yàn)?Rancher 必須使用 SSL 證書撇寞，我們也有自己的域名證書，為了方便在 SLB 上進(jìn)行 SSL 證書的維護(hù)，我們使用的是 7 層協(xié)議五督，在 SLB 上做的 SSL 終止押逼，Rancher Server 的架構(gòu)圖可以參考下圖：
下游集群箫措，也就是用來(lái)承載業(yè)務(wù)的 K8s 集群塑陵，我們也是一半一半，在阿里云的兩個(gè)可用區(qū)進(jìn)行部署的谭贪，需要注意的是境钟，為了保證兩個(gè)區(qū)的網(wǎng)絡(luò)時(shí)延 <= 15 ms，這就完成了一個(gè)高可用的災(zāi)備架構(gòu)俭识。
備份方面慨削，我們也使用了阿里云 ECS 快照 + ETCD S3 協(xié)議備份到了阿里云的 OSS 對(duì)象存儲(chǔ)兩種方案，確保出現(xiàn)故障后套媚，能夠及時(shí)恢復(fù)服務(wù)缚态。
部署的詳細(xì)教程可以參考 Rancher 官方文檔。
容器的運(yùn)維
容器的運(yùn)維堤瘤，這里主要指容器的日志收集和容器監(jiān)控玫芦，容器監(jiān)控方面呢，Rancher 自帶了 Prometheus 和 Grafana本辐，而且和 Rancher 的 UI 有一些整合桥帆，就非常的方便，所以監(jiān)控方面我就不展開講了慎皱，我主要說(shuō)一說(shuō)日志收集老虫。
在 K8s 里，日志的收集相比傳統(tǒng)的物理機(jī)茫多、虛機(jī)等方式要復(fù)雜一些祈匙，因?yàn)?K8s 所提供的是動(dòng)態(tài)的環(huán)境，像綁定 hostpath 這種方式是不適用的地梨，我們可以通過(guò)以下這個(gè)表格直觀的對(duì)比一下：
可以看到菊卷，K8s 需要采集的日志種類比較多缔恳，而容器化的部署方式宝剖，在單機(jī)器內(nèi)的應(yīng)用數(shù)是很高的洁闰，而且都是動(dòng)態(tài)的，所以傳統(tǒng)的采集方式是不適用于 K8s 的万细。
目前 K8s 的采集方式大體可以分為兩種扑眉，被動(dòng)采集和主動(dòng)推送。
主動(dòng)推送一般有 DockerEngine 和 業(yè)務(wù)直寫兩種方式：DockerEngine 是 Docker 的 LogDriver 原生自帶的赖钞，一般只能收集 STDOUT腰素、一般不建議使用；而業(yè)務(wù)直寫雪营，則需要在應(yīng)用里集成日志收集的 SDK弓千，通過(guò) SDK 直接發(fā)送到收集端，日志不需要落盤献起，也不需要部署Agent洋访，但是業(yè)務(wù)會(huì)和 SDK 強(qiáng)綁定，靈活性偏低谴餐，建議對(duì)于日志量較大姻政，或者對(duì)日志有定制化要求的場(chǎng)景使用。
被動(dòng)推送是采用部署日志收集 Agent 進(jìn)行采集的岂嗓，有兩種方式汁展，一種是 Daemonset 每個(gè)機(jī)器節(jié)點(diǎn)上部署一個(gè) Agent，還有一種 Sidecar厌殉，每個(gè) Pod 以 Sidecar 的形式部署一個(gè) Agent食绿。
Sidecar 部署方式比較消耗資源，相當(dāng)于每個(gè) Pod 都有一個(gè) agent公罕，但是這種方式 靈活性以及隔離性較強(qiáng)炫欺，適合大型的 K8s 集群或者作為 PaaS 平臺(tái)為業(yè)務(wù)方提供服務(wù)的群使用，Daemonset 部署方式熏兄，資源消耗較小品洛，適合功能單一、業(yè)務(wù)不多的集群摩桶。
結(jié)合我們自身的場(chǎng)景桥状，屬于小規(guī)模集群，并且業(yè)務(wù)也不算多硝清，我們選擇了 Daemonset 的部署方式辅斟，在測(cè)試環(huán)境，我們經(jīng)過(guò)調(diào)研選擇了阿里開源的一個(gè)日志收集組件log-pilot GitHub 地址是：github.com/AliyunContainerService/log-pilot 芦拿，通過(guò)結(jié)合 Elasticsearch士飒、Kibana 等算是一個(gè)不錯(cuò)的 K8s 日志解決方案查邢。
因?yàn)槲覀兊姆?wù)器都在阿里云上，我們運(yùn)維人員比較少只有2位酵幕，沒(méi)有精力再去維護(hù)一個(gè)大型的分布式存儲(chǔ)集群扰藕，所以我們的業(yè)務(wù)日志選擇存儲(chǔ)在了阿里云的日志服務(wù)，所以在生產(chǎn)環(huán)境芳撒，我們的 K8s 也使用了阿里云日志服務(wù)邓深，目前單日日志 6億+ 沒(méi)有任何問(wèn)題。
使用阿里云收集日志呢笔刹，你需要開通阿里云的日志服務(wù)芥备，然后安裝 Logtail 日志組件alibaba-log-controller Helm，這個(gè)在官方文檔里有安裝腳本舌菜，我把文檔鏈接貼在下面萌壳，在安裝組件的過(guò)程中會(huì)自動(dòng)創(chuàng)建aliyunlogconfigs CRD，部署alibaba-log-controller的Deployment日月，最后以 DaemonSet 模式安裝 Logtail袱瓮。然后你就可以在控制臺(tái)，接入你想要收集的日志了山孔。安裝完以后是這樣的：
Logtail支持采集容器內(nèi)產(chǎn)生的文本日志懂讯，并附加容器的相關(guān)元數(shù)據(jù)信息一起上傳到日志服務(wù)。Kubernetes文件采集具備以下功能特點(diǎn)：
只需配置容器內(nèi)的日志路徑台颠，無(wú)需關(guān)心該路徑到宿主機(jī)的映射
支持通過(guò)Label指定采集的容器
支持通過(guò)Label排除特定容器
支持通過(guò)環(huán)境變量指定采集的容器
支持通過(guò)環(huán)境變量指定排除的容器
支持多行日志（例如java stack日志）
支持Docker容器數(shù)據(jù)自動(dòng)打標(biāo)簽
支持Kubernetes容器數(shù)據(jù)自動(dòng)打標(biāo)簽
如果你想了解更多褐望，可以查看阿里云日志服務(wù)的官方文檔：
https://help.aliyun.com/document_detail/157317.html?spm=a2c4g.11186623.6.621.193c25f44oLO1V
容器的多租戶隔離
我這里所講的，主要指的是企業(yè)內(nèi)部用戶的多租戶隔離串前，而不是指的 SaaS瘫里、KaaS 服務(wù)模型的多租戶隔離。
在權(quán)限方面荡碾，因?yàn)槲宜緦?duì)于權(quán)限的管控較嚴(yán)格谨读，而 Rancher 恰好提供了非常方便的基于 集群、項(xiàng)目坛吁、命名空間等多個(gè)粒度的權(quán)限控制劳殖，并且支持我司基于 OpenLDAP 的認(rèn)證協(xié)議，非常便于管理拨脉，我可以給不同項(xiàng)目組的開發(fā)哆姻、測(cè)試人員開通相對(duì)應(yīng)的 集群/項(xiàng)目/命名空間的權(quán)限。
比如下圖玫膀，我可以給集群添加用戶矛缨、也可以給某個(gè) Project 添加用戶，并且可以指定幾個(gè)不同的角色，甚至可以自定義角色箕昭。
比如場(chǎng)景1：我可以給 項(xiàng)目組長(zhǎng)灵妨，分配開發(fā)環(huán)境集群->項(xiàng)目1 所有者(Owner)權(quán)限，然后項(xiàng)目組長(zhǎng)可以自由控制給本項(xiàng)目添加他的成員落竹，并分配相應(yīng)權(quán)限泌霍。
場(chǎng)景2：我可以給 測(cè)試經(jīng)理，分配測(cè)試集群的所有者(Owner)權(quán)限筋量，由測(cè)試經(jīng)理來(lái)分配烹吵，誰(shuí)來(lái)負(fù)責(zé)哪個(gè)項(xiàng)目的測(cè)試部署碉熄，以及開發(fā)人員只能查看日志等桨武。
在資源方面，一定要進(jìn)行容器的資源配額設(shè)置锈津，如果不設(shè)置資源限額呀酸，一旦某一個(gè)應(yīng)用出現(xiàn)了性能問(wèn)題，將會(huì)影響整個(gè) node 節(jié)點(diǎn)上的所有應(yīng)用琼梆，K8s 會(huì)將出現(xiàn)問(wèn)題的應(yīng)用調(diào)度到其他 node 上性誉，如果你的資源不夠，將會(huì)出現(xiàn)整個(gè)系統(tǒng)的癱瘓茎杂，導(dǎo)致雪崩错览。
Java 應(yīng)用的資源配額限制也有一個(gè)坑，因?yàn)槟J(rèn) Java 是通過(guò) /proc/meminfo 來(lái)獲取內(nèi)存信息的煌往，默認(rèn) JVM 會(huì)使用系統(tǒng)內(nèi)存的 25% 作為 Max Heap Size倾哺，但是容器內(nèi)的/proc/meminfo是宿主機(jī)只讀模式掛載到容器里的，所以采取默認(rèn)值是行不通的刽脖，會(huì)導(dǎo)致應(yīng)用超過(guò)容器限制的內(nèi)存配額后被OOM羞海，而健康檢查又將服務(wù)重啟，造成應(yīng)用不斷的重啟曲管。
那是不是通過(guò)手動(dòng)參數(shù)設(shè)置 JVM 內(nèi)存 = 容器內(nèi)存限額呢却邓？不行！因?yàn)?JVM消耗的內(nèi)存不僅僅是 Heap院水，因?yàn)?JVM 也是一個(gè)應(yīng)用腊徙，它需要額外的空間去完成它的工作，你需要配置的限額應(yīng)該是 Metaspace + Threads + heap + JVM 進(jìn)程運(yùn)行所需內(nèi)存 + 其他數(shù)據(jù) 關(guān)于這塊檬某，因?yàn)樯婕暗降膬?nèi)容較多撬腾，就不進(jìn)行展開，感興趣的同學(xué)可以自己去搜索 一下橙喘。
總 結(jié)
因?yàn)槲覀兊臉I(yè)務(wù)場(chǎng)景并不復(fù)雜时鸵，所以我們的容器化之路，其實(shí)走的也相對(duì)來(lái)講蠻順暢的，我們的運(yùn)維人員很少饰潜，只有 2 位初坠，所以我們也沒(méi)有太多的時(shí)間精力去維護(hù)太多的自建系統(tǒng)，我們使用了很多的阿里云產(chǎn)品彭雾，包括 Rancher碟刺，他很方便的部署方式，友好的 UI薯酝，包括集成好的監(jiān)控等等半沽，在容器化之路上給了我們很大的信心。
我們使用構(gòu)建兩層鏡像的方式吴菠，降低了開發(fā)人員的學(xué)習(xí)復(fù)雜度者填。使用了小體積鏡像 alpine + 預(yù)編譯 glibc 減小了鏡像體積。提高了部署的時(shí)間做葵，在架構(gòu)上占哟，我們采用了阿里云雙區(qū)機(jī)房的災(zāi)備的架構(gòu)，以及完備的備份方案酿矢。使用 Daemonset 部署的日志收集組件榨乎，收集到阿里云日志服務(wù)，支撐我們 6億/日的日志系統(tǒng)瘫筐。Rancher 還提供給了我們深度集成的監(jiān)控系統(tǒng)蜜暑、多租戶隔離等。還有我們自己踩坑 踩出來(lái)的資源配額設(shè)置策肝。
其實(shí)容器化并不復(fù)雜肛捍，如果沒(méi)有 K8s，我們需要自己構(gòu)建健康監(jiān)測(cè)系統(tǒng)驳糯、發(fā)版系統(tǒng)篇梭、維護(hù)不同的主機(jī)環(huán)境，不能細(xì)粒度的進(jìn)行資源劃分酝枢，不能更有效的利用計(jì)算資源恬偷，運(yùn)維的工作主要是什么？在我看來(lái)其實(shí)就是 節(jié)約成本帘睦、提高效率袍患。虛擬化、自動(dòng)化竣付、智能化诡延、高性能、高可用古胆、高并發(fā) 等等肆良，這些無(wú)一不是圍繞著成本和效率這兩個(gè)詞筛璧，而 K8s 其實(shí)已經(jīng)幫我們都做好了，而像 Rancher 這種編排平臺(tái)又幫我們降低了 K8s 的學(xué)習(xí)復(fù)雜度惹恃，所以你要做的就是加入 K8s夭谤，好了，到這里這次的分享就結(jié)束了巫糙。感謝~
社區(qū)QA
Q1：K8S在生產(chǎn)環(huán)境的高可用存儲(chǔ)方案有推薦嗎朗儒？
A1：存儲(chǔ)方案沒(méi)有標(biāo)準(zhǔn)答案，我們主要使用阿里云参淹，所以用的是阿里云的塊存儲(chǔ)醉锄，比較常見的方案還有 Ceph、GlusterFS浙值、Portworx恳不、OpenEBS 等，他們各有優(yōu)劣亥鸠，需結(jié)合自己的業(yè)務(wù)需求進(jìn)行選擇
Q2：灰度發(fā)布妆够，Kubernetes網(wǎng)絡(luò)流量可以通過(guò)服務(wù)網(wǎng)格分流實(shí)現(xiàn)網(wǎng)絡(luò)層面的分發(fā)识啦，但是涉及到應(yīng)用大版本的更新時(shí)候负蚊，涉及到數(shù)據(jù)庫(kù)結(jié)構(gòu)的變更的時(shí)候，如何實(shí)現(xiàn)灰度發(fā)布颓哮？
A2：沒(méi)有遇到過(guò)這個(gè)場(chǎng)景家妆，不過(guò)提供一個(gè)思路，可以準(zhǔn)備兩套數(shù)據(jù)庫(kù)冕茅，網(wǎng)絡(luò)分流也可以分流到不通數(shù)據(jù)庫(kù)伤极，具體需要你自己驗(yàn)證一下是否可行
要分清楚這是兩層，一層是邏輯層姨伤，一層是數(shù)據(jù)層哨坪，不能混為一談
Q3：Pipeline是用什么做的？Pipeline下乍楚，如何處理同一個(gè)分支当编，需要并行測(cè)試多個(gè)版本的場(chǎng)景？我用Rancher的Pipeline徒溪，局限性比較大忿偷，就是同一個(gè)分支無(wú)法并行多套進(jìn)行測(cè)試。命名空間在使用臊泌，但是同一個(gè)分支下鲤桥，命名空間是寫在.rancher.yml下的，所以無(wú)法區(qū)分渠概，Rancher的Pipeline不能在外面注入變量進(jìn)行區(qū)分茶凳。
A3：Rancher 的 Pipline 目前還是有一些不夠靈活，我們使用的是自建 Jenkins 做 Pipeline 的，并行測(cè)試贮喧，可以用命名空間等隔離策略進(jìn)行隔離顷牌，或者準(zhǔn)備多套測(cè)試環(huán)境
Q4: 你們運(yùn)維的Dockerfile和開發(fā)的Dockerfile是怎么合并的？
A4：開發(fā)的 Dockerfile 是 From 運(yùn)維的 Dockerfile
Q5：你們k8s的漏洞掃描用的什么工具塞淹？一般什么級(jí)別的鏡像漏洞需要進(jìn)行修復(fù)窟蓝？
A5：暫時(shí)沒(méi)有使用漏掃工具，我們主要根據(jù) Rancher 企業(yè)服務(wù)通知的修復(fù)建議進(jìn)行修復(fù)
Q6: 就是比如說(shuō)從外網(wǎng)饱普，通過(guò)service ip能夠登陸并且管理容器运挫。想實(shí)現(xiàn)這一步必須通過(guò)將service ip暴露出來(lái)，然后這個(gè)service ip怎么暴露出來(lái)套耕？麻煩解答一下谁帕。
A6：如果需求是管理容器，其實(shí)可以使用 Rancher 的用戶權(quán)限控制冯袍，讓某一用戶擁有某一容器的權(quán)限匈挖，暴露 service ip 到公網(wǎng)，讓用戶管理容器是無(wú)法實(shí)現(xiàn)的
Q6 : 好的康愤，謝謝儡循，我還有一點(diǎn)不明白，這個(gè)service ip有什么辦法能讓他暴露出來(lái)呢征冷？你意思是說(shuō)讓不同的用戶通過(guò)rancher平臺(tái)去管理不同的容器嗎择膝？麻煩再給解答一下，謝謝检激。
A6：可以使用 NodePort 暴露肴捉，通過(guò) Node ip 和 端口進(jìn)行訪問(wèn)，或者使用 公有云的負(fù)載均衡產(chǎn)品
Q6 : 我不是這個(gè)意思叔收，我是想把service ip暴露出來(lái)齿穗，不只單單想通過(guò)集群內(nèi)部訪問(wèn)。
A6：service ip 本來(lái)就是 K8s 內(nèi)部的饺律，暴露不了窃页，只能轉(zhuǎn)發(fā)
Q7: 為何沒(méi)有放在3個(gè)可用區(qū)，如果可用區(qū)H掛掉蓝晒，是否會(huì)導(dǎo)致集群不可訪問(wèn)腮出？
A7：3個(gè)可用區(qū)當(dāng)然也是可以的，Rancher HA 架構(gòu)芝薇，只要有一個(gè) Server 可用就沒(méi)有關(guān)系
Q8：請(qǐng)教下你們多套開發(fā)測(cè)試環(huán)境的pipeline是怎么樣的流程呢 (差異化)胚嘲？有使用helm template嗎，方便講解下更多細(xì)節(jié)么洛二？
A8：目前是通過(guò) Jenkins 部署參數(shù)馋劈，部署的時(shí)候可以選擇 命名空間攻锰、環(huán)境標(biāo)識(shí)、分支等妓雾，通過(guò) sed 修改 template
Q9：請(qǐng)問(wèn)你們的devops流是怎樣的呢娶吞？一個(gè)環(huán)境對(duì)應(yīng)一個(gè)docker鏡像，還是說(shuō)test pre prd共用一個(gè)docker鏡像呢械姻？如果是一個(gè)docker鏡像共用test pre prd的話是怎么做的呢(比如不同環(huán)境的配置以及開發(fā)的協(xié)‘同開發(fā)流)妒蛇？
A9：我們是用的同一個(gè)鏡像，部署時(shí)通過(guò)選擇不同的環(huán)境標(biāo)識(shí)參數(shù)楷拳，程序會(huì)自動(dòng)注入不同環(huán)境的配置绣夺，需要開發(fā)進(jìn)行一些相應(yīng)的配置修改
Q10:不大懂容器的資源限制該如何配置，自己配置了感覺不起作用
A10：Rancher 可以在項(xiàng)目欢揖、命名空間陶耍、Pod 三個(gè)粒度進(jìn)行設(shè)置，優(yōu)先級(jí)相反
