限制

對於 Linux，可擴展的解決方案需要 kvm2 驅動程式（已測試 15 個 Keycloak 副本）。當添加超過 8 GB 的 RAM 時，可以有更多實例。

Linux 上的 Podman 驅動程式目前僅支援最多 5 個 Keycloak 實例，因為開啟檔案數量的限制實際上是執行緒數量的限制。之後，容器會抱怨它們無法啟動更多進程。

在較大的機器上測試 cri-o 執行時間時，啟動 Pod 並透過 Kubernetes API 和網路瀏覽器存取它們是不穩定的。Pod 的存活探針不時失敗，且 Pod 會重新啟動。經過一些分析後，原因仍然不明，可能與開啟檔案數量有限有關。

minikube 中的 PVC 將從本機檔案系統掛載。因此，不會檢查 PVC 的大小，並且一個服務可能會填滿磁碟，導致其他服務也無法使用。

為每個追蹤收集的資料量很大，可能會導致 Jaeger Pod 快速發生記憶體不足的情況。為了盡量減少收集的資料量，OTEL_TRACES_SAMPLER_ARG 的值設定為 0.001，以便僅追蹤千分之一的請求。追蹤預設為停用，並可在 Keycloak 的 helm chart 的 values.yaml 檔案中啟用。

作為替代追蹤解決方案，曾考慮使用 Tempo。雖然追蹤透過 OTEL 成功提交，並且依追蹤 ID 搜尋如預期般運作，但搜尋追蹤（目前為 Beta 版）不會傳回某些追蹤（例如刪除使用者）。因此，目前使用 Jaeger 追蹤。

helm chart 的內容最初是由 Cryostat 運算子建立的。在分析 2.0 版本中運算子建立的資源時，沒有支援的方法將所需的環境變數新增至發現的 cryostat-deployment。因此，現在已將其提取並作為 Helm chart 放置在此處。

Cryostat 實例需要在與其連線的 JVM 相同的命名空間中執行。因此，它是 Keycloak 部署的一部分，而不是單獨的 Helm chart。

建立的分析是定期分析，而不是非同步分析。因此，分析將會遭受安全點偏差問題。詳情請參閱 Java 非同步分析器。

目前，在另有證明之前，不使用非同步分析應該已足夠。