Azure Arc 지원 Kubernetes 클러스터에 대한 확장 문제 해결

아티클
01/09/2025

이 문서에서는 Azure의 GitOps(Flux v2) 또는 OSM(Open Service Mesh)과 같은 클러스터 확장과 관련된 일반적인 문제에 대한 문제 해결 팁을 설명합니다.

일반적으로 Azure Arc 지원 Kubernetes 문제 해결에 대한 도움말은 Azure Arc 지원 Kubernetes 문제 해결을 참조하세요.

GitOps(Flux v2)

참고 항목

Flux v2 확장은 Azure Arc 지원 Kubernetes 클러스터 또는 AKS(Azure Kubernetes Service) 클러스터에서 사용할 수 있습니다. 이러한 문제 해결 팁은 일반적으로 모든 클러스터 유형에 적용됩니다.

리소스를 사용할 fluxConfigurations 때 문제 해결에 대한 일반적인 도움말을 보려면 매개 변수를 --debug 사용하여 다음 Azure CLI 명령을 실행합니다.

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

웹후크 건식 실행 오류

Flux가 실패하고 다음과 유사한 오류가 표시될 dry-run failed, error: admission webhook "<webhook>" does not support dry run수 있습니다. 문제를 ValidatingWebhookConfiguration MutatingWebhookConfiguration해결하려면 구성에서 값을 NoneOnDryRun>/에 None 대해 sideEffects 설정합니다.

자세한 내용은 어떻게 할까요? "webhook에서 실행이 지원되지 않음" 오류 해결을 참조하세요.

microsoft.flux 확장 설치 오류

확장은 microsoft.flux Azure Arc 지원 Kubernetes 클러스터 또는 AKS(Azure Kubernetes Service) 클러스터에 Flux 컨트롤러 및 Azure GitOps 에이전트를 설치합니다. 확장이 클러스터에 아직 설치되어 있지 않고 클러스터 에 대한 GitOps 구성 리소스 를 만드는 경우 확장이 자동으로 설치됩니다.

설치 중에 오류가 발생하거나 확장에 상태가 표시되는 Failed 경우 클러스터에 네임스페이스 또는 해당 네임스페이스의 리소스 만들기 flux-system 를 제한하는 정책이 없는지 확인합니다.

AKS 클러스터의 경우 Azure 구독에서 기능 플래그가 사용하도록 설정되어 있는지 확인 Microsoft.ContainerService/AKS-ExtensionManager 합니다.

az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager

다음으로, 다음 명령을 실행하여 다른 문제가 있는지 확인합니다. 클러스터 유형 매개 변수(-t) connectedClusters 를 Azure Arc 지원 클러스터의 경우 또는 managedClusters AKS 클러스터로 설정합니다. GitOps 구성을 만들 때 확장이 자동으로 설치된 경우 확장의 microsoft.flux 이름은 다음과 같습니다 flux.

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 릴리스를 제거합니다.
를 flux-system 실행 kubectl delete namespaces flux-system하여 클러스터에서 네임스페이스를 삭제합니다.

그런 다음 확장을 자동으로 설치하는 새 Flux 구성을 microsoft.flux 만들거나 Flux 확장을 수동으로 설치할 수 있습니다.

Microsoft Entra Pod 관리 ID가 있는 클러스터에 microsoft.flux 확장을 설치하는 동안 오류가 발생했습니다.

Microsoft Entra Pod 관리 ID가 있는 클러스터에 Flux 확장을 설치하려고 하면 Pod에서 extension-agent 오류가 발생할 수 있습니다. 결과는 다음 예제와 같은 모습입니다.

{"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}}\"}]}}",

이 경우 Pod는 클러스터의 extension-agent Azure Instance Metadata Service에서 해당 토큰을 가져오려고 하지만 토큰 요청은 Pod ID에 의해 가로채집니다. 이 문제를 해결하려면 최신 버전의 확장으로 업그레이드합니다 microsoft.flux .

microsoft.flux 확장을 설치하기 위한 메모리 및 CPU 리소스 요구 사항

확장을 설치할 때 Kubernetes 클러스터에 설치된 microsoft.flux 컨트롤러에는 Kubernetes 클러스터 노드에서 제대로 예약할 수 있는 충분한 CPU 및 메모리 리소스가 있어야 합니다. 클러스터가 최소 메모리 및 CPU 리소스 요구 사항을 충족하는지 확인합니다.

다음 표에서는 이 시나리오에 대한 잠재적인 CPU 및 메모리 리소스 요구 사항에 대한 최소 및 최대 제한을 나열합니다.

컨테이너 이름	최소 CPU	최소 메모리	최대 CPU	최대 메모리
`fluxconfig-agent`	5분	30Mi	50m	150Mi
`fluxconfig-controller`	5분	30Mi	100m	150Mi
`fluent-bit`	5분	30Mi	20분	150Mi
`helm-controller`	100m	64Mi	1,000 m	1Gi
`source-controller`	50m	64Mi	1,000 m	1Gi
`kustomize-controller`	100m	64Mi	1,000 m	1Gi
`notification-controller`	100m	64Mi	1,000 m	1Gi
`image-automation-controller`	100m	64Mi	1,000 m	1Gi
`image-reflector-controller`	100m	64Mi	1,000 m	1Gi

Kubernetes 클러스터의 컨테이너에 대한 리소스를 제한하는 사용자 지정 또는 기본 제공 Azure Policy Gatekeeper 정책을 사용하도록 설정한 경우 정책의 리소스 제한이 앞의 표에 표시된 제한보다 크거나 네임스페이 flux-system 스가 정책 할당의 매개 변수의 excludedNamespaces 일부인지 확인합니다. 이 시나리오에서 정책의 예는 다음과 같습니다 Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Flux v1

참고 항목

가능한 한 빨리 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 flux create <parameters> --debug

Azure Monitor Container Insights

이 섹션에서는 Azure Arc 지원 Kubernetes 클러스터용 Azure Monitor의 Container Insights 문제 해결에 대한 도움말을 제공합니다.

Canonical Charmed Kubernetes 클러스터에 대해 권한 있는 모드 사용

Azure Monitor Container Insights를 사용하려면 Kubernetes DaemonSet이 권한 있는 모드에서 실행되어야 합니다. 모니터링을 위해 Canonical Charmed Kubernetes 클러스터를 설정하려면 다음 명령을 실행합니다.

juju config kubernetes-worker allow-privileged=true

Oracle Linux 9.x에 AMA Pod를 설치할 수 없습니다.

Oracle Linux(RHEL(Red Hat Enterprise Linux)) 9.x Kubernetes 클러스터에 AMA(Azure Monitor Agent)를 설치하려고 하면 Pod의 컨테이너로 인해 addon-token-adapter AMA Pod 및 AMA-RS Pod가 제대로 작동하지 않을 수 있습니다. Podaddon-token-adapter container의 ama-logs-rs 로그를 확인하면 다음 예제와 유사한 출력이 표시됩니다.

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 배포판에 자동으로 로드되지 않기 때문에 발생합니다.

이 문제를 해결하려면 클러스터의 각 노드에서 모듈을 iptables_nat 명시적으로 로드해야 합니다. modprobe 명령을 sudo modprobe iptables_nat사용합니다. 각 노드에 로그인하고 iptable_nat 모듈을 수동으로 추가한 후 AMA 설치를 다시 시도합니다.

참고 항목

이 단계를 수행해도 iptables_nat 모듈이 영구화되지는 않습니다.

Azure Arc 지원 Open Service Mesh

이 섹션에서는 클러스터에서 OSM(Open Service Mesh) 확장 구성 요소 배포의 유효성을 검사하고 문제를 해결하는 데 사용할 수 있는 명령을 보여 줍니다.

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 컨트롤러 Pod 확인

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

한 컨트롤러의 Evicted 상태가 한 지점에서 있더라도 다른 컨트롤러는 상태를 1/1 가지 READY 며 Running 0 다시 시작됩니다. READY 상태가 다른 1/1상태이면 서비스 메시가 끊어진 상태입니다. 이 0/1경우 READY 컨트롤 플레인 컨테이너가 충돌합니다.

다음 명령을 사용하여 컨트롤러 로그를 검사합니다.

kubectl logs -n arc-osm-system -l app=osm-controller

READY 상태가 슬래시(/) 이후보다 1 큰 숫자인 경우 사이드카가 설치됩니다. 일반적으로 사이드카가 연결되면 OSM 컨트롤러가 제대로 작동하지 않습니다.

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

참고 항목

실제 값 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 경우 컨트롤 플레인은 비정상입니다. 이 비정상 상태는 컨트롤러 Pod가 충돌했거나 올바르게 배포되지 않은 것을 의미합니다.

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 인젝터 Pod 확인

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 인젝터 Pod를 나타냅니다.

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에 대해 엔드포인트가 하나 이상 있어야 합니다. OSM 인젝터 엔드포인트의 IP 주소는 다르지만 포트 값 9090 은 동일해야 합니다.

웹후크 확인: 유효성 검사 및 변경

다음 명령을 실행하여 유효성 검사 웹후크를 확인합니다.

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

유효성 검사 웹후크가 정상이면 다음 예제와 유사한 출력이 나타납니다.

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m

다음 명령을 실행하여 변경 웹후크를 확인합니다.

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

변경 웹후크가 정상이면 다음 예제와 유사한 출력이 나타납니다.

NAME                  WEBHOOKS   AGE
arc-osm-webhook-osm   1          102m

다음 명령을 사용하여 유효성 검사 웹후크의 서비스 및 CA 번들(CA 번들) 을 확인합니다.

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'

잘 구성된 유효성 검사 웹후크에는 다음 예제와 비슷한 출력이 있습니다.

{
  "name": "osm-config-validator",
  "namespace": "arc-osm-system",
  "path": "/validate",
  "port": 9093
}

다음 명령을 사용하여 변경 웹후크의 서비스 및 CA 번들을 확인합니다.

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'

잘 구성된 변경 웹후크에는 다음 예제와 비슷한 출력이 있습니다.

{
  "name": "osm-injector",
  "namespace": "arc-osm-system",
  "path": "/mutate-pod-creation",
  "port": 9090
}

OSM 컨트롤러가 다음 명령을 사용하여 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

예제 출력:

출력의 숫자는 바이트 수 또는 CA 번들의 크기를 나타냅니다. 출력이 비어 있거나, 0이거나, 1,000 미만인 경우 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	Default value	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`	배열	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge`
`spec.traffic.outboundIPRangeExclusionList`	배열	`[]`	`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`	배열	`[]`	`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`	부울	`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`	부울	`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`	부울	`"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`

네임스페이스 확인

참고 항목

네임스페이 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"
}

CLI를 사용하지 않는 경우 네임스페이 osm 스에 이러한 주석을 수동으로 추가할 수 있습니다. 네임스페이스에 주석이 추가 "openservicemesh.io/sidecar-injection": "enabled"되지 않았거나 레이블 "openservicemesh.io/monitored-by": "osm"이 지정되지 않은 경우 OSM 인젝터에서 Envoy 사이드카를 추가하지 않습니다.

참고 항목

osm namespace add를 호출한 후 새 Pod에는 Envoy 사이드카가 삽입됩니다. 명령을 사용하여 kubectl rollout restart deployment 기존 Pod를 다시 시작해야 합니다.

SMI CRD 확인

OSM SMI(서비스 메시 인터페이스)의 경우 클러스터에 필요한 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 릴리스 정보를 참조 하세요.

인증서 관리 문제 해결

OSM이 애플리케이션 Pod에서 실행되는 Envoy 프록시에 인증서를 발급하고 관리하는 방법에 대한 자세한 내용은 OSM 설명서를 참조 하세요.

Envoy 업그레이드

추가 기능으로 모니터링되는 네임스페이스에 새 Pod가 만들어지면 OSM은 해당 Pod에 Envoy 프록시 사이드카를 삽입합니다. Envoy 버전을 업데이트해야 하는 경우 OSM 설명서의 업그레이드 가이드 의 단계를 따릅니다.

클러스터 확장에 대해 자세히 알아봅니다.
Arc 지원 Kubernetes 클러스터에 대한 일반적인 문제 해결 팁을 확인합니다.

다음을 통해 공유

Azure Arc 지원 Kubernetes 클러스터에 대한 확장 문제 해결

GitOps(Flux v2)

웹후크 건식 실행 오류

microsoft.flux 확장 설치 오류

Microsoft Entra Pod 관리 ID가 있는 클러스터에 microsoft.flux 확장을 설치하는 동안 오류가 발생했습니다.

microsoft.flux 확장을 설치하기 위한 메모리 및 CPU 리소스 요구 사항

Flux v1

Azure Monitor Container Insights

Canonical Charmed Kubernetes 클러스터에 대해 권한 있는 모드 사용

Oracle Linux 9.x에 AMA Pod를 설치할 수 없습니다.

Azure Arc 지원 Open Service Mesh

OSM 컨트롤러 배포 확인

OSM 컨트롤러 Pod 확인

OSM 컨트롤러 서비스 확인

OSM 컨트롤러 엔드포인트 확인

OSM 인젝터 배포 확인

OSM 인젝터 Pod 확인

OSM 인젝터 서비스 확인

OSM 인젝터 엔드포인트 확인

웹후크 확인: 유효성 검사 및 변경

`osm-mesh-config` 리소스 확인

네임스페이스 확인

SMI CRD 확인

인증서 관리 문제 해결

Envoy 업그레이드

피드백

추가 리소스

다음을 통해 공유

Azure Arc 지원 Kubernetes 클러스터에 대한 확장 문제 해결

GitOps(Flux v2)

웹후크 건식 실행 오류

microsoft.flux 확장 설치 오류

Microsoft Entra Pod 관리 ID가 있는 클러스터에 microsoft.flux 확장을 설치하는 동안 오류가 발생했습니다.

microsoft.flux 확장을 설치하기 위한 메모리 및 CPU 리소스 요구 사항

Flux v1

Azure Monitor Container Insights

Canonical Charmed Kubernetes 클러스터에 대해 권한 있는 모드 사용

Oracle Linux 9.x에 AMA Pod를 설치할 수 없습니다.

Azure Arc 지원 Open Service Mesh

OSM 컨트롤러 배포 확인

OSM 컨트롤러 Pod 확인

OSM 컨트롤러 서비스 확인

OSM 컨트롤러 엔드포인트 확인

OSM 인젝터 배포 확인

OSM 인젝터 Pod 확인

OSM 인젝터 서비스 확인

OSM 인젝터 엔드포인트 확인

웹후크 확인: 유효성 검사 및 변경

osm-mesh-config 리소스 확인

네임스페이스 확인

SMI CRD 확인

인증서 관리 문제 해결

Envoy 업그레이드

관련 콘텐츠

피드백

추가 리소스

`osm-mesh-config` 리소스 확인