คอนเทนเนอร์
Kubernetes: ออร์เคสเตรเตอร์ โต้แย้งอย่างตรงไปตรงมา
Kubernetes คือผู้ควบคุมคอนเทนเนอร์ที่กลายมาเป็นสารตั้งต้นเริ่มต้นของระบบขนาดใหญ่ของโครงสร้างพื้นฐาน ได้แก่ การปรับใช้ บริการ ทางเข้า PersistentVolumes และ API ที่อธิบายสถานะที่ต้องการ มันยังยิ่งใหญ่อีกด้วย บทความตรงไปตรงมาเกี่ยวกับ Kubernetes เริ่มต้นเมื่อไม่ควรใช้งาน จากนั้นครอบคลุมสถาปัตยกรรมที่แท้จริง ตัวเลือกการโฮสต์ (แบบจัดการเทียบกับ k3) และวินัยในการดำเนินการที่มันต้องการ
ประเด็นสำคัญ
- โมเดลออบเจ็กต์หลักนั้นดีอย่างแท้จริง: การปรับใช้อธิบายสถานะแบบจำลองที่ต้องการ บริการให้เครือข่ายที่เสถียร ConfigMaps/Secret แยกการกำหนดค่า และ Ingress เข้าถึงภายนอก การกระทบยอดแบบประกาศ (ตัวควบคุมการแก้ไขดริฟท์) เป็นสถาปัตยกรรมที่ทุกสิ่งทุกอย่างสร้างขึ้น
- น้ำหนักในการปฏิบัติงานเป็นเรื่องจริง: ส่วนประกอบของระนาบควบคุม (เซิร์ฟเวอร์ API, ฯลฯ, ตัวกำหนดเวลา, ตัวจัดการตัวควบคุม) แต่ละรายการต้องการ HA และการตรวจสอบ การสำรองข้อมูล etcd เป็นงานเดียวที่ไม่น่าดึงดูดใจที่จะตัดสินว่าคลัสเตอร์สามารถกู้คืนได้หรือไม่ และการอัพเกรดวินัย (หนึ่งเวอร์ชันรองต่อขั้นตอน โหนดคานารีก่อน) ถือเป็นข้อผูกมัดที่คงอยู่
- ทางแยกที่มีการจัดการและจัดการด้วยตนเอง: การควบคุมการแลกเปลี่ยน GKE/EKS/AKS เพื่อลดการดำเนินการ, k3s/microk8s เป็นการแจกจ่ายขนาดเล็กที่ถูกต้องตามกฎหมายสำหรับฟลีตขนาดเล็ก และต้นแบบ HA ที่จัดการด้วยตนเองยังคงเป็นโปรเจ็กต์ทีมขนาดใหญ่ สำหรับธุรกิจโฮสติ้ง k3 บนโหนดจำนวนหนึ่งมักจะถือเป็นเพดานที่ถูกต้อง
- พื้นที่จัดเก็บข้อมูลเป็นจุดที่คลัสเตอร์แรกๆ ส่วนใหญ่ได้รับผลกระทบ: PV/PVC ทั่วทั้งคลาสพื้นที่จัดเก็บข้อมูลบนคลาวด์ที่แตกต่างกัน hostPath เป็นเหมือนปืนลูกซอง และคลาสที่สนับสนุนพื้นที่เก็บข้อมูลแบบบล็อกมีความหมาย IOPS/อัตราจริง วางแผนคลาสพื้นที่จัดเก็บข้อมูลและกลยุทธ์การสำรองข้อมูล (คลาส velero) ก่อนเวิร์กโหลดแบบมีสถานะแรก
- ระบบเครือข่ายมีระเบียบวินัยในตัวเอง: ทางเลือกของ CNI (ผ้าสักหลาด, ผ้าดิบ, ซีลีเนียม) การควบคุมการซ้อนทับเทียบกับนโยบายการกำหนดเส้นทางและทางออกดั้งเดิม Ingress (nginx/traefik) พร้อมตัวจัดการใบรับรอง TLS; เครื่องมือทางการตลาดจะแตกต่างกันไปตามอายุของ Gateway API วัดผลก่อนเลือก
- คำตัดสินที่ตรงไปตรงมาในหมวดหมู่คอนเทนเนอร์ของเรา: นำ Kubernetes มาใช้เมื่อการกำหนดเวลาแบบหลายโหนด การปรับขนาดอัตโนมัติ และการปรับใช้อัตโนมัติที่ขับเคลื่อนด้วย API แบกภาระงาน อย่า k8s เซิร์ฟเวอร์ WordPress เดียว การแจกแจงคลาส k3s ขยายโซนอรรถประโยชน์ แต่คลัสเตอร์ที่เล็กที่สุดยังคงมีค่าใช้จ่ายในการดำเนินการมากกว่าการเขียน
บันทึกจากหน้างาน
ลูกค้าที่ 'ต้องการ Kubernetes' กลับกลายเป็นว่าต้องการบริการสี่รายการบนโฮสต์สองแห่ง และ k3s ได้นำเครื่องบินควบคุมมาคอยดูแลเพื่อรับสิทธิ์นี้ เราย้ายพวกเขาไปยังสแต็คการเขียนธรรมดาและเพจเจอร์ที่เรียกใช้ได้ก็เงียบไป การตัดสินใจที่ดีที่สุดของ Kubernetes มักเป็นการตัดสินใจที่คุณไม่ได้ตัดสินใจ
คำถามที่พบบ่อย
โฮสติ้งขนาดเล็กของเราควรย้ายไปที่ Kubernetes หรือไม่
อาจไม่ใช่: หากปริมาณงานของคุณเป็นบริการจำนวนหนึ่งจากโฮสต์จำนวนหนึ่ง สแต็กการเขียนหรือสแต็กที่จัดการโดย Podman จะปลอดภัยและตรวจสอบได้ง่ายกว่า ผลตอบแทนของ k8s เริ่มต้นด้วยความต้องการการจัดกำหนดการแบบไดนามิกอย่างแท้จริงหรือระบบอัตโนมัติที่ขับเคลื่อนด้วย API ในวงกว้าง
GKE, EKS, AKS หรือ k3 ที่จัดการด้วยตนเอง
เครื่องบินควบคุมที่มีการจัดการควบคุมการแลกเปลี่ยนสำหรับการอัพเกรดที่บรรทุก; k3s-class สำหรับภายในองค์กรและเพดานต้นทุน Kubernetes เต็มรูปแบบที่จัดการด้วยตนเองเป็นโปรเจ็กต์พิเศษและไม่ค่อยมีคำตอบที่ถูกต้องสำหรับโปรไฟล์ธุรกิจโฮสติ้ง
ความล้มเหลวในการดำเนินงานที่พบบ่อยที่สุดคืออะไร?
etcd ไม่ถูกสำรองข้อมูล: การหมดอายุของใบรับรองในระนาบควบคุมจะปรากฏขึ้นถัดไป ถือว่าการสำรองข้อมูลคลัสเตอร์ (สแน็ปช็อต ฯลฯ หรือ velero) เป็นสิ่งแรกที่ถูกปรับใช้หลังจากคลัสเตอร์เอง
เราจะรักษาความปลอดภัยคลัสเตอร์อย่างมีสติได้อย่างไร?
RBAC มีสิทธิ์น้อยที่สุดโดยมีบทบาทจริงต่อทีม นโยบายเครือข่ายที่แบ่งกลุ่มการรับส่งข้อมูลเนมสเปซ การสแกนรูปภาพเมื่อรับเข้า (ฮุคนโยบายระดับสามชั้น) และความลับในคลัสเตอร์ที่จัดการผ่านผู้จัดการความลับภายนอกของคุณ แทนที่จะเป็น YAML แบบดิบ
Kinetikatech ช่วยเรื่อง คอนเทนเนอร์ ได้อย่างไร
ข้อเสนอง่าย ๆ แบบนี้: การจัดการ การประสานงาน และความปลอดภัยของคอนเทนเนอร์ในสภาพแวดล้อมโปรดักชัน ส่งให้บริการ การจัดการเซิร์ฟเวอร์และความปลอดภัยเซิร์ฟเวอร์ Linux ของเราดูแล มีการประเมินอย่างเหมาะสม ลงมือแบบสะอาด และมีคนเฝ้าตลอด 24 ชั่วโมง