อธิบายการเก็บ Configuration บน Kubernetes ด้วย ConfigMaps

หัวข้อนี้เป็นหัวข้อย่อยมาจากบทความ Kubernetes Components แบบละเอียด เพื่อแสดงการเก็บข้อมูล ENV และตัว URL ของ Service เพื่อให้ Pod มาเรียกใช้งานได้ และยังเป็นการแสดงการออกแบบ Cluster แบบ Centralized Configuration อีกด้วย

Prerequisite

ต่อจากความเดิมตอนที่แล้วถ้าใครยังไม่ได้อ่าน อธิบายการสร้าง Kubernetes Pod ด้วย Deployments Resources และ อธิบายการสร้าง Kubernetes Internal Services และ Networking ด้วย Service Resource กับ อธิบายการสร้าง Kubernetes External Services และ Networking ด้วย Service Resource และ อธิบายการเก็บ Sensitive Data บน Kubernetes ด้วย Secret ย้อนกลับไปอ่านก่อนนะครับ

File Structure Details

เราลองมาดูโครงสร้างการทำ ConfigMaps กัน

apiVersion: v1
kind: ConfigMap
metadata:
  name: mongo-express-configmap
data:
  database_url: mongo-service

การเขียนง่ายมากๆ แค่ประกาศส่วนของ Data เหมือนการสร้าง Secret จากนั้นก็เอาแล้วเอาข้อมูลมาแปะได้เลยในส่วนของ data

ย้อนกลับบทความที่อธิบายการสร้าง Kubernetes External Services และ Networking ด้วย Service Resource ไว้นิดนึง มันจะมีส่วนนึงที่ผมได้ประกาศ ME_CONFIG_MONGODB_SERVER เป็นแบบ plain text คือ mongo-service

env:
  - name: ME_CONFIG_MONGODB_SERVER
  value: mongo-service

ในค่าที่ใส่เอาไว้จะเป็นชื่อของ k8s service ที่เราได้สร้างเอาไว้เพื่อให้ตัว Service ที่เรากำลังสร้างรู้ว่าเราต้องไปต่อกับ k8s Pod ไหน ตรงนี้ที่ผมได้อธิบายไปในบทความหลักว่า

เมื่อเวลา Pod เราถูกลบหายหรือตายไปจาก Cluster เมื่อตัว kube-scheduler สร้าง Pod ขึ้นมาให้ใหม่ ตัว IP ที่เปลี่ยนไปจะถูก resolve ที่ชื่อของ Service ต่างๆ ที่เก็บใน ​ConfigMaps อัตโนมัติทันที่ เราไม่มีความจำเป็นต้องไปแก้ Pod URL

สำหรับการเรียกใช้งานก็เพียงแค่ทำแบบนี้

# old
env:
  - name: ME_CONFIG_MONGODB_SERVER
  value: mongo-service
---
# new
env:
  - name: ME_CONFIG_MONGODB_SERVER
  valueFrom:
    configMapKeyRef: 
      name: mongo-express-configmap
      key: database_url

เปลี่ยน value ไปให้เป็น valueFrom จากนั้นเรียกใช้ configMapKeyRef ตามด้วยชื่อ ConfigMaps ที่เราสร้างไว้ ต่อด้วย key ที่ประกาศไว้เท่านี้ก็เป็นอันเสร็จ

Running

ถ้า describe มาดูแล้วไม่มี Error ไรก็ถือว่าเสร็จ จากนั้นลองมาเช็คที่ Pod ดูว่าใช้งานได้ไหม

จะเห็นได้ว่าตอนเรา describe เพื่อมา debug มันได้ทำการไปเรียกที่ mongo-express-configmap ที่เราได้ทำไว้พร้อมกับ key env ที่เราได้ประกาศไว้เหมือนกัน หลังจากนี้ถ้า มันจะเข้ากระบวนการของ kube-proxy ในการวิ่งไปหา Pod อื่นๆ ใน Cluster ให้เองแล้ว

ฝากติดตามบทความและโพสต่างๆ ที่เป็นประโยชน์ที่แฟนเพจ Algorithml