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
을 찾고 sideEffects
를 None
또는 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 flux 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/1
및 Running
라는 다른 컨트롤러가 있습니다. 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
는 다릅니다. 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 번들을 확인합니다.
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 문서 사이트의 업그레이드 가이드에 있는 단계를 수행합니다.
다음 단계
- 클러스터 확장에 대해 자세히 알아봅니다.
- Arc 지원 Kubernetes 클러스터에 대한 일반적인 문제 해결 팁을 확인합니다.