在我們的架構中，有一隻 Cronjob 會產出 report，像是 Payment, Member info 等，某天他突然掛掉，導致 report 沒有正常產出，發現這個問題後我們開始排查。

$ k describe job  generate-payment-history-report-cronjob-manual-20221026
Name:             generate-payment-history-report-cronjob-manual-20221026.
.
.
Events:
  Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  2m46s (x29 over 145m)  job-controller  Error creating: Internal error occurred: failed calling webhook "mpod.appmesh.k8s.aws": failed to call webhook: Post "https://appmesh-controller-webhook-service.appmesh-system.svc:443/mutate-v1-pod?timeout=30s": no endpoints available for service "appmesh-controller-webhook-service"

看起來是 appmesh-controller 出了點問題，我們再細查 appmesh-controller 相關 endpoints，發現真的不見了

k get endpoints -n appmesh-system
NAME                                 ENDPOINTS         AGE
appmesh-controller-webhook-service                    657d

由於是 appmesh controller 的問題，屬於 Cluster 內行為。剛好我們 cluster 有開啟 Control Plane 相關 Log Group，所以我們追查到 Control Plane Log 的 Kubernetes API server component logs 跟 Controller manager。

我們在 API Server Log 中有看到以下重複的 Error

===== API Error Logs =====
{"@timestamp":"xxx","@message":"I1025 xxx       9 healthz.go:261] etcd check failed: healthz\n[-]etcd failed: error getting data from etcd: context deadline exceeded"}

{"@timestamp":"xxx","@message":"I1025 xxx       9 healthz.go:261] etcd check failed: healthz\n[-]etcd failed: error getting data from etcd: context deadline exceeded\n{\"level\":\"warn\",\"ts\":\"2022-10-25T08:38:27.193Z\",\"logger\":\"etcd-client\",\"caller\":\"v3/retry_interceptor.go:62\",\"msg\":\"retrying of unary invoker failed\",\"target\":\"etcd-endpoints://0xc000e2aa80/#initially=[

並且可以看到事件發生時 API server 和 kube-scheduler 的 Healthcheck 有瞬間掉下去一下。

總結到此，我們大概可以知道幾個脈絡

1. Pod "appmesh-controller-6fc8ccd978-jp9gx" 有出現損毀並且重啟的動作。並且在當下 appmesh-controller webhook 是由一個單副本的服務 (single-replica pod) 所提供
2. appmesh-controller 的 pod logs 有顯示使用 ConfigMap 進行相關 leader election 的行為，在 Pod 損毀期間，有發現 cluster 在 etcd 的部分有相對高的延遲，這部分有可能造成更新 ConfigMap 延遲，並且導致 appmesh-controller pod 失敗的情形
3. 事發期間 API server / etcd 或是等等元件有問題，進而造成 appmesh controller webhook service endpoint 的 IP 沒有與 Pod 一併更新成功。在 webhook Pod 無法被連線時，所有相關 API 請求皆被阻擋，並且在事件過程中 API Server 可以觀察到呼叫該 webhook 失敗的相關請求報錯。

優化方式

1. 從 EKS best-practice 中我們可以得知它建議所有 webhook 服務的 Pod 相關設定為至少兩個 replica (2 個 Pod以上)，並且考慮使用 pod disruption budgets，此設定可以讓該服務中的其中一個 Pod 被終止後依照需求重新部署，而另一個 Pod 則可以正常維持提供該服務，這樣可以避免相關請求因為此調度/更新而失敗。
2. 此 Pod 調整為可以承擔 Kubernetes API 服務相關偶發事件/延遲/中斷的設定，例如，當 Kubernetes API 因為安全更新而重啟。appmesh-controller 的相關 Pod 應該更新為當在與 Kubernetes API 溝通時，可以容忍偶發失敗和重試。
3. API server / etcd 等問題只能詢問 AWS 是否有查到相關問題