Private Kubernetes Deployment for Autonomous Reliability Infrastructure
Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.
คลัสเตอร์ที่ลูกค้าจัดการ
การแยกเพลนควบคุม / เพลนการดำเนินการ
รูปแบบการแยกเนมสเปซ
เข้ากันได้กับโมเดลไฮบริดและเอนเคลฟ
ทำไมองค์กรจึงต้องการออร์เคสเตรชันแบบส่วนตัว
หลายทีมได้กำหนดมาตรฐานบน Kubernetes สำหรับแพลตฟอร์มภายในอยู่แล้ว Zof รองรับการจัดวางการดำเนินการในคลัสเตอร์เหล่านั้นโดยไม่จำเป็นต้องละทิ้งการลงทุนด้านออร์เคสเตรชันที่มีอยู่
- -มาตรฐานคลัสเตอร์ที่มีอยู่และไปป์ไลน์ GitOps
- -ทีมแพลตฟอร์มเป็นเจ้าของโหนดและระบบเครือข่าย
- -ความจำเป็นในการเก็บเวิร์กโหลดที่ละเอียดอ่อนออกจากการดำเนินการแบบ SaaS ที่ใช้งานร่วมกันหลายผู้เช่า
- -สภาพแวดล้อมที่มีการกำกับดูแลพร้อมการแยกระดับเนมสเปซ
การรันโครงสร้างพื้นฐานการดำเนินการในคลัสเตอร์ที่ลูกค้าจัดการ
เอเจนต์การดำเนินการสามารถนำไปใช้งานเป็นเวิร์กโหลดในคลัสเตอร์ที่คุณดำเนินการได้ การวางแผนและการอนุมัติอาจรันในเพลนควบคุมบนคลาวด์ ไพรเวทคลาวด์ หรือออนพรีมิส ขึ้นอยู่กับนโยบาย
- -เอเจนต์ถูกจัดกำหนดการเช่นเดียวกับบริการภายในอื่น ๆ
- -เข้ากันได้กับ CNI และเอนจินนโยบายของลูกค้า
- -ไม่ต้องการการเข้าถึงขาเข้าสู่คลัสเตอร์
- -รองรับฟลีตแบบหลายคลัสเตอร์เมื่อเวลาผ่านไป
การแยกเพลนควบคุมและเพลนการดำเนินการ
เพลนควบคุมเก็บนโยบาย บริบทกราฟ การอนุมัติ และการจัดกำหนดการ ส่วนเพลนการดำเนินการรันแคปซูลที่ลงนามกับแอปพลิเคชันภายในคลัสเตอร์หรือเครือข่ายที่เชื่อมต่อ
การประมวลผลบน Private Kubernetes
เอเจนต์ที่รองรับการประมวลผลในคลัสเตอร์ที่ลูกค้าจัดการ ไม่ใช่การติดตั้งแพลตฟอร์มเต็มรูปแบบ
- -ขอบเขตการทบทวนด้านความปลอดภัยที่ชัดเจน
- -ข้อมูลรันไทม์ที่ละเอียดอ่อนยังคงอยู่ในเนมสเปซการดำเนินการ
- -API ของเพลนควบคุมไม่ได้รันการทดสอบกับแอปที่ได้รับการป้องกันโดยตรง
- -การแบ่งแบบไฮบริดเป็นเรื่องปกติในการเปิดใช้งานระดับองค์กร
เอเจนต์การดำเนินการ Kubernetes
เอเจนต์ถูกออกแบบมาให้เข้ากันได้กับ Kubernetes ของลูกค้า ไม่ใช่เพื่อแทนที่ทีมแพลตฟอร์มของคุณ การปรับขนาด HA และการอัปเกรดเป็นไปตามมาตรฐานคลัสเตอร์ของคุณ
- -การนำไปใช้งานผ่านมานิเฟสต์หรือออเปอเรเตอร์ที่ลูกค้าอนุมัติ
- -เคารพขีดจำกัดทรัพยากรและนโยบายความปลอดภัยของพอด
- -อัตลักษณ์รันเนอร์และรายการที่อนุญาตสำหรับโฮสต์การดำเนินการ
- -การเปิดใช้งานแบบเป็นขั้นตอนต่อเนมสเปซหรือคลัสเตอร์
ขอบเขตการดำเนินการที่ปลอดภัย
เนมสเปซ นโยบายเครือข่าย และเซอร์วิสแอคเคานต์แยกการดำเนินการออกจากเวิร์กโหลดที่ไม่เกี่ยวข้อง ซีเครตถูกเมานต์ในเวลารันไทม์ ไม่ได้จัดเก็บใน Zof Cloud
- -RBAC ที่จำกัดขอบเขตเฉพาะเนมสเปซ
- -การผสานการทำงานกับตัวจัดการซีเครตภายนอกในกรณีที่รองรับ
- -การจัดแนวกับเซอร์วิสเมชแบบเลือกได้
- -การตรวจสอบเหตุการณ์วงจรชีวิตของเอเจนต์
การทดสอบแอปพลิเคชันเฉพาะภายในเท่านั้น
ตรวจสอบความถูกต้องของไมโครเซอร์วิส API ภายใน และ UI สำหรับผู้ดูแลระบบที่เข้าถึงได้จากเครือข่ายคลัสเตอร์ โดยไม่ต้องเปิดให้อินเทอร์เน็ตสาธารณะเข้าถึง
- -การทดสอบระหว่างบริการภายในคลัสเตอร์
- -เฉพาะอินเกรสในกรณีที่นโยบายอนุญาต
- -จับคู่กับเอดจ์รันเนอร์สำหรับระบบเก่าที่อยู่นอกคลัสเตอร์
- -การกำหนดเป้าหมายที่รับรู้กราฟช่วยลดสัญญาณรบกวน
การแยกเนมสเปซ
ทีมจับคู่หน่วยธุรกิจหรือสภาพแวดล้อมกับเนมสเปซที่มีนโยบาย การเก็บรักษา และโหมดหลักฐานที่แตกต่างกัน
- -การแยก dev / staging / prod
- -โควตาต่อทีมและขีดจำกัดการทำงานพร้อมกัน
- -ที่จัดเก็บหลักฐานที่จำกัดขอบเขตเฉพาะเนมสเปซ
- -กระบวนการเลื่อนระดับข้ามเนมสเปซ
การจัดการซีเครต
ข้อมูลรับรองถูกจัดสรรในเวลาที่ดำเนินการผ่าน PAM หรือการผสานการทำงานกับซีเครตของคลัสเตอร์ ซีเครตที่มีอายุยาวจะไม่ถูกคัดลอกไปยัง SaaS ภายนอกโดยค่าเริ่มต้น
- -แนะนำให้ใช้โทเค็นที่มีอายุสั้น
- -รูปแบบที่เข้ากันได้กับ PAM
- -ไม่มีการเก็บซีเครตคงค้างในเพลนการวางแผนโดยไม่มีการอนุมัติ
- -การหมุนเวียนคีย์ที่สอดคล้องกับมาตรฐานของคุณ
การกำหนดเส้นทางอาร์ติแฟกต์
อาร์ติแฟกต์การทดสอบและบันเดิลยังคงอยู่ในที่จัดเก็บที่ลูกค้าควบคุม เว้นแต่คุณจะกำหนดค่าการส่งออกแบบผ่านการกรองข้อมูลหรือเฉพาะข้อมูลเมตา
สถาปัตยกรรมการประมวลผลแบบไฮบริด
การจัดการกระบวนการบนคลาวด์พร้อมฟลีตการประมวลผลภายในเครื่องแบบกระจาย
- -ที่รองรับ S3 NFS หรือวอลุ่มภายในคลัสเตอร์
- -นโยบายการเก็บรักษาต่อเนมสเปซ
- -เช็กซัมและการลงนามสำหรับบันเดิล
- -การเลื่อนระดับไปยังแคตตาล็อกหลักฐานส่วนกลางแบบเลือกได้
ขอบเขตเทเลเมทรี
เมตริกและล็อกจากเอเจนต์สามารถคงอยู่ในสแต็กการสังเกตการณ์ภายในคลัสเตอร์ได้ แดชบอร์ดส่วนกลางอาจได้รับเฉพาะสรุปข้อมูลเมตา
- -รูปแบบที่เข้ากันได้กับ OpenTelemetry ในกรณีที่รองรับ
- -การปกปิดข้อมูลก่อนการส่งออกข้ามขอบเขต
- -Correlation ID สำหรับการตรวจสอบ
- -ไม่มีการบังคับให้ส่งออกล็อกทั้งหมด
การกำกับดูแลระดับองค์กร
การลงนามแคปซูล การอนุมัติโดยมนุษย์ และเกตการแก้ไข ใช้อย่างสม่ำเสมอไม่ว่าการดำเนินการจะอยู่บน VM แบร์เมทัล หรือ Kubernetes
- -เวอร์ชันนโยบายถูกตรึงไว้กับการรัน
- -ลำดับขั้นการอนุมัติสำหรับเส้นทางสู่โปรดักชัน
- -การผสานรวมกับบันทึกการเปลี่ยนแปลงของ ITSM
- -ส่งออกข้อมูลสำหรับ GRC และการตรวจสอบภายใน
รูปแบบสถาปัตยกรรมแบบไฮบริด
การดำเนินการบน Kubernetes มักทำงานร่วมกับ VPC runner ไซต์ edge และ endpoint agent ภายใต้ control plane เดียวกัน
- -การจัดการกราฟและฟลีตแบบรวมศูนย์
- -โมเดลแคปซูลที่สอดคล้องกันทุกพื้นผิวการทำงาน
- -นโยบายหลักฐานเฉพาะแต่ละพื้นผิวการทำงาน
- -การทบทวนสถาปัตยกรรมกำหนดลำดับการ rollout
คำถามเกี่ยวกับการติดตั้งใช้งานแบบ on-prem
คำถามที่พบบ่อยจากทีมโครงสร้างพื้นฐานและทีมความปลอดภัย
หารือเรื่องการนำไปใช้งานอย่างปลอดภัยกับ Zof
ตรวจทานการแบ่งส่วน การกำกับดูแลแคปซูล และการจัดวางรันเนอร์ร่วมกับทีมที่สนับสนุนองค์กรในอุตสาหกรรมที่มีการกำกับดูแล
