266

สิ่งที่ฉันเข้าใจในเอกสารประกอบคือ:

kubectl create = สร้างทรัพยากร k8s ใหม่ในคลัสเตอร์
kubectl replace = อัปเดตทรัพยากรในคลัสเตอร์สด
kubectl ใช้ = ถ้าฉันต้องการสร้าง + แทนที่ ( ข้อมูลอ้างอิง )

คำถามของฉันคือ

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

kubernetes kubectl

— สุเรชวิษณุ
แหล่งที่มา

315

นี่เป็นสองแนวทางที่แตกต่าง:

การจัดการความจำเป็น

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

การจัดการการประกาศ

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

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการจัดการที่จำเป็นและการประกาศในเอกสารการจัดการวัตถุของ Kubernetes

— Ara Pulido
แหล่งที่มา

24

ต้องใช้อันไหนในการผลิต

— Yogesh Jilhawar

11

@YogeshJilhawar ทั้งสองเป็นวิธีที่ถูกต้องในการทำงานในการผลิต

— guival

2

ดังนั้นโดยสรุปแล้วมันเหมือนกับการดัดแปลงวัตถุทั้งหมดกับแพทช์บางส่วน?

— Ryall

12

คำตอบนี้ไม่ได้ยืนยันว่าการดำเนินการทั้งสองนี้kubectl createและkubectl applyมีผลเหมือนกันหรือไม่

— นาวาซ

61

@Nawaz - พวกเขาทำสิ่งต่าง ๆ kubectl createจะโยนข้อผิดพลาดหากทรัพยากรมีอยู่แล้ว kubectl applyเคยชิน. ความแตกต่างคือที่kubectl createระบุว่า "สร้างสิ่งนี้โดยเฉพาะ" ในขณะที่kubectl applyพูดว่า "ทำสิ่งที่จำเป็น (สร้างปรับปรุง ฯลฯ ) เพื่อให้มีลักษณะเช่นนี้"

— นาย Llama

44

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

สิ่งที่คุณสามารถทำได้คือการใช้ (รูปแบบการประกาศ) ผลลัพธ์ของคำสั่งที่จำเป็นของคุณโดยใช้--dry-run=trueและ-o yamlตัวเลือก:

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

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

สิ่งนี้มีประโยชน์มากในบางกรณีที่คุณไม่สามารถใช้รูปแบบการประกาศได้ (ตัวอย่างเช่นเมื่อสร้างความลับนักเทียบท่า - สตรี)

— เซบาสเตียนแดน
แหล่งที่มา

หรือลบทรัพยากรก่อนสร้างด้วยแฟล็ก --ignore-not-found นี้จะไม่เพิ่มAlreadyExistsข้อผิดพลาด ตัวอย่างเช่น:kubectl delete deployment nginx --ignore-not-found; kubectl create deployment nginx --image=nginx

— Noam Manos

33

เพียงเพื่อให้คำตอบที่ตรงไปตรงมามากขึ้นจากความเข้าใจของฉัน:

apply- ทำการเปลี่ยนแปลงที่เพิ่มขึ้นกับวัตถุที่มีอยู่
create- สร้างวัตถุใหม่ทั้งหมด (ก่อนหน้านี้ไม่มีอยู่ / ลบ)

การทำสิ่งนี้จากบทความ DigitalOceanซึ่งเชื่อมโยงโดยเว็บไซต์ Kubernetes:

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

— User9123
แหล่งที่มา

ใช่ไหม? เหมือนตอนที่เราใช้นักแต่งเพลงประกอบ: + ใช้applyเหมือนdocker-compose up -d+ ใช้createชอบdocker-compose up -d --buildไหม?

— Whoiskp

8

เหล่านี้คือคำสั่งที่จำเป็น :

kubectl run = kubectl create deployment

ข้อดี:

ง่ายง่ายต่อการเรียนรู้และจดจำได้ง่าย
ต้องการเพียงขั้นตอนเดียวในการเปลี่ยนแปลงคลัสเตอร์

ข้อเสีย:

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

เหล่านี้คือการกำหนดค่าวัตถุที่จำเป็น :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

ข้อดีเมื่อเปรียบเทียบกับคำสั่งที่จำเป็น:

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

ข้อเสียเปรียบเทียบกับคำสั่งที่จำเป็น:

ต้องการความเข้าใจพื้นฐานเกี่ยวกับสคีมาของวัตถุ
ต้องการขั้นตอนเพิ่มเติมในการเขียนไฟล์ YAML

ข้อดีเมื่อเปรียบเทียบกับการกำหนดค่าวัตถุที่เปิดเผย:

ง่ายและเข้าใจง่าย
เป็นผู้ใหญ่มากขึ้นหลังจาก Kubernetes เวอร์ชั่น 1.5

ข้อเสียเปรียบเทียบกับการกำหนดค่าวัตถุที่เปิดเผย:

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

เหล่านี้คือการกำหนดค่าวัตถุที่เปิดเผย

kubectl diff -f configs/

kubectl apply -f configs/

ข้อดีเมื่อเปรียบเทียบกับการกำหนดค่าวัตถุที่จำเป็น:

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

ข้อเสียเปรียบเทียบกับการกำหนดค่าวัตถุที่จำเป็น:

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

— โซอี้หวาดระแวง
แหล่งที่มา

3

คำอธิบายด้านล่างจากเอกสารที่เป็นทางการkubectl applyช่วยให้ฉันเข้าใจ

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

kubectl create ในทางกลับกันจะสร้างทรัพยากร (ควรเป็นที่ไม่มีอยู่)

— F01
แหล่งที่มา

1

kubectl createสามารถทำงานกับไฟล์การกำหนดค่าวัตถุได้ครั้งละหนึ่งไฟล์ สิ่งนี้เรียกว่าการจัดการที่จำเป็น

kubectl สร้างชื่อไฟล์ -f | url

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

รายละเอียด:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

— นูแมนข่าน
แหล่งที่มา

0

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

"สร้าง" เป็นเหมือนการเล่น GOD โดยนำสิ่งต่าง ๆ มาไว้ในมือของเราเอง เป็นการดีสำหรับการดีบักเฉพาะที่เมื่อคุณต้องการทำงานกับ POD เท่านั้นและไม่สนใจ abt Deployment / Replication Controller

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

— Ankur Kothari
แหล่งที่มา

kubectl ใช้ vs kubectl สร้าง?