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

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 如何設定。
如果團隊有這個需求的可以看一下要如何操作。

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

ref: https://engineering.hellofresh.com/ambassador-the-evolution-of-ingress-gateway-at-hellofresh-3889232cab6f

本篇文章是 HelloFresh 這個美國生鮮食材訂購服務想要分享其團隊中 Ingress gateway 的演化史。該團隊過往使用 VM 作為其底層基礎架構來部署應用程式，後來遷移到
kubernetes 改用容器來部署，然而其內部的其他元件並沒有隨者 kubernetes 轉移而一併更新，譬如文章要探討的 Ingress gateway。
因此文章後將探討原先的 Ingress gateway 架構以及相關問題，最後如何將其與 kubernetes 進行整合來解決前述問題。

再使用 kubernetes 之前，團隊使用兩種不同的方式來處理，分別是內部 API Gateway Janus 以及網頁處理的 Entry (基於 Nginx 的 Reverse-Proxy)
團隊遷移到 kubernetes 之後，這兩個服務都想要透過 kubernetes Nginx Ingress 來處理，不過處理的過程中卻遇到一些問題。

1. 一致性: 每個微服務一開始都透過 Ingress 讓外界存取，然而當團隊開始使用 istio 後有些服務就改使用 Istio Ingress-Gateway 來處理，其他想要使用 TCP 的服務則會改使用 AWS ELB 來處理。
2. 延遲性: 因為 API Gateway 的存取節點都是基於 FQDN 的方式來存取，所以每個封包都要經過更多的節點來到達最終目的，這會增加整個封包傳輸時間。

最大的困惱還是第一個一致性的問題，k8s中有太多的方式讓外界可以存取期服務，每個都有自己獨特的設定，監控以及警示。
為了針對這些問題去解決，團隊內部先期構思一下到底什麼是團隊中理想的 Ingress Gateway

1. Reverse Proxy (HTTP) for websites
2. Mixture of an API Gateway
3. Kubernetes native
4. Advanced routing : (headers, methods, path)-based
5. JWT scope validation
6. Reliability features: Rate-limiting, Retries, Circuit breaking
7. Traffic shadowing
8. Interface for extensions
9. Integration with service mesh

後續文章包含了一些內容，如
1. 作者接者談談為什麼不使用 Service Mesh 所提供的 Ingress gateway
2. 到底要自行開發還是購買解決方案?(最後選擇了 Ambassador Edge Stack)
3. 如何透過 Ambassador Edge Stack 來解決團隊問題
4. 透過 Ambassador Edge Stack 後帶來的好處

有興趣的別忘了參閱全文

Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。

本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。

好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。

以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。

相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Vault /Sealed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)

https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb