Kubernetes 中最基本的運作單元是 Pod，基於 Pod 之上則有各種不同作用的高階抽象層，譬如 DaemonSet, Job, Deployment 等。
使用 Kubernetes 來部署應用程式時，遲早都要面臨資源使用的問題，到底每個 Pod 要使用多少的 CPU/Memory，同時如果是 Deployment 時到底要設定多少個 replica 來符合應用程式的需求。

Kubernetes 提供了 HPA 的方式來水平擴展 Pod 的數量，透過 HPA 的幫助， Pod 的數量可以根據當前的使用情況而自動改變。前述提到除了數量外， CPU 與 Memory 的設定也是一個煩惱的議題，因此就有一個名為 VPA (Vertical Pod Autoscaler) 的專案來處理這個情況，根據當前 Pod 的運行情況來調整 CPU/Memory 的設定(Request/Limit)。

這個專案並非 Kubernetes 的內建資源，必須要額外安裝相關的 CRD 與 Controller 來使用
今天這篇文章針對 VPA 的專案進行詳細的介紹，包括如何安裝，基本架構介紹， VPA 的概念以及使用上的限制都有詳細介紹。

特別要注意的是 VPA 與 HPA 不能同時針對一個 Pod 使用，否則會出現不可預期的行為。這部分也可以理解，畢竟兩個專案並沒有良好的整合，因此兩個 Controller 都會互相一直調整 Pod 行為時，可能會導致不預期的結果。


對於 VPA 這種調整 CPU/Memory (Request/Limut) 專案有興趣的人不仿參考下列文章
https://medium.com/infrastructure-adventures/vertical-pod-autoscaler-deep-dive-limitations-and-real-world-examples-9195f8422724

本文是一篇 2017 年的文章，雖然已經四年之久，但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container，而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的，透過對這些底層實作的瞭解，才有辦法針對 Container 效能部分去除錯與提升。

這種文章探討的都是很底層的概念，建議所有人都閱讀一遍，好好複習關於 cgroups/namespace 的概念，透過對這些概念的理解與掌握，能夠更有系統的去解釋何謂Docker Container，何謂輕量級虛擬化。

以下幫大家節錄一些重點，還是推薦自行閱讀全文

1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性，不同 namespace 內看到的資訊是獨立的，但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範，不同發行版其位置不同，譬如 /sys/fs/cgropu.

假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace，接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式，因為除了 Host 本身外，每個 pid namespace 都有自己的老爸，而老爸是可以看到小孩資訊的，這意味 docker dameon 雖然創建新的 pid namespace，但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看，可以看到該 Java 應用程式也會有一個不同的 PID，而這個 PID 也會於 cgroup 系統中有自己的設定

4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間，相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境，三個 Container Task 分別給予 2048,1024,1024 share 的話，第一個 Container 大致是會被分配到兩個 CPU Time

5. CPU shares 沒有辦法去保證每個 task 最小用量是多少，所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內，你最小可以使用多少時間，所以假如設定 cfs_quota_us 為 100ms，則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU

k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577


6. JVM 看到的是系統上全部的 CPU 資源，但是 Contaienr 本身當被限制 CPU 用量時，會有資訊落差，造成 GC 運行的效果不如預期，因為其認為系統有超多 CPU，而不知道自己其實被限制的CPU很少。

原文滿精彩的，推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling

今天這篇文章是經驗談，由 Intuit 的人來探討管理 200 個不同大小 Kubernetes Cluster 上關於 Scale 的各種經驗。Intuit 同時管理由 AWS EKS 提供的 Kubernetes 服務以及地端自行架設管理的 K8s。

針對 Scale 這個議題，其探討了五個面向帶來的各種挑戰，每個挑戰分成
1. What -> 這個議題要探討什麼
2. How -> 如何做
3. Benefits -> 帶來的好處
4. Leaning -> 學到的經驗

這五個議題分別是
1. Vertical Scale
2. Horizontal Scale
3. Reliability
4. Upgrade
5. Stability

整篇文章算偏長，這邊針對第一個議題進行介紹，對於後續有興趣的人可以在參閱全文

Vertical Scale
What:
目標就是提高應用程式的效能，主要方向是
1) 找到合適的機器規格等級
2) 應用程式根據機器規格能夠最佳化其效能
3) 提升整體的 TPS 數值

How:
1) 針對 GC 的規則調整，提升應用程式效能
2) 節點規格調整，從 Largr -> 4XLarge
3) 確認限定的 CPU/Memory 中可以運行多少個 Pod
4) 使用 HAP 來調整 Pod 的數量

Benefits:
1) TPS 從一開始轉移的 10TPS 提升到最高 10K TPS

Learning:
1) 動態建立節點且將服務部署上去大概需要 5-7 分鐘的時間，事先創好節點的話可以節省時間
2) 團隊需要於 10 分鐘內 scale 超過100以上的資源，這部分預設的 HPA 沒有辦法順利達成，團隊真的問題修改 Scale 的條件

對全文有興趣的可以參考看看，裡面文章滿長的，並不是很容易讀懂全部，需要閱讀多次才好懂。
https://sumitnagal.medium.com/operating-kubernetes-at-scale-65a3e76d74ad

這篇文章算是一個資安問題的討論文章，作者透過一系列的手法成功地獲取了大量使用者的電腦資訊，由於這次的實驗只是要證明資安問題，因此作者的程式只有獲取如 IP, Hostname 等簡單資訊，若是惡意的話是可以執行更多危險程式碼的。

作者開門見山表示，現在的程式語言有太多的豐富的第三方函式庫，譬如 NodeJs(NPM), Ruby(RubyGem), Python(PyPI)，豐富的第三方實作讓開發者可以更快速的完成任務。
開發者在使用這些套件函式庫時，大部分情況都不會去檢查太多，而是直接信賴般的去使用這些函式庫，而這種盲點般的信任是否有可能讓攻擊者有跡可循？

作者基於這個想法進行了一系列研究，發現 PayPal 公開專案(NodeJs) 內的 package.json 內交互使用了公開與內部的 packages。 公開部分勢必來自 npm 而那些內部的應該是來自於 PayPal 內部系統，同時也注意到這些內部的 package name 目前於 npm 上也不存在。

針對這個情境，作者提出一些問題
1) 如果有人上傳跟 PayPal 內部 package 相同名稱的套件到 npm 服務器上，有沒有可能 PayPal 內部某些專案會預設使用 npm 上的套件而非內部自架的伺服器?
2) 開發者或是其他自動化系統有沒有可能運行這些 packages 內的程式碼，這樣有沒有機會造成一個漏洞的可能性？
3) 其他的公司是否也會有類似的問題?

為了證實這個問題，作者設計了一系列的實驗與準備來測試上述問題，譬如更有系統的去尋找這種有跡可循的 package.json(Tesla, Apple, Yelp 等公司都被到可以利用的 package names)。

作者將自己這系列的攻擊行為稱為 depdendency confusion 來呼應本文標題。

結果來看是令人非常震驚的，作者打造同名的npm的確被大量下載與執行，也讓作者收集到大量運行的內部服務器IP與名稱。
與 Apple 合作通報相關報告後， Apple 也於兩週內修復相關問題。

原文滿長的，非常推薦閱讀
我個人認為資安這概念就是不出問題不被重視，但是一但出問題可能造成的影響卻非常巨大的。團隊內每個人都要培養基本的資安理念，同時與相關的安全團隊合作逐漸地提高整個產品的安全性，永遠不要想一聲令下明天就可以反轉一切。


https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

本篇是一個 GKE 上面的使用經驗談，主要問題發生調整 StatefulSet 數量時(3->5)，發現新增出來的 Pod 都沒有辦法順利的被排程到節點上。
作者團隊遇到的錯誤訊息是

FailedScheduling 4m42s (x3 over 4m44s) default-scheduler 0/9 nodes are available: 3 pod has unbound immediate PersistentVolumeClaims, 6 node(s) didn’t match node selector.

根據上述訊息，可以觀察到兩個點
1) 3個 Pod 因為 PVC 的問題過不去
2) 6個節點沒有符合 node selector 的敘述

這個錯誤訊息讓團隊覺得很莫名，畢竟本來的 StatefulSet 運行的很好，只是改個 replica 的數量就出問題了。

經過調查與研究後發現， GKE 創造的 PV(PersistentVOlume)全部都綁定於 europe-west4-b 上，然而所有的 Pod 全部都綁定於 europe-west4-a 上。
Zone 的使用上沒有一致導致這個問題發生。
作者本來是期許 GKE 要可以更聰明的去處理這個問題，所有自動創立的 PV 應該要針對 Node Selector 有符合的 Zone 去設定，這樣才可以確保運行的 Pod 有對應的 PV 可以使用。

最後作者閱讀了相關文件，得到兩個結論
1. 根據官方文件，Regional persistent disk 只會針對同 regional 內的兩個 zone 去複製與同步 Disk，因此對於一個有 3個 zone 的 Region，是有機會存取到一個沒有該 Disk 的 Zone。
2. 根據 GKE 的文件，使用者最好維護自己的 StorageClass 物件，透過該物件去來 select 多個 zone，同時團隊也比較有能力針對多zone的情況去控管

https://faun.pub/a-story-about-gke-zonal-nodes-and-stateful-set-scaling-1e15acfe5523

這次帶來的是個人的原創文章「從網路觀點來看導入 Kubernetes 的可能痛點
」，就我個人的理解與經驗跟大家討論導入 Kubernetes 到現有環境中會遇到的各種網路問題。

雲端平台的方便性使得架設 Kubernetes 簡單容易上手，然而對於地端環境來說，要導入 Kubernetes 並沒有想像中的簡單。團隊服務沒有辦法一夜轉換到 Kubernetes 的情況下，最麻煩的便是轉換過渡期中要如何讓 k8s 與現有架構整合。

Kubernetes 原生的 Service 與 CNI 架構為其提供低門檻的使用方式，讓 Kubernetes 運作起來不需要太深的網路背景與概念即可順利使用。本篇文章就地端環境來討論幾個可能需要的網路情境，而這些情境為什麼於 Kubernetes 內難以實現與完成，如果真的有需求時可以用何種角度與方式去解決。

長話短說就是本篇文章探討如何透過 Multus/DANM 等 Metaplugin CNI 搭配 SR-IOV/DHCP/Static CNI/IPAM 來滿足

1. Pod 固定 IP
2. K8s 叢集支援多個底層網路，針對需要讓不同流量走不同底層網路
3. 不同強度的網路隔離

https://www.hwchiu.com/k8s-network-issue.html

本篇文章主要探討的是如何打造一個 GitHub 個人帳號的 README 檔案。
作者因為某份職缺招募者告訴他，我們看了很多你的 GitHub 紀錄，建議寫一個 READEME 來好好的介紹你自己，因此作者開始思考如何透過 README 來好好的銷售自己展示自己的能力。

去年開始所有 GitHub 帳號都可以創造一個基於自己名稱的 repo，並且該 repo 內的 README 則會是自己帳號首頁的自我介紹，而本文則是示範如何設計一個有特色的 README 內容，從排版，選色，字型等議題都有所涉略

有興趣的也可以參考這個網站: https://awesomegithubprofile.tech/
裡面列出了非常多有趣很酷的 README，必須說很多都超乎我的想像.....

https://emmanueljose.medium.com/readme-a-makeover-story-b9c7be37a6de

這次跟大家分享一個 ConfigMap 相關的小 issue，當透過 configmap 來存放任何 json 格式資料時，某些情況會導致 configmap 內最後存放的資料格式全部跑掉，所有的換行符號都以\n的方式出現於資料中，導致整個 json 變得非常醜陋，這個醜陋會使得想要手動去編輯這個 json 資料非常困難，必須要手動修復後再修改。

最常遇到這個問題的一個情境是，透過 kubectl create configmap xxxx --from-file=xxx.json 的方式將一個已知的 json 轉化成 configmap 的資料並存放。
該 Issue 回報於 2016 然而實際上就算於 k8s v1.19 都還是可以遇到這類型的問題，Issue 列表中有不少人在討論如何解決這個問題，基本上有幾大重點，掌握這些重點就可以避免 json 格式跑版
1. 避免使用 tab，全面使用空白
2. 移除任何 trailing whitespaces

如果有遇到這類型需求的的不彷試試看這些解法
https://github.com/kubernetes/kubernetes/issues/36222

本文闡述三個為什麼即使身為管理職缺，依然需要寫程式

網路上有非常多的文章再探討到底身為工程團隊的管理者，需不需要繼續寫程式來保持手感？
作者更好奇的是為什麼會有這類型的問題出現，假設今天目標是需要領導整個工程團隊並且讓每個工程人員都能夠更好發揮的情況下，管理人員為什麼要把時間花在沒有辦法達到上述目標的過程？

作者根據自身的經驗來思考這些問題，最後整理出三個理由想要分享給大家

1. Coding Give You Energy
"通常"會變成工程團隊領導者過去也都身為軟體開發人員或是相關的技術人員，能夠長時間位居於此職位且被考慮升等成領導人員的人，勢必都曾經對於 coding 與技術相關的工作擁有熱情。

某些人很享受撰寫程式的過程，能夠找到問題並且動手解決這些問題，透過這些行動讓自己感受到自己是真的有在工作，是有成果的。
相反的，作為一個管理人員，很多時候很難去解釋跟展示自己的能力與進度，沒有辦法像過往一樣簡單的說「這個功能我做的」來簡單展現自我成就，反而其績效可能會變成團隊是否有準時遞交新功能等以團隊為主的表現。

更重要的是，作為管理人員，每一週重新審思一週進度時，都很不好回答到底本週做了什麼樣的事情，更多時候都在處理底下人員間的互動與情緒。
透過重新 coding 能夠讓你找回自己的成就與存在感，讓你重新從撰寫程式中取得快樂，為枯燥的生活添加一些樂趣。

除此之外，還有提到一個是未來職涯的考慮，如果對於自身的職涯還處於一個探索期，甚至最後有想要從管理職轉回到IC (Individual Contributor)等職位，勢必到時候可能又會有一番的Coding面試。
為了確保自己繼續保持那些動手實作的能力與習慣以及隨時準備好轉職一番，培養撰寫程式的習慣能夠讓你更容易得去轉換跑道。

最後提到，最重要的一點其實是要先了解自己，知道自己到底需不需要繼續寫更多程式，如果自己從撰寫程式這個過程可以得到更多的成就，活力與喜悅，可能就要思考管理職缺是否是一個自己追求的長久目標。


https://betterprogramming.pub/why-engineering-managers-still-want-to-write-code-d1c04b4cadaf

本篇文章探討的也是資安系列問題，而這次的目標主角則是 MAC 系統上廣為流傳的 Homebrew 系統。

結論:
作者透過觀察 Homebrew 的 Github Action 流程，成功得上傳一個會列印一行的程式碼到 iterm2 套件中，讓所有安裝的使用者都會於 Terminal 上看到一行作者客製化的訊息。

本次的漏洞是作者刻意從 Homebrew 的 Vulnerability Disclosure Program 專案中去嘗試尋找可能的問題，所有的操作都有跟官方專案的人探討過流程，並且一切的 PoC 都是單純證明該攻擊的可行性，所以有興趣研究的人請遵循一樣的想法去做，不要認真的想攻擊。

原因:
1. Homebrew 透過 Github Action 執行 CI/CD 動作
2. Homebrew 撰寫了一個自動合併 Pull Request 的 Action
3. CI 內會透過一個Ruby的 Git Diff 第三方函式庫來驗證，只要符合下列條件就可以自動合併
- Modifying only 1 file
- Not moving/creating/deleting file
- Target filepath matches \ACasks/[^/]+\.rb\Z
- Line count of deletions/additions are same
- All deletions/additions matches /\A[+-]\s*version "([^"]+)"\Z/ or - -\A[+-]\s*sha256 "[0-9a-f]{64}"\Z
- No changes to format of versions (e.g. 1.2.3 => 2.3.4)

作者一開始想要從該規則下手，找尋有沒有可能塞入惡意攻擊並且騙過系統讓其自動合併，然而這些規則看起來沒有什麼太多問題，於是作者轉往其他領域去找尋問題，其中一個想法就是到底該 Ruby 的 Git Diff 是如何實作，也許從實作下手更有辦法去欺騙這一切。

很順利的是，作者真的於該函式庫中找到問題，對於一個 Git Diff 的結果來說，該函式庫會透過 +++ "?b/(.*) 這樣的正規表達式來判別檔案路徑的資訊而並非程式修改內容，譬如下列 diff
```
diff --git a/source file path b/destination file path
index parent commit hash..current commit hash filemode
--- a/source file path
+++ b/destination file path
@@ line information @@
Details of changes (e.g.: `+asdf`,`-zxcv`)
```

作者就開始思考，如果讓程式碼可以符合 +++ "?b/(.*) 的規則，是否有辦法讓程式碼不被視為一個檔案的修改，因此就可以修改多行程式碼但是讓 CI 系統認為只有一行程式碼於是進行自動合併

作者最初的想法如下，第一行用來放惡意程式碼，第二行用來偽裝檔案路徑，經過一番嘗試後作者真的成功塞入了類似 PRINTF 的程式碼到環境中並觸發自動合併。接者各地使用者透過 brew 安裝 iterm 版本都會看到使用者塞入的程式碼。
```
++ "b/#{Arbitrary codes here}"
++ b/Casks/cask.rb
```

原文還有更多作者的思路過程，有興趣的不要錯過

原文:
https://blog.ryotak.me/post/homebrew-security-incident-en/#fn:7
測試用PR:
https://github.com/Homebrew/homebrew-cask/pull/104191

這篇文章探討的是關於 Serverless 使用上的經驗分享

作者基於自身實戰經驗探討於 AWS 上使用 Serverless 的七種架構模式

模式一:
作者認為最簡單的模式，使用 API Gateway, Lambda Functions 配上 DynamoDB 來處理商業需求
團隊可以透過 API Gateway 來達到快取，限速等不同的調整


模式二:
針對微服務的架構調整，基於模式一進行延伸。
因為 API Gateway 以及 Lambda 相關的限制都是基於帳戶設定的(可以聯絡客服調高)，因此模式二就是用更多的帳戶來處理更多的服務，藉此讓這些限制不會被許多服務共享。

模式三:
該模式是標準有前(SPA)後端應用程式的架構。

前端(Single Page Application)網頁放到不公開的 S3，前方透過 AWS CloudFront 來處理應用並且將 Request 給 Proxy 到後方 S3。而後端則是如同模式一的方式去部署

模式四:
模式三的延伸，如果需要使用者是來自於不同的地理位置，想要針對地理位置去進行更多處理時，會透過 CloudFront 作為 Proxy 來處理 Regional API Gateway.

剩下三種模式就不詳述，有興趣的可以閱讀原文看看七種模式

https://waswani.medium.com/serverless-architecture-patterns-in-aws-edeab0e46a32

這篇文章是個專案教學文，探討的是如何使用由 Rancher 所開發維護的 Harvester(HCI, 超融合基礎架構)專案。

雲端架構的特性能夠應付大部分的應用與場景，但是部分的應用則必須要繼續使用地端實體機器去架設服務。

虛擬化的時代，要如何將一個又一個硬體機器轉變成簡單好用的 VM 供上層應用程式使用則是一個有趣但困難的操作，開源的 Openstack 或是各種商業軟體則是眾多企業過往的選擇。

當這一切碰到 Kubernetes 時又變得複雜，主要是 Openstack 等專案強大卻難以駕馭，複雜的元件與架構讓它沒有辦法如 Kubernetes 一樣簡單好用，輕易上手。

如何讓一群硬體機器上面部署一個 Kubernetes 叢集不是一個困難問題，目前有眾多的解決方案幫忙處理，但是如何讓一群硬體機器上面跑出各種不同的 VM，並且於 VM 上面運行 Kubernetes 則是一個難以搞定但確實存在的需求。

Rancher 本身很擅長如何於一群 VM 上運行這些 Kubernetes 叢集，因此其發展了 Harvester 這個專案，該專案基於 Rancher 的 K3OS 作為底層作業系統。接者透過 Kubevirt 專案來管理與創建 VMs，儲存方面則是使用 Longhorn 來管理，網路的話則是 Kubevirt 本身已經導入 Multus CNI 來提供更多的網路操作。

這個專案還非常新，還在持續開發中，對於地端環境部署有需求的話，可以持續關注這個專案

https://blog.linnovate.net/baremetal-kubernetes-with-harvester-and-k3s-25fe9e7ab695

今天這篇文章要跟大家介紹的是 kubectl 一個好用的 plguin, flame，這個名稱就是大家所熟悉的火焰圖，所以長話短多。 kubectl flame 用來幫助維運人員針對任何已經運行的 Container 透過不同的 proflier 來進行效能分析，並且畫出相對應的火焰圖供研究。

對於維運人員來，透過 profiling 分析程式碼中存在的效能瓶頸是個非常常見的行為，有效的工具能夠幫助開發人員更快速的找到效能瓶頸並加以修正，而火焰圖則是一個非常知名的視覺化方式，將這些 profiling 的結果透過 stack 的方式顯示出來，讓開發人員一目了然地找到痛點。

雖然 profiling 聽起來如此強大，但是要於 Kubernetes 中針對運行的應用程式進行效能分析並不是如此簡單，主要是 profiling 通常會伴隨兩個條件
1. 程式碼需要修改，加入相對應的參數或是函數才能夠正確地將 function symbol 給顯示出來
2. 針對正式生產環境的除錯同時也會帶來效能影響的取捨，為了分析應用程式的效能意味者 profiler 必須要針對應用程式進行取樣與分析，這些都會帶整體效能上的影響。

更重要的事，如果今天要對一個已經運行的應用程式加上 profiling 需要的修改與參數，代表整個 Pod 會需要重啟來部署新版本的 Container Image。這類型的重啟可能會導致效能問題消失，整個除錯過程變得非常困難。

Kubectl flame 透過部署一個全新的 Container 到目標 Container 所在的節點上，同時透過 PIDNamespace 與 MountFilesystem 等方式來達到透過外部應用程式來幫忙進行 profiling，不過要注意的是不同的 profilter 所支援的程式語言不同。

有興趣的可以參考下列文章，甚至可以使用 pyroscope 這套 continuous profiling platform 來達成長時間的效能分析。

https://medium.com/swlh/introducing-kubectl-flame-effortless-profiling-on-kubernetes-4b80fc181852

本篇是一個 Kubernetes 的入門介紹文，探討 Kubernetes 內要如何透過 SSL/TLS 憑證來加強應用程式之間的連線。

本篇文章不使用任何第三方套件，反而是從 Kubernetes 內建的資源功能出發去探討，理解 Kubernetes 的能力與極限其實長久下來對於評估各種專案都滿有幫助的。

Kubernetes 的 Secret 除了使用 base64 作為編碼技術外，其實本身也提供不少類型方便管理人員使用，譬如本文提到的 tls 類型， container registry credential 以及最廣泛使用的 generic 等。

Secret(tls類型)本身創建時會吃兩個參數，分別是 tls.crt 與 tls.key，接者這類型的 secret 可以與 ingress 進行整合，將 TLS 給掛載到 Ingress 物件中並且同時執行 TLS Termination，讓 Ingres 與外部連線使用 HTTPS 而內部服務則使用 HTTP 來溝通。

文章中提到如何透過 openssl 創建一個 self-signed 的憑證，並且針對 self-signed 的特性進行討論，其列出了四個 self-signed 的缺點

1. 瀏覽器連接到這些 self-signed 憑證的網站時都會露出警告告知使用者，因此這類型的憑證不適合任何正式生產環境使用
2. 因為 self-signed 就是開發者自行創造，缺少第三方可信任機關的認證，因此惡意攻擊者可以輕鬆換掉服務上的簽證，畢竟瀏覽器本來就覺得簽證有問題，無法分辨到底是先前的自簽憑證還是被替換的憑證。
3. 第三方CA都會針對發行的憑證給予一些保固與服務，這部分是自簽沒有辦法擁有的
4. 愈來愈多的使用者會不太願意瀏覽與使用沒有合法且信任憑證的網站

作者提到 Kubernetes 內部雖然有一個 CA，但是不推薦把任何服務相關的憑證都跟其扯上關係，
因為該 CA 是給 Kubernetes 內部控制平面使用的，譬如 kubelet, API Server, Controller, Scheduler 等元件彼此溝通中間使用的。

文章最後作者示範透過 cfssl 的該指令幫一個內部服務創建一個憑證，由於內部服務會透過 Kubernetes Service 提供的 DNS 來存取，因此創建憑證時會於 CN 欄位補上 alternative 的名稱，把 service.svc.... 之類的全部都補上。


https://medium.com/avmconsulting-blog/how-to-secure-applications-on-kubernetes-ssl-tls-certificates-8f7f5751d788

本篇是一個入門介紹文，探討的議題是微服務架構下的監控架構要有什麼樣的元件與功能

Observability 基本上現在已經是個顯學，任何的叢集架構都需要有一個匹配的監控系統來(主動or被動)告知當前各種元件的狀況，讓維運人員能夠儘早地針對問題處理，減少任何損失。

普遍主流認為可觀測性底下目前有三大類別，分別是
- Metrics
- Logs
- Tracing

監控系統必須要能夠讓維運人員知道什麼元件壞掉以及為什麼，維運人員能夠快速簡單的定位問題的可能點，並且快速的找到真正的 root cause。作者認為發生問題時最重要的就是要找對地方，就算今天環境中架設了各式各樣的儀表板並且收集了四面八方的資料，如果發生問題時沒有辦法準確的找到進入點，那再多的工具也都沒有用途。
作者列舉了四個必須要從任何服務都要收集的相關 Metrics，包含
- Latency: 每個服務請求花費的時間
- Errors: 系統中發生錯誤的訊息，甚至是沒有辦法被正確處理的請求
- Traffic
- Saturation: 服務用量的測量，譬如CPU/Memory/Disk/Network

接者要針對每個 Metrics 選決定一個適合的觀察類別，譬如說
1. Counters: 透過數值來表示各種可累積的 metrics，譬如 request 的數量， error 的數量。
2. Gauges: 透過數值來表示一種會上下起伏變化的 metrics, 譬如跟 database 的連線數量， 記憶體/CPU 的使用量，系統平均負載值
3. Histograms: 需要將取樣觀察結果依照不同類別來分類顯示，譬如 I/O latency

當監控系統建置完畢後，接下來就要有能力使用該系統來進行主動回報，也就是所謂的 Alert 系統。
當元件的狀況符合預先設定的條件時，就要通知維運人員來檢查與處理，這邊作者特別提到針對 Alert 的規則必須要仔細的設定分類與優先度，特別是當某些服務或是底層架構觸發時，可能會一口氣觸發多個 Alert 通知，這時候要如何快速的從眾多警報中找到真正的源頭就經驗搭配良好的系統規劃。

https://medium.com/@milan.brankovic/monitoring-microservices-e0f89496fa9e

本篇文章要介紹的是 2021 年熱門的日誌視覺化分析工具，作者於本篇文章列出 8 種不同的工具，分別是

1. Logiq.ai (2019 創立)
2. Datadog (2010 創立)
4. Dynatrace (2005 創立)
5. Logz.io (2014 創立)
6. Graylog (2009 創立)
7. Google Cloud Logging
8. Scalyr (2011 創立)
9. LOGalyze (開源專案，但是官網連 HTTPS 都沒有....)

作者列出的基本上都是商業解決方案，要使用開源方案還是商業解決方案一直以來都沒有絕對的答案，畢竟一個解決方案除了功能完整性之外，技術支援也是非常重要的一環。

好奇上述的解決方案大家有沒有相關使用經驗？

https://medium.com/nerd-for-tech/top-log-visualization-tools-in-2021-fa0a2d897ad1

今天帶來的內容是關於 DevSecOps 的介紹，由 synk 這間公司所撰寫的 DevSecOps 介紹，與其說是文章更像是一個專欄，內文非常豐富，從基本的介紹，到文化，人員組成，運作流程以及相關技術探討都包含其中，我認為對這個領域有興趣的人很值得花些時間咀嚼一下這系列文章，來看看到底別人認知的 DevSecOps 到底是什麼。

本篇文章針對 overview 的部分進行介紹，其餘詳細部分請到連結中閱讀囉

What is DevSecOps:
1. 將 Security 的概念帶入到 DevOps 的軟體交付流程
2. Dev & Ops 共享責任來交付安全的應用與軟體

從功能面來看，盡可能地於整個軟體開發交付流程中盡可能早的發現安全並且修復，要特別注意的是"安全是所有人共享的責任"並不是單純 DevOps 團隊人員的責任，大夥還是努力合作一起解決問題，就如同 DevOps 的概念一致。

6 Benefits of the DevSecOps Model
- Faster delivery: 將 Security 等概念整合到軟體交付流程中時，可以讓任何漏洞於正式部署前就發現與解決，這樣可以使得整體的開發流程更加順利與快速。
- Improved security posture: 資安不再是個上線後才要擔心的議題，而是打成軟體設計開發初期就要關注的點，透過這個方式才有辦法把資安跟建置，部署進行一個緊密的整合
- Reduced costs: 正式部署前能夠定位找到任何 vulnerabilities 能夠有效率地減少各種維運上的風險成本。
...等

原文非常有趣，非常推薦有興趣的閱讀這整篇專欄

https://snyk.io/devsecops/

本篇文章是ㄧ個 Kubernetes 相關工具經驗分享文，作者認為即使是前端開發工程師也必須要瞭解一下 Kubernetes 這個容器管理平台，作者認為 k8s 基本上已經算是這個領域的標準(de-facto)。

因此作者於本篇文章介紹一些搭建一個 K8s 叢集時需要注意的工具，透過這些自動化工具來減少反覆動作的執行藉此簡化每天的工作流程。

工具包含
1. ArgoCD
2. MetalLB
3. External-secrets
4. Cert-manager
5. External-dns


Simplify deploying of new apps
作者大力推薦使用 ArgoCD 來簡化部署應用程式，作者提到一開始使用 ArgoCD 時也是感到無比煩感，因為心中一直存在要於 `GitLab CI/CD pipeline` 透過 kubectl apply 的方式來部署應用程式，並不想要導入其他的元件來加入更多的複雜性。

然而當作者嘗試 ArgoCD 後，第一眼發現的是其架構不如想像中複雜，完全依賴 GitOps 的原則來簡化整個部署流程，同時透過一個 WebUI 的方式來呈現當前應用程式的部署狀況

Load balancer for your on-prem clusters
地端環境的 Load-Balancer，沒什麼好說就是 MetalLB。

Managing your secrets
Secrets 是 Kubernetes 內一個非常重要的物件，然而大部分的團隊都會思考如何有效且安全的去管理 Kubernetes 內的 Secret 物件。雲端供應商譬如 AWS Secrets Manager, Azure Key Vault 或是廣受熱門的 HashiCorp Vault.

作者推薦使用 external-secrets operator 這個專案來將外部的管理系統給同步到 Kubernetes 內並且產生對於的 secrets。


詳細全文可以參考下列原文

https://chris-blogs.medium.com/tools-that-should-be-used-in-every-kubernetes-cluster-38969ed3e603

本篇文章是經驗分享文，作者分享為什麼其跟最初學習 Kubernetes 使用的 minikube 說掰掰，而轉換到新歡 KIND 的故事

作者之前演講分享時，透過 minikube 架設所有 demo 環境，平常使用都好好的然而活動前幾天開始覺得叢集有點慢，但是作者並沒有特別注意去處理。
活動當天 demo 直接爆炸，系統變得很慢，不論是 pod 的各種操作都很慢，作者沒有辦法很漂亮的清除 minikube 內的環境，最後只好砍掉VM全部重來。

活動結束後作者重新創建了一次整個 VM(使用 VirtualBox)，結果整個系統還是很慢，作者開始思考有沒有其他的替代方案，後來找到了 Kind 這套解決方案。

KIND 是 Kubernetes In Docker 的縮寫，透過 Docker Container 的方式創建節點並基於該節點創建 Kubernetes 叢集。

這邊要注意的是 KIND 透過 Docker 創建節點，而節點內卻使用 Contaeinrd 作為 k8s 的 CRI 解決方案。

除了 KIND 之外， Rancher 維護的 K3D 也是一樣類型的創建方式，其中 K3D 支持動態加入與移除節點，KIND 只能一開始創建時就定好 cluster 的大小。

https://nfrankel.medium.com/goodbye-minikube-340070edc5af

本篇文章是一個經驗分享文，作者探討使用 Rancher 遇到的問題，以及最後是如何使用 Kubecost 來解決成本使用的分析問題。

作者認為 Rancher 對自己公司的 DevOps Team 來說是個非常好用的工具，透過 Rancher 的視覺化工具，任何人都可以清楚的去管理以及檢視當前 K8s 叢集內的各種資訊，對於任何加入團隊還不熟悉 Kubernetes 的開發者來說，Rancher 的特色讓這些新開發者容易上手，熟悉概念後再轉往理解 kubectl 等工具的使用。

不過作者公司團隊遇到的問題是 Kubernetes 內不同專案彼此的成本用量難以計算，雖然 Rancher 內有再提供一個 Project 的抽象介面，可以控管 Project 底下的 CPU/Memory 以及相關物件的分配。

但是這樣還是有三個問題沒有辦法解決
1. 無法有效且快速的知道每個 namsepace 底下於 Node 上所佔的資源比例
2. 當一個 Team 本身會使用到多個 namespace 時上述的計算會變得更加麻煩。
3. 團隊看透過 kubectl top 去計算，或是使用 Prometheus/Grafana 來整合計算，但是實際上還是一個困難的麻煩事

作者最後從 Rancher 的線上研討會中，聽到了 Kubecost 有趣的專案，該專案可以順利的與 Rancher 整合，基於 Rancher Project 作為基本分類，來檢視每個 Project 底下各種資源的使用量，同時搭配金額的分配還可以把使用量轉換成實際的金額，團隊更有能力去估算使用量。

有興趣的可以閱讀全文並且嘗試看看 kubecost 這個工具
https://itnext.io/kubecost-rancher-saved-df30fe77135b

本篇文章是一個技術探討文，探討 Docker 是如何使用硬碟空間以及當維運人員發現空間不足時應該要如何清理系統上的空間。

Docker 的便利使用方式使得開發人員可以非常簡的透過的 Container 的概念來運行各式各樣的應用程式，這中間牽扯包含 Image 的建置，抓取以及透過其產生出一個運行的 Container。
隨者時間愈用愈久，系統內可用的空間也會愈來愈少，這時候可以透過 docker system df 來觀看一下目前系統上的空間資訊，主要包含下列四種類型，而每個類型也會包含目前使用量以及可以回收的量有多少
1. Images
2. Containers
3. Local Volumes
4. Build Cache(只有 docker 18.09 後使用 buildkit 才會有)

當 Contaienr 被創建時， /var/lib/docker 底下會有很多檔案以及資料夾都被創建出來，譬如

- /var/lib/docker/containers/ID (資料夾):如果 container 使用的是預設的 logging driver，則 log 檔案都會以 JSON 的格式存放於這個資料夾底下。
所以要注意，當 contaienr 有太多 log 時，其會透過這個方式影響節點檔案系統的容量
- /var/lid/docker/overlay2 (資料夾): 這邊包含了 containers 本身的 read-write layer 的檔案，大部分 Linux 發行版預設都會使用 overlay2 來管理。此外 contaienr 內如果有存放任何額外檔案於系統中，實際上都會放這節點上的這個資料夾內。

接下來作者透過一個實際的範例，讓一個全新的 contaienr 內透過 dd 指令來產生一些檔案，並且觀察上述資料夾的變化以及 docker system df 的結果，最後介紹 docker prune 以及 docker rm 針對 contaienr 的處理。

關於 image 的部分，除了常規使用的 Image 外，還有
1. Dangling images: 不再被參考使用的 image，譬如 ID/Tag 都是 None 的
這邊可以透過 docker image ls -f dangling=true 的指令

文章後半部分還有介紹 docker volume 以及 build cache 的部分，這篇文章非常推薦大家閱讀，除了基本使用外還會介紹底層 docker 實際上用到的資料夾，有了這些概念未來對於如何清除 docker 環境就會更有概念，知道要刪除哪些資料夾以及為什麼要刪除。

https://betterprogramming.pub/docker-tips-clean-up-your-local-machine-35f370a01a78