1、學(xué)習(xí)曲線
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了水富免費(fèi)建站歡迎大家使用！
它包含了類C語法、GC內(nèi)置和工程工具。這一點(diǎn)非常重要，因?yàn)镚o語言容易學(xué)習(xí)，所以一個(gè)普通的大學(xué)生花一個(gè)星期就能寫出來可以上手的、高性能的應(yīng)用。在國(guó)內(nèi)大家都追求快，這也是為什么國(guó)內(nèi)Go流行的原因之一。
2、效率
Go擁有接近C的運(yùn)行效率和接近PHP的開發(fā)效率，這就很有利的支撐了上面大家追求快速的需求。
3、出身名門、血統(tǒng)純正
之所以說Go語言出身名門，是因?yàn)槲覀冎繥o語言出自Google公司，這個(gè)公司在業(yè)界的知名度和實(shí)力自然不用多說。Google公司聚集了一批牛人，在各種編程語言稱雄爭(zhēng)霸的局面下推出新的編程語言，自然有它的戰(zhàn)略考慮。而且從Go語言的發(fā)展態(tài)勢(shì)來看，Google對(duì)它這個(gè)新的寵兒還是很看重的，Go自然有一個(gè)良好的發(fā)展前途。我們看看Go語言的主要?jiǎng)?chuàng)造者，血統(tǒng)純正這點(diǎn)就可見端倪了。
4、組合的思想、無侵入式的接口
Go語言可以說是開發(fā)效率和運(yùn)行效率二者的完美融合，天生的并發(fā)編程支持。Go語言支持當(dāng)前所有的編程范式，包括過程式編程、面向?qū)ο缶幊桃约昂瘮?shù)式編程。
5、強(qiáng)大的標(biāo)準(zhǔn)庫(kù)
這包括互聯(lián)網(wǎng)應(yīng)用、系統(tǒng)編程和網(wǎng)絡(luò)編程。Go里面的標(biāo)準(zhǔn)庫(kù)基本上已經(jīng)是非常穩(wěn)定，特別是我這里提到的三個(gè)，網(wǎng)絡(luò)層、系統(tǒng)層的庫(kù)非常實(shí)用。
6、部署方便
我相信這一點(diǎn)是很多人選擇Go的最大理由，因?yàn)椴渴鹛奖?，所以現(xiàn)在也有很多人用Go開發(fā)運(yùn)維程序。
7、簡(jiǎn)單的并發(fā)
它包含降低心智的并發(fā)和簡(jiǎn)易的數(shù)據(jù)同步，我覺得這是Go最大的特色。之所以寫正確的并發(fā)、容錯(cuò)和可擴(kuò)展的程序如此之難，是因?yàn)槲覀冇昧隋e(cuò)誤的工具和錯(cuò)誤的抽象，Go可以說這一塊做的相當(dāng)簡(jiǎn)單。
8、穩(wěn)定性
Go擁有強(qiáng)大的編譯檢查、嚴(yán)格的編碼規(guī)范和完整的軟件生命周期工具，具有很強(qiáng)的穩(wěn)定性，穩(wěn)定壓倒一切。那么為什么Go相比于其他程序會(huì)更穩(wěn)定呢?這是因?yàn)镚o提供了軟件生命周期的各個(gè)環(huán)節(jié)的工具，如go
tool、gofmt、go test。
1、簡(jiǎn)單易學(xué)。
Go語言的作者本身就很懂C語言，所以同樣Go語言也會(huì)有C語言的基因，所以對(duì)于程序員來說，Go語言天生就會(huì)讓人很熟悉，容易上手。
2、并發(fā)性好。
Go語言天生支持并發(fā)，可以充分利用多核，輕松地使用并發(fā)。 這是Go語言最大的特點(diǎn)。
描述
Go的語法接近C語言，但對(duì)于變量的聲明有所不同。Go支持垃圾回收功能。Go的并行模型是以東尼·霍爾的通信順序進(jìn)程（CSP）為基礎(chǔ)，采取類似模型的其他語言包括Occam和Limbo，但它也具有Pi運(yùn)算的特征，比如通道傳輸。
在1.8版本中開放插件（Plugin）的支持，這意味著現(xiàn)在能從Go中動(dòng)態(tài)加載部分函數(shù)。
與C++相比，Go并不包括如枚舉、異常處理、繼承、泛型、斷言、虛函數(shù)等功能，但增加了 切片(Slice) 型、并發(fā)、管道、垃圾回收、接口（Interface）等特性的語言級(jí)支持。
簡(jiǎn)述 etcd 及其特點(diǎn)？
答：etcd 是 CoreOS 團(tuán)隊(duì)發(fā)起的開源項(xiàng)目，是一個(gè)管理配置信息和服務(wù)發(fā)現(xiàn)
（service discovery）的項(xiàng)目，它的目標(biāo)是構(gòu)建一個(gè)高可用的分布式鍵值（key-value）
數(shù)據(jù)庫(kù)，基于 Go 語言實(shí)現(xiàn)。
特點(diǎn)：
l 簡(jiǎn)單：支持 REST 風(fēng)格的 HTTP+JSON API
l 安全：支持 HTTPS 方式的訪問
l 快速：支持并發(fā) 1k/s 的寫操作
l 可靠：支持分布式結(jié)構(gòu)，基于 Raft 的一致性算法，Raft 是一套通過選舉主節(jié)點(diǎn)來
實(shí)現(xiàn)分布式系統(tǒng)一致性的算法。
簡(jiǎn)述 etcd 適應(yīng)的場(chǎng)景？
答：etcd 基于其優(yōu)秀的特點(diǎn)，可廣泛的應(yīng)用于以下場(chǎng)景：
l 服務(wù)發(fā)現(xiàn)(Service Discovery)：服務(wù)發(fā)現(xiàn)主要解決在同一個(gè)分布式集群中的進(jìn)程
或服務(wù)，要如何才能找到對(duì)方并建立連接。本質(zhì)上來說，服務(wù)發(fā)現(xiàn)就是想要了解
集群中是否有進(jìn)程在監(jiān)聽 udp 或 tcp 端口，并且通過名字就可以查找和連接。
一些配置信息放到 etcd 上進(jìn)行集中管理。
l 負(fù)載均衡：在分布式系統(tǒng)中，為了保證服務(wù)的高可用以及數(shù)據(jù)的一致性，通常都
會(huì)把數(shù)據(jù)和服務(wù)部署多份，以此達(dá)到對(duì)等服務(wù)，即使其中的某一個(gè)服務(wù)失效了，
也不影響使用。etcd 本身分布式架構(gòu)存儲(chǔ)的信息訪問支持負(fù)載均衡。etcd 集群化
以后，每個(gè) etcd 的核心節(jié)點(diǎn)都可以處理用戶的請(qǐng)求。所以，把數(shù)據(jù)量小但是訪問
頻繁的消息數(shù)據(jù)直接存儲(chǔ)到 etcd 中也可以實(shí)現(xiàn)負(fù)載均衡的效果。
通過注冊(cè)與異步通知機(jī)制，實(shí)現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，從而
對(duì)數(shù)據(jù)變更做到實(shí)時(shí)處理。
l 分布式鎖：因?yàn)?etcd 使用 Raft 算法保持了數(shù)據(jù)的強(qiáng)一致性，某次操作存儲(chǔ)到集
群中的值必然是全局一致的，所以很容易實(shí)現(xiàn)分布式鎖。鎖服務(wù)有兩種使用方式，
一是保持獨(dú)占，二是控制時(shí)序。
l 集群監(jiān)控與 Leader 競(jìng)選：通過 etcd 來進(jìn)行監(jiān)控實(shí)現(xiàn)起來非常簡(jiǎn)單并且實(shí)時(shí)性強(qiáng)。
簡(jiǎn)述 Kubernetes 和 Docker 的關(guān)系？
答：Docker 提供容器的生命周期管理和，Docker 鏡像構(gòu)建運(yùn)行時(shí)容器。它的主要優(yōu)
點(diǎn)是將將軟件/應(yīng)用程序運(yùn)行所需的設(shè)置和依賴項(xiàng)打包到一個(gè)容器中，從而實(shí)現(xiàn)了可移
植性等優(yōu)點(diǎn)。
Kubernetes 用于關(guān)聯(lián)和編排在多個(gè)主機(jī)上運(yùn)行的容器。
簡(jiǎn)述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？
答：Minikube 是一種可以在本地輕松運(yùn)行一個(gè)單節(jié)點(diǎn) Kubernetes 群集的工具。
Kubectl 是一個(gè)命令行工具，可以使用該工具控制 Kubernetes 集群管理器，如檢查
群集資源，創(chuàng)建、刪除和更新組件，查看應(yīng)用程序。
Kubelet 是一個(gè)代理服務(wù)，它在每個(gè)節(jié)點(diǎn)上運(yùn)行，并使從服務(wù)器與主服務(wù)器通信。
簡(jiǎn)述 Kubernetes 常見的部署方式？
答：常見的 Kubernetes 部署方式有：
l kubeadm：也是推薦的一種部署方式；
l 二進(jìn)制：
l minikube：在本地輕松運(yùn)行一個(gè)單節(jié)點(diǎn) Kubernetes 群集的工具。
簡(jiǎn)述 Kubernetes 如何實(shí)現(xiàn)集群管理？
答：在集群管理方面，Kubernetes 將集群中的機(jī)器劃分為一個(gè) Master 節(jié)點(diǎn)和一群工
作節(jié)點(diǎn) Node。其中，在 Master 節(jié)點(diǎn)運(yùn)行著集群管理相關(guān)的一組進(jìn)程 kube
apiserver、kube-controller-manager 和 kube-scheduler，這些進(jìn)程實(shí)現(xiàn)了整個(gè)集
群的資源管理、Pod 調(diào)度、彈性伸縮、安全控制、系統(tǒng)監(jiān)控和糾錯(cuò)等管理能力，并且
都是全自動(dòng)完成的。
簡(jiǎn)述 Kubernetes 相關(guān)基礎(chǔ)概念？
答：
l master：k8s 集群的管理節(jié)點(diǎn)，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問入口。
擁有 Etcd 存儲(chǔ)服務(wù)（可選），運(yùn)行 Api Server 進(jìn)程，Controller Manager 服務(wù)
進(jìn)程及 Scheduler 服務(wù)進(jìn)程。
l node（worker）：Node（worker）是 Kubernetes 集群架構(gòu)中運(yùn)行 Pod 的服
務(wù)節(jié)點(diǎn)，是 Kubernetes 集群操作的單元，用來承載被分配 Pod 的運(yùn)行，是 Pod
運(yùn)行的宿主機(jī)。運(yùn)行 docker eninge 服務(wù)，守護(hù)進(jìn)程 kunelet 及負(fù)載均衡器
kube-proxy。
l pod：運(yùn)行于 Node 節(jié)點(diǎn)上，若干相關(guān)容器的組合。Pod 內(nèi)包含的容器運(yùn)行在同
一宿主機(jī)上，使用相同的網(wǎng)絡(luò)命名空間、IP 地址和端口，能夠通過 localhost 進(jìn)行通信。Pod 是 Kurbernetes 進(jìn)行創(chuàng)建、調(diào)度和管理的最小單位，它提供了比容
器更高層次的抽象，使得部署和管理更加靈活。一個(gè) Pod 可以包含一個(gè)容器或者
多個(gè)相關(guān)容器。
l label：Kubernetes 中的 Label 實(shí)質(zhì)是一系列的 Key/Value 鍵值對(duì)，其中 key 與
value 可自定義。Label 可以附加到各種資源對(duì)象上，如 Node、Pod、Service、
RC 等。一個(gè)資源對(duì)象可以定義任意數(shù)量的 Label，同一個(gè) Label 也可以被添加到
任意數(shù)量的資源對(duì)象上去。Kubernetes 通過 Label Selector（標(biāo)簽選擇器）查詢
和篩選資源對(duì)象。
l Replication Controller：Replication Controller 用來管理 Pod 的副本，保證集
群中存在指定數(shù)量的 Pod 副本。集群中副本的數(shù)量大于指定數(shù)量，則會(huì)停止指定
數(shù)量之外的多余容器數(shù)量。反之，則會(huì)啟動(dòng)少于指定數(shù)量個(gè)數(shù)的容器，保證數(shù)量
不變。Replication Controller 是實(shí)現(xiàn)彈性伸縮、動(dòng)態(tài)擴(kuò)容和滾動(dòng)升級(jí)的核心。
l Deployment：Deployment 在內(nèi)部使用了 RS 來實(shí)現(xiàn)目的，Deployment 相當(dāng)
于 RC 的一次升級(jí)，其最大的特色為可以隨時(shí)獲知當(dāng)前 Pod 的部署進(jìn)度。
l HPA（Horizontal Pod Autoscaler）：Pod 的橫向自動(dòng)擴(kuò)容，也是 Kubernetes
的一種資源，通過追蹤分析 RC 控制的所有 Pod 目標(biāo)的負(fù)載變化情況，來確定是
否需要針對(duì)性的調(diào)整 Pod 副本數(shù)量。
l Service：Service 定義了 Pod 的邏輯集合和訪問該集合的策略，是真實(shí)服務(wù)的抽
象。Service 提供了一個(gè)統(tǒng)一的服務(wù)訪問入口以及服務(wù)代理和發(fā)現(xiàn)機(jī)制，關(guān)聯(lián)多個(gè)
相同 Label 的 Pod，用戶不需要了解后臺(tái) Pod 是如何運(yùn)行。
l Volume：Volume 是 Pod 中能夠被多個(gè)容器訪問的共享目錄，Kubernetes 中的
Volume 是定義在 Pod 上，可以被一個(gè)或多個(gè) Pod 中的容器掛載到某個(gè)目錄下。l Namespace：Namespace 用于實(shí)現(xiàn)多租戶的資源隔離，可將集群內(nèi)部的資源對(duì)
象分配到不同的 Namespace 中，形成邏輯上的不同項(xiàng)目、小組或用戶組，便于
不同的 Namespace 在共享使用整個(gè)集群的資源的同時(shí)還能被分別管理。
簡(jiǎn)述 Kubernetes RC 的機(jī)制？
答：Replication Controller 用來管理 Pod 的副本，保證集群中存在指定數(shù)量的 Pod
副本。當(dāng)定義了 RC 并提交至 Kubernetes 集群中之后，Master 節(jié)點(diǎn)上的 Controller
Manager 組件獲悉，并同時(shí)巡檢系統(tǒng)中當(dāng)前存活的目標(biāo) Pod，并確保目標(biāo) Pod 實(shí)例的數(shù)量剛好等于此 RC 的期望值，若存在過多的 Pod 副本在運(yùn)行，系統(tǒng)會(huì)停止一些
Pod，反之則自動(dòng)創(chuàng)建一些 Pod。
簡(jiǎn)述 Kubernetes 中 Pod 的重啟策略？
答：Pod 重啟策略（RestartPolicy）應(yīng)用于 Pod 內(nèi)的所有容器，并且僅在 Pod 所處
的 Node 上由 kubelet 進(jìn)行判斷和重啟操作。當(dāng)某個(gè)容器異常退出或者 健康 檢查失敗
時(shí)，kubelet 將根據(jù) RestartPolicy 的設(shè)置來進(jìn)行相應(yīng)操作。
Pod 的重啟策略包括 Always、OnFailure 和 Never，默認(rèn)值為 Always。
l Always：當(dāng)容器失效時(shí)，由 kubelet 自動(dòng)重啟該容器；
l OnFailure：當(dāng)容器終止運(yùn)行且退出碼不為 0 時(shí)，由 kubelet 自動(dòng)重啟該容器；
l Never：不論容器運(yùn)行狀態(tài)如何，kubelet 都不會(huì)重啟該容器。
同時(shí) Pod 的重啟策略與控制方式關(guān)聯(lián)，當(dāng)前可用于管理 Pod 的控制器包括
ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（靜態(tài) Pod）。
不同控制器的重啟策略限制如下：
l RC 和 DaemonSet：必須設(shè)置為 Always，需要保證該容器持續(xù)運(yùn)行；
l Job：OnFailure 或 Never，確保容器執(zhí)行完成后不再重啟；
l kubelet：在 Pod 失效時(shí)重啟，不論將 RestartPolicy 設(shè)置為何值，也不會(huì)對(duì) Pod
進(jìn)行 健康 檢查。
簡(jiǎn)述 Kubernetes Pod 的 LivenessProbe 探針的常見方式？
答：kubelet 定期執(zhí)行 LivenessProbe 探針來診斷容器的 健康 狀態(tài)，通常有以下三種
方式：
l ExecAction：在容器內(nèi)執(zhí)行一個(gè)命令，若返回碼為 0，則表明容器 健康 。
l TCPSocketAction：通過容器的 IP 地址和端口號(hào)執(zhí)行 TCP 檢查，若能建立 TCP
連接，則表明容器 健康 。
l HTTPGetAction：通過容器的 IP 地址、端口號(hào)及路徑調(diào)用 HTTP Get 方法，若響
應(yīng)的狀態(tài)碼大于等于 200 且小于 400，則表明容器 健康 。
. 簡(jiǎn)述 Kubernetes Pod 的常見調(diào)度方式？
答：Kubernetes 中，Pod 通常是容器的載體，主要有如下常見調(diào)度方式：
l Deployment 或 RC：該調(diào)度策略主要功能就是自動(dòng)部署一個(gè)容器應(yīng)用的多份副本，
以及持續(xù)監(jiān)控副本的數(shù)量，在集群內(nèi)始終維持用戶指定的副本數(shù)量。
l NodeSelector：定向調(diào)度，當(dāng)需要手動(dòng)指定將 Pod 調(diào)度到特定 Node 上，可以
通過 Node 的標(biāo)簽（Label）和 Pod 的 nodeSelector 屬性相匹配。
l NodeAffinity 親和性調(diào)度：親和性調(diào)度機(jī)制極大的擴(kuò)展了 Pod 的調(diào)度能力，目前
有兩種節(jié)點(diǎn)親和力表達(dá)：
l requiredDuringSchedulingIgnoredDuringExecution：硬規(guī)則，必須滿足指定
的規(guī)則，調(diào)度器才可以調(diào)度 Pod 至 Node 上（類似 nodeSelector，語法不同）。
l preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調(diào)度至滿
足的 Node 的節(jié)點(diǎn)，但不強(qiáng)求，多個(gè)優(yōu)先級(jí)規(guī)則還可以設(shè)置權(quán)重值。
l Taints 和 Tolerations（污點(diǎn)和容忍）：
l Taint：使 Node 拒絕特定 Pod 運(yùn)行；
l Toleration：為 Pod 的屬性，表示 Pod 能容忍（運(yùn)行）標(biāo)注了 Taint 的 Node。
簡(jiǎn)述 Kubernetes DaemonSet 類型的資源特性？
答：DaemonSet 資源對(duì)象會(huì)在每個(gè) Kubernetes 集群中的節(jié)點(diǎn)上運(yùn)行，并且每個(gè)節(jié)
點(diǎn)只能運(yùn)行一個(gè) pod，這是它和 deployment 資源對(duì)象的最大也是唯一的區(qū)別。因此，
在定義 yaml 文件中，不支持定義 replicas。
它的一般使用場(chǎng)景如下：
l 在去做每個(gè)節(jié)點(diǎn)的日志收集工作。
l 監(jiān)控每個(gè)節(jié)點(diǎn)的的運(yùn)行狀態(tài)。
簡(jiǎn)述 Kubernetes Service 分發(fā)后端的策略？
答：Service 負(fù)載分發(fā)的策略有：RoundRobin 和 SessionAffinity
l RoundRobin：默認(rèn)為輪詢模式，即輪詢將請(qǐng)求轉(zhuǎn)發(fā)到后端的各個(gè) Pod 上。
l SessionAffinity：基于客戶端 IP 地址進(jìn)行會(huì)話保持的模式，即第 1 次將某個(gè)客戶
端發(fā)起的請(qǐng)求轉(zhuǎn)發(fā)到后端的某個(gè) Pod 上，之后從相同的客戶端發(fā)起的請(qǐng)求都將被
轉(zhuǎn)發(fā)到后端相同的 Pod 上。
簡(jiǎn)述 Kubernetes Scheduler 使用哪兩種算法將 Pod 綁定到 worker 節(jié)點(diǎn)？
答：Kubernetes Scheduler 根據(jù)如下兩種調(diào)度算法將 Pod 綁定到最合適的工作節(jié)點(diǎn)：
l 預(yù)選（Predicates）：輸入是所有節(jié)點(diǎn)，輸出是滿足預(yù)選條件的節(jié)點(diǎn)。kube
scheduler 根據(jù)預(yù)選策略過濾掉不滿足策略的 Nodes。如果某節(jié)點(diǎn)的資源不足或
者不滿足預(yù)選策略的條件則無法通過預(yù)選。如“Node 的 label 必須與 Pod 的
Selector 一致”。
l 優(yōu)選（Priorities）：輸入是預(yù)選階段篩選出的節(jié)點(diǎn)，優(yōu)選會(huì)根據(jù)優(yōu)先策略為通過
預(yù)選的 Nodes 進(jìn)行打分排名，選擇得分最高的 Node。例如，資源越富裕、負(fù)載
越小的 Node 可能具有越高的排名。
簡(jiǎn)述 Kubernetes Secret 有哪些使用方式？
答：創(chuàng)建完 secret 之后，可通過如下三種方式使用：
l 在創(chuàng)建 Pod 時(shí)，通過為 Pod 指定 Service Account 來自動(dòng)使用該 Secret。
l 通過掛載該 Secret 到 Pod 來使用它。
l 在 Docker 鏡像下載時(shí)使用，通過指定 Pod 的 spc.ImagePullSecrets 來引用它。
簡(jiǎn)述 Kubernetes 網(wǎng)絡(luò)策略原理？
答：Network Policy 的工作原理主要為：policy controller 需要實(shí)現(xiàn)一個(gè) API
Listener，監(jiān)聽用戶設(shè)置的 Network Policy 定義，并將網(wǎng)絡(luò)訪問規(guī)則通過各 Node 的
Agent 進(jìn)行實(shí)際設(shè)置（Agent 則需要通過 CNI 網(wǎng)絡(luò)插件實(shí)現(xiàn)）。
簡(jiǎn)述 Kubernetes 集群聯(lián)邦？
答：Kubernetes 集群聯(lián)邦可以將多個(gè) Kubernetes 集群作為一個(gè)集群進(jìn)行管理。因此，
可以在一個(gè)數(shù)據(jù)中心/云中創(chuàng)建多個(gè) Kubernetes 集群，并使用集群聯(lián)邦在一個(gè)地方控
制/管理所有集群。
簡(jiǎn)述 Kubernetes 如何進(jìn)行優(yōu)雅的節(jié)點(diǎn)關(guān)機(jī)維護(hù)？
答：由于 Kubernetes 節(jié)點(diǎn)運(yùn)行大量 Pod，因此在進(jìn)行關(guān)機(jī)維護(hù)之前，建議先使用
kubectl drain 將該節(jié)點(diǎn)的 Pod 進(jìn)行驅(qū)逐，然后進(jìn)行關(guān)機(jī)維護(hù)。
. 簡(jiǎn)述 Kubernetes 中，如何使用 EFK 實(shí)現(xiàn)日志的統(tǒng)一管理？
答：在 Kubernetes 集群環(huán)境中，通常一個(gè)完整的應(yīng)用或服務(wù)涉及組件過多，建議對(duì)
日志系統(tǒng)進(jìn)行集中化管理，通常采用 EFK 實(shí)現(xiàn)。
EFK 是 Elasticsearch、Fluentd 和 Kibana 的組合，其各組件功能如下：
l Elasticsearch：是一個(gè)搜索引擎，負(fù)責(zé)存儲(chǔ)日志并提供查詢接口；
l Fluentd：負(fù)責(zé)從 Kubernetes 搜集日志，每個(gè) node 節(jié)點(diǎn)上面的 fluentd 監(jiān)控并
收集該節(jié)點(diǎn)上面的系統(tǒng)日志，并將處理過后的日志信息發(fā)送給 Elasticsearch；
l Kibana：提供了一個(gè) Web GUI，用戶可以瀏覽和搜索存儲(chǔ)在 Elasticsearch 中的
日志。通過在每臺(tái) node 上部署一個(gè)以 DaemonSet 方式運(yùn)行的 fluentd 來收集每臺(tái) node
上的日志。Fluentd 將 docker 日志目錄/var/lib/docker/containers 和/var/log 目錄
掛載到 Pod 中，然后 Pod 會(huì)在 node 節(jié)點(diǎn)的/var/log/pods 目錄中創(chuàng)建新的目錄，可
以區(qū)別不同的容器日志輸出，該目錄下有一個(gè)日志文件鏈接到
/var/lib/docker/contianers 目錄下的容器日志輸出。
重慶分公司
重慶分公司
