TH
RAILSHOT.
กลับไปที่ห้องจัดแสดง

Railshot

AI deployment & operations platform

ดีพลอยเว็บแอปที่สร้างบนเครื่องไปยังสภาพแวดล้อมคลาวด์และออนพรีมิสที่เตรียมไว้ แล้วดูแลการทำงาน

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

2026.09.28 — 2026.10.04 · เสร็จสิ้น

โปรเจกต์ทีม · ส่วนที่รับผิดชอบ: การวางแผนและพัฒนา CI คลัสเตอร์ CSP และอินเทอร์เฟซ Ansible การดูแลระบบ การรีวิวโค้ดและการผสานของทีม

SoftBank Hackathon 2026 powered by KOREC & Progateผู้เข้าร่วมรอบคัดเลือก · ประกาศผลคัดเลือกเข้ารอบชิงชนะเลิศ 2026.10.26 (ณ 2026.10.07)

  • เว็บพัฒนาแล้ว · แฮกกาธอน
  • เซิร์ฟเวอร์ MCPพัฒนาแล้ว · รีโมต · ในเครื่อง

คลัสเตอร์ดูแลระบบและคลัสเตอร์แอปของลูกค้าแยกกัน และเส้นทางสาธารณะแยกจากการควบคุมการดีพลอย

ใน K3s ของการดูแลระบบ แดชบอร์ด API ผลิตภัณฑ์ และ build controller อยู่บนโหนดบทบาท platform และ runner Job อยู่บนโหนดบทบาท build โดย Argo CD จัดการการดีพลอย แอปของลูกค้ารันใน namespace ที่กำหนดของคลัสเตอร์ K3s + Cilium โหนดเดียวที่แยกต่างหากสำหรับแต่ละเป้าหมายที่ลงทะเบียน

แผนที่คลัสเตอร์ · วาดจากการประกาศและโค้ดที่คอมมิตสาธารณะ 645e28a
แผนที่คลัสเตอร์ดูแลระบบและคลัสเตอร์ลูกค้าของ Railshotคลัสเตอร์ K3s ของการดูแลระบบและคลัสเตอร์แอปของลูกค้าที่ลงทะเบียน ในคลัสเตอร์ดูแลระบบ namespace railshot-system วางแดชบอร์ด API ผลิตภัณฑ์ MCP แบบรีโมต (เฉพาะเมื่อมีอิมเมจ) และ build controller บนโหนดบทบาท platform ส่วน runner Job ใน namespace railshot-build รับงาน GitHub Actions บนโหนดบทบาท build ที่ติด taint งาน release ที่โฮสต์บน GitHub เผยแพร่ bundle ที่ทดสอบแล้วไปยัง GHCR API ผลิตภัณฑ์คอมมิต workload ไปยัง config Git และ sync Application ใน namespace argocd แล้ว Argo CD นำ Deployment, NodePort Service และ NetworkPolicy ไปใช้กับ namespace ที่ลงทะเบียนในคลัสเตอร์ลูกค้า คำขอของแอปเข้ามาทางทางเข้า L7 ของผู้ให้บริการไปยัง NodePort และ Service ของโหนด แล้วไปยัง Pod ของแอป คำตัดสินการดีพลอยอิงเพียงสถานะของ Argo และการตรวจ URL สาธารณะ ส่วนการวินิจฉัย Pod ล็อก และเมตริกถูกอ่านเป็นสัญญาณแยกกัน อินพุตการติดตั้งและการลงทะเบียนของผู้ดูแลระบบแยกจาก payload ของแอปของ tenantผู้ใช้ Railshotแดชบอร์ด · MCPbootstrap ของผู้ดูแลระบบติดตั้ง · ลงทะเบียน · SecretGHCRอิมเมจตาม digestรีโพซิทอรี config Gitworkload.json · revisionทางเข้า L7 ของผู้ให้บริการALB · GCP LB · Amphoraผู้ใช้แอปHTTPS สาธารณะVM ผู้สังเกตการณ์นอก K3s ของลูกค้า · Composerailshot-systemdashboard · nginxMCP แบบรีโมต · เฉพาะเมื่อมีอิมเมจbuild controller · CronJobAPI ผลิตภัณฑ์ · cd.js → bridge.pyargocdArgo CD · ApplicationAppProject · cluster SecretCronJob ต่ออายุ · ทุก 2 ชม.railshot-buildrunner Job · hostNetwork · Docker socketrailshot-deploy.ymlloop job · self-hosted runnerrelease job · GitHub-hosted<app namespace>Deployment · Pod · อิมเมจตาม digestNodePort Service · LocalNetworkPolicy · CIDR ที่ระบุrailshot-argocd SA · โทเค็นkube-systemCilium · Helm · VXLANrailshot-observabilitynode-exporterkube-state-metricsคลัสเตอร์ดูแลระบบ · K3sAWS · โหนดตามบทบาทโหนดบทบาท platformnodeSelectorโหนดบทบาท buildNoSchedule taintGitHubActions · GHCRคลัสเตอร์แอปของลูกค้า · ตัวอย่างหนึ่งคลัสเตอร์ต่อเป้าหมายที่ลงทะเบียนK3s หนึ่งโหนด · serverCilium · คง kube-proxy ไว้1workflow_dispatch2เติม runner Job3รับงาน4bundle ที่ทดสอบแล้ว5 เผยแพร่ตาม digest · release job · GitHub-hosted → GHCR51workload commit · push2revision3 Application sync · API ผลิตภัณฑ์ · cd.js → bridge.py → Argo CD · Application34นำไปใช้กับ namespace5ดึงตาม digest1HTTPS 4432NodePort3 ไปยัง Pod · NodePort Service · Local → Deployment · Pod · อิมเมจตาม digest34 บังคับใช้นโยบาย · Cilium · Helm · VXLAN → NetworkPolicy · CIDR ที่ระบุ45 แดชบอร์ด · API · ผู้ใช้ Railshot → dashboard · nginx51 revision · health · อิมเมจ · API ผลิตภัณฑ์ · cd.js → bridge.py → Argo CD · Application12การตรวจ HTTPS สาธารณะ3การวินิจฉัย Pod · ไม่ใช่คำตัดสิน4tail ล็อก · 100 บรรทัดต่อ Pod5scrape · NodePort6Blackbox probe1เรนเดอร์ platform · Secret2bootstrap การลงทะเบียน3ติดตั้ง K3s · Cilium4TokenRequest · 6 ชม.

บิลด์ → เผยแพร่อิมเมจ

API ผลิตภัณฑ์ขอการรัน GitHub Actions และ runner บนโหนด build รับงานไปตรวจ เฉพาะ bundle ที่ผ่านการตรวจชุดเดิมเท่านั้นที่ถูกเผยแพร่ไปยัง GHCR โดยงาน release ที่โฮสต์บน GitHub

  1. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemworkflow_dispatchloop job · self-hosted runnerrailshot-deploy.yml

    API ผลิตภัณฑ์ขอการรัน GitHub Actions ด้วย tenant, app, source commit และ target โดย API ไม่เคยเรียก runner Job โดยตรง

  2. build controller · CronJobrailshot-systemเติม runner Jobrunner Job · hostNetwork · Docker socketrailshot-build

    CronJob ของ build controller (ทุกนาที บนโหนด platform) สร้าง runner Job ใน namespace railshot-build Role ของมันอนุญาตเพียง get, list และ create Job รวมถึง get, update และ patch บน Secret การลงทะเบียน runner เพียงตัวเดียว ไม่สามารถสร้าง namespace หรือ Secret อื่นได้

  3. runner Job · hostNetwork · Docker socketrailshot-buildรับงานloop job · self-hosted runnerrailshot-deploy.yml

    runner บนโหนดบทบาท build (hostname ที่ระบุแน่นอน, NoSchedule toleration) รับงาน loop ตามป้าย self-hosted แล้วรัน ซอร์สของลูกค้ารันในคอนเทนเนอร์บิลด์และตรวจ Docker แบบจำกัดสิทธิ์ที่มีอยู่

  4. runner Job · hostNetwork · Docker socketrailshot-buildbundle ที่ทดสอบแล้วrelease job · GitHub-hostedrailshot-deploy.yml

    งาน loop ทิ้ง bundle ที่ผ่านการตรวจชุดเดิมไว้ และงาน release รับเฉพาะ bundle นั้น

  5. release job · GitHub-hostedrailshot-deploy.ymlเผยแพร่ตาม digestGHCR

    งาน release ที่โฮสต์บน GitHub (ubuntu-24.04) เผยแพร่อิมเมจของ bundle ที่ทดสอบแล้วไปยัง GHCR โดยไม่บิลด์ใหม่ การเผยแพร่อิมเมจไม่เคยเกิดขึ้นภายในคลัสเตอร์แอปของลูกค้า

Config Git → Argo → namespace ของลูกค้า

config Git นำทรัพยากรที่ต้องการ ส่วน GHCR นำไบต์ของอิมเมจ Argo CD นำไปใช้กับ namespace ของลูกค้าที่ลงทะเบียนเท่านั้น

  1. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemworkload commit · pushรีโพซิทอรี config Git

    cd.js รัน bridge.py ซึ่งคอมมิตและ push workload.json เฉพาะเมื่อบันทึกการเผยแพร่และเป้าหมายที่ลงทะเบียนตรงกัน แล้วอ่าน revision ฝั่งรีโมตกลับมา Git นำทรัพยากรที่ต้องการ ส่วน GHCR นำไบต์ของอิมเมจ

  2. รีโพซิทอรี config GitrevisionArgo CD · Applicationargocd

    Application อ่านเฉพาะรีโพซิทอรี config พาธ และ revision ที่จำกัดไว้ของตน

  3. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemApplication syncArgo CD · Applicationargocd

    Application ที่ระบุชื่อถูกตั้งด้วย server-side apply และขอ sync ของ revision ที่ระบุแน่นอนหนึ่งรายการโดยไม่ prune ServiceAccount railshot-product ของ API ผลิตภัณฑ์ถือทั้งสิทธิ์ bootstrap การลงทะเบียนที่ผู้ดูแลระบบติดตั้งไว้ (create สำหรับ Secret, AppProject และ Application ใน argocd; get, update และ escalate บน Role ที่ระบุชื่อ) และสิทธิ์ get กับ patch ที่ต่อท้ายตามชื่อที่ระบุแน่นอนสำหรับแต่ละเป้าหมายที่ตรวจแล้ว create ของ Kubernetes จำกัดตามชื่อไม่ได้ การตรวจอินพุตของผลิตภัณฑ์จึงช่วยรักษาชื่อให้อยู่ในขอบเขตด้วย

  4. Argo CD · Applicationargocdนำไปใช้กับ namespace<app namespace>

    Argo CD นำไปใช้กับ namespace ที่กำหนดในคลัสเตอร์ลูกค้าด้วยข้อมูลรับรองของ cluster Secret ที่ลงทะเบียน AppProject อนุญาตเฉพาะ kind ระดับ namespace และไม่อนุญาตทรัพยากรระดับคลัสเตอร์

  5. Deployment · Pod · อิมเมจตาม digest<app namespace>ดึงตาม digestGHCR

    อิมเมจตาม digest ที่เผยแพร่ถูกดึงด้วย pull Secret ที่อ้างอิงตามชื่อใน namespace เดียวกัน ค่าของ Secret ไม่เคยเข้าไปในอาร์ติแฟกต์หรือ config Git

เส้นทางคำขอสาธารณะ

คำขอของแอปไปตามเส้นทาง ทางเข้า L7 ของผู้ให้บริการ → NodePort ของโหนด → Service → Pod ของแอป การบังคับใช้นโยบายของ Cilium เป็นการควบคุมแยกต่างหาก ไม่ใช่จุดที่นำคำขอผ่าน ทางเข้าสู่แดชบอร์ดการดูแลระบบเป็นเส้นทางแยก

  1. ผู้ใช้แอปHTTPS 443ทางเข้า L7 ของผู้ให้บริการ

    ผู้ใช้แอปเข้าถึงทางเข้า L7 ของผู้ให้บริการผ่าน hostname ที่ลงทะเบียน ผู้ให้บริการแต่ละรายพัฒนาทางเข้าของตนเอง

  2. ทางเข้า L7 ของผู้ให้บริการNodePortNodePort Service · Local<app namespace>

    ทางเข้าส่งต่อไปยังที่อยู่ส่วนตัวและ NodePort ของโหนด NodePort คือค่าที่จัดสรรตอนลงทะเบียนเป้าหมาย

  3. NodePort Service · Local<app namespace>ไปยัง PodDeployment · Pod · อิมเมจตาม digest<app namespace>

    Service ส่งคำขอไปยัง Pod ของแอป (Deployment) บนโหนดเดียวกัน ด้วย externalTrafficPolicy Local ที่อยู่ต้นทางจึงไปถึงการตรวจ CIDR ที่ลงทะเบียนของ NetworkPolicy โดยไม่เปลี่ยน

  4. Cilium · Helm · VXLANkube-systemบังคับใช้นโยบายNetworkPolicy · CIDR ที่ระบุ<app namespace>

    Cilium บังคับใช้ NetworkPolicy: ขาเข้าเฉพาะจาก CIDR ที่ลงทะเบียนไปยังพอร์ตของแอป ไม่มีขาออกเป็นค่าเริ่มต้น ยกเว้นที่อยู่ฐานข้อมูลที่อนุมัติ ไฟร์วอลล์ของคลาวด์และกฎของโฮสต์ยังคงสำคัญ

  5. ผู้ใช้ Railshotแดชบอร์ด · APIdashboard · nginxrailshot-system

    ผู้ใช้เข้ามาทางทางเข้าของการดูแลระบบสู่แดชบอร์ด nginx และ nginx อยู่ด้านหน้า API ผลิตภัณฑ์ Service ของแดชบอร์ดเป็น NodePort เฉพาะเมื่อมี node port ที่อนุมัติ ส่วน API ยังคงเป็น ClusterIP

ตรวจยืนยัน · สังเกต

คำตัดสินการดีพลอยอิงเพียงสถานะของ Argo และการตรวจ URL สาธารณะ การวินิจฉัย Pod ล็อกปัจจุบัน และเมตริกการดูแลระบบเป็นสัญญาณแยกที่ไม่เคยเปลี่ยนคำตัดสินนั้น

  1. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemrevision · health · อิมเมจArgo CD · Applicationargocd

    deployed ต้องมี sync revision ของ Application, Synced และ Healthy, operation Succeeded และการอ้างอิงอิมเมจที่บันทึกในสถานะ Argo Application ต้องเท่ากับอิมเมจตาม digest ของ Deployment ที่รีวิวแล้ว นี่ไม่ใช่เกตที่ตรวจ imageID ของ Pod โดยตรง และสถานะสีเขียวของ Argo เพียงอย่างเดียวไม่ได้ยืนยันความตรงกันนี้

  2. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemการตรวจ HTTPS สาธารณะทางเข้า L7 ของผู้ให้บริการ

    URL สาธารณะที่ลงทะเบียนถูกตรวจโดยไม่ตาม redirect บันทึกเป็น Succeeded เมื่อมีทั้งคำตัดสินของ Argo และการตรวจนี้เท่านั้น

  3. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemการวินิจฉัย Pod · ไม่ใช่คำตัดสินDeployment · Pod · อิมเมจตาม digest<app namespace>

    หลังคำตัดสินของ Argo และการตรวจสาธารณะ Deployment, ReplicaSet และ Pod ถูกอ่านแยกด้วยข้อมูลรับรองที่ลงทะเบียน และ imageID กับความพร้อมถูกต่อท้ายเป็นการวินิจฉัย ready, progressing หรือ unavailable การวินิจฉัยที่ล้มเหลวหรือต่างออกไปไม่เคยเปลี่ยนคำตัดสิน deployed หรือ succeeded

  4. API ผลิตภัณฑ์ · cd.js → bridge.pyrailshot-systemtail ล็อก · 100 บรรทัดต่อ PodDeployment · Pod · อิมเมจตาม digest<app namespace>

    เฉพาะ operation ที่ดีพลอยอยู่ในปัจจุบัน ด้วย config ที่เชื่อถือได้และข้อมูลรับรองที่ลงทะเบียน สำหรับแต่ละ Pod ปัจจุบัน (สูงสุดสาม) digest ของอิมเมจที่รันอยู่ต้องเท่ากับ digest ที่คาดไว้ จากนั้นจึงอ่านได้สูงสุด 100 บรรทัดที่ปิดบังข้อมูลแล้วต่อ Pod ภายในขีดจำกัดไบต์ ความพยายามที่เก่ากว่าจะตอบ superseded หากไม่มีการตั้งค่าจะตอบ not_configured นี่ไม่ใช่การรวมล็อก

  5. VM ผู้สังเกตการณ์scrape · NodePortrailshot-observability

    Prometheus บน VM ผู้สังเกตการณ์ scrape node-exporter และ kube-state-metrics ผ่าน NodePort สองพอร์ตที่จำกัดด้วยไฟร์วอลล์ ค่าที่หายไปหรือเก่าคือไม่ทราบ ไม่ใช่ศูนย์

  6. VM ผู้สังเกตการณ์Blackbox probeทางเข้า L7 ของผู้ให้บริการ

    probe_success=1 หมายถึงได้ 2xx ณ ตำแหน่ง probe นั้น ไม่ได้พิสูจน์ทั้งการเข้าถึงของผู้ใช้ทุกคนและเวอร์ชันที่ดีพลอย และไม่เคยเลื่อนสถานะ published เป็น deployed

การติดตั้ง · การลงทะเบียนของผู้ดูแลระบบ

การติดตั้งคลัสเตอร์ bootstrap การลงทะเบียนและอินพุตของเป้าหมาย Secret และการตั้งค่าการต่ออายุข้อมูลรับรอง เป็นอินพุตของผู้ดูแลระบบ ไม่เคยเป็นส่วนหนึ่งของ payload ของแอปของ tenant

  1. bootstrap ของผู้ดูแลระบบเรนเดอร์ platform · Secretrailshot-system

    ผู้ดูแลระบบสร้างการประกาศ platform ด้วย render-platform.py และใส่ config การดูแลระบบและ Secret ที่เป็นส่วนตัว MCP แบบรีโมตรวมอยู่เฉพาะเมื่อมีอิมเมจ และเกตเวย์ส่วนตัว (WireGuard) รวมอยู่เฉพาะเมื่อใช้ --personal

  2. bootstrap ของผู้ดูแลระบบbootstrap การลงทะเบียนAppProject · cluster Secretargocd

    ผู้ดูแลระบบติดตั้ง Role bootstrap การลงทะเบียนและ Role registrations ที่ว่างเปล่าใน argocd และเตรียมอินพุตของเป้าหมาย จากนั้น helper การลงทะเบียนที่ API ผลิตภัณฑ์รัน (environment.py, applications.py) จะเขียน Secret railshot-<target> ด้วยข้อมูลรับรองที่จำกัดขอบเขต (clusterResources false, ระบุ namespace ที่อนุญาต) และต่อท้ายชื่อที่ตรวจแล้วแบบระบุแน่นอนลงใน Role registrations การลงทะเบียนรายแอปผูก namespace app-<id> เข้ากับ AppProject ชื่อเดียวกัน

  3. bootstrap ของผู้ดูแลระบบติดตั้ง K3s · CiliumCilium · Helm · VXLANkube-system

    install-k3s.sh ติดตั้ง K3s server แบบโหนดเดียว (ปิด flannel, network policy, traefik และ servicelb คง kube-proxy ไว้) และติดตั้ง Cilium เป็น Helm release (kubeProxyReplacement false, VXLAN, ปิด Hubble)

  4. CronJob ต่ออายุ · ทุก 2 ชม.argocdTokenRequest · 6 ชม.railshot-argocd SA · โทเค็น<app namespace>

    CronJob railshot-credentials ขอโทเค็นใหม่อายุหกชั่วโมงสำหรับ SA ของลูกค้าทุกสองชั่วโมง Role ฝั่งลูกค้าอนุญาตเพียง create token สำหรับ SA ของตนเอง หกชั่วโมงคือ TTL ของโทเค็นหนึ่งตัว ไม่ใช่เวลาที่สิทธิ์เข้าถึงของผู้ดูแลระบบสิ้นสุด

ทุกการเชื่อมต่อมีน้ำหนักเท่ากัน เลือกโฟลว์เพื่อไฮไลต์เฉพาะเส้นทางของโฟลว์นั้นพร้อมขั้นตอนที่มีหมายเลข

  • เส้นทึบ · ทิศทางที่คำขอ bundle อิมเมจ และการประกาศไหลไป
  • เส้นประ · คำขอให้รัน การนำไปใช้ การติดตั้ง ข้อมูลรับรอง
  • เส้นยาวสลับจุด · การอ่านสถานะ ล็อก probe เมตริก แยกจากคำตัดสิน
  • เส้นดำหนา · โฟลว์ที่เลือก ตัวเลขบอกลำดับ
  • กล่อง · namespace พร้อมชื่อในส่วนหัว (ไม่ใช่โหนด)
  • ชิปด้านใน · องค์ประกอบใน namespace นั้น
  • กล่องเส้นประ · อยู่นอกคลัสเตอร์
  • railshot-system · ผลิตภัณฑ์
  • argocd · อำนาจการดีพลอย
  • railshot-build · อำนาจ Docker ของโฮสต์
  • GitHub · คลัสเตอร์ลูกค้า

การตัดสินใจเรื่องการวางเมื่อ October 2 ใน docs/architecture (โหนดสองบทบาท) และแผนภาพใน README สาธารณะเป็นประวัติ แผนที่นี้เป็นไปตามการประกาศและโค้ดที่ 645e28a ลูกศรแสดงเหตุและทิศทาง ไม่ใช่หลักฐานว่าเส้นทางของผู้ให้บริการทุกรายใช้งานอยู่ในขณะนี้

namespace และโหนด
namespace คือขอบเขตการตั้งชื่อ ไม่ใช่ฮาร์ดแวร์และไม่ใช่ขอบเขตความปลอดภัยในตัวเอง บทบาท platform และ build คือการวางตำแหน่งการจัดตารางด้วย nodeSelector และ taint แผนที่นี้ไม่ได้กำหนดจำนวนโหนดของคลัสเตอร์ดูแลระบบ การวางโหนดของ Argo CD ก็เป็นการตรวจแยกต่างหากเช่นกัน
อำนาจของโหนด build
runner Job รันด้วย hostNetwork, Docker socket ของโฮสต์, NET_ADMIN และ root namespace, taint หรือ RBAC ไม่ได้ลบอำนาจ Docker ของโฮสต์ นี่จึงไม่ใช่ทั้งการแยกผู้ดูแล VM และแซนด์บ็อกซ์สำหรับโค้ดใดก็ได้
namespace ของลูกค้า
เป้าหมายที่ลงทะเบียนแต่ละรายการใช้ namespace และ AppProject ที่ไม่ใช่ค่าเริ่มต้น (เช่น tenant-demo หรือ app-<id> ต่อแอป) สร้างเฉพาะ Deployment ของบริการเดียว (ปิด automount โทเค็น ServiceAccount), NodePort Service และ NetworkPolicy รวมถึง PVC หรือ migration Job ที่ไม่บังคับ ส่วน Secret ถูกอ้างอิงตามชื่อเท่านั้น (pull Secret และ DATABASE_URL ที่อนุมัติ) ไม่เคยถูกสร้าง
ทางเข้า AWS
Route 53 Alias → ALB ร่วม HTTPS 443 → ที่อยู่ส่วนตัวและ NodePort ของโหนดลูกค้า หลายแอปใช้โหนดเดียวร่วมกัน โดยแต่ละแอปมี namespace, Application และ NodePort ของตัวเอง
ทางเข้า GCP
Global EXTERNAL_MANAGED HTTPS LB → zonal GCE_VM_IP_PORT NEG → NodePort ส่วนตัวของ VM ที่มีอยู่ ใบรับรองมาจาก Certificate Manager ด้วย DNS authorization โมดูลไม่ได้เป็นเจ้าของทั้ง VM และ VPC และ VM หนึ่งเครื่องยังคงเป็นจุดล้มเหลวจุดเดียว
ทางเข้า OpenStack
Amphora TLS listener 443 พร้อมนโยบาย L7 ตาม Host และ path → HTTP NodePort ที่อยู่เริ่มต้นเป็น VIP ส่วนตัว Octavia, K3s, ฐานข้อมูล และ DNS อยู่นอกโมดูล การเข้าถึงสาธารณะและความพร้อมของ Amphora ในสถานที่จริงต้องมีการรับมอบแยกต่างหาก และยังไม่มีการตรวจยืนยันการนำไปใช้ในสถานที่จริงด้วยโมดูลนี้
ข้ามผู้ให้บริการ
ทางเข้าทั้งสามเป็นการพัฒนาที่แยกกัน ไม่มี failover หรือการทำสำเนาอัตโนมัติระหว่างผู้ให้บริการ คลัสเตอร์แอปของลูกค้าเป็นตัวอย่างของเป้าหมายที่ลงทะเบียน ไม่ใช่การอ้างว่าการดีพลอยเดียวกันรันบนทุกคลาวด์พร้อมกัน
ตัวเลือกของผู้ดูแลระบบ
เกตเวย์ส่วนตัว (WireGuard) เข้าร่วม platform เฉพาะเมื่อผู้ดูแลระบบเปิด --personal และไม่ใช่เส้นทางบังคับสำหรับคลาวด์ของลูกค้า ในโหมด direct ที่รองรับ VM ผู้สังเกตการณ์อาจใช้ร่วมกับ VM ควบคุมการดูแลระบบได้