前陣子客戶那邊有個問題需要先了解 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 分享給大家

最近雖然受到 COVID-19 影響導致有些國外專案進度有點落後，但就 OpenShift 4 功能本身不知道為啥成長幅度變的蠻快的…有時候想跟也很難跟上，只能透過影片來了解，然後 Red Hat 本家不知道哪根筋不對了，跑去 Twitch (!!??) 開了一個頻道 RedHatOpenShift Twitch，三不五時就開直播上演下圖的狀況，相當有事

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