K8s/Kubernetes: AWS กับ GCP กับ Azure
เผยแพร่แล้ว: 2022-03-11Kubernetes (มักใช้สไตล์ "K8s") ชนะการต่อสู้ของเครื่องมือจัดเรียงตู้คอนเทนเนอร์เมื่อหลายปีก่อน อย่างไรก็ตาม ยังคงมีหลายวิธีในการติดตั้ง Kubernetes ในปัจจุบัน และทำให้ใช้งานได้กับโครงสร้างพื้นฐานที่หลากหลาย และเครื่องมือมากมาย—บางวิธีได้รับการดูแลดีกว่าวิธีอื่นๆ บางทีการพัฒนาที่น่าสนใจที่สุดในด้านนั้นก็คือผู้ให้บริการคลาวด์ชั้นนำได้ตัดสินใจเปิดตัวเวอร์ชัน Kubernetes ที่มีการจัดการของตนเอง:
- Microsoft Azure ให้บริการ Azure Kubernetes (AKS)
- AWS เสนอบริการ Amazon Elastic Kubernetes (EKS)
- Google Cloud นำเสนอ Google Kubernetes Engine (GKE)
จากมุมมองของ DevOps แพลตฟอร์มเหล่านี้นำเสนออะไร พวกเขาดำเนินชีวิตตามคำสัญญาหรือไม่? เวลาในการสร้างและการเปรียบเทียบอื่น ๆ เป็นอย่างไร? พวกเขารวมเข้ากับแพลตฟอร์มของตนได้ดีเพียงใด โดยเฉพาะเครื่องมือ CLI ของพวกเขา การดูแลและทำงานกับพวกเขาเป็นอย่างไร ด้านล่างนี้ เราจะเจาะลึกคำถามเหล่านี้ และอื่นๆ
หมายเหตุ: สำหรับผู้อ่านที่ต้องการอธิบายแนวคิดของคลัสเตอร์ Kubernetes ก่อนอ่าน Dmitriy Kononov ขอเสนอบทนำที่ยอดเยี่ยม
AKS กับ EKS กับ GKE: คุณสมบัติที่โฆษณา
เราได้ตัดสินใจจัดกลุ่มคุณลักษณะต่างๆ ที่มีให้สำหรับ Kubernetes ที่มีการจัดการแต่ละเวอร์ชันเป็นไซโล:
- ภาพรวมทั่วโลก
- ระบบเครือข่าย
- ความสามารถในการปรับขนาดและประสิทธิภาพ
- ความปลอดภัยและการตรวจสอบ
- ระบบนิเวศ
- ราคา
หมายเหตุ: รายละเอียดเหล่านี้อาจเปลี่ยนแปลงเมื่อเวลาผ่านไป เนื่องจากผู้ให้บริการระบบคลาวด์อัปเดตผลิตภัณฑ์ของตนเป็นประจำ
ภาพรวมทั่วโลก
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| ปีที่ออก | 2017 | 2018 | 2014 |
| รุ่นล่าสุด | 1.15.11 (ค่าเริ่มต้น) - 1.18.2 (ตัวอย่าง) | 1.16.8 (ค่าเริ่มต้น) | 1.14.10 (ค่าเริ่มต้น) - 1.16.9 |
| ส่วนประกอบเฉพาะ | oms-agent, หน้าอุโมงค์ | aws-node | คล่องแคล่ว, คล่องแคล่ว-gcp-scaler, ตัวส่งออกเหตุการณ์, l7-default-backend |
| Kubernetes อัพเกรดเครื่องบินควบคุม | คู่มือ | คู่มือ | อัตโนมัติ (ค่าเริ่มต้น) หรือด้วยตนเอง |
| อัพเกรดคนงาน | คู่มือ | ใช่ (ง่ายกับกลุ่มโหนดที่มีการจัดการ) | ใช่: แบบอัตโนมัติและแบบแมนนวล สามารถปรับแบบละเอียดได้ |
| SLA | 99.95 เปอร์เซ็นต์พร้อมโซนความพร้อมใช้งาน 99.9% ไม่มี | 99.9 เปอร์เซ็นต์สำหรับ EKS (มาสเตอร์), 99.99 เปอร์เซ็นต์สำหรับ EC2 (โหนด) | 99.95 เปอร์เซ็นต์ภายในภูมิภาค 99.5 เปอร์เซ็นต์ภายในโซน |
| การสนับสนุน Knative พื้นเมือง | ไม่ | ไม่ | ไม่ (แต่ติดตั้ง Istio ดั้งเดิม) |
| Kubernetes ราคาเครื่องบินควบคุม | ฟรี | $0.10/ชั่วโมง | $0.10/ชั่วโมง |
Kubernetes เป็นโครงการของ Google ดังนั้นจึงควรที่พวกเขาเป็นคนแรกที่เสนอเวอร์ชันที่โฮสต์ในปี 2014
จากการเปรียบเทียบทั้งสามนี้ Azure อยู่ถัดจาก AKS และมีเวลาปรับปรุงบ้าง: หากคุณจำ acs-engine ซึ่งเคยใช้เพื่อจัดเตรียม Kubernetes บน Azure เมื่อไม่กี่ปีที่ผ่านมา คุณจะซาบซึ้งในความพยายามของ Microsoft ในการแทนที่ เครื่องยนต์ aks
AWS เป็นตัวสุดท้ายที่เปิดตัว EKS เวอร์ชันของตัวเอง ดังนั้นบางครั้งอาจดูเหมือนอยู่เบื้องหลังที่ด้านหน้าของฟีเจอร์ แต่ก็กำลังตามทัน
ในแง่ของราคา แน่นอนว่าสิ่งต่าง ๆ เคลื่อนไหวอยู่เสมอ และ Google ตัดสินใจเข้าร่วมกับ AWS ในราคา $0.10 ต่อชั่วโมง โดยมีผลในเดือนมิถุนายน 2020 Azure เป็นคนนอกที่นี่โดยแจกบริการ AKS ฟรี แต่ก็ไม่ชัดเจนว่าจะทำอย่างไร นานที่อาจคงอยู่
ความแตกต่างที่สำคัญอีกประการหนึ่งอยู่ในคุณลักษณะการอัพเกรดของคลัสเตอร์ การอัปเกรดอัตโนมัติส่วนใหญ่อยู่ใน GKE และจะเปิดไว้โดยค่าเริ่มต้น อย่างไรก็ตาม AKS กับ EKS มีความคล้ายคลึงกันที่นี่ ในแง่ที่ว่าทั้งคู่ต้องการคำขอด้วยตนเองเพื่อให้สามารถอัพเกรดโหนดหลักหรือโหนดผู้ปฏิบัติงานได้
ระบบเครือข่าย
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| นโยบายเครือข่าย | ใช่: นโยบายเครือข่าย Azure หรือ Calico | จำเป็นต้องติดตั้งผ้าดิบ | ใช่: พื้นเมืองผ่าน Calico |
| โหลดบาลานซ์ | โหลดบาลานเซอร์ SKU พื้นฐานหรือมาตรฐาน | ตัวโหลดบาลานซ์แบบคลาสสิกและเครือข่าย | คอนเทนเนอร์เนทีฟโหลดบาลานเซอร์ |
| บริการตาข่าย | ไม่มีนอกกรอบ | AWS App Mesh (ตาม Envoy) | Istio (นอกกรอบ แต่เป็นเบต้า) |
| รองรับ DNS | การปรับแต่ง CoreDNS | CoreDNS + Route53 ภายใน VPC | CoreDNS + Google Cloud DNS |
ในด้านของเครือข่าย ผู้ให้บริการคลาวด์ทั้งสามนั้นอยู่ใกล้กันมาก พวกเขาทั้งหมดให้ลูกค้าใช้นโยบายเครือข่ายกับ Calico เป็นต้น ในส่วนที่เกี่ยวกับการทำโหลดบาลานซ์ พวกเขาทั้งหมดใช้การผสานรวมกับทรัพยากรตัวจัดสรรภาระงานของตนเอง และให้วิศวกรเลือกได้ว่าจะใช้อะไร
ความแตกต่างหลักที่พบในที่นี้ขึ้นอยู่กับมูลค่าเพิ่มของตาข่ายบริการ AKS ไม่รองรับเมชบริการใด ๆ ที่แกะกล่อง (แม้ว่าวิศวกรจะสามารถติดตั้ง Istio ได้ด้วยตนเอง) AWS ได้พัฒนาตาข่ายบริการของตัวเองที่เรียกว่า App Mesh สุดท้าย Google ได้เปิดตัวการรวมเข้ากับ Istio (แม้ว่าจะยังอยู่ในช่วงเบต้า) ซึ่งลูกค้าสามารถเพิ่มได้โดยตรงเมื่อสร้างคลัสเตอร์
ทางออกที่ดีที่สุด: GKE
ความสามารถในการปรับขนาดและประสิทธิภาพ
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| โหนดโลหะเปลือย | ไม่ | ใช่ | ไม่ |
| โหนดสูงสุดต่อคลัสเตอร์ | 1,000 | 1,000 | 5,000 |
| คลัสเตอร์ความพร้อมใช้งานสูง | ไม่ | ใช่สำหรับแผนการควบคุม คู่มือสำหรับ AZ สำหรับผู้ปฏิบัติงาน | ใช่ผ่านคลัสเตอร์ระดับภูมิภาค ต้นแบบและผู้ปฏิบัติงานจะถูกจำลองแบบ |
| ปรับขนาดอัตโนมัติ | ใช่ผ่านตัวปรับขนาดคลัสเตอร์อัตโนมัติ | ใช่ผ่านตัวปรับขนาดคลัสเตอร์อัตโนมัติ | ใช่ผ่านตัวปรับขนาดคลัสเตอร์อัตโนมัติ |
| ตัวปรับขนาดอัตโนมัติพ็อดแนวตั้ง | ไม่ | ใช่ | ใช่ |
| Node Pools | ใช่ | ใช่ | ใช่ |
| โหนด GPU | ใช่ | ใช่ | ใช่ |
| ในองค์กร | พร้อมใช้งานผ่าน Azure ARC (เบต้า) | ไม่ | GKE ในองค์กรผ่าน Anthos GKE |
เกี่ยวกับประสิทธิภาพและความสามารถในการปรับขนาดของ GKE กับ AKS เทียบกับ EKS ดูเหมือนว่า GKE จะเป็นผู้นำ อันที่จริง รองรับโหนดจำนวนมากที่สุด (5,000) และมีเอกสารประกอบที่ครอบคลุมเกี่ยวกับวิธีการปรับขนาดคลัสเตอร์อย่างเหมาะสม ฟีเจอร์ทั้งหมดสำหรับความพร้อมใช้งานสูงมีให้ใช้งานและปรับแต่งได้ง่าย ยิ่งไปกว่านั้น GKE เพิ่งเปิดตัว Anthos ซึ่งเป็นโครงการเพื่อสร้างระบบนิเวศรอบๆ GKE และฟังก์ชันต่างๆ ด้วย Anthos คุณสามารถทำให้ GKE ในองค์กรใช้งานได้
แม้ว่า AWS มีข้อได้เปรียบที่สำคัญ: เป็นสิ่งเดียวที่อนุญาตให้โหนด Bare-metal เรียกใช้คลัสเตอร์ Kubernetes ของคุณ
ณ เดือนมิถุนายน 2020 AKS ขาดความพร้อมในระดับสูงสำหรับปรมาจารย์ ซึ่งเป็นประเด็นสำคัญที่ต้องพิจารณา แต่เช่นเคย สิ่งนั้นอาจเปลี่ยนแปลงได้ในไม่ช้า
ทางออกที่ดีที่สุด: GKE
ความปลอดภัยและการตรวจสอบ
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| การเข้ารหัสลับแอพ | ไม่ | ใช่ ทำได้ผ่าน AWS KMS | ใช่ ทำได้ผ่าน Cloud KMS |
| การปฏิบัติตาม | HIPAA, SOC, ISO, PCI DSS | HIPAA, SOC, ISO, PCI DSS | HIPAA, SOC, ISO, PCI DSS |
| RBAC | ใช่ | ใช่ และการบูรณาการที่แข็งแกร่งกับ IAM | ใช่ |
| การตรวจสอบ | คุณลักษณะความสมบูรณ์ของคอนเทนเนอร์ Azure Monitor | Kubernetes ควบคุมการตรวจสอบเครื่องบินที่เชื่อมต่อกับ Cloudwatch, Container Insights Metrics สำหรับโหนด | Kubernetes Engine การตรวจสอบและการผสานรวมกับ Prometheus |
ในแง่ของการปฏิบัติตามข้อกำหนด ผู้ให้บริการคลาวด์ทั้งสามรายนั้นเทียบเท่ากัน อย่างไรก็ตาม ในแง่ของความปลอดภัย EKS และ GKE มอบการรักษาความปลอดภัยอีกชั้นหนึ่งด้วยบริการการจัดการคีย์แบบฝังตัว
สำหรับการตรวจสอบ Azure และ Google Cloud มีระบบนิเวศการตรวจสอบของตนเองรอบ Kubernetes เป็นที่น่าสังเกตว่า Google เพิ่งอัปเดตเพื่อใช้ Kubernetes Engine Monitoring ซึ่งออกแบบมาเฉพาะสำหรับ Kubernetes
Azure จัดเตรียมระบบตรวจสอบคอนเทนเนอร์ของตัวเอง ซึ่งเดิมสร้างขึ้นสำหรับระบบนิเวศคอนเทนเนอร์พื้นฐานที่ไม่ใช่ของ Kubernetes พวกเขาได้เพิ่มการตรวจสอบสำหรับเมตริกและทรัพยากรเฉพาะของ Kubernetes (ความสมบูรณ์ของคลัสเตอร์ การปรับใช้)—ในโหมดแสดงตัวอย่าง ณ เดือนมิถุนายน 2020
AWS เสนอการตรวจสอบแบบเบาสำหรับระนาบควบคุมโดยตรงใน Cloudwatch ในการตรวจสอบผู้ปฏิบัติงาน คุณสามารถใช้ Kubernetes Container Insights Metrics ที่จัดเตรียมผ่านตัวแทน CloudWatch เฉพาะที่คุณติดตั้งในคลัสเตอร์ได้
ทางออกที่ดีที่สุด: GKE
ระบบนิเวศ
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| ตลาดกลาง | Azure Marketplace (แต่ไม่มีการรวม AKS ที่ชัดเจน) | AWS Marketplace (250+ แอป) | Google Marketplace (90+ แอป) |
| Infrastructure-as-Code (IaC) สนับสนุน | โมดูล Terraform โมดูล Ansible | โมดูล Terraform โมดูล Ansible | โมดูล Terraform โมดูล Ansible |
| เอกสาร | ชุมชนที่อ่อนแอ แต่สมบูรณ์และแข็งแกร่ง (2,000+ โพสต์ Stack Overflow) | ชุมชนไม่ทั่วถึง แต่เข้มแข็ง (โพสต์มากกว่า 1,500 โพสต์) | เอกสารอย่างเป็นทางการที่กว้างขวางและชุมชนที่แข็งแกร่งมาก (4,000+ โพสต์ Stack Overflow) |
| การสนับสนุน CLI | สมบูรณ์ | สมบูรณ์พร้อม eksctl เครื่องมือแยกพิเศษ (ครอบคลุมด้านล่าง) | สมบูรณ์ |
ในแง่ของระบบนิเวศ ผู้ให้บริการทั้งสามรายมีจุดแข็งและสินทรัพย์ที่แตกต่างกัน ตอนนี้ AKS มีเอกสารประกอบที่สมบูรณ์มากเกี่ยวกับแพลตฟอร์ม และเป็นอันดับสองในแง่ของการโพสต์บน Stack Overflow EKS มีจำนวนโพสต์บน Stack Overflow น้อยที่สุด แต่ได้ประโยชน์จากความแข็งแกร่งของ AWS Marketplace GKE เป็นแพลตฟอร์มที่เก่าแก่ที่สุด มีโพสต์บน Stack Overflow มากที่สุด และมีแอพจำนวนมากในตลาดกลาง แต่มีเอกสารประกอบที่ครอบคลุมที่สุด
เดิมพันที่ดีที่สุด: GKE และ EKS
ราคา
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| ขีด จำกัด การใช้งานฟรี | มูลค่า 170 เหรียญ | ไม่มีสิทธิ์ได้รับระดับฟรี | มูลค่า $300 |
| Kubernetes ควบคุมต้นทุนเครื่องบิน | ฟรี | $0.10/ชั่วโมง | $0.10/ชั่วโมง (มิถุนายน 2020) |
| ราคาที่ลดลง (อินสแตนซ์ Spot/โหนดที่ยอมให้มีการขัดจังหวะชั่วคราว) | ใช่ | ใช่ | ใช่ |
| ตัวอย่างราคาสำหรับหนึ่งเดือน | $342 3 D2 โหนด | $300 3 t3.โหนดขนาดใหญ่ | $190 3 n1-มาตรฐาน-2 โหนด |
เกี่ยวกับราคาโดยรวม แม้ว่า GKE จะใช้จุดราคา $0.10/ชั่วโมงสำหรับคลัสเตอร์ใดๆ ก็ตามของ GKE ก็ยังคงเป็นระบบคลาวด์ที่ถูกที่สุด ต้องขอบคุณส่วนลดสำหรับการใช้งานแบบต่อเนื่องของ Google ซึ่งจะนำไปใช้เมื่อใดก็ตามที่การใช้ทรัพยากรแบบออนดีมานด์รายเดือนถึงขั้นต่ำที่กำหนด
สิ่งสำคัญที่ควรทราบคือ แถวราคาตัวอย่างไม่คำนึงถึงการรับส่งข้อมูลไปยังคลัสเตอร์ Kubernetes ที่ผู้ให้บริการระบบคลาวด์สามารถเรียกเก็บเงินได้
เหตุผลที่ AWS ไม่อนุญาตให้ใช้ Free Tier เพื่อทดสอบคลัสเตอร์ EKS ก็คือ EKS ต้องการเครื่องที่ใหญ่กว่าระดับ tX.micro และการกำหนดราคารายชั่วโมงของ EKS ไม่ได้อยู่ใน Free Tier
อย่างไรก็ตาม ยังคงสามารถประหยัดในการทดสอบตัวเลือก Kubernetes ที่มีการจัดการเหล่านี้ด้วยการโหลดที่เหมาะสมโดยใช้โหนดแบบจุด/โหนดที่ยอมให้มีการขัดจังหวะชั่วคราวของผู้ให้บริการระบบคลาวด์แต่ละราย ซึ่งกลยุทธ์ดังกล่าวจะช่วยประหยัดได้ 80 ถึง 90 เปอร์เซ็นต์จากราคาสุดท้ายได้อย่างง่ายดาย (แน่นอนว่าไม่แนะนำให้รันการโหลดการผลิตแบบเก็บสถานะบนเครื่องดังกล่าว!)
คุณลักษณะที่โฆษณาและความได้เปรียบของ Google
เมื่อดูคุณลักษณะต่างๆ ที่โฆษณาทางออนไลน์ ดูเหมือนว่ามีความสัมพันธ์กันระหว่างระยะเวลาที่เวอร์ชัน Kubernetes ที่มีการจัดการมีอยู่ในตลาดและจำนวนคุณลักษณะต่างๆ ดังที่ได้กล่าวมาแล้ว Google ที่เป็นผู้ริเริ่มโครงการ Kubernetes ดูเหมือนจะเป็นข้อได้เปรียบที่ไม่อาจปฏิเสธได้ ส่งผลให้มีการบูรณาการที่ดีขึ้นและแข็งแกร่งขึ้นกับแพลตฟอร์มคลาวด์ของตัวเอง
แต่ไม่ควรมองข้าม AKS และ EKS เมื่อโตเต็มที่ ทั้งสองสามารถใช้ประโยชน์จากคุณลักษณะเฉพาะของตนได้ ตัวอย่างเช่น AWS เป็นรายเดียวที่มีการผสานรวมโหนดแบบ Bare-Metal และยังมีแอปพลิเคชันจำนวนสูงสุดในตลาด
ตอนนี้ฟีเจอร์ที่โฆษณาสำหรับข้อเสนอ Kubernetes แต่ละรายการมีความชัดเจนแล้ว เรามาเจาะลึกกับการทดสอบภาคปฏิบัติกัน
Kubernetes: AWS กับ GCP กับ Azure ในทางปฏิบัติ
การโฆษณาเป็นสิ่งหนึ่ง แต่แพลตฟอร์มต่างๆ จะเปรียบเทียบกันอย่างไรเมื่อต้องแสดงโฆษณาในปริมาณมาก ในฐานะวิศวกรระบบคลาวด์ ฉันรู้ถึงความสำคัญของระยะเวลาที่ใช้ในการวางไข่และทำลายคลัสเตอร์เมื่อบังคับใช้โครงสร้างพื้นฐานเป็นโค้ด แต่ฉันยังต้องการสำรวจความเป็นไปได้ของแต่ละ CLI และแสดงความคิดเห็นว่าผู้ให้บริการระบบคลาวด์แต่ละรายทำให้มันวางไข่คลัสเตอร์ได้ง่ายเพียงใด (หรือไม่)
ประสบการณ์ผู้ใช้การสร้างคลัสเตอร์
AKS
บน AKS การวางไข่ของคลัสเตอร์จะคล้ายกับการสร้างอินสแตนซ์ใน AWS เพียงค้นหาเมนู AKS และดำเนินการตามเมนูต่างๆ เมื่อตรวจสอบการกำหนดค่าแล้ว คลัสเตอร์จะถูกสร้างขึ้นได้ ซึ่งเป็นกระบวนการสองขั้นตอน มันตรงไปตรงมามาก และวิศวกรสามารถเปิดใช้คลัสเตอร์ด้วยการตั้งค่าเริ่มต้นได้อย่างง่ายดายและรวดเร็ว
EKS
การสร้างคลัสเตอร์นั้นซับซ้อนกว่าใน EKS กับ AKS อย่างแน่นอน ประการแรก ตามค่าเริ่มต้น AWS กำหนดให้ต้องเดินทางไปที่ IAM เพื่อสร้างบทบาทใหม่สำหรับเครื่องบินควบคุม Kubernetes และมอบหมายวิศวกรให้ สิ่งสำคัญที่ควรทราบเช่นกันว่าการสร้างคลัสเตอร์นี้ไม่รวมการสร้างโหนด ดังนั้นเมื่อฉันวัดโดยเฉลี่ย 11 นาที สิ่งนี้มีไว้สำหรับการสร้างต้นแบบเท่านั้น การสร้างกลุ่มโหนดเป็นอีกขั้นตอนหนึ่งสำหรับผู้ดูแลระบบ โดยต้องมีบทบาทอีกครั้งสำหรับผู้ปฏิบัติงานด้วยนโยบายที่จำเป็นสามประการที่จะทำผ่านแผงควบคุม IAM
GKE
สำหรับฉัน ประสบการณ์ในการสร้างคลัสเตอร์ด้วยตนเองบน GKE นั้นน่าพอใจที่สุด หลังจากค้นหา Kubernetes Engine ใน Google Cloud Console แล้ว ให้คลิกเพื่อสร้างคลัสเตอร์ การตั้งค่าประเภทต่างๆ จะปรากฏในเมนูทางด้านซ้าย Google จะเติมคลัสเตอร์ใหม่ล่วงหน้าด้วย Node Pool เริ่มต้นที่แก้ไขได้ง่าย สุดท้ายแต่ไม่ท้ายสุด GKE มีเวลาวางไข่ของคลัสเตอร์ที่เร็วที่สุด ซึ่งจะนำเราไปยังตารางถัดไป
ถึงเวลาวางไข่คลัสเตอร์
| ด้านการ บริการ | AKS | EKS | GKE |
|---|---|---|---|
| ขนาด | 3 โหนด (Ds2-v2) โดยแต่ละโหนดมี 2 vCPU, RAM 7 GB | 3 โหนด t3.large | 3 โหนด n1-standard-2 |
| เวลา (m:ss) | เฉลี่ย 5:45 สำหรับคลัสเตอร์เต็ม | 11:06 สำหรับมาสเตอร์บวก 2:40 สำหรับกลุ่มโหนด (รวม 13:46 สำหรับคลัสเตอร์เต็ม) | เฉลี่ย 2:42 สำหรับคลัสเตอร์เต็ม |
ฉันทำการทดสอบเหล่านี้ในภูมิภาคเดียวกัน (แฟรงค์เฟิร์ตและยุโรปตะวันตกสำหรับ AKS) เพื่อขจัดผลกระทบที่อาจเกิดขึ้นต่อเวลาวางไข่ของความแตกต่างนี้ ฉันยังพยายามเลือกขนาดเดียวกันสำหรับโหนดสำหรับคลัสเตอร์: สามโหนด โดยแต่ละโหนดมี vCPU สองตัวและหน่วยความจำเจ็ดหรือแปด GB ซึ่งเป็นขนาดมาตรฐานสำหรับโหลด Kubernetes เพียงเล็กน้อยและเริ่มทำการทดลอง ฉันสร้างแต่ละคลัสเตอร์สามครั้งเพื่อคำนวณค่าเฉลี่ย
ในการทดสอบเหล่านี้ GKE ยังคงนำหน้าด้วยเวลาวางไข่น้อยกว่าสามนาทีเสมอ
Kubernetes: ภาพรวม AWS กับ GCP กับ Azure CLI
ไม่ได้สร้าง CLI ทั้งหมดเท่ากัน แต่ในกรณีนี้ CLI ทั้งสามตัวเป็นโมดูลของ CLI ที่ใหญ่กว่า การเริ่มต้นใช้งาน CLI toolchain ของผู้ให้บริการคลาวด์แต่ละรายเป็นอย่างไร
AKS CLI (ผ่าน az )
หลังจากติดตั้งเครื่องมือ az แล้วโมดูล AKS (ผ่าน az aks install-cli ) วิศวกรจำเป็นต้องอนุญาตให้ CLI สื่อสารกับบัญชี Azure ของโครงการ นี่เป็นเรื่องของการรับข้อมูลประจำตัวเพื่ออัปเดตไฟล์ kubeconfig ในเครื่องผ่าน az aks get-credentials --resource-group myResourceGroup --name myAKSCluster อย่างง่าย
ในทำนองเดียวกัน เพื่อสร้างคลัสเตอร์: az aks create --resource-group myResourceGroup --name myAKSCluster
EKS CLI (ผ่าน aws หรือ eksctl )
บน AWS เราพบแนวทางที่แตกต่าง—มีเครื่องมือ CLI อย่างเป็นทางการสองแบบที่แตกต่างกันเพื่อจัดการคลัสเตอร์ EKS เช่นเคย aws สามารถเชื่อมต่อกับทรัพยากร AWS โดยเฉพาะคลัสเตอร์ การรับข้อมูลประจำตัวใน kubeconfig ในพื้นที่สามารถทำได้ผ่าน: aws eks update-kubeconfig --name cluster-test
อย่างไรก็ตาม วิศวกรยังสามารถใช้ eksctl ที่พัฒนาโดย Weaveworks และเขียนในภาษา Go เพื่อสร้างและจัดการคลัสเตอร์ EKS ได้อย่างง่ายดาย ประโยชน์หลักที่ EKS มอบให้สำหรับวิศวกรระบบคลาวด์คือพวกเขาสามารถรวมเข้ากับไฟล์การกำหนดค่า YAML เพื่อสร้างโครงสร้างพื้นฐานเป็นโค้ด (IaC) เนื่องจากทำงานร่วมกับ CloudFormation เป็นเรื่องที่ควรพิจารณาอย่างยิ่งเมื่อรวมคลัสเตอร์ EKS เข้ากับโครงสร้างพื้นฐานขนาดใหญ่บน AWS
การสร้างคลัสเตอร์ผ่าน eksctl นั้นง่ายเหมือน eksctl create cluster ไม่จำเป็นต้องใช้พารามิเตอร์อื่น
GKE CLI (ผ่าน gcloud )
สำหรับ GKE ขั้นตอนจะคล้ายกันมาก: ติดตั้ง gcloud จากนั้นตรวจสอบสิทธิ์ผ่าน gcloud init ความเป็นไปได้จากที่นั่น: วิศวกรสามารถสร้าง ลบ อธิบาย รับข้อมูลรับรองสำหรับ ปรับขนาด อัปเดต หรืออัปเกรดคลัสเตอร์ หรือแสดงรายการคลัสเตอร์
ไวยากรณ์ในการสร้างคลัสเตอร์ด้วย gcloud นั้นตรงไปตรงมา: gcloud container clusters create myGCloudCluster --num-nodes=1
AKS กับ EKS กับ GKE: ผลการขับทดสอบ
ในทางปฏิบัติ เราจะเห็นได้ว่า GKE นั้นเร็วที่สุดในการหมุนคลัสเตอร์พื้นฐาน ในแง่ของความเรียบง่ายของคอนโซลและเวลาวางไข่ของคลัสเตอร์ UX-wise ด้วยปุ่มเชื่อมต่อที่อยู่ถัดจากคลัสเตอร์ ทำให้ง่ายต่อการเชื่อมต่อกับคลัสเตอร์เช่นกัน
ในแง่ของเครื่องมือ CLI ผู้ให้บริการระบบคลาวด์ทั้งสามรายได้ใช้ฟังก์ชันการทำงานที่คล้ายคลึงกัน อย่างไรก็ตาม เราสามารถเน้นที่เครื่องมือพิเศษที่ Weaveworks สำหรับ EKS ให้มา eksctl เป็นเครื่องมือที่สมบูรณ์แบบสำหรับคุณในการปรับใช้โครงสร้างพื้นฐานเป็นโค้ดบนโครงสร้างพื้นฐาน AWS ที่มีอยู่ก่อนของคุณ โดยรวมบริการอื่นๆ เข้ากับ EKS
ข้อเสนอ Kubernetes ที่ได้รับการจัดการ Forge Ahead: AWS กับ GCP กับ Azure
สำหรับผู้ที่เพิ่งเริ่มต้นในโลกของ Kubernetes การใช้งานแบบ go-to สำหรับฉันคือ GKE เพราะมันตรงไปตรงมาที่สุด ตั้งค่าได้ง่าย มี UX ที่ง่ายและรวดเร็วสำหรับการวางไข่ และมีการผสานรวมเข้ากับระบบนิเวศของ Google Cloud Platform เป็นอย่างดี
แม้ว่า AWS จะเป็นคนสุดท้ายที่เข้าร่วมการแข่งขัน แต่ก็มีข้อดีที่ปฏิเสธไม่ได้บางประการ เช่น โหนดโลหะเปลือยและข้อเท็จจริงง่ายๆ ที่รวมเข้ากับผู้ให้บริการที่มีส่วนแบ่งทางความคิดที่ใหญ่ที่สุด
ในที่สุด AKS ก็มีความก้าวหน้าอย่างมากนับตั้งแต่มีการก่อตั้ง การใช้เครื่องมือและความเท่าเทียมกันของคุณลักษณะจะใช้เวลาไม่นาน ในขณะเดียวกันก็ออกจากพื้นที่ในกระบวนการสร้างสรรค์สิ่งใหม่ ๆ และเช่นเดียวกับข้อเสนอ Kubernetes ที่มีการจัดการใดๆ สำหรับผู้ที่อยู่บนแพลตฟอร์มหลักอยู่แล้ว การผสานรวมจะเป็นจุดขาย
เมื่อทีมได้เลือกผู้ให้บริการคลาวด์ Kubernetes แล้ว การดูประสบการณ์ของทีมอื่นๆ อาจเป็นเรื่องที่น่าสนใจ โดยเฉพาะความล้มเหลว การชันสูตรพลิกศพเหล่านี้เป็นภาพสะท้อนของกรณีต่างๆ ในโลกแห่งความเป็นจริง ซึ่งเป็นจุดเริ่มต้นที่ดีสำหรับการพัฒนาแนวปฏิบัติที่ดีที่สุดของตนเองอยู่เสมอ ฉันหวังว่าจะแสดงความคิดเห็นของคุณด้านล่าง!