1. Homepage
  2. Service Mesh (1.2)
  3. Service Mesh のトラブルシューティング

  4. ポリシー適用の問題

ポリシー適用の問題のトラブルシューティング

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: LoadBalancer

解決策

Istio では、すべてのポートに名前を付ける​必要があります。このエラーを解決するには、名前付きのポートを使用してサービスを作成し直します。

apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes
spec:
  type: LoadBalancer
  ports:
  - port: 80
    name: http
    targetPort: 8080
  selector:
    app: hello-kubernetes

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 (バインドサービス名が実際のサービス名と一致しない)

バインドを作成するときには、サービス名を指定する必要があります。指定したサービス名が実際のサービス名と一致しないと、ポリシーは適用されません。

原因

存在しないサービスを参照するようにバインドが作成されました。

診断

この問題を診断する手順は、次のとおりです。

  1. 次のいずれかのコマンドを使用してサービスバインドを確認します。

    • $ asmctl api binding list

    • $ asmctl adapter binding list

  2. サービスをバインドと比較します。

    $ kubectl -n <namespace> get services

    バインドサービスと実際のサービスの不一致エラー

上の例では、サービス名は ​customers.nto-payment.svc.cluster.nto-cluster​ ではなく、​customer-service​ などである必要があります。

解決策

この問題を解決する手順は、次のとおりです。

  1. 次のいずれかのコマンドを実行して既存のバインドを削除します。

    • $ asmctl api binding delete --name=​binding_name​ --namespace=​binding_namespace

    • $ asmctl adapter binding delete --name=​binding_name​ --namespace=​binding_namespace

  2. 実際のサービスを参照するようにバインドを作成し直します。

バインドサービスと実際のサービスの不一致エラーの解決

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

原因

このエラーは、ライセンスが期限切れになり、その結果としてアダプターが再起動した場合に発生します。

診断

この問題を診断する手順は、次のとおりです。

  1. アダプターポッドを表示します。

    $ kubectl get pods -n service-mesh

  2. アダプターのログを取得します。

    $ kubectl -n service-mesh logs $(kubectl -n service-mesh get pod -l namespace=​replace_with_namespace​ -oname) -c mule

    ライセンスが期限切れになっている場合は、次のようなエラーが表示されます。

    内部 500 エラーメッセージ

解決策

この問題を解決する手順は、次のとおりです。

  1. 既存のライセンスを有効なライセンスに置き換えます。

    $ asmctl management config license --license=/path/to/license.lic

  2. アダプターを再デプロイします。

    $ 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)\"}]"