DevOps

[PlAwAnSaI]

DevOps Saturday

แชร์วิดีโอของคุณกับเพื่อน ครอบครัว และผู้คนทั่วโลก

www.youtube.com

ข้อมูลเบื้องต้นเกี่ยวกับ DevOps: ทำความเข้าใจหลักการและ Lifecycle

แนวคิดและวัตถุประสงค์ของ DevOps:

• DevOps คือแนวคิดและการปฏิบัติ
• ที่มุ่งเน้นการประสานงานระหว่าง Team พัฒนา (Development) และ Team ปฏิบัติการ (Operations)
• วัตถุประสงค์สำคัญ:
  • ส่งมอบ Feature ได้เร็วขึ้น
  • เพิ่มประสิทธิภาพและการทำงานร่วมกัน
  • ยกระดับคุณภาพและความเสถียรของระบบ

ประโยชน์ของ DevOps ในองค์กร:

• ลดเวลาออกสู่ตลาด (Time to Market)
• เพิ่มความถี่ในการ Deploy (Deployment Frequency)
• เพิ่มความเสถียรและความน่าเชื่อถือ
• ใช้งานทรัพยากรอย่างคุ้มค่าและขยายระบบได้ง่าย

90DaysOfDevOps/README.md at main · ThaiCPE/90DaysOfDevOps

Contribute to ThaiCPE/90DaysOfDevOps development by creating an account on GitHub.

github.com

 

[PlAwAnSaI]

https://medium.com/@pbijjala/studynotes-kcna-certification-96ee4aa2b514

KCNA Certification ใน 3 ขั้นตอนง่ายๆ

CNCF Kubernetes and Cloud-Native Associate (KCNA)

KCNA เป็น Certificate ระดับโลกของ CNCF ในระดับเริ่มต้นที่สอน:

• Landscape ของ Technology Cloud Native
• ส่วนประกอบหลักของ Kubernetes
• โครงการ CNCF จำนวนมากที่เกิดขึ้นอย่างรวดเร็ว เครื่องมือ Cloud-native
• ภาพรวมทั่วไปของความปลอดภัย การ Deploy และการ Monitor
• โครงสร้างและ Governance ของ CNCF และชุมชนอื่นๆ ของ Cloud-Native
• เป็น Cert ตัวแรกสู่ Cert ระดับสูงอย่าง CKAD, CKA

Kubernetes เป็นหนึ่งใน Technology ที่ Hot ที่สุดในโลก!

นี่คือบันทึกและสื่อที่เรารวบรวมไว้ระหว่างการเตรียมตัวสำหรับการสอบ มันง่ายที่จะเตรียมตัวและทำข้อสอบถ้าคุณเคยรู้จักหรือใช้ Kubernetes มาก่อน ไม่ว่าจะเป็นการใช้งานโดยตรงหรือผ่านบริการ Cloud ต่างๆ เช่น EKS ในบางกรณี ใช้เวลาในการทบทวนหัวข้อและเอกสาร Kubernetes ประมาณหนึ่งสัปดาห์เพื่อเตรียมตัวเอง

เรารู้สึกว่าทั้ง 3 ขั้นตอนนี้จะเพียงพอในการทำให้ได้รู้ลึกและกว้างที่จำเป็นสำหรับการสอบ:

1. ศึกษา KCNA Overview จาก CNCF พร้อมกับหลักสูตรโดยเฉพาะ Video การบรรยายของ Andrew Brown ความยาว 14 ชั่วโมงเกี่ยวกับ KCNA เราได้ใช้ Course Free ของ ExamPro ซึ่งมีการจัดหัวข้อไว้อย่างดี นอกจากนี้ ExamPro ยังมีแบบทดสอบสำหรับฝึกฝน ซึ่งแบบทดสอบเหล่านี้มีความใกล้เคียงกับข้อสอบ KCNA จริง ทั้งในแง่ของความกระชับและความลึกของเนื้อหา
   
   
   
   
2. ทำความเข้าใจกับโครงการและ Landscape ของ CNCF เคยมีคำถามเกี่ยวกับเครื่องมือของ CNCF เพียง 2-3 ข้อเท่านั้น ดังนั้นการรู้จักโครงการหลักๆ จะเป็นประโยชน์ แต่คำถามเกี่ยวกับ CNCF Personas และ Governance Model พบได้หลายข้อ (เป็นตัวเลือกเสริม) Video Series CNCF Minutes ของ Saiyam Pathak อาจช่วยให้เข้าใจเครื่องมือและมาตรฐานที่ใช้งานได้ดี แต่ไม่ได้ครอบคลุมทุกโครงการที่ Graduated และ Incubating
   
   
3. สร้างความคุ้นเคยกับ kubectl โดยเริ่มต้นจาก Cheat Sheet ซึ่งเป็นตัวช่วยที่ดี นอกจากนี้การเก็บไฟล์ PDF ของผลลัพธ์ Minikube จากการทดลองของคุณจะช่วยให้สามารถเรียกดูได้อย่างรวดเร็ว ตัวเลือกในข้อสอบค่อนข้างซับซ้อน ดังนั้นการฝึกฝนในขั้นตอนนี้ซ้ำหลายๆ ครั้งจะช่วยได้มาก

คนที่จะเหมาะสำหรับ CNCF KCNA หาก...:

• คุณยังใหม่ใน Cloud-native และ Kubernetes และอยากเรียนรู้ขั้นพื้นฐาน
• คุณอยู่ในระดับผู้บริหาร Management หรือ Sale และอยากรู้ข้อมูลเชิงกลยุทธ์เกี่ยวกับ Cloud-native สำหรับการนำไปใช้หรือการ Migrate
• คุณเป็นวิศวกร Cloud อาวุโส หรือ Solution Architect ที่อยากเพิ่มความรู้ Kubernetes และ Cloud-Native อย่างรวดเร็ว

CNCF KNCA เป็นการสอบที่ยากสำหรับมือใหม่ คุณจะต้องมีทั้ง Hands On และความรู้ที่กว้างของโครงการ Kubernetes และ Cloud Native

สำหรับคนที่อยู่ใน Role การ Implement ทาง Technique อยู่แล้ว เช่น Kubernetes Engineer, Cloud Native Engineer จะไม่เพียงพอที่จะได้ Role Cloud-native แต่มันสามารถช่วยให้ Resume ของคุณเด่นขึ้นมาสำหรับการสัมภาษณ์

เมื่อคุณได้ Cert นี้คุณจะ ...:

• สามารถ Deploy App ง่ายๆ ใน Cluster Kubernetes
• เข้าใจส่วนประกอบต่างๆ ของ Kubernetes สำหรับผู้ใช้งาน
• แต่ยังไม่พอที่จะ Deploy App สำหรับใช้งานเป็น Production

แล้วใช้เวลาเรียนเท่าไหร่?:

• 50 ชั่วโมง (ชม) สำหรับผู้เริ่มต้นที่ไม่เคยทำ Linux, Network หรือ Cloud, ไม่เคยเขียน Code หรือทำงานด้าน Technology
• 20 ชม สำหรับคนที่มีประสบการณ์จริงในการทำงานกับผู้ให้บริการ Cloud, มีความรู้ในทางปฏิบัติเกี่ยวกับ Linux และ Linux Networking, ทำงานด้าน Technology มาซักระยะ

เวลาเรียนเฉลี่ย 30 ชั่วโมง:

• การบรรยายและ Lab 50%
• Practice Exams 50%

เรียนวันละ 1-2 ชั่วโมง ก็จะประมาณ 20 วัน

ข้อสอบมี 5 Domain: https://github.com/cncf/curriculum/blob/master/KCNA_Curriculum.pdf

1. 46% - พื้นฐาน Kubernetes 27-28 ข้อ
2. 22% - Container Orchestration 25 ข้อ
3. 16% - Container Native Architecture 25 ข้อ
4. 8% - Cloud Native Observability 4-5 ข้อ
5. 8% - การ Deliver App แบบ Cloud Native 4-5 ข้อ

• ผ่านต้องได้ *750/1000 หรือประมาณ 75% CNCF อาจใช้ Scaled Scoring
• มี 60 ข้อ ผิดได้ 15 ข้อ คำถามเป็นแบบ Choice และ หลายคำตอบ
• มีเวลา 90 นาที หรือข้อละนาทีครึ่ง
• Cert มีอายุ 3 ปี
• ตกได้รอบนึง รอบสองสอบ Free

Cloud-Native คืออะไร?:

Cloud-native อธิบายถึงสถาปัตยกรรมที่เน้นการใช้งาน Workload ที่ *พกพาได้ (Portable) เป็น Module (Modular) และแยกออกจากกัน (Isolate) ระหว่างผู้ให้บริการ Cloud ด้วย Model การ Deploy ที่แตกต่างกัน

ผู้ให้บริการ Cloud มักจะอธิบาย Cloud-Native ว่าเป็นคำที่มีความหมายว่าทุกอย่างที่สร้างขึ้นบน Cloud หรืออธิบายที่ดีกว่าเรียกว่า "Cloud-First"

บางคนอธิบายว่า Cloud-Native เป็นหลักการสำคัญ 4 ประการ คือ:

1. Microservices
2. อยู่ใน Container
3. Delivery อย่างต่อเนื่อง
4. DevOps

ใน KCNA, Cloud-Native จะหมายถึง Technology เช่น Kubernetes และโครงการ CNCF ที่อยู่บนผู้ให้บริการ Cloud เจ้าไหนก็ได้

CNCF นิยามว่า:

Technology Cloud Native ช่วยให้องค์กรสามารถสร้างและ Run App ที่ปรับขนาดได้สมัยใหม่, Dynamic, Environment เช่น Public, Private และ Hybrid Cloud
Container, บริการ, Meshes, Microservices, โครงสร้างพื้นฐานที่เปลี่ยนแปลงได้ และ Declarative API

Technique เหล่านี้ช่วยให้ระบบ Loosely Couple ซึ่งมี Resilient, จัดการได้ (Manageable) และสังเกตเห็นได้ (Observable)

เมื่อรวมกับระบบอัตโนมัติที่แข็งแกร่ง มันจะช่วยให้วิศวกรสามารถทำการเปลี่ยนแปลง Impact สูงๆ ได้บ่อยครั้ง และจะได้รับผลกระทบน้อยที่สุด

Cloud Native Foundation พยายามที่จะผลักดันการใช้วิธีนี้โดยการส่งเสริมและสนับสนุน Ecosystem ของ Open Source โครงการไม่มี Vendor Lock-in

CNCF จึงรวบรวมรูปแบบที่ทันสมัยเพื่อทำให้นวัตกรรมเหล่านี้เข้าถึงทุกคนได้

ผู้ให้บริการ Cloud (CSP):

• Collection ของบริการบน Cloud
• การ Integrate App ที่แข็งแกร่งและการทำงานร่วมกันระหว่าง Service
• การใช้การเรียกเก็บเงินตามการใช้งานจริง
• ภายใต้ Unified API เดียว

Cloud-Native คือ Workload, App หรือระบบที่ออกแบบมาเพื่อทำงานบน Cloud และ "ใช้ข้อดีของ Cloud"

Workload Cloud-Native ไม่สามารถใช้ประโยชน์จากข้อดีทั้งหมดของผู้ให้บริการ Cloud ได้ เพราะแต่ละเจ้า Technology ไม่เหมือนกัน เพื่อดึงดูดให้คุณใช้บริการของพวกเค้าซึ่งมีการ Integrate กับบริการอื่นโดยเฉพาะ

Cloud Native Shared Responsibility Model:

The Linux Foundation (LF) เป็นองค์กรที่ไม่แสวงหาผลกำไรทาง Technology ก่อตั้งในปี พ.ศ. 2543 เป็นการควบรวมกิจการระหว่าง Lab การพัฒนา Open Source (Open-Source Development Labs) และกลุ่มมาตรฐานเสรี (Free Standards Group) เพื่อสร้างมาตรฐาน Linux, สนับสนุนการเติบโต และส่งเสริมการ Adopt เชิงพาณิชย์

LF ได้รับการสนับสนุนจากบริษัท Technology ต่างๆ เช่น AT&T, Tencent, Microsoft, FUJITSU, Google, ORACLE, Qualcomm, HUAWEI, HITACHI, NEC, vmware, SAMSUNG, facebook, orange, intel, etc.

Cloud Native Computing Foundation (CNCF) เป็นโครงการของ Linux Foundation ที่ก่อตั้งขึ้นในปี 2558 เพื่อช่วยพัฒนา Technology Container

CNCF ดำเนินงานในฐานะองค์กรอิสระจากองค์กรแม่:

• มีสมาชิกคณะกรรมการเป็นของตัวเอง
• มีการประชุม Technology ระดับโลกของตัวเองชื่อ: CloudNativeCon + KubeCon
• มีใบรับรอง Cloud Native ของตัวเอง
• มีชุดโครงการของตัวเอง: Kubernetes, Prometheus, Etcd, ContainerD และมากกว่านั้น...

Cloud Native Landscape เป็นแผนที่แบบ Interactive ที่พัฒนาโดย CNCF เพื่อแสดง Technology Cloud-native ทั้งหมดที่มีอยู่ และเพื่อช่วยระบุหมวดหมู่ที่พวกเค้าให้บริการ

The Cloud Native Trail Map เป็นเส้นทางที่แนะนำในการนำสถาปัตยกรรม Cloud-Native มาใช้

 

[PlAwAnSaI]

1. 
   
2. 
   
3. 
   
4. 
   
5. 
   
6. 
   
7. 
   
8. 
   
9. 
   
10. Notary และ The Update Framework (TUF) เป็นสองโครงการสำคัญด้านความปลอดภัยภายใต้ CNCF ที่มุ่งเน้นการรักษาความปลอดภัยในการ Distribute Software และความถูกต้องของการ Update Software

ลำดับเส้นทางจะแตกต่างกันไปตามกรณีการใช้งานของคุณ

Virtual Machines (VMs) ใช้พื้นที่ไม่คุ้มค่าที่สุด App ไม่ได้ถูกแยกออกจากกัน ซึ่งอาจทำให้เกิดความขัดแย้งในการ Config, ปัญหาด้านความปลอดภัย หรือการใช้ทรัพยากรมากเกินไป

Container ช่วยให้คุณสามารถ Run App ได้หลาย App ซึ่งจะแยกกันอยู่, Launch Container ใหม่และ Config OS Dependency ต่อ Container

สถาปัตยกรรมแบบ Monolithic - App เดียวรับผิดชอบทุกอย่าง, Function เชื่อมต่อกันอย่างแน่นหนา (Tightly Coupled)

สถาปัตยกรรม Microservices - หลาย App แต่ละ App รับผิดชอบอย่างเดียว, Function แยก (Isolate) และ Stateless

Thai ComPuter Engineer - Thaicpe

Microservices Pattern — The API Gateway: https://siamchamnankit.co.th/ลองสรุป-microservices-pattern-the-api-gateway-eeb6ca40238 . Kong API Gateway ฉบับรวบรัด:...

www.facebook.com

Kubernetes เป็นระบบ Container Orchestration แบบ Open source สำหรับการ Deploy, การปรับขนาด และการจัดการ Container โดยอัตโนมัติ

เดิมสร้างโดย Google และได้รับการดูแลโดย CNCF นับเป็นโครงการนึง

• 8 แทนตัวอักษรที่เหลือ "ubernete"

**ข้อดีของ Kubernetes ที่ดีกว่า Docker คือความสามารถในการ Run "Container App" บน VM หลายตัว

ส่วนประกอบเฉพาะของ Kubernetes คือ Pods
Pod เป็นกลุ่มของ Container หนึ่งในหลายกลุ่มที่มีการ Share ที่เก็บข้อมูล เครือข่าย และการตั้งค่าที่ใช้ร่วมกันอื่นๆ

Kubernetes เหมาะสำหรับสถาปัตยกรรม Micro-service ที่บริษัทมีบริการหลายสิบถึงร้อยที่ต้องจัดการ

ภาพรวมส่วนประกอบของ Kubernetes:

• Cluster:
  การจัดกลุ่มแบบ Logical ของส่วนประกอบทั้งหมดภายใน Cluster
  
  
• Namespace:
  การจัดกลุ่มแบบ Logical ที่ตั้งชื่อส่วนประกอบของ Kubernetes ภายใน Cluster
  ใช้เพื่อแยก Workload ที่แตกต่างกันบน Cluster เดียวกัน
  
  
• Node:
  VM หรือ Server มี 2 แบบ คือ Control Plane และ Worker Node
  Worker Node คือที่ที่ App ของเราหรือ Workload อยู่ ส่วน Control Plane Node เอาไว้ควบคุมจัดการ Worker Node
  
  
• Pod:
  เป็นหน่วยที่เล็กที่สุดใน K8s มันจะห่อ Container เอาไว้ ตาม Best Practice ต้องมี Container หลักตัวเดียวข้างในเท่านั้น
  
  
• Service:
  Static IP และชื่อ DNS สำหรับชุดของ Pod (ยังอยู่แม้ว่า Pod ตายไปแล้ว) และ Load Balancer
  อาจหมายถึง Container ที่ทำงานอย่างต่อเนื่อง
  
  
• Ingress:
  แปลง HTTP/S Rule เพื่อ Point ไปหา Service

 

[PlAwAnSaI]

https://medium.com/sirisoft/kubernetes-zero-2-hero-26523dc068be

https://www.aware.co.th/th/kubernetes-101-สิ่งที่จำเป็นต้องรู้

• API Server:
  ช่วยให้ผู้ใช้สามารถโต้ตอบกับส่วนประกอบของ K8s โดยใช้ KubeCTL หรือโดยการส่งคำขอ HTTP
  
  
• Kubelet:
  เป็น Agent ที่ติดตั้งบนทุก Node ช่วยให้ผู้ใช้สามารถโต้ตอบกับ Node ผ่าน API Server และ KubeCTL ได้
  
  
• KubeCTL:
  Command Line Interface (CLI) ที่อนุญาตให้ผู้ใช้โต้ตอบกับ Cluster และส่วนประกอบผ่าน API Server
  
  
• ตัวจัดการ Cloud Controller (Manager):
  อนุญาตให้คุณเชื่อมโยงผู้ให้บริการ Cloud (CSP) เช่น AWS, Azure, GCP เพื่อใช้ประโยชน์จากบริการ Cloud
  
  
• ตัวจัดการ Controller (Manager):
  Controller Loop ที่ดูสถานะของ Cluster และจะเปลี่ยนสถานะปัจจุบันกลับเป็นสถานะที่ต้องการ
  
  
• Scheduler:
  กำหนดตำแหน่งที่จะวาง Pod บน Node ไหน โดยการ Schedule ตาม Queue
  
  
• Kube Proxy:
  App บน Worker Node ที่จัดการ Routing และการ Filter Rule สำหรับ Ingress (Incoming) ข้อมูล (Traffic) ไปยัง Pod
  
  
• Network Policy:
  ทำหน้าที่เป็น Virtual Firewall ในระดับ Namespace หรือระดับ Pod
  
  
• ConfigMap:
  อนุญาตให้คุณแยกการ Configure Environment ออกจาก Container Image ของคุณได้ ดังนั้น App ของคุณสามารถ Deploy ได้ง่าย (Portable) ใช้ในการจัดเก็บข้อมูลที่ไม่เป็นความลับใน Key-value Pair
  
  
• Secret:
  ข้อมูลละเอียดอ่อน เช่น รหัสผ่าน Token หรือ Key
  
  
• Volumes:
  การติดตั้งที่เก็บข้อมูล เช่น Local บน Node หรือ Remote ไปยังที่เก็บข้อมูลระบบ Cloud
  
  
• StatefulSet:
  การันตีเกี่ยวกับการจัดลำดับ และความเป็นเอกลักษณ์ของ Pod เหล่านี้
  • คิดถึงฐานข้อมูลที่คุณต้องกำหนดลำดับการอ่านและเขียนหรือจำกัดจำนวน Container
  • StatefulSets มีความยาก เมื่อคุณสามารถ Host DB ของคุณภายนอกจาก Cluster K8s
  
  
• ReplicaSets:
  รักษาเสถียรภาพของชุด Replica Pod ที่ทำงานในเวลาที่กำหนด สามารถรับประกันความพร้อมใช้งาน
  
  
• Deployment:
  เป็นพิมพ์เขียวสำหรับ Pod (คล้าย Launch Template)

Manifest (ไม่ใช่คำอธิบายทาง Technique):
เป็นเอกสารที่ใช้กันทั่วไปสำหรับศุลกากรเพื่อแสดงรายการเนื้อหาของสินค้า หรือผู้โดยสาร มันเป็นรายการสิ่งของต่างๆ

Manifest File (ของ Kubernetes):
ก็คือ File Configure Kubernetes ต่างๆ ที่กำหนดค่า Component K8s นั่นเอง

ตัวอย่าง Manifest File ที่มีวัตถุประสงค์เฉพาะ:

• Deployment File
• PodSpec File
• Network Policy File

Manifest File สามารถเขียนได้ในรูปแบบ:

• YAML
  

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
      - containerPort: 80

• JSON
  

  {
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
      "name": "nginx"
    },
    "spec": {
      "containers": [
        {
          "name": "nginx",
          "image": "nginx:1.14.2",
          "ports": [
            {
              "containerPort": 80
            }
          ]
        }
      ]
    }
  }

  

  Transform YAML into JSON - Online YAML Tools

  Free, quick and easy online utility that converts YAML to JSON in your browser. There are no ads or downloads. Simply enter YAML and get JSON. Created by developers for developers.

  onlineyamltools.com

Manifest สามารถมีส่วนประกอบ K8s Definition/Configure หลายรายการได้

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
--- > ใน YAML คุณจะเห็น - สามอัน ถูกใช้เพื่อกำหนดหลายองค์ประกอบ
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl apply โดยทั่วไปใช้ในการ Deploy Manifest File

kubectl apply -f resources.yml

Resource Configuration File บางครั้งใช้เพื่ออธิบายหลาย Resource ใน Manifest

Control Plane Node (รู้จักกันอย่างเป็นทางการว่า Master Node):
จัดการกระบวนการต่างๆ เช่น การกำหนดเวลา การ Restart Node...

• API Server - Backbone ของการสื่อสาร
• Scheduler - กำหนดว่าจะ Start Pod ตรงไหนบน Worker Node
• Controller Manager - คอยตรวจสอบการเปลี่ยนแปลงสถานะ (หาก Pod พัง ให้ Restart)
• etcd - Key/ค่าที่จัดเก็บสถานะของ Cluster
• Kubelet - อนุญาตให้ผู้ใช้โต้ตอบกับ Node ผ่าน KubeCTL

Worker Node:
Running App ของคุณใน Pod และ Container ... จะ Run:

• Kubelet
• Kube Proxy
• Container Runtime
• Pod และ Container

Pod:
เป็นหน่วยที่เล็กที่สุดใน Kubernetes ถ้าเราต้องการจะ Run Container เราต้องเอา Container ของเรายัดเข้าไปใน Pod ก่อนถึงจะ Run ได้

Pod มีวัตถุประสงค์เพื่อเรียกใช้ App เดียวในหลาย Container

• Pod ฐานข้อมูล, Pod งาน, Pod App Frontend, Pod App Backend
• คุณสามารถ Run App ได้หลาย App ใน Pod แต่เวลา Container พัง/Restart/ลบ ก็จะไปทั้งหมด

แต่ละ Pod จะมี IP Private ของตัวเอง:

• แต่ละ Container ใน Pod จะทำงานบน Port ต่างกัน
• Container สามารถพูดคุยกันผ่าน Localhost

แต่ละ Pod สามารถมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน Attach มา

• Container ทั้งหมดจะ Share ใช้ Volume เดียวกัน

เมื่อ container สุดท้ายที่เหลืออยู่ใน Pod หยุดทำงาน (หรืออาจจะเกิด Crash):

• เมื่อมีการสร้าง Pod ใหม่เพื่อทดแทน Pod นั้นจะได้รับการกำหนด IP Address
  • IP address ของ Pod เป็นแบบชั่วคราว (Ephemeral) โดยปกติแล้วจะไม่คงอยู่ถาวร

ถ้าคุณต้องการดู Pods และ IP Address ของ pod

kubectl get pod -o wide

Core ของ Kubernetes Control Plane คือ API Server มันจะเปิดให้บริการ HTTP API ที่ช่วยให้ผู้ใช้งาน, ส่วนต่างๆ ของ Cluster และ Component ภายนอกสามารถสื่อสารกันได้

Kubernetes API ช่วยให้คุณสามารถค้นหาและจัดการสถานะของ API Objects ใน Kubernetes (เช่น: Pod, Namespace, ConfigMap และ Event)

API server เป็นส่วนประกอบของ Kubernetes Control Plane ที่เปิดให้เข้าถึง Kubernetes API ได้ ทำหน้าที่เป็นส่วนหน้าบ้าน (Front End) สำหรับ Kubernetes Control Plane

การใช้งานหลักของ Kubernetes API Server คือ kube-apiserver ที่ถูกออกแบบให้สามารถขยายในแนวนอน—นั่นคือ สามารถขยายได้โดยการเพิ่มจำนวน Instances

คุณสามารถ Run kube-apiserver หลาย Instances และกระจาย Traffic ระหว่าง Instances เหล่านั้นได้

ทุกอย่างต้องผ่าน API Server คุณสามารถโต้ตอบกับ API Server ได้ 3 วิธี:

• UI
• API
• CLI KubeCTL

Deployment ใช้สำหรับ Update Pod และ ReplicaSet แบบ Declarative

Deployment Controller เปลี่ยนสถานะจริงให้เป็นไปตามสถานะที่ต้องการในอัตราที่ควบคุมได้

• สามารถเปลี่ยน Default Deployment Controller เป็นเครื่องมือ Deployment อื่นๆ ได้ เช่น: Argo CD, Flux, Jenkin X....

Deployment กำหนดสถานะที่ต้องการของ ReplicaSet และ Pod จะสร้างและจัดการ ReplicaSet
ReplicaSet จะจัดการ Replica ของ Pod หรือ Deployment จะใช้ Object หลังบ้านอย่าง ReplicaSet เวลาต้องการ Scale Pod นั่นเอง

ReplicaSet เป็นวิธีการรักษาจำนวน Redundant Pod (Replica) ที่ต้องการ เพื่อรับประกันความพร้อมใช้งาน

Field Pod metadata.ownerReference กำหนดการเชื่อมต่อจาก Pod ไปยัง ReplicaSet

ไม่แนะนำให้สร้าง ReplicaSets โดยตรง ควรใช้ Deployment ซึ่งมีความสามารถในการทำ Rolling Update และ Rollback จะสร้างและจัดการ ReplicaSet ให้คุณโดยอัตโนมัติแทน

Horizontal Pod Autoscaler (HPA) สามารถใช้ในการปรับขนาด ReplicaSet อัตโนมัติได้

Stateless > ปลาทอง/ปศุสัตว์ > ReplicaSets:

• ไม่สนใจทุกคำขอ (ลืม) เกี่ยวกับสถานะก่อนหน้าหรือปัจจุบัน
• Web-app ที่เก็บ Session ไว้ภายนอก VM Web-app (Database หรือ Cookies) จะเป็น Stateless Web-app
• ส่งคำขอไปยัง Server ไหนก็ได้

Stateful > สัตว์เลี้ยง > StatefulSets:

• ทุกคำขอขึ้นอยู่กับ State ข้อมูล (ความจำ)
• ฐานข้อมูลทั้งหมด Stateful
• Web-app แบบ Monolithic ที่เก็บข้อมูล Session ไว้ในหน่วยความจำบน VM ก็เป็น Stateful
• สามารถเขียนไปยัง Primary DB เท่านั้น

 

[PlAwAnSaI]

Stateful Set จะถูกใช้เมื่อคุณต้องการส่ง Traffic ไปยัง Pod ที่ต้องการ
Stateful Set จะมี:

• ชื่อและที่อยู่ที่ไม่เหมือนใครและคาดเดาได้
• หมายเลข Index ที่กำหนดแต่ละ Pod
• มีการ Attach Persistent Volume (PV) ด้วย Link ที่ไม่เปลี่ยน จาก Pod ไปยังที่เก็บข้อมูล
  • หาก Pod ถูก Reschedule PV จะถูก Mount เพื่อให้แน่ใจว่าข้อมูลมีความสมบูรณ์และสอดคล้องกัน
• Stateful Set Pods จะเริ่มต้นตามลำดับเสมอ (Web-0 > Web-1) และจะถูกยุติการทำงานในลำดับย้อนกลับ (Web-1 > Web-0)

StatefulSets ต้องการ 'Headless' Service เพื่อจัดการ Identity

มี Headless Service ที่ใช้ในการรักษา Network Identity ของ Pod และมีอีก Service นึงที่ให้การเข้าถึงแบบอ่าน (Read Access) ไปยัง Pod

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
    name: www
  spec:
    accessModes: [ "ReadwriteOnce" ]
    storageClassName: "my-storage-class"
    resources:
      requests:
        storage: 1Gi

DNS Hostname สำหรับการเขียนข้อมูล:

• การเขียนข้อมูลจะถูกส่งไปยัง Pod หลักผ่าน DNS Hostname ซึ่งถูกระบุโดย Headless Service

ClusterIP สำหรับการอ่านข้อมูล:

• สำหรับ Traffic การอ่านข้อมูล สามารถกระจายไปยัง Pod ที่ทำหน้าที่อ่านทั้งหมดได้โดยใช้ ClusterIP Service

Headless Service:

• Headless Service คือ Service ที่ไม่มีการตั้งค่า ClusterIP
• ไม่มีการทำ Load Balancing
• ไม่มีการกำหนด IP Address แบบ Static
• Headless Service ใช้เพื่อระบุ Pod เฉพาะโดยการกำหนด DNS Record
• จำเป็นต้องมี Headless Service เพื่อให้ StatefulSet ทำงานได้

PVC และ PV:

• แต่ละ Pod มี Volume เป็นของตัวเอง โดย Persistent Volume Claim สามารถอ้างอิงถึง Persistent Volume ได้แบบ Dynamic

Namespace เป็นวิธีแยก (Isolate) Resource ภายใน Kubernetes Cluster
Namespace สามารถจัดเรียงตามโครงการ แผนก หรือการจัดกลุ่มที่กำหนดโดยผู้ใช้

ดู Namespace ทั้งหมด:

kubectl get namespace

Kubernetes มี 4 Default Namespace:

1. default:
   Namespace เริ่มต้นที่ Pod และบริการทั้งหมดของเรา Run เว้นแต่จะมีการระบุ Namespace
2. kube-public:
   สำหรับ Resource ที่มองเห็นและอ่านได้จาก Public
3. kube-system:
   • Namespace ระบบที่จัดเก็บ Object ที่สร้างโดยระบบ Kubernetes
   • วิศวกรที่ Deploy App ไม่ควรแตะ Namespace นี้
4. kube-node-lease:
   • เก็บ Lease Object (Object ที่ใช้ในการจองหรือยืนยันสถานะการทำงาน) ที่เกี่ยวข้องกับแต่ละ Node ใช้สำหรับตรวจจับความล้มเหลวของ Node โดยการส่งสัญญาณ Heartbeat

สามารถสร้าง Namespace ของคุณเองได้ด้วย:

kubectl create namespace production

ใน Cluster ที่มี Resource จำนวนน้อย Namespace ไม่จำเป็น

ชื่อของ Resource ต้องไม่ซ้ำกันภายใน Namespace แต่สามารถซ้ำกันต่าง Namespace ได้ การกำหนด Namespace ใช้ได้เฉพาะกับ Namespaced Object เท่านั้น เช่น Deployments, Services แต่ไม่สามารถใช้กับ Cluster-wide Object เช่น StorageClass, Nodes, PersistentVolumes ได้

แบ่งเป็น 3 ประเภท:

1. Single-Namespace Object:
   ConfigMaps และ Secrets ไม่สามารถ Share ข้าม Namespace ได้
2. Multi-Namespace Objects:
   Service และ Pods สามารถอยู่ได้หลาย Namespace
3. Cluster-Wide Objects:
   Volumes และ Nodes ไม่สามารถผูกกับ Namespace ได้เพราะเป็น Resource ระดับ Global

คุณสามารถกำหนด System Quota Restriction บน Namespace เพื่อป้องกันการใช้งานเกิน เช่น หน่วยความจำ (Memory), การประมวลผล (Compute)
หากไม่ระบุ Namespace, Component มันจะถูกสร้างใน Default Namespace

ใน Project Cloud-Native คุณจะได้ยินคำว่า "In-Tree" และ "Out-of-Tree"

In-Tree: Plugin, Component หรือ Function การทำงานที่มีมาให้โดย Default และ/หรืออยู่ในที่เก็บ Repo หลัก เหมือนเป็น Internal Plugin

Out-of-Tree: Plugin, Component หรือ Function การทำงานที่ต้องติดตั้งเอง และเป็นส่วนขยายหรือแทนที่ Default Behavior เหมือนเป็น External Plugin

หมายเหตุ: นี่เป็นนิยามของ In-Tree และ Out-of-Tree โดย Andrew เนื่องจากคำศัพท์นี้ยังไม่มีการกำหนดมาตรฐานที่แน่นอน

Endpoints ติดตาม IP Address ของ Pod ที่ถูกกำหนดให้กับ Kubernetes Service
เมื่อตัวเลือกของ Service ตรงกับ Pod Label, IP Address ของ Pod จะถูกเพิ่มเข้าไปในกลุ่มของ Endpoint
Pod Expose ตัวเองให้กับ Service ผ่าน Endpoint

คำสั่งที่ใช้เพื่อดู List ของ Endpoint:

kubectl get endpoints

Endpoint Slices แบ่ง Endpoints ออกเป็นกลุ่มๆ ที่จัดการได้ง่ายขึ้น แต่ละ Endpoint Slice มีข้อจำกัดที่ 100 Podะ

Background Job คืองานที่ทำครั้งเดียวที่ใช้สำหรับ Run Code ชิ้นหนึ่ง มักใช้เพื่อทำงานบำรุงรักษาหรือเริ่มการประมวลผลที่ต้องใช้ทรัพยากรมาก ตัวอย่างเช่น สำรองฐานข้อมูลทุกๆ x นาที, ลบผู้ใช้ทั้งหมดที่ยังไม่ได้ยืนยัน Email

Job จะสร้าง Pod หนึ่งตัวหรือมากกว่า และจะพยายาม Run ไปเรื่อยๆ จนกว่าจะทำงานสำเร็จ

kubectl create job hello --image=busybox -- echo "Hello_World" => สร้าง job ชื่อ hello ใช้ image busybox และแสดงข้อความ "Hello World"

CronJob คือ Job ที่ทำงานตามตารางเวลาที่กำหนดไว้และจะทำซ้ำๆ

kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello_World"

Kubernetes Dashboard คือ App Open source ที่คุณสามารถติดตั้งลงใน Cluster ของคุณ เพื่อใช้เป็นส่วนติดต่อผู้ใช้ (UI) สำหรับดู Component ต่างๆ ของ Kubernetes

Selectors คือวิธีการเลือก Object หนึ่งหรือหลาย Object ใน Kubernetes
ใน Kubernetes มี 3 ประเภท:

1. Label Selector เลือก Object Kubernetes ตาม Label ที่กำหนดไว้
   สามารถกำหนด Label ในรูปแบบ Key/Value Pair ภายใต้ส่วน metadata ใน File Manifest
   สามารถใช้ flag --show-labels เพื่อดู Label ต่างๆ ได้
   

   kubectl get pods --show-labels

   สามารถกำหนด Label ได้ด้วยคำสั่ง label
   

   kubectl label pods apache-web owner=devops

   
   Label และ Annotation ที่ใช้ร่วมกันจะมีคำนำหน้าเหมือนกันคือ: app.kubernetes.io"
   Label ที่ไม่มีคำนำหน้า จะถือว่าเป็นแบบส่วนตัวสำหรับผู้ใช้
   นี่คือ Label ที่แนะนำว่า 'ควร' นำไปใช้กับทุกๆ Resource Object:
   1. app.kubernetes.io/name - ระบุชื่อ App
   2. .../instance - ชื่อเฉพาะของ Instance ของ App
   3. .../version - Version ปัจจุบันของ App (อาจเป็น Version แบบ Semantic หรือ Hash)
   4. .../component - Component ใน Architecture
   5. .../part-of - ชื่อ Level ที่ใหญ่กว่า App ที่ Resource นี้อยู่
   6. .../managed-by - เครื่องมือที่ใช้จัดการ App
   7. .../created-by - Controller/ผู้ใช้ที่สร้าง Resource นี้
      

      # This is an excerpt
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        labels:
          app.kubernetes.io/name: mysql
          app.kubernetes.io/instance: mysql-abcxzy
          app.kubernetes.io/version: "5.7.21"
          app.kubernetes.io/component: database
          app.kubernetes.io/part-of: wordpress
          app.kubernetes.io/managed-by: helm
          app.kubernetes.io/created-by: controller-manager

      K8s Object อย่างเช่น Services และ ReplicaSets จะเลือก Target Pod ตาม Label Selector
      สังเกตว่า Selector Syntax จะแตกต่างกันไปตามแต่ละ Template
      สามารถใช้ Selector ใน KubeCTL Command Line ด้วย --selector หรือตัวย่อ -l
      

      kubectl get pods --selector env=development
      kubectl get pods -l env=development

2. Field Selector เลือก Object ตามข้อมูลของ Object เช่น Metadata, Status
3. Node Selector เลือก Node สำหรับการวาง Pod ที่ต้องการความเฉพาะเจาะจง

 

[PlAwAnSaI]

Annotations ใน Kubernetes ช่วยให้คุณสามารถ Attach Metadata ที่ไม่ระบุเอกลักษณ์ใดๆ กับ Object ได้
Client (เช่น Tool และ Library) อาจต้องการ Annotation เหล่านี้เพื่อให้ทำงานได้
Ingress มักใช้ Annotations เพื่อสื่อสารกับ Ingress Controller
ในการใช้ Nginx Ingress Controller คุณจำเป็นต้องระบุ Path Rewrite-target

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
    paths:
    - path: /testpath
      pathType: Prefix
      backend:
        service:
          name: test
          port:
            number: 80

PodSpec เป็น File Configure ที่อธิบาย Pod > kind: Pod

ส่วน spec จะกำหนด:

• Container หลายตัว
  • ชื่อของ Container
  • Image ที่ใช้
  • คำสั่งที่จะ Run ตอน Start
  • Port ที่ Container จะใช้งาน
  • Policy การ Restart
  • และอื่นๆ

สามารถ Deploy Pod ได้โดยใช้คำสั่ง:

kubectl apply -f nginx.yaml

ในทางปฏิบัติ จะไม่ Deploy Pod โดยตรง แต่จะใช้ Deployment หรือ Job เป็น kind แทน

Remote Procedure Call (RPC) คืออะไร?
RPC เป็น Framework สำหรับการสื่อสารในระบบ Distributed ที่ช่วยให้ Program นึงในเครื่องหนึ่งสามารถสื่อสารกับ Program ในอีกเครื่องได้โดยไม่ต้องรู้ว่าเป็นอีกเครื่องนึง แนวคิดของ RPC มีมาตั้งแต่ช่วงปี 2513

gRPC เป็น Framework RPC แบบ Open Source ที่มีประสิทธิภาพสูง ซึ่งสามารถทำงานได้ในทุก Environment ถูกสร้างขึ้นโดย Google

สามารถมองว่า gRPC เป็น วิธีการสื่อสารอีกทางเลือก แทนการใช้ REST หรือ GraphQL

gRPC สามารถ Connect บริการทั้งภายในและข้าม Data Center ได้ พร้อมทั้งรองรับ Feature ที่สามารถ Plugin เสริมได้ เช่น:

• Load Balancing
• Tracing
• Health Checking
• Authentication

gRPC ทำงานโดย:

• ติดตั้ง Library gRPC ให้ Program ของคุณ
• กำหนด File Protobuf ที่อธิบายโครงสร้างข้อมูล
  • File Protobuf จะมีนามสกุล .proto
• เขียน Code ที่ทำงานร่วมกับ gRPC

ระบบ Distribute เช่น Kubernetes ใช้ gRPC สำหรับการสื่อสารระหว่าง Pod

Kubelet มีหน้าที่ดูแลการสื่อสารของ API ภายใน Pod ผ่าน API Server และเป็น Node Agent ที่ Run อยู่บนทุก Node (ทั้ง Control Plane และ Worker Node)

Agent คือ Program ที่ติดตั้งบน Server เพื่อตรวจสอบสิ่งที่เกิดขึ้นใน Specific Program และสื่อสารข้อมูลภายนอก หรือถูกเรียกใช้ให้ทำอะไร

หน้าที่ของ Kubelet:

• คอยดูการเปลี่ยนแปลงของ Pod
• กำหนดค่า Container Runtime เพื่อ:
  • Pull Image
  • สร้าง Namespace
  • Run Container

Kubelet ใช้ PodSpec file เพื่อกำหนดว่าจะ Pull Image ไหนและ Run Containers ไหน

• คำสั่ง kubectl ที่ใช้ในการแก้ไข Resource บน Server คือ:
  

  kubectl edit <resource_type> <resource_name>

  ตัวอย่าง:
  หากต้องการแก้ไข deployment ชื่อ my-app
  

  kubectl edit deployment my-app

  คำสั่งนี้จะเปิด File YAML ของ Resource นั้น และเมื่อบันทึกการเปลี่ยนแปลง ระบบจะ Update Resource บน Server โดยอัตโนมัติ
  
  
• PV คือพื้นที่จัดเก็บข้อมูลภายใน Cluster ที่ถูกจัดเตรียมโดยผู้ดูแลระบบ หรือถูกสร้างขึ้นแบบ Dynamic โดยใช้ Storage Classes ซึ่ง PV เป็น Resource ใน Cluster เช่นเดียวกับ Node
  PVs เป็น Plugin ของ Volume คล้ายกับ Volume ทั่วไป แต่เป็นอิสระจาก Pod ที่ใช้งาน PV นั้นๆ Object API นี้เก็บรายละเอียดเกี่ยวกับการใช้งานพื้นที่จัดเก็บ ไม่ว่าจะเป็น NFS, iSCSI หรือระบบจัดเก็บข้อมูลเฉพาะของผู้ให้บริการ Cloud
  
  
• DaemonSet เป็นตัวกำหนดให้ Node ทั้งหมด (หรือบาง Node) ใน Cluster Run สำเนาของ Pod หนึ่งๆ เมื่อมีการเพิ่ม Node เข้ามาใน Cluster, Pod จะถูกเพิ่มให้กับ Node เหล่านั้นโดยอัตโนมัติ และเมื่อมีการลบ Node ออกจาก Cluster, Pod ที่เกี่ยวข้องจะถูกลบ การลบ DaemonSet จะเป็นการลบ Pod ทั้งหมดที่สร้างขึ้นโดย DaemonSet ด้วย
  การใช้งานทั่วไปของ DaemonSet Run Daemon สำหรับการ:
  • จัดเก็บข้อมูลของ Cluster บนทุก Node
  • เก็บรวบรวม Log บนทุก Node
  • Monitor Node ทุก Node
  ในกรณีปกติ DaemonSet หนึ่งตัวอาจครอบคลุมทุก Node เพื่อใช้สำหรับ Daemon ประเภทเดียว แต่ในกรณีที่ซับซ้อนมากขึ้น อาจต้องใช้ DaemonSet หลายตัวสำหรับ Daemon ประเภทเดียว โดยแต่ละตัวอาจกำหนดค่า Flags หรือ Resource (Memory และ CPU) ที่แตกต่างกันเพื่อรองรับ Hardware ที่ต่างกัน
  
  
• StatefulSets มีประโยชน์สำหรับ App ที่ต้องการ:
  • ตัวระบุเครือข่ายที่มีความเสถียรและไม่ซ้ำกัน
  • การจัดเก็บข้อมูลถาวร
  • การ Deploy และขยายระบบอย่างเป็นลำดับ
  • การ Update แบบ Rolling Update อย่างเป็นลำดับและอัตโนมัติ
    .
• OPA เป็น Policy Engine ที่มีวัตถุประสงค์โดยทั่วไปและเป็น Open Source ซึ่งช่วยให้สามารถกำหนดและบังคับใช้นโยบายได้ในหลากหลายสภาพแวดล้อม เช่น Kubernetes, API gateways, CI/CD pipelines, และอื่น ๆ
  
  
• คำสั่งสำหรับดู File kubeconfig ใน Kubernetes:
  

  kubectl config view

  
  
• kOps - kubernetes Operations เป็นวิธีที่ง่ายที่สุดในการสร้างและ Run Cluster Kubernetes ระดับ Production-grade ได้อย่างรวดเร็ว สามารถมอง kOps ว่าเป็นเครื่องมือคล้าย kubectl สำหรับการจัดการ Cluster
  kOps ไม่เพียงแค่ช่วยสร้าง ทำลาย Upgrade และดูแล Cluster Kubernetes ระดับ Production-grade ที่มีความพร้อมใช้งานสูง แต่ยังช่วยจัดเตรียมโครงสร้างพื้นฐานบน Cloud ที่จำเป็นด้วย
  รองรับ:
  AWS อย่างเป็นทางการ
  DigitalOcean, GCE (Google Compute Engine) และ OpenStack ในสถานะ Beta
  Azure และ AliCloud ในสถานะ Alpha
  
  
• Operator จัดเก็บข้อมูลสำหรับ Kubernetes:
  Rook เปลี่ยนระบบจัดเก็บข้อมูลแบบ Distribute ให้กลายเป็นบริการจัดเก็บข้อมูลที่สามารถจัดการตนเอง ขยายขนาดได้เอง และซ่อมแซมตัวเองได้โดยอัตโนมัติ มันช่วยให้งานของผู้ดูแลระบบจัดเก็บข้อมูลเป็นไปโดยอัตโนมัติ ไม่ว่าจะเป็นการ Deploy, การเริ่มต้นระบบ, การกำหนดค่า, การ Provision, การขยายขนาด, การ Upgrade, การ Migrate, การกู้คืนจากภัยพิบัติ, การ Monitor และการจัดการทรัพยากร
  Rook ใช้ประโยชน์จาก Platform Kubernetes เพื่อให้บริการของตนผ่าน Kubernetes Operator สำหรับผู้ให้บริการจัดเก็บข้อมูลแต่ละราย
  
  
• 4C คือ Best Practices สำคัญของการวางระบบ Security Automation ให้ระบบ Software ในองค์กรมีความปลอดภัยมากยิ่งขึ้น ตามกระบวนการแนวคิด Cloud Native มี:
  Cloud Security - การวาง Secured Cloud Infrastructure, CWPP, CSPM และ CIEM
  Cluster Security - Technique Protect Kubernetes ทั้งบน Cloud และ On-premise ให้ปลอดภัย
  Container Security - การ Product ตัว Container ด้วย Docker หรือ Kubernetes
  Code Security - การ Scan Source Code รวมถึง Third-Party Software ต่าง ๆ

https://ajitfawade.medium.com/kubernetes-architecture-explained-1389ac9d18d0

Kubernetes (K8s) เป็น Platform Open-source แบบ Cloud-native ที่ช่วยให้สามารถ Deploy, ขยายขนาด, และจัดการ App ในหลาย Node และ Cluster ได้

K8s มาจากภาษากรีก ซึ่งมีความหมายว่า “ผู้นำทาง” หรือ “นักบิน” นอกจากนี้ ยังเป็นรากศัพท์ของคำว่า “Cybernetic” ซึ่งหมายถึง “ศาสตร์แห่งการควบคุมและการสื่อสารในสัตว์และเครื่องจักร” ดังนั้น K8s จึงเป็นชื่อที่เหมาะสมสำหรับเครื่องมือที่ช่วยให้ควบคุมและสื่อสารกับ Container และ Machine

Kubernetes มีประโยชน์มากมายกับ Dev และผู้ปฏิบัติงานที่ต้องการ Run App ใน Container โดยมีข้อดีดังนี้:

• ความพร้อมใช้งานสูง: K8s ช่วยให้ App ทำงานได้อย่างต่อเนื่อง โดยทำการ Restart Container ที่ Fail โดยอัตโนมัติ ย้ายไปยัง Node อื่น หรือขยายขนาดเพื่อรองรับความต้องการ
  
  
• การกระจาย Load: K8s กระจาย Traffic ไปยัง Container โดยเปิดเผยเป็น Service พร้อมที่อยู่ IP และชื่อ DNS ของตัวเอง นอกจากนี้ยังรองรับ Service Discovery และกลไกการกำหนดเส้นทาง เพื่อให้บริการสามารถเชื่อมต่อกันได้อย่างราบรื่น
  
  
• ความสามารถในการ Scale: K8s ช่วยให้สามารถเพิ่มหรือลดขนาด App ได้ง่ายเพียงแค่เปลี่ยนจำนวน Replica หรือใช้ Horizontal Pod Auto-scaling นอกจากนี้ ยังสามารถขยายหรือลดขนาด Cluster ได้โดยการเพิ่มหรือลบ Node ตามความต้องการ
  
  
• ความสามารถในการพกพา: K8s ช่วยให้สามารถ Run App บน Platform ใดก็ได้ที่รองรับ K8s เช่น Public, Private, Hybrid Cloud หรือ Server แบบ Bare Metal นอกจากนี้ ยังสามารถย้าย App ระหว่าง Environment ต่างๆ ได้โดยไม่ต้องแก้ Code หรือ Configuration
  
  
• ระบบอัตโนมัติ: K8s ช่วยให้ทำงานหลายอย่างโดยอัตโนมัติ ลดความซับซ้อนและข้อผิดพลาดที่อาจเกิดขึ้น เช่น การ Deploy, การ Rollback, การจัดการ Configuration, การจัดการ Secret, Service Discovery, การจัดสรร Resource และการ Monitor Health ของระบบ

 

[PlAwAnSaI]

• ความสามารถในการขยาย: K8s ถูกออกแบบให้เป็นระบบ Modular และ Plug-gable ทำให้สามารถ Custom ให้เหมาะกับความต้องการได้ สามารถใช้เครื่องมือและ Plugin ต่างๆ ที่ทำงานร่วมกับ K8s ได้ เช่น Helm, Istio, Prometheus เป็นต้น นอกจากนี้ ยังสามารถขยาย K8s ได้โดยเพิ่ม Resources & Controller แบบกำหนดได้เอง

---

• Command สำหรับดู Log ของ Container ruby ที่ถูก Terminate ไปแล้ว จาก Pod web-1:
  

  kubectl logs -p -c ruby web-1

  
  
• Container Runtime Interface (CRI) คือ เป็น API ที่ใช้ gRPC ซึ่งช่วยให้ Kubernetes สามารถทำงานร่วมกับ Container Runtime ต่างๆ ได้อย่างเป็นมาตรฐาน และกำหนดวิธีที่ Kubelet ควรสื่อสารกับ Container Runtime เพื่อจัดการ Lifecycle ของ Pod และ Container
  
  
• Workload คือ App ที่ Run บน Kubernetes ไม่ว่าจะเป็นส่วนประกอบเดียวหรือหลายส่วนที่ทำงานร่วมกัน บน Kubernetes คุณจะ Run มันภายในชุดของ Pod, ใน Kubernetes Pod เป็นตัวแทนของชุด Container ที่กำลังทำงานอยู่ใน Cluster ของคุณ
  Pods ของ Kubernetes มี Lifecycle ที่กำหนดไว้ ตัวอย่างเช่น เมื่อ Pod กำลัง Run ใน Cluster ของคุณ แล้วเกิด ข้อผิดพลาดร้ายแรงบน Node ที่ Pod นั้นทำงานอยู่ Pod ทั้งหมดบน Node นั้นจะล้มเหลว Kubernetes ถือว่าระดับความล้มเหลวนั้นเป็น Final ซึ่งหมายความว่า คุณต้องสร้าง Pod ใหม่เพื่อให้ระบบกลับมาทำงานได้ แม้ว่า Node นั้นจะกลับมาอยู่ในสถานะปกติในภายหลังก็ตาม
  
  
• etcd เป็น Distributed Key-Value Store ที่ทำหน้าที่เป็น ที่เก็บข้อมูลหลักสำหรับ Kubernetes API Server
  
  
  
  
  
  
• StatefulSet ใน Kubernetes ต้องใช้ Headless Service เพื่อจัดการ Network Identity ของ Pods
  
  
• Resource requests และ limits ถูกกำหนดภายในส่วนของ Container Definition (อยู่ภายใต้ Field resources) โดย
  'requests' คือการระบุ Resource ขั้นต่ำที่ Container ต้องการเพื่อการทำงาน ในขณะที่
  'limits' คือการกำหนด Resource สูงสุดที่ Container สามารถใช้ได้ ส่วน Field
  'affinity' และ 'tolerations' ใช้สำหรับควบคุมการกำหนดค่า Pod ว่าจะถูกจัดสรรไปยัง Node ใด และ Condition Tolerate เฉพาะของ Node
  
  
• Feature Telemetry ของ Istio โดยเฉพาะ Tracing ช่วยให้คุณสามารถติดตาม Flow ของ Request ผ่าน Microservices ของคุณได้ ด้วยการตรวจสอบข้อมูลการติดตาม คุณสามารถระบุคอขวด (Bottleneck) ปัญหาความล่าช้า (Latency) และปัญหาประสิทธิภาพอื่นๆ ที่เกี่ยวข้องกับการเรียกผ่านเครือข่ายได้
  Fault Injection จำลองความล้มเหลวสำหรับการทดสอบ
  Service Entry ใช้สำหรับ Service Discovery
  Virtual Service และ Destination Rule ใช้สำหรับการจัดการการรับส่งข้อมูล (Traffic Management)
  
  
• Pod Disruption Budgets (PDB) เป็น Feature ของ Kubernetes ที่ช่วยรักษาความพร้อมใช้งานของ App ของคุณโดยการจำกัดจำนวน Pod ที่สามารถลบได้ในช่วงเวลาหนึ่งๆ มันช่วยให้มั่นใจว่ามี Pod ที่สมบูรณ์อย่างน้อยตามจำนวนขั้นต่ำที่กำหนดยังคงทำงานอยู่ แม้ในระหว่างการ Update หรือการบำรุงรักษา
  

  https://medium.com/grean-developers-family/รักษาเธอไว้ด้วย-pod-disruption-budget-3faa4e504db2

  
  
• 'rollbackConfig' ใน Flux ช่วยให้คุณกำหนดกลยุทธ์การ Rollback สำหรับการ Deploy ได้ การตั้งค่า 'failed: true' ช่วยให้มั่นใจว่าหากการ Deploy ล้มเหลว ระบบจะย้อนกลับไปยัง Version ที่ทำงานได้ก่อนหน้าโดยอัตโนมัติ ซึ่งช่วยลดเวลาที่ระบบไม่สามารถใช้งานได้ (Downtime) และรับประกันความเสถียร
  
  
• 'nodeAffinity' กำหนด 'requiredDuringSchedulingIgnoredDuringExecution' เพื่อบังคับการ Schedule บน Specific Node
  'Taints และ Tolerations': ใช้ taint กับ Specific Node ที่สะท้อนถึงความพร้อมใช้งานของ Volume จากนั้นกำหนดค่า Pod ให้ทนต่อ taint เฉพาะนั้น ซึ่งรับประกันว่า Pod จะถูก Schedule ได้เฉพาะบน Node ที่มี taint ที่ตรงกันเท่านั้น ในขณะที่
  'podAffinity' และ 'podAntiAffinity' มีประโยชน์สำหรับการจัดกลุ่มหรือกระจาย Pod
  
  
• ส่วน VolumeMounts ภายใน Pod Definition ช่วยให้คุณสามารถ Map Directory ของ Host หรือ Persistent Volume เข้าไปใน Container ของคุณได้ เป็นวิธีที่ปลอดภัยและควบคุมได้ในการเข้าถึง File จากเครื่อง Host ภายใน Container ของคุณ
  
  
• Runtime Environment ของ Kubernetes ประกอบด้วยหลายองค์ประกอบที่ทำงานร่วมกันเพื่อจัดการ Container องค์ประกอบเหล่านี้ได้แก่:
  • Kubelet: เป็น Agent ที่ทำงานบนแต่ละ Node และมีหน้าที่รับผิดชอบในการจัดการ Pod และทำให้มั่นใจว่า Container ภายใน Pod กำลังทำงานตามที่ระบุไว้ใน File YAML
  • Containerd: เป็น Runtime ของ Container ที่ Provide Low-level Interface สำหรับการทำงานของ Container
    
    
    
    
  • CRI-O: คล้ายกับ containerd เป็นอีกหนึ่ง Runtime Container ที่นิยมใช้ซึ่งรองรับ Container Runtime Interface (CRI) สำหรับ Kubernetes เช่นกัน
  • Docker: เป็น Runtime Container ที่นิยมใช้กับ Kubernetes อย่างไรก็ตามมักถูกแทนที่ด้วย containerd หรือ CRI-O เพื่อการทำงานร่วมกับ Kubernetes ที่ดีขึ้น
    .
• ConfigMaps และ Secrets เป็น Resource ของ Kubernetes ที่ช่วยให้คุณสามารถส่งข้อมูล Configuration ไปยัง Container ได้
  ConfigMaps เก็บ Key-value Pair อย่างง่าย เหมาะสำหรับ Environment Variable ในขณะที่
  Secrets ใช้เพื่อเก็บข้อมูลที่ Sensitive เช่น รหัสผ่านหรือ API Key
  
  
• Component kube-apiserver ทำหน้าที่เป็น Central Control Plane สำหรับ Kubernetes มันจัดการการสื่อสารและคำขอทั้งหมดจาก Component อื่นๆ รวมถึงการ Authentication และการอนุญาต (Authorization) และบังคับใช้นโยบายความปลอดภัย (Security Policy) โดยการตรวจสอบ Credential และให้สิทธิ์การเข้าถึงตาม Rule ที่ได้ Configure ไว้

---

• CoreDNS ให้บริการที่เชื่อถือได้และสามารถขยายได้สำหรับ Service Discovery และ Name Resolution โดยใช้ DNS ภายใน Cluster Kubernetes ซึ่งเป็นสิ่งจำเป็นสำหรับการสื่อสารระหว่าง Pod และ Service ใน Container Environment ที่ซับซ้อนและมีการเปลี่ยนแปลงอยู่ตลอด
  
  
• Karpenter จะเริ่มทำงานเมื่อมี Pod Pending รอการจัดสรร Resource โดยมันจะคำนวณ List ของ ประเภท Instance ที่ตรงกับข้อกำหนดที่ระบุไว้ใน Pod Manifest จากนั้นจะทำการเรียก EC2 Fleet API ซึ่งจะเลือก Instance ที่เหมาะสมตาม กลยุทธ์การจัดสรรทรัพยากร และดำเนินการเปิดตัว Instance นั้นเพื่อรองรับ Workload โดยอัตโนมัติ
  

  https://blog.wisesight.com/ใช้งาน-aws-eks-ให้ถูกลงด้วย-karpenter-d3be28a5467e

  
  
• Scheduler คือส่วนประกอบของ Control Plane ที่คอยเฝ้าดู Pod ที่ถูกสร้างขึ้นใหม่แต่ยังไม่มีการกำหนด Node มันจะเลือก Node สำหรับให้ Pod เหล่านั้นทำงาน โดยตัดสินใจตามปัจจัยหลายอย่าง เช่น ความต้องการทรัพยากร (CPU, Memory, Storage ฯลฯ), ข้อจำกัดด้าน Hardware/Software/นโยบาย (เช่น ต้องใช้ GPU หรือระบบปฏิบัติการเฉพาะ), Affinity และ Anti-affinity, Inter-workload Interference, etc.
  
  
• Container Insights เป็นเครื่องมือที่ช่วย รวบรวม, สรุป, และวิเคราะห์ ข้อมูล Metric และ Log จาก App ที่ Run อยู่บน Container และ Microservice ใน Amazon EKS และ ECS
  
  
• Amazon CloudWatch เป็นบริการที่ช่วยให้คุณสามารถ รวบรวม, Monitor, และวิเคราะห์ Log, Metric, และ Event จาก AWS Resource และ App
  CloudWatch ใน Amazon EKS ใช้สำหรับ รวบรวมและจัดเก็บ Logs จาก Control Plane ของ Amazon EKS เพื่อให้สามารถวิเคราะห์และตรวจสอบสถานะของ Cluster ได้จากศูนย์กลาง สามารถรวบรวม:
  • API Server Log → ตรวจสอบคำขอที่ส่งไปยัง Kubernetes API Server
  • Audit Log → บันทึกกิจกรรมทั้งหมดที่เกิดขึ้นภายใน Cluster
  • Authenticator Log → ตรวจสอบการยืนยันตัวตนและการเข้าถึงของผู้ใช้
  • Controller Manager Log → จัดการกระบวนการควบคุม เช่น การสร้าง Pod, Node และ ReplicaSets
  • Scheduler Logs → บันทึกการตัดสินใจเกี่ยวกับการกำหนด Pod ไปยัง Node
    .
• Best Practice ในสถาปัตยกรรม Microservices คือการ Deploy แต่ละ Microservice ต่อหนึ่ง Pod

---

https://learn.microsoft.com/th-th/training/paths/implement-security-through-pipeline-using-devops

• การตั้งค่าสิทธิ์แยกต่างหากสำหรับแต่ละโครงการจะช่วยให้สามารถควบคุมบุคคลที่สามารถเข้าถึงทรัพยากรของโครงการได้ และไม่ปล่อยให้มีการละเมิดในโครงการหนึ่งส่งผลกระทบต่อโครงการอื่นๆ
  
  
• การเพิ่ม File ที่ปลอดภัยของโครงการไปยังโครงการของ Team ต่างๆ ช่วยให้การจัดการการเข้าถึงง่ายขึ้นและรองรับการรักษาความลับ

 

[PlAwAnSaI]

• Istio:
  • ให้วิธีการที่สอดคล้องในการจัดการการ Call เครือข่ายและความปลอดภัยในทุก Microservices
  • ช่วยให้บรรลุความสามารถในการปรับขนาดและความทนทานต่อความล้มเหลวที่ดีขึ้นสำหรับ Microservices
  • Control Plane ของ Istio ทำให้การ Deploy และการจัดการ Microservices ง่ายขึ้น
  • ช่วยให้การ Debug และการแก้ไขปัญหา (Troubleshooting) ของการทำงานร่วมกันระหว่าง Microservices ที่ซับซ้อนทำได้ง่ายขึ้น
  • แต่มันไม่ได้ทำให้กระบวนการย้าย Code แบบ Monolithic ที่มีอยู่เดิมง่ายขึ้นโดยอัตโนมัติ การย้ายต้องการการปรับโครงสร้างและการเปลี่ยนแปลงสถาปัตยกรรมอย่างรอบคอบ ซึ่ง Istio เป็นส่วนเสริม ไม่ใช่สิ่งทดแทน
    .
• NetworkPolicy ถูกออกแบบมาสำหรับควบคุมการรับส่งข้อมูลเครือข่ายภายใน Cluster Kubernetes มันช่วยให้คุณกำหนดกฎที่ควบคุมการรับส่งข้อมูลขาเข้าและขาออกสำหรับ Pod โดยอิงตาม Label, Namespace และเกณฑ์อื่นๆ มันช่วยให้คุณสามารถบังคับใช้การจำกัดการเข้าถึงระหว่าง Pod และ Service ภายในเครือข่ายของ App ของคุณ
  PodSecurityPolicy มีหน้าที่หลักในการจำกัดการตั้งค่าความปลอดภัยสำหรับ Pod
  ServiceAccount ให้ตัวตนและข้อมูลรับรอง และ
  ResourceQuota และ LimitRange จัดการการใช้ทรัพยากร
  
  
• Kubernetes สร้างความพร้อมใช้งานสูง (High Availability: HA) สำหรับ Deployment ด้วยการผสมผสาน Technique ต่างๆ องค์ประกอบเหล่านี้ทำงานร่วมกันเพื่อให้มั่นใจว่า App ยังคงพร้อมใช้งานแม้ในกรณีที่ Node ล้มเหลว:
  • Replicas: Field 'replicas' ทำให้มั่นใจว่ามีหลาย Instance ของ App ทำงานอยู่บน Node ที่แตกต่างกัน หาก Node หนึ่งล้มเหลว, Pod ที่ทำงานบน Node นั้นจะถูก Restart โดยอัตโนมัติบน Node อื่นที่ยังทำงานได้ดี
  • etcd: ฐานข้อมูลแบบ Distributed เก็บสถานะของ Cluster ซึ่งหมายความว่าแม้ Node หนึ่งจะล้มเหลว Node อื่นๆ ยังคงสามารถเข้าถึงข้อมูลสถานะล่าสุดและดำเนินการต่อไปได้
  • Self-healing: Kubernetes ตรวจสอบสถานะของ Pod อย่างต่อเนื่องและ Restart Pod ที่ล้มเหลวบน Healthy Node ทำให้มั่นใจว่าจำนวน Replica ที่ต้องการจะคงอยู่เสมอ แม้ว่า Pod บางส่วนจะเกิดความล้มเหลว
    .
• Admission Controller ใน Kubernetes สามารถใช้เพื่อบังคับใช้ Policy สำหรับ Image Container คุณสามารถกำหนดค่า Admission Controller เพื่อตรวจสอบว่า Image อยู่ใน Image Registry ที่ได้รับอนุมัติหรือไม่ หรือมันเป็นไปตามเกณฑ์ความปลอดภัยที่กำหนดไว้หรือไม่ สิ่งนี้ช่วยป้องกันไม่ให้ Image ที่ไม่ได้รับอนุญาตหรือไม่ปลอดภัยถูกนำไปใช้งานใน Cluster ของคุณ
  
  
• วิธีที่ปลอดภัยและได้รับการแนะนำเพื่อเชื่อมต่อกับ Cloud SQL จาก Cloud Functions มากที่สุดคือการใช้บัญชีผู้ให้บริการ (Service Account) ที่มีสิทธิ์ที่เหมาะสม วิธีนี้ควบคุมการเข้าถึงแบบละเอียดและทำให้มั่นใจว่า Cloud Functions มีเพียงสิทธิ์ที่จำเป็นในการโต้ตอบกับฐานข้อมูลเท่านั้น
  
  
• ArgoCD สามารถกำหนดค่าให้ใช้ Webhooks ซึ่งเป็น HTTP Callback ที่ถูกกระตุ้นโดยเหตุการณ์ต่างๆ เช่น การ Push Image ไปยัง Container Registry มันช่วยให้ ArgoCD สามารถ Update Cluster โดยอัตโนมัติทุกครั้งที่มีการ Push Image Tag ใหม่ ทำให้มั่นใจว่าการ Deploy ของคุณใช้ Image Version ล่าสุดอยู่เสมอ
  
  
• การปรับค่าใช้จ่ายให้เหมาะสมสำหรับ Microservices เกี่ยวข้องกับการทำความเข้าใจการใช้ Resource และการทำให้การ Scale มีประสิทธิภาพ:
  • Distributed Tracing ช่วยระบุ Microservices ที่ใช้ Resource สูงเพื่อการปรับปรุง
  • HPA (Horizontal Pod Autoscaler) ช่วยให้ Microservices แต่ละตัวสามารถ Scale ได้อย่างอิสระ ทำให้มั่นใจว่ามีการใช้ Resource อย่างเหมาะสม
  • การออกแบบ Microservices ให้เป็นแบบ Stateless และ Idempotent ทำให้การ Scale และการ Restart ง่ายขึ้น ลดการสูญเสีย Resource ที่อาจเกิดขึ้น
    .
• การเปลี่ยนแปลงใน Git Repository จะถูก Update ใน Kubernetes Cluster ด้วย:
  • ArgoCD ต้องทำงานอยู่และได้รับการกำหนดค่าอย่างถูกต้องเพื่อตรวจสอบการเปลี่ยนแปลงใน Repository
  • ArgoCD ต้องสามารถเข้าถึง Repository เพื่อดึงการกำหนดค่า
  • การกำหนดค่าที่ไม่ถูกต้องหรือไม่สมบูรณ์ใน Repository จะทำให้ ArgoCD ไม่สามารถ Apply การเปลี่ยนแปลงที่ต้องการได้
  • ArgoCD ต้องสามารถสื่อสารกับ Kubernetes Cluster เพื่อใช้การกำหนดค่า
  • App เฉพาะใน ArgoCD ต้องได้รับการกำหนดค่าให้ตรวจสอบ Repository และ Namespace ที่ถูกต้อง
    .
• การจัดการความสอดคล้องและความน่าเชื่อถือของข้อมูลในระบบแบบ Distribute ที่มี Microservices เป็นความท้าทายที่ซับซ้อน มีแนวทางต่างๆ เพื่อให้บรรลุเป้าหมายนี้ ได้แก่:
  • การใช้ระบบฐานข้อมูลแบบ Distribute เช่น Cassandra หรือ MongoDB ช่วยให้สามารถทำการ Replicate ข้อมูล และทนต่อความล้มเหลวใน Node ต่างๆ ช่วยให้มั่นใจถึงความพร้อมใช้งานและความสอดคล้องของข้อมูล
  • Message Broker สามารถอำนวยความสะดวกในการ Synchronize ข้อมูลระหว่าง Microservices - Message ถูกใช้เพื่อแจ้งการเปลี่ยนแปลงข้อมูลและทำให้มั่นใจว่าทุกบริการรับรู้ถึงสถานะล่าสุด
  • Distributed Transaction Manager ช่วยให้มั่นใจว่า Transaction หลายรายการใน Microservices ต่างๆ จะเสร็จสมบูรณ์ซึ่งเป็นการดำเนินการครั้งเดียวต้องสำเร็จทั้งหมดหรือล้มเหลวทั้งหมด ไม่มีสถานะกึ่งกลาง (Single Atomic Operation) ช่วยรักษาความสอดคล้องและความสมบูรณ์ของข้อมูล
  • Event Sourcing เกี่ยวข้องกับการเก็บลำดับของเหตุการณ์ที่แสดงถึงการเปลี่ยนแปลงในระบบ CQRS (Command Query Responsibility Segregation) แยกคำสั่ง (ที่แก้ไขข้อมูล) ออกจากการสืบค้น (ที่ดึงข้อมูล) แนวทางนี้สามารถช่วยจัดการความสอดคล้องของข้อมูลและให้ Architecture ที่แข็งแรงยิ่งขึ้น
  แนวทางที่ดีที่สุดขึ้นอยู่กับความต้องการเฉพาะของ App ของคุณ เช่น ระดับความสอดคล้องของข้อมูล ความต้องการด้านประสิทธิภาพ และความต้องการในการขยายตัว
  
  
• การใช้ Container Security Scanner เพื่อระบุและแก้ไขช่องโหว่เป็นมาตรการที่มีประสิทธิภาพมากที่สุดในการลดความเสี่ยงจากช่องโหว่ที่รู้จักใน Container Image ของคุณ โดยจะวิเคราะห์ Image ของคุณเพื่อหาปัญหาความปลอดภัยที่เป็นที่รู้จักและให้คำแนะนำในการ Patch หรือ Upgrade ช่วยให้คุณแก้ไขช่องโหว่ที่อาจเกิดขึ้นเชิงรุกและปรับปรุงความปลอดภัยโดยรวมของ App Kubernetes ของคุณ
  
  
• Deployment เป็น Resource ของ Kubernetes ที่ออกแบบมาเพื่อจัดการ Lifecycle ของ Pod พวกมันมี Feature เช่น Rolling Update, การ Restart อัตโนมัติ และการซ่อมแซมตัวเอง (Self-healing) เมื่อ Pod ล้มเหลว, Deployment Controller จะตรวจจับความล้มเหลวและสร้าง Pod ใหม่โดยอัตโนมัติมาแทนที่, ทำให้มั่นใจในความพร้อมใช้งานสูง
  
  
• Service Meshes อย่างเช่น Istio ถูกออกแบบมาเพื่อลดความซับซ้อนในการจัดการ Microservices ใน Kubernetes โดยให้ Layer ของการทำให้เป็นนามธรรม (Abstraction) เหนือ API ของ Kubernetes ในขณะที่พวกมันมอบความปลอดภัยที่เพิ่มขึ้น ความสามารถในการสังเกตการณ์ และการจัดการ Traffic ข้อมูล พวกมันไม่ได้ให้การเข้าถึง API ของ Kubernetes โดยตรง ช่วยให้นักพัฒนาสามารถมุ่งเน้นไปที่ตรรกะของ App มากกว่าการจัดการโครงสร้างพื้นฐาน
  

  https://www.somkiat.cc/basic-of-istio

  
  
• หาก Pod ร้องขอทรัพยากร CPU มากกว่าขีดจำกัดที่กำหนดไว้ Container จะถูกจำกัด (Throttled) ซึ่งจะส่งผลต่อประสิทธิภาพการทำงานของมันโดยตรง ขีดจำกัด CPU ทำหน้าที่เป็นเพดานสูงสุด (Hard Ceiling) ที่ป้องกันไม่ให้ Container ใช้ทรัพยากรเกินกว่าที่กำหนดไว้ แม้ว่า Container จะร้องขอ CPU เพิ่มเติม แต่ก็จะถูกจำกัดอยู่ที่ค่าขีดจำกัด ส่งผลให้ประสิทธิภาพลดลง อย่างไรก็ตาม Container จะไม่ถูกปิด, Restart หรือถูกลดขนาดลงโดยอัตโนมัติ มันจะยังคงทำงานต่อไป แต่ประสิทธิภาพจะได้รับผลกระทบเนื่องจากข้อจำกัดด้านทรัพยากร
  
  
• ReplicaSet มีหน้าที่รับผิดชอบในการทำให้มั่นใจว่ามีจำนวน Pod ที่ต้องการกำลังทำงานสำหรับการ Deploy มันคอยตรวจสอบ Pod และทดแทน Pods ที่ล้มเหลวโดยอัตโนมัติ
  
  
• Cluster Resource รับผิดชอบในการกำหนดโครงสร้างของ Cluster Kubernetes รวมถึงจำนวนและประเภทของ Node มันเป็น Resource ระดับสูงสุดใน Kubernetes
  
  
• วิธีแก้ปัญหาที่มีประสิทธิภาพสำหรับการระบุ Container ที่ใช้หน่วยความจำมาก
  • 'kube_pod_container_status_memory_usage_bytes' ช่วยให้คุณสามารถวิเคราะห์ Metric โดยตรง ซึ่งแสดงการใช้หน่วยความจำจริงของแต่ละ Container ภายใน Pod
  • กรอง Query Prometheus ตามชื่อ Container และเรียงลำดับตามการใช้หน่วยความจำ ช่วยให้คุณสามารถระบุ Container ที่มีการใช้หน่วยความจำสูงสุดได้อย่างง่ายดาย
    .
• สิ่งสำคัญสำหรับ Pipeline CI/CD ที่แข็งแรง:
  • การสร้าง Container Image เป็นการห่อหุ้ม App ของคุณ
  • การ Push ไปยัง Registry ช่วยให้มั่นใจว่าสามารถเข้าถึงได้ง่าย
  • การใช้การกำหนดค่า Kubernetes เป็นการกำหนดการ Deploy และ
  • การทดสอบอัตโนมัติช่วยตรวจสอบ Function การทำงานของ App ก่อนการ Deploy

 

[PlAwAnSaI]

• Azure Event Hubs คือแนวทางที่แนะนำสำหรับการเชื่อมต่อ Kafka กับ Azure Functions สำหรับการรับข้อมูล Streaming แบบ Real-time มันมอบความสามารถในการทำงานที่มี Throughput สูงและความสามารถในการปรับขนาด ทำให้เหมาะสมอย่างยิ่งสำหรับการจัดการข้อมูล Streaming ปริมาณมาก
  Service Bus เหมาะสำหรับการจัด Queue ข้อความ ไม่ได้ออกแบบมาสำหรับข้อมูล Streaming เป็นหลัก
  การ Polling Topic Kafka โดยตรง อาจไม่มีประสิทธิภาพและอาจปรับขนาดไม่ดี
  Custom Connector อาจมีความซับซ้อนและอาจขาด Function การทำงานที่จำเป็นสำหรับการรับข้อมูล Streaming
  Data Factory มุ่งเน้นไปที่การเคลื่อนย้ายข้อมูลและการแปลงข้อมูลมากกว่า ไม่ใช่การ Streaming แบบ Real-time
  
  
• การใช้ Istio's Mixer ช่วยให้คุณสามารถ Integrate Jaeger กับ Istio และ Prometheus ได้ การ Integrate นี้ช่วยให้คุณสามารถเสริมข้อมูลการ Trace (Tracing Data) ด้วย Metric ที่เกี่ยวข้องและ Log ที่ Capture ได้จากความสามารถในการจัดการการจราจรของ Istio วิธีนี้ให้ Platform ที่เป็นหนึ่งเดียวสำหรับการเชื่อมโยงความสัมพันธ์ระหว่าง Log, Metric และ Trace
  ใช้ Custom Logging Agent มุ่งเน้นเฉพาะ Log ไม่มีวิธีการเชื่อมโยง Log กับ Metric หรือ Trace
  แม้ว่า Istio สามารถ Capture Log ได้ แต่การส่ง Log ไปยัง Prometheus ไม่ใช่วิธีแก้ปัญหาที่เหมาะสมสำหรับการสร้างความสัมพันธ์
  ระบบ Log แบบรวมศูนย์อย่าง FluentD สามารถรวบรวม Log ได้ แต่ไม่ได้มีกลไกในตัวที่จะเชื่อมโยง Log กับ Metric หรือ Trace
  การสร้างความสัมพันธ์ระหว่าง Log, Metric และ Trace ด้วยตนเองโดยใช้ 'kubectl logs' เป็นงานที่น่าเบื่อและมีแนวโน้มที่จะเกิดข้อผิดพลาด โดยเฉพาะใน Environment แบบ Dynamic เช่น Kubernetes
  
  
• จำเป็นต้องมี Custom Kubernetes Controller เพื่อเชื่อม Gap ระหว่าง HPA และ Prometheus โดยมันจะดึง Metric จาก Prometheus และส่งให้กับ HPA คุณสามารถใช้ Flag '-metrics' ใน File YAML ของ HPA เพื่อระบุ Metric แบบกำหนดเองและที่มาของพวกมัน (รวมถึง Endpoint ของ Prometheus)
  
  
• ConfigMap มักถูกใช้เพื่อให้ Prometheus มีการกำหนดค่าที่จำเป็นสำหรับการดึงข้อมูล (Scraping) จาก Pod มันสามารถมีรายละเอียดต่างๆ เช่น ช่วงเวลาในการดึงข้อมูล, Label ของเป้าหมาย, และ Authentication Credential การกำหนดค่านี้ช่วยให้ Prometheus สามารถตรวจสอบ Pod ที่ Run App ต่างๆ ภายใน Cluster Kubernetes ได้อย่างมีประสิทธิภาพ
  
  
• Container Image คือพิมพ์เขียวสำหรับการสร้าง Container ในขณะที่ Container Runtime คือ Software ที่ทำการ Execute Container
  Container Image มีองค์ประกอบที่จำเป็นทั้งหมด, Library, และ Dependency ต่างๆ เพื่อ Run App ใน Container มันเป็น Snapshot ของจุดเวลาที่เฉพาะเจาะจง
  Container Runtime เช่น Docker, containerd, หรือ CRI-O, รับผิดชอบในการ Load Image, สร้าง Container, และจัดการ Lifecycle ของมัน พวกมันจัดเตรียม Environment และ Resource สำหรับให้ Container ทำงาน
  
  
• แนวคิดเหล่านี้ช่วยให้คุณปรับการจัดสรรทรัพยากรให้เหมาะสม:
  • NodeSelector: อนุญาตให้คุณระบุ Label บน Node และจับคู่ Label เหล่านั้นใน Pod Definition ของคุณ ทำให้มั่นใจว่า Pod จะถูก Schedule บน Node ที่มีคุณลักษณะตามที่ต้องการ
  • PodAntiAffinity: ป้องกันไม่ให้ Pod ถูก Schedule บน Node เดียวกันหรือแม้แต่ใน Zone เดียวกัน ส่งเสริมการกระจายตัวระหว่าง Node
  • Tolerations: อนุญาตให้ Pod ทนต่อ Taint ที่ใช้กับ Node, Taint ถูกใช้เพื่อทำเครื่องหมาย Node ว่าไม่เหมาะสำหรับ Pod บางประเภท เว้นแต่ว่า Pod เหล่านั้นจะมีความอดทน (Toleration) ที่สอดคล้องกัน
  • Taint: ทำเครื่องหมาย Node ด้วยคุณลักษณะเฉพาะ ป้องกันไม่ให้ Pod Schedule บน Node เหล่านั้น เว้นแต่พวกมันจะมีความอดทนต่อ Taint เหล่านั้น
    .
• https://github.com/ThaiCPE/30DaysOfKCNA