The Cloud Camp Week#14 (Recap + Q&A)

Week นี้ Recap + Q&A ผมมีจดๆไว้ สรุปมาดังนี้

Architecture

1. คือตอนนี้เจอเคสที่ว่า service บางตัวต้องอยู่แยกnodeกับ service อื่น เพื่อไม่ให้ทั้งระบบพัง เช่น api service อยู่แยกกับ document service อยากรู้ว่าเมื่อไหร่ควรแยกหรือร่วม พวก criteria

Ans ดูก่อนว่า App Host ที่ไหน VM / Container / Serverless ถัดมาจะแยก หรือร่วมกัน ต้องวัดให้ชัดก่อนว่า ตัว App นั้นๆ ใช้ Resource ไปเท่าไหร่ ทำ Observability ให้มี Metric ออกมา เช่น Resource Consumption / จำนวน Request ที่เข้ามา / Connection ที่ถืออยู่ เป็นต้น

พอวัดได้แล้ว เราเอา Metric นั้นมากำหนดเงื่อนไข ใช้ Resource ให้คุ้มค่า ในจำนวน Node ที่น้อยสุด ถ้าเป็น K8S

• รู้ Resource Consumption > มากำหนด กำหนด Resource Request / Limit เพื่อไม่ให้ Node รับภาระมากไป
• Health Check - ทำ Readiness Probe เพื่อไม่ให้ Pod นั้นๆ รับภาระมากไป โดยวัดจาก Latency ถ้าช้าเกิน Criteria ที่รับให้ปิดรับ Request

ในกรณีที่ Resource Request / Limit + Readiness Probe แล้วตึงมือ ถึงเริ่มขยับไปใช้ Node อื่น โดยการทำ HPA เพื่อ Scale นั้นเอง

Observability

1. ตอนที่เราเรียนวันเสาร์ได้ลองเอา พวก log, metric, trace ยิงตรงไป display กับอีกวิธีนึงคือไป stamp ลง db แล้วให้ collector ไปเลือกไป คำถามคือเลือกวิธีไหนดี หรือวิธีที่นิยมใช้จริงในปัจจุบัน

Ans ไม่มีถูก ผิดนะ ขึ้นกับการตกลงของทีมนะ ว่าจะยิงตรงเข้า Log / Trace / Metric DB ก็ได้ แต่ถ้าให้

• App มีหน้าที่ติดต่อเอง มันจะรู้จักกับ Log / Trace / Metric DB 3 จุดเลย
• อีกแบบที่แนะนำให้ App ติดต่อกับ Collector อย่าง Grafana Agent / OTLP Collector ซึ่งมันช่วยแปลง Protocol ให้ รวมถึงการทำ process ให้ โดยเจ้าตัว Collector 3 ส่วน
  - Receiver - รับข้อมูลจาก App ได้หลายแบบ เช่น OTLP / Zipkin เป็นต้น
  - Processor - เตรียมข้อมูล เช่น การรวม Log หรือ การเตรียมข้อมูล เพื่อเอาไป Plot เป็น Node Graph หน้าที่ของ Collector
  - Exporter - ส่งข้อมูลออกไป โดยรูปแบบ ประมาณนี้
  --> Receiver > Exporter
  --> Receiver > Processor > Exporter

สุดท้าย ต้องออกแบบกันก่อนว่าจะเก็บอะไร เอาไปใช้อะไร ถ้ามันซับซ้อนมากๆ ทำ Data Pipeline ให้ชัด อาจจะให้ Collector A ทำหน้าทื่ Preprocess จัด Format แล้วให้ Collector B มา Process เข้า Aggregate จาก Log หรือ Derived ข้อมูลออกมาอีกที เช่น ยอดรวมของทุกสาขา

2. เคส Monitor Resource ถ้าเจอ Lazy Loading ทำยังไงครับ

Keyword: Lazy Loading ข้อมูลที่ไม่ได้ Update บ่อยๆ เช่น พวก Cache

Ans Solution

• ฝั่ง app
  - กำหนด TTL Time to Live ของ Cache
  - ถ้า Data นั้นมีผลเยอะไหม ถ้ามี ทำ Job มา Clear Lazy Loading
  - ถ้า Source Data มีแก้ เราสั่ง หลังมัน Save ให้ flush cache ทิ้ง
  - Implement Out-Box Pattern
• ฝั่ง Load Balance
  - กำหนด TTL + ทำ script purge cache ไว้ รันทุกครั้งหลัง deploy เพื่อ Clear รูป / js / css ออก

Kubernetes

1. ขอ demo วิธีเช็ค request pod resource ก่อนที่จะ config ลงไปใน yaml file อีกรอบนึงได้มั้ยคะ จำได้ว่าวันเสาร์เคยทำให้ดูแต่จำไม่ได้แล้ว TT

Ans ก่อนอื่นต้องรู้ก่อนว่า Pod ใช้จริงๆ เท่าไหร่ โดยการเอาส่วน Request / Limit ออกจาก Deployment จากนั้น Deploy แล้วดูด้วยคำสั่ง

kubectl top pod

kubectl top pod -n <<YOUR-NAME-SPACE>>

NOTE: ต้อง Setup Metric Server ให้เรียบร้อยด้วย
มีจด Blog ไว้ The Cloud Camp Week#09 (K8S Part4: Resource/HealthCheck/Scale/Scheduler)

2. ตอน Inject Configmap / Secret ENV เข้า App ถ้า Key ของ App มี : อันนี้แก้ยังไงครับ

Ans ปกติแล้วตัว K8S จะไม่ยอมให้ : ใน Namespace ตัว

ตัว dotnet หารูปแบบ appsetting มีลักษณะ ดังนี้

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "ConnectionStrings": {
    "DefaultCon": "<<YOUR DB CONNECTION STRING>>"
  },
}

ปกติแล้ว เราจะ Inject ENV ตอน Debug ใน launchSettings.json อาจจะใส่เป็น ConnectionStrings:DefaultCon แต่ใน Deployment / Configmap ของ K8S มันไม่ยอมให้ใส่ : ลงไป

ดังนั้นให้ใช้แก้จาก : เป็น __

เดิม ConnectionStrings:DefaultCon
ใหม่ ConnectionStrings__DefaultCon

แต่ถ้าเป็น List ให้ใช้ index แทน

"list": [
"a",
"b"
]

จะได้เป็น

list__0= a
list__1=b

3. จากข้อ 2 ถ้า ENV นำหน้าด้วยตัวเลข ทำยังไงครับ "2AA2BB" แบบนี้
Ans ปกติ ไม่ควรนำด้วยตัวเลย เอาตัวหนังสือมาทำแปะข้างหน้าดีกว่า เดี่ยวจะมีปัญหากับบาง Runtime / OS

4. อยากให้ยกตัวอย่าง usecase ของการหนด pvc,pv ยังไม่ค่อยเข้าใจว่าใช้งานจริง แตกต่างกันยังไง

Ans Pod ไม่เก็บข้อมูลนะ ถ้าตายแล้วตายเลย ดังนั้นเลยมีแนวคิดของ PV / PVC ขึ้นมา โดยที่

• PV ขอจองพื้นที่ตาม Criteria เช่น Storage Class / Policy Read/Write ..
• PVC ใช้ตามที่จองไว้ใน PV

5. ปกติควรทำ healthcheck ใน level ของ Load balancer หรือ container หรอคะ

Ans ควรทำทุก Level Load balancer + container โดยให้ LB Check Pool ไม่เจอ ให้ไปตัวอื่น หรือ Return 500

6. Kubernetes เซ็ตได้หรือเปล่าว่า Node ไหน Allocate ให้ Kubernetes ใช้ได้เท่าไหร่ครับ ป้องกัน Pod ใช้ Mem หมด จน Node ตายครับ

Ans ใช้ Resource Quotas

CI/CD

1. อยากได้ mindmap สรุปการทำงานของ argocd ค่ะ หรือแนะนำ tool อื่นที่ทำงานคล้ายกัน มือใหม่เข้าใจง่าย
ดูที่ละส่วน Flux

Ans

• tool อื่นที่ทำงานคล้ายกับ argocd >> Flux (fluxcd.io)
• ส่วน mindmap สรุปดูจาก Blog ผมก็ได้คับ

• App of App Pattern แยก Micro Service ออกเป็นกลุ่ม

git cart k8s ----monitor by--> [Argo App Cart]-----|
git payment k8s -monitor by--> [Argo App payment]--|-monitor by--> [Argo App Online Shop]
git product k8s -monitor by--> [Argo App product]--|

2. how to optimize ci/cd pipeline build time นอกเหนือจากการ containerize เช่นต้องไปลบไฟล์ที่ไม่จำเป็นตรงไหน) หรือเคลียร์ cache ตรงไหนบ้าง

Ans optimize ci/cd pipeline build time

• ทำให้ Container Image ของเล็กสุด
  - base image วิธีการ multi-stage
  1. Install Dependency ตรงนี้ลดเวลาได้อีก จากทำ Cache ใน CI
  Example node ตอน build ใช้ npm install ci หรือย้ายไปใช้ค่ายอื่น เช่น Bun
  2. Build
  3. Excute (เอาไปลงจริง alipine / distroless / chisel)
  Note ถ้า Test แล้วช้า แบ่ง Test ย่อยทำ Parallel Pipeline
• ใช้ Resource ให้น้อยที่สุด
• ส่วนตัว เอา Code ที่ไม่ใช่ ออกคับ บิ้วเร็วขึ้น dotnet ลองมาแล้ว

ถ้าเอา Image เล็กมีเขียน Blog สรุปไว้นะ Optimize Container image size

แล้วพวก Recap ผมมีสรุปไว้ใน TAG The Cloud Camp by JumpBox ครับผม

วันเสาร์มีเฉลยการบ้าน และให้คุย Final Project กันแล้ว ทำไม่ทัน 5555