Azure Arc 対応 Kubernetes クラスター拡張機能に関する問題のトラブルシューティング
このドキュメントでは、GitOps (Flux v2) や Open Service Mesh など、クラスター拡張機能に関連する一般的な問題に関するトラブルシューティングのヒントについて説明します。
Azure Arc 対応 Kubernetes に関する一般的な問題のトラブルシューティングについては、「Azure Arc 対応 Kubernetes の問題のトラブルシューティング」を参照してください。
GitOps (Flux v2)
Note
Flux v2 拡張機能は、Azure Arc 対応 Kubernetes クラスターまたは Azure Kubernetes Service (AKS) クラスターで使用できます。 これらのトラブルシューティングのヒントは、通常、クラスターの種類に関係なく適用されます。
fluxConfigurations リソースに関する問題の一般的なトラブルシューティングについては、--debug パラメーターを指定して次の Azure CLI コマンドを実行してください。
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug
Webhook/dry run エラー
dry-run failed, error: admission webhook "<webhook>" does not support dry run のようなエラーが発生して、Flux の調整に失敗した場合は、ValidatingWebhookConfiguration または MutatingWebhookConfiguration を検索し、sideEffects を None または NoneOnDryRun に設定して問題を解決できます。
詳細については、「webhook does not support dry run エラーを解決する方法」を参照してください。
microsoft.flux 拡張機能のインストール
microsoft.flux 拡張機能は、Azure Arc 対応の Kubernetes または Azure Kubernetes Service (AKS) クラスターに、Flux コントローラーと Azure GitOps エージェントをインストールします。 クラスターに拡張機能がまだインストールされていない場合、そのクラスターの GitOps 構成リソースを作成すると、拡張機能が自動的にインストールされます。
インストール中にエラーが発生した場合、または拡張機能が失敗状態の場合は、クラスターに flux-system 名前空間またはその名前空間内のリソースの作成を制限するポリシーがないことを確認してください。
AKS クラスターの場合は、サブスクリプションで Microsoft.ContainerService/AKS-ExtensionManager 機能フラグが有効になっていることを確かめます。
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
その後、このコマンドを実行して、他の問題があるかどうかを判断します。 クラスターの種類 (-t) パラメーターは、Arc 対応クラスターの場合は connectedClusters、AKS クラスターの場合は managedClusters に設定します。 microsoft.flux 拡張機能が GitOps 構成の作成時に自動的にインストールされた場合、この拡張機能の名前は "flux" です。 詳細については、statuses オブジェクトを参照してください。
az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>
表示された結果は、問題の原因とその修正方法を判断するのに役立ちます。 考えられる修復アクションは次のとおりです。
az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>を実行して拡張機能を強制的に削除するhelm uninstall flux -n flux-system実行して Helm リリースをアンインストールするkubectl delete namespaces flux-systemを実行してクラスターからflux-system名前空間を削除する
その後、flux 構成を再作成するか (microsoft.flux 拡張機能が自動的にインストールされます)、flux 拡張機能を手動で再インストールすることができます。
Microsoft Entra Pod ID が有効なクラスターへの microsoft.flux 拡張機能のインストール エラー
Microsoft Entra のポッド ID が有効になっているクラスターに Flux 拡張機能をインストールしようとすると、拡張機能エージェント ポッドでエラーが発生する可能性があります。
{"Message":"2021/12/02 10:24:56 Error: in getting auth header : error {adal: Refresh request failed. Status Code = '404'. Response body: no azure identity found for request clientID <REDACTED>\n}","LogType":"ConfigAgentTrace","LogLevel":"Information","Environment":"prod","Role":"ClusterConfigAgent","Location":"westeurope","ArmId":"/subscriptions/<REDACTED>/resourceGroups/<REDACTED>/providers/Microsoft.Kubernetes/managedclusters/<REDACTED>","CorrelationId":"","AgentName":"FluxConfigAgent","AgentVersion":"0.4.2","AgentTimestamp":"2021/12/02 10:24:56"}
拡張機能の状態も Failed として返されます。
"{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"ExtensionCreationFailed\",\"message\":\" error: Unable to get the status from the local CRD with the error : {Error : Retry for given duration didn't get any results with err {status not populated}}\"}]}}",
この場合、拡張機能エージェント ポッドは、クラスター上の IMDS からトークンを取得しようとします。 しかし、このトークン要求はポッド ID によって遮断されます)。 この問題を解決するには、microsoft.flux 拡張機能を最新バージョンにアップグレードしてください。
AKS クラスターに microsoft.flux 拡張機能をインストールする際の kubelet ID に関する問題
AKS クラスターを使用する場合、認証オプションの 1 つに、ユーザー割り当てマネージド ID を使う kubelet ID があります。 kubelet ID を使用すると、運用上のオーバーヘッドを減らし、Azure Container Registry などの Azure リソースに接続するときのセキュリティを向上させることができます。
Flux で kubelet ID を使用できるようにするには、Flux 拡張機能をインストールするときにパラメーター --config useKubeletIdentity=true を追加します。
az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true
microsoft.flux 拡張機能のインストールに必要なメモリと CPU の要件が満たされていることを確認する
microsoft.flux 拡張機能を使用して Kubernetes クラスターにインストールされたコントローラーでは、Kubernetes クラスター ノードで適切にスケジュールを設定するために CPU とメモリ リソースが必要です。 クラスターが、要求される可能性がある最小メモリと CPU リソースを満たすことができることを確認します。 また、ここに示されている CPU およびメモリ リソースの潜在的な要件の上限にも注意してください。
| コンテナー名 | 最小 CPU | 最小メモリ | 最大 CPU | 最大メモリ |
|---|---|---|---|---|
| fluxconfig-agent | 5 m | 30 Mi | 50 m | 150 Mi |
| fluxconfig-controller | 5 m | 30 Mi | 100 m | 150 Mi |
| fluent-bit | 5 m | 30 Mi | 20 m | 150 Mi |
| helm-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| source-controller | 50 m | 64 Mi | 1000 m | 1 Gi |
| kustomize-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| notification-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| image-automation-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
| image-reflector-controller | 100 m | 64 Mi | 1000 m | 1 Gi |
Kubernetes クラスターでコンテナーのリソースを制限するカスタムまたは組み込みの Azure Gatekeeper Policy (Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits など) を有効にした場合は、ポリシーのリソース制限がここに示す制限より上回るか、flux-system 名前空間がポリシー割り当ての excludedNamespaces パラメーターに含まれていることを確かめてください。
Flux v1
Note
できるだけ早く Flux v2 に移行 することをお勧めします。 2024 年 1 月 1 日より前に作成された Flux v1 ベースのクラスター構成リソースのサポートは、2025 年 5 月 24 日に終了します。 2024 年 1 月 1 日から、新しい Flux v1 ベースのクラスター構成リソースを作成することはできません。
Flux v1 の sourceControlConfigurations リソースに関する問題のトラブルシューティングに役立てるため、--debug パラメーターを指定して次の Azure CLI コマンドを実行します。
az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration create <parameters> --debug
Azure Monitor Container Insights
このセクションでは、Azure Arc 対応 Kubernetes クラスター の Azure Monitor Container Insights に関する問題のトラブルシューティングについて説明します。
Canonical Charmed Kubernetes クラスターの特権モードの有効化
Azure Monitor Container Insights では、その DaemonSet を特権モードで実行する必要があります。 監視のために Canonical Charmed Kubernetes クラスターを正常に設定するには、次のコマンドを実行します。
juju config kubernetes-worker allow-privileged=true
Oracle Linux 9.x に Azure Monitor エージェント (AMA) をインストールできない
Oracle Linux (RHEL) 9.x Kubernetes クラスターに Azure Monitor エージェント (AMA) をインストールしようとすると、ポッド内の addon-token-adapter コンテナーが原因で AMA ポッドと AMA-RS ポッドが正常に動作しない可能性があります。 このエラーで、ama-logs-rs ポッドの addon-token-adapter container ログを確認すると、次のような出力が表示されます。
Command: kubectl -n kube-system logs ama-logs-rs-xxxxxxxxxx-xxxxx -c addon-token-adapter
Error displayed: error modifying iptable rules: error adding rules to custom chain: running [/sbin/iptables -t nat -N aad-metadata --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
iptables v1.8.9 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
このエラーは、拡張機能をインストールするには iptable_nat モジュールが必要ですが、このモジュールが Oracle Linux (RHEL) 9.x ディストリビューションに自動的に読み込まれないために発生します。
この問題を解決するには、modprobe コマンド sudo modprobe iptables_nat を使用して、クラスター内の各ノードに iptables_nat モジュールを明示的に読み込む必要があります。 各ノードにサインインし、iptable_nat モジュールを手動で追加したら、AMA のインストールを再試行します。
Note
この手順を実行しても、iptables_nat モジュールは永続的になりません。
Azure Arc 対応 Open Service Mesh
このセクションでは、クラスター上の Open Service Mesh (OSM) 拡張機能コンポーネントのデプロイの検証とトラブルシューティングに使用できるコマンドについて説明します。
OSM コントローラーのデプロイを確認する
kubectl get deployment -n arc-osm-system --selector app=osm-controller
OSM コントローラーが正常な場合は、次のような出力が表示されます。
NAME READY UP-TO-DATE AVAILABLE AGE
osm-controller 1/1 1 1 59m
OSM コントローラー ポッドを確認する
kubectl get pods -n arc-osm-system --selector app=osm-controller
OSM コントローラーが正常な場合は、次のような出力が表示されます。
NAME READY STATUS RESTARTS AGE
osm-controller-b5bd66db-wglzl 0/1 Evicted 0 61m
osm-controller-b5bd66db-wvl9w 1/1 Running 0 31m
ある時点で 1 つのコントローラーは Evicted になっていますが、もう 1 つは READY 1/1、Running、RESTARTS 0 になっています。 READY 列が 1/1 以外の場合、サービス メッシュは破損した状態です。 0/1 の READY 列は、コントロール プレーン コンテナーがクラッシュしていることを示します。
コントローラーのログを調べるには、次のコマンドを使います。
kubectl logs -n arc-osm-system -l app=osm-controller
/ の後に 1 より大きい数が示された READY 列は、サイドカーがインストールされていることを示します。 OSM コントローラーは通常、サイドカーが接続された状態では正常に動作しません。
OSM コントローラー サービスの確認
kubectl get service -n arc-osm-system osm-controller
OSM コントローラーが正常な場合は、次の出力が表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
Note
CLUSTER-IP が異なります。 サービス NAME と PORT(S) は、ここに表示されているものと 一致する必要があります。
OSM コントローラー エンドポイントを確認する
kubectl get endpoints -n arc-osm-system osm-controller
OSM コントローラーが正常な場合は、次のような出力が表示されます。
NAME ENDPOINTS AGE
osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
クラスターに osm-controller 用の ENDPOINTS がない場合、コントロール プレーンは異常です。 この異常な状態は、コントローラー ポッドがクラッシュしたか、正しくデプロイされなかったことを意味します。
OSM インジェクターのデプロイを確認する
kubectl get deployments -n arc-osm-system osm-injector
OSM インジェクターが正常な場合は、次のような出力が表示されます。
NAME READY UP-TO-DATE AVAILABLE AGE
osm-injector 1/1 1 1 73m
OSM インジェクター ポッドを確認する
kubectl get pod -n arc-osm-system --selector app=osm-injector
OSM インジェクターが正常な場合は、次のような出力が表示されます。
NAME READY STATUS RESTARTS AGE
osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
READY 列は 1/1 である必要があります。 その他の値は、OSM インジェクター ポッドに異常があることを示します。
OSM インジェクター サービスを確認する
kubectl get service -n arc-osm-system osm-injector
OSM インジェクターが正常な場合は、次のような出力が表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
osm-injector ClusterIP 10.0.39.54 <none> 9090/TCP 75m
osm-injector サービス用にリストされている IP アドレスが 9090 であることを確認します。 EXTERNAL-IP はないはずです。
OSM インジェクターのエンドポイントを確認する
kubectl get endpoints -n arc-osm-system osm-injector
OSM インジェクターが正常な場合は、次のような出力が表示されます。
NAME ENDPOINTS AGE
osm-injector 10.240.1.172:9090 75m
OSM を機能させるには、osm-injector のエンドポイントが少なくとも 1 つ必要です。 OSM インジェクター エンドポイントの IP アドレスは異なりますが、ポート 9090 は同じである必要があります。
Validating と Mutating の Webhook を調べる
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Validating Webhook が正常な場合は、次のような出力が表示されます。
NAME WEBHOOKS AGE
osm-validator-mesh-osm 1 81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Mutating Webhook が正常な場合は、次のような出力が表示されます。
NAME WEBHOOKS AGE
arc-osm-webhook-osm 1 102m
次のコマンドを使用して、Validating Webhook のサービスと CA バンドルを確認します。
kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'
適切に構成された Validating Webhook 構成の出力は、次のようになります。
{
"name": "osm-config-validator",
"namespace": "arc-osm-system",
"path": "/validate",
"port": 9093
}
次のコマンドを使用して、Mutating Webhook のサービスと CA バンドルを確認します。
kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'
適切に構成された Mutating Webhook 構成の出力は、次のようになります。
{
"name": "osm-injector",
"namespace": "arc-osm-system",
"path": "/mutate-pod-creation",
"port": 9090
}
次のコマンドを使用して、OSM コントローラーによって Validating (または Mutating) Webhook に CA バンドルが提供されているかどうかを確認します。
kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c
kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c
出力例:
1845
出力のこの数値は、CA バンドルのバイト数またはサイズを示しています。 出力が空、0、または 1000 未満の数値である場合は、CA バンドルが正しくプロビジョニングされていません。 正しい CA バンドルがないと、ValidatingWebhook はエラーをスローします。
osm-mesh-config リソースを確認する
リソースの存在を確認します。
kubectl get meshconfig osm-mesh-config -n arc-osm-system
OSM MeshConfig の内容を確認します。
kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml
次のような出力が表示されます。
apiVersion: config.openservicemesh.io/v1alpha1
kind: MeshConfig
metadata:
creationTimestamp: "0000-00-00A00:00:00A"
generation: 1
name: osm-mesh-config
namespace: arc-osm-system
resourceVersion: "2494"
uid: 6c4d67f3-c241-4aeb-bf4f-b029b08faa31
spec:
certificate:
certKeyBitSize: 2048
serviceCertValidityDuration: 24h
featureFlags:
enableAsyncProxyServiceMapping: false
enableEgressPolicy: true
enableEnvoyActiveHealthChecks: false
enableIngressBackendPolicy: true
enableMulticlusterMode: false
enableRetryPolicy: false
enableSnapshotCacheMode: false
enableWASMStats: true
observability:
enableDebugServer: false
osmLogLevel: info
tracing:
enable: false
sidecar:
configResyncInterval: 0s
enablePrivilegedInitContainer: false
logLevel: error
resources: {}
traffic:
enableEgress: false
enablePermissiveTrafficPolicyMode: true
inboundExternalAuthorization:
enable: false
failureModeAllow: false
statPrefix: inboundExtAuthz
timeout: 1s
inboundPortExclusionList: []
outboundIPRangeExclusionList: []
outboundPortExclusionList: []
kind: List
metadata:
resourceVersion: ""
selfLink: ""
osm-mesh-config リソースの値は次のとおりです。
| キー | Type | 既定値 | Kubectl Patch コマンドの例 |
|---|---|---|---|
| spec.traffic.enableEgress | [bool] | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enableEgress":false}}}' --type=merge |
| spec.traffic.enablePermissiveTrafficPolicyMode | [bool] | true |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}' --type=merge |
| spec.traffic.outboundPortExclusionList | array | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge |
| spec.traffic.outboundIPRangeExclusionList | array | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundIPRangeExclusionList":["10.0.0.0/32","1.1.1.1/24"]}}}' --type=merge |
| spec.traffic.inboundPortExclusionList | array | [] |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge |
| spec.certificate.serviceCertValidityDuration | string | "24h" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"certificate":{"serviceCertValidityDuration":"24h"}}}' --type=merge |
| spec.observability.enableDebugServer | [bool] | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"enableDebugServer":false}}}' --type=merge |
| spec.observability.osmLogLevel | string | "info" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"osmLogLevel": "info"}}}}' --type=merge |
| spec.observability.tracing.enable | [bool] | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"enable":true}}}}' --type=merge |
| spec.sidecar.enablePrivilegedInitContainer | [bool] | false |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"enablePrivilegedInitContainer":true}}}' --type=merge |
| spec.sidecar.logLevel | string | "error" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"logLevel":"error"}}}' --type=merge |
| spec.featureFlags.enableWASMStats | bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableWASMStats":"true"}}}' --type=merge |
| spec.featureFlags.enableEgressPolicy | bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEgressPolicy":"true"}}}' --type=merge |
| spec.featureFlags.enableMulticlusterMode | bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableMulticlusterMode":"false"}}}' --type=merge |
| spec.featureFlags.enableSnapshotCacheMode | bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableSnapshotCacheMode":"false"}}}' --type=merge |
| spec.featureFlags.enableAsyncProxyServiceMapping | bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableAsyncProxyServiceMapping":"false"}}}' --type=merge |
| spec.featureFlags.enableIngressBackendPolicy | bool | "true" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableIngressBackendPolicy":"true"}}}' --type=merge |
| spec.featureFlags.enableEnvoyActiveHealthChecks | bool | "false" |
kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEnvoyActiveHealthChecks":"false"}}}' --type=merge |
名前空間を確認する
Note
arc-osm-system 名前空間は、サービス メッシュに参加することはありません。また、ここに示されているキーと値を使用してラベル付けされたり注釈を付けられたりすることもありません。
osm namespace add コマンドを使用して、特定のサービス メッシュに名前空間を参加させます。 Kubernetes 名前空間がメッシュの一部である場合は、次の手順に従って要件が満たされていることを確認します。
名前空間 bookbuyer の注釈を表示します。
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
次の注釈が存在する必要があります。
{
"openservicemesh.io/sidecar-injection": "enabled"
}
名前空間 bookbuyer のラベルを表示します。
kubectl get namespace bookbuyer -o json | jq '.metadata.labels'
次のラベルが存在する必要があります。
{
"openservicemesh.io/monitored-by": "osm"
}
osm CLI を使用していない場合は、これらの注釈を名前空間に手動で追加することもできます。 名前空間に "openservicemesh.io/sidecar-injection": "enabled" の注釈が付けられていない場合、または "openservicemesh.io/monitored-by": "osm" でラベル付けされていない場合、OSM インジェクターでは Envoy サイドカーは追加されません。
Note
osm namespace add を呼び出すと、新しいポッドのみに Envoy サイドカーが挿入されます。 kubectl rollout restart deployment コマンドを使用して既存のポッドを再起動する必要があります。
SMI CRD を確認する
次のコマンドを使用して、クラスターに必要なカスタム リソース定義 (CRD) があるかどうかを確認します。
kubectl get crds
CRD がリリース ブランチで使用可能なバージョンに対応していることを確認します。 使用中の CRD バージョンを確認するには、SMI でサポートされているバージョンのページにアクセスし、[リリース] ドロップダウンからバージョンを選択します。
次のコマンドを使用して、インストールされている CRD のバージョンを取得します。
for x in $(kubectl get crds --no-headers | awk '{print $1}' | grep 'smi-spec.io'); do
kubectl get crd $x -o json | jq -r '(.metadata.name, "----" , .spec.versions[].name, "\n")'
done
CRD がない場合は、次のコマンドを使用してクラスターにこれらをインストールします。 必要に応じて、これらのコマンドのバージョンを置き換えます (たとえば、v1.1.0 は release-v1.1 となります)。
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_http_route_group.yaml
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_tcp_route.yaml
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_access.yaml
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_split.yaml
リリース間の CRD の変更を確認するには、OSM のリリース ノートを参照してください。
証明書の管理のトラブルシューティングを行う
アプリケーション ポッドで実行されている Envoy プロキシに対する OSM による証明書の発行と管理方法については、OSM のドキュメント サイトを参照してください。
Envoy をアップグレードする
アドオンによって監視されている名前空間に新しいポッドが作成されると、OSM により、そのポッドに Envoy プロキシ サイドカーが挿入されます。 Envoy バージョンを更新する必要がある場合は、OSM のドキュメント サイトの「アップグレード ガイド」にある手順に従ってください。
次のステップ
- クラスター拡張機能の詳細情報。
- 一般的な Arc 対応 Kubernetes クラスターのトラブルシューティングのヒントを確認します。