[D12] Appmesh and envoy

2023 iThome 鐵人賽

DAY 12

DevOps

SRE/K8S 碎碎念系列第 12 篇

15th鐵人賽

嗷嗷嗷

2023-09-27 00:20:36

608 瀏覽

分享至

某次 release 之後，我們有一隻 client api 發出了 TargetResponseTime >= 1.5 跟 HTTPCode_Target_5XX_Count >= 30.0 的告警。去查了這隻 client api 的 pod logs 後，發現他跳出了

[error] [AppNet Agent] Unable to reach Envoy Admin port: giving up after 4 attempt(s), error: Get "http://127.0.0.1:9901/stats?format=json ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

同時，我們也查了下相關的 pod 跟 deployment，可以看到這句”Readiness probe failed: command "sh -c curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" timed out”以及 envoy OOMKilled，下方我們來一一作解釋

k describe pod client-api
Name:             client-api
.
.
Init Containers:
  proxyinit:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     60m
      memory:  72Mi
    Requests:
      cpu:     10m
      memory:  32Mi

Containers:
  client-api-container
    State:          Running
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
    Restart Count:  1
    Limits:
      cpu:     100m
      memory:  128Mi
    Requests:
      cpu:      100m
      memory:   128Mi
    Liveness:   http-get http://:3000/health-check delay=60s timeout=30s period=10s #success=1 #failure=5
    Readiness:  http-get http://:3000/health-check delay=30s timeout=20s period=10s #success=1 #failure=3

  envoy
    State:          Running
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
    Ready:          True
    Restart Count:  111
    Limits:
      cpu:     60m
      memory:  72Mi
    Requests:
      cpu:      10m
      memory:   32Mi
    Readiness:  exec [sh -c curl -s http://localhost:9901/server_info | grep state | grep -q LIVE] delay=1s timeout=1s period=10s #success=1 #failure=3

Events:
  Type     Reason     Age                    From     Message
  ----     ------     ----                   ----     -------
  Warning  Unhealthy  58s (x56115 over 18d)  kubelet  Readiness probe failed: command "sh -c curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" timed out

k describe client-api-deployment
Name:             client-api-deployment
.
.
Containers:
  envoy:
    State:          Running
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    0
    Ready:          True
    Restart Count:  4
    Limits:
      cpu:     60m
      memory:  72Mi
    Requests:
      cpu:      10m
      memory:   32Mi
    Readiness:  exec [sh -c curl -s http://localhost:9901/server_info | grep state | grep -q LIVE] delay=1s timeout=1s period=10s #success=1 #failure=3

Events:
  Type     Reason     Age                    From     Message
  ----     ------     ----                   ----     -------
  Warning  Unhealthy  7s (x1347 over 5h45m)  kubelet  Readiness probe failed: command "sh -c curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" timed out

什麼是 Readiness probe

在 Kubernetes 中，Readiness Probe 是一個檢查機制，用於確定 Pod 中的容器是否已準備好開始接收流量。當容器成功通過 Readiness Probe 的檢查時，Kubernetes 將該容器標記為 Ready 狀態，並允許該容器開始接收服務的請求。

白話文來說，目前的狀況是檢查 pod 的機制一直失敗，如果檢查失敗，Cluster 就無法將pod 認定為 ready，就會導致服務無法使用。

什麼是 Envoy

Envoy 是一個開源的高性能代理，通常用作服務網格的數據平面。它主要負責節點之間的網絡通信，包括負載均衡、流量路由、安全性和監控。在服務網格架構中，Envoy 通常與控制平面組件（如：Istio、Linkerd 等）一起使用，以管理大型分佈式系統。

白話文來說，每個節點（可以先想像成是 pods）外面包一層專門處理流量的。剛剛前者提到的Readiness probe也會先問節點的 envoy 確認節點狀態

插播：AWS APPMESH & appmesh controller & Envoy

AWS App Mesh 是一個 AWS 的服務，也是一種服務網格，幫助您管理和監控微服務應用程序通信的工具。App Mesh 在每個服務之間建立了一個“網格”，讓您可以更容易地控制它們之間的通信。而appmesh controller 是 Kubernetes 控制器，用於將 Kubernetes 資源（例如 VirtualNode, VirtualService 等）轉換為 AWS App Mesh API 操作，如此我們就可以在 EKS 中更輕鬆地管理 App Mesh，而不必直接操作 AWS App Mesh API。而Envoy 代理會監控 App Mesh API 以獲取最新的設置和流量策略。

白話文就是 Envoy 代理根據從 App Mesh Controller 獲取的指示來管理 Pod 之間的網路通信，並提供內建的計量、日誌和追踪功能。

理解以上內容之後，我們再回來理解現有資訊，今天當 envoy 因為 OOM 建立不起來，kubelet Readiness probe 一直無法跟 envoy 聯繫，於是判斷此服務沒有成功建立，也就不會將流量導入。而等待此服務回應是否建立起來的時間有使用者湧入，但服務並沒有加開成功，所以造成 target response time 上升

Root Cause

根據官方的建議，envoy 應該設定 512 CPU 和至少 64 MiB（envoy 是 CPU intensive application）。但從 deployment 來看，我們的 envoy 只給到 cpu 10m 跟 memory: 32Mi。而因為在 Amazon EKS 集群中，當您使用 App Mesh 時，App Mesh Controller 會自動管理和配置 Envoy 代理。Envoy 代理將作為 sidecar 容器與應用程序容器一起運行，以提供能夠管理和控制流量的功能。而我們的App Mesh Controller是 helm 部署的，所以有了以下手順

helm get values appmesh-controller -n appmesh-system --output yaml > appmesh-value-stage.yaml
// 更改 requests and limit
// CPU 512
// Mem 64
helm upgrade -n appmesh-system appmesh-controller eks/appmesh-controller -f appmesh-value-stage.yaml
kubectl rollout restart deployment/client-api-service-deployment
kubectl describe deployment client-api-service-deployment
kubectl logs client-api-service-pod