DevOps

PlAwAnSaI

PlAwAnSaI

Administrator
www.youtube.com

DevOps Saturday

แชร์วิดีโอของคุณกับเพื่อน ครอบครัว และผู้คนทั่วโลก
www.youtube.com www.youtube.com
ข้อมูลเบื้องต้นเกี่ยวกับ DevOps: ทำความเข้าใจหลักการและ Lifecycle

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

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

Contribute to ThaiCPE/90DaysOfDevOps development by creating an account on GitHub.
github.com github.com
:cool:
 
Last edited:
PlAwAnSaI

PlAwAnSaI

Administrator

CNCF Kubernetes and Cloud-Native Associate (KCNA)

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

คนที่จะเหมาะสำหรับ 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

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

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
www.facebook.com

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 www.facebook.com

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

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

Kubernetes โดยทั่วไปเรียกว่า K8s
  • 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

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
          }
        ]
      }
    ]
  }
}
    onlineyamltools.com

    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 หลายรายการได้
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

PlAwAnSaI

Administrator
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"
:cool:
 
Last edited:
You must log in or register to reply here.
Top