容器平台強固化保護思路
不知道各位看了這麼久的容器平台 (Container Platform) 技術,一聽到 Kubernetes 的反應,是如何在腦袋中反射出技術堆棧圖 (Technology Stack) 的呢?今天要來分享一下筆者針對於 Kubernetes 容器平台,如何看待加固 (Hardening) 及系統基礎保護的技術觀點,本篇因沒有涉及到資安弱掃,故以強固化 (Hardening) 作為出發點
不知道各位看了這麼久的容器平台 (Container Platform) 技術,一聽到 Kubernetes 的反應,是如何在腦袋中反射出技術堆棧圖 (Technology Stack) 的呢?今天要來分享一下筆者針對於 Kubernetes 容器平台,如何看待加固 (Hardening) 及系統基礎保護的技術觀點,本篇因沒有涉及到資安弱掃,故以強固化 (Hardening) 作為出發點
建立好一座 Kubernetes / OpenShift 集群後,大部分的疑難排解文章都是教你如何從 Kubernetes / OpenShift 的角度,透過 Kubernetes 的 kubectl
或 OpenShift 的 oc
指令來進行一系列的偵查,而這個查詢的結果都是基於 kube-apiserver
為核心的結果,中間已經抽象過很多層,距離底層資訊已有段距離。
若今天想要特意建立一個 Container 出來,用來進行 OS 或 Kubernetes 層級的 Troubleshooting 該如何實作呢?
一般討論的資料中心資料流量,主要分為兩大流向
那如果套用在 Red Hat OpenShift v3.11 容器平台架構下,那實際網路流量是如何對應?
一日江湖行走,路上撿到一個問題:Nvidia DGX 要怎麼跟透過容器化調度應用呀?
然後我就開始了一連串的研究探索…
在小弟先前的演講中 20190218_OpenShift Storage 架構思考,有提到針對每個容器在容器平台 (Kubernetes / OpenShift / …) 上,所儲存的資料會分為三大種架構類型:
但我那天沒講的事情是,這些 Backend Storage 的類型應該要選擇什麼是比較恰當的?所以下面整理了一下
Red Hat OpenShift v3.11 架構裡網路主要分為三大塊: