ปี 2023 ที่ผ่านมา

เผลอแป๊ปเดียวก็ได้มาเขียนบันทึกความทรงจำปี 2023 แล้ว ตอนแรกว่าจะไม่เขียนละ แต่เดี๋ยวถ้าไม่เขียนจะลืมเรื่องราวต่างๆในปี 2023 ไป ซึ่งจริงๆตอนนี้ก็ลืมไปหลายเรื่องละ แล้วที่บอกว่าเวลามันเร็วจริงๆแล้วไม่เร็วหรอกครับเราแค่รู้สึกไปเอง

งาน

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

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

ส่วนปีนี้ที่แปลกหน่อยก็ได้ดูแลเด็กฝึกงาน ซึ่งพอได้ดูแลน้องๆแล้วก็รู้สึกว่าเราแก่เอาเสียมากๆแบบตามไม่ทัน Trend ที่น้องๆคุยกัน แถมเรื่องความรู้นี่เหมือนน้องๆรู้เยอะกว่าเราตอนเรียนอีก แบบถ้าเอามาฝึกอีกนิดนี่น่าจะกลายเป็น Programmer เทพๆได้แน่นอน

ความรัก

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

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

แต่ปีนี้ก็มีเรื่องที่ไม่รู้ดีไหมคือปีนี้ขอ IG สาวที่ชอบสำเร็จแล้ว ตอนนั้นจำได้ว่ากว่าจะพูดออกไปได้นี่ยากเหลือเกิน ในหัวมีแต่เขาจะว่าเราไหมนะ จากนี้จะมองหน้ากันได้เหรอ เขาจะมองเรายังไง แต่สุดท้ายเรื่องที่เราอ่านก็ย้อนเข้ามาในหัวว่า “มันมีเรื่องที่เราควบคุมไม่ได้ หน้าที่ของเราคือทำเรื่องที่เราควบคุมได้” ซึ่งเรื่องที่เราควบคุมได้คือ การเอ่ยปากขอ ส่วนเขาจะให้ไม่ให้ไม่ใช่เรื่องที่เราควบคุม ผลจะเป็นอย่างไรก็ปล่อยมันไป แค่เราทำสิ่งที่เราทำได้เต็มที่ก็พอ ซึ่งพอทำไปแล้วก็สบายใจเพราะเหมือนได้เข้าใกล้คนที่ตัวเองอยากเป็นไปอีกขั้น แถมได้ IG ของคนที่ชอบมาด้วย ฮ่าๆๆๆๆๆ

ความตาย

ปีนี้ได้ใกล้ชิดกับความตายมากขึ้นอะไรหลายๆอย่างที่คุ้นเคยเห็นกันมานานเป็น 10 - 20 ปีอยู่ดีๆก็หายไป คนที่รักก็เจ็บป่วยจนเกือบจะจากกันแบบไม่ได้จากลา ไม่ได้เตรียมตัว ตอนนั้นนี่แบบนี่มันอะไรวะ เกิดอะไรขึ้น แล้วเราจะต้องทำยังไง ซึ่งจริงๆมันเป็นเรื่องที่เรากลัวที่สุดเพราะเรารู้ดีว่าเราไม่ใช่ผู้ใหญ่ เราเป็นแค่เด็กอายุ 12 ที่อยู่ในร่างคนอายุ 30 เราไม่เคยรับผิดชอบอะไรจริงๆจังๆ ไม่เคยตัดสินใจอะไรใหญ่ๆ สุดท้ายทุกอย่างก็ผ่านไป ได้บทเรียนหลายๆอย่างจากเรื่องนี้ไม่ว่าจะเวลาที่เหลือน้อยลงทุกที อะไรที่ยังขาด ได้รู้จักความกลัวของตัวเองไปอีกขั้น ซึ่งก็ยังไม่รู้วิธีจัดการ แต่อย่างน้อยเราก็รู้ว่าเรากลัวอะไรล่ะนะ

อ่านหนังสือ

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

ปรัชญา

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

ละครเวที

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

งานเขียน

ปีนี้ได้ลองเขียนงานลง web ดู เป็นเรื่องสั้นที่ดูขัดแย้งกับกระแสหลัก แถมดูจะขัดกับความชอบของคนส่วนใหญ่ด้วย ซึ่งผลออกมาก็ไม่ค่อยดีสักเท่าไหร่ แต่อย่างน้อยก็ได้เขียนได้ระบายความคิดของตัวเองให้คนอื่นอ่าน อย่างน้อยเราก็มีงานประมาณ 100 หน้า (เป็นหนังสือเล่มเล็กๆได้เลยนะเนี่ย) ของตัวเองแล้ว

ใครสนใจไปอ่านได้ที่ : https://www.readawrite.com/a/999058dbffdbc084ac18e535e303ce52

ดูหนัง

เนื่องจากเฮิร์ทเพราะจีบสาวไม่ติด 2 รอบติดต่อกัน จนมาถึงจุดที่ว่าต้องหาอะไรทำเพื่อพาตัวเองออกจากวังวนที่คิดเรื่องนั้นซ้ำไปซ้ำมา จนสุดท้ายมาเห็นว่า Major มีสมาชิกรายเดือน และตอนนั้นมีหนังที่อยากดูหลายเรื่องก็เลยสมัครแล้วไปดูหนัง 4 เรื่องติดต่อกัน ซึ่งพอได้ดูหนังแล้วก็สนุกดี เหมือนตัวเองหลุดไปจากโลกที่กำลังอยู่ ได้ไปทำความเข้าใจหนัง พยายามค้นหาว่าหนังบอกอะไร ได้ดูทั้งหนังดี หนังไม่ดี ได้เห็นลูกเล่นการเล่าเรื่อง การสร้างตัวละคร ได้หงุดหงิดกับความอะไรวะของบท พอดูบ่อยก็ติดเป็นนิสัยจนตอนนี้กลายเป็นว่าปีนี้ทั้งปีดูหนังเกือบจะเยอะกว่าทั้งชีวิตอีก

ช่อง Youtube

ปีนี้ได้ทำช่อง Youtube เยอะขึ้น จากตอนแรกว่าจะลงเกี่ยวกับการเขียน Code อย่างเดียว แต่คิดไปคิดมาไหนๆเราก็มีอะไรอยากเล่า อยากพูดมากกว่าเรื่อง code แถมเรื่อง code ก็พูดไปเกือบหมดแล้ว ก็เลยเอาวะทำ podcast พูดเรื่องหนังกับละครเวทีที่ดู หนังสือที่อ่าน แล้วก็มีทำคลิปสอนเรื่องเกี่ยวกับการเขียนโปรแกรม ซึ่งทำไปก็สนุกดีนะ แบบมันมีอะไรให้เราทำอยู่ตลอด

ใครสนใจอยากฟังเกี่ยวกับหนัง หนังสือ หรือ เรื่องเกี่ยวกับการเขียนโปรแกรมไปกดติดตามได้ที่ : https://www.youtube.com/channel/UCd1p76uP-ufG8UEWuuTWzUg

จัดฟัน

จริงๆเลิกคิดจะจัดฟันไปนานแล้วเนื่องจากคิดว่าฟันก็ปกติดีไม่มีปัญหาอะไรแล้วก็อยู่ได้มาตั้ง 30 ปี ก็ไม่น่าจะต้องปรับแต่งอะไร แต่อยู่ดีๆก็เริ่มเจ็บฟันคุดขึ้นมาก็เลยคิดว่าเออไปถอนฟันคุดทิ้งดีไหม พอดีกับคนที่ทำงานชวนไปลองดูว่าถ้าจัดฟันต้องทำอะไรบ้าง ตอนแรกก็กะจะไม่ทำอยู่ดี จนผู้หญิงที่ผมชอบ (แต่เขาแต่งงานไปแล้ว)บอกว่า ทำไมแกเห็นแก่ตัวอย่างนี้นะ แกไม่สงสารคนที่รักแกในอนาคตเลยเหรอที่เขาจะต้องมาทนกับหน้าแกแบบนี้ไปทั้งชีวิต แกเหมือนเป็นคนเห็นใจคนอื่นรักคนอื่นนะ แต่ไม่ใช่อะแกเห็นแก่ตัว พอผมได้ฟังประโยคนี้นี่ทำให้ได้คิดในมุมที่ไม่เคยคิด พอมานึกภาพผู้หญิงที่ผมรักต้องมาทนกับหน้าตาของผู้ชายคนหนึ่งที่ออกไปทางไม่หล่อตามค่านิยมกลาง ถึงเขาจะไม่คิดอะไร แต่ถ้าเราดูดีกว่านี้ ดูปกติอยู่ในค่านิยมกลางสักหน่อย เขาคงจะมีความสุขขึ้นสักนิดล่ะนะ พอคิดได้แบบนั้นก็เลย เอาวะลองดู ฟันเหยินมา 20 กว่าปีละ ลองเป็นคนฟันไม่เหยินในช่วงชีวิตที่เหลือดู อย่างน้อยก็เพื่อคนที่เรารัก (ที่ไม่รู้ว่ามีหรือเปล่าดู)

ปี 2024 ทำอะไรดีล่ะ

• ปลูกต้นไม้

  หลังจากคิดหาอะไรทำมานานก็มาคิดถึงอะไรที่ทำแล้วไม่ต้องคอยดูตลอด แต่ต้องไปดูแลบ้าง คิดไปคิดมาก็ซึ่งสิ่งนั้นก็คือการปลูกต้นไม้ เพราะเราไม่ต้องคอยเฝ้าจับตามันตลอดเวลามันก็สามารถเจริญเติบโตเองได้ แต่เราก็ต้องไปดูแลมันบ้าง ซึ่งถือเป็นงานอดิเรกที่ไม่แน่นและไม่หลวมจนเกินไป

• ออกกำลังกาย

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

• ทำช่อง Youtube ต่อ

  ปีนี้ก็จะทำช่อง Youtube ต่อโดยจะทำเรื่องเกี่ยวกับเรื่อง code ให้เยอะขึ้นเพราะตอนนี้ช่องจะกลายเป็นช่อง Review หนังไปแล้ว

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

เพลงที่ได้ฟังในปีนี้

Basic Kubernetes Part 10 - Helm - เครื่องมือที่ช่วยในการ Deploy อะไรที่ซับซ้อน Part 3

ในการ Deploy นั้นไม่ใช่ว่าทุกการ Deploy จะสำเร็จ บางทีอาจจะเกิดปัญหาขึ้น เช่น มีการ config ผิด หรือพอ Deploy ไปแล้วเกิด Bug ที่รุนแรงจนระบบไม่สามารถทำงานต่อได้ ซึ่งเมื่อเกิดเรื่องแบบนี้ขึ้นก็เป็นที่แน่นอนว่าเราต้องทำการ Rollback เอาการ Deploy ครั้งก่อนกลับมา ซึ่งวิธีการ Rollback กลับมาก็มีได้หลายวิธี เช่น เอา VM ที่ Backup ไว้กลับมา เอา Folder ของ App เวอร์ชั่นเก่ากลับมา เป็นต้น

คราวนี้พอเรามาใช้ k8s ในการ deploy application เราจะเอาการ deploy เก่ากลับมายังไง วิธีง่ายสุดก็คือเก็บไฟล์ yaml เก่าเก็บไว้ พอมีปัญหาค่อยเอาตัวเก่ามาสั่ง apply แต่ปัญหาคือ ในไฟล์ yaml ที่เราสร้างนั้นมีการเพิ่ม deployment service หรือสิ่งต่างๆเข้าไป พอคุณเอาไฟล์เก่ามา apply ตัว resource ใหม่ที่เพิ่มมามันไม่หายไปด้วย ซึ่งนั่นเป็นปัญหาที่คุณต้องตามไปจัดการ

ซึ่งคนที่ใช้ helm ในการ deploy ก็เจอปัญหานี้เหมือนกัน ดังนั้นเขาจึงคิดวิธีการจัดการปัญหาโดยมี Feature การ Rollback ให้กับเราครับ

Deploy version 1

ตัวอย่างไฟล์ทั้งหมดสามารถดูได้ที่ Link

ในขั้นแรกเราลอง Deploy application version 1 กันก่อนโดยไฟล์ template ที่ใช้ในการ deploy คือ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
spec:
  rules:
    - host: {{ .Values.domain }}
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

จากนั้นสั่ง deploy

1

helm upgrade --install whoami-helm --namespace whoami-namespace  --create-namespace whoami/

จากนั้นลองสั่งคำสั่งด้านล่างเพื่อดู Resource ที่เราทำการสร้างขึ้นมาว่ามีอะไรบ้าง

1

kubectl -n whoami-namespace get all

จากนั้นลองสั่งคำสั่งด้านล่างเพื่อดูรายละเอียดของชุด Deploy ที่เราสร้างด้วย helm ครับ

1

helm list -A

จะเห็นว่ามีการสร้างชุด deploy ชื่อ whoami-helm ขึ้นมาแล้วและเลข REVISION เป็น 1 ให้จำเลขตัวนี้ไว้นะครับ

ลองเข้า http://company-c.com/?env=true ผ่าน browser ซึ่งจะเห็นว่าสามารถเปิดได้

Deploy version ที่มีปัญหา

คราวนี้เรามาลองจำลองสถานการณ์ว่าเรา Deploy แล้วเกิดปัญหา โดยผมจะทำการแก้ config ให้ผิด และ เพิ่ม deployment ที่ไม่ใช้งานเข้าไป โดยดูตัวอย่างได้ใน folder : whoami-bug

แก้ไขไฟล์ values.yaml

จากไฟล์จะเห็นว่าผมแก้ตัว domain เปลี่ยนไปทำให้เข้าด้วย http://company-c.com/?env=true ไม่ได้ อีกทั้งก็เปลี่ยนค่า environment owner ไป

1
2

domain: "wasinee-company-c.com"
owner: "WASINEE BD"

แก้ไขไฟล์ whoami.yaml

จากไฟล์ผมจะทำการเพิ่มตัว nginx-bug-deployment เข้าไปเพื่อให้มี deployment ใหม่ที่เกินเข้าไป

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-bug-deployment
  labels:
    app: nginx-bug
spec:
  selector:
    matchLabels:
      app: nginx-bug-app
  template:
    metadata:
      labels:
        app: nginx-bug-app
    spec:
      containers:
        - name: nginx-bug-container
          image: nginx:1.25.3-alpine
          ports:
            - containerPort: 80
---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
spec:
  rules:
    - host: {{ .Values.domain }}
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

จากนั้นสั่ง deploy ด้วยคำสั่งด้านล่างเพื่อ update ตัว helm

1

helm upgrade --install whoami-helm --namespace whoami-namespace  --create-namespace whoami-bug/

จากนั้นลองสั่งคำสั่งด้านล่างเพื่อดู Resource ที่เราทำการสร้างขึ้นมาว่ามีอะไรบ้าง

1

kubectl -n whoami-namespace get all

จากภาพจะเห็นว่ามี deployment nginx-bug-deployment โผล่ขึ้นมา

จากนั้นลองสั่งคำสั่งด้านล่างเพื่อดูรายละเอียดของชุด Deploy ที่เราสร้างด้วย helm ครับ

1

helm list -A

จะเห็นว่า whoami-helm เปลี่ยน REVISION เป็น 2 แล้ว

ลองเข้า http://company-c.com/?env=true ผ่าน browser ซึ่งจะเห็นว่าไม่สามารถเปิดได้

Rollback กลับเป็น version เก่า

จากตัวส่วนที่แล้วเราได้จำลองการ Deploy ที่เกิดปัญหาคือค่า config domain ผิดและทำการเพิ่ม deployment ใหม่เข้าไป คราวนี้ถ้าเราอยากให้การ deployment ของเราทั้งหมดกลับไปเป็น version ก่อนหน้านี้คือ มีค่า config domain เดิม และ deployment เหมือนเดิมทั้งหมดจะทำยังไงดี อย่างที่บอกไป helm มีคำสั่งให้เรา rollback อยู่แล้ว ซึ่งเราสามารถสั่งได้โดยสั่ง (เดี๋ยวเรามาอธิบายคำสั่งทีหลัง)

1

helm rollback -n whoami-namespace whoami-helm 1 --force

เมื่อสั่งเสร็จเรามาลอง get resource ดูกันว่าเกิดอะไรขึ้น

1

kubectl -n whoami-namespace get all

จะเห็นว่าตัว nginx-bug-deployment หายไปแล้ว

ลองเข้า http://company-c.com/?env=true ผ่าน browser ซึ่งจะเห็นว่าสามารถเปิดเข้าไปได้เหมือนเดิมแล้ว

ซึ่งนั่นแปลว่าการ Deploy ทั้งหมดกลับมาเป็น Version 1 ที่เราต้องการแล้ว ซึ่งแปลว่าเราสามารถทำการ Rollback สำเร็จแล้ว

คราวนี้เรามาลอง helm list ดูกันว่ามีอะไรเปลี่ยนแปลง

1

helm list -A

จากภาพจะเห็นว่าเลข REVISION เปลี่ยนเป็น 3 ต่อจาก 2

อธิบายคำสั่ง helm rollback

1

helm rollback -n whoami-namespace whoami-helm 1 --force

• helm rollback : เป็นคำสั่งเพื่อสั่งให้ทำการ Rollback
• -n whoami-namespace : -n เป็นตัวบอกว่าตัวชุด deploy ที่ต้องการ rollack นั้นอยู่ที่ไหน โดยจากตัวอย่างคือ whoami-namespace
• whoami-helm : ตรงส่วนนี้คือชื่อตัวชุด deploy โดยในตัวอย่างคือ whoami-helm
• 1 : ตรงส่วนนี้คือตัว REVISION ที่เราต้องการ Rollback กลับไปหา ในที่นี้คือ 1
• –force : ส่วนนี้เป็นการบอกว่าให้ทำการ update ไม่ว่าจะต้องทำการลบ หรือ สร้างใหม่ก็ตาม

รวมแล้วคือ ทำการ rollback ตัวชุด deploy : whoami-helm ที่อยู่ที่ namespace : whoami-namespace ให้กลับไปอยู่ใน REVISION ที่ 1 โดยทำการลบหรือสร้างใหม่ถ้าจำเป็นต้องทำ

ซึ่งเมื่อทำการสั่ง rollback ไปแล้วนั้นเลข REVISION นั้นจะไม่ได้กลับไปเป็นเลข 1 นะครับ ตัวเลข REVISION จะเพิ่มขึ้นเรื่อยๆ แต่ค่าการ config ต่างๆของ RESOURCE นั้นจะกลับไปเท่ากับ REVISION ที่เราเลือกในคำสั่งครับ

รายละเอียดเพิ่มเติมเกี่ยวกับคำสั่งสามารถดูได้ที่ : https://helm.sh/docs/helm/helm_rollback/

สรุป

ในตอนนี้เราได้รู้วิธีการ Rollback การ Deploy โดยใช้ helm แล้ว ซึ่งง่ายมากๆแค่ใช้คำสั่งคำสั่งเดียว และสำหรับตอนนี้ถือเป็นตอนสุดท้ายของ Basic Kubernetes ซึ่งผมก็หวังว่าทั้ง 10 ตอนที่ได้เขียนไปจะมีประโยชน์กับผู้อ่านได้นำไปใช้ในการทำงาน แล้วเจอกันใหม่ในเรื่องหน้าสวัสดีครับ

Basic Kubernetes Part 9 - Helm - เครื่องมือที่ช่วยในการ Deploy อะไรที่ซับซ้อน Part 2

ในตอนที่แล้วเราได้ลองใช้งานตัว Helm ในการทำการ deploy application โดยทำการสร้าง template และแทนค่าด้วย value ตามที่กำหนดไว้ ซึ่งเราสามารถ deploy application ให้กับ company a , company b , company c ผ่านการใช้ config file ซึ่งดูเหมือนว่ามันจะหมดแล้ว แต่ในการใช้งานจริงนั้นมีความต้องการอีกหลายอย่างที่ต้องการและ Helm สามารถช่วยเราได้

ตัวอย่างไฟล์ทั้งหมดสามารถดูได้ที่ Link

if

ในบางกรณีที่เราต้องการ Deploy ที่ต้องใช้ if ตัวอย่างเช่นถ้าเป็นลูกค้า vip นั้นจะใช้ memory ได้ 500MB แต่ถ้าไม่ใช่จะใช้ memory ได้แค่ 100MB (ผมขอใช้ env บอกขนาด memory ที่ใช้ได้ แทนการบังคับ memory จริงๆ จะได้ตรวจสอบง่ายๆ)

ด้วยความรู้ที่เรามีตอนนี้สิ่งที่เราทำได้คือการสร้างค่า config เพิ่มในไฟล์ values.yaml และแก้ไขไฟล์ template ดังตัวอย่างด้านล่าง

values.yaml

1
2
3

domain: "company-c.com"
owner: "NORMAL PROGRAMMER"
maxMemory: "400MB"

จากตัวอย่างด้านบนเราทำการสร้าง config ชื่อ maxMemory ขึ้นมาเพื่อใช้แสดง memory สูงสุดที่สามารถใช้ได้

whoami.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
            - name: "MAX_MEMORY"
              value: {{ .Values.maxMemory }}
---
# ผมขอละการประกาศส่วน service กับ ingress นะครับ

จากตัวอย่างด้านบนจะเห็นว่าเราเพิ่ม .Values.maxMemory เข้าไป ด้วยการทำเท่านี้เราก็สามารถ deploy application ได้ตามความต้องการแล้ว

ปัญหาที่เกิดขึ้น

ปัญหาที่เกิดขึ้นนั้นมาจากการเรากำหนด maxMemory ไว้ที่ไฟล์ config เพื่อบอกว่า memory ที่ใช้ได้คือเท่าไหร่ ทีนี้ลองคิดภาพตามว่าถ้าสมมติว่ามีการเปลี่ยนกฏเกี่ยวกับ maxMemory เช่น ลูกค้า VIP ใช้ maxMemory ได้ 800MB ส่วนที่ไม่ใช่จะได้ 600MB ถ้ามีการเปลี่ยนกฏแบบนี้รับรองเลยว่าคุณจะต้องไปไล่แก้ config ไฟล์ของทุกลูกค้าโดยแก้จาก 400MB ไปเป็น 800MB ซึ่งแน่นอนว่าถ้ามีสัก 100 บริษัทก็น่าจะเป็นฝันร้ายในการไล่แก้ อีกทั้ง ถ้าชนิดของลูกค้ามีหลายระดับเช่น nomal , goal , vip แล้วบางระดับใช้ memory เท่ากัน เช่น goal กับ vip ใช้ memory เท่านั้น คราวนี้คุณจะไม่สามารถ replace all 400MB ไปเป็น 800MB ได้แล้ว เพราะคุณต้องไปแยกเองว่าตกลงแล้วบริษัทนี้มันอยู่ระดับอะไร สร้างความวุ่นวาย ปวดหัวไปอีก นี่ยังไม่รวมว่าถ้าย้ายระดับจะต้องแก้กี่ค่า (กรณีที่ไม่ได้จำกัดแค่ maxMemory)

ใช้ if มาแก้ปัญหา

จากปัญหาในส่วนที่แล้ว จะเห็นว่าเราต้องการควบคุมขนาดของ maxMemory ที่เดียว ไม่อยากไปจัดการที่ไฟล์ config ดังนั้นเราจึงควรกำหนดมันลงไปที่ template เลย ในส่วน config นั้นเราเปลี่ยนมากำหนดชนิดของลูกค้าไปในไฟล์ values แทน เพื่อที่จะได้รู้ไปเลยว่าตกลงแล้วลูกค้านี้เนี่ยอยู่ในระดับใด และเวลาแก้ไขก็แก้ระดับก็แก้ทีค่าเดียวไปเลย

values.yaml

1
2
3

domain: "company-c.com"
owner: "NORMAL PROGRAMMER"
customerType : "VIP"

ในส่วนนี้เราจะเพิ่ม config value : customerType ขึ้นมาเพื่อบอกว่าลูกค้านี้อยู่ type อะไร

whoami.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
            - name: "CUSTOMER_TYPE"
              value: {{ .Values.customerType }}
            - name: "MAX_MEMORY"
        {{ if eq .Values.customerType "VIP" }}
              value: "400MB"
        {{ else if eq .Values.customerType "GOLD" }}
              value: "300MB"
        {{ else }}
              value: "100MB"
        {{ end }}
---
# ผมขอละการประกาศส่วน service กับ ingress นะครับ

จากตัวอย่างจะเห็นว่าเราทำการเพิ่มส่วน if else เข้าไป โดยตรง if eq .Values.customerType “VIP” เป็นเงื่อนไขที่ต้องการ ถ้าตรงจะให้ทำสิ่งนั้น ในที่นี้เราทำการตั้งเงื่อนไขว่า ถ้า customerType มีค่าเป็น VIP เราจะกำหนด value ของ maxMemory เป็น 400MB ในส่วนของ else if ก็ใช้หลักการเดียวกันแต่เปลี่ยนจาก VIP เป็น GOLD และส่วนที่เป็น else ก็คือถ้าไม่ตรงอะไรเลยก็เข้าเงื่อนไขนั้นซึ่งในที่นี้คือกำหนด memory เป็น 100MB

ทดสอบ Deploy

เมื่อเราลอง dpeloy และเข้าดูผ่าน browser ที่ url : http://company-c.com/?env=true ซึ่งเมื่อเข้าไปดูแล้วจะพบว่า maxMemory เป็น 400MB ตามเงื่อนไขที่เรากำหนด

คราวนี้เรามาลองเปลี่ยน config customerType ในไฟล์ values.yaml ดูว่าถ้าเปลี่ยนแล้วค่าจะเปลี่ยนตามไหม โดยผมจะลองเปลี่ยน custmoerType เป็น GOLD ซึ่งเมื่อเปลี่ยนแล้วลองไปเช็คดูจะพบว่าค่าเปลี่ยนเป็น 300MB ตามที่ตั้งค่าไว้

คราวนี้ลองเปลี่ยน customerType เป็น NORMAL และลอง deploy update จะพบว่าค่าเปลี่ยนเป็น 100MB

ซึ่งจากการทดลองจะเห็นว่าเราสามารถ if else ได้ตามความต้องการของเราแล้ว

loop

ในบางกรณีเราอยากจะวน loop ทำอะไรสักอย่าง ตัวอย่างเช่น ถ้าลูกค้าบางคนต้องการเพิ่ม environment เพิ่มเข้าไปเองเพื่อเอาไปใช้ ซึ่งแต่ละลูกค้ามี environment ที่ไม่เหมือนกันเลยนั้น เราจะทำอย่างไร ซึ่งด้วยความรู้ที่เรามีอยู่ตอนนี้เราไม่สามารถทำได้เลยเพราะ template นั้นเป็นค่า fix จะไปรู้ได้อย่างไรว่ามีค่า environment อะไรบ้าง มีกี่ตัว ตรงจุดนี้เองที่ loop จะเข้ามาช่วยเรา

values.yaml

1
2
3
4
5
6
7
8

domain: "company-c.com"
owner: "NORMAL PROGRAMMER"

customEnvironment:
  CUSTOM_VALUE_1 : "WASINEE"
  MY_TIMEZONE: "Asia/Bangkok"
  MAX_RETRY: "5"
  USERNAME: "TEST_USER"

ตรงส่วนนี้เราทำการเพิ่ม config : customEnvironment โดยภายใต้ customEnvironment นั้นเรามีการกำหนด environment ที่เราจะเพิ่มเข้าไปคือ CUSTOM_VALUE_1 , MY_TIMEZONE , MAX_RETRY, USERNAME

whoami.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
          {{ range $key, $value := .Values.customEnvironment }}
            - name: "{{ $key }}"
              value: "{{ $value }}"
          {{ end }}
---
# ผมขอละการประกาศส่วน service กับ ingress นะครับ

ตรงส่วนนี้เราจะเพิ่มส่วนการ for loop เอาค่าไปใน environment โดยตรงส่วนที่เราประกาศว่า range $key, $value := .Values.customEnvironment ตรงส่วนนี้คือการบอกว่าจะทำการวน loop โดยวนที่ตัว customEnvironment ซึ่งภายในมีค่า

1
2
3
4

CUSTOM_VALUE_1 : "WASINEE"
MY_TIMEZONE: "Asia/Bangkok"
MAX_RETRY: "5"
USERNAME: "TEST_USER"

โดยตอนวนนั้นจะให้ค่า $key คือค่าที่เป็น key (ซึ่งนั่นก็คือ CUSTOM_VALUE_1 , MY_TIMEZONE , MAX_RETRY , USERNAME ) และค่า $value คือค่าที่เป็น value (ซึ่งนั่นก็คือ WASINEE , Asia/Bangkok , 5, TEST_USER) ดังนั้นเวลาวนค่าของ key value จะเป็น

1
2
3
4

- key : CUSTOM_VALUE_1  - value : WASINEE
- key : MY_TIMEZONE     - value : Asia/Bangkok
- key : MAX_RETRY       - value : 5
- key : USERNAME        - value : TEST_USER

ซึ่งในส่วนที่ต่อมาคือส่วนที่เราเอาค่า key value ไปใช้ ในที่นี้คือการกำหนดค่า environment ของ pod นั่นเอง

ทดสอบ Deploy

เมื่อเราลอง dpeloy และเข้าดูผ่าน browser ที่ url : http://company-c.com/?env=true จะพบว่ามีค่า Environment เป็นไปตามที่เราใช้ loop กำหนดใน template

คราวนี้เรามาลองทดสอบเพิ่มค่าใน customEnvironment เหมือนด้านล่าง จากนั้นลองสั่ง Deploy

1
2
3
4
5
6
7
8
9
10

domain: "company-c.com"
owner: "NORMAL PROGRAMMER"

customEnvironment:
  CUSTOM_VALUE_1 : "WASINEE"
  CUSTOM_VALUE_2 : "PICHAYA"
  CUSTOM_VALUE_3 : "SUNISA"
  MY_TIMEZONE: "Asia/Bangkok"
  MAX_RETRY: "5"
  USERNAME: "TEST_USER"

ซึ่งจากภาพจะเห็นว่าค่า environment มีการเพิ่มตามที่เราเพิ่มในไฟล์ values.yaml จริงๆ ดังนั้นก็แปลว่าการประกาศ template แบบ loop ที่เราต้องการนั้นทำงานถูกต้อง

สรุป

สำหรับตอนนี้เราได้เรียนรู้การใช้ความสามารถของ Helm ในการใช้ if และ loop บนตัว template เพื่อให้สามารถทำการ deploy application ที่มีความซับซ้อนมากขึ้นได้แล้ว สำหรับตอนหน้าซึ่งน่าจะเป็นตอนสุดท้ายของซีรีย์ Basic Kubernetes เราจะมาเรียนรู้วิธีการ Rollback โดยใช้ Helm

Basic Kubernetes Part 8 - Helm - เครื่องมือที่ช่วยในการ Deploy อะไรที่ซับซ้อน Part 1

ในตอนที่แล้วเราได้ลองทำโจทย์การ Deploy : WordPress ทำให้เราเห็นว่ามันมีความต้องการที่ต้องการ Deploy WordPress ที่มี Template เดียวกัน แตกต่างกันแค่ Config เช่น domain name ซึ่งในตอนที่แล้วเราใช้ envsubst ในการทำ แต่ปัญหาที่เรายังแก้ไม่ได้ก็คือ ถ้ามีการแบ่งลูกค้าเป็นหลายแบบ แต่ละแบบมี template ที่ deploy แตกต่างกันเพียงเล็กน้อยเราจะทำอย่างไร (จริงๆก็แยกเป็นหลายๆ template เลยก็ได้นะ แต่มันดูเหนื่อยเกินไปถ้ามีสัก 5 แบบ แล้วแตกต่างกันนิดเดียว) ซึ่งปัญหานี้ได้มีคนสร้างเครื่องมือเพื่อแก้ปัญหาแล้ว เครื่องมือนั้นคือ Helm ที่เรากำลังจะไปเรียนรู้นั่นเอง

Helm คืออะไร

สำหรับผม Helm คือเครื่องมือที่ใช้ในการ Deploy application ที่ซับซ้อนบน k8s โดยมี Feature ในการ Install , Update , Rollback , Uninstall ก็ได้ (นิยามจริงๆอ่านได้ที่นี่) ซึ่งจะเห็นว่าพวก Feature ที่ว่าไปนั้นตัว k8s ไม่มีให้ ลองนึกถึงตอนที่ทำการ Uninstall อะไรที่เราพึ่งสั่ง apply ไปสิครับ เราต้องไปไล่หาไฟล์ทั้งหมดที่เราสั่ง apply มาสั่ง delete แต่ถ้าเป็น Helm ล่ะก็คุณสั่งแค่คำสั่งเดียวครับ

Install Helm

ก่อนจะใช้งาน Helm เราต้อง install helm กันก่อนครับ โดยวิธี Install ดูได้ตาม Link นี้เลย : https://helm.sh/docs/intro/install/ ลงแบบไหนเอาตามที่ท่านสะดวกเลย

• สำหรับใครที่ VM ของผม

ให้แก้ไขไฟล์ : /root/.bashrc

จากนั้นเพิ่มบรรทัดนี้เข้าไปใไฟล์

1

export KUBECONFIG="/etc/rancher/k3s/k3s.yaml"

จากนั้นสั่ง

1

source /root/.bashrc

จากนั้นสั่งกด ctrl + , เพื่อเปิดหน้าจอ Setting และกดตามภาพเราจะเปิดหน้า setting ขึ้นมา

จากนั้นนำข้อมูล JSON ด้านล่างไปใส่ในไฟล์ที่เปิดขึ้นมา

1
2
3

{
    "terminal.integrated.defaultProfile.linux": "bash"
}

จากนั้นลองสั่งคำสั่งด้านล่างผ่าน terminal

1

helm list

ถ้าลงสำเร็จจะต้องได้ดังภาพ

เริ่มใช้งาน Helm

ตัวอย่างไฟล์ทั้งหมดสามารถดูได้ที่ Link

ทำการสั่ง command ด้านล่าง

1

helm create whoami

คำสั่งนี้จะเป็นคำสั่งที่สั่งสร้างสิ่งที่เรียกว่า Charts ขึ้นมา โดย Charts ก็เป็นเหมือน Template ที่บอกว่าเราต้องการ Deploy อะไรบ้าง ตัวแปร config ที่จะไปแทนที่ใน Template เป็นอะไร โดยเมื่อสั่งคำสั่งด้านบนเราจะได้ Folder และไฟล์แบบด้านล่าง

โดยสิ่งที่เราจะสนใจคือไฟล์ดังต่อไปนี้

1. Chart.yaml

   ไฟล์นี้เป็นไฟล์ที่บอกรายละเอียดของ Chart นี้ว่าใช้ version อะไร เอาไปใช้ทำอะไร ให้คนที่เอา Chart เราไปใช้รู้ว่ามันคืออะไร

2. templates

   Folder นี้เป็น Folder ที่เก็บไฟล์ yml ของ k8s ที่เราต้องการทำเป็น template

3. values.yaml

   ไฟล์นี้เป็นไฟล์ที่ใส่ค่า config ที่เราจะไปแทนที่ใน template

จากนั้นทำการลบไฟล์ให้หมดจนเหลือแค่นี้ครับ (ลบไฟล์ใน Folder ด้วย)

สร้างไฟล์ template

สร้างไฟล์ whoami.yml ใน folder : templates โดยเราจะสร้าง deployment : whoami จากนั้นให้ยิงเข้ามาผ่าน ingress ที่ domain ชื่อ company-c.com ( อย่าลืม Add Domain name ใน file hosts นะครับ )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: "company-c.com"
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
spec:
  rules:
    - host: "company-c.com"
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

จากนั้นสั่งคำสั่งด้านล่างเพื่อให้ helm ทำงาน (เดี๋ยวอธิบายคำสั่งทีหลังนะครับ)

1

helm upgrade --install whoami-helm --namespace whoami-namespace  --create-namespace whoami/

จากนั้นสั่งคำสั่งด้านล่างเพื่อดูว่า helm ทำงานสำเร็จหรือไม่

1

helm list -A

จากนั้นลองสั่งคำสั่งด้านล่างเพื่อเช็คว่ามีอะไรเกิดขึ้นบ้าง

1
2
3

kubectl -n whoami-namespace get deployment
kubectl -n whoami-namespace get service
kubectl -n whoami-namespace get ingress

จากภาพจะเห็นว่ามีการสร้าง deployment , service ,ingress ขึ้นมาให้ตาม template เลย

จากนั้นลองเข้า Browser ไปที่ URL : http://company-c.com?env=true ซึ่งจะพบว่าสามารถเข้าถึง Container whoami ที่เราสร้างขึ้นมาได้

จากทั้งหมดเราจะเห็นว่าคำสั่งของ helm จะทำการสร้าง k8s object ตามไฟล์ที่ใส่ไว้ใน folder : template จากตัวอย่างคือไฟล์ : whoami.yaml

ทำ helm เอาค่า variable มาใส่ใน template ได้

จากตอนที่แล้วเรามีความต้องการที่จะ deploy app หลายๆตัวที่มีโครงสร้าง app เหมือนกันหมดเลย ต่างกันแค่บางค่าที่เฉพาะเช่น เปลี่ยน domain name เปลี่ยนค่า config ให้กับ app เป็นต้น ซึ่งตอนที่แล้วเราใช้ตัว envsubst ในการทำ แต่ตอนนี้เราจะใช้ helm ทำกันครับ

กำหนด Variable ที่จะใช้ในการแทนค่าได้

ส่วนนี้จะคล้ายๆกับการ set environment แต่ของ helm เราต้องกำหนดค่าที่ไฟล์แทน โดยเราจะกำหนดค่าที่ไฟล์ values.yaml โดยตัวไฟล์มีค่าดังนี้ (ค่าเก่าลบทิ้งไปได้เลยครับ)

1
2

domain: "company-c.com"
owner: "NORMAL PROGRAMMER"

ทำให้ Template สามารถเอาค่ามาใส่ได้

เมื่อเรากำหนดค่า variable มาแทนค่าได้แล้ว ส่วนต่อไปที่เราต้องทำคือทำให้ไฟล์ template สามารถเอาค่า variable มาใส่ โดยเราสามารถทำได้โดยการไปแก้ไขไฟล์ : whoami.yml โดยแก้ไขเป็น

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami-app
  template:
    metadata:
      labels:
        app: whoami-app
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: "OWNER"
              value: {{ .Values.owner }}
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
spec:
  rules:
    - host: {{ .Values.domain }}
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

โดยเราจะเห็นว่าส่วนแก้ไขคือ

1
2

{{ .Values.owner }}
{{ .Values.domain }}

ซึ่งมันคือ variable ที่เราประกาศไว้ในไฟล์ values.yaml ที่เราพึ่งกำหนดไป

จากนั้นลองสั่งคำสั่งด้านล่าง

1

helm upgrade --install whoami-helm --namespace whoami-namespace  --create-namespace whoami/

จากนั้นลองเปิด Browser ไปที่ URL : http://company-c.com?env=true ซึ่งจากภาพจะเห็นว่าสามารถเข้าไปที่ company-c.com ตาม value ที่กำหนดใน domain และ environment : onwer นั้นมีค่าเป็น NORMAL PROGRAMMER

คุณสามารถลองเปลี่ยนค่า variable ในไฟล์ values.yaml เป็นค่าอื่นดูแล้วสั่ง helm upgrade ดูว่าค่านั้นเปลี่ยนไปตามที่คุณต้องการหรือไม่

ถ้าอยากลบล่ะ

เราสามารถลบชุดการ deploy ที่สร้างขึ้นมาได้โดยใช้คำสั่ง

1

helm delete -n whoami-namespace whoami-helm

โดยเมื่อเราลองสั่ง list ดูจะเห็นว่าไม่มีข้อมูลชุดการ deploy : whoami-helm เหลืออยู่แล้ว

อธิบาย helm command

helm upgrade

คำสั่งนี้เราได้ใช้มาหลายครั้งแล้ว ส่วนนี้เรามาเข้าใจว่ามันทำอะไร

1

helm upgrade --install whoami-helm --namespace whoami-namespace  --create-namespace whoami/

• helm upgrade : คำสั่งนี้เป็นการสั่งให้ helm upgrade ชุดการ deploy ที่ระบุ โดยในที่นี้คือสั่งให้ upgrade : whoami-helm

• –install : ส่วนนี้คือการบอกว่าถ้าไม่เคยสร้างตัวชุดการ deploy มาก่อนให้ทำการสร้าง ในที่นี้คือถ้าไม่เคยมี whoami-helm

• –namespace : ส่วนนี้คือการบอกว่าตัวชุดการ deploy นั้นจะไปอยู่ใน namespace ไหน ในที่นี้คือไปสร้างใน namespace : whoami-namespace

• –create-namespace : ส่วนนี้คือการบอกว่าถ้า namespace ที่จะให้ไปอยู่ยังไม่เคยสร้าง ให้ทำการสร้าง namespace ขึ้นมาด้วย

• whoami/ : ส่วนนี้คือ parameter ที่บอกว่าตัว template และ variable อยู่ที่ใด โดยในที่นี้คืออยู่ใน folder : whoami

รวมแล้วคำสั่งนี้คือการสั่งให้ helm ทำการสร้างชุด deploy ชื่อ whoami-helm ให้อยู่ที่ namespace : whoami โดยรายละเอียดที่ว่าต่างๆจะอยู่ใน folder whoami โดยถ้าชุดการ deploy : whoami-helm ไม่เคยสร้างให้ทำการสร้าง ถ้า namespace : whoami ไม่เคยสร้างให้ทำการสร้าง

helm list

1

helm list -A

• helm list : คำสั่งนี้เป็นคำสั่งที่ทำการแสดง ชุดการ deploy ทั้งหมดที่สร้างด้วย helm ใน namespace ที่เรากำลังอยู่

• -A : ส่วนนี้คือบอกว่าให้แสดงทุก namespace

รวมแล้วคำสั่งนี้คือให้แสดงชุดการ deploy ทั้งหมดทีสร้างด้วย helm ในทุก namespace

helm delete

1

helm delete -n whoami-namespace whoami-helm

• helm delete : คำสั่งนี้เป็นคำสั่งให้ทำการลบชุดการ deploy ที่ต้องการ

• -n : คือการบอกว่าชุดการ deploy ที่ต้องการลบอยู่ namespace ไหน ในที่นี้คือ namespace : whoami-namespace

• whoami-helm : คือ parameter ชื่อชุดการ deploy ในที่นี้คือ whoami-helm

รวมแล้วคำสั่งนี้คือการสั่งให้ลบ ชุดการ deploy ที่ชื่อ whoami-helm ที่อยู่ใน namespace : whoami-namespace

อยาก Deploy หลายๆ config

จากที่ส่วนที่ผ่านมาจะเห็นว่าเราสามารถแทน variable ไปใส่ใน template ได้แล้ว และเราสามารถแก้ไข variable ได้ที่ไฟล์ : values.yaml แต่ถ้าลองคิดดีๆมันก็เหมือนว่าเราต้องค่อยๆแก้ไขไฟล์ values.yaml ทุกครั้งที่เราอยากจะ deploy app ด้วย config ที่แตกต่าง ซึ่งนั่นไม่แตกต่างจากการแก้ไขที่ไฟล์ template เลย

แต่ไม่ต้องกังวลครับ helm เขาคิดเรื่องนี้มาแล้วและเปิดช่องทางให้เราสามารถ deploy ด้วยการใช้ values.yaml จากหลายที่ได้

สร้างไฟล์ values ใหม่ขึ้นมาเพื่อใช้ในการ deploy ที่มี config แตกต่าง

ทำการสร้าง folder : config-value จากนั้นทำการสร้างไฟล์

• values-company-a.yaml

1
2

domain: "company-a.com"
owner: "COMPANY-A-WASINEE"

• values-company-b.yaml

1
2

domain: "company-b.com"
owner: "COMPANY-B-PICHAYA"

จะเห็นว่าเรากำหนดตัว domain และ owner แตกต่างกันไว้

ทำการ deploy โดยใช้ไฟล์ values.yaml ตามที่เรากำหนด

ลองสั่งคำสั่งด้านล่าง โดยจะเห็นว่ามี parameter เพิ่มเข้ามาคือ -f ซึ่ง parameter ตัวนี้เป็นตัวบอกว่าไฟล์ values.yaml ที่เราอยากใช้นั้นคือไฟล์ไหน

1
2

helm upgrade --install company-a-whoami-helm --namespace whoami-a-namespace  --create-namespace whoami/ -f config-value/values-company-a.yaml
helm upgrade --install company-b-whoami-helm --namespace whoami-b-namespace  --create-namespace whoami/ -f config-value/values-company-b.yaml

จากภาพจะเห็นว่าเราได้ชุดการ deploy มาสองตัวคือ company-a-whoami-helm , company-b-whoami-helm ออกมา

มาทดสอบว่าการ deploy นี้ใช้งานได้จริงหรือไม่โดยเข้า browser แล้วไปที่ : http://company-a.com/?env=true

จากภาพจะเห็นว่าสามารถเข้าถึง company-a ได้จริงและค่า environment owner นั้นค่าตรงกับที่ config ไว้ในไฟล์ values-company-a.yaml

มาลองกับ company-b โดยเข้าไปที่ http://company-b.com/?env=true

จากภาพจะเห็นว่าสามารถเข้าถึง company-b และ environment เป็นไปตามที่ config ไว้ใน values-company-b.yaml

สรุป

สำหรับตอนนี้เราได้รู้เกี่ยวกับวิธีการใช้ helm ในการ deploy ประกาศ template ยังไง ประกาศ variable ยังไง และจะเอา variable มาใส่ใน template ยังไง อีกทั้งเรายังสามารถ deploy โดยกำหนดไฟล์ values ตามตำแหน่งที่เราต้องการได้ ซึ่งจากการทำวิธีนี้ทำให้เราสามารถ deploy application ให้แตกต่างตาม config ได้เทียบเท่ากับการใช้ envsubst ในตอนที่แล้ว (อาจจะง่ายกว่าด้วย) สำหรับตอนหน้าเรามาลองใช้ feature อื่นๆของ helm ที่คิดว่าทำให้การ deploy นั้นซับซ้อนขึ้นได้อีก และ คำสั่งที่จะอำนวยความสะดวกเราในการ deploy

Basic Kubernetes Part 7 - ทำโจทย์ - Deploy Wordpress บน k8s

WordPress เป็น Application หนึ่งที่ถูกเอามาใช้เพื่อสร้างเป็น Web ซึ่งได้รับความนิยมเป็นอย่างมากเพราะคนสามารถเอาไปดัดแปลงทำได้หลายอย่าง ตั้งแต่ Blog บอกเล่าเรื่องราวของคนทั่วไป ไปจนถึง ทำ Web ขายของออนไลน์ก็ได้ ใครอยากรู้ว่า WordPress คืออะไรแบบละเอียด กดที่ Link แล้วหาอ่านเพิ่มเติมได้เลย

วิเคราะห์โจทย์

คราวนี้ถ้าเราจะ Deploy ตัว WordPress ล่ะเราจะต้องทำอะไรบ้าง อย่างแรกคือเราต้องรู้ก่อนว่าตัว WordPress ต้องการอะไรบ้าง และมี Docker ให้ใช้ไหม

มี Docker ให้ใช้ไหมและต้องใช้อะไรบ้าง

เราสามารถ Search ที่ google ด้วยคำว่า WordPress + Docker ซึ่งเราก็เจอที่ Dockerhub โดยเรามี Docker ของ WordPress ให้ใช้ พร้อมบอกวิธีการ Set: ENVIRONMENT ด้วย

ซึ่งจากการดู ENVIRONMENT แล้ว เราจะพบว่าตัว WordPress เนี่ยต้องการใช้ MySQL ด้วย ซึ่งถ้าเรามี MySQL อื่นให้ใช้ก็ OK แต่เราไม่มีดังนั้นแปลว่าเราต้องสร้าง Database ด้วย

สรุปแล้วเราต้อง Deploy container 2 ตัวคือ

1. WordPress

2. MySQL

เริ่มสร้างไฟล์เพื่อ Deploy

ตัวอย่างไฟล์ทั้งหมดสามารถดูได้ที่ Link

สร้างส่วนที่เกี่ยวกับ MySQL

สิ่งที่ต้องสร้างสำหรับส่วน MySQL ที่ต้องมีคือ

1. Deployment ที่มีไว้สร้าง Pod
2. Service ที่ใช้เป็นตัวเปิดเส้นทางให้สามารถ Request ไปหา Pod ได้
3. ConfigMap เนื่องจากเราอยากแยก Config ออกจาก Deployment
4. Persistent Volume เนื่องจากตัว MySQL ต้องมีที่เก็บข้อมูล
5. Persistent Volume Cliam ต้องสร้างเพื่อให้ Pod สามารถเข้าถึง Volume ที่ต้องการได้

สร้างส่วน PV , PVC

ทำการสร้างไฟล์ mysql-volume.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  storageClassName: mysql-volume
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    # ตรงนี้เปลี่ยนเป็น path ของเครื่องคุณ
    path: /root/volume/mysql

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: mysql-volume
  resources:
    requests:
      storage: 2Gi

โดยไฟล์นี้จะทำการสร้าง pv กับ pvc เพื่อใช้เก็บข้อมูลของ MySQL โดยในการใช้งานจริงเราไม่ควรใช้ Storage ประเภท hostPath นะครับ เพราะมันจะทำให้เวลา Deploy เราจะต้องบังคับให้ Pod อยู่กับ Node ที่มี Volume อยู่เท่านั้น ไม่สามารถกระจายไป Node ต่างๆได้ ในงานจริงควรจะเป็นพวก nfs ครับ

สร้าง ConfigMap

สร้างไฟล์ mysql-configmap.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-configmap
data:
  MYSQL_ROOT_PASSWORD: "root"
  MYSQL_DATABASE: "wordpress_db"

เนื่องจากเราต้องการแยก config ออกจาก deployment เราจึงแยกออกมาเป็น ConfigMap โดยค่าที่อยู่ใน configMap คือ ENVIRONMENT ที่เราอยากจะเอาไป set ใน pod โดย Environment ที่เราจะ set คือ MYSQL_ROOT_PASSWORD (อันนี้คือตั้งค่า root password ) , MYSQL_DATABASE (อันนี้คือสร้าง database ชื่ออะไร)

สร้าง Deployment

สร้างไฟล์ mysql-deployment.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-pod
  labels:
    app: mysql-app   
spec:
  selector:
    matchLabels:
      app: mysql-app
  template:
    metadata:
      labels:
        app: mysql-app
    spec:
      containers:
      - name: mysql-app
        imagePullPolicy: Always
        image: mysql:5.7
        envFrom:
          - configMapRef:
              name: mysql-configmap
        ports:
        - containerPort: 3306
          name: mysql-port
        volumeMounts:
        - mountPath: /var/lib/mysql
          name: mysql-volume
      volumes:
        - name: mysql-volume
          persistentVolumeClaim:
            claimName: mysql-pvc

ไฟล์นี้ทำการสร้าง Deployment โดยใช้ environment จาก oonfigMap : mysql-configmap และทำการ mount volume ไปที่ /var/lib/mysql โดยใช้ volume จาก mysql-pvc

สร้าง Service

ทำการสร้างไฟล์ : mysql-service.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  selector:
    app: mysql-app
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
      nodePort: 32020
  type: NodePort

โดยไฟล์นี้ทำการสร้าง Service type NodePort โดยให้เข้าที่ port : 32020 จากนั้นลองตรวจสอบว่าสามารถใช้งาน

จากภาพผมใช้ตัว dbeaver เข้าไปตรวจสอบว่าสามารถใช้งาน MySQL ได้ไหมและมี Database ชื่อ wordpress_db ที่สั่งสร้างไหม ซึ่งปรากฏว่าดังที่สร้าง

สร้างส่วนที่เกี่ยวกับ WordPress

ในส่วนของ WordPress นั้นมีส่วนที่เราต้องสร้างดังต่อไปนี้

1. ส่วน Deployment เพื่อทำการสร้าง Pod
2. Service ที่ใช้เป็นตัวเปิดเส้นทางให้สามารถ Request ไปหา Pod ได้
3. ConfigMap เนื่องจากเราอยากแยก Config ออกจาก Deployment
4. Ingress เนื่องจากเราต้องการใช้งาน WordPress ผ่าน Port 80

ในส่วนของ Volume นั้นเราไม่ได้ใช้เพราะเราจะทำการ Save ข้อมูลลง MySQL ซึ่งเราสร้างไปแล้ว

สร้าง ConfigMap

สร้างไฟล์ wordpress-configmap.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10

apiVersion: v1
kind: ConfigMap
metadata:
  name: wordpress-configmap
data:
  WORDPRESS_DB_HOST: "mysql-service.default.svc.cluster.local"
  WORDPRESS_DB_USER: "root"
  WORDPRESS_DB_PASSWORD: "root"
  WORDPRESS_DB_NAME: "wordpress_db"
  WORDPRESS_TABLE_PREFIX: "wasinee_"

จากไฟล์เราสร้าง configMap โดยค่า configMap นี้จะเอาไปใช้เป็น Environment โดย Environment ที่เราตั้งค่าไว้จะเกี่ยวกับ Database เพราะ WordPress ต้องใช้ database หากสังเกตจะเห็นว่า WORDPRESS_DB_HOST นั้นเราชี้ไปหา service : mysql-service ที่เราสร้างโดยใช้ชื่อ service (ใครงงกลับไปอ่านตอน service นะครับ)

สร้าง Deployment

สร้างไฟล์ wordpress-deployment.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-deployment
  labels:
    app: wordpress-app   
spec:
  selector:
    matchLabels:
      app: wordpress-app
  template:
    metadata:
      labels:
        app: wordpress-app
    spec:
      containers:
      - name: wordpress-app
        imagePullPolicy: Always
        image: wordpress:6.3.1-apache
        envFrom:
          - configMapRef:
              name: wordpress-configmap
        ports:
        - containerPort: 80
          name: wordpress-port

โดยจากไฟล์จะเห็นว่าเราสร้าง wordpress โดยเอา environment จาก configMap : wordpress-configmap และเปิด port 80

สร้าง Service

สร้างไฟล์ wordpress-service.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: wordpress-service
spec:
  selector:
    app: wordpress-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32030
  type: NodePort

จากไฟล์เราจะทำการสร้าง service แบบ NodePort ที่ port 32030 แล้วชี้ไปที่ pod ที่มี label เป็น app = wordpress-app

ทำการทดลองเปิด Browser แล้วเข้า URL - http://<ip ของเครื่องที่ run>:32030 ของผมเป็น http://192.168.156.101:32030 ซึ่งเมื่อเปิดแล้วจะได้เป็นดังภาพ

จะเห็นว่าเราสามารถเปิด Wordpress ได้ (ไม่ต้องตกใจครับ มันคือหน้า install เนื่องจากเราเข้ามาครั้งแรก)

ส่วน Ingress

สร้างไฟล์ wordpress-ingress.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
spec:
  rules:
    - host: "wordpress-application.com" 
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: wordpress-service
              port:
                number: 80

สุดท้ายเป็นการสร้าง ingress ให้สามารถเข้าผ่าน port 80 ได้ โดยเราตั้งกฏว่าถ้าเข้ามาด้วย domain name : wordpress-application.com จะ route ไปที่ service : wordpress-service

เรามาทดสอบว่า ingress ว่าใช้งานได้ไหมโดยเปิด Browser ไปที่ : http://wordpress-application.com (อย่าลืม set file hosts ก่อนนะครับ)

ซึ่งจากภาพจะเห็นว่าเราสามารถเปิด wordpress ได้

ลองใช้งาน Wordpress เพื่อตรวจสอบ

ลองมาใช้งาน wordpress เพื่อทดสอบว่ามีปัญหาอะไรไหม โดยเราลองทำการ install และใช้งาน

จากนั้นลอง login ด้วย username , password ที่เราใส่ไปตอน install

ซึ่งเมื่อ Login เข้าไปแล้วจะเข้าไปหน้า Manage ดังภาพ

ซึ่งจากการทดลองเล่นนั้นไม่พบว่าติดปัญหาอะไร ซึ่งนั่นก็พอจะการันตีได้แล้วว่าเรา Deploy ตัว WordPress สำเร็จ

แล้วถ้าอยาก Deploy wordpress แบบนี้อีกหลายตัวล่ะ

ถ้าสมมติมีความต้องการ Deploy : wordpress อีกหลายๆตัวล่ะ เช่น บริษัท A , บริษัท B , บริษัท C wordpress ของละบริษัทต้องมี mysql ของตัวเอง domain name ของตัวเอง แล้วเราทำอะไรได้บ้าง

1. Copy File

ง่ายๆเลยก็คือเรา copy ไฟล์ที่เราสร้างทั้งหมดแล้วไปแก้ไฟล์ตามแต่ละบริษัทต้องการ วิธีนี้ก็ง่ายครับเราสามารถทำได้เลย แต่ปัญหาถ้าบริษัทที่ต้องการไม่ใช่ 3 บริษัทแต่เป็น 100 บริษัทล่ะจะเป็นยังไง แค่นึกภาพว่าต้อง copy ไฟล์ทุกไฟล์ที่ว่ามาแล้วไปไล่แก้แต่ละไฟล์ก็เหนื่อยแล้ว

2. ใช้ envsubst

เราจะใช้ envsubst ร่วมกับการใช้ environment เพื่อทำการ Deploy หลายๆ config

โดยเราจะใช้ envsubst กับค่าที่เปลี่ยนแปลงไปในแต่ละบริษัทตัวอย่างเช่น ตัวอย่างเช่น domain name โดยเราจะทำประมาณนี้

ทำการสร้างไฟล์ : wordpress-ingress-envsubst.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
spec:
  rules:
    - host: "$DOMAIN_NAME" 
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: wordpress-service
              port:
                number: 80

จากนั้นลองสั่ง

1
2

export DOMAIN_NAME=wasinee-application.com
envsubst < wordpress-ingress-envsubst.yaml

จากภาพจะเห็นว่าค่าของ DOMAIN_NAME ที่เรา set ไว้นั้นไปแทนที่ค่าที่ $DOMAIN_NAME ในไฟล์ wordpress-ingress-envsubst.yaml โดยหากเราจะใช้วิธีนี้เราต้องทำดังต่อไปนี้

1. สร้าง template file
2. สร้าง environment file
3. สร้าง script เพื่อทำการ deploy

สร้าง Template file

ทำการสร้างไฟล์ whoami-template.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      env:
        - name: "OWNER"
          value: "$OWNER"
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
spec:
  rules:
    - host: "$DOMAIN_NAME" 
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

จากไฟล์จะเห็นว่ามีการใช้ environment 2 ในไฟล์คือ

• OWNER : อันนี้มีไว้ set ใน whoami เพื่อใช้ดูว่าค่าถูก set จริงไหม และไปถูก Pod ไหม
• DOMAIN_NAME : อันนี้มีไว้ set domain name ไว้ใช้ตอน ingress

สร้าง environment file

สร้างไฟล์ company-a.sh และใส่ค่าตามด้านล่าง

1
2

export DOMAIN_NAME=company-a.com
export OWNER=company-a

สร้างไฟล์ company-b.sh และใส่ค่าตามด้านล่าง

1
2

export DOMAIN_NAME=company-b.com
export OWNER=company-b

ส่วนนี้คือการกำหนด environment ตามที่เราจะไปใช้กับ Template และ script โดยเราจะทำ 2 ไฟล์คือ company-a.sh กับ company-b.sh ซึ่งถ้าโดยไม่ต้องสน file extension มันคือไฟล์ config ดีๆนี่เอง

สร้าง script เพื่อทำการ deploy

สร้างไฟล์ deploy.sh

โดย script นี้ไม่มีอะไรมากคือทำการรับ parameter 1 ตัวเข้ามา ซึ่ง parameter ที่รับเข้ามาคือไฟล์ environment จากนั้นก็จะไปทำการ set environment ด้วยคำสั่ง source จากนั้นจะทำการเช็ค namespace ว่าเคยมีไหม ถ้าไม่มีจะทำการสร้าง (namespace ขอติดไว้ก่อน แต่มองว่า namespace เหมือนเป็นจักรวาลใน marvel ละกัน ถ้าอยู่คนละ namespace ถือว่าอยู่คนละจักรวาล ยุ่งเกี่ยวกันยากถ้าไม่ผ่านช่องทางที่กำหนด) จากนั้นทำการใช้คำสั่ง envsubst เพื่อแทนค่า environment ไปใน template และส่งผลลัพธ์นั้นไปให้คำสั่ง kubectl apply ทำงานต่อ

1
2
3
4
5
6
7
8
9
10
11
12

echo $1

# Set environment 
source $1

# ทำการสร้าง namespace ในกรณีที่ไม่มี namespace
if ! kubectl get ns $OWNER > /dev/null 2>&1; then
   kubectl create namespace $OWNER
fi

# ทำการเรียกใช้ envsubst เพื่อแทนค่า environment ลงไปในไฟล์ template จากนั้นส่งค่าไฟล์ที่ถูกแทนค่าแล้วไปให้คำสั่ง kubectl apply 
envsubst < whoami-template.yml | kubectl apply --namespace=$OWNER -f -

ลอง Deploy

ตัวอย่างไฟล์ทั้งหมดเกี่ยวกับการทำ template deploy สามารถดูได้ที่ : Link

เดี๋ยวผมจะทำตัวอย่างการ Deploy โดยใช้คำสั่งด้านล่าง

1
2
3
4
5

# deploy โดยใช้ environment config ของ company-a
bash deploy.sh company-a.sh

# deploy โดยใช้ environment config ของ company-b
bash deploy.sh company-b.sh

จากนั้นลองสั่งด้านล่างเพื่อเช็คว่าสามารถสร้าง pod และ service สำเร็จหรือไม่

1
2

kubectl get all --namespace company-a
kubectl get all --namespace company-b

ซึ่งจะเห็นว่ามีการสร้าง pod และ service ขึ้นมาทั้ง 2 namespace(จักรวาล) และสังเกตุจะเห็นว่าชื่อ pod และ service เหมือนกัน ซึ่งในกรณีที่เราทำแบบไม่กำหนด namespace มันจะไปอยู่ที่ default ซึ่งถ้ามีชื่อซ้ำกันมันจะทำการ update ดังนั้นถ้าอยากให้ชื่อซ้ำกันได้ก็ต้องแยกไปอยู่คนละ namespace (ลองเทียบในหนัง จักรวาล 616 มี Spider man ได้คนเดียว แต่จักรวาลอื่นก็มี Spider man ได้เหมือนกัน )

คราวนี้เรามาลองเปิด Browser แล้วเข้า URL ดังต่อไปนี้เพื่อเช็คว่า Ingress ทำงานได้ไหมและ Route ไปถูกเครื่องรึเปล่า (อย่าลืม set file hosts)

1
2

http://company-a.com/?env=true
http://company-b.com/?env=true

จากภาพจะเห็นว่า Ingress route ได้ถูกดูได้จากค่า OWNER ที่วงแดงไว้ ซึ่งตรงกับการ config ใน environment ของเรา

วิธีนี้ดียังไง

วิธีนี้ดีกว่าวิธีแก้ไฟล์ยังไง อย่างแรกคือคุณไม่ต้องตามไปแก้ไฟล์ yml ทุกไฟล์ คุณต้องทำการแก้แค่ไฟล์ environment config เพียงไฟล์เดียว ถ้าในตัวอย่างที่เราทำหากต้องเพิ่ม company-c เราก็แค่สร้างไฟล์ company-c.sh จากนั้นกำหนดค่าให้ไฟล์ environment config เท่านั้น แถมเวลาอัพเดทเกี่ยวกับการ Pod service ingress ต่างๆนาๆ เราสามารถแก้ที่ชุด template ที่เดียวเลย ไม่ต้องไปไล่แก้ทุกอันที่เคย Deploy (ถ้า Deploy ไปแล้ว 100 เจ้า แล้วจะเพิ่มอะไรสักอย่างแล้วต้องไปแก้ 100 เจ้า สยองขวัญน่าดู)

มีวิธีที่ดีกว่านี้ไหม

คำตอบคือมีครับ หากเราลองคิดดีๆการที่เราทำมันคือการทำงานเกี่ยวกับ Template processor แบบพวก PHP ที่สามารถใส่ตัวแปรไปใน HTML แล้วสั่ง rendering หรือ JSP และ Template engine อีกมากมาย โดยพวก Template engine พวกนี้จะมีลูกเล่นอีกมากมายที่สามารถทำได้ เช่น if else กับ template เช่น ถ้าค่า type เป็น VIP ให้ทำการใช้ template ส่วนนี้ด้วย หากไม่ใช่ให้ใช้ template ที่ไม่มีส่วนนี้ ซึ่งในงานจริงคุณต้องเจอมันแน่ๆ เช่น บริษัท W เป็นลูกค้าระดับ VIP ดังนั้นเขาต้องการการทำงานที่เร็วกว่าปกติ เราจึงต้องเอา REDIS มาทำ CACHE ในการดึงข้อมูล ดังนั้นจะต้องมี Pod ของ REDIS เพิ่มเข้ามา แต่เพิ่มเข้ามาแค่เฉพาะลูกค้าที่เป็น VIP ถ้าที่เราทำอยู่ตอนนี้น่าจะไม่พอในการทำแบบนั้น

แต่โชคดีครับที่ชาวโลกมีคนเห็นปัญหานี้เหมือนกันและได้สร้างสิ่งที่มาช่วยในการทำแบบนี้ซึ่งนั่นก็คือ HELM ซึ่ง HELM เนี่ยทำได้มากกว่าเป็น Template engine มันสามารถทำ version ของการ Deploy ได้ด้วย ประมาณว่าถ้าคุณทำตัว template deploy ใหม่ไปอัพเดทแล้วเกิดปัญหา คุณสามารถสั่งให้ helm เนี่ยกลับไปใช้ตัว deploy ก่อนหน้าที่ไม่มีปัญหาได้เลย

สรุป

สำหรับตอนนี้เราได้ลองทำโจทย์ Deploy Wordpress กันไปแล้ว ซึ่งจะเห็นว่าไม่ได้ยากมากเลย แถมเรายังได้รู้ปัญหาเกี่ยวกับ Deploy และทำให้เรามารู้จักกับ Tool ที่ใช้ตัว Deploy ที่เราจะไปเรียนรู้กันในตอนต่อไปซึ่งนั่นก็คือ HELM

Basic Kubernetes Part 6 - Ingress

ในการติดต่อกันระหว่าง Client Server ในชั้น Application Layer นั้นเราจะใช้ IP กับ Port ซึ่ง Protocol HTTP ใช้ port 80 , HTTPS ใช้ port 443 ทุกอย่างเหมือนไม่มีปัญหาอะไร แต่ปัญหาเกิดขึ้นเมื่อเครื่องเรา deploy application หลายๆ appliaction ซึ่งหลายๆ application นั้นใช้ protocol http , https ซึ่งเราไม่สามารถให้ 2 pod ใช้ Port เดียวกันได้ จะให้ใช้ Port แบบ 32010 , 32020 ก็ไม่สะดวกเพราะ คนใช้งานต้องกำหนด Port มาใน URL ซึ่งน่าจะสร้างความลำบากให้ผู้ใช้น่าดู

ถ้าเป็นการ Deploy แบบไม่ใช่ k8s นั้นเรามีวิธีทำคือ เราก็สร้าง Reverse proxy (nginx , apache) ขึ้นมาแล้ว Run บน Port 80 , 443 จากนั้นก็ให้มันรับ Request แล้ว routing ตามกฏไปหา Application ที่ต้องการ

คราวนี้ถ้าเราอยากทำแบบนี้บน k8s ล่ะจะทำยังไง จากความรู้ที่เรามีเราไม่สามารถทำได้ เพราะตอนเราสร้าง service แบบ NodePort ไม่สามารถตั้งค่า Port เป็น 80 , 443 ได้ ดังนั้นเราไม่สามารถเอา nginx หรือ apache ไปวางได้ แล้วเราจะทำยังไงล่ะ

จากความต้องการแบบนี้ตัว k8s ได้กำหนดสิ่งที่เรียกว่า Ingress ขึ้นมามาให้เราเพื่อทำตามความต้องการที่อยากได้ โดย Ingress นี้เป็นแค่ Spec ของ Configfile เท่านั้นไม่มีตัวที่ทำงานจริง ตัวที่ทำงานจริงคือ Ingress controller ซึ่ง Ingress controller มีให้เราใช้มากมายตัวอย่างเช่น

• NGINX
• Traefik
• contour

โดยใครอยากใช้ Ingress controller ตัวไหนก็ลองเข้าไปดูวิธี Install ที่ Document ของแต่ละเจ้าได้เลย ส่วนใครที่ใช้ VM ของผมนั้น ตัว k3s เขาลงตัว Traefik Ingress controller มาให้แล้ว ดังนั้นไม่ต้องลงเพิ่มนะครับ

ลองสร้าง Ingress กัน

ตัวอย่างไฟล์ Config สามารถได้ดูได้ที่ Link

เตรียม Application (Pod)

อันดับเแรกมาทำการสร้าง Application (Pod) บน k8s กันก่อน โดยสร้างไฟล์ : nginx-whoami-app.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.25.1
          ports:
            - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
spec:
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      name: whoami-pod
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami-container
          image: traefik/whoami
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32010
  type: NodePort
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32020
  type: NodePort

จากนั้นทดสอบเปิด Browser แล้วเข้าไปที่ URL

• http://<ip ที่ run k8s>:32010 (ของผมคือ http://192.168.156.101:32010)
• http://<ip ที่ run k8s>:32020 (ของผมคือ http://192.168.156.101:32020)

จากภาพจะเห็นว่าเราสามารถเข้าถึง nginx ผ่าน port 32010 และ whoami ผ่าน port 32020

Set file host

เนื่องจากเราไม่ได้จด Domain name : nginx-application.com และ whoami-application.com ไว้ (ต่อให้จดได้ก็จะไม่ได้ ip ตรงกันเพราะแต่ละเครื่องที่ run k8s มี ip ไม่เหมือนกัน) ดังนั้นจะไม่สามารถ resolve domain name ได้ แต่เราสามารถแก้ปัญหานี้ได้โดยการกำหนดค่าในไฟล์ : hosts ซึ่งไฟล์ host นี้แต่ละ os อยู่ไม่เหมือนกัน โดยแต่ละ os ไฟล์จะอยู่ที่

• windows : c:\Windows\System32\Drivers\etc\hosts
• linux : /etc/hosts
• macOs : /private/etc/hosts

เมื่อเปิดไฟล์ให้และเพิ่มข้อมูลลงไปคือ

1
2

<ip เครื่องที่ run k8s> nginx-application.com
<ip เครื่องที่ run k8s> whoami-application.com

ซึ่งของผมจะได้เป็น

1
2

192.168.156.101 nginx-application.com
192.168.156.101 whoami-application.com

ทำการทดสอบลองใช้คำสั่ง ping ไปที่ nginx-application.com , whoami-application.com ว่าทำการ resolve ip เป็น ip ที่ตั้งไว้หรือไม่

1
2

ping nginx-application.com
ping whoami-application.com

สร้าง Ingress

สร้างไฟล์ basic-ingress.yml จากนั้นสั่ง apply file

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  rules:
    - host: "nginx-application.com" 
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: nginx-service
              port:
                number: 80
    - host: "whoami-application.com"
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: whoami-service
              port:
                number: 80

จากนั้นลอง get และ describe ingress ดูครับ

จากภาพจะเห็นว่ามี Ingress ชื่อ basic-ingress ขึ้นมาและมีการบอก host และ path ซึ่งตรงกับที่เรากำหนดในไฟล์ อีกทั้งมีชื่อ service คือ nginx-service , whoami-service

จากนั้นลองเข้า browser แล้วเปิด URL

• nginx-application.com
• whoami-application.com

จากภาพจะเห็นว่าสามารถเปิดหน้าได้ตรงตามความต้องการของเราคือ เข้า nginx-application.com ก็ไปหา nginx เข้า whoami-application.com ก็ไปหา whoami ซึ่งนั่นแปลว่า Ingress ของเราทำงานได้ตรงตามความต้องการของเราแล้ว

อธิบายไฟล์ basic-ingress.yml

ในส่วนของ apiVersion , kind , metadata ไม่ขอลงรายละเอียดเพราะเหมือนกับตัวอื่นๆที่ผ่านมา

rules

ตรงนี้จะเป็นการประกาศเกี่ยวกับ rule (มีได้หลาย rule) ที่ใช้ในการ route ของ Ingress (Reverse Proxy) ถ้าเทียบง่ายๆก็เหมือน file nginx.conf ของ nginx ที่เรากำหนดว่ามาด้วย host นี้จะให้ส่งไปที่ไหนต่อ โดย rule จะเป็นไปตามรายละเอียดต่อไปนี้

1
2
3
4
5
6
7
8
9
10

- host: "nginx-application.com" 
  http:
    paths:
    - path: /
        pathType: Prefix
        backend:
        service:
            name: nginx-service
            port:
            number: 80

host

ตรงส่วนนี้จะเป็นการบอกกฏว่า request ที่มาต้องมีค่า host ตรงกับ nginx-application.com

http

ตรงนี้เป็นการบอกว่าถ้าเป็น protocol http

paths

ตรงนี้จะเป็นการบอกต่อว่าเมื่อเข้ามาด้วย http แล้วจะใช้ path อะไรในการ map (มีได้หลาย path)

path

1
2
3
4
5
6
7

- path: /
    pathType: Prefix
    backend:
    service:
        name: nginx-service
        port:
        number: 80

ตรงนี้จะเป็นการบอกรายละเอียดแล้วว่าต้องตรงด้วย path อะไร ลักษณะของการ map เป็นแบบไหน ถ้า map ตรงแล้วจะให้ยิงไปที่ service ไหน port อะไร

จากตัวอย่างจะเป็นการว่า ถ้า map ที่ path : / การ map เป็นแบบ Prefix คือถ้าขึ้นต้นด้วย / จะถือว่าตรงตามเงื่อนไขหมด ซึ่งถ้าตรงตามเงื่อนไขทั้งหมดเนี่ยให้ route request นี้ไปหา service : nginx-service ที่ port 80

สรุปการ config rule

1
2
3
4
5
6
7
8
9
10

- host: "nginx-application.com" 
  http:
    paths:
    - path: /
        pathType: Prefix
        backend:
        service:
            name: nginx-service
            port:
            number: 80

rule นี้มีความหมายคือ request ที่ยิงเข้ามามีค่า host == nginx-application.com แล้วมี path ที่ขึ้นต้นด้วย / จะถูก route request ไปที่ nginx-service port 80

สิ่งที่ต้องอ่านเพิ่มเติม

การตั้งค่าเพิ่มเติม Ingress Controller

ที่อยู่ในตัวอย่างทั้งหมดของเรานั้นเป็น Ingress กลางๆที่ k8s กำหนดขึ้นให้ใช้ได้กับทุก IngressController ซึ่ง Rule ที่ตั้งได้นั้นมีจำกัดมากๆแค่ host กับ path จะ route ด้วยเงื่อนไขอื่นๆ เช่น header ที่เรากำหนดเป็นต้น หรือ เวลา Route แล้วให้เราทำการแก้ไข path เพิ่ม header ที่ต้องการ อันนี้ไม่สามารถทำได้ผ่านการประกาศแบบนี้

แต่ถามว่าทำได้ไหม ก็ต้องบอกว่าสามารถทำได้ครับ แต่ต้องเพิ่มการประกาศตาม Ingress controller ที่คุณเลือกใช้ เช่น

• Nginx : เราสามารถใช้ Feature ต่างๆแบบที่ nginx reverse proxy ทำได้แต่ต้องประกาศในส่วนของ Annotation โดยสามารถดูรายละเอียดการ config ได้ที่ Link
• Traefik : ถ้าอยากใช้ Feature ที่มากกว่าที่ k8s กำหนดต้องประกาศตัว IngressRoute ของ Traefik เพิ่ม โดยสามารถดูรายละเอียดการ config ได้ที่ Link และดู Annotation ได้ที่ Link
• Contour : ตัวนี้จะคล้ายๆกับตัว Traefik ที่ต้องทำการประกาศ Ingress ของตัว Contour เองเพื่อใช้ Feature ของ Contour โดยสามารถดูรายละเอียดการ Config ได้ที่ Link

การ Set ssl ให้กับ Ingress

ในตัวอย่างที่เราได้ทดลองนั้น เราทดลองสร้าง Ingress ที่เป็นแบบ http แต่ในการทำงานจริงๆนั้นคนที่ใช้งานจริงๆนั้นใช้งานแบบ https นั้นจะต้อง set อย่างไร โดยสามารถดูรายละเอียดการ setting ได้ที่ : Link

สรุป

สำหรับตอนนี้เราได้ทำความรู้จักกับ Ingress ว่าคืออะไร เอาไปใช้อะไรกับกรณีไหน rule ที่เราพอตั้งให้ได้คืออะไร ซึ่งถ้าใครอ่านมาตั้งแต่ตอนแรกจนถึงตอนนี้ก็น่าจะสามารถ Deploy application ขึ้น k8s ไปใช้งานได้แล้ว (แต่ไม่ได้ดีมาก และไม่ถูกต้องตาม best practice ) แต่อ่านอย่างเดียวอาจจะไม่เข้าใจ ตอนหน้าเรามาลองทำการ Deploy application สักตัวกันว่าถ้าต้องทำโจทย์แบบนี้แล้วเราต้องทำอะไรบ้าง

Basic Kubernetes Part 5 - ConfigMap และ Secret

ตอนนี้เรามาทำความทำความรู้จัก ConfigMap และ Secret กันว่าคืออะไร

รูปแบบการ Config ที่เป็นที่นิยม

สิ่งหนึ่งที่ขาดไม่ได้ของ Application คือการ Configuration เช่น nginx ต้องทำการ Config เปลี่ยน Endpoint ของ Reverse proxy หรือตัว Application เองต้องการกำหนดตัว Connection Pool ของ Database ให้มากขึ้นหรือลดลง หรือ แก้ไข Maximum file size ที่จะ Upload เข้ามาใน Application การ Config

Application นั้นนิยมทำการ Config ผ่านไฟล์ แต่ในปัจจุบันที่ใช้ Container กันนั้นเปลี่ยนมา Config ผ่านตัว Environment แทน เนื่องจากเราไม่อยากเข้าไปยุ่งกับตัว Volume เพราะเมื่อไหร่ที่ยุ่งกับ Volume จะมีข้อจำกัดต่างๆ เช่น Volume นี้ต้อง Mount จากไหน อ่านได้จากกี่ Node แต่ถ้าเป็น Environment นั้น ตัวสร้างสามารถกำหนดค่า Environment ผูกไปกับ Container ตอนสร้างได้เลย ซึ่งจะไป Run ที่ Node ก็ได้ ดังนั้นการ Config ผ่าน Environment จึงเป็นที่นิยม

เพื่อให้ทำการ Config ทั้ง 2 แบบได้ ทาง k8s ก็ได้ทำการสร้างสิ่งอำนวยความสะดวกในการทำการ Config ขึ้นมาซึ่งนั่นก็คือ ConfigMap โดย ConfigMap นั้นสามารถ Mount volume ไปเป็น File ได้และความพิเศษของมันก็คือมันสามารถถูกเข้าถึงได้จากทุก Node ใน Cluster ของ k8s ดังนั้น ConfigMap จึงแก้ปัญหาการ Config แบบ File ได้

ConfigMap คืออะไร

ConfigMap คือ Object แบบ KeyValue ที่ตัว Pods สามารถเข้าถึงและเอาไปเป็น Environment เอาไป Mount Volume เป็นไฟล์ (นิยามเต็มไปอ่านที่ : Link )

ตัวอย่างไฟล์ Configuration ทั้งหมดในตอนนี้อยู่ที่ Link

สร้าง ConfigMap กัน

สร้างไฟล์ basic-configmap.yml

1
2
3
4
5
6
7
8

apiVersion: v1
kind: ConfigMap
metadata:
  name: basic-configmap
data:
  config1: "data config 1"
  config2: "data config 2"
  CONFIG_DATABASE: "EXAMPLE CONFIG"

จากนั้นสั่ง apply และลอง get และ describe ตัว configMap ดู

จะเห็นว่ามี ConfigMap ที่เราสร้างโผล่ขึ้นมาและเมื่อ Describe ดูค่าแล้วเราจะเห็นค่าที่เรากำหนดไว้กับ key ต่างๆเลย เช่น key : config1 มี value : data config 1

อธิบายไฟล์ basic-configmap.yml

ส่วนของ apiVersion , kind , metadata ไม่ขออธิบายนะครับเพราะเหมือนกับ Pod , Deployment , Service

data

ตรงนี้จะเป็นการประกาศ Key , Value ของ ConfigMap โดยตัวอย่างจะเป็น

1
2
3

config1: "data config 1"
config2: "data config 2"
CONFIG_DATABASE: "EXAMPLE CONFIG"

ซึ่งหมายความว่า key : “config1” มี value : “data config 1” key : config2 มี value : “data config 2” โดยเราสามารถประกาศตัว key value ได้ตามใจเพียงค่าอย่าให้ key ซ้ำกันก็พอ

เอา ConfigMap ไปเป็น Environment

จากตัวอย่างที่เราทำมาเราจะทำการ set environment ของ Pod ผ่านตรง env เช่นตัวอย่างด้านล่าง

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      env:
        - name: config1
          value: "data config 1"
        - name: config2
          value: "data config 2"
        - name: CONFIG_DATABASE
          value: "EXAMPLE CONFIG"

ซึ่งถ้า Config env มันเยอะตรงนี้มันก็จะดูมากมายเต็มไปหมด เวลา Config อะไรก็ต้องมาแก้การ Define Pod ตลอด ดังนั้นถ้าเราแยกส่วน Config ออกมาเวลาแก้ไขก็แก้ที่ Config เลยน่าจะดีกว่า (ทีม Config จะได้ยุ่งแค่ Config ไฟล์เดียวไม่ต้องมายุ่งกับการประกาศ Pod ) ซี่งเราสามารถทำได้โดยประกาศแบบนี้

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# whoami-pod-002.yml
apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      envFrom:
        - configMapRef:
            name: basic-configmap

เพื่อให้ง่ายต่อการเช็ค Environment ผมขอใช้ตัว image : whoami เพราะมันมี api ให้เรายิงไปดู Environment ที่ถูก set ไว้ให้กับ container ได้ (สามารถดูรายละเอียดได้ที่ : Link ) ดังนั้นผมขอสร้าง Service เพื่อเรียกผ่าน Browser นะครับ จะได้ไม่ต้องมานั่ง Describe ตัว Pod หา IP แล้วยิง

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# whoami-service.yml
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32020
  type: NodePort

ให้เราเปิด Browser แล้วเปิด URL : http://<ip ของเครื่องที่ run k8s>:32020/api?env=true (ของผมเป็น http://192.168.156.101:32020/api?env=true)

จากภาพจะเห็นว่าเมื่อยิงไปจะได้ json response กลับมาจะมีส่วนที่เป็น environment กลับมาดังภาพ ซึ่งนั่นแปลว่าตัว Pod whoami ถูก Set environment จาก ConfigMap จริงๆ

อธิบายไฟล์ whoami-pod-002.yml

ในไฟล์นี้จะมีส่วนที่เพิ่มเติมมาคือ envFrom

envFrom

ตรงส่วนนี้จะเป็นการบอกว่าจะเอา Environment มาจากไหน

1
2
3

envFrom:
  - configMapRef:
      name: basic-configmap

โดยจากตัวอย่างเนี่ยเราบอกว่าให้เอามาจาก configMap โดยบอกจาก keyword : configMapRef โดยเอามาจาก ConfigMap ชื่อ basic-configmap ซึ่งการประกาศแบบนี้คือเอาทุกค่าใน ConfigMap มาใส่ในนี้เลย

อยาก Set แค่บาง Environment ล่ะ

ในส่วนที่แล้วเราลอง Set environment ผ่าน ConfigMap ซึ่งเป็นการเอามาใส่ทั้ง ConfigMap แต่บางกรณีเราไม่อยากเอาค่าทุกค่าจาก ConfigMap ไปเป็น environment เราอยากได้แค่บางค่าเราจะทำยังไง แน่นอนว่านี่คือปัญหาทั่วไปที่ทุกคนอยากได้ซึ่ง k8s ก็ทำให้เราสามารถทำแบบนั้นได้ครับ โดยทำแบบนี้

ทำการสร้างไฟล์ : whoami-pod-003.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# whoami-pod-003.yml
apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      env:
        - name: "OWNER"
          value: "WASINEE"
        - name: "CONFIG_DATABASE_FOR_CONNECTION"
          valueFrom:
            configMapKeyRef:
              name: "basic-configmap"
              key: "CONFIG_DATABASE"

จากนั้นสั่งคำสั่งด้านล่างและเปิด Browser และใส่ url เดิมลงไป

1
2
3

# สั่งเพื่อลบ pod ตัวเก่าทิ้งไป
kubectl delete whoami-pod
kubectl apply -f whoami-pod-003.yml

จากภาพจะเห็นว่า Environment ถูก Set แค่ค่าที่ต้องการจริงๆคือ OWNER (อันนี้ประกาศแบบธรรมดา) กับ CONFIG_DATABASE_FOR_CONNECTION (อันนี้ประกาศแบบใหม่)

อธิบายไฟล์ whoami-pod-003.yml

จากไฟล์เราจะเห็นตัวอย่างมีการประกาศ evironment แบบใหม่คือ

1
2
3
4
5

- name: "CONFIG_DATABASE_FOR_CONNECTION"
  valueFrom:
    configMapKeyRef:
      name: "basic-configmap"
      key: "CONFIG_DATABASE"

valueFrom

ตรงนี้เป็นการบอกว่าค่า Value นั้นให้ไปเอามาจากไหนซึ่งตรงนี้ประกาศว่า configMapKeyRef ซึ่งแปลว่าเอามาจาก configMap ส่วนด้านในส่วน name , key นั้นเป็นการบอกว่า ConfigMap ชื่ออะไร และ key ที่จะให้เอาค่าคืออะไร จากตัวอย่างก็คือไปเอาค่าจาก ConfigMap ชื่อ basic-configmap และ key ชื่อ CONFIG_DATABASE

เอา ConfigMap ไป Mount volume เป็นไฟล์

ในตอนต้นเรารู้แล้วว่า Applicaiton นิยม Config ด้วยไฟล์ แต่ปัญหาเมื่อเอามาใช้กับ k8s คือมันต้องทำการ Mount volume ซึ่งก็จะมีปัญหาเรื่องอ่านเขียนได้จากกี่ Node เวลาแก้ไข Config ต้องไปแก้ที่ Volume ตรงไหน เพื่อแก้ปัญหานั้น k8s จึงทำให้เราสามารถ Mount ตัว ConfigMap ไปเป็น Volume ได้ โดยตัวอย่างนี้ผมจะสร้าง ConfigMap ที่มีค่าเป็นไฟล์ HTML และ Mount volume ไปใน nginx ซึ่งเมื่อเราเรียกผ่าน Browser จะต้องแสดงผลแบบไฟล์ HTML ของเรา

สร้างไฟล์ nginx-configmap.yml จากนั้นสั่ง apply

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configmap
data:
  indexFile: |
    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>HELLO WORLD</title>
    </head>
    <body>
        <h1>HELLO WORLD</h1>
    </body>
    </html>
  wasineeFile: |
    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>HELLO WASINEE</title>
    </head>
    <body>
        <h1>HELLO WASINEE</h1>
    </body>
    </html>

จากไฟล์ที่เราประกาศจะเห็นว่าเราใช้เครื่อง “|” ซึ่งเครื่องหมายนี้เป็นการบอกว่าจะค่าที่จะ config นั้นมีหลายบรรทัด โดยในไฟล์นี้เราสร้าง configMap ที่มี 2 key คือ indexFile , wasineeFile

สร้างไฟล์ nginx-pod.yml จากนั้น apply ไฟล์

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx-container
      image: nginx:1.25.1
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nginx-volume
  volumes:
    - name: nginx-volume
      configMap:
        name: nginx-configmap
        items:
        - key: "indexFile"
          path: "index.html"
        - key: "wasineeFile"
          path: "wasinee.html"
---
# ตรงนี้แค่ประกาศ Service เพื่อไว้ใช้เปิดเข้ามาดูผ่าน Browser ได้
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32030
  type: NodePort

จากนั้นเราเปิด Browser แล้วเข้า URL :

• http://<ip ของเครื่อง run k8s>:32030/index.html (ของผมเป็น http://192.168.156.101:32030/index.html)
• http://<ip ของเครื่อง run k8s>:32030/wasinee.html (ของผมเป็น http://192.168.156.101:32030/wasinee.html)

ซึ่งจะเห็นว่า nginx นั้นแสดงผลไฟล์ index.html เหมือนกับค่าใน configMap key : indexFile และ wasinee.html นั้นแสดงผลตรงกับค่าใน configMap key : wasineeFile

อธิบายไฟล์ nginx-pod.yml

ไฟล์นี้จะคล้ายๆไฟล์ nginx-use-pvc.yml แต่ต่างกันตรงการประกาศ volume

1
2
3
4
5
6
7
8
9

volumes:
  - name: nginx-volume
    configMap:
      name: nginx-configmap
      items:
      - key: "indexFile"
        path: "index.html"
      - key: "wasineeFile"
        path: "wasinee.html"

โดยอันนี้เราจะเปลี่ยนจาก persistentVolumeClaim มาเป็น configMap แทน

name

ตรงนี้เป็นการบอกว่าเราจะใช้ configMap ชื่ออะไรในการ Mount volume

items

ตรงนี้เป็นการบอกว่าจะเอา key ไหนไปเป็นไฟล์อะไรบ้างและเอาไปเป็นไฟล์วางไว้ในที่ไหน โดยจากตัวอย่าง เราจะเอา key: indexFile ไปเป็นไฟล์ index.html และ key : wasineeFile ไปเป็นไฟล์ wasinee.html

Secret คืออะไร

ถ้ามองแบบง่ายๆมันก็คือ ConfigMap นั่นแหละครับ แต่เป็น ConfigMap ที่มีการปกป้องไม่ให้สามารถอ่านออกได้แบบตรงๆ (ระดับง่ายสุดคือ base6
4) Secret เหมาะที่จะใช้กับอะไรที่ต้องการเป็นความลับ เช่น password , token , private key เป็นต้น (สามารถอ่านนิยามที่ถูกต้องได้ที่ : Link)

ลองสร้าง Secret

ทำการสร้างไฟล์ basic-secret.yml

1
2
3
4
5
6
7
8

apiVersion: v1
kind: Secret
metadata:
  name: basic-secret
type: Opaque
data:
  username: d2FzaW5lZQ==  # Base64-encoded username raw is : wasinee
  password: UEBzc3cwcmQ=  # Base64-encoded passwor  raw is : P@ssw0rd

จากนั้นสั่ง apply และทำการ get และ describe ดู secret

จากภาพจะเห็นว่ามันแสดงผลคล้ายๆกับ configMap เลยคือมี key ให้รู้ว่า secret นี้มี key อะไรบ้าง เพียงแต่เราไม่สามารถเห็นค่า value : secret ได้เหมือนกับ configMap ก็เท่านั้น

อธิบายไฟล์ basic-secret.yml

ในส่วนของ apiVersion , kind , metadata ผมขอไม่พูดนะครับเพราะเหมือนกับ pod , deployment , configMap จะพูดตรง type ลงไป

type

ตรงนี้เป็นการบอกว่า Secret นี้เป็น type อะไร โดย Opaque เป็น type basic ของ secret ตัว type มีอีกมากมายสามารถดูได้ที่ https://kubernetes.io/docs/concepts/configuration/secret/#secret-types

data

ส่วนนี้เป็นการประกาศ key กับ value โดย value จะต้องเป็นค่าที่ถูก Base64 ไว้ครับ

เอา Secret ไปเป็น Environment

ในเมื่อ configMap สามารถเอาไปผูกเป็น Environment ได้ secret ก็น่าจะต้องเอาไปใช้เป็น Environment ได้

** ทำการลบ whoami-pod และ whoami-service ทิ้งก่อนนะครับ

สร้างไฟล์ whoami-pod-004.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      envFrom:
        - secretRef:
            name: basic-secret
---
# ส่วนนี้ประกาศ Service เฉยๆ
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32020
  type: NodePort

จากนั้นทำการ apply file และเปิด Browser แล้วเปิด URL : http://<ip ของเครื่องที่ run k8s>:32020/api?env=true (ของผมเป็น http://192.168.156.101:32020/api?env=true)

จากภาพจะเห็นว่าค่า username , password นั้นเอามาจาก secret: basic-secret

อธิบายไฟล์ : whoami-pod-004.yml

จากไฟล์จะเห็นว่าส่วนที่แตกต่างไปจากเดิมคือ envFrom

envFrom

ตรงส่วนนี้คือบอกว่าจะเอา env มาจากไหน โดย secretRef คือบอกว่าให้เอาจาก secretRef ซึ่งในตัวอย่างคือ secret ชื่อ basic-secret

1
2
3

envFrom:
  - secretRef:
      name: basic-secret

อยาก Set ค่าแค่บาง Environment จาก Secret ล่ะ

หัวข้อนี้เหมือนกับ configMap เลยคืออยาก set : environment แค่บางค่าจาก Secret ล่ะทำยังไง

** ทำการลบ whoami-pod และ whoami-service ทิ้งก่อนนะครับ

สร้างไฟล์ : whoami-pod-005.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apiVersion: v1
kind: Pod
metadata:
  name: whoami-pod
  labels:
    app: whoami
spec:
  containers:
    - name: whoami-container
      image: traefik/whoami
      ports:
        - containerPort: 80
      env:
        - name: "OWNER"
          value: "WASINEE"
        - name: "CONFIG_DATABASE_PASSWORD"
          valueFrom:
            secretKeyRef:
              name: "basic-secret"
              key: "password"
---
# ส่วนนี้ประกาศ Service เฉยๆ
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32020
  type: NodePort

จากนั้นทำการ apply file และเปิด Browser แล้วเปิด URL : http://<ip ของเครื่องที่ run k8s>:32020/api?env=true (ของผมเป็น http://192.168.156.101:32020/api?env=true)

จากภาพจะเห็นว่าค่า Environment : CONFIG_DATABASE_PASSWORD มาจาก basic-secret ที่ key : password

อธิบายไฟล์ : whoami-pod-005.yml

จากตัวอย่างจะเห็นว่าที่แตกต่างจาก configMap คือ valueFrom ที่กำหนดเป็น secretKeyRef

secretKeyRef

1
2
3
4
5

- name: "CONFIG_DATABASE_PASSWORD"
  valueFrom:
    secretKeyRef:
      name: "basic-secret"
      key: "password"

จากตัวอย่างจะเห็นว่าเราบอกว่าเราจะเอาค่าจาก secret ชื่อ basic-secret ที่ key : password ไปเป็น environment ชื่อ CONFIG_DATABASE_PASSWORD

เอา Secret ไป Mount volume เป็นไฟล์

Secret นั้นแทบจะเหมือนกับ ConfigMap ซึ่งตัว ConfigMap สามารถ Mount volume ได้ ดังนั้น Secret ก็น่าจะต้อง Mount volume ได้เช่นกัน

** ทำการลบ nginx-pod และ nginx-service ทิ้งก่อนนะครับ

สร้างไฟล์ : nginx-use-secret.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx-container
      image: nginx:1.25.1
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nginx-volume
  volumes:
    - name: nginx-volume
      secret:
        secretName: basic-secret
        items:
        - key: "username"
          path: "index.html"
---
# ส่วนนี้ประกาศ Service เฉยๆ
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32030
  type: NodePort

สั่ง apply ไฟล์ จากนั้นเราเปิด Browser แล้วเข้า URL : http://<ip ของเครื่อง run k8s>:32030/index.html (ของผมเป็น http://192.168.156.101:32030/index.html)

ซึ่งจากภาพจะเห็นว่าจะได้คำว่า wasinee โผล่ขึ้นมาที่หน้าจอ ซึ่งตรงกับค่า basic-secret ที่ key : username

อธิบายไฟล์ : nginx-use-secret.yml

จากไฟล์จะเห็นส่วนที่แตกต่างจาก configMap คือตรงประกาศ volume นั้นประกาศด้วย secret

secret

1
2
3
4
5
6
7

volumes:
  - name: nginx-volume
    secret:
      secretName: basic-secret
      items:
      - key: "username"
        path: "index.html"

จากตัวอย่างจะเห็นว่าเราประกาศบอกว่า volume นี้เอามาจาก secret โดยบอกว่าเอามาจาก secretName ชื่อ basic-secret และเอา key username ไปเป็นไฟล์ index.html ดังนั้นค่า wasinee ที่อยู่ที่ key : username เลยไปกลายเป็นไฟล์ index.html อย่างที่เราทดลอง

สรุป

สำหรับตอนนี้เราได้รู้ว่า ConfigMap กับ Secret คืออะไร ได้รู้วิธีการประกาศ การนำไปใช้เป็น environment และนำไป mount volume เป็นไฟล์ สำหรับตอนต่อไปเราจะไปดูเกี่ยวกับ ingress กันครับ

Basic Kubernetes Part 4 - สร้าง Volume ให้ Pod ใช้

3 ตอนที่ผ่านมาเราได้เรียนรู้การสร้าง Pod สร้าง Network เข้าไปหา Pod สิ่งที่เรายังขาดคือการ Disk หรือ Volume ที่ให้ตัว Pod (Application) ของเราใช้งานในการเขียนไฟล์ อ่านไฟล์ วางไฟล์ config ตัวอย่างของ Pod (Application) ที่จำเป็นต้องใช้ Database ที่ต้องใช้ Disk หรือ Volume ในการเก็บข้อมูล

ตัวอย่างไฟล์ Configuration ทั้งหมดในตอนนี้อยู่ที่ Link

Persistent Volume : PV

Persistent Volume หรือเรียกสั้นๆว่า PV นั้นคือ Volume ที่เราแจ้งให้ k8s ทราบว่า k8s สามารถเอาไปใช้งานได้ เหมือนกับเราต้องการเอา Hard disk (สมัยนี้อาจจะเป็น SSD หมดแล้ว) มาใช้งาน เราก็ต้องแจ้งกับ OS ว่า Hard disk ของเราต่ออยู่กับช่องไหน

ลองสร้าง Persistent Volume กัน

ทำการสร้าง Folder ชื่อ nginx-volume จากนั้นสร้างไฟล์ index.html ขึ้นมา

1
2
3
4
5
6
7
8
9
10
11
12

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>HELLO WORLD</title>
</head>
<body>
    <h1>HELLO WORLD</h1>
</body>
</html>

สร้างเสร็จแล้วจะได้โครงสร้าง Folder แบบนี้

1
2
3

.
├── nginx-volume
    └── index.html

ออกมาจาก Folder nginx-volume จากนั้นสร้างไฟล์ basic-pv.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nginx-pv
spec:
  storageClassName: nginx-volume
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: <"Path ไป Folder nginx-volume">
    
    # ตัวอย่าง
    # ของผมว่าง nginx volme อยู่ที่ /root/test-pod/part4/nginx-volume ข้อมูลเลยเป้นด้านล่าง
    # path: /root/test-pod/part4/nginx-volume

จากนั้นสั่ง apply ตัวไฟล์ basic-pv.yml จากนั้นสั่งด้านล่างเพื่อดูรายละเอียดของ Persistent Volume

1
2

kubectl get pv
kubectl descrbie pv nginx-volume

อธิบายไฟล์ basic-pv.yml

ในส่วนของ apiVersion , kind , metadata ขอไม่อธิบายนะครับ เพราะเหมือนกับ pod , service , deployment จะขออธิบายในส่วนของ spec

storageClassName

ส่วนนี้เป็นการบอกว่า volume นี้อยู่ในประเภทไหน โดย storageClassName จะถูกเอาไปใช้ใน map เพื่อเอา volume ไปใช้งาน ซึ่งค่านี้สามารถตั้งเป็นอะไรก็ได้ ผมตั้งชื่อมันว่า nginx-volume

capacity

เป็นการบอกว่า Volume นี้มีขนาดเท่าไหร่ จากตัวอย่างของผมประกาศไว้ว่ามีขนาด 2 GB

accessModes

ส่วนนี้เป็นการบอกว่า Volume นี้สามารถเข้าถึงจาก Node ใน k8s cluster ( k8s สามารถทำให้มีหลายๆเครื่องทำงานร่วมกันได้ ดังนั้น 1 cluster สามารถมีหลายเครื่องทำงานร่วมกันได้ โดยเราจะเรียกเครื่องใน k8s cluster ว่า Node ) รูปใดบ้าง โดยตอนนี้มี 3 แบบ

• ReadWriteOnce : สามารถอ่านเขียนได้จาก Node เดียวใน k8s cluster

• ReadOnlyMany : สามารถอ่านได้อย่างเดียวจากทุก Node ใน k8s cluster

• ReadWriteMany : สามารถอ่านเขียนได้จากทุก Node ใน k8s cluster

ตัวอย่างเรา Set เป็น ReadWriteOnce

hostPath

ส่วนนี้เป็นการบอกว่า Volume นี้เป็นแบบใช้ไฟล์บนเครื่อง Node นั้นโดยบอกว่า path บนเครื่องคือ path ไหน โดยในตัวอย่างของผมคือ /root/test-pod/part4/nginx-volume

Persistent Volume Cliam : PVC

ในส่วนของ Persistent Volume นั้นเป็นประกาศให้ k8s ทราบว่ามี Volume พร้อมให้ใช้งาน แต่คงมีปัญหาแน่นอนถ้ามีหลายที่พยายามใช้ Volume เดียวกัน เช่น Volume นี้ถูกใช้งานจาก MYSQL และ MongoDB ดังนั้นเพื่อให้ Volume ถูกเอาไปใช้งานและไม่เกิดแย่งกันจึงต้องมีการประกาศสิ่งที่เรียกว่า Persistent Volume Cliam เพื่อบอกว่า Volume ตรงนี้ชั้นจองไว้นะ

ลองสร้าง Persistent Volume Cliam : PVC

ทำการสร้างไฟล์ basic-pvc.yml

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: nginx-volume
  resources:
    requests:
      storage: 2Gi

จากนั้นสั่ง apply ไฟล์ basic-pvc.yml และสั่งดูรายละเอียดของ Persistent Volume claim