正文

kubernetes負載均衡（kubernetes負載均衡訪問地址）

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

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

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

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

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

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

本文目錄:

1、K8S有什么作用？
2、docker 和 k8s 面試總結
3、服務器搭建k8s內存需要多大
4、什么是K8S？

kubernetes負載均衡（kubernetes負載均衡訪問地址）

一、K8S有什么作用？

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

花了大半個月對k8s&docker進行了梳理，包括之前讀過的書，官方文檔以及k&d在公司項目的實踐等。

以下是個人對docker & k8s 面試知識點的總結：

1 docker

常見面試題如下每一點可根據(jù)回答進行適當深入

1.1 什么是docker

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

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

如何理解docker的緩存機制？

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

docker的網(wǎng)絡基礎是什么？

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

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

1.3 docker 基礎命令

cmd和entryPoint差異？

copy和add的差異？

簡單講下swam/compose？

2 kubernetes

常見面試題如下每一點可根據(jù)回答進行適當深入

2.1 什么是k8s?

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

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

3 可以簡單說下Node Pod container 之間的關系嗎？【可引入2.2/2.3對Pod SVC的考察】

4 什么是SVC可以簡單描述下嗎？【可引入2.3對SVC的考察】

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

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

7 swarm和k8s如何選擇？

2.2 考察Pod

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

簡單講下Pod的生命周期重啟策略呢？

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

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

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

簡單說下Pod的調度方式？

2.3 考察SVC

SVC有哪4種類型

2.4 k8s網(wǎng)絡模型

DNS和Iptables在k8s中的運用？有何差異

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

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

3 參考答案

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

4 docker

問題和答案如下

4.1 什么是docker？

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

如果這個都無法回答，那么接下來的docker考察也就毫無意義了，此問題通常也會結合以下問題來進行考察。

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

docker都有哪些核心組件？

可以簡單說下docker的架構嗎？

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

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

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

docker組件： docker引擎【包含Docker客戶端&服務端】,docker鏡像，docker容器，Registry【鏡像倉庫】

docker的架構: C/s架構

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

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

這里也經(jīng)常會結合K8s網(wǎng)絡原理進行考察，以及如下幾個考點

docker的網(wǎng)絡基礎是什么？

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

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

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

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

4.3 docker 基礎命令

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

cmd和entry差異？

copy和add的差異？

docker-compose & docker swarm？

CMD & ENTRYPONIT

都是容器操作指令：

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

注意區(qū)別docker run 和RUN 一個是容器啟動命令，一個是鏡像構建時候所用。

copy & add

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

docker-compose & docker swarm

使用Docker compose可以用YAML文件來定義一組需要啟動的容器，以及容器運行時的屬性。docker-compose用來對這一組容器進行操作。

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

5 kubernetes

5.1 什么是k8s?

對k8s的考察一般逃不過這樣入門級的問題，針對入門級的問題，面試官可能也會針對如下幾個點進行考察，在候選人答出來的基礎上，選擇其中一個進行深入。

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

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

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

什么是SVC可以簡單描述下嗎？【可引對SVC的考察】

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

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

swarm和k8s如何選擇？

1 什么是k8s 為什么用k8s：

一個開源的容器集群管理平臺【容器編排工具】，可提供容器集群的自動部署，擴縮容，維護等功能。分為管理節(jié)點Master和工作節(jié)點Node。在我們的項目中主要解決了環(huán)境一致性的問題，通過CI/CD使得運維部署變得簡單起來，以及自動部署，故障監(jiān)控，自動擴縮容?？梢蕴嵘_發(fā)效率。

2 k8s有那些組件：

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

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

controller manager負責維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；

scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；

kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網(wǎng)絡（CNI）的管理；

Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；

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

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

4 什么是SVC: SVC是對一組功能相似的Pod資源的抽象，相當于一組服務的負載均衡。

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

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

同Pod內的容器：同一個Pod的容器共享同一個網(wǎng)絡命名空間可以直接進行通訊

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

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

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

5.2 對SVC的考察

SVC是k8s中的核心概念這里涉及知識點眾多常見的面試考點如下

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

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

SVC有哪幾種類型？

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

集群外如何訪問SVC?

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

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

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

ClusterIp 默認類型分配的一個虛擬地址，內部可以相互訪問，外部不行

NodePort 將SVC端口號映射到物理機

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

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

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

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

5.2 Pod考察

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

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

Pod如何健康檢查？

Pod的調度方式？【擴展調度算法】

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

答案

待補充 --詳見《k8s權威指南》讀書筆記

5.3 基礎原理類考察

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

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是什么

簡述k8s中的如下屬性及其作用resources tolerations affinity

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

答案

待補充 --詳見《k8s權威指南》讀書筆記

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

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

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

Docker的網(wǎng)絡基礎是什么？

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

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

外部如何訪問k8s集群？

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

三、服務器搭建k8s內存需要多大

你好！2gb或者4gb都行

1.什么是k8s？

k8s是一個docker容器管理工具

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

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

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

a，容器編排

b，輕量級

c，開源

d，彈性伸縮

e，負載均衡

二：k8s的核心功能

1.自愈: 重新啟動失敗的容器，在節(jié)點不可用時，替換和重新調度節(jié)點上的容器，對用戶定義的健康檢查不響應的容器會被中止，并且在容器準備好服務之前不會把其向客戶端廣播。

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

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

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

四、什么是K8S？

‍

k8s是什么?

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

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

早期: 在物理服務器上面部署應用程序存在資源分配問題,因為其不能在物理服務器中的應用程序定義資源邊界,導致應用程序資源利用不足而無法擴展.

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

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

為什么需要使用k8s容器?

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

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

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

名詞解釋

secret

Secret有三種類型：

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

k8s的組成

k8s是由組件,API,對象等組成.

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

組件

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

API

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

對象

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

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

容器化應用正在運行(以及在哪些節(jié)點上)
這些應用可用的資源
關于這些應用如何運行的策略，如重新策略，升級和容錯

Kubernetes 架構

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

master 流程圖

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

節(jié)點

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

節(jié)點上的組件包括 kubelet、容器運行時以及 kube-proxy。

節(jié)點狀態(tài)

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

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

一個節(jié)點包含以下信息:

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

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

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

控制器

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

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

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

云控制器管理器

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

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

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

Kubernetes 安全性

云原生安全

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

云原生安全模型的每一層都是基于下一個最外層，代碼層受益于強大的基礎安全層（云、集群、容器）。我們無法通過在代碼層解決安全問題來為基礎層中糟糕的安全標準提供保護。

基礎設施安全

Kubetnetes 基礎架構關注領域

建議

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

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

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

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

Kubernetes 云訪問提供商的 API

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

訪問 etcd

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

etcd 加密

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

集群組件安全

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

容器安全

容器安全性關注領域
- 容器搭建配置(配置不當,危險掛載, 特權用戶)
- 容器服務自身缺陷
- Linux內核漏洞
- 鏡像簽名和執(zhí)行

代碼安全

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

Kubernetes架構常見問題

Kubernetes ATTACK 矩陣

信息泄露

云賬號AK泄露

API憑證（即阿里云AccessKey）是用戶訪問內部資源最重要的身份憑證。用戶調用API時的通信加密和身份認證會使用API憑證.

API憑證是云上用戶調用云服務API、訪問云上資源的唯一身份憑證。

API憑證相當于登錄密碼，用于程序方式調用云服務API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

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

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

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

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

云服務器提供了通過ssh登陸的形式進行登陸master節(jié)點.

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

容器組件未鑒權服務

Kubernetes架構下常見的開放服務指紋如下:

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

注:前六個重點關注: 一旦被控制可以直接獲取相應容器、相應節(jié)點、集群權限的服務

了解各個組件被攻擊時所造成的影響

組件分工圖:

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

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

攻擊apiserver

apiserver介紹:

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

在攻擊者眼中Kubernetes APIServer

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

默認情況下apiserver都有鑒權:

未鑒權配置如下:

對于這類的未鑒權的設置來說，訪問到 apiserver 一般情況下就獲取了集群的權限：

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

攻擊kubelet

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

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

在配置文件中,若進行如下配置,則可能存在未授權訪問漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授權訪問漏洞,我們可以直接訪問/pods進行查看

根據(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得到命令結果：

使用wscat工具連接websocket

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

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

獲取token

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

然后即可訪問kube-api server,獲取集群權限

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進行對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配置不當導致dashboard未授權訪問漏洞的情況下，通過dashboard我們可以控制整個集群。

默認情況下, dashboard是需要進行鑒權操作的,當用戶開啟了enable-skip-login時可以在登錄界面點擊Skip跳過登錄進入dashboard.

通過skip登陸的dashboard默認是沒有操作集群的權限,因為Kubernetes使用RBAC(Role-based access control)機制進行身份認證和權限管理，不同的serviceaccount擁有不同的集群權限。

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

為Kubernetes-dashboard綁定cluster-admin 設置如下:

新建dashboard-admin.yaml內容
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便有了管理集群的權限.

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

新建一個Pod如下:

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

攻擊etcd

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

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

未授權訪問流程:

檢查是否正常鏈接
etcdctl endpoint health
讀取service account token
etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
通過token認訪問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遠程操控的默認端口，通過這個端口可以直接對遠程的docker 守護進程進行操作。Docker 守護進程默認監(jiān)聽2375端口且未鑒權.

當機器以方式啟動daemon時，可以在外部機器對該機器的docker daemon進行直接操作：

docker daemon -H=0.0.0.0:2375

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

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

-H

因此當你有訪問到目標Docker API 的網(wǎng)絡能力或主機能力的時候，你就擁有了控制當前服務器的能力。我們可以利用Docker API在遠程主機上創(chuàng)建一個特權容器，并且掛載主機根目錄到容器.

檢測目標是否存在docker api未授權訪問漏洞的方式也很簡單，訪問http://[host]:[port]/info路徑是否含有ContainersRunning、DockerRootDir等關鍵字。

攻擊kubectl proxy

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

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