關於 istio功能 ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://jzimnowo.medium.com/harbor-keycloak-and-istio-a-good-dance-troupe-6c3520fb87de

本篇是個經驗分享文，作者想要打造一個基於 Kubernetes namespace 的多租戶 Kubernetes 平台。
該平台主要針對的是團隊內不同的 DevOps team，並且每個 Team 都會有自己的下列資源
1. Harbor: Private Container Registry
2. Keycloak: SSO
3. Istio: Service Mesh.

# Harbor
Harbor 是 CNCF 的畢業專案，專注於提供 private container registry，本身除了有友善的操作介面外，也整合了多項常見功能，譬如
1. 基於 OIDC 的授權認證機制
2. 容器安全性掃描
3. Chartmuseum (未來會被移除)
4. 專案管理

透過 OIDC 與專案的機制，能夠很輕鬆的針對不同專案設定不同權限，譬如屬於群組 A 的只能使用 Project A。
此外每個專案本身也有提供 robot account，該 robot account 的目的則是讓整個工作流程更佳簡潔。

如果要於 Kubernetes 中去抓取這些 Private Container Registry，則必須要透過 ImagePullSecret 的物件來描述登入資訊。
為了避免使用個人帳戶來存取，作者推薦每個專案都要準備兩個 Robot Account，這兩個 Robot Account 都只能針對該專案底下的 container 去存取
所以也不用擔心會去存取到其他 Team 的專案。
第一個 robot account 專注於 Pull Image，主要是讓 Kubernetes 內部可以下載 Image 使用。
第二個 robot account 則是給 CI/CD pipeline 使用，讓 pipeline 有能力將新的 image 給推向 Harbor。

前述所說 Harbor 可以基於 OIDC 來滿足認證的機制，作者於團隊中就使用 Keycloak 這個開源來作為一個 OIDC 提供者(另外一個常見的是 Dex)。
文章中有稍微介紹如何於 Keycloak 中創立一個 Client 的物件，並且於 Harbor 如何設定。
如果團隊有這個需求的可以看一下要如何操作。

文章最後探討使用這三個專案的一些經驗與痛點，有興趣的可以閱讀全文參考

#容器周報 #服務網格正夯 #K8S電商實例

北歐最大規模的3C零售電商Elkjop主要採取委外開發，再由小規模IT部門來管理和負責整合，不過，6年前，他們決定擁抱微服務設計，自己來改造那些用來串接各委外系統間的API，尤其要自己開發一個進階版支付API，來串接電商平臺和店內POS系統，也採用自建K8s平臺方式來部署微服務。

推薦閱讀
1️⃣14本導入和維運K8s必讀的上手書
2️⃣快速一覽三大雲端龍頭K8s代管服務的2月新功能
3️⃣Nvidia翻新GPU虛擬化軟體，簡化K8s部署GPU的維運框架
4️⃣開源服務網格Istio釋出1.9新版，容器服務網格也能整合VM管理
5️⃣Azure Functions出現容器脫逃漏洞，惡意程式能進入底層主機
6️⃣開源政策管理引擎OPA專案正式畢業，Google、微軟和VMware將持續維護

https://www.ithome.com.tw/news/142897

Service Mesh 這幾年的話題沒有停過，不論是 Linkerd, istio 或是其他解決方案都有各自的支持者。今天這篇文章是 Linkerd 官方文章，來跟大家解釋說明為什麼 Linkerd 沒有像其他解決方案一樣直接採用 Enovy 做為底層 proxy，而是要自行開發一個名為 Linkerd2-proxy 的取代方案

# 前提
1. Linkerd 是一個由工程團隊打造給工程團隊使用的產品，所有的決定都是基於工程方面的考量，而不是市場壓力
2. Envoy 很棒，但是對於 Linkerd 來說並沒有辦法透過 Envoy 打造一個簡單，輕量且安全的 Service Mesh 解決方案
3. 透過重新打造 Linkerd2-proxy，針對自己的需求重新設計才有機會讓 Linkerd 變得簡單且好用

# 想法
1. Linkerd2-proxy 是一個完全不考慮使用者面向的 Proxy 實作，跟 Envoy, Nginx 以及 Apache 這類型的實作是完全不同考慮。 Linkerd2-proxy 就是一個專門給 Linkerd 內部使用的
2. Envoy 超級彈性，同時是一個多用途的 Proxy，這種框架導致 Envoy 非常熱門，但帶來的就是其底層複雜。對於 Linked 來說需要的功能沒有這麼多。簡單來說就是殺雞焉用牛刀
3. 根據 Linkerd 內部的效能壓測，於 4,000 RPS(Request Per Second) 的前提下， Istio's Envoy 使用的 CPU 量相對於 Linkerd2-proxy 是 50% ~ 1000% 的增長，而 Memory 則是 1000%
4. Linkerd2-proxy 採用 Rust 開發，相對於 C++ 來說再安全性方面的開發會比較輕鬆一點，這個並不代表 Envoy 不安全，因為 Enovy 的社群龐大，CVE跟 bug 的修復也是很快。

# 其他
1. 相對於重新開發一個類似 Linkerd2-proxy 的專案，直接使用 Envoy 做為底層的 proxy 是非常簡單且省時的。並不是所有的 Service Mesh 解決方案都有足夠的能力與時間去開發屬於自己的 Proxy，因此整合 Enovy 並非錯誤
2. 目前使用 Linkerd 解決方案的使用者，其底層都是使用 Linkerd2-proxy
3. 其他的 Service Mesh 並不太能直接改採用 Linkerd2-proxy，畢竟其本身的設計就不是一個市場與使用者面向的專案。作者建議可以考慮使用 Rust 的 network library 來打造一個自己的方案

這篇文章並不是教你如何使用 Service Mesh，反而是分享更多一些設計上的哲學思考，個人覺得非常有趣，有興趣的可以點選下列連結觀看全文
https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/