समस्या का हल

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

Istio 404 (नहीं मिला) गड़बड़ी

Istio पर 404 (नहीं मिला) गड़बड़ी को ठीक करना मुश्किल हो सकता है. हमें उम्मीद है कि इससे आपको यह पता लगाने में मदद मिलेगी कि कहां गड़बड़ी हो रही है.

वाइल्डकार्ड गेटवे का टकराव

सिर्फ़ एक गेटवे डेफ़िनिशन हो सकता है, जिसमें वाइल्डकार्ड "*" होस्ट वैल्यू का इस्तेमाल किया गया हो. अगर आपने वाइल्डकार्ड गेटवे को शामिल करने वाला कोई दूसरा कॉन्फ़िगरेशन डिप्लॉय किया है, तो क्लाइंट कॉल 404 स्टेटस के साथ फ़ेल हो जाएंगे.

उदाहरण:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

अगर ऐसा है, तो आपको टकराव वाले किसी एक गेटवे को मिटाना होगा या उसमें बदलाव करना होगा.

उस जगह का पता लगाना जहां रूट काम नहीं कर रहा है

Istio, प्याज़ (या शायद, एक राक्षस) की तरह है. इसमें कई लेयर होती हैं. 404 कोड वाली गड़बड़ी को डीबग करने का एक व्यवस्थित तरीका यह है कि टारगेट से बाहर की ओर काम किया जाए.

बैकएंड वर्कलोड

पुष्टि करें कि साइडकार से वर्कलोड को ऐक्सेस किया जा सकता है:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

बैकएंड साइडकार

सेवा का पता सेट करें और वर्कलोड पॉड का आईपी पता पाएं.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

साइडकार के ज़रिए वर्कलोड ऐक्सेस करें:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

इसके अलावा, अगर Istio mTLS चालू है, तो:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

गेटवे (या फ़्रंटएंड साइडकार)

गेटवे से सेवा को ऐक्सेस करें:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

इसके अलावा, अगर Istio mTLS चालू है, तो:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

आंकड़े मौजूद नहीं हैं

अगर आपको Analytics के यूज़र इंटरफ़ेस (यूआई) में आंकड़े नहीं दिख रहे हैं, तो इसकी ये वजहें हो सकती हैं:

• Apigee में डेटा आने में कुछ मिनट लग सकते हैं
• Envoy gRPC ऐक्सेस लॉग को सही तरीके से कॉन्फ़िगर नहीं किया गया है
• Envoy, रिमोट सर्विस तक नहीं पहुंच सकता
• रिमोट सेवा के ज़रिए अपलोड नहीं किया जा सका

एपीआई पासकोड मौजूद नहीं है या गलत है, लेकिन उसे अस्वीकार नहीं किया जा रहा है

अगर एपीआई पासकोड की पुष्टि करने की सुविधा ठीक से काम नहीं कर रही है, तो इसकी ये वजहें हो सकती हैं:

डायरेक्ट प्रॉक्सी

ext-authz कॉन्फ़िगरेशन की जांच करें.

• पक्का करें कि लिसनर को इंटरसेप्ट करने के लिए कॉन्फ़िगर किया गया हो.
• ext-authz कॉन्फ़िगरेशन की जांच करें.

अमान्य अनुरोधों की जांच की जा रही है और उन्हें अनुमति दी जा रही है

• रिमोट सेवा को फ़ेल ओपन के लिए कॉन्फ़िगर किया गया है
• Envoy को RBAC की जांच के लिए कॉन्फ़िगर नहीं किया गया है

इन समस्याओं को ठीक करने के बारे में जानने के लिए, Envoy के दस्तावेज़ का यह विषय पढ़ें: External Authorization. साथ ही, failure_mode_allow प्रॉपर्टी के बारे में जानकारी देखें. इस प्रॉपर्टी की मदद से, गड़बड़ियों के मामले में फ़िल्टर के व्यवहार में बदलाव किया जा सकता है.

JWT मौजूद नहीं है या खराब है, लेकिन उसे अस्वीकार नहीं किया जा रहा है

इसकी वजह यह हो सकती है कि Envoy JWT फ़िल्टर कॉन्फ़िगर नहीं किया गया है.

मान्य एपीआई पासकोड काम नहीं करता

संभावित वजहें

• Envoy, रिमोट सेवा तक नहीं पहुंच सकता
• आपके क्रेडेंशियल मान्य नहीं हैं
• Apigee API प्रॉडक्ट को टारगेट और एनवायरमेंट के लिए कॉन्फ़िगर नहीं किया गया है

समस्या हल करने का तरीका

Apigee पर अपना एपीआई प्रॉडक्ट देखना

• क्या यह आपके एनवायरमेंट (टेस्ट बनाम प्रॉड) के लिए चालू है?

  प्रॉडक्ट को उसी एनवायरमेंट से बाइंड किया जाना चाहिए जिससे आपकी रिमोट सेवा बाइंड है.

• क्या यह उस टारगेट से जुड़ा है जिसे ऐक्सेस किया जा रहा है?

  Apigee की रिमोट सेवा के टारगेट सेक्शन देखें. याद रखें कि सेवा का नाम, पूरी तरह क्वालिफ़ाइड होस्ट नेम होना चाहिए. अगर यह Istio सेवा है, तो नाम कुछ इस तरह का होगा helloworld.default.svc.cluster.localcode> - यह default नेमस्पेस में helloworld सेवा को दिखाता है.

• क्या संसाधन का पाथ आपके अनुरोध से मेल खाता है?

  ध्यान रखें कि / या /** जैसे पाथ, किसी भी पाथ से मेल खाएंगे. मैच करने के लिए, '*' या '**' वाइल्डकार्ड का इस्तेमाल भी किया जा सकता है.

• क्या आपके पास Developer App है?

  एपीआई प्रॉडक्ट को डेवलपर ऐप्लिकेशन से बाइंड किया जाना चाहिए, ताकि उसकी कुंजियों की जांच की जा सके.

अपने अनुरोध की जांच करना

• क्या आपने x-api-key header में उपभोक्ता कुंजी पास की है

  उदाहरण:

  curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"

• क्या आपने सही Consumer Key का इस्तेमाल किया है?

  पक्का करें कि जिस ऐप्लिकेशन का इस्तेमाल किया जा रहा है उसके क्रेडेंशियल, आपके एपीआई प्रॉडक्ट के लिए स्वीकार किए गए हों.

रिमोट सर्विस के लॉग देखें

1. debug level पर लॉगिंग के साथ रिमोट सेवा शुरू करें. रिमोट सेवा के लॉग लेवल सेट करना लेख पढ़ें.

   कमांड लाइन पर -l debug विकल्प का इस्तेमाल करें. उदाहरण के लिए:

   apigee-remote-service-envoy -l debug

2. टारगेट को ऐक्सेस करने की कोशिश करें और लॉग देखें

   लॉग में ऐसी लाइन देखें:

   Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
   Selected: [helloworld]
   Eliminated: [helloworld2 doesn't match path: /hello]
   

रिमोट सेवा के लॉग लेवल सेट करना

कमांड लाइन फ़्लैग का इस्तेमाल करके, रिमोट सेवा को इनमें से किसी एक डीबग मोड में शुरू किया जा सकता है. ये मोड, वर्बोसिटी के क्रम में दिए गए हैं. इनमें debug सबसे ज़्यादा वर्बोस है और error सबसे कम:

• debug - यह सबसे ज़्यादा वर्बोस लॉगिंग मोड है.
• info - डिफ़ॉल्ट.
• warn
• error - सबसे कम वर्बोस लॉगिंग मोड.

उदाहरण के लिए, debug लेवल पर सेवा शुरू करने के लिए:

apigee-remote-service-envoy -l debug