ในปัจจุบัน บริษัทต่างๆ จำนวนมากขึ้นเรื่อยๆ กำลังถ่ายโอนโครงสร้างพื้นฐานของตนจากเซิร์ฟเวอร์ฮาร์ดแวร์และเครื่องเสมือนของตนเองไปยังระบบคลาวด์ โซลูชันนี้อธิบายได้ง่าย: ไม่จำเป็นต้องกังวลเกี่ยวกับฮาร์ดแวร์ คลัสเตอร์ได้รับการกำหนดค่าอย่างง่ายดายด้วยวิธีต่างๆ มากมาย... และที่สำคัญที่สุดคือ เทคโนโลยีที่มีอยู่ (เช่น Kubernetes) ทำให้สามารถปรับขนาดกำลังการประมวลผลโดยขึ้นอยู่กับโหลด .
ด้านการเงินมีความสำคัญเสมอ เครื่องมือที่กล่าวถึงในบทความนี้ออกแบบมาเพื่อช่วยลดงบประมาณเมื่อใช้โครงสร้างพื้นฐานระบบคลาวด์กับ Kubernetes
การแนะนำ
เรามีไคลเอนต์ที่มี Kubernetes ทั้งในระบบคลาวด์ AWS และ GCP ที่คุ้นเคย และโดยทั่วไปแล้วสำหรับชุมชน Linux อย่าง Azure ในทุกแพลตฟอร์มที่รองรับโดย Kubecost สำหรับบางส่วน เราคำนวณต้นทุนของบริการภายในคลัสเตอร์ด้วยตนเอง (โดยใช้วิธีการที่คล้ายกับที่ Kubecost ใช้) และยังตรวจสอบต้นทุนโครงสร้างพื้นฐานและพยายามปรับให้เหมาะสม ดังนั้นจึงเป็นเหตุผลที่เราสนใจความเป็นไปได้ในการทำงานดังกล่าวโดยอัตโนมัติ
ซอร์สโค้ดของโมดูล Kubecost หลักเปิดภายใต้เงื่อนไขของใบอนุญาต Open Source (Apache License 2.0) สามารถใช้งานได้อย่างอิสระและคุณสมบัติที่มีอยู่ควรจะเพียงพอสำหรับโครงการขนาดเล็ก อย่างไรก็ตาม ธุรกิจก็คือธุรกิจ ส่วนที่เหลือปิดก็สามารถใช้งานได้
ทุกอย่างทำงานอย่างไร
ดังนั้นส่วนหลักของ Kubecost ก็คือแอปพลิเคชัน
โดยทั่วไปแล้ว โมเดลต้นทุนจะมีอินเทอร์เฟซเว็บของตัวเอง ซึ่งจะแสดงกราฟและสถิติโดยละเอียดเกี่ยวกับต้นทุนในรูปแบบตาราง รวมถึงเคล็ดลับในการปรับต้นทุนให้เหมาะสม แดชบอร์ดที่นำเสนอใน Grafana เป็นขั้นตอนเริ่มต้นในการพัฒนา Kubecost และมีข้อมูลจำนวนมากเหมือนกับโมเดลต้นทุน เสริมด้วยสถิติปกติเกี่ยวกับการใช้ CPU/หน่วยความจำ/เครือข่าย/พื้นที่ดิสก์ในคลัสเตอร์และพื้นที่ ส่วนประกอบ
Kubecost ทำงานอย่างไร?
- โมเดลต้นทุนรับราคาสำหรับบริการผ่าน API ของผู้ให้บริการคลาวด์
- นอกจากนี้ ขึ้นอยู่กับประเภทเหล็กของโหนดและภูมิภาค ต้นทุนต่อโหนดจะถูกคำนวณ
- ขึ้นอยู่กับต้นทุนของการรันโหนด แต่ละ leaf pod จะได้รับต้นทุนต่อชั่วโมงการใช้งาน CPU ต่อกิกะไบต์ของหน่วยความจำที่ใช้ และต่อชั่วโมงต่อกิกะไบต์ของข้อมูลที่จัดเก็บ ขึ้นอยู่กับโหนดที่รันอยู่หรือคลาสของพื้นที่จัดเก็บข้อมูล
- ขึ้นอยู่กับค่าใช้จ่ายในการดำเนินการแต่ละพ็อด การชำระเงินจะถูกคำนวณสำหรับเนมสเปซ บริการ การปรับใช้ และชุดสถานะ
- สถิติคำนวณโดยใช้เมตริกที่ได้รับจาก kube-state-metrics และ node-exporter
สิ่งสำคัญคือต้องคำนึงถึง Kubecost โดยค่าเริ่มต้นจะนับเฉพาะทรัพยากรที่มีอยู่ใน Kubernetes. ฐานข้อมูลภายนอก เซิร์ฟเวอร์ GitLab พื้นที่เก็บข้อมูล S3 และบริการอื่นๆ ที่ไม่ได้อยู่ในคลัสเตอร์ (แม้ว่าจะอยู่ในคลาวด์เดียวกันก็ตาม) จะไม่สามารถมองเห็นได้ แม้ว่าสำหรับ GCP และ AWS คุณสามารถเพิ่มคีย์ของบัญชีบริการของคุณและคำนวณทุกอย่างร่วมกันได้
การติดตั้ง
Kubecost ต้องการ:
- Kubernetes เวอร์ชัน 1.8 และสูงกว่า
- kube-state-เมตริก;
- โพร;
- ผู้ส่งออกโหนด
มันเกิดขึ้นที่คลัสเตอร์ของเราตรงตามเงื่อนไขเหล่านี้ทั้งหมดล่วงหน้า ดังนั้นจึงปรากฏว่าการระบุตำแหน่งข้อมูลที่ถูกต้องสำหรับการเข้าถึง Prometheus ก็เพียงพอแล้ว อย่างไรก็ตาม แผนภูมิ kubecost Helm อย่างเป็นทางการมีทุกสิ่งที่คุณต้องการเพื่อเรียกใช้บนคลัสเตอร์เปล่า
มีหลายวิธีในการติดตั้ง Kubecost:
- วิธีการติดตั้งมาตรฐานที่อธิบายไว้ใน
คำแนะนำ บนเว็บไซต์ของผู้พัฒนา จำเป็น เพิ่มที่เก็บตัววิเคราะห์ต้นทุนไปยัง Helm จากนั้นติดตั้งแผนภูมิ. สิ่งที่เหลืออยู่คือการส่งต่อพอร์ตของคุณและปรับการตั้งค่าเป็นสถานะที่ต้องการด้วยตนเอง (ผ่าน kubectl) และ/หรือใช้เว็บอินเตอร์เฟสแบบจำลองต้นทุนเราไม่ได้ลองใช้วิธีนี้เนื่องจากเราไม่ได้ใช้การกำหนดค่าสำเร็จรูปของบุคคลที่สาม แต่ดูเหมือนว่าจะเป็นตัวเลือก "ลองด้วยตัวคุณเอง" ที่ดี หากคุณมีส่วนประกอบของระบบบางส่วนติดตั้งอยู่แล้ว หรือต้องการปรับแต่งเพิ่มเติม ควรพิจารณาเส้นทางที่สองจะดีกว่า
- ใช้เป็นหลัก
แผนภูมิเดียวกัน แต่กำหนดค่าและติดตั้งด้วยตัวเอง ด้วยวิธีใดก็ได้ที่สะดวกดังที่กล่าวไปแล้ว นอกเหนือจาก kubecost แล้ว แผนภูมินี้ยังมีแผนภูมิ Grafana และ Prometheus ซึ่งสามารถปรับแต่งได้ตามความต้องการ
มีอยู่ในแผนภูมิ
values.yaml
สำหรับเครื่องวิเคราะห์ต้นทุนช่วยให้คุณสามารถกำหนดค่า:- รายการส่วนประกอบเครื่องวิเคราะห์ต้นทุนที่ต้องใช้งาน
- ตำแหน่งข้อมูลของคุณสำหรับ Prometheus (หากคุณมีอยู่แล้ว)
- โดเมนและการตั้งค่าทางเข้าอื่นๆ สำหรับแบบจำลองต้นทุนและ Grafana
- คำอธิบายประกอบสำหรับพ็อด
- ความจำเป็นในการใช้พื้นที่เก็บข้อมูลถาวรและขนาดของมัน
รายการตัวเลือกการกำหนดค่าที่มีพร้อมคำอธิบายทั้งหมดมีอยู่ใน
เอกสาร .เนื่องจาก kubecost ในเวอร์ชันพื้นฐานไม่สามารถจำกัดการเข้าถึงได้ คุณจะต้องกำหนดค่าการตรวจสอบสิทธิ์พื้นฐานสำหรับแผงเว็บทันที
- เพื่อทำการติดตั้ง เฉพาะแกนของระบบเท่านั้น - แบบจำลองต้นทุน ในการดำเนินการนี้ คุณต้องติดตั้ง Prometheus ในคลัสเตอร์ และระบุค่าที่สอดคล้องกันของที่อยู่ในตัวแปร
prometheusEndpoint
สำหรับหางเสือ หลังจากนั้น - สมัครชุดการกำหนดค่า YAML ในคลัสเตอร์คุณจะต้องเพิ่ม Ingress ด้วยการตรวจสอบสิทธิ์แบบพื้นฐานด้วยตนเองอีกครั้ง สุดท้าย คุณจะต้องเพิ่มส่วนสำหรับรวบรวมเมตริกแบบจำลองต้นทุน
extraScrapeConfigs
ในการกำหนดค่า Prometheus:- job_name: kubecost honor_labels: true scrape_interval: 1m scrape_timeout: 10s metrics_path: /metrics scheme: http dns_sd_configs: - names: - <адрес вашего сервиса kubecost> type: 'A' port: 9003
เราได้อะไร?
ด้วยการติดตั้งแบบสมบูรณ์ เรามีแผงเว็บ kubecost และ Grafana พร้อมชุดแดชบอร์ดไว้คอยบริการ
ค่าใช้จ่ายทั้งหมดที่แสดงบนหน้าจอหลักจะแสดงต้นทุนทรัพยากรโดยประมาณสำหรับเดือนนั้นจริง ๆ นี้ ฉาย ราคาสะท้อนถึงต้นทุนการใช้คลัสเตอร์ (ต่อเดือน) ที่ระดับการใช้ทรัพยากรปัจจุบัน
ตัวชี้วัดนี้มีไว้เพื่อการวิเคราะห์ค่าใช้จ่ายและเพิ่มประสิทธิภาพมากขึ้น การดูต้นทุนรวมสำหรับบทคัดย่อเดือนกรกฎาคมใน kubecost ไม่สะดวกนัก: คุณจะต้องทำเช่นนี้ ไปที่การเรียกเก็บเงิน. แต่คุณสามารถดูค่าใช้จ่ายแยกตามเนมสเปซ ป้ายกำกับ พ็อดเป็นเวลา 1/2/7/30/90 วัน ซึ่งการเรียกเก็บเงินจะไม่แสดงให้คุณเห็น
พูดถึง ฉลาก. คุณควรไปที่การตั้งค่าทันทีและตั้งชื่อป้ายกำกับที่จะใช้เป็นหมวดหมู่เพิ่มเติมสำหรับการจัดกลุ่มต้นทุน:
คุณสามารถแขวนฉลากใดๆ ก็ได้ - สะดวกหากคุณมีระบบการติดฉลากของคุณเองอยู่แล้ว
นอกจากนี้คุณยังสามารถเปลี่ยนที่อยู่ของตำแหน่งข้อมูล API ที่โมเดลต้นทุนเชื่อมต่อ ปรับขนาดส่วนลดใน GCP และกำหนดราคาของคุณเองสำหรับทรัพยากรและสกุลเงินสำหรับการวัดผล (ด้วยเหตุผลบางประการ คุณลักษณะนี้ไม่ส่งผลต่อต้นทุนทั้งหมด)
Kubecost สามารถแสดงผลได้หลากหลาย ปัญหาในคลัสเตอร์ (และแม้กระทั่งแจ้งเตือนในกรณีเกิดอันตราย) น่าเสียดายที่ตัวเลือกนี้ไม่สามารถกำหนดค่าได้ ดังนั้น หากคุณมีสภาพแวดล้อมสำหรับนักพัฒนาและใช้งาน คุณจะเห็นสิ่งนี้อยู่ตลอดเวลา:
เครื่องมือสำคัญ - การออมคลัสเตอร์. โดยจะวัดกิจกรรมของพ็อด (การใช้ทรัพยากร รวมถึงทรัพยากรเครือข่าย) และยังคำนวณจำนวนเงินและสิ่งที่คุณสามารถประหยัดได้
อาจดูเหมือนว่าเคล็ดลับการเพิ่มประสิทธิภาพค่อนข้างชัดเจน แต่ประสบการณ์แนะนำว่ายังมีบางสิ่งที่ต้องพิจารณา โดยเฉพาะอย่างยิ่ง กิจกรรมเครือข่ายของพ็อดได้รับการตรวจสอบ (Kubecost แนะนำให้ให้ความสนใจกับกิจกรรมที่ไม่ได้ใช้งาน) การเปรียบเทียบหน่วยความจำที่ร้องขอและจริงและการใช้ CPU รวมถึง CPU ที่ใช้โดยโหนดคลัสเตอร์ (แนะนำให้ยุบหลายโหนดเป็นหนึ่งเดียว) ดิสก์ โหลดและพารามิเตอร์อีกสองสามโหล
เช่นเดียวกับปัญหาการปรับให้เหมาะสมอื่นๆ การเพิ่มประสิทธิภาพทรัพยากรตามข้อมูล Kubecost ต้องการ: รักษาด้วยความระมัดระวัง. ตัวอย่างเช่น Cluster Savings แนะนำให้ลบโหนดโดยอ้างว่าปลอดภัย แต่ไม่ได้คำนึงถึงการมีอยู่ของตัวเลือกโหนดและเทนต์ในพ็อดที่ใช้งานบนโหนดเหล่านั้นซึ่งไม่มีอยู่บนโหนดอื่น และโดยทั่วไปแล้วแม้แต่ผู้เขียนผลิตภัณฑ์ของพวกเขาเอง
ผลของการ
หลังจากใช้ kubecost เป็นเวลาหนึ่งเดือนกับสองโปรเจ็กต์ เราสามารถสรุปได้ว่าเป็นเครื่องมือที่น่าสนใจ (และยังเรียนรู้และติดตั้งได้ง่าย) สำหรับการวิเคราะห์และเพิ่มประสิทธิภาพต้นทุนสำหรับบริการของผู้ให้บริการคลาวด์ที่ใช้สำหรับคลัสเตอร์ Kubernetes การคำนวณมีความแม่นยำมาก: ในการทดลองของเรา การคำนวณนั้นใกล้เคียงกับสิ่งที่ผู้ให้บริการต้องการจริงๆ
นอกจากนี้ยังมีข้อเสียบางประการ: มีข้อบกพร่องที่ไม่สำคัญ และในบางตำแหน่งฟังก์ชันการทำงานไม่ครอบคลุมความต้องการเฉพาะของบางโครงการ อย่างไรก็ตาม หากคุณต้องการเข้าใจอย่างรวดเร็วว่าเงินจะไปอยู่ที่ไหน และสิ่งใดที่สามารถ "ตัด" ได้ เพื่อลดค่าบริการสำหรับบริการคลาวด์อย่างสม่ำเสมอ 5-30% (นี่คือสิ่งที่เกิดขึ้นในกรณีของเรา) นี่เป็นตัวเลือกที่ยอดเยี่ยม .
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «
การปรับขนาดอัตโนมัติและการจัดการทรัพยากรใน Kubernetes (ภาพรวมและรายงานวิดีโอ) "; - «
การผจญภัยของ Kubernetes Dailymotion: การสร้างโครงสร้างพื้นฐานในระบบคลาวด์ + ภายในองค์กร "; - «
เคล็ดลับและคำแนะนำของ Kubernetes: เกี่ยวกับการจัดสรรโหนดและการโหลดแอปพลิเคชันเว็บ '
ที่มา: will.com