การซื้อบัญชี Google Cloud: สร้างอินสแตนซ์การปรับใช้ Docker โดยอาศัย GCP Artifact Registry และ GKE

เมฆ 2026-05-30 阅读 15

เพื่อนๆส่วนใหญ่ที่เล่นคลาวด์เนทีฟและโยน K8s ได้สัมผัสกับความเจ็บปวดจากการถูกทรมานจาก "การกระจายภาพคอนเทนเนอร์" และ "การปรับใช้คลัสเตอร์"

กระบวนการสร้างขึ้นเองแบบดั้งเดิมมักจะเป็นเช่นนี้: เขียนโค้ดในเครื่องบรรจุลงในมิเรอร์ Docker จากนั้นส่งไปยัง Harbor ส่วนตัวหรือ Docker Hub แบบโอเพนซอร์สจากนั้นคุณต้องดูแลรักษาข้อมูลประจำตัวสำหรับการดึงสตรีมของโหนด K8s (Secret) ด้วยตนเองเมื่อข้อมูลประจำตัวหมดอายุคลัสเตอร์ GKE (Google Kubernetes Engine) จะแจ้งข้อผิดพลาดอย่างรัวๆ

ImagePullBackOff

(ดึงกระจกล้มเหลว) ข้อผิดพลาดเหนือธรรมชาติไม่ต้องพูดถึงว่าเนื่องจากคลังสินค้ามิเรอร์และคลัสเตอร์คอมพิวเตอร์ไม่ได้อยู่ในห้องคอมพิวเตอร์เดียวกันเมื่อมีการดึงมิเรอร์ขนาดใหญ่หลาย GB ข้ามภูมิภาคค่าบริการข้อมูลเครือข่ายสาธารณะที่สูงและความล่าช้าในการดึงสตรีมที่ช้ามาก

ในระบบนิเวศสมัยใหม่ของ Google Cloud(GCP, Google Cloud) มีการผสมผสานทองคำระดับองค์กรระดับตำรา:

ใช้ Artifact Registry เพื่อจัดการสินทรัพย์คอนเทนเนอร์และร่วมมือกับ GKE เพื่อดำเนินการจัดเรียงและจัดส่งคอนเทนเนอร์อัตโนมัติ

ความอยู่ยงคงกระพันของทั้งสองคนคือ

สิทธิ์ระดับล่างถูกเชื่อมโยงโดยธรรมชาติ (บนพื้นฐานของ IAM)

。คุณไม่จำเป็นต้องกำหนดค่า K8s Secret ที่ยุ่งยากใดๆโหนด GKE สามารถดึงมิเรอร์ในไม่กี่วินาทีและทำการอัปเดตแบบเลื่อนให้เสร็จสมบูรณ์ด้วยแบนด์วิดท์อินทราเน็ตที่ปลอดภัยสูงมาก

วันนี้เราจะไม่พูดถึงทฤษฎีระบบกระจายที่ซับซ้อนพร้อมปฏิเสธศัพท์แสงทางการทุกชนิดเริ่มต้นโดยตรงจากศูนย์นำคุณไปบรรจุเว็บแอปพลิเคชันและปรับใช้อย่างต่อเนื่องในคลัสเตอร์การผลิต GKE ด้วยมาตรฐานการผลิตของผู้ผลิตรายใหญ่

ระยะที่หนึ่ง: การถอดประกอบเชิงลึกโมเดลโลกสามมิติของการส่งมอบแบบคลาวด์เนทีฟ

ก่อนที่จะพิมพ์คำสั่งคุณต้องชี้แจงวงจรชีวิตที่สมบูรณ์ตั้งแต่รหัสไปจนถึงออนไลน์สาธารณะในใจของคุณระบบท่อส่งระดับองค์กรทั้งชุดประกอบขึ้นจากสามฐานยุทธศาสตร์หลักดังต่อไปนี้:

ท่าเรือคอนเทนเนอร์ (Artifact Registry): คลังสินค้าผลิตภัณฑ์พิเศษรุ่นใหม่ของ GCP (แทนที่ GCR เก่าอย่างสมบูรณ์) มีหน้าที่จัดเก็บเวอร์ชันมิเรอร์ Docker ที่คุณบรรจุไว้และมาพร้อมกับฟังก์ชันการสแกนช่องโหว่ระดับผู้ผลิต Google

คำนวณเครื่องยนต์ (GKE คลัสเตอร์): บริการ K8s ของ Google โฮสติ้งคุณไม่จำเป็นต้องจัดการโหนด Master ที่ด้านล่างเพียงแค่บอกผ่านไฟล์ YAML ที่ประกาศ: "ฉันต้องการเรียกใช้เว็บคอนเทนเนอร์3สำเนา" และจะช่วยคุณรักษาเสถียรภาพในพื้นหลังโดยอัตโนมัติ

Security Gate (บทบาท IAM): นี่คือกุญแจสำคัญในการผ่านโดยไม่ต้องใช้คีย์เราจะแขวนบัญชีบริการเฉพาะสำหรับโหนด GKE เพื่อให้มีสิทธิพิเศษในการอ่านอิมเมจ Artifact Registry

ขั้นตอนที่สอง: การเตรียมความพร้อมด้านสิ่งแวดล้อม-การเปิดพื้นที่โครงสร้างพื้นฐานบน GCP

โปรดตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งและกำหนดค่าไว้แล้ว

ตกลงแล้ว

จีคลาวด์

CLI (เครื่องมือบรรทัดคำสั่งของ Google Cloud) และ Docker Engine

1.เปิดใช้งานหลัก API (ขั้นตอนแรกของการถมที่รกร้างว่างเปล่า)

พิมพ์คำสั่งนี้ในเทอร์มินัลและเปิดใช้งานเครื่องยนต์ Google Cloud ทั้งหมดที่เราต้องการใช้:

แบช

gcloud services enable container.googleapis.com artifactregistry.googleapis.com

2. สร้างคลังภาพลับ (Artifact Registry)

เราอยู่ในภูมิภาคไต้หวันของจีน(

เอเชีย-ตะวันออก1

,ความหน่วงในการเข้าถึงภายในประเทศต่ำมาก) สร้างคลังเก็บเฉพาะสำหรับ Docker โดยสมมุติให้ ID ของโครงการคือ

โครงการ-จีเคอีของฉัน

แบช

Gcloud artifacts repositories create gke-repo\

--รูปแบบที่เก็บข้อมูล=docker

--ตำแหน่ง=เอเชียตะวันออก1

-- Description = "GKE Production Images Repository"

3. สร้างคลัสเตอร์ GKE แบบโฮสต์ (โหมด Autopilot)

สำหรับวิสาหกิจขนาดกลางและขนาดย่อมหรือทีมงานที่ไม่ต้องการถูกความซับซ้อนในการปรับแต่งของ K8s ทำให้เหนื่อยใจ

ขอแนะนำอย่างยิ่งให้เลือกใช้โหมด Autopilot (การขับขี่อัตโนมัติ)

。คุณไม่จำเป็นต้องจัดการการกำหนด CPU และหน่วยความจำของโหนดโดยกูเกิลจะปรับขนาดแบบอัตโนมัติตามคำประกาศของพอดของคุณและเรียกเก็บค่าใช้จ่ายเฉพาะตามปริมาณทรัพยากรที่พอดของคุณใช้งานจริงเท่านั้น

แบช

Gcloud container clusters create-auto prod-gke-cluster \

--ตำแหน่ง=เอเชียตะวันออก1

(การสร้างคลัสเตอร์จะใช้เวลาประมาณ3~ 5นาทีดื่มกาแฟสักแก้วแล้วอดทนรอค่ะ)

ขั้นตอนที่สาม: การฝึกปฏิบัติจริง – การบรรจุโค้ดในเครื่องลงในคอนเทนเนอร์และการอัปโหลดข้อมูลสู่คลาวด์

เราคิดว่าคุณมีเว็บแอปพลิเคชันที่ง่ายมาก (ไม่ว่าจะเป็น Node.js หรือ Python) ซึ่งจะตรวจสอบภายในเครื่อง

8080

พอร์ต

1. สร้าง Dockerfile ระดับการผลิตที่มีความแข็งแกร่ง

ในไดเรกทอรีหลักของโครงการให้สร้างใหม่หนึ่งรายการ

ไฟล์ Dockerfile

# ใช้ภาพฐานแบบเบาอย่างเป็นทางการ

จากอัลไพน์:3.18

# ติดตั้งความขับเคลื่อนของรันไทม์ (ตัวอย่างด้วย Python)

เรียกใช้คำสั่ง apk add --no-cache python3 py3-pip

กำหนดไดเรกทอรีการทำงานเป็น /app

คาร์บอนมอนอกไซด์

พีวาย. /แอป

# เปิดเผยพอร์ตของระบบธุรกิจ

เปิดเผย8080

# เริ่มต้นบริการเว็บ

CMD ["python3", "-m", "http.server", "8080"]

2. การผูกข้อความลับ: กำหนดค่าการยืนยันตัวตนระหว่าง Docker ที่ทำงานบนเครื่องและ GCP

หลายคนที่สตรีมข้อมูลที่นี่มักจะพบข้อผิดพลาดเนื่องจากโดยค่าเริ่มต้น Docker ไม่รู้จักคลังของ GCP เราจำเป็นต้องทำให้

จีคลาวด์

นำใบรับรองความปลอดภัยไปฝังลงในไฟล์กำหนดค่าของ Docker บนเครื่องโดยตรง:

แบช

gcloud auth configure-docker asia-east1-docker.pkg.dev

3. คอมไพล์ติดป้ายกำกับและสตรีมอย่างเข้มข้น

ตามข้อกำหนดมาตรฐานของ Artifact Registry ให้ตั้งชื่อภาพดิสก์อย่างเป็นมาตรฐานโดยมีพาธบนคลาวด์แล้วจึงอัปโหลดขึ้นไป:

แบช

# คอมไพล์และแพ็กเกจเป็นเวอร์ชัน v1.0

docker build -t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0.

# ผลักดันการสตรีมขึ้นสู่คลาวด์อย่างเต็มที่

docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

เมื่อแถบแสดงความคืบหน้าดำเนินไปจนครบแล้วให้เข้าสู่หน้า Artifact Registry ในคอนโซลของ GCP คุณจะพบว่าอิมเมจได้ถูกเก็บไว้อย่างมั่นคงบนคลาวด์และกูเกิลได้เริ่มทำการสแกนหาช่องโหว่ของระบบปฏิบัติการให้โดยอัตโนมัติในเบื้องหลังเรียบร้อยแล้ว

ขั้นตอนที่สี่: การฝึกปฏิบัติจริงตอนที่สอง – การใช้ YAML แบบประกาศเพื่อปรับใช้คลัสเตอร์ GKE

อิมเมจได้อัปโหลดขึ้นคลาวด์แล้วทำอย่างไรให้ GKE ดึงอิมเมจนั้นมาสร้างเป็นคอนเทนเนอร์ (Pod) ที่พร้อมให้บริการจริง? ในโลกของ K8s เราไม่ได้พิมพ์คำสั่งบูตเราเขียน

ไฟล์กำหนดค่า YAML

。

เชื่อมต่อจากเครื่องภายในไปยังคลัสเตอร์ GKE ที่เพิ่งสร้างขึ้นและดึงข้อมูลประจำตัวสำหรับการรับรองความถูกต้อง:

แบช

gcloud container clusters get-credentials prod-gke-cluster --location=asia-east1

สร้างใหม่ในพื้นที่ที่เรียกว่า

เดปโลยเมนต์.ยูเอ็มแอล

ไฟล์ดังกล่าวให้ใส่โค้ดเชิงประกาศต่อไปนี้ซึ่งสอดคล้องกับข้อกำหนดโครงสร้างแบบข้ามชาติของบริษัทยักษ์ใหญ่:

ยามล

apiVersion: apps/v1

ชนิด: การปรับใช้

เมตาดาต้า:

ชื่อ: การปรับใช้แอปพลิเคชันเว็บ

ป้ายกำกับ:

App: web-se

บริการ

สเปค:

สำเนา: 3 # กำหนดให้มีความพร้อมใช้งานสูงแบบตายตัว: มีคอนเทนเนอร์สำรองประจำอยู่3ชุดหากมีอันใดเสียหายระบบจะเริ่มต้นคอนเทนเนอร์ใหม่อัตโนมัติ

ตัวเลือก:

จับคู่ป้ายกำกับ:

แอป: บริการเว็บ

แม่แบบ:

เมตาดาต้า:

ป้ายกำกับ:

แอป: บริการเว็บ

สเปค:

คอนเทนเนอร์:

-ชื่อ: เว็บ-คอนเทนเนอร์

# ระบุเส้นทางของอิมเมจที่คุณเพิ่งส่งไปยัง Artifact Registry อย่างแม่นยำ

ภาพ: asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

กีฬา:

-พอร์ตคอนเทนเนอร์: 8080

ทรัพยากร: # จำกัดข้อกำหนดด้านทรัพยากรอย่างเข้มงวดเพื่อป้องกันไม่ให้โค้ดที่เป็นอันตรายดึงทรัพยากรจนหมดจากคลัสเตอร์

ขีดจำกัด:

ซีพียู: "500m"

หน่วยความจำ: "512Mi"

คำขอ:

ซีพียู: "200m"

หน่วยความจำ: "256Mi"

---

apiVersion: v1

ชนิด: บริการ

เมตาดาต้า:

ชื่อ: บริการโหลดบาลานซ์แอปเว็บ

สเปค:

ประเภท: LoadBalancer # ให้ GKE ดำเนินการขอ IP ของตัวโหลดบาลานซ์สาธารณะทั่วโลกที่มีระบบป้องกัน DDoS ขั้นสูงจากโครงสร้างพื้นฐานเครือข่ายของ Google โดยอัตโนมัติ

ตัวเลือก:

แอป: บริการเว็บ

กีฬา:

-โปรโตคอล: TCP

พอร์ต: 80 # พอร์ตประตูสาธารณะของส่วนหน้า

targetPort: 8080 # หมายถึงพอร์ตจริงภายในคอนเทนเนอร์

ในเทอร์มินัลให้เรียกใช้คำสั่งปรับใช้แบบคลิกเดียวเพื่อส่งแบบจำลองการออกแบบนี้ไปยัง GKE:

แบช

kubectl apply -f deployment.yaml

ขั้นตอนที่ห้า: ช่วงเวลาแห่งการพิสูจน์ปาฏิหาริย์ – การทดสอบระบบหลังเปิดใช้งานและการจำลองสถานการณ์หยุดทำงานเพื่อความปลอดภัย

หลังจากทำการปรับใช้เสร็จสิ้นแล้วพวกเราใช้คำสั่ง “Tianyan” ของ K8s เพื่อติดตามการก่อเกิดของโครงสร้างพื้นฐาน:

แบช

kubectl get p

โอดีเอส

คุณจะเห็นบนหน้าจอมีไฟสีเขียวสว่างขึ้น3ดวง

การวิ่ง

พอดในสถานะนั้น

ประเด็นสำคัญอยู่ที่ว่า: ในกระบวนการนี้เราไม่ได้กำหนดรหัสผ่านสำหรับการดึงอิมเมจ (ImagePullSecret) เลยแต่ GKE กลับอาศัยสิทธิ์ IAM โดยธรรมชาติสามารถดึงอิมเมจส่วนตัวจาก Artifact Registry ได้อย่างปลอดภัย!

จากนั้นให้ตรวจสอบเกตเวย์อินเทอร์เน็ตภายนอกของระบบบาลานซ์โหลดแบบสาธารณะที่ Google ได้กำหนดให้กับเรา:

แบช

kubectl get service web-app-lb-service

คุณจะได้เห็น

ภายนอก-ไอพี

ในช่องดังกล่าวปรากฏ IP สาธารณะแบบคงที่สีทอง (เช่น

34.120.x.x

)。พิมพ์ IP นี้ลงในเบราว์เซอร์เพจจะเปิดขึ้นทันทีบริการเว็บแบบคลาวด์เนทีฟของคุณก็ได้ประกาศศักดาสู่อินเทอร์เน็ตอย่างเป็นทางการแล้ว!

การซ้อมรับมือเหตุการณ์ “เมลท์ดาวน์ของร่างกาย” จำลองสภาพแวดล้อมการผลิต

เพื่อทดสอบความสามารถในการฟื้นฟูตนเองของ GKE เราจึงตั้งใจเข้าไปก่อกวนในระบบเบื้องหลังลบคอนเทนเนอร์ (Pod) ที่กำลังทำงานอยู่ด้วยตนเอง:

แบช

kubectl delete pod web-app-deployment-xxxxxx-xxxxx

ในวินาทีที่ถูกลบคุณกลับไปรีเฟรชหน้าเว็บไซต์อีกครั้ง

ไม่มีอาการกระตุกหรือสะดุดเลยแม้แต่น้อย

(เนื่องจากอินสแตนซ์สำรองอีก2ตัวกำลังรับภาระการรับส่งข้อมูลอยู่) ที่น่าพิศวงยิ่งกว่านั้นคือเมื่อคุณดำเนินการอีกครั้ง

kubectl get pods

เมื่อถึงเวลานั้นคุณจะพบว่า Pod ใหม่ตัวหนึ่งได้ถูกเปิดใช้งานโดยอัตโนมัติภายในไม่กี่วินาทีและเข้าสู่สถานะพร้อมใช้งานอย่างสมบูรณ์แล้วนี่คือพลังอันเป็นจุดเด่นของ GKE ในการบำรุงรักษา ReplicaSet แบบประกาศลักษณะการทำงานโดยอัตโนมัติ

ขั้นตอนที่หก: ประวัติเลือดและน้ำตาของการหลีกเลี่ยง陷阱ในธุรกิจคลาวด์เนทีฟข้ามชาติ

เมื่อแนวทางนี้ผ่านการทดสอบจนใช้งานได้จริงคุณก็ได้ก้าวข้ามอุปสรรคที่ยากที่สุดของคลาวด์เนทีฟไปเรียบร้อยแล้วแต่เพื่อให้สามารถอยู่รอดได้ในสภาพแวดล้อมระดับองค์กรที่มีการเข้าใช้งานพร้อมกันสูงอย่างแท้จริงในฐานะสถาปนิกคุณจำเป็นต้องดำเนินการเสริมความแข็งแกร่งให้กับการกำหนดค่าในขั้นตอนที่สองทันทีเพื่อป้องกันหลุมพรางลึกที่มองไม่เห็นสองประการดังต่อไปนี้:

1. ห้ามใช้เด็ดขาด

ล่าสุด

ป้ายกำกับ (ต้นกำเนิดแห่งความเลวร้ายของการจัดการเวอร์ชัน)

หลายทีมเลือกทางสะดวกโดยทุกครั้งที่คอมไพล์อิมเมจในเครื่องก็จะติดป้ายกำกับไว้เลย

แอปเว็บของฉัน:ล่าสุด

ปักป้ายขึ้นไปใน YAML ก็เขียนไว้เช่นกัน

รูปภาพ:...:ล่าสุด

。

เมื่อเกิดเหตุการณ์วิกฤต: เมื่อโค้ดบนระบบจริงเกิดบั๊กและจำเป็นต้องย้อนกลับอย่างเร่งด่วนคุณจะพบว่ารุ่นเก่าทั้งหมดถูกทับด้วยแท็ก latest ไปจนหมดยิ่งไปกว่านั้นด้านใต้ของ K8s มีกลไกการแคชอิมเมจอยู่หากพบว่าในเครื่องมีอิมเมจ latest อยู่แล้วแม้ว่าคุณจะพัฒนาโค้ดใหม่ขึ้นมาก็อาจเกิดกรณีที่ระบบละเลยและนำอิมเมจเก่าในเครื่องมาใช้งานซ้ำส่งผลให้เวอร์ชันใหม่ของคุณไม่สามารถเผยแพร่ได้เลย

แนวทางมาตรฐานของบริษัทขนาดใหญ่: ตัดการใช้งานฟีเจอร์ latest ออกอย่างเด็ดขาดทุกครั้งที่ทำการเผยแพร่ข้อมูลต้องใช้หมายเลขเวอร์ชันที่มีความหมาย (เช่น v1.0, v1.1) หรือ

ใช้รหัส Commit ID ของ Git โดยตรงเมื่อเผยแพร่เวอร์ชันใหม่ให้แก้ไขหมายเลขเวอร์ชันในไฟล์ YAML เพื่อให้ GKE ดำเนินการอัปเดตแบบโรลลิ่งอัปเดต (Rolling Update) อย่างสมบูรณ์ทำให้การปล่อยเวอร์ชันไม่มีการหยุดชะงักของบริการ

2.หยุดการทำงานอัตโนมัติของ Artifact Registry (การจัดการวงจรชีวิต)

หากทีมพัฒนาได้กำหนดค่าสายการผลิตแบบอัตโนมัติของ CI/CD ไว้ (เช่น GitHub Actions หรือ GitLab CI) ทุกครั้งที่มีการรวมโค้ดจะมีการสร้างอิมเมจขนาดหลาย GB โดยอัตโนมัติและส่งไปเก็บไว้ใน Artifact Registry หากไม่สนใจดูแลไม่กี่เดือนต่อมาในคลังข้อมูลก็จะมีอิมเมจเก่าที่ไม่ได้ใช้งานสะสมอยู่นับหมื่นนับแสนภาพบิลค่าใช้จ่ายบริการเก็บข้อมูลบน Google Cloud ปลายเดือนอาจทำให้หัวหน้าปวดใจไปตามๆกัน

เทคนิคประหยัดเงินแบบเข้มข้น: ในการตั้งค่าของคลังเก็บ Artifact Registry ให้เปิดใช้งาน “นโยบายการลบขยะ (Cleanup Policies)”

กฎการลบข้อมูลสินทรัพย์ที่ไม่ได้ใช้งานโดยอัตโนมัติ: กำหนดกฎหนึ่งข้อดังนี้ “สำหรับอิมเมจชั่วคราวระดับกลางที่ไม่มีป้ายกำกับใดๆ (Untagged) หากเกิน7วันให้ทำลายทางกายภาพทันที” หรือ “สำหรับอิมเมจที่มีป้ายกำกับเวอร์ชันให้คงไว้เฉพาะ20เวอร์ชันล่าสุดส่วนเวอร์ชันเก่าให้ลบออกโดยอัตโนมัติ” ให้ระบบช่วยคุณจัดการลดทอนและกำจัดสิ่งไม่จำเป็นโดยอัตโนมัติซึ่งจะช่วยให้องค์กรประหยัดค่าใช้จ่ายด้านพื้นที่จัดเก็บข้อมูลบนคลาวด์ที่ไม่ได้ใช้งานซึ่งมีราคาสูงได้

สรุป

จาก GCP Artifact Registry และ GKE สร้างตัวอย่างการปรับใช้เนทีฟบนคลาวด์สาระสำคัญระดับอุตสาหกรรมหลักอยู่ใน16คำ:

ล็อกเวอร์ชันอิมเมจดึงสตรีมอย่างปลอดภัยแบบไม่ใช้รหัสประกาศข้อมูลสำเนาเพื่อรักษาเสถียรภาพและทำความสะอาดคลังโดยอัตโนมัติ

。

ด้วยการผสมผสานสีทองแบบวงปิดนี้คุณจะได้รับการปลดปล่อยอย่างสมบูรณ์จากการกำหนดค่าสภาพแวดล้อมเซิร์ฟเวอร์ที่ยุ่งยากการสร้างโหลดบาลานซ์เครือข่ายที่ซับซ้อนและการต่อสู้ทางกายภาพกับการหยุดทำงานมอบทุกความทุ่มเทให้กับโค้ดและธุรกิจโดยแท้จริงบนโครงสร้างพื้นฐานแบบคลาวด์เนทีฟระดับโลกชั้นนำของ Google แอปพลิเคชันของคุณจะได้รับความสามารถในการปรับขนาดอย่างไร้ขีดจำกัดและระบบสำรองข้อมูลเพื่อความต่อเนื่องทางธุรกิจแบบอัตโนมัติอันเป็นความมั่นใจในศักยภาพระดับบริษัทยักษ์ใหญ่ชั้นนำ

gcloud services enable container.googleapis.com artifactregistry.googleapis.com

2. สร้างคลังภาพลับ (Artifact Registry)

เราอยู่ในภูมิภาคไต้หวันของจีน(

เอเชีย-ตะวันออก1

โครงการ-จีเคอีของฉัน

แบช

gcloud artifacts repositories create gke-repo

--รูปแบบที่เก็บข้อมูล=docker

--ตำแหน่ง=เอเชียตะวันออก1

--คำอธิบาย

Ption = "GKE Production Images Repository"

3. สร้างคลัสเตอร์ GKE แบบโฮสต์ (โหมด Autopilot)

ขอแนะนำอย่างยิ่งให้เลือกใช้โหมด Autopilot (การขับขี่อัตโนมัติ)

แบช

gcloud container clusters create-auto โปรเจกต์-จีเคอี-คลัสเตอร์

--ตำแหน่ง=เอเชียตะวันออก1

(การสร้างคลัสเตอร์จะใช้เวลาประมาณ3~ 5นาทีดื่มกาแฟสักแก้วแล้วอดทนรอค่ะ)

เราขอสมมติว่าคุณมีแอปพลิเคชันเว็บที่เรียบง่ายมากอยู่ในเครื่อง (ไม่ว่าจะเป็น Node.js หรือ Python) ซึ่งกำลังฟังอยู่บนเครื่องของคุณ

8080

พอร์ต

1. สร้าง Dockerfile ระดับการผลิตที่มีความแข็งแกร่ง

ในไดเรกทอรีหลักของโครงการให้สร้างใหม่หนึ่งรายการ

ไฟล์ Dockerfile

# ใช้ภาพฐานแบบเบาอย่างเป็นทางการ

จากอัลไพน์:3.18

# ติดตั้งความขับเคลื่อนของรันไทม์ (ตัวอย่างด้วย Python)

เรียกใช้คำสั่ง apk add --no-cache python3 py3-pip

กำหนดไดเรกทอรีการทำงานเป็น /app

COPY. /แอป

# เปิดเผยพอร์ตของระบบธุรกิจ

เปิดเผย8080

# เริ่มต้นบริการเว็บ

CMD ["python3", "-m", "http.server", "8080"]

จีคลาวด์

นำใบรับรองความปลอดภัยไปฝังลงในไฟล์กำหนดค่าของ Docker บนเครื่องโดยตรง:

แบช

gcloud auth configure-docker asia-east1-docker.pkg.dev

3. คอมไพล์ติดป้ายกำกับและสตรีมอย่างเข้มข้น

แบช

# คอมไพล์และแพ็กเกจเป็นเวอร์ชัน v1.0

Docker build -t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:

V1.0.

# ผลักดันการสตรีมขึ้นสู่คลาวด์อย่างเต็มที่

docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

อิมเมจได้อัปโหลดขึ้นคลาวด์แล้วทำอย่างไรให้ GKE ดึงอิมเมจนั้นมาสร้างเป็นคอนเทนเนอร์ (Pod) ที่พร้อมให้บริการจริง? ในโลกของ K8s เราไม่ได้พิมพ์คำสั่งบนเทอร์มินัลแต่เราเขียน

ไฟล์กำหนดค่า YAML

。

แบช

gcloud container clusters get-credentials prod-gke-cluster --location=asia-east1

สร้างใหม่ในพื้นที่ที่เรียกว่า

เดปโลยเมนต์.ยูเอ็มแอล

ยามล

apiVersion: apps/v1

ชนิด: การปรับใช้

เมตาดาต้า:

ชื่อ: การปรับใช้แอปพลิเคชันเว็บ

ป้ายกำกับ:

แอป: บริการเว็บ

สเปค:

ตัวเลือก:

จับคู่ป้ายกำกับ:

แอป: บริการเว็บ

แม่แบบ:

เมตาดาต้า:

ป้ายกำกับ:

แอป: บริการเว็บ

สเปค:

คอนเทนเนอร์:

-ชื่อ: เว็บ-คอนเทนเนอร์

# ระบุเส้นทางของอิมเมจที่คุณเพิ่งส่งไปยัง Artifact Registry อย่างแม่นยำ

ภาพ: asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

กีฬา:

-พอร์ตคอนเทนเนอร์: 8080

Resources: # จำกัดข้อกำหนดทรัพยากรอย่างเคร่งครัดเพื่อป้องกันไม่ให้ถูกบีบโดยรหัสโกง

คลัสเตอร์แห้ง

ขีดจำกัด:

ซีพียู: "500m"

หน่วยความจำ: "512Mi"

คำขอ:

ซีพียู: "200m"

หน่วยความจำ: "256Mi"

---

apiVersion: v1

ชนิด: บริการ

เมตาดาต้า:

ชื่อ: บริการโหลดบาลานซ์แอปเว็บ

สเปค:

ตัวเลือก:

แอป: บริการเว็บ

กีฬา:

-โปรโตคอล: TCP

พอร์ต: 80 # พอร์ตประตูสาธารณะของส่วนหน้า

targetPort: 8080 # หมายถึงพอร์ตจริงภายในคอนเทนเนอร์

แบช

kubectl apply -f deployment.yaml

แบช

kubectl get pods

คุณจะเห็นบนหน้าจอมีไฟสีเขียวสว่างขึ้น3ดวง

การวิ่ง

พอดในสถานะนั้น

แบช

kubectl get service web-app-lb-service

คุณจะได้เห็น

ภายนอก-ไอพี

ในช่องดังกล่าวปรากฏ IP สาธารณะแบบคงที่สีทอง (เช่น

34.120.x.x

แบช

kubectl delete pod web-app-deployment-xxxxxx-xxxxx

ในขณะที่คุณลบคุณไปอีกครั้ง

หน้าเว็บใหม่เว็บไซต์

ไม่มีอาการกระตุกหรือสะดุดเลยแม้แต่น้อย

kubectl get pods

1. ห้ามใช้เด็ดขาด

ล่าสุด

ป้ายกำกับ (ต้นกำเนิดแห่งความเลวร้ายของการจัดการเวอร์ชัน)

แอปเว็บของฉัน:ล่าสุด

ปักป้ายขึ้นไปใน YAML ก็เขียนไว้เช่นกัน

รูปภาพ:...:ล่าสุด

。

แนวทางมาตรฐานของบริษัทขนาดใหญ่: ตัดการใช้งานฟีเจอร์ latest ออกอย่างเด็ดขาดทุกครั้งที่คุณผลักดันสตรีมคุณต้องใช้หมายเลขเวอร์ชันที่มีความหมาย (เช่น v1.0, v1.1) หรือใช้รหัสคำสั่ง Git โดยตรงเมื่อเผยแพร่เวอร์ชันใหม่ให้แก้ไขหมายเลขเวอร์ชันในไฟล์ YAML เพื่อให้ GKE ดำเนินการอัปเดตแบบโรลลิ่งอัปเดต (Rolling Update) อย่างสมบูรณ์ทำให้การปล่อยเวอร์ชันไม่มีการหยุดชะงักของบริการ

2. ข้อผิดพลาดทำให้ระบบกำจัดขยะอัตโนมัติ (การจัดการวงจรชีวิต) ของ Artifact Registry หยุดทำงาน

กฎการลบข้อมูลสินทรัพย์ที่ไม่ได้ใช้งานโดยอัตโนมัติ: กำหนดกฎหนึ่งข้อดังนี้ “สำหรับอิมเมจชั่วคราวระดับกลางที่ไม่มีป้ายกำกับใดๆ (Untagged) หากเกิน7วันให้ทำลายทางกายภาพทันที” หรือ “สำหรับอิมเมจที่มีป้ายกำกับเวอร์ชันให้คงไว้เฉพาะ20เวอร์ชันล่าสุดส่วนเวอร์ชันเก่าให้ลบออกโดยอัตโนมัติ” ให้ระบบช่วยคุณออกจากระบบโดยอัตโนมัติซึ่งสามารถช่วยประหยัดทรัพย์สินบนคลาวด์ของบริษัทได้

ค่าธรรมเนียมการจัดเก็บที่ไม่ได้ใช้งานสูง

สรุป

การสร้างอินสแตนซ์การปรับใช้แบบคลาวด์เนทีฟโดยอาศัย GCP Artifact Registry และ GKE หัวใจสำคัญในระดับอุตสาหกรรมแท้จริงแล้วก็อยู่ที่คำสิบหกคำว่า:

。

ด้วยชุดคู่หูทองคำแบบปิดลูปนี้คุณจะหลุดพ้นจากความยุ่งยากในการกำหนดค่าสภาพแวดล้อมเซิร์ฟเวอร์การสร้างระบบกระจายภาระเครือข่ายที่ซับซ้อนรวมถึงการเฝ้าระวังและแก้ไขปัญหาเซิร์ฟเวอร์ล่มด้วยตนเองอย่างสิ้นเชิงมอบทุกความทุ่มเทให้กับโค้ดและธุรกิจโดยแท้จริงบนโครงสร้างพื้นฐานแบบคลาวด์เนทีฟระดับโลกชั้นนำของ Google แอปพลิเคชันของคุณจะได้รับความสามารถในการปรับขนาดอย่างไร้ขีดจำกัดและระบบสำรองข้อมูลเพื่อความต่อเนื่องทางธุรกิจแบบอัตโนมัติอันเป็นความมั่นใจในศักยภาพระดับบริษัทยักษ์ใหญ่ชั้นนำ