การทำงานกับเทนต์และความคลาดเคลื่อนใน Kubernetes

Taints & Tolerants ใน Kubernetes คืออะไรและทำงานอย่างไร

ในชีวิตทั่วไป เรามักจะพัฒนาความสัมพันธ์กับคนที่เราชอบและต้องการมีส่วนร่วมบ่อยครั้งใน Kubernetes เราสามารถสร้างความสัมพันธ์ที่ใกล้ชิดระหว่างโหนดและพ็อดในทำนองเดียวกัน

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

“มลทินและความอดทน ”

มาทำความเข้าใจกับยุงและการเปรียบเทียบของมนุษย์กันดีกว่า:

สมมุติว่าคุณไม่อยากให้ยุงกัดคุณ ในกรณีนี้ คุณจะทำอย่างไร? คุณใช้ยาไล่ยุงหรือใช้ Odomos (เจลไล่ยุง)

ไม่ว่าคุณจะใช้ Odomos ที่ส่วนใดของร่างกายคุณ ส่วนนั้นจะ “มีมลทิน” ยุงของเราไม่ทนต่อมลทินประเภทนี้ ดังนั้นเมื่อใดก็ตามที่พวกมันเข้ามาใกล้ส่วนของร่างกายที่เปื้อน พวกมันก็จะทนไม่ไหวและจะบินหนีไป

ดังนั้น ร่างกายของเราจึง “มีมลทิน ” และยุงก็ “ไม่ทนต่อ ”

แต่หากมีแมลงประเภทอื่นเกิดขึ้นซึ่งสามารถทนต่อสารปนเปื้อน (สารขับไล่) พวกมันก็จะเกาะอยู่บนร่างกายของเราได้

ดังนั้นในกรณีนี้เนื้อหาคือ “มีมลทิน” ข้อบกพร่องอื่นๆ คือ “ทนทาน ”

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

ความสกปรกและความคลาดเคลื่อนในบริบทของ Kubernetes:

ในกรณีของ Kubernetes

• โหนด: คือบุคคลที่แมลงต้องการนั่ง โหนดของเธอโดยทั่วไปมีมลทิน
• พ็อด: คือตัวแมลง/ยุงนั่นเอง โดยทั่วไปแล้วพ็อดที่นี่มีความทนทาน

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

มาทำความเข้าใจกับรูปด้านล่าง:

คำอธิบาย:

คนงาน NODE 1 มีมลทิน & POD 3 ทำเครื่องหมายว่าทนทาน:

NODE 1 ที่นี่ถูกทำเครื่องหมายว่าปนเปื้อนด้วย (สีเขียว) ซึ่งหมายความว่าไม่มีพ็อด, POD 1, POD 2, POD 3 ใด ๆ ที่จะสามารถอาศัยอยู่บน NODE 1 ได้จนกว่าอันใดอันหนึ่งหรือทั้งหมดจะถูกทำเครื่องหมายว่าทนทานต่อโหนด มีตำหนิ 1 รายการ

ดังนั้นหากเราทำเครื่องหมาย POD 3 ว่าทนทานต่อมลทินของ NODE 1ดังแสดงในรูปด้านบน และปล่อยให้พ็อดอื่นๆ พ็อด 1, พ็อด 2 ไม่ทนต่อมลทินของโหนด 1 ต่อไปนี้คือ สถานการณ์จะเป็นอย่างไร:

คำอธิบาย:

POD 3 ได้รับอนุญาตให้อยู่ใน NODE 1 เนื่องจากมีเครื่องหมายว่าทนทานต่อมัน พ็อดที่เหลือได้รับอนุญาตให้อยู่ใน NODE 2 และ NODE 3

หมายเหตุ!

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

ดังนั้นด้วยสัญชาตญาณและความเข้าใจนี้ จึงถึงเวลาที่จะเข้าใจ

มีการนำเทนต์ไปใช้อย่างไร?

คุณเพิ่มเทนต์ให้กับโหนดโดยใช้ "kubectl taint"

ตัวอย่างเช่น การเพิ่มเทนต์โดยใช้คำสั่ง kubectl taint จะมีไวยากรณ์ดังต่อไปนี้:

kubectl taint nodes <node name >key=value:taint-effect

ที่นี่

• taint: คือคำสั่งเพื่อใช้เทนต์ในโหนด
• โหนด: เป็นชุดของโหนดผู้ปฏิบัติงาน
• ชื่อโหนด: คือชื่อของโหนดผู้ปฏิบัติงานเฉพาะ ซึ่งต้องใช้เทนต์ โดยมีคู่คีย์-ค่า
• คู่คีย์-ค่า:ใช้เพื่อระบุประเภทแอปพลิเคชันในพ็อดที่จะแนบโหนดนี้
• เอฟเฟกต์มลทิน: ใช้เพื่อกำหนดวิธีปฏิบัติต่อพ็อดหากพ็อดไม่ทนต่อมลทิน

เอฟเฟกต์สีซีดมีประเภทดังต่อไปนี้

• ไม่มีกำหนดการ
• PreferNoSchedule
• ไม่ดำเนินการ

คำสั่งสุดท้ายจะมีลักษณะดังนี้:

kubectl taint nodes node1 app=blue: NoSchedule

ที่นี่ node1 เสียด้วยพ็อดที่มีคู่คีย์-ค่า app=blue โดยที่พ็อดถูกแมปด้วยประเภทเอฟเฟกต์เทนต์: NoSchedule หมายความว่าจะไม่มีการกำหนดเวลา พ็อด ไปยังโหนดที่กำหนด โหนด1 จนกว่าจะมีความคลาดเคลื่อนที่ตรงกัน

การเพิ่มความคลาดเคลื่อนให้กับพ็อด:

ในคำจำกัดความของพ็อดข้างต้น เราระบุความคลาดเคลื่อนสำหรับพ็อดในส่วน Spec ของพ็อดดังแสดงในรูปด้านบน

tolerations:
- key: "app"
  operator: "Equal"
  value: "blue"
  effect: "NoSchedule"

คำจำกัดความของความคลาดเคลื่อนนี้ตรงกับคำสั่งด้านล่าง

kubectl taint nodes node1 app=blue: NoSchedule

โดยที่เราเพิ่มเทนต์เพื่อจับคู่พ็อดกับคู่คีย์-ค่า app=blue.

ดังนั้นด้วยการยอมรับนี้ ตอนนี้ Pod tol-pod จะได้รับอนุญาตให้กำหนดเวลากับ Node ซึ่งไม่บริสุทธิ์ให้ยอมรับประเภทค่า app= blue

มลทินและความอดทนทำงานร่วมกันอย่างไร:

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

ข้อควรจำ: มีสองกรณีพิเศษ:

โดยค่าเริ่มต้นการดำเนินการจะเป็นประเภท: เท่ากับ

• หากในคำจำกัดความมี คีย์ ว่างซึ่งมีโอเปอเรเตอร์ประเภท มีอยู่ จะตรงกับคีย์ ค่า และเอฟเฟกต์ทั้งหมด ซึ่งหมายความว่าคีย์-ค่านี้แมปกับเทนต์ใดๆ จะ อดทนกับทุกสิ่ง
• เอฟเฟกต์ ที่ว่างเปล่าจะจับคู่เอฟเฟกต์ทั้งหมดด้วยคีย์ คีย์

การทำความเข้าใจผลกระทบจากมลทินอื่นๆ:

เอฟเฟกต์สีมัว: ไม่กำหนดตารางเวลา

tolerations:
- key: "app"
  operator: "Equal"
  value: "blue"
  effect: "PreferNoSchedule"

หากเราเปลี่ยนประเภทเอฟเฟกต์เทนต์เป็น : effect: "PreferNoSchedule",

ซึ่งหมายความว่าเป็นเวอร์ชัน "การตั้งค่า" หรือ "แบบอ่อน" ของ NoSchedule -- ระบบจะพยายามหลีกเลี่ยงการวางพ็อดที่ไม่ทนต่อมลทินบนโหนด แต่ไม่จำเป็น

ผลเสีย: ไม่มีการดำเนินการ

เพื่อให้เข้าใจได้ดีขึ้น เรามาพิจารณากรณีการใช้งานใหม่โดยที่เรามี Tolerance หลายค่าที่แมปด้วยคู่คีย์-ค่าเดียวกัน แต่มีเอฟเฟกต์เทนต์ประเภทอื่น

มาเพิ่มโหนดเสีย: โหนด 1 ดังที่แสดงด้านล่าง

- $ kubectl taint nodes node1 app=blue:NoSchedule
- $ kubectl taint nodes node1 app=blue:NoExecute
- $ kubectl taint nodes node1 app=green:NoSchedule

ตอนนี้เรามาสร้างคำจำกัดความของพ็อดที่มีความคลาดเคลื่อนสองค่า ดังที่แสดงด้านล่าง:

apiVersion: v1
kind: Pod
metadata:
  name: tol-pod
  labels:
    env: prod
spec:
  containers:
  - name: nginx-cotainer
    image: nginx
  
  tolerations:
  - key: "app"
     operator: "Equal"
     value: "blue"
     effect: "NoSchedule"
  - key: "app"
     operator: "Equal"
     value: "blue"
     effect: "NoExecute"

คำอธิบาย:

ในสถานการณ์ที่อธิบายไว้ข้างต้น พ็อดของเราจะไม่ถูกกำหนดตารางเวลาบนโหนด node1เนื่องจากไม่มีค่าความคลาดเคลื่อนที่ตรงกับเทนต์ที่สาม

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

โดยทั่วไป หากโหนดใดๆ มีเทนต์ประเภท NoExecute และพ็อดใดๆ ที่ยังไม่ได้พัฒนา ความทนทานต่อการจัดการเทนต์ จะถูกกำจัดออก (หากมีอยู่แล้วก่อนที่โหนดจะเสีย )แต่พ็อดใดๆ ที่ทนต่อมลทินจะไม่มีวันถูกไล่ออก

ความอดทนวินาที:

หากเราต้องการสั่งสอน pod ด้วยเอฟเฟกต์ taint: NoExecute ให้คงการเชื่อมโยงกับโหนดที่แปดเปื้อนและถูกบังคับให้ขับไล่ ในช่วงระยะเวลาหนึ่งโดยเฉพาะ เราสามารถใช้ฟิลด์เสริม tolerationSeconds ใน tolerations ความหมายตามที่แสดงด้านล่าง

tolerations:
- key: "app"
  operator: "Equal"
  value: "app"
  effect: "NoExecute"
  tolerationSeconds: 3600

สรุป:

เราเข้าใจ

• Taints & Tolerations คืออะไร?
• เหตุใดจึงใช้ Taints & Tolerations?
• จะเพิ่มเทนต์ลงใน Worker Node ได้อย่างไร
• จะเพิ่มความอดทนให้กับพ็อดได้อย่างไร?

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

โหนดเฉพาะที่เชื่อมโยงกับกลุ่มผู้ใช้เฉพาะ/ชุดผู้ใช้

• หากในฐานะผู้ดูแลระบบ Kubernetes หรือสถาปนิก DevOps คุณต้องการใช้โหนดผู้ปฏิบัติงานใดๆ ในคลัสเตอร์ k8s สำหรับชุดหรือกลุ่มผู้ใช้เฉพาะโดยเฉพาะ เราสามารถทำได้โดย

$ kubectl taint nodes nodename dedicated=groupName:NoSchedule

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

เราจะเรียนรู้เพิ่มเติมเกี่ยวกับ Node Affinity ในบทความถัดไปในชุดนี้หรือเรื่อง Taints & Tolerations

<แข็งแกร่ง>2. การขับไล่ตามมลทิน:

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

อะไรต่อไป?

เราจะพิจารณากรณีการใช้งานขั้นสูงของ Taints & Tolerations เช่น

• ความสัมพันธ์ของโหนด
• กรณีการใช้งาน Pod Eviction แบบไร้มลทิน
• จะควบคุมข้อกำหนดเฉพาะระดับฮาร์ดแวร์ในโหนดได้อย่างไร
• และอื่น ๆ อีกมากมาย…..

หากคุณชอบงานชิ้นนี้แสดงการสนับสนุนและความรักโดยติดตามฉันและปรบมือ

ขอบคุณที่อยู่ตรงนั้น……..