這幾週常被問到一個問題
以技術觀點來看，請問容器 (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 的版本生命週期規定 的教條而改變的…
這世界上沒有完美的架構，只有權衡後的辦法，但…
來一個圖文不符的 RHEL 網路線路圖，架構圖百百種，每個角色跟角度看的樣子都會不太一樣，這張圖目的是要呈現 OS 上的網卡跟網段對應的關係，算是蠻常見的網路架構表示法，一般習慣上我都是畫成像是五線譜ㄧ樣，比較好清楚表示每個角色的相呼關係，大家可以參考參考
但今天要特別講一下關於 OpenShift 本身的角度，我是怎麼看待這些抽象網路邏輯的，這跟如果要整第三方 SDN 解決方案有直接的關係
承襲上文 Red Hat OpenShift 4 的 etcd 之幾個你應該要知道的事之一，繼續針對硬碟的部分進行調整，畢竟 etcd 對硬碟 IOPS 相當要求，建議用 SSD 比較好
沒意外的，開場分享個 Deploying OpenShift 4.4 to VMware vSphere 7，整體上比較重要的是利用 VMware vSphere 7 裡面的 DRS (Dynamic Resource Scheduler) 及 NSX-T 的部分，之後有機會再說