前陣子客戶那邊有個問題需要先了解 Kubernetes 從部署 Deployment 到實際上跟這些主要組件溝通的流程，不然很難進行 Troubleshooting (a.k.a. 觀落陰)。幸好本次研究有 3 位大大的一起參與 Max、地瓜、喜德，最終找到了一個跟現象毫無關係的根本問題 =_=，但因為過程算蠻難得的，特別記錄下來給大家參考參考

照例講個雜事，Red Hat OpenShift 4.6 (等同 Kubernetes 1.19) 要出啦！這是一個可以一路用到 2022 年 3 月 的版本，各位 Infra 不用在為了更新和升級落淚了 Q_Q，有興趣者可以參考 What’s New in OpenShift Container Platform 4.6

最近這一個月出了一些事，導致太久沒寫廢文。最近有個需求需要逆向研究出 Red Hat OpenShift 4 原生安裝後，它預設安裝一堆的 Namespace (在 OpenShift 稱作 Project，但在這邊可以視為一樣)，各自的 CPU / Memory / Storage 資源消耗多少，身為一位計算資源精算師，所以就有了下面這篇的紀錄

本月無心力，無梗圖呈現

這幾週常被問到一個問題

以技術觀點來看，請問容器 (Container) 或者是容器平台 (Kubernetes) 比較適合部署在虛擬環境 (VM) 中還是裸機環境中 (Bare Metal)?

其實這個問題在十年前虛擬機技術剛出來的時候，也蠻多人做過架構及性能比較，時光快轉到現在的年代，來到容器的世代，相同的問題也被拿出來討論，本篇就是要特別講述一下關於這些架構上的比較分析、使用影響及建議採用的策略作法建議，這篇會採用比較中立的角度闡述，如果有觀點太偏頗的地方，可以私下跟我說及提供修改建議

不免俗的我還是要來講一下本次新發現，三個感覺不會同框的公司 Microsoft + Red Hat + HPE 一起出了本架構書 HPE Reference Architecture for delivering insight across all your data with Microsoft SQL Server 2019 Big Data Clusters 我覺得實在太玄了 XD 分享給大家

打從 Kubernetes 1.15 之後，OpenShift 的版本迭代速度就是落差一版而已，在那之前基本上都是兩版的差距，這一切都是為了 Kubernetes 的版本生命週期規定 的教條而改變的…