ポリシー適用の問題のトラブルシューティング
ポリシーをサービスに適用しても、Mule アダプターがこれらのポリシーを適用せずに次のエラーメッセージが返される場合があります。
Service port is not named (サービスポートに名前がない)
サービスを作成するときは、ポートやセレクターなどの仕様を指定する必要があります。これらはそれぞれ定義する必要のあるパラメーターを持ちます。ポートをサービスに割り当てるときは、エラーを回避するために、そのポートの名前 (「http」など) も指定する必要があります。Istio では、すべてのポートに名前を付ける
必要があります。
原因
サービスポートの名前が指定されていません。
診断
この問題を診断するには、アプリケーションを公開しているサービスの定義を確認します。
$ kubectl -n namespace get services -o yaml
たとえば、次のサービスは名前付きのポートを持っていません。
apiVersion: v1 items: - apiVersion: v1 kind: Service metadata: creationTimestamp: "2019-10-09T19:08:28Z" name: hello-kubernetes namespace: default resourceVersion: "7075" selfLink: /api/v1/namespaces/default/services/hello-kubernetes uid: 2d0719a5-eac8-11e9-93c9-06b247319cf6 spec: clusterIP: 172.20.177.73 externalTrafficPolicy: Cluster ports: - nodePort: 32231 port: 80 protocol: TCP targetPort: 8080 selector: app: hello-kubernetes sessionAffinity: None type: LoadBalancertext
解決策
Istio では、すべてのポートに名前を付ける必要があります。このエラーを解決するには、名前付きのポートを使用してサービスを作成し直します。
apiVersion: v1 kind: Service metadata: name: hello-kubernetes spec: type: LoadBalancer ports: - port: 80 name: http targetPort: 8080 selector: app: hello-kubernetestext
Policy not disassociated after deleting bindings (バインドの削除後にポリシーの関連付けが解除されていない)
バインドを削除しても、サービスに適用されていたポリシーが正常に削除されない場合があります。
原因
バインドを削除したときに、関連付けられていたトラフィックルールを削除しませんでした。その結果、トラフィックが Mule アダプターに引き続き送信されています。
診断
この問題を診断するには、サービスルールが削除されていることを確認します。
$ kubectl get rules -l serviceName=service name
まだルールが適用されている場合は、ルールを手動で削除してください。
解決策
サービスに適用されている正しくないルールを削除します。
$ kubectl delete rules -l serviceName=service_name
Binding service name does not match actual service name (バインドサービス名が実際のサービス名と一致しない)
バインドを作成するときには、サービス名を指定する必要があります。指定したサービス名が実際のサービス名と一致しないと、ポリシーは適用されません。
原因
存在しないサービスを参照するようにバインドが作成されました。
診断
この問題を診断する手順は、次のとおりです。
-
次のいずれかのコマンドを使用してサービスバインドを確認します。
-
$ asmctl api binding list -
$ asmctl adapter binding list
-
-
サービスをバインドと比較します。
$ kubectl -n <namespace> get services
上の例では、サービス名は customers.nto-payment.svc.cluster.nto-cluster ではなく、customer-service などである必要があります。
解決策
この問題を解決する手順は、次のとおりです。
-
次のいずれかのコマンドを実行して既存のバインドを削除します。
-
$ asmctl api binding delete --name=binding_name --namespace=binding_namespace -
$ asmctl adapter binding delete --name=binding_name --namespace=binding_namespace
-
-
実際のサービスを参照するようにバインドを作成し直します。
Application pod does not have an Envoy sidecar (アプリケーションポッドに Envoy サイドカーが割り当てられていない)
アプリケーションポッドの Envoy エラーにより、ポリシーが適用されません。
原因
すべてのポッドに Envoy サイドカーを挿入するようにマークされていた名前空間で、アプリケーションが再起動されませんでした。
診断
この問題を診断するには、サイドカーに Envoy プロキシが関連付けられていることを確認します。
$ asmctl management check sidecar
解決策
端末の状況が Injected と表示されていない場合は、ポッドを再起動する必要があります。
$ kubectl -n <namespace> delete pods <pod_name>
Internal error with 500 error code (エラーコード 500 の内部エラー)
Anypoint Service Mesh で管理されているアプリケーションがエラーコード 500 を生成し、次のエラー情報を返しました。
INTERNAL:grpcmule-nto-payment.handler.service-mesh.INTERNAL:grpcmule-nto-payment.handler.service-mesh
原因
このエラーは、ライセンスが期限切れになり、その結果としてアダプターが再起動した場合に発生します。
診断
この問題を診断する手順は、次のとおりです。
-
アダプターポッドを表示します。
$ kubectl get pods -n service-mesh -
アダプターのログを取得します。
$ kubectl -n service-mesh logs $(kubectl -n service-mesh get pod -l namespace=replace_with_namespace -oname) -c muleライセンスが期限切れになっている場合は、次のようなエラーが表示されます。
解決策
この問題を解決する手順は、次のとおりです。
-
既存のライセンスを有効なライセンスに置き換えます。
$ asmctl management config license --license=/path/to/license.lic -
アダプターを再デプロイします。
$ kubectl -n service-mesh patch $(kubectl -n service-mesh get deploy -l namespace=replace_with_namespace -oname) --type=json -p="[{\"op\": \"replace\", \"path\": \"/spec/template/metadata/annotations/kubectl.kubernetes.io~1restartedAt\",\"value\":\"$(date -u +%FT%TZ)\"}]"