ศูนย์คู่มือ Ruk-Com PaaS

คู่มือการพัฒนา Deploy และดูแล Application บน Platform

RUK-COM PAAS / KUBERNETES HOSTING

ความต้องการของระบบ

คู่มือนี้เรียบเรียงสำหรับ Ruk-Com PaaS หน้าจอและตัวเลือกอาจแตกต่างตามเวอร์ชันและสิทธิ์ของบัญชี

ตรวจสอบ Environment, Region, สิทธิ์บัญชี และสำรองค่าปัจจุบันก่อนดำเนินการกับระบบจริง

ปรับปรุงตามเอกสาร Platform ปัจจุบัน

ตรวจสอบชื่อเมนู ตัวเลือก และข้อกำหนดล่าสุดจากเนื้อหาภาษาอังกฤษในหน้าเดียวกันก่อนดำเนินการกับระบบจริง

วัตถุประสงค์

บทความนี้อธิบายการใช้งาน ความต้องการของระบบ บน Ruk-Com Cloud PaaS โดยจัดลำดับขั้นตอนและจุดตรวจสอบสำหรับการนำไปใช้งานจริง

ก่อนเริ่มดำเนินการ

  • เข้าสู่ระบบด้วยบัญชีที่มีสิทธิ์จัดการ Environment ที่เกี่ยวข้อง
  • ตรวจสอบชื่อ Environment, Region และ Resource เป้าหมายก่อนบันทึกการเปลี่ยนแปลง
  • สำรองข้อมูลหรือกำหนดแผนย้อนกลับก่อนแก้ไขระบบ Production

PackageCluster Kubernetesอาจไม่มีให้บริการในบางภูมิภาคเนื่องจาก Hardware เฉพาะของ Platform นั้น ๆ ในกรณีนี้โปรดติดต่อฝ่ายสนับสนุนผู้ให้บริการ Hosting ของคุณ

การใช้ RAM, CPU และหน่วยเก็บข้อมูลขั้นต่ำและเหมาะสมที่สุดขึ้นอยู่กับขนาด Cluster, ส่วนประกอบที่ติดตั้ง, ปริมาณงานที่ใช้งานอยู่ ฯลฯ

หมายเหตุ :

  • [1]วัดใน Cluster development แบบเปล่า ๆ และ production โดยไม่มีภาระ (load) เพิ่มเติมใด ๆ ดังนั้นค่าที่ระบุจึงเป็นข้อกำหนดขั้นต่ำของระบบซึ่งอาจสูงกว่ามากสำหรับ loaded clusters (โดยเฉพาะอย่างยิ่งสำหรับ production)
  • [2]Topology Development cluster – หนึ่ง master, หนึ่ง worker, หนึ่ง storage node ไม่มีเครื่องมือตรวจสอบตัวอย่างการ deploy สำหรับ Hello World
  • [3]Topology Production cluster - API balancer, สาม master, สอง worker, หนึ่ง storage node, เครื่องมือตรวจสอบ, ตัวอย่างการ deploy สำหรับ Hello World
  • [4]ดิสก์ที่รวดเร็วมีความสำคัญอย่างยิ่งต่อประสิทธิภาพของ etcd (ที่เก็บคีย์ - ค่าที่ใช้โดย K8s) ในขณะที่ etcd ที่ช้าอาจทำให้ Cluster ไม่เสถียรเนื่องจากปริมาณงานที่ล้มเหลว

ศึกษาเพิ่มเติม :ข้อกำหนดของดิสก์, ข้อมูลเกณฑ์มาตรฐาน, วิธีเรียกใช้เกณฑ์มาตรฐาน, และดาวน์โหลดเกณฑ์มาตรฐาน

ในตัวอย่างนี้ขอแนะนำให้ใช้ development cluster เป็น sandbox environment เท่านั้น สำหรับ production purposes เป็น Topology ที่พร้อมใช้งานสูงโดยมี multi-master เป็นตัวเลือกที่ต้องการ จากนั้นขึ้นอยู่กับภาระที่คาดไว้ว่าสามารถเพิ่มจำนวน worker ที่ต้องการได้ด้วยตนเองหรือสามารถกำหนดHorizontal Scaling อัตโนมัติที่เหมาะสมได้ การเพิ่ม Node master เพิ่มเติมจะเหมาะสมก็ต่อเมื่อมีคำขอจำนวนมากที่มาจาก Client (kubectl, dashboard, continuous integration job, Application K8s-native ฯลฯ )