ค่าผ่านทางของ AKS — 91 pod ที่ไม่ใช่ของเรา จอง 6 cores ใช้จริง 0.6

ที่มา: เราไม่เคยได้รับคำอธิบายจาก vendor ว่าของพวกนี้คืออะไร เปิดไว้ทำไม ปิดได้ไหม — เลยไม่กล้าแตะ แต่มันกิน resource เยอะจนกระทบการวางแผนจำนวนเครื่อง เอกสารนี้ไล่ดูทีละตัวจากของจริง

วิธีเก็บข้อมูล: kubectl get pods -A -o json + kubectl top + az aks show บน aks-SupperApp-dev · 23/08/2026

ตัวเลขเดียวที่ต้องจำ

Azure จองไว้ 6.0 cores แต่ใช้จริง 0.6–1.2 cores

จองเกินการใช้จริงราว 5–10 เท่า แล้วแต่จังหวะที่วัด

และเพราะ cluster-autoscaler ตัดสินใจจำนวนเครื่องจาก “ที่ที่จอง” ไม่ใช่ “ที่ที่ใช้” ตัวเลข 6.0 cores นี้จึงเป็นตัวกำหนดว่าเราต้องจ่ายค่าเครื่องกี่เครื่อง

⚠️ ตัวเลขการใช้จริงเป็น snapshot และแกว่งแรง — วัด 2 รอบห่างกัน 1 นาทีได้ 629m แล้ว 1,176m (ama-logs แกว่ง 434m→173m) · ทิศทาง “จองเกินหลายเท่า” แข็ง แต่อย่าอ้างตัวเลขเดียวเป็น fact

1. cluster เราประกอบด้วยอะไรบ้าง

🔑 ของ Azure กินที่มากกว่าแอปทั้ง dev และ uat รวมกัน 2 เท่า และคิดเป็น 31% ของกำลังทั้ง cluster (19,300m บน 5 เครื่อง)

2. ไล่ทีละตัว — 91 pod นั้นคืออะไร

เรียงจากที่จองมากไปน้อย · DS = ต้องมี 1 ชุดต่อเครื่อง (โตตามจำนวนเครื่อง) · คงที่ = มีจำนวนตายตัว

3. 🔴 3 เรื่องที่ไม่มีใครเคยอธิบายให้เราฟัง

ข้อ 3.2 กับ 3.3 เป็นข้อเท็จจริงที่ verify แล้ว · ข้อ 3.1 ถูกลดระดับจาก “ข้อกล่าวหา” เป็น “คำถาม” หลัง review เพราะคำอธิบายอยู่ใน config ของเราเอง

3.1 retina-agent รันอยู่ 5 ชุด ทั้งที่ฟีเจอร์ที่ “น่าจะเป็นเจ้าของ” ปิดอยู่

az aks show --query networkProfile.advancedNetworking
{ "enabled": false, "observability": { "enabled": false }, "security": { "enabled": false } }

แต่บน cluster: retina-agent DaemonSet 5 pod จอง 500m + 1,000Mi ใช้จริง 5m · label kubernetes.azure.com/managedby: aks = Azure วางเอง ลบด้วย kubectl แล้วมันกลับมา

⚠️ แก้ไข 23/08 หลัง review: ฉบับแรกเขียนข้อนี้ในรูป “Azure บอกว่าปิดแต่ยังรัน” ซึ่ง สรุปเกินหลักฐาน — คำอธิบายที่ไม่ใช่ความผิดใครอยู่ใน config ของเราเอง:

• retina-config → enablePodLevel: false, plugin แค่ [dropreason, packetforward, linuxutil] = retina basic mode ซึ่งสอดคล้องกับ ACNS ปิด ไม่ได้ขัดกัน
• ama-metrics-settings-configmap → networkobservabilityRetina = true และเราเปิด Managed Prometheus อยู่ (azureMonitorProfile.metrics.enabled = true)

→ retina basic น่าจะมาพร้อม Managed Prometheus ไม่ใช่ advancedNetworking · ยังไม่ได้พิสูจน์เหตุ-ผล (scrape setting อาจเป็น default เฉยๆ) แต่พอที่จะไม่ควรเอาไปยิงใส่ vendor ในรูปข้อกล่าวหา

คำถามที่ถูกต้องคือ “retina basic ผูกกับ Managed Prometheus ใช่ไหม ปิดเฉพาะ retina โดยยังคง Prometheus ไว้ได้ไหม” ไม่ใช่ “ทำไมของที่ปิดแล้วยังรัน”

3.2 csi-azurefile-node รัน 5 ชุด ทั้งที่ไม่มีใครใช้ Azure File เลย

PVC ทั้งหมดใน cluster มี 3 อัน ใช้ managed-csi (Azure Disk) ทั้งหมด — ไม่มีอันไหนเป็น Azure File

security/dependency-track-data    managed-csi
security/sonarqube-data           managed-csi
security/sonarqube-extensions     managed-csi

จอง 200m + 400Mi เพื่อ driver ที่ไม่มีงานทำ · ตัวนี้ปิดได้จริงด้วย az aks update --disable-file-driver

3.3 Azure Policy 16 ข้อ อยู่ใน dryrun ทั้งหมด — รายงานอย่างเดียว ไม่บล็อกอะไร

azurepolicy-k8sazurev1serviceallowedports        dryrun   ละเมิด 76 จุด
azurepolicy-k8sazurev2containerallowedimages     dryrun   ละเมิด 71 จุด
azurepolicy-k8sazurev2blockautomounttoken        dryrun   ละเมิด 60 จุด
...รวม 16 constraint ทั้งหมด dryrun

จอง 360m + 868Mi (5 pod) เพื่อทำหน้าที่ “รายงานว่ามีอะไรผิดกฎ” ซึ่งมีการละเมิดค้างอยู่ 431 จุด และไม่มีใครแก้

คำถามคือ มีใครอ่านรายงานนี้ไหม ถ้าไม่มี = จ่ายค่า audit ที่ไม่มีใครดู · ถ้ามี = ต้องเอาไปเข้า security uplift ไม่ใช่ปิดทิ้ง

4. ⚠️ ปิดจากใน cluster ไม่ได้ — ต้องปิดที่ระดับ Azure

DaemonSet ส่วนใหญ่ติด label addonmanager.kubernetes.io/mode: Reconcile = แก้หรือลบด้วย kubectl แล้ว AKS จะสร้างกลับทันที

🔑 สัญชาตญาณที่ว่า “ไม่กล้าปิด” ถูกต้องแล้ว — และความจริงคือส่วนใหญ่ปิดเองจากใน cluster ไม่ได้ด้วยซ้ำ ต้องไปปิดที่ตัว AKS resource ซึ่งกระทบทั้ง cluster (dev + uat พร้อมกัน)

5. ตารางตัดสินใจ — ถ้าจะปิด ปิดอะไรได้บ้าง

🔴 อ่านหัวข้อถัดไปก่อนใช้เลข 2,660m — เกือบทั้งหมดเป็น DaemonSet ซึ่ง autoscaler ไม่นับแล้ว · ผลจริงต่อจำนวน node = 260m

🔴 แก้ไขสำคัญ (23/08 หลัง review) — 2,660m ไม่ได้ แปลว่าลด node ได้

ฉบับแรกเขียนว่า “2,660m ที่จะได้คืน ≈ เท่ากับที่ต้องตัดพอดีเพื่อลง 4→3 เครื่อง” — ผิด และเป็นการเทียบข้ามหน่วย 2 ชั้น

ผลจริงต่อตัวเลขที่ autoscaler ใช้ตัดสิน = 260m ไม่ใช่ 2,660m

เล็กกว่าที่เขียนไว้ 10 เท่า · คิดเป็น 1.7% ของ user pool

และ 260m นั้นมาจาก Azure Policy ล้วน (gatekeeper-controller + gatekeeper-audit + azure-policy + webhook — เป็น non-DaemonSet ทั้งหมด) ซึ่งเป็นชิ้นที่ต้องผ่าน security owner

แล้วสรุปควรทำอะไร

ประโยคเดิมที่ว่า “จัดการ addon ให้ผลมากกว่าการไล่ปรับ pod ของเราเองทั้งหมดรวมกัน” — กลับด้าน ในแง่จำนวน node ของเราเองให้ผลมากกว่าราว 10 เท่า

⚠️ ตัวเลขเงินในตารางข้างบนมาจากไหน

$208 และ $66 ไม่ใช่เลขที่วัดใหม่วันนี้ — มาจาก Cost Review 21/08 ซึ่งรายงาน Azure Monitor ทั้งบรรทัด = $211.41/เดือน และ Defender ทั้งบรรทัด = $74.82/เดือน

🔴 ทั้งสองบรรทัดเป็นของที่ใช้ร่วมกัน — omsagent และ defender ชี้ workspace เดียวกัน (log-SupperApp-dev) ซึ่งรับทั้ง dev และ uat → ปิดบน cluster นี้ไม่ได้ลบทั้งบรรทัด

และเอกสารต้นทางเองประเมินส่วนที่กู้คืนได้จริงไว้แค่ ”~$30–60 · ปานกลาง — ยังไม่ verify” พร้อมทิ้งคำถามค้างว่ายังไม่เคย query สัดส่วนจริง

ห้ามเอา $208 + $66 = $274 ไปผูกกับ commitment เรื่อง budget — ตัวเลขที่มีหลักฐานรองรับคือ $30–60 · ถ้าจะใช้เลขใหญ่ต้อง query Cost Management แยก meter ContainerInsights/ContainerLogV2 ของ cluster นี้ก่อน

6. คำถามที่ควรถาม vendor

1. retina-agent ผูกอยู่กับอะไร — advancedNetworking.enabled = false แต่ ama-metrics-settings-configmap มี networkobservabilityRetina = true และเราเปิด Managed Prometheus อยู่ · ปิดเฉพาะ retina โดยยังคง Managed Prometheus ไว้ได้ไหม และมันจอง 500m/1GiB เพื่อ basic mode คุ้มไหม
2. csi-azurefile-node จำเป็นต้องรันทุก node ไหม ในเมื่อไม่มี PVC ที่เป็น Azure File เลย · --disable-file-driver มีผลข้างเคียงอะไรกับ cluster ที่รันอยู่
3. ทำไม addon ทุกตัวตั้ง resource request สูงกว่าการใช้จริง 9.5 เท่า · ค่าพวกนี้ปรับได้ไหม หรือ Azure บังคับ · ถ้าปรับไม่ได้ vendor แนะนำให้ sizing node ยังไง
4. azure-npm จอง 1.5 GiB เพื่อบังคับใช้ NetworkPolicy 8 อัน (ทั้งหมดเป็นของ ArgoCD) — จำเป็นไหมสำหรับ non-prod
5. มีเอกสารรายการ addon ที่ Azure เปิดให้เป็น default พร้อมบอกว่าตัวไหนปิดได้/ปิดไม่ได้ไหม — เราไม่เคยได้รับ

7. ที่ยังไม่ได้ยืนยัน

• ตัวเลข kubectl top เป็น snapshot ณ 23/08 และแกว่งแรง — วัด 2 รอบห่างกัน 1 นาทีได้ platform total 629m แล้ว 1,176m · ยังไม่ได้ดู P95 ย้อนหลัง
• 🔴 การจัดหมวดในข้อ 1 มีข้อโต้แย้ง — app-routing-system 3,000m ถูกนับเป็น “เครื่องมือที่เราเลือกติดตั้งเอง” (62% ของก้อนนั้น) แต่จริงๆ เป็น AKS managed addon (ingressProfile.webAppRouting.enabled = true, CR default เป็นของ Azure) · ถ้านับเป็น platform สัดส่วนกลายเป็น 66 / 13 / 21 ซึ่งยิ่งหนุนข้อสรุปของเอกสารนี้ แต่เลข 43% เอาไปนำเสนอเป็น fact ไม่ได้ถ้าไม่บอกเกณฑ์แบ่ง
• ยังไม่ได้พิสูจน์ว่า retina-agent ผูกกับ Managed Prometheus จริง (§3.1 เป็นความสอดคล้อง ไม่ใช่เหตุ-ผล)
• ยังไม่ได้ทดสอบว่าปิด addon ตัวไหนแล้ว pod หายจริงภายในกี่นาที และมีผลข้างเคียงอะไร
• ยังไม่ได้ตรวจว่ามีใครอ่านรายงาน Azure Policy / log ใน Log Analytics จริงหรือไม่ — เป็นคำถามเชิงองค์กร ไม่ใช่เชิงเทคนิค
• ยังไม่ได้ปิดอะไรทั้งสิ้น เอกสารนี้เป็นการสำรวจเพื่อให้ตัดสินใจได้ ไม่ใช่บันทึกการลงมือ