Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Panduan pemecahan masalah Inference Gateway

Ikhtisar: HyperPod Inference Gateway merutekan lalu lintas melalui tiga lapisan: Body-Based Router (BBR), gateway denganHTTPRoute, dan Endpoint Picker (EPP). Kesalahan konfigurasi pada setiap lapisan dapat mengakibatkan permintaan gagal, lalu lintas mencapai model yang salah, atau beban yang tidak merata di seluruh pod yang melayani model. Bagian ini mencakup masalah dengan gateway, BBR, gateway danHTTPRoute,, dan EPPInferencePool, dan masalah apa pun yang muncul darinya.

Mendiagnosis status gateway

Gunakan perintah berikut untuk memeriksa gateway dan sumber daya yang dikelolanya.

Daftar setiap InferenceGatewayConfig sumber daya di seluruh ruang nama:

kubectl get inferencegatewayconfig -A

Tampilkan status terperinci, status peluncuran per penjadwal, dan pesan kondisi untuk gateway tertentu:

kubectl describe inferencegatewayconfig <name> -n <namespace>

Periksa pengontrol gateway dan pod Body-Based Router:

kubectl get pods -n hyperpod-inference-system

Periksa sumber daya perutean hilir yang dihasilkan oleh pengontrol:

kubectl get httproute,inferencepool,securitypolicy -A

Periksa status.conditions dan masing-masing penjadwal rolloutState (Pending,, ProgressingAvailable, atauDegraded). Alasan kegagalan yang dapat ditindaklanjuti ada pada pesan kondisi yang sesuai.

Add-on masalah instal

Masalah: Sumber daya gateway hilang, atau tidak GatewayClass diterima setelah menginstal add-on HyperPod Inference Amazon EKS.

Gejala dan resolusi: kubectl get gatewayclass inference-gateway pengembalianNotFound, atau sumber daya menunjukkanACCEPTED=False. Ini menunjukkan bahwa add-on tidak diinstal atau instalasi tidak selesai. Instal ulang atau perbarui add-on:

aws eks update-addon --cluster-name $CLUSTER --region $REGION \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --resolve-conflicts OVERWRITE

Kemudian konfirmasikan pengontrol gateway sedang berjalan:

kubectl rollout status deploy/inference-gateway-controller \
  -n hyperpod-inference-system --timeout=150s

InferenceGatewayConfig Tidak Menjadi Siap

Masalah: An InferenceGatewayConfig dibuat, tetapi status.conditions acaranya Accepted=False atauReady=False, atau kubectl apply ditolak langsung oleh validasi.

Gejala dan resolusi:

Per-scheduler kegagalan

Masalah: Kondisi penjadwal tertentu (BackendsReady,LoraSupported, atauPoolReady) menunjukkan bahwa penjadwal belum sepenuhnya siap.

Gejala dan resolusi:

Scheduler RolloutState Terdegradasi

Masalah: Penerapan Endpoint Picker untuk penjadwal macet dan tidak menjadi Tersedia.

Gejala dan resolusi: EPPReady Kondisi pada penjadwal membawa alasan yang dapat ditindaklanjuti. Penyebab umum meliputi:

Gunakan perintah berikut untuk mengidentifikasi penjadwal yang gagal dan memeriksa Deployment:

# List the schedulers reporting Degraded
kubectl get inferencegatewayconfig <name> -n <namespace> \
  -o jsonpath='{range .status.schedulers[?(@.rolloutState=="Degraded")]}{.name}{"\n"}{end}'

# Describe the scheduler's Endpoint Picker Deployment for pod events and container errors
kubectl describe deploy -n <namespace> \
  -l inference.sagemaker.aws.amazon.com/scheduler=<scheduler-name>

Titik akhir basi setelah pod model restart

Masalah: Setelah pod model dihapus dan pod pengganti menjadi Ready, Endpoint Picker terus merutekan ke alamat IP pod yang dihapus. Permintaan mengembalikan HTTP 503 atau koneksi ditolak, dan kondisinya tidak pulih dengan sendirinya.

Resolusi: Tambahkan probe kesiapan ke pod model sehingga Kubernetes menandai pod NotReady sebelum IP-nya dihapus dari pool, dan hanya mengiklankan pod pengganti setelah sepenuhnya melayani lalu lintas. Setel port ke penjadwal targetPort dan path ke titik akhir kesehatan server model Anda:

readinessProbe:
  httpGet:
    path: /health
    port: 8000

Solusi: Jika Anda tidak dapat segera menerapkan ulang pod model, restart Endpoint Picker penjadwal untuk memaksanya membangun kembali daftar titik akhir dari kumpulan pod saat ini:

kubectl rollout restart deploy -n <namespace> \
  -l inference.sagemaker.aws.amazon.com/scheduler=<scheduler-name>

Otentikasi JWT mengembalikan 401 atau 403

Masalah: spec.auth.jwt dikonfigurasi dan permintaan ditolak sebelum mencapai model, atau gateway tidak pernah menjadi Siap setelah otentikasi JWT diaktifkan.

Gejala dan resolusi:

Metrik hilang dari dasbor

Masalah: Metrik Endpoint Picker atau Body-Based Router tidak muncul di dasbor pemantauan Anda.

Gejala dan resolusi: Pengumpulan metrik diaktifkan secara default, sehingga sespan OpenTelemetry Kolektor biasanya ada. Konfirmasikan apakah sespan berjalan pada kedua jenis pod, dan apakah metrik dinonaktifkan secara eksplisit.

Periksa sespan pada pod Body-Based Router:

kubectl -n hyperpod-inference-system get pods \
  -o jsonpath='{.items[*].spec.containers[*].name}' | tr ' ' '\n' | grep otel

Periksa sespan pada pod Endpoint Picker:

kubectl -n <namespace> get pods \
  -o jsonpath='{.items[*].spec.containers[*].name}' | tr ' ' '\n' | grep otel

Periksa apakah metrik dinonaktifkan secara eksplisit:

kubectl get inferencegatewayconfig <name> -n <namespace> \
  -o jsonpath='{.spec.observability.metrics.enabled}'

Output kosong dari perintah terakhir berarti bidang tidak diatur, dan metrik diaktifkan. Hanya eksplisit yang false menonaktifkan sespan. Jika nilainyafalse, atur ke true atau hapus bidang, dan pengontrol menyuntikkan sespan pada rekonsiliasi berikutnya.

Kegagalan permintaan

Masalah: Gateway sudah Siap, tetapi permintaan inferensi gagal.

Gejala dan resolusi:

Mendebug pemilihan titik akhir

Masalah: Lalu lintas condong ke sejumlah kecil pod model, atau permintaan LoRa dirutekan ke pod yang tidak meng-host adaptor.

Resolusi: Tingkatkan verbositas log Endpoint Picker untuk sementara untuk memeriksa keputusan penilaiannya. Setel logLevel pada penjadwal:

spec:
  schedulers:
    - name: <scheduler-name>
      logLevel: 4

Arti tingkat log:

Periksa log Endpoint Picker:

kubectl logs -n <namespace> -l app=<scheduler-name>-epp -c epp --tail=200 -f

Kembali logLevel ke defaultnya saat penyelidikan selesai untuk menghindari volume log berlebih.

Siklus hidup dan pembersihan

Masalah: Menghapus instalasi atau memutakhirkan add-on HyperPod Inference Amazon EKS meninggalkan sumber daya yatim piatu di cluster, atau memblokir instalasi berikutnya.

Resolusi: Selalu hapus setiap InferenceGatewayConfig sumber daya sebelum menghapus atau memutakhirkan add-on. Menghapus instalasi add-on saat masih InferenceGatewayConfig ada menghapus pengontrol yang memiliki finalizer sumber daya, yang membuat sumber daya tersebut macet. Terminating

kubectl delete inferencegatewayconfig --all -A
kubectl get inferencegatewayconfig -A

Konfirmasikan bahwa perintah kedua tidak mengembalikan baris sebelum melanjutkan operasi add-on.

Setelah menginstal ulang add-on, daftarkan sumber daya di namespace gateway dan hapus apa pun yang tidak lagi dipetakan ke live: InferenceGatewayConfig

kubectl get deploy,svc,httproute,inferencepool,gateway,configmap \
  -n hyperpod-inference-system

Sertifikat ACM yang dikeluarkan oleh controller tidak dihapus oleh add-on uninstall. Untuk menghapusnya, filter sertifikat ACM di AWS Resource Groups Tagging API dengan tag CreatedBy=HyperPodInference dan hapus sertifikat yang tidak lagi Anda perlukan.

Kumpulkan log

Gunakan perintah berikut untuk mengambil log dari setiap komponen gateway:

# Gateway controller
kubectl logs -n hyperpod-inference-system deploy/inference-gateway-controller

# Body-Based Router (deployment name is <gateway-name>-bbr)
kubectl logs -n hyperpod-inference-system deploy/<gateway-name>-bbr -c bbr

# Endpoint Picker for a specific scheduler
kubectl logs -n <namespace> -l app=<scheduler-name>-epp -c epp