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

이 문서에서는 GitOps(Flux v2) 및 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을 찾고 sideEffectsNone 또는 NoneOnDryRun로 설정하여 문제를 해결할 수 있습니다.

자세한 내용은 webhook does not support dry run 오류를 어떻게 해결하나요?를 참조하세요.

microsoft.flux 확장 설치 오류

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

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

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

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

그런 다음, 이 명령을 실행하여 다른 문제가 있는지 확인합니다. 클러스터 형식(-t) 매개 변수를 Arc 지원 클러스터의 경우 connectedClusters로, AKS 클러스터의 경우 managedClusters로 설정할 수 있습니다. GitOps 구성을 만드는 동안 확장이 자동으로 설치된 경우 microsoft.flux 확장의 이름은 "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 네임스페이스 삭제

그런 후에 microsoft.flux 확장을 자동으로 설치하는 플럭스 구성을 다시 만들거나수동으로 플럭스 확장을 다시 설치할 수 있습니다.

Microsoft Entra Pod ID를 사용하도록 설정한 상태에서 클러스터에 microsoft.flux 확장을 설치하는 동안 오류 발생

Microsoft Entra Pod ID가 사용하도록 설정된 클러스터에 Flux 확장을 설치하려고 하면 확장 에이전트 Pod에서 오류가 발생할 수 있습니다.

{"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는 클러스터의 IMDS에서 해당 토큰을 가져오려고 시도합니다. 그러나 Pod ID가 토큰 요청을 가로챕니다. 이 문제를 해결하려면 microsoft.flux 확장의 최신 버전으로 업그레이드합니다.

AKS 클러스터에 microsoft.flux 확장을 설치할 때 kubelet ID와 관련된 문제 발생

AKS 클러스터를 사용할 때 인증 옵션 중 하나는 사용자 할당 관리 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분 30Mi 50m 150Mi
fluxconfig-controller 5분 30Mi 100m 150Mi
fluent-bit 5분 30Mi 20분 150Mi
helm-controller 100m 64Mi 1000m 1Gi
source-controller 50m 64Mi 1000m 1Gi
kustomize-controller 100m 64Mi 1000m 1Gi
notification-controller 100m 64Mi 1000m 1Gi
image-automation-controller 100m 64Mi 1000m 1Gi
image-reflector-controller 100m 64Mi 1000m 1Gi

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

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 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에 AMA(Azure Monitor 에이전트)를 설치할 수 없음

Oracle Linux(RHEL) 9.x Kubernetes 클러스터에 AMA(Azure Monitor 에이전트)를 설치하려고 하면 Pod의 addon-token-adapter 컨테이너로 인해 AMA Pod 및 AMA-RS Pod가 제대로 작동하지 않을 수 있습니다. 이 오류가 발생할 경우 ama-logs-rs Pod 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 설치를 다시 시도합니다.

참고 항목

이 단계를 수행해도 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

한 컨트롤러가 어느 시점에서 제거되었지만, 0이 다시 시작되어 READY 1/1Running라는 다른 컨트롤러가 있습니다. READY 열이 1/1이 아닌 경우 서비스 메시는 중단된 상태에 있게 됩니다. 0/1가 있는 열 READY은 컨트롤 플레인 컨테이너가 충돌함을 나타냅니다.

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

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

READY 열의 / 뒤에 1보다 큰 숫자가 있으면 사이드카가 설치되어 있는 것입니다. 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는 다릅니다. NAMEPORT(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 번들을 확인합니다.

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

예제 출력:

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 배열 [] 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 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

네임스페이스 확인

참고 항목

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 사이드카를 추가하지 않습니다.

참고 항목

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

SMI CRD 확인

다음 명령을 사용하여 클러스터에 필수 CRD(Custom Resource Definition)가 있는지 확인합니다.

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이 애플리케이션 포드에서 실행되는 Envoy 프록시에 대한 인증서를 발급하고 관리하는 방법에 대한 자세한 내용은 OSM 문서 사이트를 참조하세요.

Envoy 업그레이드

추가 항목에서 모니터링하는 네임스페이스에 새 Pod가 만들어지면 OSM은 해당 Pod에 Envoy 프록시 사이드카를 삽입합니다. Envoy 버전을 업데이트해야 하는 경우 OSM 문서 사이트의 업그레이드 가이드에 있는 단계를 수행합니다.

다음 단계