正文

kubernetes負(fù)載均衡（kubernetes負(fù)載均衡訪問地址）

發(fā)布時(shí)間：2023-04-08 04:23:09 稿源：創(chuàng)意嶺閱讀： 97

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于kubernetes負(fù)載均衡的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、K8S有什么作用？
2、docker 和 k8s 面試總結(jié)
3、服務(wù)器搭建k8s內(nèi)存需要多大
4、什么是K8S？

kubernetes負(fù)載均衡（kubernetes負(fù)載均衡訪問地址）

一、K8S有什么作用？

K8s在什么情況會(huì)殺掉服務(wù)？使用Rancher來運(yùn)行Kubernetes有很多優(yōu)勢(shì)。大多數(shù)情況下能使用戶和IT團(tuán)隊(duì)部署和管理工作更加方便。Rancher自動(dòng)在Kubernetes后端實(shí)現(xiàn)etcd 的HA，并且將所需要的服務(wù)部署到此環(huán)境下的任何主機(jī)中。在設(shè)置訪問控制，可以輕易連接到現(xiàn)有的LDAP和AD基礎(chǔ)構(gòu)架。Rancher還可以自動(dòng)實(shí)現(xiàn)容器聯(lián)網(wǎng)以及為Kubernetes提供負(fù)載均衡服務(wù)。通過使用Rancher，你將會(huì)在幾分鐘內(nèi)有擁有Kubernetes的HA實(shí)現(xiàn)。命名空間現(xiàn)在我們的集群已經(jīng)運(yùn)行了，讓我們進(jìn)入并查看一些基本的Kubernetes資源吧。你可以訪問Kubernetes集群也可以直接通過kubectl CLI訪問，或者通過Rancher UI 訪問。Rancher的訪問管理圖層控制可以訪問集群，所以你需要在訪問CLI前從Rancher UI那里生成API密匙。我們來看下第一個(gè)Kubernetes資源命名空間，在給定的命名空間中，所有資源名稱必須有唯一性。此外,標(biāo)簽是用來連接劃定到單個(gè)命名空間的資源。這就是為什么同一個(gè)Kubernetes集群上可以用命名空間來隔離環(huán)境。例如，你想為應(yīng)用程序創(chuàng)建Alpha, Beta和生產(chǎn)環(huán)境，以便可以測(cè)試最新的更改且不會(huì)影響到真正的用戶。最后創(chuàng)建命名空間，復(fù)制下面的文本到namespace.yaml文件，并且運(yùn)行 kubectl -f namespace.yaml 命令，來創(chuàng)建一個(gè)beta命名空間。kind: NamespaceapiVersion: v1metadata:name: betalabels:name: beta當(dāng)然你還可以使用頂部的命名空間菜單欄從Rancher UI上創(chuàng)建、查看和選擇命名空間。你可以使用下面的命令，用kubectl來為CLI交互設(shè)置命名空間：$ kubectl config set-context Kubernetes --namespace=beta.為了驗(yàn)證目前context是否已經(jīng)被設(shè)置好，你可以使用config view命令，驗(yàn)證一下輸出的命名空間是否滿足你的期望。$ kubectl config view | grep namespace command namespace: betaPods現(xiàn)在我們已經(jīng)定義好了命名空間，接下來開始創(chuàng)建資源。首先我們要看的資源是Pod。一組一個(gè)或者多個(gè)容器的Kubernetes稱為pod，容器在pod 里按組來部署、啟動(dòng)、停止、和復(fù)制。在給定的每個(gè)主機(jī)種類里，只能有一個(gè)Pod,所有pod里的容器只能在同一個(gè)主機(jī)上運(yùn)行，pods可以共享網(wǎng)絡(luò)命名空間,通過本地主機(jī)域來連接。Pods也是基本的擴(kuò)展單元,不能跨越主機(jī),因此理想狀況是使它們盡可能接近單個(gè)工作負(fù)載。這將消除pod在擴(kuò)展或縮小時(shí)產(chǎn)生的副作用，以及確保我們創(chuàng)建pods不太耗資源而影響到主機(jī)。我們來給名為mywebservice的pod定義，在規(guī)范命名web-1-10中它有一個(gè)容器并使用nginx容器鏡像，然后把端口為80下的文本添加至pod.yaml文檔中。apiVersion: v1kind: Podmetadata:name: mywebservicespec:containers:- name: web-1-10image: nginx:1.10ports:- containerPort: 80使用kubetl create命令創(chuàng)建pod，如果您使用set-context command設(shè)置了您的命名空間，pods將會(huì)在指定命名空間中被創(chuàng)立。在通過運(yùn)行pods命令去驗(yàn)證pod狀態(tài)。完成以后，我們可以通過運(yùn)行kubetl delete命令刪除pod。$ kubectl create -f ./pod.yamlpod "mywebservice" created$ kubectl get podsNAME READY STATUS RESTARTS AGEmywebservice 1/1 Running 0 37s$ kubectl delete -f pod.yamlpod "mywebservice" deleted在Rancher UI 中查看pod，通過頂端的菜單欄選擇 Kubernetes > Pods 。

二、docker 和 k8s 面試總結(jié)

花了大半個(gè)月對(duì)k8s&docker進(jìn)行了梳理，包括之前讀過的書，官方文檔以及k&d在公司項(xiàng)目的實(shí)踐等。

以下是個(gè)人對(duì)docker & k8s 面試知識(shí)點(diǎn)的總結(jié)：

1 docker

常見面試題如下每一點(diǎn)可根據(jù)回答進(jìn)行適當(dāng)深入

1.1 什么是docker

docker和傳統(tǒng)linux的差異？

容器和鏡像的區(qū)別？

如何理解docker的緩存機(jī)制？

1.2 docker 網(wǎng)絡(luò)模型是什么？有何局限

docker的網(wǎng)絡(luò)基礎(chǔ)是什么？

docker的網(wǎng)絡(luò)模型是？有什么局限？

docker如何實(shí)現(xiàn)容器間通信的？

1.3 docker 基礎(chǔ)命令

cmd和entryPoint差異？

copy和add的差異？

簡(jiǎn)單講下swam/compose？

2 kubernetes

常見面試題如下每一點(diǎn)可根據(jù)回答進(jìn)行適當(dāng)深入

2.1 什么是k8s?

1 為什么用k8s 解決了什么問題？

2 k8s有哪些組件,有什么作用？【同：Master節(jié)點(diǎn)和Node節(jié)點(diǎn)都用哪些組件】

3 可以簡(jiǎn)單說下Node Pod container 之間的關(guān)系嗎？【可引入2.2/2.3對(duì)Pod SVC的考察】

4 什么是SVC可以簡(jiǎn)單描述下嗎？【可引入2.3對(duì)SVC的考察】

5 可以簡(jiǎn)單講下k8s的網(wǎng)絡(luò)模型嗎？

6 Pod SVC Node Container 之間如何相互訪問

7 swarm和k8s如何選擇？

2.2 考察Pod

靜態(tài)Pod和普通Pod的差異？

簡(jiǎn)單講下Pod的生命周期重啟策略呢？

- 不同組件對(duì)Pod的重啟策略要求一樣嗎？

如何檢查Pod的健康狀態(tài)？哪2種探針？

- 2種探針的實(shí)現(xiàn)方式

簡(jiǎn)單說下Pod的調(diào)度方式？

2.3 考察SVC

SVC有哪4種類型

2.4 k8s網(wǎng)絡(luò)模型

DNS和Iptables在k8s中的運(yùn)用？有何差異

- k8s如何解決多機(jī)器部署容器的網(wǎng)絡(luò)問題？

Pod SVC Node Container 之間如何相互訪問

3 參考答案

答案是根據(jù)所在公司項(xiàng)目結(jié)合自己的理解給出的答案不一定完全準(zhǔn)確但在面試中要做到有理有據(jù)突出自己的思路即可。

4 docker

問題和答案如下

4.1 什么是docker？

通常問這個(gè)問題主要在于考察候選人是否真正了解過docker，很多人項(xiàng)目中都有用到docker，真正去了解過概念，架構(gòu)的不多。從而來辨別簡(jiǎn)歷上的熟悉/了解docker的水分。

如果這個(gè)都無法回答，那么接下來的docker考察也就毫無意義了，此問題通常也會(huì)結(jié)合以下問題來進(jìn)行考察。

docker和傳統(tǒng)linux的差異？

docker都有哪些核心組件？

可以簡(jiǎn)單說下docker的架構(gòu)嗎？

容器和鏡像的區(qū)別？

docker是什么： Docker是一個(gè)可以把開發(fā)的應(yīng)用程序自動(dòng)部署到容器的開源引擎。

docker和VM差異： docker是一個(gè)應(yīng)用層的抽象，容器之間通過網(wǎng)絡(luò)命名空間進(jìn)行隔離，多個(gè)容器共享同一個(gè)操作系統(tǒng)內(nèi)核。VM是對(duì)物理硬件層的抽象，每個(gè)VM都包含獨(dú)立的操作系統(tǒng)，重且啟動(dòng)緩慢。VM主要為了提供系統(tǒng)環(huán)境，容器主要是為了提供應(yīng)用環(huán)境。

docker組件： docker引擎【包含Docker客戶端&服務(wù)端】,docker鏡像，docker容器，Registry【鏡像倉(cāng)庫(kù)】

docker的架構(gòu): C/s架構(gòu)

容器和鏡像的區(qū)別：鏡像是一個(gè)只讀模板，包括運(yùn)行容器所需的數(shù)據(jù)，其內(nèi)容在構(gòu)建之后就不會(huì)被改變，可以用來創(chuàng)建新的容器。鏡像由多個(gè)只讀層組成，容器在只讀層的基礎(chǔ)上多了一個(gè)讀寫層。

4.2 docker 網(wǎng)絡(luò)模型是什么？有何局限

這里也經(jīng)常會(huì)結(jié)合K8s網(wǎng)絡(luò)原理進(jìn)行考察，以及如下幾個(gè)考點(diǎn)

docker的網(wǎng)絡(luò)基礎(chǔ)是什么？

docker的網(wǎng)絡(luò)模型是？有什么局限？

docker如何實(shí)現(xiàn)容器間通信的？

Docker網(wǎng)絡(luò)基礎(chǔ)： Docker是在操作系統(tǒng)層上對(duì)應(yīng)用的抽象，使用網(wǎng)絡(luò)命名空間來對(duì)不同容器之間進(jìn)行網(wǎng)絡(luò)隔離，用Veth設(shè)備對(duì)來進(jìn)行容器之間的通訊。

docker的網(wǎng)絡(luò)模型：有4種網(wǎng)絡(luò)模型分別是Bridge Container host none 默認(rèn)使用bridge網(wǎng)絡(luò)模型，容器的初次啟動(dòng)會(huì)虛擬化出來一個(gè)新的網(wǎng)卡名為docker0,在多機(jī)器部署下docker0地址可能會(huì)沖突。所以docker對(duì)多機(jī)部署支持的不夠友好。

4.3 docker 基礎(chǔ)命令

出現(xiàn)頻率較高的為以下幾條命令的考察

cmd和entry差異？

copy和add的差異？

docker-compose & docker swarm？

CMD & ENTRYPONIT

都是容器操作指令：

CMD 用于指定容器啟動(dòng)時(shí)候默認(rèn)執(zhí)行的命令。可以被docker run指定的啟動(dòng)命令覆蓋。ENTRYPONIT 指令可讓容器以應(yīng)用程序或者服務(wù)的形式運(yùn)行。一般不會(huì)被docker run指定的啟動(dòng)命令覆蓋。dockerfile中的多個(gè)CMD & ENTRYPONIT只有最后一個(gè)會(huì)生效。

注意區(qū)別docker run 和RUN 一個(gè)是容器啟動(dòng)命令，一個(gè)是鏡像構(gòu)建時(shí)候所用。

copy & add

ADD & COPY 選取目標(biāo)文件復(fù)制到鏡像當(dāng)中。是針對(duì)鏡像的指令，唯一差別在于add源文件可以支持url且可以對(duì)壓縮文件進(jìn)行解壓操作。而copy針對(duì)的是當(dāng)前構(gòu)建環(huán)境。

docker-compose & docker swarm

使用Docker compose可以用YAML文件來定義一組需要啟動(dòng)的容器，以及容器運(yùn)行時(shí)的屬性。docker-compose用來對(duì)這一組容器進(jìn)行操作。

docker swarm 原生的Docker集群管理工具，依賴docker本身，很多重要功能依賴團(tuán)隊(duì)二次開發(fā)。且社區(qū)不夠活躍，一般公司生產(chǎn)環(huán)境會(huì)選擇k8s，個(gè)人項(xiàng)目或者容器數(shù)量較少可選swarm,只需要docker即可完成，相對(duì)較輕。

5 kubernetes

5.1 什么是k8s?

對(duì)k8s的考察一般逃不過這樣入門級(jí)的問題，針對(duì)入門級(jí)的問題，面試官可能也會(huì)針對(duì)如下幾個(gè)點(diǎn)進(jìn)行考察，在候選人答出來的基礎(chǔ)上，選擇其中一個(gè)進(jìn)行深入。

為什么用k8s 解決了什么問題？

k8s有哪些組件,有什么作用？

可以簡(jiǎn)單說下Node Pod container 之間的關(guān)系嗎？【進(jìn)一步可對(duì)Pod SVC細(xì)節(jié)進(jìn)行考察】

什么是SVC可以簡(jiǎn)單描述下嗎？【可引對(duì)SVC的考察】

可以簡(jiǎn)單講下k8s的網(wǎng)絡(luò)模型嗎？【可以和docker網(wǎng)絡(luò)模型結(jié)合考察】

Pod SVC Node Container 之間如何相互訪問【衍生外部環(huán)境如何訪問k8s】

swarm和k8s如何選擇？

1 什么是k8s 為什么用k8s：

一個(gè)開源的容器集群管理平臺(tái)【容器編排工具】，可提供容器集群的自動(dòng)部署，擴(kuò)縮容，維護(hù)等功能。分為管理節(jié)點(diǎn)Master和工作節(jié)點(diǎn)Node。在我們的項(xiàng)目中主要解決了環(huán)境一致性的問題，通過CI/CD使得運(yùn)維部署變得簡(jiǎn)單起來，以及自動(dòng)部署，故障監(jiān)控，自動(dòng)擴(kuò)縮容。可以提升開發(fā)效率。

2 k8s有那些組件：

etcd保存了整個(gè)集群的狀態(tài)；

apiserver提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制；

controller manager負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等；

scheduler負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；

kubelet負(fù)責(zé)維護(hù)容器的生命周期，同時(shí)也負(fù)責(zé)Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理；

Container runtime負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI）；

kube-proxy負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；

3 Node&Pod&container之間的關(guān)系：Node一般指工作節(jié)點(diǎn)包含多個(gè)Pod Pod中包含多個(gè)Container,Pod中的container共享同一個(gè)網(wǎng)絡(luò)命名空間。

4 什么是SVC: SVC是對(duì)一組功能相似的Pod資源的抽象，相當(dāng)于一組服務(wù)的負(fù)載均衡。

5 k8s的網(wǎng)絡(luò)模型：IP-Per-Pod 每個(gè)Pod有獨(dú)立的Ip地址，無論是否處于同一個(gè)Node節(jié)點(diǎn)，Pod可以通過IP相互訪問，且Pod和容器的地址和外部看到的地址是同一個(gè)地址。

6 Pod SVC Node Container 之間如何相互訪問：

同Pod內(nèi)的容器：同一個(gè)Pod的容器共享同一個(gè)網(wǎng)絡(luò)命名空間可以直接進(jìn)行通訊

同Node內(nèi)不同Pod的容器：多個(gè)Pod都關(guān)聯(lián)在同一個(gè)Docker0網(wǎng)橋上，通過docker0網(wǎng)橋完成相互通訊。

不同Node內(nèi)Pod的容器：不同Node上的docker0可能會(huì)相同，PodIP和docker0是同網(wǎng)段的，所以需要將PodIP和NodeIP進(jìn)行關(guān)聯(lián)且保障唯一，不同Pod之間的數(shù)據(jù)通過物理機(jī)的端口進(jìn)行轉(zhuǎn)發(fā)即可完成通訊。

7： k8s 和docker swarm如何選擇： :

5.2 對(duì)SVC的考察

SVC是k8s中的核心概念這里涉及知識(shí)點(diǎn)眾多常見的面試考點(diǎn)如下

什么是SVC? 如何創(chuàng)建SVC?

使用SVC創(chuàng)建多個(gè)副本和使用RC創(chuàng)建多個(gè)副本有什么差異？

SVC有哪幾種類型？

SVC 負(fù)載分發(fā)策略有那些？

集群外如何訪問SVC?

SVC: 是對(duì)一組功能相似的Pod資源的抽象，相當(dāng)于一組服務(wù)的負(fù)載均衡。可以使用配置文件的方式創(chuàng)建也可以使用命令創(chuàng)建kubectl expose

SVC和RC提供服務(wù)的差距： RC創(chuàng)建的服務(wù)PodIP可能會(huì)變。SVC提供的clusterIP不會(huì)。通過Iptables的NAT轉(zhuǎn)換重定向到本地端口，在均衡到后端Pod。

svc的幾種類型： ClusterIp/NodePort/LoadBalancer/ExternalName

ClusterIp 默認(rèn)類型分配的一個(gè)虛擬地址，內(nèi)部可以相互訪問，外部不行

NodePort 將SVC端口號(hào)映射到物理機(jī)

LoadBalancer 基于NodePort，云服務(wù)商在外部創(chuàng)建了一個(gè)負(fù)載均衡到Pod

ExternalName 將外部地址經(jīng)過集群內(nèi)部的再一次封裝(實(shí)際上就是集群DNS服務(wù)器將CNAME解析到了外部地址上)，實(shí)現(xiàn)了集群內(nèi)部訪問即可。

svc負(fù)載分發(fā)策略： RoundRobin/SessionAffinity/自定義實(shí)現(xiàn)【基于標(biāo)簽選擇器】

集群外部訪問：端口映射到物理機(jī)即可

5.2 Pod考察

Pod和靜態(tài)Pod的區(qū)別

生命周期和重啟策略【這里可擴(kuò)展不同控制器對(duì)Pod的重啟策略要求】

Pod如何健康檢查？

Pod的調(diào)度方式？【擴(kuò)展調(diào)度算法】

Pod如何擴(kuò)縮容？【擴(kuò)展 RC和RS的差異】

答案

待補(bǔ)充 --詳見《k8s權(quán)威指南》讀書筆記

5.3 基礎(chǔ)原理類考察

主要考察對(duì)基本組件的理解和原理分析

API Server

Controller Manager【Replication Controller/Node Controller/ResourceQuota Controller/Namespace Controller/SVC Controller& Endpoint Controller】

Scheduler

Kubelet 【Pod健康檢查資源監(jiān)控】

Kube-Proxy

k8s-DNS & Iptables差異

k8s中Ingress是什么

簡(jiǎn)述k8s中的如下屬性及其作用resources tolerations affinity

k8s中pod、rs、deployment、hpa的基本概念，以及他們之間的關(guān)系

答案

待補(bǔ)充 --詳見《k8s權(quán)威指南》讀書筆記

5.4 網(wǎng)絡(luò)原理類考察

主要考察對(duì)基本組件的理解和原理分析

k8s的網(wǎng)絡(luò)模型是什么？

Docker的網(wǎng)絡(luò)基礎(chǔ)是什么？

Docker的網(wǎng)絡(luò)模型和局限？

k8s的網(wǎng)絡(luò)組件之間是如何通訊的？

外部如何訪問k8s集群？

有那些開源組件支持k8s網(wǎng)絡(luò)模型？

三、服務(wù)器搭建k8s內(nèi)存需要多大

你好！2gb或者4gb都行

1.什么是k8s？

k8s是一個(gè)docker容器管理工具

它是一個(gè)全新的基于容器技術(shù)的分布式架構(gòu)領(lǐng)先方案，是開源的容器集群管理系統(tǒng)。

在docker的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行，資源調(diào)度，服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)伸縮等一系列完整功能

2.----k8s的優(yōu)勢(shì)：

a，容器編排

b，輕量級(jí)

c，開源

d，彈性伸縮

e，負(fù)載均衡

二：k8s的核心功能

1.自愈: 重新啟動(dòng)失敗的容器，在節(jié)點(diǎn)不可用時(shí)，替換和重新調(diào)度節(jié)點(diǎn)上的容器，對(duì)用戶定義的健康檢查不響應(yīng)的容器會(huì)被中止，并且在容器準(zhǔn)備好服務(wù)之前不會(huì)把其向客戶端廣播。

彈性伸縮: 通過監(jiān)控容器的cpu的負(fù)載值,如果這個(gè)平均高于80%,增加容器的數(shù)量,如果這個(gè)平均低于10%,減少容器的數(shù)量

服務(wù)的自動(dòng)發(fā)現(xiàn)和負(fù)載均衡: 不需要修改您的應(yīng)用程序來使用不熟悉的服務(wù)發(fā)現(xiàn)機(jī)制，Kubernetes 為容器提供了自己的 IP 地址和一組容器的單個(gè) DNS 名稱，并可以在它們之間進(jìn)行負(fù)載均衡。

滾動(dòng)升級(jí)和一鍵回滾: Kubernetes 逐漸部署對(duì)應(yīng)用程序或其配置的更改，同時(shí)監(jiān)視應(yīng)用程序運(yùn)行狀況，以確保它不會(huì)同時(shí)終止所有實(shí)例。如果出現(xiàn)問題，Kubernetes會(huì)為您恢復(fù)更改，利用日益增長(zhǎng)的部署解決方案的生態(tài)系統(tǒng)。

四、什么是K8S？

‍

k8s是什么?

Kubernetes 是一個(gè)可移植的，可擴(kuò)展的開源容器編排平臺(tái)，用于管理容器化的工作負(fù)載和服務(wù)，方便了聲明式配置和自動(dòng)化。它擁有一個(gè)龐大且快速增長(zhǎng)的生態(tài)系統(tǒng)。Kubernetes 的服務(wù)，支持和工具廣泛可用。

為什么現(xiàn)在流行使用容器?

早期: 在物理服務(wù)器上面部署應(yīng)用程序存在資源分配問題,因?yàn)槠洳荒茉谖锢矸?wù)器中的應(yīng)用程序定義資源邊界,導(dǎo)致應(yīng)用程序資源利用不足而無法擴(kuò)展.

后來: 為了解決該問題,引入了虛擬化技術(shù), 虛擬化技術(shù)是指允許你在單個(gè)物理服務(wù)器的 CPU 上運(yùn)行多個(gè)虛擬機(jī),可以讓多個(gè)應(yīng)用程序在虛擬機(jī)之間進(jìn)行隔離,具有一定的安全性, 每一個(gè)虛擬機(jī)就是一臺(tái)完整的計(jì)算機(jī), 在虛擬化硬件之上運(yùn)行所有組件.

現(xiàn)在: 多數(shù)在物理服務(wù)器上面部署應(yīng)用程序都是采kubectl用容器的方式,容器類似于虛擬機(jī),它們都具有自己的文件系統(tǒng)、CPU、內(nèi)存、進(jìn)程空間等, 且由于它們與基礎(chǔ)架構(gòu)分離，因此可以跨云和 OS 發(fā)行版本進(jìn)行移植。基于此特點(diǎn)被企業(yè)大范圍使用.

為什么需要使用k8s容器?

若出現(xiàn)這樣一個(gè)環(huán)境: 在生產(chǎn)環(huán)境中如果一個(gè)容器發(fā)生故障,則我們需要手動(dòng)去啟動(dòng)另外一個(gè)容器,這樣的操作是對(duì)我們的管理員來說是不太方便的, 若一個(gè)容器出現(xiàn)故障,另一個(gè)容器可以自動(dòng)啟動(dòng)容器接管故障的容器,這樣是最好的.

k8s就可以實(shí)現(xiàn)該效果,Kubernetes 提供了一個(gè)可彈性運(yùn)行分布式系統(tǒng)的框架。 Kubernetes 會(huì)滿足你的擴(kuò)展要求、故障轉(zhuǎn)移、部署模式等。

k8s功能: 服務(wù)發(fā)現(xiàn)和負(fù)載均衡, 存儲(chǔ)編排, 自動(dòng)部署和回滾, 自動(dòng)完成裝箱計(jì)算, 自我修復(fù), 密鑰與配置管理

名詞解釋

secret

Secret有三種類型：

Service Account：用來訪問Kubernetes API，由Kubernetes自動(dòng)創(chuàng)建，并且會(huì)自動(dòng)掛載到Pod的目錄中；
/run/secrets/kubernetes.io/serviceaccount
Opaque：base64編碼格式的Secret，用來存儲(chǔ)密碼、密鑰等；
kubernetes.io/dockerconfigjson：用來存儲(chǔ)私有docker registry的認(rèn)證信息。

k8s的組成

k8s是由組件,API,對(duì)象等組成.

包含所有相互關(guān)聯(lián)組件的 Kubernetes 集群圖如下:

組件

控制平面組件
- kube-apiserver: 為k8s的api服務(wù)器,公開了所有Kubernetes API, 其他所有組件都必須通過它提供的API來操作資源數(shù)據(jù).
  - 保證集群狀態(tài)訪問的安全
  - 隔離集群狀態(tài)訪問的方式和后端存儲(chǔ)實(shí)現(xiàn)的方式：API Server是狀態(tài)訪問的方式，不會(huì)因?yàn)楹蠖舜鎯?chǔ)技術(shù)etcd的改變而改變。
- etcd: 為k8s的鍵值數(shù)據(jù)庫(kù),保存了k8s所有集群數(shù)據(jù)的后臺(tái)數(shù)據(jù)庫(kù)。
- kube-scheduler: 收集和分析當(dāng)前Kubernetes集群中所有Node節(jié)點(diǎn)的資源(內(nèi)存、CPU)負(fù)載情況，然后依此分發(fā)新建的Pod到Kubernetes集群中可用的節(jié)點(diǎn)。 kube-controller-manager: 在主節(jié)點(diǎn)上運(yùn)行控制器的組件。
- cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制邏輯的控制平面組件
Node 組件
- kubelet: 一個(gè)在集群中每個(gè)節(jié)點(diǎn)（node）上運(yùn)行的代理。它保證容器（containers）都運(yùn)行在 Pod 中。
- kube-proxy: kube-proxy是集群中每個(gè)節(jié)點(diǎn)上運(yùn)行的網(wǎng)絡(luò)代理,維護(hù)節(jié)點(diǎn)上的網(wǎng)絡(luò)規(guī)則。這些網(wǎng)絡(luò)規(guī)則允許從集群內(nèi)部或外部的網(wǎng)絡(luò)會(huì)話與 Pod 進(jìn)行網(wǎng)絡(luò)通信。
- 容器運(yùn)行時(shí): 負(fù)責(zé)運(yùn)行容器的軟件。
插件(Addons)
- DNS: 集群 DNS 是一個(gè) DNS 服務(wù)器，和環(huán)境中的其他 DNS 服務(wù)器一起工作，它為 Kubernetes 服務(wù)提供 DNS 記錄。
- Web 界面（儀表盤）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用戶界面。
- 容器資源監(jiān)控: 容器資源監(jiān)控將關(guān)于容器的一些常見的時(shí)間序列度量值保存到一個(gè)集中的數(shù)據(jù)庫(kù)中，并提供用于瀏覽這些數(shù)據(jù)的界面。
- 集群層面日志: 集群層面日志機(jī)制負(fù)責(zé)將容器的日志數(shù)據(jù) 保存到一個(gè)集中的日志存儲(chǔ)中，該存儲(chǔ)能夠提供搜索和瀏覽接口。

API

Kubernetes 控制面的核心是 API 服務(wù)器。 API 服務(wù)器負(fù)責(zé)提供 HTTP API，以供用戶、集群中的不同部分和集群外部組件相互通信。

對(duì)象

Kubernetes對(duì)象是Kubernetes系統(tǒng)中的持久實(shí)體。Kubernetes使用這些實(shí)體來表示集群的狀態(tài).

具體來說，他們可以描述：

容器化應(yīng)用正在運(yùn)行(以及在哪些節(jié)點(diǎn)上)
這些應(yīng)用可用的資源
關(guān)于這些應(yīng)用如何運(yùn)行的策略，如重新策略，升級(jí)和容錯(cuò)

Kubernetes 架構(gòu)

Kubernetes 架構(gòu)由節(jié)點(diǎn),控制面到節(jié)點(diǎn)通信, 控制器, 云控制器管理器組成.

master 流程圖

Kubecfg將特定的請(qǐng)求，比如創(chuàng)建Pod，發(fā)送給Kubernetes Client。
Kubernetes Client將請(qǐng)求發(fā)送給API server。
API Server根據(jù)請(qǐng)求的類型，比如創(chuàng)建Pod時(shí)storage類型是pods，然后依此選擇何種REST Storage API對(duì)請(qǐng)求作出處理。
REST Storage API對(duì)的請(qǐng)求作相應(yīng)的處理。
將處理的結(jié)果存入高可用鍵值存儲(chǔ)系統(tǒng)Etcd中。
在API Server響應(yīng)Kubecfg的請(qǐng)求后，Scheduler會(huì)根據(jù)Kubernetes Client獲取集群中運(yùn)行Pod及Minion/Node信息。
依據(jù)從Kubernetes Client獲取的信息，Scheduler將未分發(fā)的Pod分發(fā)到可用的Minion/Node節(jié)點(diǎn)上。

節(jié)點(diǎn)

節(jié)點(diǎn)可以是一個(gè)虛擬機(jī)或者物理機(jī)器，取決于所在的集群配置。每個(gè)節(jié)點(diǎn)包含運(yùn)行 Pods 所需的服務(wù)，這些 Pods 由控制面負(fù)責(zé)管理.

節(jié)點(diǎn)上的組件包括 kubelet、容器運(yùn)行時(shí)以及 kube-proxy。

節(jié)點(diǎn)狀態(tài)

可以使用 kubectl 來查看節(jié)點(diǎn)狀態(tài)和其他細(xì)節(jié)信息：

kubectl describe node <�節(jié)點(diǎn)名稱>

一個(gè)節(jié)點(diǎn)包含以下信息:

地址
- HostName：由節(jié)點(diǎn)的內(nèi)核設(shè)置。可以通過 kubelet 的 —hostname-override 參數(shù)覆蓋。
- ExternalIP：通常是節(jié)點(diǎn)的可外部路由（從集群外可訪問）的 IP 地址。
- InternalIP：通常是節(jié)點(diǎn)的僅可在集群內(nèi)部路由的 IP 地址。
狀況(conditions 字段描述了所有 Running 節(jié)點(diǎn)的狀態(tài))
- Ready 如節(jié)點(diǎn)是健康的并已經(jīng)準(zhǔn)備好接收 Pod 則為 True；False 表示節(jié)點(diǎn)不健康而且不能接收 Pod；Unknown 表示節(jié)點(diǎn)控制器在最近 node-monitor-grace-period 期間（默認(rèn) 40 秒）沒有收到節(jié)點(diǎn)的消息
- DiskPressure為True則表示節(jié)點(diǎn)的空閑空間不足以用于添加新 Pod, 否則為 False
- MemoryPressure為True則表示節(jié)點(diǎn)存在內(nèi)存壓力，即節(jié)點(diǎn)內(nèi)存可用量低，否則為 False
- PIDPressure為True則表示節(jié)點(diǎn)存在進(jìn)程壓力，即節(jié)點(diǎn)上進(jìn)程過多；否則為 False
- NetworkUnavailable為True則表示節(jié)點(diǎn)網(wǎng)絡(luò)配置不正確；否則為 False
容量與可分配
- 描述節(jié)點(diǎn)上的可用資源：CPU、內(nèi)存和可以調(diào)度到節(jié)點(diǎn)上的 Pod 的個(gè)數(shù)上限。
信息
- 關(guān)于節(jié)點(diǎn)的一般性信息，例如內(nèi)核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系統(tǒng)名稱。這些信息由 kubelet 從節(jié)點(diǎn)上搜集而來。

控制面到節(jié)點(diǎn)通信

節(jié)點(diǎn)到控制面
- apiserver在安全的 HTTPS 端口（443）上監(jiān)聽遠(yuǎn)程連接請(qǐng)求
- 以客戶端證書的形式將客戶端憑據(jù)提供給 kubelet
控制面到節(jié)點(diǎn)
- API 服務(wù)器到 kubelet連接用于
  - 獲取 Pod 日志
  - 掛接（通過 kubectl）到運(yùn)行中的 Pod
  - 提供 kubelet 的端口轉(zhuǎn)發(fā)功能。
  - (注: 在連接狀態(tài)下, 默認(rèn)apiserver 不檢查 kubelet 的服務(wù)證書。容易受到中間人攻擊，不安全.)
- apiserver 到節(jié)點(diǎn)、Pod 和服務(wù)
  - SSH 隧道(目前已經(jīng)廢棄)
    - 產(chǎn)生原因: 若無服務(wù)證書, 又要求避免在非受信網(wǎng)絡(luò)或公共網(wǎng)絡(luò)上進(jìn)行連接,則可以在apiserver 和 kubelet 之間使用ssh隧道.
    - Kubernetes 支持使用 SSH 隧道來保護(hù)從控制面到節(jié)點(diǎn)的通信路徑。
  - Konnectivity 服務(wù)
    - 為ssh隧道的替代品, Konnectivity 服務(wù)提供 TCP 層的代理，以便支持從控制面到集群的通信。

控制器

在 Kubernetes 中，控制器通過監(jiān)控集群的公共狀態(tài)，并致力于將當(dāng)前狀態(tài)轉(zhuǎn)變?yōu)槠谕臓顟B(tài)。

舉個(gè)例子: 當(dāng)前室內(nèi)溫度為20度, 我們通過調(diào)節(jié)遙控器,使其溫度上升至24度, 這20度到24度的變化即為讓其從當(dāng)前狀態(tài)接近期望狀態(tài)。

控制器模式分為直接控制和通過API服務(wù)器來控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制邏輯的控制平面組件。云控制器管理器允許您鏈接聚合到云提供商的應(yīng)用編程接口中，并分離出相互作用的組件與您的集群交互的組件。

云控制器管理器中的控制器包括：

節(jié)點(diǎn)控制器
- 節(jié)點(diǎn)控制器負(fù)責(zé)在云基礎(chǔ)設(shè)施中創(chuàng)建了新服務(wù)器時(shí)為之創(chuàng)建節(jié)點(diǎn)（Node）對(duì)象。節(jié)點(diǎn)控制器從云提供商獲取當(dāng)前租戶中主機(jī)的信息。
- 執(zhí)行功能:
  - 針對(duì)控制器通過云平臺(tái)驅(qū)動(dòng)的 API 所發(fā)現(xiàn)的每個(gè)服務(wù)器初始化一個(gè) Node 對(duì)象
  - 利用特定云平臺(tái)的信息為 Node 對(duì)象添加注解和標(biāo)簽
  - 獲取節(jié)點(diǎn)的網(wǎng)絡(luò)地址和主機(jī)名
  - 檢查節(jié)點(diǎn)的健康狀況。
路由控制器
- Route 控制器負(fù)責(zé)適當(dāng)?shù)嘏渲迷破脚_(tái)中的路由，以便 Kubernetes 集群中不同節(jié)點(diǎn)上的容器之間可以相互通信。
服務(wù)控制器
- 服務(wù)（Service）與受控的負(fù)載均衡器、 IP 地址、網(wǎng)絡(luò)包過濾、目標(biāo)健康檢查等云基礎(chǔ)設(shè)施組件集成。服務(wù)控制器與云驅(qū)動(dòng)的 API 交互，以配置負(fù)載均衡器和其他基礎(chǔ)設(shè)施組件。

Kubernetes 安全性

云原生安全

云原生安全4個(gè)C: 云(Cloud)、集群(Cluster)、容器(Container)和代碼(Code)

云原生安全模型的每一層都是基于下一個(gè)最外層，代碼層受益于強(qiáng)大的基礎(chǔ)安全層（云、集群、容器）。我們無法通過在代碼層解決安全問題來為基礎(chǔ)層中糟糕的安全標(biāo)準(zhǔn)提供保護(hù)。

基礎(chǔ)設(shè)施安全

Kubetnetes 基礎(chǔ)架構(gòu)關(guān)注領(lǐng)域

建議

通過網(wǎng)絡(luò)訪問 API 服務(wù)（控制平面)

所有對(duì) Kubernetes 控制平面的訪問不允許在 Internet 上公開，同時(shí)應(yīng)由網(wǎng)絡(luò)訪問控制列表控制，該列表包含管理集群所需的 IP 地址集。

通過網(wǎng)絡(luò)訪問 Node（節(jié)點(diǎn))

節(jié)點(diǎn)應(yīng)配置為僅能從控制平面上通過指定端口來接受（通過網(wǎng)絡(luò)訪問控制列表）連接，以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務(wù)連接。如果可能的話，這些節(jié)點(diǎn)不應(yīng)完全暴露在公共互聯(lián)網(wǎng)上。

Kubernetes 云訪問提供商的 API

每個(gè)云提供商都需要向 Kubernetes 控制平面和節(jié)點(diǎn)授予不同的權(quán)限集。為集群提供云提供商訪問權(quán)限時(shí)，最好遵循對(duì)需要管理的資源的最小特權(quán)原則。Kops 文檔提供有關(guān) IAM 策略和角色的信息。

訪問 etcd

對(duì) etcd（Kubernetes 的數(shù)據(jù)存儲(chǔ)）的訪問應(yīng)僅限于控制平面。根據(jù)配置情況，你應(yīng)該嘗試通過 TLS 來使用 etcd。更多信息可以在 etcd 文檔中找到。

etcd 加密

在所有可能的情況下，最好對(duì)所有驅(qū)動(dòng)器進(jìn)行靜態(tài)數(shù)據(jù)加密，但是由于 etcd 擁有整個(gè)集群的狀態(tài)（包括機(jī)密信息），因此其磁盤更應(yīng)該進(jìn)行靜態(tài)數(shù)據(jù)加密。

集群組件安全

運(yùn)行的應(yīng)用程序的安全性關(guān)注領(lǐng)域
- 訪問控制授權(quán)(訪問 Kubernetes API)
- 認(rèn)證方式
- 應(yīng)用程序 Secret 管理 (并在 etcd 中對(duì)其進(jìn)行靜態(tài)數(shù)據(jù)加密)
- Pod 安全策略
- 服務(wù)質(zhì)量（和集群資源管理）
- 網(wǎng)絡(luò)策略
- Kubernetes Ingress 的 TLS 支持

容器安全

容器安全性關(guān)注領(lǐng)域
- 容器搭建配置(配置不當(dāng),危險(xiǎn)掛載, 特權(quán)用戶)
- 容器服務(wù)自身缺陷
- Linux內(nèi)核漏洞
- 鏡像簽名和執(zhí)行

代碼安全

代碼安全關(guān)注領(lǐng)域
- 僅通過 TLS 訪問(流量加密)
- 限制通信端口范圍
- 第三方依賴性安全
- 靜態(tài)代碼分析
- 動(dòng)態(tài)探測(cè)攻擊(黑盒)

Kubernetes架構(gòu)常見問題

Kubernetes ATTACK 矩陣

信息泄露

云賬號(hào)AK泄露

API憑證（即阿里云AccessKey）是用戶訪問內(nèi)部資源最重要的身份憑證。用戶調(diào)用API時(shí)的通信加密和身份認(rèn)證會(huì)使用API憑證.

API憑證是云上用戶調(diào)用云服務(wù)API、訪問云上資源的唯一身份憑證。

API憑證相當(dāng)于登錄密碼，用于程序方式調(diào)用云服務(wù)API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有關(guān)Kubernetes集群的詳細(xì)信息，包括它們的位置和憑據(jù)。

云廠商會(huì)給用戶提供該文件,以便于用戶可以通過kubectl對(duì)集群進(jìn)行管理. 如果攻擊者能夠訪問到此文件（如辦公網(wǎng)員工機(jī)器入侵、泄露到Github的代碼等），就可以直接通過API Server接管K8s集群，帶來風(fēng)險(xiǎn)隱患。

Master節(jié)點(diǎn)SSH登錄泄露

常見的容器集群管理方式是通過登錄Master節(jié)點(diǎn)或運(yùn)維跳板機(jī)，然后再通過kubectl命令工具來控制k8s。

云服務(wù)器提供了通過ssh登陸的形式進(jìn)行登陸master節(jié)點(diǎn).

若Master節(jié)點(diǎn)SSH連接地址泄露,攻擊者可對(duì)ssh登陸進(jìn)行爆破,從而登陸上ssh,控制集群.

容器組件未鑒權(quán)服務(wù)

Kubernetes架構(gòu)下常見的開放服務(wù)指紋如下:

kube-apiserver: 6443, 8080
kubectl proxy: 8080, 8081
kubelet: 10250, 10255, 4149
dashboard: 30000
docker api: 2375
etcd: 2379, 2380
kube-controller-manager: 10252
kube-proxy: 10256, 31442
kube-scheduler: 10251
weave: 6781, 6782, 6783
kubeflow-dashboard: 8080

注:前六個(gè)重點(diǎn)關(guān)注: 一旦被控制可以直接獲取相應(yīng)容器、相應(yīng)節(jié)點(diǎn)、集群權(quán)限的服務(wù)

了解各個(gè)組件被攻擊時(shí)所造成的影響

組件分工圖:

假如用戶想在集群里面新建一個(gè)容器集合單元, 流程如下:

用戶與 kubectl進(jìn)行交互,提出需求(例: kubectl create -f pod.yaml)
kubectl 會(huì)讀取 ~/.kube/config 配置，并與 apiserver 進(jìn)行交互，協(xié)議：http/https
apiserver 會(huì)協(xié)同 ETCD, kube-controller-manager, scheduler 等組件準(zhǔn)備下發(fā)新建容器的配置給到節(jié)點(diǎn)，協(xié)議：http/https
apiserver 與 kubelet 進(jìn)行交互，告知其容器創(chuàng)建的需求，協(xié)議：http/https；
kubelet 與Docker等容器引擎進(jìn)行交互，創(chuàng)建容器，協(xié)議：http/unix socket.
容器已然在集群節(jié)點(diǎn)上創(chuàng)建成功

攻擊apiserver

apiserver介紹:

在Kubernetes中,對(duì)于未鑒權(quán)對(duì)apiserver, 能訪問到 apiserver 一般情況下就能獲取了集群的權(quán)限.

在攻擊者眼中Kubernetes APIServer

容器編排K8S總控組件
pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,
endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,
persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …
可控以上所有k8s資源
可獲取幾乎所有容器的交互式shell
利用一定技巧可獲取所有容器母機(jī)的交互式shell

默認(rèn)情況下apiserver都有鑒權(quán):

未鑒權(quán)配置如下:

對(duì)于這類的未鑒權(quán)的設(shè)置來說，訪問到 apiserver 一般情況下就獲取了集群的權(quán)限：

如何通過apiserver來進(jìn)行滲透,可參考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

攻擊kubelet

每一個(gè)Node節(jié)點(diǎn)都有一個(gè)kubelet(每個(gè)節(jié)點(diǎn)上運(yùn)行的代理)服務(wù)，kubelet監(jiān)聽了10250，10248，10255等端口。

10250端口,是kubelet與apiserver進(jìn)行通信對(duì)主要端口, 通過該端口,kubelet可以知道當(dāng)前應(yīng)該處理的任務(wù).該端口在最新版Kubernetes是有鑒權(quán)的, 但在開啟了接受匿名請(qǐng)求的情況下，不帶鑒權(quán)信息的請(qǐng)求也可以使用10250提供的能力, 在Kubernetes早期,很多挖礦木馬基于該端口進(jìn)行傳播.

在配置文件中,若進(jìn)行如下配置,則可能存在未授權(quán)訪問漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授權(quán)訪問漏洞,我們可以直接訪問/pods進(jìn)行查看

根據(jù)在pods中獲取的信息,我們可以在容器中執(zhí)行命令

curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} -d 'input=1' -d 'output=1' -d 'tty=1' -d 'command=whoami'

上述命令得到websocket地址，連接websocket得到命令結(jié)果：

使用wscat工具連接websocket

wscat -c “https://X.X.X.X:10250/{websocket}” --no-check

即可得到我們執(zhí)行命令的結(jié)果.

獲取token

/var/run/secrets/kubernetes.io/serviceaccount

然后即可訪問kube-api server,獲取集群權(quán)限

curl -ks -H "Authorization: Bearer ttps://master:6443/api/v1/namespaces/{namespace}/secrets

攻擊kubelet總體步驟如下:

訪問pods獲取信息
獲取namespace、podsname、containername
執(zhí)行exec獲取token
/var/run/secrets/kubernetes.io/serviceaccount
利用Token訪問API Server進(jìn)行對(duì)pods操作。

攻擊dashboard

dashboard登陸鏈接如下:

http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的圖形化界面.在Kubernetes配置不當(dāng)導(dǎo)致dashboard未授權(quán)訪問漏洞的情況下，通過dashboard我們可以控制整個(gè)集群。

默認(rèn)情況下, dashboard是需要進(jìn)行鑒權(quán)操作的,當(dāng)用戶開啟了enable-skip-login時(shí)可以在登錄界面點(diǎn)擊Skip跳過登錄進(jìn)入dashboard.

通過skip登陸的dashboard默認(rèn)是沒有操作集群的權(quán)限,因?yàn)镵ubernetes使用RBAC(Role-based access control)機(jī)制進(jìn)行身份認(rèn)證和權(quán)限管理，不同的serviceaccount擁有不同的集群權(quán)限。

但有些開發(fā)者為了方便或者在測(cè)試環(huán)境中會(huì)為Kubernetes-dashboard綁定cluster-admin這個(gè)ClusterRole（cluster-admin擁有管理集群的最高權(quán)限）.

為Kubernetes-dashboard綁定cluster-admin 設(shè)置如下:

新建dashboard-admin.yaml內(nèi)容
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
kubectl create -f dashboard-admin.yaml

后通過skip登陸dashboard便有了管理集群的權(quán)限.

創(chuàng)建Pod控制node節(jié)點(diǎn),該pod主要是將宿主機(jī)根目錄掛載到容器tmp目錄下。

新建一個(gè)Pod如下:

通過該容器的tmp目錄管理node節(jié)點(diǎn)的文件

攻擊etcd

Kubernetes默認(rèn)使用了etcd v3來存儲(chǔ)數(shù)據(jù), 若能na

etcd對(duì)內(nèi)暴露2379端口，本地127.0.0.1可免認(rèn)證訪問. 其他地址要帶—endpoint參數(shù)和cert進(jìn)行認(rèn)證。

未授權(quán)訪問流程:

檢查是否正常鏈接
etcdctl endpoint health
讀取service account token
etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
通過token認(rèn)訪問API-Server端口6443，接管集群：
kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="[ey...]" -n kube-system get pods

攻擊docker remote api(Docker daemon公網(wǎng)暴露)

2375是docker遠(yuǎn)程操控的默認(rèn)端口，通過這個(gè)端口可以直接對(duì)遠(yuǎn)程的docker 守護(hù)進(jìn)程進(jìn)行操作。Docker 守護(hù)進(jìn)程默認(rèn)監(jiān)聽2375端口且未鑒權(quán).

當(dāng)機(jī)器以方式啟動(dòng)daemon時(shí)，可以在外部機(jī)器對(duì)該機(jī)器的docker daemon進(jìn)行直接操作：

docker daemon -H=0.0.0.0:2375

之后依次執(zhí)行systemctl daemon-reload、systemctl restart docker

外部主機(jī)使用即可操作暴露2375端口的主機(jī).

-H

因此當(dāng)你有訪問到目標(biāo)Docker API 的網(wǎng)絡(luò)能力或主機(jī)能力的時(shí)候，你就擁有了控制當(dāng)前服務(wù)器的能力。我們可以利用Docker API在遠(yuǎn)程主機(jī)上創(chuàng)建一個(gè)特權(quán)容器，并且掛載主機(jī)根目錄到容器.

檢測(cè)目標(biāo)是否存在docker api未授權(quán)訪問漏洞的方式也很簡(jiǎn)單，訪問http://[host]:[port]/info路徑是否含有ContainersRunning、DockerRootDir等關(guān)鍵字。

攻擊kubectl proxy

二次開發(fā)所產(chǎn)生的問題

管理Kubernetes無論是使用 kubectl 或 Kubernetes dashboard 的UI功能，其實(shí)都是間接在和 APIServer 做交互.

如果有需求對(duì)k8s進(jìn)行二次開發(fā)的話,大部分的開發(fā)功能請(qǐng)求了 APIServer 的 Rest API 從而使功能實(shí)現(xiàn)的。

例如: