不知道各位看了這麼久的容器平台 (Container Platform) 技術，一聽到 Kubernetes 的反應，是如何在腦袋中反射出技術堆棧圖 (Technology Stack) 的呢？今天要來分享一下筆者針對於 Kubernetes 容器平台，如何看待加固 (Hardening) 及系統基礎保護的技術觀點，本篇因沒有涉及到資安弱掃，故以強固化 (Hardening) 作為出發點

建立好一座 Kubernetes / OpenShift 集群後，大部分的疑難排解文章都是教你如何從 Kubernetes / OpenShift 的角度，透過 Kubernetes 的 kubectl 或 OpenShift 的 oc 指令來進行一系列的偵查，而這個查詢的結果都是基於 kube-apiserver 為核心的結果，中間已經抽象過很多層，距離底層資訊已有段距離。

若今天想要特意建立一個 Container 出來，用來進行 OS 或 Kubernetes 層級的 Troubleshooting 該如何實作呢?

資料中心東西南北向網路流

一般討論的資料中心資料流量，主要分為兩大流向

• 南北向 (North-South Traffic): Client 與 Server 之間的網路流量
• 東西向 (East-West Traffic): Server 與 Server 之間的網路流量

那如果套用在 Red Hat OpenShift v3.11 容器平台架構下，那實際網路流量是如何對應?

一日江湖行走，路上撿到一個問題：Nvidia DGX 要怎麼跟透過容器化調度應用呀? 然後我就開始了一連串的研究探索…

在小弟先前的演講中 20190218_OpenShift Storage 架構思考，有提到針對每個容器在容器平台 (Kubernetes / OpenShift / …) 上，所儲存的資料會分為三大種架構類型：

1. Data in the Container
2. Data in a Host Volume
3. Data in a Shared Storage

但我那天沒講的事情是，這些 Backend Storage 的類型應該要選擇什麼是比較恰當的？所以下面整理了一下

Red Hat OpenShift v3.11 架構裡網路主要分為三大塊:

1. Hosts subnet
2. Service subnet
3. Pod subnet

最近 VMWare NSX-T 出了一篇跟 Red Hat OpenShift 3.11 的整合文章及影片，下圖的整體技術架構上是十分靠譜的，但有些點是可以另外加入考慮的，但本文不贅述，