🥇วิธีใช้ kubectl อย่างมีประสิทธิภาพมากขึ้น: คำแนะนำโดยละเอียด

หากคุณทำงานกับ Kubernetes kubectl อาจเป็นหนึ่งในยูทิลิตี้ที่คุณใช้บ่อยที่สุด และเมื่อใดก็ตามที่คุณใช้เวลามากมายในการทำงานกับเครื่องมือบางอย่าง จะต้องศึกษาให้ดีและเรียนรู้วิธีใช้งานอย่างมีประสิทธิภาพ

ทีม Kubernetes aaS จาก Mail.ru แปลบทความโดย Daniel Weibel ซึ่งคุณจะพบเคล็ดลับและคำแนะนำในการทำงานกับ kubectl อย่างมีประสิทธิภาพ นอกจากนี้ยังจะช่วยให้คุณเข้าใจ Kubernetes อย่างลึกซึ้งยิ่งขึ้น

ตามที่ผู้เขียนกล่าวไว้ เป้าหมายของบทความนี้คือการทำให้งานประจำวันของคุณกับ Kubernetes ไม่เพียงแต่มีประสิทธิภาพมากขึ้นเท่านั้น แต่ยังสนุกสนานมากขึ้นด้วย!

บทนำ: kubectl คืออะไร

ก่อนที่คุณจะสามารถเรียนรู้การใช้ kubectl ได้อย่างมีประสิทธิภาพมากขึ้น คุณต้องมีความเข้าใจพื้นฐานว่ามันคืออะไรและทำงานอย่างไร

จากมุมมองของผู้ใช้ kubectl คือแผงควบคุมที่ช่วยให้คุณดำเนินการ Kubernetes ได้

ในทางเทคนิคแล้ว kubectl คือไคลเอ็นต์ Kubernetes API

Kubernetes API เป็น HTTP REST API API นี้เป็นอินเทอร์เฟซผู้ใช้ Kubernetes ที่แท้จริงซึ่งมีการควบคุมอย่างสมบูรณ์ ซึ่งหมายความว่าทุกการดำเนินการของ Kubernetes จะถูกเปิดเผยเป็นจุดสิ้นสุด API และสามารถสร้างได้ด้วยคำขอ HTTP ไปยังตำแหน่งข้อมูลนั้น

ดังนั้นงานหลักของ kubectl คือส่งคำขอ HTTP ไปยัง Kubernetes API:

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

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

ลองดูตัวอย่าง.

สมมติว่าคุณต้องการสร้างทรัพยากร ReplicaSet เมื่อต้องการทำเช่นนี้ คุณอธิบาย ReplicaSet ในไฟล์ตามชื่อ replicaset.yamlจากนั้นรันคำสั่ง:

$ kubectl create -f replicaset.yaml

สิ่งนี้จะสร้างทรัพยากร ReplicaSet แต่จะเกิดอะไรขึ้นเบื้องหลัง?

Kubernetes มีการดำเนินการสร้าง ReplicaSet เช่นเดียวกับการดำเนินการอื่นๆ การดำเนินการดังกล่าวจะถูกเปิดเผยเป็นจุดสิ้นสุด API ตำแหน่งข้อมูล API เฉพาะสำหรับการดำเนินการนี้มีลักษณะดังนี้:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

คุณสามารถดูจุดสิ้นสุด API สำหรับการดำเนินการ Kubernetes ทั้งหมดได้ที่ การอ้างอิง API (รวมถึง ปลายทางข้างต้น). หากต้องการส่งคำขอจริงไปยังตำแหน่งข้อมูล คุณต้องเพิ่ม URL เซิร์ฟเวอร์ API ไปยังเส้นทางตำแหน่งข้อมูลที่ระบุไว้ในการอ้างอิง API ก่อน

ดังนั้น เมื่อคุณดำเนินการคำสั่งข้างต้น kubectl จะส่งคำขอ HTTP POST ไปยังจุดสิ้นสุด API ข้างต้น ข้อกำหนด ReplicaSet ที่คุณระบุในไฟล์ replicaset.yamlถูกส่งไปในเนื้อความของคำขอ

นี่คือวิธีการทำงานของ kubectl สำหรับคำสั่งทั้งหมดที่โต้ตอบกับคลัสเตอร์ Kubernetes ในกรณีเหล่านี้ทั้งหมด kubectl จะส่งคำขอ HTTP ไปยังตำแหน่งข้อมูล Kubernetes API ที่เหมาะสม

โปรดทราบว่าคุณสามารถจัดการ Kubernetes ได้อย่างสมบูรณ์โดยใช้ยูทิลิตี้เช่น curlโดยส่งคำขอ HTTP ไปยัง Kubernetes API ด้วยตนเอง Kubectl ทำให้การใช้ Kubernetes API ง่ายขึ้น

นี่คือพื้นฐานของ kubectl คืออะไรและทำงานอย่างไร แต่มีอย่างอื่นเกี่ยวกับ Kubernetes API ที่ผู้ใช้ kubectl ทุกคนควรรู้ มาดูโลกภายในของ Kubernetes กันดีกว่า

โลกภายในของ Kubernetes

Kubernetes ประกอบด้วยชุดส่วนประกอบอิสระที่ทำงานเป็นกระบวนการแยกกันบนโหนดคลัสเตอร์ ส่วนประกอบบางอย่างทำงานบนโหนดหลัก ส่วนประกอบอื่นๆ ทำงานบนโหนดของผู้ปฏิบัติงาน โดยแต่ละส่วนประกอบทำงานเฉพาะของตัวเอง

ต่อไปนี้เป็นส่วนประกอบที่สำคัญที่สุดบนโหนดหลัก:

ห้องนิรภัย - เก็บคำจำกัดความของทรัพยากร (โดยปกติแล้วจะเป็น ฯลฯ).
เซิร์ฟเวอร์เอพีไอ — จัดเตรียม API และจัดการพื้นที่เก็บข้อมูล
ผู้จัดการฝ่ายควบคุม — ตรวจสอบให้แน่ใจว่าสถานะของทรัพยากรเป็นไปตามข้อกำหนด
กำหนดการ - กำหนดเวลาพ็อดบนโหนดของผู้ปฏิบัติงาน

และนี่คือองค์ประกอบที่สำคัญที่สุดอย่างหนึ่งบนโหนดของผู้ปฏิบัติงาน:

คูเบเลต — จัดการการเปิดตัวคอนเทนเนอร์บนโหนดการทำงาน

เพื่อให้เข้าใจว่าส่วนประกอบเหล่านี้ทำงานร่วมกันอย่างไร ลองดูตัวอย่าง

สมมติว่าคุณเพิ่งทำเสร็จ kubectl create -f replicaset.yamlหลังจากนั้น kubectl ก็ได้ส่งคำขอ HTTP POST ไป จุดสิ้นสุด ReplicaSet API (ผ่านข้อกำหนดทรัพยากร ReplicaSet)

เกิดอะไรขึ้นในกลุ่ม?

หลังทำ kubectl create -f replicaset.yaml เซิร์ฟเวอร์ API จะจัดเก็บคำจำกัดความทรัพยากร ReplicaSet ของคุณไว้ในที่เก็บข้อมูล:
ถัดไป ตัวควบคุม ReplicaSet จะเปิดตัวในตัวจัดการตัวควบคุม ซึ่งจัดการการสร้าง การแก้ไข และการลบทรัพยากร ReplicaSet:
ตัวควบคุม ReplicaSet สร้างคำจำกัดความของพ็อดสำหรับแบบจำลอง ReplicaSet แต่ละรายการ (ตามเทมเพลตพ็อดในคำจำกัดความ ReplicaSet) และจัดเก็บไว้ในที่เก็บข้อมูล:
เปิดตัวตัวกำหนดเวลา โดยติดตามพ็อดที่ยังไม่ได้กำหนดให้กับโหนดของผู้ปฏิบัติงาน:
ตัวกำหนดเวลาจะเลือกโหนดผู้ปฏิบัติงานที่เหมาะสมสำหรับแต่ละพ็อด และเพิ่มข้อมูลนี้ไปยังคำจำกัดความของพ็อดในร้านค้า:
บนโหนดผู้ปฏิบัติงานที่ได้รับมอบหมายพ็อด Kubelet จะถูกเปิดใช้งาน โดยจะติดตามพ็อดที่กำหนดให้กับโหนดนี้:
Kubelet อ่านคำจำกัดความของพ็อดจากพื้นที่เก็บข้อมูลและสั่งให้รันไทม์ของคอนเทนเนอร์ เช่น Docker เพื่อเปิดใช้คอนเทนเนอร์บนโหนด:

ด้านล่างนี้เป็นเวอร์ชันข้อความของคำอธิบายนี้

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

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

งานของตัวควบคุม ReplicaSet คือการตรวจสอบให้แน่ใจว่ามีจำนวนพ็อด ReplicaSet ที่ต้องการอยู่ ในตัวอย่างของเรา ยังไม่มีพ็อด ดังนั้นตัวควบคุม ReplicaSet จึงสร้างคำจำกัดความของพ็อดเหล่านี้ (ตามเทมเพลตพ็อดในข้อกำหนด ReplicaSet) และจัดเก็บไว้ในที่เก็บข้อมูล

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

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

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

ณ จุดนี้ แอปพลิเคชัน ReplicaSet ของคุณก็เริ่มทำงานในที่สุด!

บทบาทของ Kubernetes API

ดังที่คุณเห็นในตัวอย่างก่อนหน้านี้ ส่วนประกอบของ Kubernetes (ยกเว้นเซิร์ฟเวอร์ API และพื้นที่เก็บข้อมูล) จะคอยดูการเปลี่ยนแปลงทรัพยากรในพื้นที่จัดเก็บและเปลี่ยนแปลงข้อมูลเกี่ยวกับทรัพยากรในพื้นที่จัดเก็บข้อมูล

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

ลองพิจารณาตัวอย่างต่อไปนี้:

ตัวควบคุม ReplicaSet ใช้จุดสิ้นสุด API แสดงรายการ ReplicaSets พร้อมพารามิเตอร์ watch เพื่อตรวจสอบการเปลี่ยนแปลงทรัพยากร ReplicaSet
ตัวควบคุม ReplicaSet ใช้จุดสิ้นสุด API สร้างพ็อด (สร้างพ็อด) เพื่อสร้างพ็อด
ตัวกำหนดเวลาใช้จุดสิ้นสุด API ฝักแพทช์ (แก้ไขพ็อด) เพื่ออัปเดตพ็อดด้วยข้อมูลเกี่ยวกับโหนดผู้ปฏิบัติงานที่เลือก

อย่างที่คุณเห็น นี่คือ API เดียวกับที่ kubectl เข้าถึง การใช้ API เดียวกันสำหรับส่วนประกอบภายในและผู้ใช้ภายนอกเป็นแนวคิดพื้นฐานในการออกแบบ Kubernetes

ตอนนี้เราสามารถสรุปวิธีการทำงานของ Kubernetes ได้แล้ว:

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

การรู้แนวคิดเหล่านี้จะช่วยให้คุณเข้าใจ kubectl ได้ดีขึ้นและได้รับประโยชน์สูงสุดจากมัน

ตอนนี้เรามาดูเคล็ดลับและคำแนะนำเฉพาะบางประการที่จะช่วยปรับปรุงประสิทธิภาพการทำงานของคุณด้วย kubectl

1. เร่งความเร็วอินพุตโดยใช้คำสั่งให้เสร็จสิ้น

หนึ่งในเทคนิคที่มีประโยชน์ที่สุด แต่มักถูกมองข้ามในการปรับปรุงประสิทธิภาพด้วย kubectl คือการทำให้คำสั่งสมบูรณ์

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

ดูว่าการเติมคำสั่ง kubectl ทำงานอย่างไร:

การดำเนินการคำสั่งให้เสร็จสิ้นใช้ได้กับเชลล์ Bash และ Zsh

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

วิธีการทำงานของคำสั่งให้เสร็จสิ้น

การเสร็จสิ้นคำสั่งเป็นคุณลักษณะของเชลล์ที่ทำงานโดยใช้สคริปต์การเสร็จสิ้น สคริปต์ส่วนขยายคือเชลล์สคริปต์ที่กำหนดลักษณะการทำงานของส่วนขยายสำหรับคำสั่งเฉพาะ

Kubectl สร้างและส่งออกสคริปต์ส่วนขยายสำหรับ Bash และ Zsh โดยอัตโนมัติโดยใช้คำสั่งต่อไปนี้:

$ kubectl completion bash

หรือ:

$ kubectl completion zsh

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

ในทางปฏิบัติ วิธีการเชื่อมต่อสำหรับ Bash (รวมถึงความแตกต่างระหว่าง Linux และ MacOS) และ Zsh จะแตกต่างกัน ด้านล่างเราจะดูตัวเลือกทั้งหมดเหล่านี้

ทุบตีบน Linux

สคริปต์การเสร็จสิ้น Bash ขึ้นอยู่กับแพ็คเกจการเสร็จสิ้น bash ดังนั้นคุณต้องติดตั้งก่อน:

$ sudo apt-get install bash-completion

หรือ:

$ yum install bash-completion

คุณสามารถทดสอบได้ว่าติดตั้งแพ็คเกจสำเร็จหรือไม่โดยใช้คำสั่งต่อไปนี้:

$ type _init_completion

หากสิ่งนี้ส่งเอาต์พุตโค้ดฟังก์ชันเชลล์ แสดงว่า bash-completion ได้รับการติดตั้งอย่างถูกต้อง หากคำสั่งแสดงข้อผิดพลาด "ไม่พบ" คุณต้องเพิ่มบรรทัดต่อไปนี้ในไฟล์ของคุณ ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

จำเป็นต้องเพิ่มบรรทัดนี้ในไฟล์หรือไม่ ~ / .bashrc หรือไม่ขึ้นอยู่กับตัวจัดการแพ็คเกจที่คุณใช้ในการติดตั้ง bash-completion นี่เป็นสิ่งจำเป็นสำหรับ APT แต่ไม่ใช่สำหรับ YUM

หลังจากติดตั้ง bash-completion คุณจะต้องกำหนดค่าทุกอย่างเพื่อให้สคริปต์การเสร็จสิ้น kubectl ถูกเปิดใช้งานในเซสชันเชลล์ทั้งหมด

วิธีหนึ่งในการทำเช่นนี้คือการเพิ่มบรรทัดต่อไปนี้ลงในไฟล์ ~ / .bashrc:

source <(kubectl completion bash)

อีกวิธีหนึ่งคือการเพิ่มสคริปต์ส่วนขยาย kubectl ลงในไดเร็กทอรี /etc/bash_completion.d (สร้างมันขึ้นมาหากไม่มีอยู่):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

สคริปต์ส่วนเสริมทั้งหมดในแค็ตตาล็อก /etc/bash_completion.d จะรวมอยู่ใน bash-complete โดยอัตโนมัติ

ตัวเลือกทั้งสองมีผลใช้บังคับเท่าเทียมกัน

หลังจากรีสตาร์ทเชลล์ การเสร็จสิ้นคำสั่ง kubectl จะทำงาน

ทุบตีบน MacOS

บน MacOS การตั้งค่าจะซับซ้อนกว่าเล็กน้อย ความจริงก็คือตามค่าเริ่มต้น MacOS ใช้ Bash เวอร์ชัน 3.2 และสคริปต์การเติมข้อความอัตโนมัติ kubectl ต้องใช้ Bash เวอร์ชันอย่างน้อย 4.1 และใช้งานไม่ได้ใน Bash 3.2

มีปัญหาด้านลิขสิทธิ์ที่เกี่ยวข้องกับการใช้ Bash เวอร์ชันล้าสมัยบน MacOS Bash เวอร์ชัน 4 ได้รับอนุญาตภายใต้ GPLv3 ซึ่ง Apple ไม่รองรับ

หากต้องการกำหนดค่าการเติมข้อความอัตโนมัติ kubectl บน MacOS คุณต้องติดตั้ง Bash เวอร์ชันที่ใหม่กว่า คุณยังสามารถตั้งค่า Bash ที่อัปเดตเป็นเชลล์เริ่มต้นได้ ซึ่งจะช่วยคุณประหยัดปัญหามากมายในอนาคต ไม่ยาก รายละเอียดอยู่ในบทความ “กำลังอัปเดต Bash บน MacOS'

ก่อนดำเนินการต่อ ตรวจสอบให้แน่ใจว่าคุณใช้ Bash เวอร์ชันล่าสุด (ตรวจสอบผลลัพธ์ bash --version).

สคริปต์การเสร็จสิ้น Bash จะแตกต่างกันไปตามโปรเจ็กต์ ทุบตีเสร็จดังนั้นคุณต้องติดตั้งก่อน

คุณสามารถติดตั้ง bash-completion ได้โดยใช้ homebrew:

$ brew install bash-completion@2

ที่นี่ @2 ย่อมาจาก bash-completion เวอร์ชัน 2 การเติมข้อความอัตโนมัติ kubectl ต้องใช้ bash-completion v2 และ bash-completion v2 ต้องใช้ Bash เวอร์ชัน 4.1 เป็นอย่างน้อย

เอาต์พุตคำสั่ง brew-install มีส่วน Caveats ซึ่งระบุสิ่งที่จำเป็นต้องเพิ่มลงในไฟล์ ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

อย่างไรก็ตาม ฉันขอแนะนำให้เพิ่มบรรทัดเหล่านี้ไม่ให้ ~/.bash_profileและใน ~/.bashrc. ในกรณีนี้ การเติมข้อความอัตโนมัติจะพร้อมใช้งานไม่เฉพาะในเชลล์คำสั่งหลักเท่านั้น แต่ยังรวมถึงเชลล์คำสั่งย่อยด้วย

หลังจากรีสตาร์ทเชลล์คำสั่ง คุณสามารถตรวจสอบว่าการติดตั้งถูกต้องโดยใช้คำสั่งต่อไปนี้:

$ type _init_completion

หากคุณเห็นฟังก์ชันเชลล์ในเอาต์พุต แสดงว่าทุกอย่างได้รับการกำหนดค่าอย่างถูกต้อง

ตอนนี้เราต้องแน่ใจว่ามีการเปิดใช้การเติมข้อความอัตโนมัติ kubectl ในทุกเซสชัน

วิธีหนึ่งคือเพิ่มบรรทัดต่อไปนี้ลงในของคุณ ~/.bashrc:

source <(kubectl completion bash)

วิธีที่สองคือการเพิ่มสคริปต์เติมข้อความอัตโนมัติลงในโฟลเดอร์ /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

วิธีนี้จะใช้ได้เฉพาะเมื่อคุณติดตั้ง bash-completion โดยใช้ Homebrew ในกรณีนี้ bash-completion จะโหลดสคริปต์ทั้งหมดจากไดเร็กทอรีนี้

หากคุณติดตั้ง kubectl โดยใช้ Homebrewดังนั้นจึงไม่จำเป็นต้องดำเนินการขั้นตอนก่อนหน้า เนื่องจากสคริปต์การเติมข้อความอัตโนมัติจะถูกวางในโฟลเดอร์โดยอัตโนมัติ /usr/local/etc/bash_completion.d ระหว่างการติดตั้ง ในกรณีนี้ การเติมข้อความอัตโนมัติ kubectl จะเริ่มทำงานทันทีที่คุณติดตั้ง bash-completion

ด้วยเหตุนี้ ตัวเลือกทั้งหมดจึงเทียบเท่ากัน

zsh

สคริปต์การเติมข้อความอัตโนมัติสำหรับ Zsh ไม่จำเป็นต้องมีการขึ้นต่อกันใดๆ สิ่งที่คุณต้องทำคือเปิดใช้งานเมื่อคุณโหลดเชลล์คำสั่ง

คุณสามารถทำได้โดยเพิ่มบรรทัดลงในของคุณ ~/.zshrc ไฟล์:

source <(kubectl completion zsh)

หากคุณได้รับข้อผิดพลาด not found: compdef หลังจากรีสตาร์ทเชลล์ คุณจะต้องเปิดใช้งานฟังก์ชันบิวท์อิน compdef. คุณสามารถเปิดใช้งานได้โดยเพิ่มไปที่จุดเริ่มต้นของไฟล์ ~/.zshrc ต่อไปนี้:

autoload -Uz compinit
compinit

2. ดูข้อกำหนดทรัพยากรอย่างรวดเร็ว

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

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

รูปแบบคำสั่งมีดังนี้:

$ kubectl explain resource[.field]...

คำสั่งจะส่งออกข้อกำหนดของทรัพยากรหรือฟิลด์ที่ร้องขอ ข้อมูลที่แสดงจะเหมือนกับข้อมูลที่มีอยู่ในคู่มือ API

Поумолчанию kubectl explain แสดงเฉพาะการซ้อนฟิลด์ระดับแรกเท่านั้น

ดูว่ามีลักษณะอย่างไร ได้ที่นี่.

คุณสามารถแสดงทั้งต้นไม้ได้หากคุณเพิ่มตัวเลือก --recursive:

$ kubectl explain deployment.spec --recursive

หากคุณไม่ทราบว่าจำเป็นต้องใช้ทรัพยากรใด คุณสามารถแสดงทรัพยากรทั้งหมดได้โดยใช้คำสั่งต่อไปนี้:

$ kubectl api-resources

คำสั่งนี้แสดงชื่อทรัพยากรในรูปแบบพหูพจน์ เช่น deployments แทน deployment. นอกจากนี้ยังแสดงชื่อย่ออีกด้วย deployสำหรับทรัพยากรเหล่านั้นที่มีอยู่ ไม่ต้องกังวลกับความแตกต่างเหล่านี้ ตัวเลือกการตั้งชื่อทั้งหมดนี้เทียบเท่ากับ kubectl นั่นคือคุณสามารถใช้อันใดก็ได้เพื่อ kubectl explain.

คำสั่งต่อไปนี้ทั้งหมดเทียบเท่ากัน:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. ใช้รูปแบบเอาต์พุตคอลัมน์แบบกำหนดเอง

รูปแบบเอาต์พุตคำสั่งเริ่มต้น kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

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

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

การใช้รูปแบบที่กำหนดเองถูกกำหนดโดยใช้ตัวเลือก:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

คุณสามารถกำหนดแต่ละคอลัมน์เอาต์พุตเป็นคู่ได้ <header>:<jsonpath>ที่ไหน <header> คือชื่อคอลัมน์ และ <jsonpath> — นิพจน์ที่กำหนดเขตข้อมูลทรัพยากร

ลองดูตัวอย่างง่ายๆ:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

เอาต์พุตมีหนึ่งคอลัมน์ที่มีชื่อของพ็อด

นิพจน์ตัวเลือกจะเลือกชื่อพ็อดจากฟิลด์ metadata.name. เนื่องจากชื่อของพ็อดถูกกำหนดไว้ในฟิลด์ชื่อลูก metadata ในคำอธิบายทรัพยากรของพ็อด รายละเอียดเพิ่มเติมสามารถพบได้ใน คู่มือ API หรือพิมพ์คำสั่ง kubectl explain pod.metadata.name.

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

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

นิพจน์เลือกชื่อโหนดจาก spec.nodeName — เมื่อพ็อดถูกกำหนดให้กับโหนด ชื่อของมันจะถูกเขียนลงในฟิลด์ spec.nodeName ข้อกำหนดทรัพยากรพ็อด ข้อมูลรายละเอียดเพิ่มเติมสามารถพบได้ในผลลัพธ์ kubectl explain pod.spec.nodeName.

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

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

แต่ก่อนอื่น เรามาดูนิพจน์การเลือกฟิลด์ให้ละเอียดยิ่งขึ้น

นิพจน์ JSONPath

นิพจน์สำหรับการเลือกฟิลด์ทรัพยากรจะขึ้นอยู่กับ JSONPath.

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

Kubectl อธิบายรองรับฟีเจอร์ JSONPath ในจำนวนจำกัด ความเป็นไปได้และตัวอย่างการใช้งานมีอธิบายไว้ด้านล่าง:

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

ตัวดำเนินการ [] มีความสำคัญอย่างยิ่ง ช่องทรัพยากร Kubernetes หลายช่องเป็นรายการ และโอเปอเรเตอร์นี้ให้คุณเลือกสมาชิกของรายการเหล่านั้นได้ มักใช้กับไวด์การ์ด เช่น [*] เพื่อเลือกองค์ประกอบทั้งหมดของรายการ

ตัวอย่างการใช้งาน

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

การแสดงภาพคอนเทนเนอร์สำหรับพ็อด:
```
$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

NAME                        IMAGES
engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4      wordpress
```
คำสั่งนี้แสดงชื่ออิมเมจคอนเทนเนอร์สำหรับแต่ละพ็อด

โปรดจำไว้ว่าพ็อดสามารถบรรจุได้หลายคอนเทนเนอร์ จากนั้นชื่อรูปภาพจะแสดงในบรรทัดเดียวโดยคั่นด้วยเครื่องหมายจุลภาค
การแสดงโซนความพร้อมใช้งานของโหนด:
```
$ kubectl get nodes 
  -o 
custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'

NAME                          ZONE
ip-10-0-118-34.ec2.internal   us-east-1b
ip-10-0-36-80.ec2.internal    us-east-1a
ip-10-0-80-67.ec2.internal    us-east-1b
```
คำสั่งนี้มีประโยชน์หากคลัสเตอร์ของคุณโฮสต์อยู่ในคลาวด์สาธารณะ จะแสดงโซนความพร้อมใช้งานสำหรับแต่ละโหนด

โซนความพร้อมใช้งานเป็นแนวคิดระบบคลาวด์ที่จำกัดโซนการจำลองให้อยู่ในภูมิภาคทางภูมิศาสตร์

โซนความพร้อมใช้งานสำหรับแต่ละโหนดจะได้รับผ่านป้ายกำกับพิเศษ - failure-domain.beta.kubernetes.io/zone. หากคลัสเตอร์ทำงานในคลาวด์สาธารณะ ป้ายนี้จะถูกสร้างขึ้นโดยอัตโนมัติและเต็มไปด้วยชื่อของโซนความพร้อมใช้งานสำหรับแต่ละโหนด

ป้ายกำกับไม่ได้เป็นส่วนหนึ่งของข้อกำหนดทรัพยากร Kubernetes ดังนั้นคุณจะไม่พบข้อมูลเกี่ยวกับป้ายกำกับเหล่านั้น คู่มือ API. อย่างไรก็ตาม สามารถมองเห็นได้ (เช่นเดียวกับป้ายกำกับอื่นๆ) หากคุณขอข้อมูลเกี่ยวกับโหนดในรูปแบบ YAML หรือ JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
นี่เป็นวิธีที่ดีในการเรียนรู้เพิ่มเติมเกี่ยวกับทรัพยากร นอกเหนือจากข้อกำหนดเฉพาะของทรัพยากรการเรียนรู้

4. สลับระหว่างคลัสเตอร์และเนมสเปซได้อย่างง่ายดาย

เมื่อ kubectl ส่งคำขอไปยัง Kubernetes API ขั้นแรกจะอ่านไฟล์ kubeconfig เพื่อรับพารามิเตอร์ที่จำเป็นทั้งหมดสำหรับการเชื่อมต่อ

ตามค่าเริ่มต้นไฟล์ kubeconfig จะเป็น ~/.kube/config. โดยทั่วไปไฟล์นี้จะถูกสร้างหรืออัพเดตโดยคำสั่งพิเศษ

เมื่อคุณทำงานกับหลายคลัสเตอร์ ไฟล์ kubeconfig จะมีการตั้งค่าสำหรับการเชื่อมต่อกับคลัสเตอร์เหล่านั้นทั้งหมด คุณต้องมีวิธีบอกคำสั่ง kubectl ว่าคลัสเตอร์ใดที่คุณใช้งานอยู่

ภายในคลัสเตอร์ คุณสามารถสร้างเนมสเปซได้หลายรายการ ซึ่งเป็นคลัสเตอร์เสมือนประเภทหนึ่งภายในคลัสเตอร์จริง นอกจากนี้ Kubectl ยังกำหนดว่าจะใช้เนมสเปซใดโดยอิงตามไฟล์ kubeconfig ซึ่งหมายความว่าคุณยังต้องมีวิธีบอกคำสั่ง kubectl ว่าเนมสเปซใดที่จะใช้งานได้

ในบทนี้เราจะอธิบายวิธีการทำงานและวิธีทำให้ทำงานอย่างมีประสิทธิผล

โปรดทราบว่าคุณอาจมีไฟล์ kubeconfig หลายไฟล์แสดงรายการอยู่ในตัวแปรสภาพแวดล้อม KUBECONFIG ในกรณีนี้ ไฟล์ทั้งหมดเหล่านี้จะรวมกันเป็นการกำหนดค่าทั่วไปเดียวในขณะรันไทม์ คุณยังสามารถเปลี่ยนไฟล์ kubeconfig เริ่มต้นได้ด้วยการรัน kubectl ด้วยพารามิเตอร์ --kubeconfig. ดู เอกสารอย่างเป็นทางการ.

ไฟล์ kubeconfig

มาดูกันว่าไฟล์ kubeconfig มีอะไรบ้าง:

อย่างที่คุณเห็นไฟล์ kubeconfig มีชุดของบริบท บริบทประกอบด้วยสามองค์ประกอบ:

คลัสเตอร์ — URL API ของเซิร์ฟเวอร์คลัสเตอร์
ผู้ใช้ - ข้อมูลรับรองการตรวจสอบผู้ใช้ในคลัสเตอร์
เนมสเปซ - เนมสเปซที่ใช้เมื่อเข้าร่วมคลัสเตอร์

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

ในช่วงเวลาใดก็ตาม บริบทหนึ่งจะเป็นปัจจุบัน:

เมื่อ kubectl อ่านไฟล์การกำหนดค่า ไฟล์นั้นจะดึงข้อมูลจากบริบทปัจจุบันเสมอ ในตัวอย่างข้างต้น kubectl จะเชื่อมต่อกับคลัสเตอร์ Hare

ดังนั้น หากต้องการสลับไปยังคลัสเตอร์อื่น คุณต้องเปลี่ยนบริบทปัจจุบันในไฟล์ kubeconfig:

ตอนนี้ kubectl จะเชื่อมต่อกับคลัสเตอร์ Fox

หากต้องการสลับไปใช้เนมสเปซอื่นในคลัสเตอร์เดียวกัน คุณต้องเปลี่ยนค่าขององค์ประกอบเนมสเปซสำหรับบริบทปัจจุบัน:

ในตัวอย่างข้างต้น kubectl จะใช้เนมสเปซ Prod ของคลัสเตอร์ Fox (ก่อนหน้านี้มีการตั้งค่าเนมสเปซการทดสอบ)

โปรดทราบว่า kubectl ยังมีตัวเลือกต่างๆ ให้เลือกด้วย --cluster, --user, --namespace и --contextซึ่งช่วยให้คุณสามารถเขียนทับแต่ละองค์ประกอบและบริบทปัจจุบันได้ โดยไม่คำนึงถึงสิ่งที่ตั้งค่าไว้ใน kubeconfig ดู kubectl options.

ตามทฤษฎีแล้ว คุณสามารถเปลี่ยนการตั้งค่าใน kubeconfig ได้ด้วยตนเอง แต่มันไม่สะดวก เพื่อให้การดำเนินการเหล่านี้ง่ายขึ้น มียูทิลิตี้หลายอย่างที่ให้คุณเปลี่ยนพารามิเตอร์ได้โดยอัตโนมัติ

ใช้ kubectx

ยูทิลิตี้ยอดนิยมสำหรับการสลับระหว่างคลัสเตอร์และเนมสเปซ

ยูทิลิตี้จัดเตรียมคำสั่ง kubectx и kubens เพื่อเปลี่ยนบริบทปัจจุบันและเนมสเปซตามลำดับ

ตามที่กล่าวไว้ การเปลี่ยนบริบทปัจจุบันหมายถึงการเปลี่ยนคลัสเตอร์หากคุณมีบริบทเดียวต่อคลัสเตอร์เท่านั้น

นี่คือตัวอย่างการรันคำสั่งเหล่านี้:

โดยพื้นฐานแล้ว คำสั่งเหล่านี้เพียงแก้ไขไฟล์ kubeconfig ตามที่อธิบายไว้ข้างต้น

ติดตั้ง kubectx, ปฏิบัติตามคำแนะนำใน Github

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

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

การใช้นามแฝงของเชลล์

คุณไม่จำเป็นต้องใช้เครื่องมือแยกต่างหากในการเปลี่ยนบริบทและเนมสเปซปัจจุบัน เนื่องจาก kubectl มีคำสั่งสำหรับสิ่งนี้ด้วย ใช่ครับ ทีม kubectl config จัดเตรียมคำสั่งย่อยสำหรับการแก้ไขไฟล์ kubeconfig

นี่คือบางส่วนของพวกเขาคือ

kubectl config get-contexts: แสดงบริบททั้งหมด
kubectl config current-context: รับบริบทปัจจุบัน
kubectl config use-context: เปลี่ยนบริบทปัจจุบัน
kubectl config set-context: เปลี่ยนองค์ประกอบบริบท

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

ฉันสร้างชุดนามแฝงตามคำสั่งเหล่านี้ซึ่งมีฟังก์ชันการทำงานคล้ายกับ kubectx คุณสามารถดูการทำงานของพวกมันได้ที่นี่:

โปรดทราบว่านามแฝงใช้ fzf เพื่อจัดเตรียมอินเทอร์เฟซการค้นหาแบบโต้ตอบฟรี (เช่น โหมดโต้ตอบของ kubectx) ซึ่งหมายความว่าคุณต้องการ ติดตั้ง fzfเพื่อใช้นามแฝงเหล่านี้

ต่อไปนี้เป็นคำจำกัดความของนามแฝง:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

หากต้องการตั้งชื่อแทนเหล่านี้ คุณต้องเพิ่มคำจำกัดความข้างต้นลงในไฟล์ของคุณ ~/.bashrc หรือ ~/.zshrc และรีบูตเชลล์ของคุณ

การใช้ปลั๊กอิน

Kubectl ช่วยให้คุณสามารถโหลดปลั๊กอินที่ดำเนินการในลักษณะเดียวกับคำสั่งพื้นฐาน ตัวอย่างเช่น คุณสามารถติดตั้งปลั๊กอิน kubectl-foo และเรียกใช้โดยดำเนินการคำสั่ง kubectl foo.

การเปลี่ยนบริบทและเนมสเปซด้วยวิธีนี้จะสะดวกกว่า เช่น โดยการรัน kubectl ctx เพื่อเปลี่ยนบริบทและ kubectl ns เพื่อเปลี่ยนเนมสเปซ

ฉันได้เขียนปลั๊กอินสองตัวที่ทำสิ่งนี้:

การทำงานของปลั๊กอินจะขึ้นอยู่กับนามแฝงจากส่วนก่อนหน้า

นี่คือวิธีการทำงาน:

โปรดทราบว่าปลั๊กอินใช้ fzf เพื่อจัดเตรียมอินเทอร์เฟซการค้นหาเชิงโต้ตอบฟรี (เช่น โหมดโต้ตอบของ kubectx) ซึ่งหมายความว่าคุณต้องการ ติดตั้ง fzfเพื่อใช้นามแฝงเหล่านี้

ในการติดตั้งปลั๊กอิน คุณจะต้องดาวน์โหลดเชลล์สคริปต์ที่มีชื่อ kubectl-ctx и kubectl-ns ไปยังไดเร็กทอรีใด ๆ ในตัวแปร PATH ของคุณและทำให้สามารถเรียกใช้งานได้เช่น chmod +x. หลังจากนี้คุณก็สามารถใช้งานได้ทันที kubectl ctx и kubectl ns.

5. ลดอินพุตด้วยนามแฝงอัตโนมัติ

นามแฝงของเชลล์เป็นวิธีที่ดีในการเร่งความเร็วอินพุต โครงการ kubectl-นามแฝง มีทางลัดประมาณ 800 รายการสำหรับคำสั่ง kubectl พื้นฐาน

คุณอาจสงสัยว่า - คุณจำนามแฝง 800 ชื่อได้อย่างไร? แต่คุณไม่จำเป็นต้องจำทั้งหมดเพราะมันถูกสร้างขึ้นตามรูปแบบง่ายๆ ซึ่งมีดังต่อไปนี้:

ตัวอย่างเช่น:

kgpooyaml - kubectl รับพ็อด oyaml
ksysgsvcw — kubectl -n kube-system รับ svc w
ksysrmcm -kubectl -n kube-ระบบ rm ซม
kgdepallsl - kubectl รับการปรับใช้ sl ทั้งหมด

อย่างที่คุณเห็น นามแฝงประกอบด้วยส่วนประกอบต่างๆ ซึ่งแต่ละองค์ประกอบแสดงถึงองค์ประกอบเฉพาะของคำสั่ง kubectl แต่ละนามแฝงสามารถมีหนึ่งคอมโพเนนต์สำหรับคำสั่งพื้นฐาน การดำเนินการ และทรัพยากร และคอมโพเนนต์หลายรายการสำหรับพารามิเตอร์ คุณเพียงแค่ "เติม" ส่วนประกอบเหล่านี้จากซ้ายไปขวาตามแผนภาพด้านบน

แผนภาพรายละเอียดปัจจุบันอยู่ที่ GitHub. ที่นั่นคุณยังสามารถหาได้ รายการนามแฝงทั้งหมด.

ตัวอย่างเช่น นามแฝง kgpooyamlall เทียบเท่ากับคำสั่ง kubectl get pods -o yaml --all-namespaces.

ลำดับสัมพัทธ์ของตัวเลือกไม่สำคัญ: command kgpooyamlall เทียบเท่ากับคำสั่ง kgpoalloyaml.

คุณไม่จำเป็นต้องใช้ส่วนประกอบทั้งหมดเป็นนามแฝง ตัวอย่างเช่น k, kg, klo, ksys, kgpo ยังสามารถใช้ได้ นอกจากนี้ คุณยังสามารถรวมนามแฝงและคำสั่งหรือตัวเลือกปกติบนบรรทัดคำสั่งได้:

ตัวอย่างเช่น:

แทนการ kubectl proxy คุณสามารถเขียน k proxy.
แทนการ kubectl get roles คุณสามารถเขียน kg roles (ขณะนี้ไม่มีนามแฝงสำหรับทรัพยากรบทบาท)
หากต้องการรับข้อมูลสำหรับพ็อดเฉพาะ คุณสามารถใช้คำสั่ง kgpo my-pod — kubectl get pod my-pod.

โปรดทราบว่านามแฝงบางรายการจำเป็นต้องมีอาร์กิวเมนต์บรรทัดคำสั่ง ตัวอย่างเช่น นามแฝง kgpol วิธี kubectl get pods -l. ตัวเลือก -l ต้องมีอาร์กิวเมนต์ - ข้อกำหนดของป้ายกำกับ หากคุณใช้นามแฝงมันจะมีลักษณะเช่นนี้ kgpol app=ui.

เนื่องจากนามแฝงบางตัวจำเป็นต้องมีอาร์กิวเมนต์ จึงต้องใช้นามแฝง a, f และ l เป็นอันดับสุดท้าย

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

การติดตั้ง

หากต้องการติดตั้ง kubectl-aliases คุณต้องดาวน์โหลดไฟล์ .kubectl_aliases จาก GitHub และรวมไว้ในไฟล์ ~/.bashrc หรือ ~/.zshrc:

source ~/.kubectl_aliases

การเติมข้อความอัตโนมัติ

ดังที่เราได้กล่าวไว้ก่อนหน้านี้ คุณมักจะเพิ่มคำเพิ่มเติมให้กับนามแฝงบนบรรทัดคำสั่ง ตัวอย่างเช่น:

$ kgpooyaml test-pod-d4b77b989

หากคุณใช้การเติมคำสั่ง kubectl คุณอาจเคยใช้การเติมข้อความอัตโนมัติสำหรับสิ่งต่างๆ เช่น ชื่อทรัพยากร แต่สามารถทำได้เมื่อใช้นามแฝงหรือไม่?

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

คำตอบขึ้นอยู่กับเชลล์ที่คุณใช้:

สำหรับ Zsh การเติมนามแฝงให้เสร็จสิ้นสามารถทำได้ทันที
น่าเสียดายที่ Bash ต้องทำงานบางอย่างเพื่อให้การเติมข้อความอัตโนมัติทำงานได้

การเปิดใช้งานการเติมข้อความอัตโนมัติสำหรับนามแฝงใน Bash

ปัญหาของ Bash คือมันพยายามทำให้นามแฝงเสร็จสมบูรณ์ (ทุกครั้งที่คุณกด Tab) ไม่ใช่คำสั่งที่นามแฝงอ้างถึง (อย่างที่ Zsh ทำ เป็นต้น) เนื่องจากคุณไม่มีสคริปต์การเติมสคริปต์สำหรับนามแฝงทั้ง 800 รายการ การเติมข้อความอัตโนมัติจึงไม่ทำงาน

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

ต่อไปนี้ ฉันจะอธิบายวิธีการติดตั้งนามแฝงแบบสมบูรณ์ก่อน จากนั้นจึงจะกำหนดค่าให้เปิดใช้งานการดำเนินการให้เสร็จสิ้นสำหรับนามแฝง kubectl ทั้งหมด

การติดตั้งนามแฝงที่สมบูรณ์

ก่อนอื่นเลย ขึ้นอยู่กับนามแฝงที่สมบูรณ์ ทุบตีเสร็จ. ดังนั้น ก่อนที่จะติดตั้ง complete-alias คุณต้องตรวจสอบให้แน่ใจว่าได้ติดตั้ง bash-completion แล้ว คำแนะนำในการติดตั้งมีให้ไว้ก่อนหน้านี้สำหรับ Linux และ MacOS

หมายเหตุสำคัญสำหรับผู้ใช้ MacOS: เช่นเดียวกับสคริปต์การเติมข้อความอัตโนมัติ kubectl นามแฝงที่สมบูรณ์ไม่สามารถใช้ได้กับ Bash 3.2 ซึ่งเป็นค่าเริ่มต้นบน MacOS โดยเฉพาะอย่างยิ่ง complete-alias ขึ้นอยู่กับ bash-completion v2 (brew install bash-completion@2) ซึ่งต้องใช้ Bash 4.1 เป็นอย่างน้อย ซึ่งหมายความว่าหากต้องการใช้นามแฝงที่สมบูรณ์บน MacOS คุณจะต้องติดตั้ง Bash เวอร์ชันที่ใหม่กว่า

คุณต้องดาวน์โหลดสคริปต์ bash_completion.sh ของ พื้นที่เก็บข้อมูล GitHub และรวมไว้ในไฟล์ของคุณ ~/.bashrc:

source ~/bash_completion.sh

หลังจากรีบูตเชลล์แล้ว นามแฝงที่สมบูรณ์จะถูกติดตั้งโดยสมบูรณ์

การเปิดใช้งานการเติมข้อความอัตโนมัติสำหรับนามแฝง kubectl

นามแฝงที่สมบูรณ์ทางเทคนิคมีฟังก์ชัน wrapper _complete_alias. ฟังก์ชันนี้จะตรวจสอบนามแฝงและส่งคืนคำแนะนำในการทำให้สมบูรณ์สำหรับคำสั่งนามแฝง

หากต้องการเชื่อมโยงฟังก์ชันกับนามแฝงเฉพาะ คุณต้องใช้กลไก Bash ในตัว สมบูรณ์, ติดตั้ง _complete_alias เป็นฟังก์ชันการเติมนามแฝง

ตัวอย่างเช่น ลองใช้นามแฝง k ซึ่งย่อมาจากคำสั่ง kubectl ติดตั้ง _complete_alias เนื่องจากเป็นฟังก์ชันเสริมสำหรับนามแฝงนี้ คุณควรรันคำสั่งต่อไปนี้:

$ complete -F _complete_alias k

ผลลัพธ์ก็คือเมื่อใดก็ตามที่คุณเติมนามแฝง k โดยอัตโนมัติ ฟังก์ชันนี้จะถูกเรียกใช้ _complete_aliasซึ่งจะตรวจสอบนามแฝงและส่งคืนคำแนะนำในการทำให้คำสั่งเสร็จสมบูรณ์ kubectl.

เป็นตัวอย่างที่สอง ลองใช้นามแฝง kgซึ่งหมายถึง kubectl get:

$ complete -F _complete_alias kg

เช่นเดียวกับในตัวอย่างก่อนหน้านี้ เมื่อคุณเติมข้อมูลกิโลกรัมอัตโนมัติ คุณจะได้รับคำแนะนำในการเติมให้สมบูรณ์แบบเดียวกับที่คุณได้รับ kubectl get.

โปรดทราบว่าคุณสามารถใช้นามแฝงที่สมบูรณ์สำหรับนามแฝงใดๆ ในระบบของคุณได้

ดังนั้น หากต้องการเปิดใช้งานการเติมข้อความอัตโนมัติสำหรับนามแฝง kubectl ทั้งหมด คุณต้องเรียกใช้คำสั่งด้านบนสำหรับแต่ละนามแฝง ตัวอย่างต่อไปนี้จะทำสิ่งนี้ทุกประการ หากคุณได้ตั้งค่านามแฝง kubectl เป็น ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

โค้ดชิ้นนี้จะต้องอยู่ในของคุณ ~/.bashrcให้รีสตาร์ทเชลล์คำสั่งและการเติมข้อความอัตโนมัติจะพร้อมใช้งานสำหรับนามแฝง kubectl ทั้งหมด 800 รายการ

6. การขยาย kubectl ด้วยปลั๊กอิน

เริ่มจาก เวอร์ชัน 1.12, kubectl รองรับ กลไกปลั๊กอินซึ่งช่วยให้คุณสามารถขยายฟังก์ชันด้วยคำสั่งเพิ่มเติมได้

ถ้าคุณรู้จัก กลไกปลั๊กอิน Gitจากนั้นปลั๊กอิน kubectl จะถูกสร้างขึ้นบนหลักการเดียวกัน

ในบทนี้ เราจะกล่าวถึงวิธีการติดตั้งปลั๊กอิน ตำแหน่งที่จะค้นหา และวิธีการสร้างปลั๊กอินของคุณเอง

การติดตั้งปลั๊กอิน

ปลั๊กอิน Kubectl ได้รับการแจกจ่ายเป็นไฟล์ปฏิบัติการธรรมดาที่มีชื่อดังนี้ kubectl-x. คำนำหน้า kubectl- จำเป็นต้องมี ตามด้วยคำสั่งย่อย kubectl ใหม่ที่อนุญาตให้คุณเรียกใช้ปลั๊กอิน

ตัวอย่างเช่น ปลั๊กอิน hello จะถูกแจกจ่ายเป็นไฟล์ที่เรียกว่า kubectl-hello.

หากต้องการติดตั้งปลั๊กอิน คุณต้องคัดลอกไฟล์ kubectl-x ไปยังไดเร็กทอรีใด ๆ ใน PATH ของคุณและทำให้สามารถเรียกใช้งานได้เช่นด้วย chmod +x. หลังจากนั้นคุณสามารถเรียกใช้ปลั๊กอินได้ kubectl x.

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

$ kubectl plugin list

คำสั่งนี้จะแสดงคำเตือนหากคุณมีปลั๊กอินหลายตัวที่มีชื่อเดียวกัน หรือหากมีไฟล์ปลั๊กอินที่ไม่สามารถเรียกใช้งานได้

การค้นหาและติดตั้งปลั๊กอินโดยใช้ Krew

ปลั๊กอิน Kubectl สามารถใช้ร่วมกันหรือนำมาใช้ซ้ำได้เช่นเดียวกับชุดซอฟต์แวร์ แต่คุณจะพบปลั๊กอินที่คนอื่นแชร์ได้ที่ไหน?

โครงการครู มุ่งหวังที่จะมอบโซลูชั่นแบบครบวงจรสำหรับการแชร์ ค้นหา ติดตั้ง และจัดการปลั๊กอิน kubectl โครงการเรียกตัวเองว่า "ตัวจัดการแพ็คเกจสำหรับปลั๊กอิน kubectl" (Krew คล้ายกับ ชง).

Krew คือรายการปลั๊กอิน kubectl ที่คุณสามารถเลือกและติดตั้งได้ ในเวลาเดียวกัน Krew ยังเป็นปลั๊กอินสำหรับ kubectl อีกด้วย

ซึ่งหมายความว่าการติดตั้ง Krew จะทำงานเหมือนกับการติดตั้งปลั๊กอิน kubectl อื่นๆ คุณสามารถดูคำแนะนำโดยละเอียดได้ที่ หน้า GitHub.

คำสั่ง Krew ที่สำคัญที่สุดคือ:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

โปรดทราบว่าการติดตั้งปลั๊กอินโดยใช้ Krew จะไม่รบกวนการติดตั้งปลั๊กอินโดยใช้วิธีมาตรฐานที่อธิบายไว้ข้างต้น

โปรดทราบว่าคำสั่ง kubectl krew list แสดงเฉพาะปลั๊กอินที่ติดตั้งโดยใช้ Krew ในขณะที่คำสั่ง kubectl plugin list แสดงรายการปลั๊กอินทั้งหมด ได้แก่ ปลั๊กอินที่ติดตั้งโดยใช้ Krew และปลั๊กอินที่ติดตั้งโดยวิธีอื่น

ค้นหาปลั๊กอินที่อื่น

Krew เป็นโปรเจ็กต์ใหม่ที่กำลังอยู่ในระหว่างดำเนินการ รายการ มีปลั๊กอินประมาณ 30 รายการเท่านั้น หากคุณไม่พบสิ่งที่ต้องการ คุณสามารถค้นหาปลั๊กอินจากที่อื่นได้ เช่น GitHub

ฉันแนะนำให้ดูที่ส่วน GitHub kubectl-ปลั๊กอิน. ที่นั่นคุณจะพบกับปลั๊กอินที่มีอยู่มากมายซึ่งควรค่าแก่การตรวจสอบ

การเขียนปลั๊กอินของคุณเอง

คุณเองก็ได้ สร้างปลั๊กอิน - มันไม่ใช่เรื่องยาก คุณต้องสร้างไฟล์ปฏิบัติการที่ทำสิ่งที่คุณต้องการตั้งชื่อตามนั้น kubectl-x และติดตั้งตามที่อธิบายไว้ข้างต้น

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

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

สร้างไฟล์ kubectl-img เนื้อหาต่อไปนี้:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

ตอนนี้ทำให้ไฟล์ปฏิบัติการได้ด้วย chmod +x kubectl-img และย้ายไปยังไดเร็กทอรีใดก็ได้ใน PATH ของคุณ หลังจากนี้คุณสามารถใช้ปลั๊กอินได้ทันที kubectl img.

ตามที่กล่าวไว้ ปลั๊กอิน kubectl สามารถเขียนด้วยภาษาโปรแกรมหรือภาษาสคริปต์ใดก็ได้ หากคุณใช้เชลล์สคริปต์ ข้อดีของการสามารถเรียก kubectl จากภายในปลั๊กอินได้อย่างง่ายดาย อย่างไรก็ตาม คุณสามารถเขียนปลั๊กอินที่ซับซ้อนมากขึ้นในภาษาโปรแกรมจริงได้โดยใช้ ไลบรารีไคลเอนต์ Kubernetes. หากคุณใช้ Go คุณก็สามารถใช้ได้เช่นกัน ไลบรารี cli-รันไทม์ซึ่งมีไว้เพื่อการเขียนปลั๊กอิน kubectl โดยเฉพาะ

วิธีแชร์ปลั๊กอินของคุณ

หากคุณคิดว่าปลั๊กอินของคุณอาจเป็นประโยชน์ต่อผู้อื่น โปรดแชร์บน GitHub ได้เลย อย่าลืมเพิ่มลงในหัวข้อ kubectl-ปลั๊กอิน.

คุณยังสามารถขอให้เพิ่มปลั๊กอินของคุณได้ รายการกรู. คำแนะนำเกี่ยวกับวิธีการทำเช่นนี้อยู่ใน ที่เก็บ GitHub.

คำสั่งเสร็จสิ้น

ขณะนี้ปลั๊กอินไม่รองรับการเติมข้อความอัตโนมัติ นั่นคือคุณต้องป้อนชื่อเต็มของปลั๊กอินและชื่อเต็มของอาร์กิวเมนต์

พื้นที่เก็บข้อมูล GitHub kubectl สำหรับฟังก์ชันนี้มี เปิดคำขอ. ดังนั้นจึงเป็นไปได้ที่คุณลักษณะนี้จะถูกนำมาใช้ในอนาคต

ขอให้โชคดี!!!

มีอะไรอีกให้อ่านในหัวข้อ:

ที่มา: will.com

วิธีใช้ kubectl อย่างมีประสิทธิภาพมากขึ้น: คำแนะนำโดยละเอียด