วิธีใช้งานไมโครเซอร์วิสด้วย Docker และ Kubernetes

ในปีที่ผ่านมา การผสมผสานระหว่างไมโครเซอร์วิส, Docker และ Kubernetes สถาปัตยกรรมแบบกระจายศูนย์ได้กลายเป็นมาตรฐานที่ใช้กันอย่างแพร่หลายในการพัฒนาแอปพลิเคชันที่ทันสมัย ​​ปรับขนาดได้ และบำรุงรักษาง่าย บริษัทจำนวนมากขึ้นเรื่อยๆ กำลังเปลี่ยนจากแอปพลิเคชันแบบรวมศูนย์ไปใช้สถาปัตยกรรมแบบกระจายศูนย์ซึ่งเหมาะสมกับสภาพแวดล้อมที่เปลี่ยนแปลงไปและกลยุทธ์ DevOps มากกว่า

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

สถาปัตยกรรมไมโครเซอร์วิสคืออะไร และแตกต่างจากสถาปัตยกรรมแบบโมโนลิธอย่างไร?

สถาปัตยกรรมไมโครเซอร์วิสมีพื้นฐานมาจาก แบ่งแอปพลิเคชันออกเป็นบริการขนาดเล็กหลายๆ บริการ ที่ทำงานได้อย่างอิสระและสามารถนำไปใช้งานได้โดยอิสระแต่ละระบบมุ่งเน้นไปที่ฟังก์ชันการทำงานเฉพาะ (ผู้ใช้ การชำระเงิน แคตตาล็อก คำสั่งซื้อ ฯลฯ) ซึ่งสื่อสารกันเป็นหลักผ่าน API ที่มีน้ำหนักเบา (HTTP/REST, gRPC, การส่งข้อความ ฯลฯ)

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

ด้วยสถาปัตยกรรมไมโครเซอร์วิส แต่ละเซอร์วิสจะมีวงจรชีวิตของตัวเอง: สามารถพัฒนา ทดสอบ ปรับใช้ ขยายขนาด และกำหนดเวอร์ชันได้อย่างอิสระสิ่งนี้ช่วยให้หลายทีมสามารถทำงานพร้อมกันได้ ลดความซับซ้อนในการนำเทคโนโลยีใหม่มาใช้ และอำนวยความสะดวกในการบูรณาการกับแนวทางปฏิบัติ CI/CD

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

ข้อดีและข้อเสียที่แท้จริงของไมโครเซอร์วิส

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

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

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

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

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

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

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

คอนเทนเนอร์: รากฐานสำหรับการเรียกใช้ไมโครเซอร์วิสแบบแยกส่วน

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

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

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

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

Docker: แพลตฟอร์มมาตรฐานสำหรับการสร้างคอนเทนเนอร์สำหรับไมโครเซอร์วิส

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

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

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

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

FROM node:14
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD

ไฟล์นี้ระบุว่าแอปพลิเคชันจะทำงานในไดเร็กทอรีนั้น /แอปภายในคอนเทนเนอร์โดยจะติดตั้งส่วนประกอบที่จำเป็นด้วย npm เปิดพอร์ต 3000 และเมื่อเริ่มต้นคอนเทนเนอร์ ระบบจะดำเนินการตามคำสั่งต่อไปนี้ เริ่ม npm.

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

docker build -t mi-app .
docker run -p 3000:3000 mi-app

ด้วยโมเดลนี้ ปัญหาคลาสสิกอย่าง "มันใช้งานได้บนเครื่องของฉัน" ลดลงเหลือน้อยที่สุดเนื่องจากสภาพแวดล้อมการทำงานจะติดตามแอปพลิเคชันไปด้วย นอกจากนี้ Docker ยังผสานรวมเข้ากับระบบ CI/CD, รีจิสทรีส่วนตัว และเครื่องมือจัดการระบบอย่าง Kubernetes ได้อย่างราบรื่น

ส่วนประกอบสำคัญใน Docker และบทบาทของส่วนประกอบเหล่านั้นในไมโครเซอร์วิส

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

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

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

Kubernetes: เครื่องมือจัดการคอนเทนเนอร์จำนวนหลายร้อยตัว

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

Kubernetes ช่วยทำให้งานสำคัญต่างๆ เป็นไปโดยอัตโนมัติ เช่น... การติดตั้งใช้งาน การขยายขนาด การกู้คืนระบบหลังความผิดพลาด การกำหนดค่าเครือข่าย และการจัดเก็บข้อมูล สำหรับแอปพลิเคชันแบบคอนเทนเนอร์ ได้รับการออกแบบให้ทำงานได้ในระบบคลาวด์สาธารณะ ระบบคลาวด์ส่วนตัว สภาพแวดล้อมแบบไฮบริด และแม้แต่ในระบบภายในองค์กร

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

องค์ประกอบพื้นฐานของ Kubernetes

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

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

ทรัพยากร การใช้งาน ใช้สำหรับกำหนดวิธีการปรับใช้และอัปเดต Pods: จำนวนสำเนา (replicas), รูปภาพที่จะใช้, แท็กที่จะใช้ และกลยุทธ์การอัปเดตที่จะปฏิบัติตาม Kubernetes จะจัดการเรื่องนี้ให้ รักษาจำนวน Pod ที่ทำงานอยู่ให้เป็นไปตามที่ต้องการเสมอ และเพื่อทำการอัปเดตหรือย้อนกลับแบบค่อยเป็นค่อยไปเมื่อคุณเปลี่ยนแปลงการกำหนดค่า

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

วิธีการตั้งค่าคลัสเตอร์ Kubernetes

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

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

การจัดเก็บสถานะถูกมอบหมายให้แก่ ฯลฯฐานข้อมูลแบบกระจายจะจัดเก็บการกำหนดค่าและข้อมูลสำหรับทรัพยากรทั้งหมดของคลัสเตอร์ นอกจากนี้ กระบวนการต่างๆ เช่นต่อไปนี้ จะทำงานบนโหนดผู้ปฏิบัติงานแต่ละโหนด: คูเบเลต (เอเจนต์ที่ทำหน้าที่สื่อสารระหว่างโหนดกับเซิร์ฟเวอร์ API) kube-พร็อกซี (ซึ่งจัดการปริมาณการรับส่งข้อมูลเครือข่ายและการกระจายโหลด) และ รันไทม์คอนเทนเนอร์ (Docker, containerd, CRI-O เป็นต้น)

การใช้งานไมโครเซอร์วิสใน Kubernetes ด้วยไฟล์ YAML

ในการใช้งานไมโครเซอร์วิสใน Kubernetes มักจะอธิบายด้วยรูปแบบดังนี้ แถลงการณ์ YAMLโดยที่คุณกำหนด Deployment (เทมเพลต Pod, รูปภาพ, พอร์ต, จำนวนสำเนา, ป้ายกำกับ) และ Service ที่เกี่ยวข้องเพื่อเปิดเผยภายในหรือภายนอกคลัสเตอร์

ตัวอย่างพื้นฐานของการปรับใช้แอปพลิเคชันที่ชื่อว่า “my-app” อาจมีลักษณะดังนี้ โดยที่ มีการกำหนดสำเนาสามชุดและพอร์ต 3000 ในฐานะท่าเรือขนส่งตู้คอนเทนเนอร์:

apiVersion: apps/v1
kind: Deployment
metadata:
name: mi-app
spec:
replicas: 3
selector:
matchLabels:
app: mi-app
template:
metadata:
labels:
app: mi-app
spec:
containers:
- name: mi-app
image: mi-app:latest
ports:
- containerPort: 3000

แถลงการณ์นี้ระบุว่ากลุ่มคลัสเตอร์จะต้องรักษาไว้ซึ่งสิ่งต่อไปนี้ แคปซูล 3 อันกำลังใช้งานอยู่ ด้วยอิมเมจ “my-app:latest” แอปทั้งหมดจะถูกติดแท็กด้วย app=my-app เพื่อให้ Service สามารถค้นหาและกระจายปริมาณการใช้งานระหว่างแอปเหล่านั้นได้ Kubernetes จะจัดการตรรกะสำหรับการปรับขนาด การอัปเดต และการแทนที่ Pods ในกรณีที่เกิดความล้มเหลวโดยอัตโนมัติ

นอกเหนือจากการปรับใช้แล้ว การกำหนดบริการประเภทต่างๆ ก็เป็นเรื่องปกติเช่นกัน ClusterIP, NodePort หรือ LoadBalancerขึ้นอยู่กับว่าไมโครเซอร์วิสควรเข้าถึงได้เฉพาะภายในคลัสเตอร์ จากโหนด หรือจากอินเทอร์เน็ต การกำหนดค่าทั้งหมดนี้จะถูกจัดเวอร์ชันไว้ในที่เก็บข้อมูล ซึ่งผสานรวมเข้ากับไปป์ไลน์ CI/CD ได้อย่างราบรื่น

การปรับขนาด การอัปเกรด และการแก้ไขตัวเองใน Kubernetes

หนึ่งในเหตุผลสำคัญที่ควรใช้ Kubernetes คือความสามารถในการ... ปรับขนาดและอัปเดตไมโครเซอร์วิสโดยไม่ต้องหยุดแอปพลิเคชันคุณสามารถเปลี่ยนจำนวนสำเนาในไฟล์ manifest (หรือด้วยคำสั่ง kubectl) และคลัสเตอร์จะจัดการสร้างหรือลบ Pods จนกว่าจะถึงค่าที่ต้องการ

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

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

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

การตรวจสอบและการสังเกตการณ์ไมโครเซอร์วิสใน Kubernetes

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

Prometheus ทำหน้าที่ "ดึง" ข้อมูลเมตริกจาก Pods, โหนด และส่วนประกอบของคลัสเตอร์ จัดเก็บไว้ และอนุญาตให้คุณกำหนดการแจ้งเตือนเกี่ยวกับข้อมูลเหล่านั้น เมื่อรวมกับ Grafana คุณสามารถสร้างแดชบอร์ดที่แสดงข้อมูลต่างๆ ได้ ตรวจสอบการใช้งาน CPU, หน่วยความจำ, ข้อผิดพลาด HTTP, ความหน่วง, จำนวนสำเนา หรือสถานะของโหนด ชัดเจนมาก.

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

ความสัมพันธ์ระหว่างไมโครเซอร์วิส, Docker และ Kubernetes

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

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

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

ตัวอย่างเช่น ในแอปพลิเคชันอีคอมเมิร์ซ คุณอาจมีไมโครเซอร์วิสสำหรับระบบยืนยันตัวตน แคตตาล็อก ตะกร้าสินค้า และการชำระเงิน โดยแต่ละไมโครเซอร์วิสมีอิมเมจ Docker และการใช้งาน Kubernetes เป็นของตัวเอง ด้วยวิธีนี้ คุณสามารถขยายขนาดแคตตาล็อกในแคมเปญขนาดใหญ่หรือการชำระเงินในช่วงเวลาสำคัญได้โดยไม่กระทบต่อส่วนอื่นๆและจัดการวงจรชีวิตทั้งหมด ตั้งแต่ไปป์ไลน์ CI/CD ไปจนถึงการตรวจสอบหลังการผลิต

การติดตั้ง Docker และ Kubernetes บน Windows

หากคุณใช้งาน Windows วิธีที่ง่ายที่สุดในการเริ่มต้นคือการติดตั้ง DockerDesktopซึ่งรวมถึง Docker engine และเครื่องมือเพิ่มเติม ตลอดจนตัวเลือกในการเปิดใช้งาน Kubernetes ที่ผสานรวมเข้ากับเครื่องของคุณ

กระบวนการโดยทั่วไปประกอบด้วย ดาวน์โหลด Docker Desktop จากเว็บไซต์อย่างเป็นทางการเรียกใช้โปรแกรมติดตั้ง (Docker Desktop Installer.exe) และทำตามขั้นตอนในตัวช่วยติดตั้ง ระหว่างการติดตั้ง คุณสามารถเลือกได้ว่าจะใช้ Hyper-V หรือ WSL 2 ในฐานะที่เป็นเทคโนโลยีเวอร์ชวลไลเซชัน หากมีเพียงเทคโนโลยีเดียวที่ใช้งานได้ ก็จะใช้เทคโนโลยีนั้น

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

ในการใช้งาน Kubernetes บน Windows คุณต้องเปิดใช้งาน Docker และความสามารถในการจำลองเสมือนก่อน จากนั้นคุณสามารถเปิดใช้งาน Kubernetes จาก Docker Desktop หรือ ติดตั้งและกำหนดค่า kubectl เพื่อจัดการคลัสเตอร์ภายนอก และหากเหมาะสม ให้ปรับใช้แดชบอร์ด Kubernetes โดยใช้ manifest ระยะไกล

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

การติดตั้ง Docker และ Kubernetes บน Linux

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

ขั้นตอนทั่วไปได้แก่ การอัปเดตระบบด้วย apt-get update และ apt-get upgradeลบ Docker Desktop เวอร์ชันเก่าทั้งหมดออก หากมี จากนั้นติดตั้ง docker-ce, docker-ce-cli, containerd.io และปลั๊กอิน docker-compose จากที่เก็บอย่างเป็นทางการ หรือโดยการระบุเวอร์ชันที่ต้องการ

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

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

จากนั้นคลัสเตอร์จะถูกเริ่มต้นบนโหนดหลักด้วย kubeadm init (โดยระบุช่วงเครือข่ายสำหรับ Pods) คำสั่ง "join" จะถูกเรียกใช้เพื่อให้โหนดผู้ปฏิบัติงานเข้าร่วมคลัสเตอร์ และการเข้าถึงภายในเครื่องจะถูกกำหนดค่าโดยการสร้างไดเร็กทอรี $HOME/.kubeโดยการคัดลอกไฟล์ admin.conf และปรับสิทธิ์การเข้าถึง

ด้วยวิธีนี้ คุณจะมีคลัสเตอร์พื้นฐานพร้อมใช้งานแล้ว ปรับใช้ไมโครเซอร์วิสแบบคอนเทนเนอร์ติดตั้งเครือข่าย Pods (เช่น Flannel, Calico เป็นต้น) และเริ่มต้นใช้งาน Deployments, Services และทรัพยากรอื่นๆ ของ Kubernetes

แนวทางปฏิบัติที่ดีที่สุดและคำแนะนำสำหรับการใช้งาน Docker และ Kubernetes

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

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

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

การจำกัดทรัพยากรที่จัดสรรให้กับแต่ละคอนเทนเนอร์ (ซีพียู หน่วยความจำ อินพุต/เอาต์พุต) จะช่วยให้ ป้องกันไม่ให้บริการเดียวผูกขาดการใช้งานโฮสต์ และลดประสิทธิภาพของส่วนที่เหลือ นอกจากนี้ คอนเทนเนอร์จะต้องได้รับการตรวจสอบด้วยเครื่องมือต่างๆ เช่น Docker Stats หรือโซลูชันขั้นสูงกว่านั้น เพื่อควบคุมการทำงานในสภาพแวดล้อมการผลิต

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

นอกจากนี้ยังเป็นความคิดที่ดี ทำให้เป็นระบบอัตโนมัติมากที่สุดเท่าที่จะเป็นไปได้ใช้ตัวควบคุมการจำลองแบบ (replication controllers), ตัวปรับขนาดอัตโนมัติ (autoscalers) และงาน (Jobs) สำหรับการอัปโหลดแบบกลุ่ม ใช้ประโยชน์จากการอัปเดตแบบต่อเนื่องและการย้อนกลับ และกำหนดรายการประกาศแบบมีเวอร์ชันในที่เก็บ Git

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

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

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