ข้อมูลเบื้องต้นเกี่ยวกับการปรับแต่ง

บันทึก. แปล: บทความนี้เขียนโดย Scott Lowe วิศวกรที่มีประสบการณ์อย่างกว้างขวางในด้านไอที ซึ่งเป็นผู้เขียน/ผู้เขียนร่วมของหนังสือที่ตีพิมพ์เจ็ดเล่ม (ส่วนใหญ่อยู่บน VMware vSphere) ปัจจุบันเขาทำงานให้กับบริษัทในเครือ VMware Heptio (ซื้อกิจการในปี 2016) ซึ่งเชี่ยวชาญด้านการประมวลผลแบบคลาวด์และ Kubernetes ข้อความนี้ทำหน้าที่เป็นคำแนะนำที่กระชับและเข้าใจง่ายเกี่ยวกับการจัดการการกำหนดค่าสำหรับ Kubernetes โดยใช้เทคโนโลยี ปรับแต่งซึ่งเพิ่งกลายมาเป็นส่วนหนึ่งของ K8s

Kustomize เป็นเครื่องมือที่ช่วยให้ผู้ใช้ "ปรับแต่งไฟล์ YAML ที่เรียบง่ายและไม่มีเทมเพลตเพื่อวัตถุประสงค์ที่แตกต่างกัน โดยปล่อยให้ YAML ดั้งเดิมไม่เสียหายและใช้งานได้" (คำอธิบายที่ยืมมาจากโดยตรง ปรับแต่งพื้นที่เก็บข้อมูลบน GitHub). สามารถเรียกใช้ Kustomize ได้โดยตรงหรือใช้ตั้งแต่ Kubernetes 1.14 เป็นต้นไป kubectl -k เพื่อเข้าถึงฟังก์ชันการทำงาน (แม้ว่าใน Kubernetes 1.15 ไบนารีที่แยกจากกันจะใหม่กว่าความสามารถที่มีอยู่ใน kubectl) (บันทึก. แปล: และด้วยการเปิดตัวล่าสุด คูเบอร์เนเตส 1.16 ปรับแต่ง สนับสนุนโดย ในยูทิลิตี้ kubeadm ด้วย) ในโพสต์นี้ ฉันอยากจะแนะนำผู้อ่านเกี่ยวกับพื้นฐานของการปรับแต่ง

ในรูปแบบ/แอปพลิเคชันที่ง่ายที่สุด kustomize เป็นเพียงคอลเลกชันของทรัพยากร (ไฟล์ YAML ที่กำหนดอ็อบเจ็กต์ Kubernetes: การปรับใช้ บริการ ฯลฯ) พร้อมด้วยรายการคำแนะนำสำหรับการเปลี่ยนแปลงที่ต้องทำกับทรัพยากรเหล่านั้น เช่นเดียวกับ make ใช้ชุดคำสั่งที่มีอยู่ใน Makefileและ Docker จะสร้างคอนเทนเนอร์ตามคำแนะนำจาก Dockerfile,ปรับแต่งการใช้งาน kustomization.yaml เพื่อจัดเก็บคำแนะนำเกี่ยวกับการเปลี่ยนแปลงที่ผู้ใช้ต้องการทำกับชุดทรัพยากร

นี่คือไฟล์ตัวอย่าง kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ฉันจะไม่พยายามพูดถึงฟิลด์ที่เป็นไปได้ทั้งหมดในไฟล์ kustomization.yaml (เรื่องนี้เขียนไว้ดี. ที่นี่) แต่ฉันจะให้คำอธิบายสั้น ๆ เกี่ยวกับตัวอย่างเฉพาะ:

• สนาม resources บ่งชี้ว่าการกำหนดค่าใด (ทรัพยากรใด) ที่จะเปลี่ยนแปลง ในกรณีนี้ มันจะค้นหาทรัพยากรในไฟล์ deployment.yaml и service.yaml ในไดเรกทอรีของคุณ (คุณสามารถระบุเส้นทางแบบเต็มหรือเส้นทางสัมพันธ์ได้หากจำเป็น)
• สนาม namePrefix สั่งให้ปรับแต่งเพื่อเพิ่มคำนำหน้า (ในกรณีนี้ - dev-) เพื่อระบุคุณลักษณะ name ทรัพยากรทั้งหมดที่กำหนดไว้ในฟิลด์ resources. ดังนั้นหากปรับใช้ได้ name ด้วยความหมาย nginx-deployment, ปรับแต่งจะทำให้มัน dev-nginx-deployment.
• สนาม namespace สั่งให้ปรับแต่งเพื่อเพิ่มเนมสเปซที่กำหนดให้กับทรัพยากรทั้งหมด ในกรณีนี้ การปรับใช้และการบริการจะอยู่ในเนมสเปซ development.
• ในที่สุดสนาม commonLabels มีชุดป้ายกำกับที่จะเพิ่มลงในทรัพยากรทั้งหมด ในตัวอย่างของเรา kustomize จะกำหนดป้ายกำกับให้กับทรัพยากรด้วยชื่อ environment และมีความหมาย development.

หากผู้ใช้ทำ kustomize build . ในไดเร็กทอรีพร้อมกับไฟล์ kustomization.yaml และทรัพยากรที่จำเป็น (เช่น ไฟล์ deployment.yaml и service.yaml) จากนั้นที่เอาต์พุตจะได้รับข้อความพร้อมการเปลี่ยนแปลงที่ระบุ kustomization.yaml.

บันทึก. แปล: ภาพประกอบจากเอกสารโครงการเกี่ยวกับการใช้ kustomize แบบ "เรียบง่าย"

สามารถเปลี่ยนเส้นทางเอาต์พุตได้หากจำเป็นต้องยอมรับการเปลี่ยนแปลง:

kustomize build . > custom-config.yaml

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

kustomize build . | kubectl apply -f -

คุณสมบัติปรับแต่งยังสามารถเข้าถึงได้ผ่านทาง kubectl -k (ตั้งแต่ Kubernetes เวอร์ชัน 1.14) อย่างไรก็ตาม โปรดทราบว่าแพ็คเกจ kustomize แบบสแตนด์อโลนจะได้รับการอัปเดตเร็วกว่าแพ็คเกจ kubectl ที่ผสานรวม (อย่างน้อยก็ในกรณีนี้ด้วยการเปิดตัว Kubernetes 1.15)

ผู้อ่านอาจถามว่า “ทำไมถึงซับซ้อนขนาดนี้ หากคุณสามารถแก้ไขไฟล์ได้โดยตรง” คำถามที่ดี ในตัวอย่างของเราจริงๆ หนึ่งสามารถ แก้ไขไฟล์ deployment.yaml и service.yaml โดยตรง แต่จะเกิดอะไรขึ้นถ้าพวกเขาเป็นทางแยกของโครงการของคนอื่น? การเปลี่ยนไฟล์โดยตรงทำให้ยาก (หากไม่ใช่เป็นไปไม่ได้) ที่จะรีบูตทางแยกเมื่อมีการเปลี่ยนแปลงต้นทาง/แหล่งที่มา การใช้ kustomize ช่วยให้คุณสามารถรวมการเปลี่ยนแปลงเหล่านี้ไว้ในไฟล์ได้ kustomization.yamlโดยปล่อยให้ไฟล์ต้นฉบับไม่เสียหาย และทำให้ง่ายต่อการรีบูตไฟล์ต้นฉบับหากจำเป็น

ประโยชน์ของการปรับแต่งจะเห็นได้ชัดเจนในกรณีการใช้งานที่ซับซ้อนมากขึ้น ในตัวอย่างข้างต้น kustomization.yaml และทรัพยากรอยู่ในไดเรกทอรีเดียวกัน อย่างไรก็ตาม ปรับแต่งรองรับกรณีการใช้งานที่มีการกำหนดค่าพื้นฐานและรูปแบบต่างๆ มากมายหรือที่เรียกว่า ซ้อนทับ. ตัวอย่างเช่น ผู้ใช้ต้องการนำการปรับใช้และบริการสำหรับ nginx ซึ่งฉันใช้เป็นตัวอย่าง และสร้างเวอร์ชันการพัฒนา การจัดเตรียม และเวอร์ชันที่ใช้งานจริง (หรือตัวแปร) ของไฟล์เหล่านั้น ในการทำเช่นนี้เขาจะต้องมีการซ้อนทับที่กล่าวมาข้างต้นและอันที่จริงแล้วคือทรัพยากรพื้นฐานด้วย

เพื่อแสดงให้เห็นแนวคิดของการซ้อนทับและทรัพยากรพื้นฐาน (ทรัพยากรฐาน)สมมติว่าไดเร็กทอรีมีโครงสร้างดังต่อไปนี้:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

ในไฟล์ base/kustomization.yaml ผู้ใช้ที่ใช้สนาม resources เพียงประกาศทรัพยากรที่ปรับแต่งควรรวมไว้ด้วย

ในแต่ละไฟล์ overlays/{dev,staging,prod}/kustomization.yaml ผู้ใช้อ้างถึงการกำหนดค่าพื้นฐานในฟิลด์ resourcesแล้วระบุการเปลี่ยนแปลงเฉพาะสำหรับ สภาพแวดล้อมที่กำหนด. ตัวอย่างเช่น ไฟล์ overlays/dev/kustomization.yaml อาจดูเหมือนตัวอย่างที่ให้ไว้ก่อนหน้านี้:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ในกรณีนี้ไฟล์ overlays/prod/kustomization.yaml อาจจะแตกต่างไปจากเดิมอย่างสิ้นเชิง:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

เมื่อผู้ใช้รัน kustomize build . ในแคตตาล็อก overlays/devปรับแต่งจะสร้างตัวเลือกการพัฒนา ถ้าคุณวิ่ง kustomize build . ในแคตตาล็อก overlays/prod - คุณได้รับตัวเลือกการผลิต และทั้งหมดนี้ - โดยไม่ทำการเปลี่ยนแปลงใดๆ กับต้นฉบับ (ฐาน) ไฟล์ทั้งหมดในลักษณะที่ประกาศและกำหนดได้ คุณสามารถคอมมิตการกำหนดค่าพื้นฐานและไดเร็กทอรีโอเวอร์เลย์ไปยังการควบคุมเวอร์ชันได้โดยตรง โดยรู้ว่าจากไฟล์เหล่านี้ คุณสามารถสร้างการกำหนดค่าที่ต้องการได้ตลอดเวลา

บันทึก. แปล: ภาพประกอบจากเอกสารประกอบโครงการเกี่ยวกับการใช้โอเวอร์เลย์ในการปรับแต่ง

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

แหล่งข้อมูลเพิ่มเติม

มีบทความและสิ่งพิมพ์ดีๆ มากมายเกี่ยวกับ kustomize นี่คือบางส่วนที่ฉันพบว่ามีประโยชน์อย่างยิ่ง:

• เปลี่ยนการกำหนดค่า YAML พื้นฐานสำหรับสภาพแวดล้อมการผลิต/การทดสอบที่แตกต่างกันโดยใช้ Kustomize;
• ปรับแต่ง — วิธีที่ถูกต้องในการทำเทมเพลตใน Kubernetes;
• การจัดการที่ประกาศของออบเจ็กต์ Kubernetes โดยใช้การกำหนดเอง;
• การปรับแต่งแผนภูมิ Helm ต้นน้ำด้วยการปรับแต่ง.

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

หากคุณมีคำถามหรือข้อเสนอแนะในการปรับปรุงเนื้อหานี้ ฉันยินดีรับฟังความคิดเห็นเสมอ คุณสามารถติดต่อฉันได้ที่ Twitter หรือ ช่องทาง Kubernetes Slack. ขอให้สนุกกับการแก้ไขรายการของคุณด้วยการปรับแต่ง!

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

• «เครื่องมือสำหรับนักพัฒนาแอปพลิเคชันที่ทำงานบน Kubernetes";
• «Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก";
• «ผลลัพธ์หลักห้าประการของ Helm Summit 2019 ในอัมสเตอร์ดัม";
• «การแนะนำเชิงปฏิบัติเกี่ยวกับตัวจัดการแพ็คเกจสำหรับ Kubernetes - Helm'

ที่มา: will.com