DevOps

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

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

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

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

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

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 มาใช้

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

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

• 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
  
  Code:

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

• JSON
  
  Code:

  {
    "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 หลายรายการได้
kubectl apply โดยทั่วไปใช้ในการ Deploy Manifest File
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

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 เท่านั้น

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


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 ทั้งหมด:

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 ของคุณเองได้ด้วย:

ใน 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:

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

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

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


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


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 ต่างๆ ได้
   
   Code:

   kubectl get pods --show-labels

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

   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 นี้
      
      Code:

      # 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
      
      Code:

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

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

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

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

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

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

สามารถ Deploy Pod ได้โดยใช้คำสั่ง:
ในทางปฏิบัติ จะไม่ 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 คือ:
  
  Code:

  kubectl edit <resource_type> <resource_name>

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

  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:
  
  Code:

  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 ต่าง ๆ

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 ของระบบ

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

---

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

  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 หรือการบำรุงรักษา
  
  Code:

  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 เป็นอีกหนึ่งรันไทม์คอนเทนเนอร์ที่นิยมใช้ซึ่งรองรับ Container Runtime Interface (CRI) สำหรับ Kubernetes เช่นกัน
    Docker: Docker เป็นรันไทม์คอนเทนเนอร์ที่นิยมใช้กับ Kubernetes อย่างไรก็ตาม ไม่ใช่ตัวเลือกเดียวและมักถูกแทนที่ด้วย containerd หรือ CRI-O เพื่อการทำงานร่วมกับ Kubernetes ที่ดีขึ้น

---

• 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 โดยอัตโนมัติ
  
  Code:

  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

---

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

[/LIST]