次の方法で共有


Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンを構成する

オープンソースの Istio は、MeshConfig を使って、Istio サービス メッシュのメッシュ全体の設定を定義しています。 AKS 用の Istio ベースのサービス メッシュ アドオンは MeshConfig の上に構築されており、さまざまなプロパティをサポートあり、許可、ブロックとして分類することができます。

この記事では、Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンを構成する方法と、そのような構成に適用されるサポート ポリシーについて説明します。

前提条件

このガイドは、こちらの [ドキュメント] に従って AKS クラスター上で Istio アドオンを有効にしていることを前提としています。

クラスター上で構成を設定する

  1. クラスターにデプロイされている Istio のリビジョンを確認します。

    az aks show --name $CLUSTER --resource-group $RESOURCE_GROUP --query 'serviceMeshProfile'
    

    出力:

    {
      "istio": {
          "certificateAuthority": null,
          "components": {
          "egressGateways": null,
          "ingressGateways": null
          },
          "revisions": [
          "asm-1-18"
          ]
      },
      "mode": "Istio"
    }
    
  2. aks-istio-system 名前空間に istio-shared-configmap-<asm-revision> という ConfigMap を作成します。 たとえば、クラスターで asm-1-18 リビジョンのメッシュが実行されている場合、ConfigMap の名前を istio-shared-configmap-asm-1-18 にする必要があります。 メッシュ構成は、メッシュのデータ セクション内で指定する必要があります。

    例:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: istio-shared-configmap-asm-1-18
      namespace: aks-istio-system
    data:
      mesh: |-
        accessLogFile: /dev/stdout
        defaultConfig:
          holdApplicationUntilProxyStarts: true
    

    defaultConfig の値は、Envoy サイドカー プロキシに適用されるメッシュ全体の設定です。

注意事項

Istio アドオンが有効な場合、既定の ConfigMap (たとえば、リビジョン asm-1-18 の istio-asm-1-18) はクラスター上の aks-istio-system 名前空間に作成されます。 ただし、この既定の ConfigMap はマネージド Istio アドオンによって調整されるため、ユーザーはこの ConfigMap を直接編集しないでください。 代わりに、ユーザーは aks-istio-system 名前空間にリビジョン固有の Istio 共有 ConfigMap (たとえば、リビジョン asm-1-18 の場合は istio-shared-configmap-asm-1-18) を作成する必要があります。そうすると、既定の設定が優先され、これは Istio コントロール プレーンによって既定の ConfigMap とマージされます。

メッシュの構成とアップグレード

Istio のカナリア アップグレードを実行する場合は、カナリア アップグレードを開始する前に新しいリビジョン用に別の ConfigMap を aks-istio-system 名前空間に作成する必要があります。 こうすることで、新しいリビジョンのコントロール プレーンがクラスターにデプロイされるときに構成を使用できるようになります。 たとえば、メッシュを asm-1-18 から asm-1-19 にアップグレードする場合、istio-shared-configmap-asm-1-18 から変更をコピーして、aks-istio-system 名前空間に istio-shared-configmap-asm-1-19 という新しい ConfigMap を作成する必要があります。

アップグレードが完了するかロールバックした後、クラスターから削除されたリビジョンの ConfigMap を削除できます。

許可、サポート、ブロックされる MeshConfig の値

MeshConfig のフィールドは、allowedsupported、または blocked に分類されます。 これらのカテゴリの詳細については、Istio アドオンの機能と構成オプションに対するサポート ポリシーを参照してください。

メッシュ構成と許可またはサポートのフィールド一覧は、リビジョン間で追加または削除されるフィールドを考慮したリビジョン固有のものです。 許可フィールドの完全な一覧と、許可一覧内のサポートされるものとサポートされないものを以下の表に示します。 新しいメッシュ リビジョンが使用可能になると、フィールドの許可およびサポートの分類に対する変更はこの表に記載されます。

MeshConfig

オープン ソースの MeshConfig リファレンス ドキュメントに記載されていても、次の表で説明されていないフィールドはブロックされます。 たとえば、configSources はブロックされます。

フィールド サポート/許可 ノート
proxyListenPort 許可 -
proxyInboundListenPort 許可 -
proxyHttpPort 許可 -
connectTimeout 許可 DestinationRule で構成可能
tcpKeepAlive 許可 DestinationRule で構成可能
defaultConfig サポートされています ProxyConfig を構成するために使用
outboundTrafficPolicy サポートされています Sidecar CR でも構成可能
extensionProviders 許可 -
defaultProviders 許可 -
accessLogFile サポートされています このフィールドは、アクセス ログの生成に関するものです。 マネージド型でのログの収集とクエリ実行のエクスペリエンスについては、AKS に対する Azure Monitor コンテナー分析情報に関するページを参照してください。 Telemetry API を使用してアクセス ログを構成することをお勧めします。
accessLogFormat サポートされています このフィールドは、アクセス ログの生成に関するものです。 ログの収集とクエリに関するマネージド エクスペリエンスについては、AKS の Azure Monitor Container Insights に関するページを参照してください
accessLogEncoding サポートされています このフィールドは、アクセス ログの生成に関するものです。 ログの収集とクエリに関するマネージド エクスペリエンスについては、AKS の Azure Monitor Container Insights に関するページを参照してください
enableTracing 許可 Telemetry API を使用してトレースを構成することをお勧めします。
enableEnvoyAccessLogService サポートされています このフィールドは、アクセス ログの生成に関するものです。 ログの収集とクエリに関するマネージド エクスペリエンスについては、AKS の Azure Monitor Container Insights に関するページを参照してください
disableEnvoyListenerLog サポートされています このフィールドは、アクセス ログの生成に関するものです。 ログの収集とクエリに関するマネージド エクスペリエンスについては、AKS の Azure Monitor Container Insights に関するページを参照してください
trustDomain 許可 -
trustDomainAliases 許可 -
caCertificates 許可 DestinationRule で構成可能
defaultServiceExportTo 許可 ServiceEntry で構成可能
defaultVirtualServiceExportTo 許可 VirtualService で構成可能
defaultDestinationRuleExportTo 許可 DestinationRule で構成可能
localityLbSetting 許可 DestinationRule で構成可能
dnsRefreshRate 許可 -
h2UpgradePolicy 許可 DestinationRule で構成可能
enablePrometheusMerge 許可 -
discoverySelectors サポートされています -
pathNormalization 許可 -
defaultHttpRetryPolicy 許可 VirtualService で構成可能
serviceSettings 許可 -
meshMTLS 許可 -
tlsDefaults 許可 -
ingressService 許可 istio イングレス コントローラー用に使用する Kubernetes サービスの名前。
ingressSelector 許可 イングレス コントローラーとして使用するゲートウェイ デプロイを定義します。 このフィールドは Gateway.selector フィールドに対応し、istio: INGRESS_SELECTOR として設定されます。

ProxyConfig (meshConfig.defaultConfig)

オープン ソースの MeshConfig リファレンス ドキュメントに記載されていても、次の表で説明されていないフィールドはブロックされます。

フィールド サポート/許可 ノート
tracingServiceName 許可 Telemetry API を使用してトレースを構成することをお勧めします。
drainDuration サポートされています -
statsUdpAddress 許可 -
proxyAdminPort 許可 -
tracing 許可 Telemetry API を使用してトレースを構成することをお勧めします。
concurrency サポートされています -
envoyAccessLogService 許可 Telemetry API を使用してトレースを構成することをお勧めします。
envoyMetricsService 許可 Telemetry API をしてメトリック収集を構成することをお勧めします。
proxyMetadata 許可 -
statusPort 許可 -
extraStatTags 許可 -
proxyStatsMatcher 許可 -
terminationDrainDuration サポートされています -
meshId 許可 -
holdApplicationUntilProxyStarts サポートされています -
caCertificatesPem 許可 -
privateKeyProvider 許可 -

注意事項

構成のサポート範囲: メッシュ構成では、Zipkin や Apache Skywalking のセルフマネージド インスタンスなどの拡張機能プロバイダーを Istio アドオンで構成できます。 ただし、これらの拡張機能プロバイダーは、Istio アドオンのサポート範囲外です。 拡張機能ツールに関する問題はすべて、Istio アドオンのサポート範囲外です。

一般的なエラーとトラブルシューティングのヒント

  • MeshConfig がタブではなくスペースでインデントされていることを確認します。
  • リビジョン固有の共有 ConfigMap (たとえば istio-shared-configmap-asm-1-18) のみを編集し、既定の ConfigMap (たとえば istio-asm-1-18) を編集しようとしていないことを確認します。
  • ConfigMap は名前 istio-shared-configmap-<asm-revision> に従い、aks-istio-system 名前空間内に存在する必要があります。
  • すべての MeshConfig フィールドの綴りが正しいことを確認します。 認識されない場合、または許可一覧に含まれていない場合、アドミッション コントロールはそのような構成を拒否します。
  • カナリア アップグレードを実行するときは、リビジョン固有の ConfigMaps を確認して、クラスターにデプロイされているリビジョンの構成が存在することを確認します。
  • accessLogging などの一部の MeshConfig オプションを使うと、Envoy のリソース消費量が増加する可能性があります。また、このような設定の一部を無効にすると、Istio データ プレーンのリソース使用率が軽減される可能性があります。 Istiod と Envoy のメモリ消費を軽減するために、MeshConfig で discoverySelectors フィールドを使うこともお勧めします。
  • MeshConfig の concurrency フィールドが誤って構成され、0 に設定されている場合、Envoy はすべての CPU コアを使い果たします。 代わりに、このフィールドが設定されていない場合、実行するワーカー スレッド数は CPU 要求と制限に基づいて自動的に決定されます。
  • Envoy よりも前にアプリケーションが開始されるポッドとサイドカーの競合状態は、MeshConfig で holdApplicationUntilProxyStarts フィールドを使って軽減できます。