บทแนะนำ Kubernetes - คำแนะนำที่ครอบคลุมสำหรับ Kubernetes

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

หัวข้อต่อไปนี้จะกล่าวถึงในบทช่วยสอนนี้:

• ความท้าทายโดยไม่ต้องจัดระเบียบตู้คอนเทนเนอร์
• Docker Swarm หรือ Kubernetes
• Kubernetes คืออะไร?
• คุณลักษณะของ Kubernetes
• สถาปัตยกรรม Kubernetes
• กรณีศึกษาของ Kubernetes
• Hands-On

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

ดังนั้นก่อนที่คอนเทนเนอร์จะเกิดขึ้นนักพัฒนาและผู้ทดสอบมักจะมีความสัมพันธ์ระหว่างกัน สิ่งนี้มักเกิดขึ้นเนื่องจากสิ่งที่ทำงานในฝั่ง dev จะไม่ทำงานในด้านการทดสอบ ทั้งคู่ดำรงอยู่ในสภาพแวดล้อมที่แตกต่างกัน ตอนนี้เพื่อหลีกเลี่ยงสถานการณ์ดังกล่าวมีการนำคอนเทนเนอร์มาใช้เพื่อให้ทั้งผู้พัฒนาและผู้ทดสอบอยู่ในหน้าเดียวกัน

การจัดการคอนเทนเนอร์จำนวนมากทั้งหมดเข้าด้วยกันก็เป็นปัญหาเช่นกัน บางครั้งในขณะที่ใช้งานตู้คอนเทนเนอร์ที่ด้านผลิตภัณฑ์มีปัญหาบางประการเกิดขึ้นซึ่งยังไม่ปรากฏในขั้นตอนการพัฒนา สถานการณ์แบบนี้ได้นำระบบ Container Orchestration System มาใช้

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

บทช่วยสอน Kubernetes: ความท้าทายโดยไม่ต้องจัดระเบียบคอนเทนเนอร์

ฉันจะรวบรวมโปรแกรม java ได้อย่างไร

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

ตอนนี้เพื่อหลีกเลี่ยงการตั้งค่าบริการด้วยตนเองและเอาชนะความท้าทายจำเป็นต้องมีบางสิ่งที่ยิ่งใหญ่ นี่คือที่ที่ Container Orchestration Engine เข้ามาในรูปภาพ.

เอ็นจิ้นนี้ช่วยให้เราสามารถจัดระเบียบตู้คอนเทนเนอร์หลาย ๆ ตู้ในลักษณะที่เปิดใช้งานเครื่องที่อยู่เบื้องหลังทั้งหมดคอนเทนเนอร์มีสุขภาพดีและกระจายในสภาพแวดล้อมแบบคลัสเตอร์ ในโลกปัจจุบันส่วนใหญ่มีเครื่องยนต์สองประเภทดังกล่าว: ผู้ว่าการ & Docker Swarm .

บทแนะนำ Kubernetes: Kubernetes เทียบกับ Docker Swarm

ผู้ว่าการ และ Docker Swarm เป็นเครื่องมือจัดเรียงตู้คอนเทนเนอร์ชั้นนำในตลาดปัจจุบัน ดังนั้นก่อนที่จะใช้ในผลิตภัณฑ์คุณควรทราบว่ามันคืออะไรและทำงานอย่างไร

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

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

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

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

แต่ถ้าคุณคิดอย่างมีเหตุผล Docker Swarm จะเป็นตัวเลือกที่ดีกว่าเพราะมันทำงานบน Docker ใช่ไหม? ถ้าฉันเป็นคุณฉันคงสับสนแน่ ๆ ว่าจะใช้เครื่องมือไหนดี แต่เดี๋ยวก่อน Kubernetes เป็นผู้นำที่ไม่มีปัญหาในตลาดและยังทำงานบน Docker container ที่มีฟังก์ชันการทำงานที่ดีกว่า

ตอนนี้คุณเข้าใจความต้องการของ Kubernetes แล้วฉันบอกคุณว่าเป็นช่วงเวลาที่ดี Kubernetes คืออะไร?

บทแนะนำ Kubernetes: Kubernetes คืออะไร?

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

บทแนะนำ Kubernetes: คุณลักษณะของ Kubernetes

คุณสมบัติของ Kubernetes มีดังนี้:

• การตั้งเวลาอัตโนมัติ: Kubernetes จัดเตรียมตัวกำหนดตารางเวลาขั้นสูงเพื่อเปิดใช้งานคอนเทนเนอร์บนโหนดคลัสเตอร์ตามความต้องการทรัพยากรและข้อ จำกัด อื่น ๆ โดยไม่ต้องเสียสละความพร้อมใช้งาน
• ความสามารถในการรักษาตนเอง: Kubernetes อนุญาตให้แทนที่และกำหนดเวลาคอนเทนเนอร์ใหม่เมื่อโหนดตาย นอกจากนี้ยังฆ่าคอนเทนเนอร์ที่ไม่ตอบสนองต่อการตรวจสอบประสิทธิภาพการทำงานที่ผู้ใช้กำหนดและไม่โฆษณาให้กับลูกค้าจนกว่าพวกเขาจะพร้อมให้บริการ
• การเปิดตัวและการย้อนกลับอัตโนมัติ: Kubernetes เปิดตัวการเปลี่ยนแปลงในแอปพลิเคชันหรือการกำหนดค่าในขณะที่ตรวจสอบความสมบูรณ์ของแอปพลิเคชันเพื่อให้แน่ใจว่าจะไม่ฆ่าอินสแตนซ์ทั้งหมดของคุณในเวลาเดียวกัน หากมีสิ่งผิดปกติเกิดขึ้นกับ Kubernetes คุณสามารถย้อนกลับการเปลี่ยนแปลงได้
  
• การปรับขนาดแนวนอนและการปรับสมดุลโหลด: Kubernetes สามารถปรับขนาดและลดขนาดแอปพลิเคชันตามความต้องการด้วยคำสั่งง่ายๆโดยใช้ UI หรือโดยอัตโนมัติตามการใช้งาน CPU

บทแนะนำ Kubernetes: สถาปัตยกรรม Kubernetes

Kubernetes Architecture มีองค์ประกอบหลักดังนี้

• โหนดหลัก
• โหนดคนงาน / ทาส

ฉันจะพูดคุยกันทีละคน ดังนั้นเริ่มต้นด้วยการทำความเข้าใจ โหนดหลัก .

โหนดหลัก

โหนดหลักรับผิดชอบการจัดการคลัสเตอร์ Kubernetes ส่วนใหญ่เป็นจุดเริ่มต้นสำหรับงานด้านการบริหารทั้งหมด สามารถมีโหนดหลักมากกว่าหนึ่งโหนดในคลัสเตอร์เพื่อตรวจสอบความทนทานต่อข้อผิดพลาด

ดังที่คุณเห็นในแผนภาพด้านบนโหนดหลักมีส่วนประกอบต่างๆเช่นเซิร์ฟเวอร์ API, ตัวจัดการตัวควบคุม, เครื่องมือจัดกำหนดการและ ETCD

• เซิร์ฟเวอร์ API: เซิร์ฟเวอร์ API เป็นจุดเริ่มต้นสำหรับคำสั่ง REST ทั้งหมดที่ใช้เพื่อควบคุมคลัสเตอร์
• ผู้จัดการตัวควบคุม: เป็น daemon ที่ควบคุมคลัสเตอร์ Kubernetes และจัดการลูปการควบคุมที่ไม่สิ้นสุดที่แตกต่างกัน
• เครื่องมือจัดกำหนดการ: ตัวกำหนดตารางเวลากำหนดเวลางานให้กับโหนดทาส จัดเก็บข้อมูลการใช้ทรัพยากรสำหรับแต่ละโหนดทาส
• ETCD: ETCD เป็นที่เก็บคีย์ - ค่าที่เรียบง่ายกระจายสม่ำเสมอ ส่วนใหญ่ใช้สำหรับการกำหนดค่าที่ใช้ร่วมกันและการค้นหาบริการ

โหนดคนงาน / ทาส

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

ดังที่คุณเห็นในแผนภาพด้านบนโหนดของผู้ปฏิบัติงานมีส่วนประกอบต่างๆเช่น Docker Container, Kubelet, Kube-proxy และ Pods

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

หากคุณต้องการคำอธิบายโดยละเอียดเกี่ยวกับส่วนประกอบทั้งหมดของ Kubernetes Architecture คุณสามารถอ้างอิงได้จาก บล็อกบน

บทแนะนำ Kubernetes: กรณีศึกษาของ Kubernetes

ย อ้า! ญี่ปุ่น เป็นผู้ให้บริการเว็บที่มีสำนักงานใหญ่ในซันนีเวลแคลิฟอร์เนีย ในขณะที่ บริษัท มีเป้าหมายที่จะทำให้ฮาร์ดแวร์เสมือนจริง บริษัท จึงเริ่มใช้ OpenStack ในปี 2555 สภาพแวดล้อมภายในของพวกเขาเปลี่ยนไปอย่างรวดเร็ว อย่างไรก็ตามเนื่องจากความก้าวหน้าของเทคโนโลยีคลาวด์และคอนเทนเนอร์ บริษัท จึงต้องการคาปาbility ในการเปิดตัวบริการบนแพลตฟอร์มต่างๆ

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

เพื่อความเข้าใจที่ดีขึ้นโปรดดูภาพด้านล่าง เมื่อโค้ดถูกเปลี่ยนที่รีจิสตรีโค้ดแล้วอิมเมจโลหะเปล่าคอนเทนเนอร์ Docker และอิมเมจ VM จะถูกสร้างขึ้นโดยเครื่องมือการรวมแบบต่อเนื่องผลักเข้าไปในรีจิสตรีอิมเมจจากนั้นปรับใช้กับแต่ละแพลตฟอร์มโครงสร้างพื้นฐาน

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

มีการใช้อินสแตนซ์ OpenStack โดยมี Docker, Kubernetes, Calico ฯลฯ อยู่ด้านบนเพื่อดำเนินการต่างๆเช่น Container Networking, Container Registry และอื่น ๆ

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

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

ด้วยการผสมผสานระหว่างขั้นตอนการสร้างภาพและ Kubernetes พวกเขาได้สร้าง toolchain ด้านล่างซึ่งทำให้ง่ายตั้งแต่การกดรหัสไปจนถึงการปรับใช้

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

วิธีตั้งค่า classpath ใน windows 10

นั่นคือสิ่งที่ผู้คน Yahoo! ญี่ปุ่น สร้าง toolchain อัตโนมัติสำหรับการปรับใช้โค้ด 'คลิกเดียว' ไปยัง Kubernetes ที่ทำงานบน OpenStack ด้วยความช่วยเหลือจาก Google และ Solinea .

บทช่วยสอนของผู้ว่าการ: Hands-On

ใน Hands-On นี้ฉันจะแสดงวิธีสร้างการปรับใช้และบริการ ฉันใช้อินสแตนซ์ Amazon EC2 เพื่อใช้ Kubernetes Amazon ได้คิดค้นขึ้นมา บริการ Amazon Elastic Container สำหรับ ผู้ว่าการ (Amazon EKS) ซึ่งช่วยให้สร้างคลัสเตอร์ Kubernetes ในระบบคลาวด์ได้อย่างรวดเร็วและง่ายดาย หากคุณต้องการเรียนรู้เพิ่มเติมคุณสามารถอ้างอิงได้จากบล็อก

ขั้นตอนที่ 1: อันดับแรก สร้างโฟลเดอร์ ซึ่งคุณจะสร้างการปรับใช้และบริการของคุณ หลังจากนั้นใช้ตัวแก้ไขและ เปิดไฟล์ Deployment .

mkdir hands บนซีดีแฮนด์บน vi Deploy.yaml

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

apiVersion: apps / v1 # กำหนดชนิดเวอร์ชัน API: พารามิเตอร์ Deployment #Kinds กำหนดไฟล์ประเภทที่นี่คือ Deployment metadata: name: dep1 # จัดเก็บชื่อข้อมูลจำเพาะการปรับใช้: # ภายใต้ข้อมูลจำเพาะคุณกล่าวถึงทั้งหมด ข้อกำหนดสำหรับแบบจำลองการปรับใช้: 3 # จำนวนแบบจำลองจะเป็น 3 ตัวเลือก: matchLabels: app: httpd # ชื่อป้ายที่จะค้นหาคือเทมเพลต httpd: metadata: label: app: httpd # ชื่อเทมเพลตจะเป็น httpd spec: # ภายใต้ ข้อมูลจำเพาะคุณระบุข้อกำหนดทั้งหมดสำหรับคอนเทนเนอร์คอนเทนเนอร์: - ชื่อ: httpd # ชื่อของคอนเทนเนอร์จะเป็นภาพ httpd: httpd: ล่าสุด # รูปภาพที่ต้องดาวน์โหลดคือ httpd: พอร์ตล่าสุด: - containerPort: 80 # แอปพลิเคชัน จะถูกเปิดเผยบนพอร์ต 80

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

kubectl ใช้ -f Deploy.yaml

นี่ -f คือชื่อแฟล็กที่ใช้สำหรับtเขาไฟล์ชื่อ.

ขั้นตอนที่ 4: ตอนนี้เมื่อใช้การปรับใช้แล้วให้รับรายการพ็อดที่กำลังทำงานอยู่

kubectl รับฝัก - กว้าง

ที่นี่ใช้ -o wide เพื่อทราบว่าโหนดใดกำลังใช้งานอยู่

ขั้นตอนที่ 5: หลังจากที่คุณสร้างการปรับใช้แล้วตอนนี้คุณต้องสร้างบริการ สำหรับสิ่งนั้นอีกครั้งให้ใช้ตัวแก้ไขและเปิดช่องว่าง บริการ. ไฟล์ yaml .

vi service.yaml

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

apiVersion: v1 # กำหนดชนิดเวอร์ชัน API: พารามิเตอร์ Service #Kinds กำหนดว่าไฟล์เป็นไฟล์ประเภทใดที่นี่เป็นข้อมูลเมตาของบริการ: ชื่อ: netsvc # จัดเก็บชื่อข้อมูลจำเพาะของบริการ: # ภายใต้ข้อกำหนดคุณระบุข้อกำหนดทั้งหมด สำหรับประเภทบริการ: NodePort selector: app: httpd ports: -protocol: TCP port: 80 targetPort: 8084 #Target Port number คือ 8084

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

kubectl ใช้ -f service.yaml

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

kubectl รับ svc

ขั้นตอนที่ 9: ตอนนี้เพื่อดูข้อมูลจำเพาะของบริการและตรวจสอบว่า Endpoint ใดผูกกับใช้คำสั่งต่อไปนี้

kubectl อธิบาย svc

ขั้นตอนที่ 10: ตอนนี้เนื่องจากเราใช้อินสแตนซ์ amazon ec2 เพื่อดึงเว็บเพจและตรวจสอบผลลัพธ์ให้ใช้คำสั่งต่อไปนี้

curl ที่อยู่ IP

หากคุณพบว่าบล็อกการสอน Kubernetes นี้เกี่ยวข้องโปรดดูที่ โดย Edureka บริษัท การเรียนรู้ออนไลน์ที่เชื่อถือได้ซึ่งมีเครือข่ายผู้เรียนที่พึงพอใจมากกว่า 250,000 คนกระจายอยู่ทั่วโลก

มีคำถามสำหรับเรา? โปรดระบุไว้ในส่วนความคิดเห็นของ ' บทแนะนำ Kubernetes ” แล้วฉันจะติดต่อกลับไป