ทำไมต้องย้ายเลยล่ะ?
Docker Compose ยอดเยี่ยมสำหรับการพัฒนาในเครื่องและการใช้งานขนาดเล็ก ฉันเรียกใช้ SaaS ของผลิตภาพบน Compose ได้เป็นเวลา 2 ปีโดยไม่มีการเสียใจเลย ความเจ็บปวดเริ่มขึ้นเมื่อคุณต้องการการปรับขนาด Container ลงชั่วคราวหรือความยืดหยุ่นของหลายโหนด หากแอปของคุณทำงานบนเซิร์ฟเวอร์เดียวและคุณยินดีกับนั้น ให้หยุดอ่าน — Compose ก็ใช้ได้ดี
แต่ถ้าคุณเจอกำแพงใดๆ เหล่านี้ Kubernetes ก็คุ้มค่ากับภาษีความซับซ้อน:
- คุณต้องการปรับขนาดบริการแต่ละรายการอย่างเป็นอิสระ
- การปรับใช้งานทำให้เกิดการหยุดชั่วคราวเนื่องจาก Container เริ่มต้นใหม่อย่างเป็นลำดับ
- ความล้มเหลวของโหนดเดียวทำให้ Stack ทั้งหมดออฟไลน์
- คุณกำลัง SSH ด้วยตนเองไปยังเซิร์ฟเวอร์เพื่อจุดหยุดหรือเริ่มต้นบริการใหม่
วิธีการแบบเพิ่มขึ้นทีละน้อย
ข้อผิดพลาดที่ใหญ่ที่สุดที่ฉันเห็นทีมทำคือพยายามย้ายทุกอย่างพร้อมกัน แต่ฉันติดตามวิธีการ 3 ขั้นตอนที่เก็บผลิตภาพให้เสถียรตลอด
ขั้นตอนที่ 1: ทำให้ Container พร้อมสำหรับผลิตภาพ
ถ้า Dockerfiles ของคุณไม่พร้อมสำหรับผลิตภาพ ให้แก้ไขก่อน Multi-stage builds, ผู้ใช้ที่ไม่ใช่ root, Health checks และการจัดการสัญญาณที่เหมาะสม ไม่มีสิ่งใดเป็น Kubernetes-specific และจะปรับปรุง Compose setup ของคุณด้วย
Dockerfile ที่ผลิตภาพดีติดตามหลักการเหล่านี้: minimal base images (Alpine หรือ distroless), explicit version pinning, layer caching optimization และการแยก ENTRYPOINT/CMD ที่เหมาะสม
ขั้นตอนที่ 2: แยกการตั้งค่า
ย้ายตัวแปรสภาพแวดล้อมทั้งหมดไปยังระบบการตั้งค่าแบบมีโครงสร้าง ใน Compose คุณอาจมีการกระจายไปทั่ว .env files และ docker-compose.yml ใน Kubernetes พวกเขาจะอยู่ใน ConfigMaps และ Secrets
สร้างเมทริกซ์การตั้งค่าที่แมปตัวแปรสภาพแวดล้อมทุกตัวกับแหล่งที่มา ไม่ว่าจะเป็นข้อมูลที่ละเอียดอ่อน และบริการใดใช้งาน แบบฝึกหัดนี้เพียงอย่างเดียวจะจับข้อบกพร่องในการตั้งค่า
ขั้นตอนที่ 3: ย้ายบริการทีละรายการ
เริ่มจากบริการที่ไม่ขาดทุน บางทีอาจเป็นพนักงานในพื้นหลังหรือเครื่องมือภายใน สร้าง Kubernetes manifests: Deployment, Service, ConfigMap ปรับใช้งานควบคู่กับ Compose stack ของคุณ เมื่อมันเสถียร ให้ส่งเส้นทางไปยังมันและปลดประจำการ Compose version
ทำซ้ำสำหรับแต่ละบริการ โดยบันทึกไว้บริการที่สำคัญที่สุดของคุณ (โดยปกติคือ API gateway หรือ primary database) สุดท้าย
รูปแบบ Manifest ที่ใช้งาน
หลังจากการย้ายแบบ 3 ครั้ง ฉันได้สรุปรูปแบบ manifest ที่ปรับขนาดได้ดี บริการแต่ละรายการได้รับไดเรกทอรี่ของตัวเองที่มี 4 ไฟล์: deployment.yaml, service.yaml, configmap.yaml และตัวเลือก hpa.yaml สำหรับการปรับขนาด
ขีดจำกัดทรัพยากร
ตั้งค่าทั้งคำขอและขีดจำกัดเสมอ คำขอกำหนดการจัดตำแหน่ง — Kubernetes ใช้พวกเขาเพื่อตัดสินใจว่าโหนดใดได้ pod ของคุณ ขีดจำกัดป้องกัน Container แบบวิ่งหนีจากการทำให้เพื่อนบ้านขาด เริ่มต้นอนุรักษ์และปรับตามตัวชี้วัดจริง
รูปแบบที่ฉันชอบ: ตั้งค่าคำขอไปยัง P50 usage และขีดจำกัดเป็น 2 เท่า 監視 สำหรับสัปดาห์ จากนั้นรัดกุม ภายใต้การจัดเตรียมทำให้เกิด OOMKills; การจัดเตรียมมากเกินไปเสียเงิน
Health Checks
Kubernetes health checks มีความแตกต่างมากกว่า Docker’s HEALTHCHECK คุณมีสามประเภท: startup probes (สำหรับแอปที่เริ่มต้นช้า) liveness probes (ฉันควรเริ่มต้นใหม่ Container นี้?) และ readiness probes (ฉันควรส่งเส้นทางที่นี่?)
ข้อผิดพลาดที่พบบ่อยที่สุดคือการทำให้ liveness probes ดุร้ายเกินไป ถ้าแอปของคุณใช้เวลา 30 วินาที ในการเริ่มต้น อย่าตั้ง liveness probe ด้วยค่าหมดเวลา 10 วินาที — Kubernetes จะฆ่ามันในลูปเริ่มต้นใหม่ ใช้ startup probes สำหรับผู้เริ่มต้นช้า และรักษา liveness probes ให้เรียบง่าย (ตรวจสอบ TCP พื้นฐาน หรือ endpoint HTTP ที่เบา)
การอัปเดตแบบ Rolling
กำหนดค่ากลยุทธ์การปรับใช้งานของคุณสำหรับการอัปเดตลงชั่วคราว การตั้งค่าหลักคือ maxSurge (กี่ pod พิเศษระหว่างการอัปเดต) และ maxUnavailable (กี่ pod สามารถลงได้พร้อมกัน) สำหรับบริการส่วนใหญ่ maxSurge ของ 1 และ maxUnavailable ของ 0 ให้การอัปเดตลำดับที่ปลอดภัยสำหรับคุณ
Networking Gotchas
สิ่งที่น่าแปลกใจที่สุดสำหรับผู้ย้ายจาก Compose ไปยัง Kubernetes คือ Networking ใน Compose บริการพูดคุยกันด้วยชื่อบน Docker network ร่วม ใน Kubernetes คุณมี ClusterIP services, DNS resolution และอาจมี network policies
Service discovery ทำงานในลักษณะเดียวกัน — คุณอ้างอิงบริการด้วยชื่อ Kubernetes Service — แต่กลไกพื้นฐานแตกต่างกัน DNS resolution สามารถเพิ่มเวลาความหน่วง และคุณจะต้องเข้าใจความแตกต่างระหว่าง ClusterIP, NodePort และ LoadBalancer service types
Ingress controllers แทนที่ reverse proxy Compose ของคุณ (โดยปกติ Nginx หรือ Traefik) ฉันแนะนำให้เริ่มต้นด้วย Nginx Ingress Controller สำหรับความคุ้นเคย จากนั้นประเมินทางเลือก เช่น Traefik หรือ Istio เมื่อคุณสบายใจ
การพิจารณาด้านการจัดเก็บข้อมูล
บริการที่ไม่มี state ย้ายได้ง่าย บริการที่มี state — ฐานข้อมูล, file storage, message queues — ต้องคิดมากขึ้น คำแนะนำของฉัน: อย่าเรียกใช้ฐานข้อมูลใน Kubernetes เว้นแต่คุณมี platform team ที่เฉพาะ ใช้บริการที่จัดการ (RDS, Cloud SQL, managed Redis) และเชื่อมต่อกับพวกเขาจาก cluster ของคุณ
สำหรับ file storage ให้แทนที่ Docker volumes ด้วย PersistentVolumeClaims ที่สนับสนุนโดย storage class ของ cloud provider ของคุณ สำหรับ shared storage ข้าม pods โปรดลองใช้ NFS หรือวิธีแก้ปัญหา cloud-native เช่น EFS
การติดตามการย้ายข้อมูล
คุณต้องการความมองเห็นก่อน ระหว่าง และหลังการย้ายข้อมูล ตั้ง Prometheus และ Grafana (หรือสแต็กที่คุณชอบ) เพื่อติดตามทั้ง Compose และ Kubernetes workloads พร้อมกัน ตัวชี้วัดหลักเพื่อติดตาม: request latency, error rates, resource utilization และ pod restart counts
ระหว่างการย้ายข้อมูล ให้เรียกใช้ทั้งสองสแต็กควบคู่กันและเปรียบเทียบตัวชี้วัด ควรสืบสวนการลดลงใด ๆ ในเวอร์ชัน Kubernetes ก่อนปลดประจำการ Compose equivalent
บทเรียนที่เรียนรู้
หลังจากการย้ายข้อมูล 3 ครั้ง นี่คือสิ่งที่ฉันหวังว่าจะรู้ตั้งแต่เริ่มต้น: ก่อนอื่น ลงทุนในเครื่องมือ local development สำหรับวัตถุประสงค์ — Skaffold, Tilt หรือเครื่องมือที่คล้ายคลึงกัน ทำให้นักพัฒนา experience สามารถทำได้ ประการที่สอง namespaces เป็นเพื่อนของคุณ; ใช้พวกเขาเพื่อแยกสภาพแวดล้อม ประการที่สาม RBAC ไม่ใช่ตัวเลือก; ตั้งค่าตั้งแต่วันแรก ประการที่สี่ GitOps (ArgoCD หรือ Flux) จ่ายสำหรับตัวเองภายในเดือนแรก
การย้ายข้อมูลเองโดยปกติจะใช้เวลา 2-4 สัปดาห์สำหรับทีมสองคน ขึ้นอยู่กับจำนวนบริการและความซับซ้อนของ stateful workloads ของคุณ วางแผนอีกเดือนหนึ่งสำหรับการปรับแต่งและเสถียรภาพก่อนเรียกมันว่าเสร็จ
