Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンを構成する
オープンソースの Istio は、MeshConfig を使って、Istio サービス メッシュのメッシュ全体の設定を定義しています。 AKS 用の Istio ベースのサービス メッシュ アドオンは MeshConfig の上に構築されており、さまざまなプロパティをサポートあり、許可、ブロックとして分類することができます。
この記事では、Azure Kubernetes Service 用の Istio ベースのサービス メッシュ アドオンを構成する方法と、そのような構成に適用されるサポート ポリシーについて説明します。
前提条件
このガイドは、こちらの [ドキュメント] に従って AKS クラスター上で Istio アドオンを有効にしていることを前提としています。
クラスター上で構成を設定する
クラスターにデプロイされている 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" }
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
のフィールドは、allowed
、supported
、または 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
フィールドを使って軽減できます。
Azure Kubernetes Service