又到了寫文章記錄踩雷的時刻，這次是發生在 AWS EKS 遇到了 Pods scale 之後，沒辦法自動註冊到 Target Group 的問題，順手紀錄一下這個解包的過程。
在開始前還是要說一句 EKS Managed node groups 是你各位的好朋友 XDD … 如果可以用 Managed node groups 事情會簡單很多。
AWS EKS 基本上是依靠 AWS Load Balancer Controller (Ingress) 作為 ALB/NLB/CLB <> EKS 之間的橋樑，詳細可以參考 AWS Load Balancer Controller on EKS 和 AWS Load Balancer Controller 這兩篇文件
在這篇的案例是拿 game-2048 作為部署的 Example，這是一個很簡單的 Namespace + Deployment + Service + Ingress 的 App 部署 (詳細參考 2048_full.yaml)，小弟很常拿來作為 Demo 範例，因為很難出錯，如果出錯絕對就是自己的錯 XDD …
很不幸的在最近的一次就遇到了 Ingress 運作不正常的情況，運行的幾個環境和情境確認：
- AWS Load Balancer Controller 安裝步驟確認無誤，並且 Deployment 運作正常
- game-2048 部署成功並且的 service 能跑在 instance NodePort 上存取得到
- AWS ALB 和 Target Group 建立完成
kubectl get ingress可拿到 ALB domain name- Target Group 沒有任何 register instance
綜合以上問題嘗試了多次 kubectl scale 調整 --replicas 數量沒反應後，因為 NodePort 其實是能存取到 game-2048 的服務，所以第一步先排除是 application 的問題，直搗黃龍認為是 AWS Load balancer Controller 可能哪邊有誤。
基於過去維護 infra 的經驗，查找 Logs 大概是最容易找到問題出在哪，以 AWS Load balancer Controller 來說直接查 deployment 應該能看到一些蛛絲馬跡：
$ kubectl logs deployment/aws-load-balancer-controller -n kube-system沒意外的話應該會看到一些有用的訊息像是：
"error":"expect exactly one securityGroup taggedwith kubernetes.io/cluster/eks for eni eni-0e11cbc41dd583bec, got: [sg-049023cdb5ba456e2 sg-07ebe4fc4071bc764]"看起來又是 Security Group 又是 Tag 又是 eni 的，馬上轉到 Amazon EKS security group considerations 啃一下文件回憶一下，在文件最後其實有提到
One, and only one, of the security groups associated to your nodes should have the following tag applied: For more information about tagging
原來是每當 AWS Load balancer Controller 要 register instance 時會去修改 Security Group 的 inbound，而修改的依據是有下 tag 的 Security Group
Key: kubernetes.io/cluster/<cluster-name>
Value: owned而一個 Worker node 可以有多個 Security Group，但只能有 1 個 Security Group 擁有這個 tag，這樣 Load balancer Controller 才知道要修改哪一個 Security Group。
在這個案例中，我的 Worker node 掛上了兩張 Security Group 而且都有 kubernetes.io/cluster/<cluster-name> 的 tag 導致 Load balancer Controller 不曉得要更新哪一張 Security Group。
移掉其中一張 Security Group 的 tag 後就正常工作了。所以說請愛用 Managed node groups …