Kubernetes現(xiàn)在，就讓我們登錄到一臺(tái)Linux機(jī)器里，執(zhí)行一條如下所示令代碼1$pstree-代碼代碼123456789|`-|`-|`- |-{in:imuxsock)S|`-{rs:main||||它的進(jìn)程組ID（ProcessGroupID,PGID）比如，這里有一個(gè)叫作rsyslogd的程序，它負(fù)責(zé)的是Linux操作系統(tǒng)里的日志處理?？梢钥催@些進(jìn)程相互協(xié)作，共同完成rsyslogd程序的職責(zé)。對(duì)于操作系統(tǒng)來說，這樣的進(jìn)程組更方便管理。舉個(gè)例子，LinuxKubernetesKubernetes項(xiàng)目之所以要這么做的原因，我面介紹Kubernetes和Borg的關(guān)系時(shí)曾經(jīng)提到過：在Borg項(xiàng)目的開發(fā)和實(shí)踐過程中，公司的工程師們發(fā)現(xiàn)，他們部署的應(yīng)用，往我還是以前面的rsyslogd為例子。已知rsyslogd由三個(gè)進(jìn)程組成：一個(gè)imklog模塊，一個(gè)imuxsockrsyslogdmain器上，否則，它們之間基于Socket的通信和文件交換，都會(huì)出現(xiàn)問題。須被分別制作成三個(gè)不同的容器。而在這三個(gè)容器運(yùn)行的時(shí)候，它們設(shè)置的內(nèi)存都是1而是指容器沒有管理多個(gè)進(jìn)程的能力。這是因?yàn)槿萜骼颬ID=1的進(jìn)程就是應(yīng)用本身，其他的進(jìn)程都是這個(gè)PID=1進(jìn)程的子進(jìn)程?？墒?，用戶編寫的應(yīng)用，并不能夠像正常操作系統(tǒng)里的init進(jìn)程或者systemd你的應(yīng)用是一個(gè)JavaWeb程序（PID=1），然后你執(zhí)行dockerexec在啟Nginx（PID=3）Nginx假設(shè)我們的Kubernetes集群上有兩個(gè)節(jié)點(diǎn)：node-13GB可用內(nèi)存，node-22.5DockerSwarmrsyslogd同一臺(tái)機(jī)器上，我就必須在另外兩個(gè)容器上設(shè)置一個(gè)affinity=main（與main容器有親密性）的約束，即：它們倆必須和main容器運(yùn)行在同一臺(tái)機(jī)器上。然后，我順序執(zhí)行：“dockerrunmain”“dockerrunimklog”和“dockerSwarmmainimklog隊(duì)并被調(diào)度到了node-2上（這個(gè)情況是完全有可能的）。imuxsockSwarm：node-20.5GBimuxsockaffinity=mainimuxsock器又只能運(yùn)行在node-2上。比如，Mesos（resourcehoarding）的機(jī)制，會(huì)在所有設(shè)置了約束的任務(wù)都達(dá)到時(shí)，才開始對(duì)它們統(tǒng)一進(jìn)行調(diào)度。而在 KubernetesPodKubernetes度單位。這就意味著，KubernetesPodimklog、imuxsockmain函數(shù)主進(jìn)程這樣的三個(gè)容器，正是一個(gè)典型的由三個(gè)容Pod。Kubernetes3GBnode-1點(diǎn)進(jìn)行綁定，而根本不會(huì)考慮node-2。特征包括但不限于：互相之間會(huì)發(fā)生直接的文件交換、使用localhost或者Socket文件進(jìn)行本地通信、會(huì)發(fā)生非常頻繁的調(diào)用、需要共享某些LinuxNamespace（比如，一個(gè)容器要加入另一個(gè)容器的NetworkNamespace）等等。這也就意味著，并不是所有有“關(guān)系”的容器都屬于同一個(gè)Pod。比如，PHP應(yīng)用容器和兩個(gè)Pod。對(duì)于初學(xué)者來說，一般都是先學(xué)會(huì)了用Docker這種單容器的工具，才會(huì)開始接觸Pod。Pod沒錯(cuò)，如果只是處理“超親密關(guān)系”這樣的調(diào)度問題，有Borg和 Kubernetes為了理解這一層含義，我就必須先給你介紹一下Pod的實(shí)現(xiàn)原理。PodCgroups，而并不存在一個(gè)所謂的Pod的邊界或者環(huán)境那么，Pod一個(gè)Volume。A、BPod，不就是等同于一個(gè)容器（A）共享另外一個(gè)容器（容器B）的網(wǎng)絡(luò)和Volume的玩兒法么？這好像通過dockerrun--net--volumes-from這樣令就能實(shí)現(xiàn)嘛，比如代碼1$dockerrun--net=B--volumes-from=B--name=Aimage-ABAPodKubernetesPodInfra在這個(gè)Pod中，Infra容器都是第一個(gè)被創(chuàng)建的容器，而其他用戶定義的容器，則通過JoinNetworkNamespace的方式，與Infra容器關(guān)聯(lián)在一起。這樣的組織關(guān)系，可以用下面Pod里有兩個(gè)用戶容器AB，還有一個(gè)Infra的容器，解壓后的大小也只有100~200KB左右。InfraHoldNetworkNamespaceInfra這也就意味著，對(duì)于Pod里的容器ABlocalhostInfraPodIPPodNetworkNamespaceIP地址；當(dāng)然，其他的所有網(wǎng)絡(luò)資源，都是一個(gè)Pod一份，并且被該P(yáng)od中的所有容器共享；Pod的生命周期只跟Infra容器一致，而與容器A和B無關(guān)。而對(duì)于同一個(gè)Pod里面的所有用戶容器來說，它們的進(jìn)出流量，也可以認(rèn)為都是通過Infra容PodNetworkNamespace，而不是每一個(gè)用戶容器如何使用你的網(wǎng)絡(luò)Infra容器鏡像的rootfs里幾乎什么都沒有，沒有你隨意發(fā)揮的空間。當(dāng)然，這同時(shí)也意味著你的網(wǎng)絡(luò)插件完全不必關(guān)心用戶容器的啟動(dòng)與否，而只需要關(guān)注如何配置Pod，也就是Infra的NetworkNamespace即可。VolumeKubernetesVolume都設(shè)計(jì)在Pod層級(jí)即可。這樣，一個(gè)Volume對(duì)應(yīng)的宿主機(jī) 對(duì)于Pod來說就只有一個(gè)，Pod里的容器只要掛載這個(gè)Volume，就一定可以共享這個(gè)Volume對(duì)應(yīng)的宿主機(jī) 代碼代碼123456789apiVersion:kind:Podname:two-:-name:shared-path:/data--name:nginx-image:nginxname:shared-mountPath:/usr/share/nginx/htmlname:debian-containerimage:debianname:shared-datamountPath:/pod-datacommand:args:["-c",ofromthedebian>/pod-在這個(gè)例子中，debian-container和nginx-container都掛載了shared-data這個(gè)Volume。而shared-data是hostPath類型。所以，它對(duì)應(yīng)在宿主機(jī)上的 這就是為什么，nginx-container可以從它的/usr/share/nginx/html container生成的index.html文件的原因。Pod能并不相關(guān)的應(yīng)用時(shí)，應(yīng)該優(yōu)先考慮它們是不是更應(yīng)該被描述成一個(gè)Pod里的多個(gè)容器。第一個(gè)最典型的例子是：WAR包與Web服務(wù)器。我們現(xiàn)在有一個(gè)JavaWeb應(yīng)用的WAR包，它需要被放在Tomcat的webapps Docker法是，把WAR包直接放在Tomcat鏡像的webapps下，做成一個(gè)新的鏡像運(yùn)WARTomcat另法是，你壓根兒不管WAR包，只發(fā)布一個(gè)Tomcat容器。不過，這個(gè)容器的webapps，就必須一個(gè)hostPath類型的Volume，從而把宿主機(jī)上的WAR包掛載進(jìn)Tomcat容器當(dāng)中運(yùn)行起來。不過，這樣你就必須要解決一個(gè)問題，即：如何讓每一臺(tái)宿主機(jī)，都預(yù)先準(zhǔn)備好這個(gè)有WAR包的呢？這樣來看，你只能獨(dú)立一套分布實(shí)際上，有了Pod之后，這樣的問題就很容易解決了。我們可以把WAR包和Tomcat分別做PodPod代碼代碼apiVersion:kind:name:javaweb--image:name:command:["cp","/sample.war",-mountPath:name:app-volume-image:name: mountPath:/root/apache-tomcat-7.0.42-v2/webappsname:app-volumecontainerPort:hostPort:8001-name:app-emptyDir:Podgeektime/sample:v2，這個(gè)鏡像里只有一個(gè)WAR包（sample.war）放在根下。而第二個(gè)容器則使用的是一個(gè)標(biāo)準(zhǔn)的Tomcat鏡像。不過，你可能已經(jīng)注意到，WAR包容器的類型不再是一個(gè)普通容器，而是一個(gè)Init在Pod中，所有InitContainer定義的容器，都會(huì)比spec.containers定義的用戶容器先啟InitContainerWARcp/app"，把應(yīng)用的WAR包拷貝到 而后這個(gè) ，就掛載了一個(gè)名叫app-volume的VolumeTomcatwebappssample.warWARVolumeVolumeWARTomcatPodTomcatWARWARInitContainerWAR包容器，扮演了一個(gè)sidecar的角色。比如，我現(xiàn)在有一個(gè)應(yīng)用，需要不斷地把日志文件輸出到容器的/var/log 這時(shí)，我就可以把一個(gè)Pod里的Volume掛載到應(yīng)用容器的/var/log 然后，我在這個(gè)Pod里同時(shí)運(yùn)行一個(gè)sidecar容器，它也掛載同一個(gè)Volume到自己 日志文件，轉(zhuǎn)發(fā)到MongoDB或者Elasticsearch中起來。這樣，一個(gè)最基本的日志收集sidecarVolume但記，Pod的另一個(gè)重要特性是，它的所有容器都共享同一個(gè)NetworkNamespace。這就使得很多與Pod網(wǎng)絡(luò)相關(guān)的配置和管理，也都可以交給sidecar完成，而完全無須用戶容器。這里最典型的例子莫過于Istio這個(gè)微服務(wù)治理項(xiàng)目了?？傇诒酒恼轮形抑攸c(diǎn)了Kubernetes項(xiàng)目中Pod的實(shí)現(xiàn)原理實(shí)際上，一個(gè)運(yùn)行在虛擬機(jī)里的應(yīng)用，哪怕再簡單，也是被管理在systemd或者supervisordPod然后，你就可以把整個(gè)虛擬機(jī)想象成為一個(gè)Pod，把這些進(jìn)程分別做成容器鏡像，把有順序關(guān)InitContainer。這才是更加合理的、松耦合的容器編排訣竅，也是從傳統(tǒng)應(yīng)注意：Pod這個(gè)概念，提供的是一種編排思想，而不是具體的技術(shù)方案。所以，Pod行在這個(gè)虛擬機(jī)里。比如，Mirantis公司的virtlet項(xiàng)目就在干這個(gè)事情。甚至，你可以去實(shí)現(xiàn)一個(gè)帶有Init進(jìn)程的容器項(xiàng)目，來模擬傳統(tǒng)應(yīng)用的運(yùn)行方式。這些工作，在Kubernetes中都是非常輕松的，也是我們后面講解CRI時(shí)會(huì)提到的內(nèi)DockerInDocker思考NetworkNamespacePodNamespace這些Namesapce的具體應(yīng)用場景嗎？歸科技所有 痛快，每一篇都鞭辟入里。

精選留言

段帥 這文章讀起來像吃脆蘋果，爽，這是我訂閱專欄中寫的最好的，沒有之一作者回復(fù)這是我見過最形象的評(píng)論…… 重要理解了這個(gè)概念，透透透！不但解決了我前幾天war和tocat做一起，完成鏡像的頻繁打包問題，而且還想到怎么用pppeteer做一個(gè)ntcotaner,然后注入到odejs主容器，從而解決chroehedess太大不容易安裝的問題，爽爽爽！劉 好專欄啊，再寫成書繼續(xù)支持小新是 war包跟tomcat這個(gè)栗子舉得恰到好處啊虎虎? 講的真的用心，水平也高。被圈粉，希望一直能出專欄。您一定有一票粉絲支持和跟隨的！繼續(xù)加油。 容器不能管理多進(jìn)程那塊，能不能每個(gè)容器都默認(rèn)搬一套系統(tǒng)的nt過去，而不要讓普通應(yīng)用進(jìn)程做進(jìn)程1，這樣是不是就可以支持容器里面管理多進(jìn)程了？作者回復(fù)對(duì)。不過我們現(xiàn)在講的古典互聯(lián)網(wǎng)技術(shù)不太建議這么做，這是原始互聯(lián)網(wǎng)時(shí)代的思路。 pod是一個(gè)小家庭，它把密不可分的家庭成員(container)聚在一起，Infracontainer則是家長， 容器與容器是的，只是有些容器更加——超親密關(guān)系的 讀老師您的文章有種海邊拾寶的感覺，時(shí)不時(shí)蹦出來個(gè)好看的貝殼，讓人興奮不已IOVE.- 請問，sdecar這種用itcotner的方式和后面講到的sttelset的改變拓?fù)錉顟B(tài)，有什么區(qū)別么？作者回復(fù)沒什 在ode節(jié)點(diǎn)上一直看到有這個(gè)鏡像，搞不懂是干嘛的如今一看豁然開朗北 如果把war獨(dú)立出來做一個(gè)鏡像的話，應(yīng)該用什么做基礎(chǔ)鏡像呢？我現(xiàn)在做鏡像的時(shí)候通常都是用debian做基礎(chǔ)鏡像，但如果只是為了這個(gè).war包的話，作者回復(fù)市面上的小鏡像多的很啊，Eddie 此專欄追到現(xiàn)在，老師用通俗的語言闡述了k8s的原理的同時(shí)也極力推崇k8s。我在學(xué)習(xí)使用的過程中也確實(shí)體會(huì)到了其各種優(yōu)勢。但是反過來想，老師是否可以簡單舉兩個(gè)例子說下k8s目前為止依然存在的一些缺陷和不足呢？方便我們在應(yīng)用過程中加以注意。作者回復(fù)不足之處肯定要在具體剖析特性的時(shí)候才會(huì)講到。另外，這Kbenetes可不是推崇的問題，你會(huì)覺得我在推崇Lux嗎？ 以前看博客文章，都是哎呀媽呀腦瓜疼腦瓜疼，現(xiàn)在終于不疼了不疼了 非常好，請教一個(gè)問題，你之前說比如HP和MySL最好分在不同的pod，很可能就是不同的ode上了，那么對(duì)于atency非常敏感的比如cace，像redis和一個(gè)webserver是不是做成不同的cotaner部署在一個(gè)pod里面合適呢？作者回復(fù)取決于1.高可用考慮2.別的pod是不是也要用這個(gè)擇 偶像，那pod有和虛擬機(jī)在類比時(shí)又有什么不同呢，還是沒什么不同？作者回復(fù)只是 關(guān)于升級(jí)ar和toct那塊，也是先修改yl？然后benertes執(zhí)行升級(jí)命令，pod會(huì)重新啟動(dòng)，生產(chǎn)也是按照這種方式嗎？作者回復(fù)對(duì)，initcontainer就是干這個(gè)的 關(guān)于部署ar包和toct，在升級(jí)ar的時(shí)候，先修改yl，然后bernets會(huì)重啟整個(gè)pod，然后按照定義好的容器啟動(dòng)順序流程走下去？正常生產(chǎn)是按照這種方式進(jìn)行升級(jí)的嗎？假裝 張老師，數(shù)據(jù)庫和war包是單獨(dú)的pod，那么應(yīng)用的數(shù)據(jù)庫是否可以動(dòng)態(tài)配置呢作者回復(fù)仔細(xì)看，是單獨(dú)的容器…… 剛下班不久，看到張老師的文章很是開心，文章從“設(shè)計(jì)思想/理念”上來剖析為何k8s要引 cetos7benetescrcontnedatutie，經(jīng)過實(shí)踐，在一個(gè)pod中有兩個(gè)業(yè)務(wù)容器，兩個(gè)業(yè)務(wù)容器會(huì)共享use容器除了daepace外所有名空間 為什么說“DockerinDocker”這種方式在生產(chǎn)環(huán)境后患無窮呀？作者回復(fù)因?yàn)槭强拥亩畏?對(duì)于war包這個(gè)例子還有點(diǎn)不明白，war包這個(gè) ，就掛載了一個(gè)名叫app-難道可以創(chuàng)建一個(gè)沒有任何對(duì)應(yīng)的volume么作者回復(fù)任何volume對(duì)應(yīng)的都是宿主機(jī)啊IOVE.- 老師，咨詢個(gè)事情?，F(xiàn)在哪些地方能考CKA呢？費(fèi)用是多少呢？有年限限制的么作者回復(fù)

架構(gòu)指 醍醐灌頂J.P. 看了不少k8s的，學(xué)習(xí)這個(gè)課程后終于清晰薛定諤的指南 兩個(gè)例子都非常經(jīng)典，尤其是tocat和ar包的例子，感覺看完了以后容器技術(shù)立馬漲了一大截，贊王亞 不得不說，真是良心之作。作者回復(fù) 講的 在與大家交流時(shí)，會(huì)聽到pod的兩種發(fā)音（“破的”，“怕的”），有時(shí)實(shí)在尷尬，不清除到底誰讀錯(cuò)了。查過字典之后，實(shí)際是英美的區(qū)別（英p?dp:d]），我聽作者也是以英式發(fā)音，作者在與海外開發(fā)者接觸的時(shí)候，他們也都是以英式發(fā)音為主嗎?作者回復(fù)這個(gè)按自己喜歡的方式就好，比如etcd的讀法 不好意思，還是我，您的回復(fù)我沒看懂。我的問題有兩一個(gè)Pod里是否可以只有initcontainer，沒有用戶容器？作者回復(fù)是。不可以。建議重新理解一下我之前的回復(fù)蝸 war包的例子并沒有解決頻發(fā)打包的問題吧?wa包變動(dòng)后,geektime/sample:v2包仍然需要重新打吧.這和東西一股腦裝在tomcat中后,重新打tomcat并沒有差太多吧?作者回復(fù)你忽略了Tomcat的鏡像也是會(huì)變更的啊。另外，我只提供了一個(gè)最佳實(shí)踐的思路給你，具體的方案應(yīng)該你自己根據(jù)需求自己設(shè)計(jì)。比如，如果你的toct鏡像從來就幾乎沒更新過，那干脆 老師好，對(duì)于"第二個(gè)例子initcontainer必須早于用戶容器啟動(dòng)，而且必須要完成并退出后才會(huì)啟動(dòng)用戶容器。如果屬于，那它必須要等sidecar容器運(yùn)行完成并退出后才能會(huì)運(yùn)行應(yīng)用容器，接著產(chǎn)生新的日志。而此時(shí)sdecar容器已經(jīng)停止運(yùn)行，如何能把新的日志轉(zhuǎn)發(fā)出去呢？如果不屬于，也是initcontainer，那么啟動(dòng)順序是先啟動(dòng)產(chǎn)生日志的容器，再運(yùn)行轉(zhuǎn)發(fā)日志的一個(gè)Pod是否可以沒有用戶容器，只有init作者回復(fù)pod里的容器當(dāng)然沒有順序關(guān)系了，需要的話要在啟動(dòng)命令里做前置檢查。米斯特. 確實(shí)深入淺出，除了學(xué)習(xí)技術(shù)本身以外，老師講解的技術(shù)的方式方法也很值得學(xué)習(xí)天 非常洛子 完美解決war和tomcat做一起，完成鏡像的頻繁打包問題！而且占據(jù)空間太大 作者回復(fù)不能球場 講的很清楚。 我在工作中pod下都是同一種類型的容器，只是啟動(dòng)多個(gè)實(shí)際，需求上沒有用到在一個(gè)pod上 思路清晰，重點(diǎn)突出，生動(dòng)形象！買了容器與容器云這本書，配合專欄一起看！w 請教下，“比如，Mesos中就有一個(gè)資源囤積（resourcehoarding）的機(jī)制，會(huì)在所有設(shè)置了Affinity約束的任務(wù)都達(dá)到時(shí)，才開始對(duì)它們統(tǒng)一進(jìn)行調(diào)度”中的任務(wù)都達(dá)到是什么意思，不大明白這是個(gè)怎樣的機(jī)制。提到的死鎖又會(huì)在什么情況下發(fā)生。作者回復(fù)從調(diào)度隊(duì)列出隊(duì)啊。比如一個(gè)容器始終沒出現(xiàn)楊孔 老師，幫忙看下，我按照官網(wǎng)和den:User\"system:anonymous\"；也按照上面blog的方案將添加到個(gè)人，但證書提示沒有足夠的信息無法驗(yàn)證該；不知道有什么替代的方案，也試過--anonymous-auth=false，但如blob的作者所說，的確會(huì)造成api-server的不穩(wěn)定楊孔 求助下，哪位大神可以幫忙看下，我按照官網(wǎng)和 04hetcd-kiehls51/1Running04hkube-apiserver-kiehls51/1Running035mkube-flannel-ds-6rrkn1/1Running03hkube-flannel-ds-f8t5p1/1Running04h -6xgmn1/1Running03h -rm2vr1/1Running03h -sqprf1/1Running04hkube-scheduler-kiehls51/1Running34hmonitoring-grafana-69d5b8cc5-knw8z1/1Running03hmonitoring-influxdb-5fdb58bd4b-fjwjs1/1Running0 者B了，k8s怎么收到failuremessage并且重新去部署Pod呢作者回復(fù)不需要什么message，請關(guān)注后續(xù)的控制器模式 Pod里的容器還可以共享PIDNamespace,IPCasdf100 動(dòng)。并且，InitContainer容器會(huì)按順序逐一啟動(dòng)，而直到它們都啟動(dòng)并且退出了，用戶容器這里的initContainer容器是在啟用完后，【會(huì)被自作者回復(fù) 所謂一個(gè)容器就是一個(gè)進(jìn)程，意思是說我們在容器化某個(gè)應(yīng)用時(shí)應(yīng)該針對(duì)一個(gè)進(jìn)程封裝為一個(gè)容器鏡像，然后以pod方式組織起來，這是推薦的容器化應(yīng)用的實(shí)現(xiàn)方式。然而我們也可以將一個(gè)容器當(dāng)做一個(gè)虛擬機(jī)來使用，將該應(yīng)用的所有組件打包為一個(gè)復(fù)雜的容器鏡像然后在kbenets里通過pod方式啟動(dòng)，只不過這樣的話應(yīng)用的組件之間耦合性太高，不好，例如，當(dāng)我們要升級(jí)某個(gè)組件時(shí)必須重新制作這個(gè)復(fù)雜的鏡像；如果要只對(duì)應(yīng)用的某個(gè)組件擴(kuò)容也是不可能實(shí)現(xiàn)的。我的理解沒錯(cuò)吧 從事Linux運(yùn)維工作多年，有一點(diǎn)一直有點(diǎn)不明白，這里到底誰掛載到誰上面-mountpath:/app文中有有這句話說"而后這個(gè) ，就掛載了一個(gè)名叫app-volume的 ---Tomecat容器同樣了掛載app-volume到自己的 mount-txxfssrc_dir比如：mount-txfs/dev/sda/opt/app上面的掛載的app-volume到底是設(shè)備還是文件，或者是去的一個(gè)別名？作者回復(fù)volume的掛載是bindmount，不是設(shè)備，它的功能就是把文件或綁定掛載在一起，所以你這里的糾結(jié)誰在誰上面是沒有意義的……唯一需要明確的