DevOps

PlAwAnSaI

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

แนวคิดและวัตถุประสงค์ของ DevOps:
  • DevOps คือแนวคิดและการปฏิบัติ
  • ที่มุ่งเน้นการประสานงานระหว่าง Team พัฒนา (Development) และ Team ปฏิบัติการ (Operations)
  • วัตถุประสงค์สำคัญ:
    • ส่งมอบ Feature ได้เร็วขึ้น
    • เพิ่มประสิทธิภาพและการทำงานร่วมกัน
    • ยกระดับคุณภาพและความเสถียรของระบบ
ประโยชน์ของ DevOps ในองค์กร:
  • ลดเวลาออกสู่ตลาด (Time to Market)
  • เพิ่มความถี่ในการ Deploy (Deployment Frequency)
  • เพิ่มความเสถียรและความน่าเชื่อถือ
  • ใช้งานทรัพยากรอย่างคุ้มค่าและขยายระบบได้ง่าย
:cool:
 
Last edited:

PlAwAnSaI

Administrator
Code:
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 ที่สุดในโลก!

0*IHRXUSd-mYRu-0P8.png


นี่คือบันทึกและสื่อที่เรารวบรวมไว้ระหว่างการเตรียมตัวสำหรับการสอบ มันง่ายที่จะเตรียมตัวและทำข้อสอบถ้าคุณเคยรู้จักหรือใช้ 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 ประการ คือ:

0*jHIZ4aEdIy06O5PM

  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:
0*1OilttpJ9c5UDScT.png


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

CNCF_TrailMap_latest.png

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

PlAwAnSaI

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

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

1*C9ohEBYkRt2Lr-G-37beyw.png


สถาปัตยกรรมแบบ 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
:cool:
 
Last edited:

PlAwAnSaI

Administrator
Code:
https://medium.com/sirisoft/kubernetes-zero-2-hero-26523dc068be
Code:
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
    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
              }
            ]
          }
        ]
      }
    }
Manifest สามารถมีส่วนประกอบ K8s Definition/Configure หลายรายการได้
Code:
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
Code:
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
687627_994695.jpeg


Worker Node:
Running App ของคุณใน Pod และ Container ... จะ Run:
  • Kubelet
  • Kube Proxy
  • Container Runtime
  • Pod และ Container
Pod:
เป็นหน่วยที่เล็กที่สุดใน Kubernetes ถ้าเราต้องการจะ Run Container เราต้องเอา Container ของเรายัดเข้าไปใน Pod ก่อนถึงจะ Run ได้

0*kbZ1yu01Z47PWl_A


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

แต่ละ Pod จะมี IP Private ของตัวเอง:
  • แต่ละ Container ใน Pod จะทำงานบน Port ต่างกัน
  • Container สามารถพูดคุยกันผ่าน Localhost
k8s-pod.png

แต่ละ Pod สามารถมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน Attach มา
  • Container ทั้งหมดจะ Share ใช้ Volume เดียวกัน
เมื่อ container สุดท้ายที่เหลืออยู่ใน Pod หยุดทำงาน (หรืออาจจะเกิด Crash):
  • เมื่อมีการสร้าง Pod ใหม่เพื่อทดแทน Pod นั้นจะได้รับการกำหนด IP Address
    • IP address ของ Pod เป็นแบบชั่วคราว (Ephemeral) โดยปกติแล้วจะไม่คงอยู่ถาวร
ถ้าคุณต้องการดู Pods และ IP Address ของ pod
Code:
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

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 เท่านั้น
:cool:
 
Last edited:

PlAwAnSaI

Administrator
https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4876c777-96bb-4563-bc98-60561dbc4442_1493x1600.png


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

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

kubernetes-endpoints.png


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

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

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

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

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

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

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

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


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 ที่ต้องการความเฉพาะเจาะจง
:cool:
 
Last edited:

PlAwAnSaI

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

landing-2.svg


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 ที่ต่างกัน
:cool:
 
Last edited:

PlAwAnSaI

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

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

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