Anthos Service Mesh 1.11은 지원 종료되어 더 이상 지원되지 않습니다. 이전 버전에서 업그레이드를 참조하세요.

최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

사용 가능한 버전

관리형 Anthos Service Mesh 구성

개요

관리형 Anthos Service Mesh는 Google 관리 제어 영역이며, 간단히 구성할 수 있는 선택적 데이터 영역입니다. Google은 이전 버전과 호환되는 방식으로 안정성, 업그레이드, 확장, 보안을 처리합니다. 이 가이드에서는 단일 또는 멀티 클러스터 구성으로 애플리케이션을 설정하거나 관리형 Anthos Service Mesh로 마이그레이션하는 방법을 설명합니다.

관리형 Anthos Service Mesh의 지원되는 기능 및 제한사항은 관리형 Anthos Service Mesh 지원 기능을 참조하세요.

기본 요건

이 가이드에서는 사용자에게 다음이 이미 있다고 가정합니다.

Cloud 프로젝트
Cloud Billing 계정
필요한 도구 설치에 지정된 설치 스크립트, kpt 및 기타 도구

요구사항

지원되는 리전 중 하나에서 지원되는 GKE 버전이 있는 클러스터가 한 개 이상 있어야 합니다.
클러스터에 워크로드 아이덴티티가 사용 설정되어 있어야 합니다. gcloud 명령어는 워크로드 아이덴티티 사용 설정을 참조하세요.
이 페이지의 후반부에 설명된 것처럼 Google 관리 데이터 영역을 사용하려면 Google 관리 제어 영역을 배포할 때 Istio 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용 설정해야 합니다.

마이그레이션

클러스터 내 제어 영역에서 Google 관리 제어 영역으로의 직접 마이그레이션/업그레이드는 Mesh CA와 함께 설치된 버전 1.9+에서만 지원됩니다.
Istio CA를 사용하여 설치하려면 먼저 1.9+ Mesh CA로 마이그레이션해야 합니다.
간접 마이그레이션/업그레이드가 지원됩니다. 즉, 클러스터 내 제어 영역을 사용하는 Anthos Service Mesh 1.11에 도달할 때까지 각 버전을 통해 표준 Anthos Service Mesh 업그레이드 경로를 따른 후 Google 관리 제어 영역으로 마이그레이션할 수 있습니다.

제한사항

관리형 Anthos Service Mesh 지원 기능 및 제한사항 목록을 검토하는 것이 좋습니다. 특히 다음 사항에 유의하세요.

관리형 Anthos Service Mesh는 단일 Google Cloud 프로젝트에서만 여러 GKE 클러스터를 사용할 수 있습니다.
IstioOperator API는 지원되지 않습니다.
관리형 데이터 영역의 제한사항은 다음과 같습니다.
- 관리형 데이터 영역의 이 미리보기 출시는 관리형 제어 영역의 새로운 배포에만 사용할 수 있습니다. 이전에 관리형 제어 영역을 배포했고 관리형 데이터 영역을 배포하려는 경우 Google 관리 제어 영역 적용에 설명된 대로 설치 스크립트를 다시 실행해야 합니다.
- 관리형 날짜 범위는 일반 및 빠른 출시 채널에서 사용할 수 있습니다.

워크로드 아이덴티티 사용 설정

워크로드 아이덴티티가 사용 설정되어 있지 않은 경우 사용 설정하는 데 필요한 IAM 권한과 gcloud CLI는 클러스터에서 워크로드 아이덴티티 사용 설정을 참조하세요.

설치 스크립트 다운로드

Anthos Service Mesh 1.11.8를 현재 작업 디렉터리에 설치하는 최신 스크립트 버전을 다운로드합니다.
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
스크립트를 실행 가능하게 만듭니다.
```
chmod +x install_asm
```

각 클러스터 구성

메시의 각 클러스터에 관리형 Anthos Service Mesh를 구성하려면 다음 단계를 수행합니다.

클러스터 사용자 인증 정보 가져오기

적절한 사용자 인증 정보를 검색합니다. 또한 다음 명령어는 kubectl 컨텍스트를 대상 클러스터에 연결합니다.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Google 관리 제어 영역 적용

관리형 Anthos Service Mesh를 사용할 각 클러스터에 대해 install_asm 설치 스크립트를 실행합니다. install_asm을 실행할 때 다음 옵션을 모두 포함하는 것이 좋습니다.

--option cni-managed: 이 옵션은 Istio 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용 설정합니다. CNI 플러그인은 높은 권한의 init 컨테이너를 사용하는 대신 CNCF CNI 인터페이스를 사용하여 사이드카 프록시와의 네트워크 트래픽 리디렉션을 구성합니다.
--enable-registration: 이 플래그는 클러스터를 Fleet에 등록합니다.

이러한 옵션은 Google 관리 데이터 영역을 배포하려는 경우에도 필요합니다. 전체 옵션 목록은 asmcli 참조 페이지를 확인하세요.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

이 스크립트는 istioctl 도구 및 샘플 애플리케이션과 함께 관리 제어 영역을 구성하고 Istio 게이트웨이를 설치하기 위해 지정된 --output_dir에 모든 파일을 다운로드합니다. 이 가이드의 단계에서는 /bin 하위 디렉터리에 istioctl이 있는 상태로 설치 디렉터리의 루트에서 istioctl을 실행한다고 가정합니다.

동일한 클러스터에서 install_asm을 다시 실행하면 기존 제어 영역 구성을 덮어씁니다. 동일한 구성을 원하는 경우 동일한 옵션 및 플래그를 지정해야 합니다.

인그레스 게이트웨이는 제어 영역과 함께 자동으로 배포되지 않습니다. 인그레스 게이트웨이와 제어 영역의 배포를 분리하면 프로덕션 환경에서 게이트웨이를 보다 쉽게 관리할 수 있습니다. 클러스터에 인그레스 게이트웨이가 필요한 경우 Istio 게이트웨이 설치를 참조하세요.

Google 관리형 데이터 영역 적용

Google에서 프록시 업그레이드를 관리하도록 하려면 Google 관리 데이터 영역을 사용 설정합니다. 사용 설정하면 사이드카 프록시와 삽입된 게이트웨이가 관리형 제어 영역과 함께 자동으로 업그레이드됩니다.

기능 미리보기에서 관리형 데이터 영역은 이전 버전의 프록시를 실행하는 포드를 삭제하여 프록시를 업그레이드합니다. 제거는 포드 중단 예산을 준수하고 변경 속도를 제어하는 방식으로 순서대로 수행됩니다.

관리형 데이터 영역의 미리보기 출시 버전에서는 다음을 관리하지 않습니다.

삽입되지 않은 포드
istioctl kube-inject를 사용하여 수동으로 삽입된 포드
작업
스테이트풀(Stateful) 세트
DaemonSet

관리형 데이터 영역을 사용하지 않거나 모든 네임스페이스에 사용 설정하지 않으려는 경우 최신 프록시 이미지를 활용하려면 프록시 다시 시작을 트리거해야 합니다. 제어 영역은 기존 프록시에서 계속 작동합니다.

관리형 데이터 영역은 신속 및 일반 출시 채널에서 사용할 수 있습니다.

Google 관리 데이터 영역을 사용 설정하려면 다음 안내를 따르세요.

데이터 영역 관리를 사용 설정합니다.
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
또는 동일한 주석을 달아 특정 포드에 Google 관리 데이터 영역을 사용 설정할 수 있습니다. 특정 포드에 주석을 추가하면 이 포드는 Google 관리 사이드카 프록시를 사용하고 나머지 워크로드는 비관리형 사이드카 프록시를 사용합니다.
관리형 데이터 영역을 설정하려는 각 네임스페이스에 이전 단계를 반복합니다.

Fleet에서 Anthos Service Mesh를 사용 설정합니다.

gcloud alpha container hub mesh enable --project=PROJECT_ID

데이터 영역 컨트롤러가 클러스터의 프록시를 관리할 때까지 최대 10분이 걸릴 수 있습니다. 다음 명령어를 실행하여 상태를 확인합니다.

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

데이터 영역 컨트롤러가 준비되면 명령어가 Managed Data Plane is ready.를 출력합니다.

10분이 지난 후에도 데이터 영역 컨트롤러의 상태가 준비되지 않으면 관리형 데이터 영역 상태에서 문제 해결 팁을 참조하세요.

Google 관리 데이터 영역을 사용 중지하고 사이드카 프록시를 직접 관리하도록 되돌리려면 주석을 변경합니다.

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Istio 게이트웨이 설치(선택사항)

Anthos Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.

게이트웨이에 대해 별도의 네임스페이스를 만드는 것이 좋습니다. istio-system 네임스페이스에 게이트웨이를 배포하지 마세요.

다음 단계에 따라 클러스터에 하나 이상의 Istio 게이트웨이를 설치하여 일반적인 인그레스 트래픽을 처리할 수 있습니다.

이 두 가지 옵션 중 하나를 선택하여 후반부 단계에서 게이트웨이를 배포할 네임스페이스를 설정합니다.
- 네임스페이스의 삽입을 사용 설정합니다.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
```
또는
- 네임스페이스의 모든 pod가 아니라 게이트웨이의 pod만 삽입되도록 사용 설정합니다. 이 명령어는 모든 삽입 라벨을 삭제하고 이후에 pod 자체에서 삽입을 사용 설정합니다.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
```

다음의 간단한 예시를 사용하여 게이트웨이의 배포 및 서비스를 만듭니다.

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

배포를 만든 후에 새 서비스가 올바르게 작동하는지 확인합니다.

kubectl get pod,service -n GATEWAY_NAMESPACE

다음과 유사한 출력이 표시되는지 확인합니다.

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

관리형 데이터 영역 컨트롤러가 서비스를 관리하는 것처럼 게이트웨이의 프록시를 관리하도록 할 수 있습니다. 관리형 데이터 영역을 배포하고 게이트웨이 프록시를 관리하려는 경우 Google 관리 데이터 영역 적용에 설명된 대로 게이트웨이 네임스페이스에 라벨을 지정하고 주석을 추가합니다.

게이트웨이를 직접 관리하려면 새 버전의 Anthos Service Mesh가 출시될 때 GATEWAY_NAMESPACE에서 포드를 다시 시작하여 새 제어 영역을 선택하도록 해야 합니다. 포드를 다시 시작하기 전에 제어 영역 측정항목 확인에 제공된 측정항목 탐색기 커스텀 쿼리를 사용하여 제어 영역 버전을 확인하여 새 제어 영역이 클러스터에 출시되었는지 확인해야 합니다.

엔드포인트 검색 구성(멀티 클러스터 설치만 해당)

Anthos Service Mesh 관리 제어 영역은 단일 프로젝트, 단일 네트워크, 다중 기본 구성을 지원하며, 제어 영역이 클러스터에 설치되지 않는다는 것이 다릅니다.

계속하기 전에 이전 단계에 설명된 대로 각 클러스터에서 이미 설치 스크립트를 실행한 상태여야 합니다. 기본 동작이므로 클러스터가 기본 클러스터임을 나타낼 필요는 없습니다.

모든 클러스터에 대해 메시에서 다른 클러스터 i=1..N에 한 번씩 다음 명령어를 실행하여 엔드포인트 검색을 사용 설정합니다.

모든 클러스터에서 kubectl 구성 컨텍스트가 현재 클러스터를 가리키는지 확인합니다.
```
export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
```

메시에서 모든 다른 클러스터 i=1..N에 대해 한 번씩 다음 명령어를 실행하여 엔드포인트 검색을 사용 설정합니다.

export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

다음 명령어를 실행하여 보안 비밀이 생성되었는지 확인합니다.

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

예상 출력을 확인합니다.

NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

현재 클러스터가 기존 멀티 클러스터 메시에 추가되는 경우, 다른 모든 클러스터에서 현재 클러스터에 따라 보안 비밀을 만들어서 다른 모든 클러스터가 해당 엔드포인트를 검색할 수 있게 해줍니다.
```
./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}
```

또한 다른 클러스터에 대해서도 보안 비밀을 확인할 수 있습니다.

kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

예상 출력을 확인합니다.

NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

자세한 내용 및 2개 클러스터가 포함된 예시는 엔드포인트 검색 사용 설정을 참조하세요.

애플리케이션 배포

애플리케이션을 배포하기 전 해당 네임스페이스에서 모든 이전 istio-injection 라벨을 삭제하고 대신 istio.io/rev:asm-managed-rapid 라벨을 설정합니다.

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

이제 Anthos Service Mesh 관리 제어 영역이 성공적으로 구성되었습니다. 이제 애플리케이션을 배포할 준비가 되었습니다. 또는 Bookinfo 샘플 애플리케이션을 배포할 수 있습니다.

멀티 클러스터 설정으로 애플리케이션을 배포할 경우 특정 구성을 클러스터 하위 집합으로 제한할 계획이 아닌 한 모든 클러스터에서 Kubernetes 및 제어 영역 구성을 복제합니다. 특정 클러스터에 적용되는 구성은 해당 클러스터에 대한 정보 소스입니다. 또한 클러스터가 다른 네임스페이스에 있는 메시 CA와 함께 Anthos Service Mesh 1.7, 1.8 이상을 실행하는 경우, 애플리케이션이 클러스터 내 제어 영역으로 제어되는 다른 애플리케이션과 통신할 수 있는지 확인합니다.

제어 영역 측정항목 확인

측정항목 탐색기에서 제어 영역과 데이터 영역의 버전을 볼 수 있습니다.

구성이 제대로 작동하는지 확인하려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 제어 영역 측정항목을 열람하세요.

측정항목 탐색기로 이동
작업공간을 선택하고 다음 매개변수를 사용하여 커스텀 쿼리를 추가합니다.
- 리소스 유형: Kubernetes 컨테이너
- 측정항목: 프록시 클라이언트
- 필터: container_name="cr-asm-managed-rapid"
- 그룹화 기준: 버전 라벨 및 proxy_version 라벨
- 애그리게이터 합계
- 기간: 1분
Google 관리형 및 클러스터 내 제어 영역을 모두 사용해서 Anthos Service Mesh를 실행할 때는 측정항목을 해당 컨테이너 이름과 구분할 수 있습니다. 예를 들어 관리형 측정항목은 container_name="cr-asm-managed"를 포함하고 비관리형 측정항목은 container_name="discovery"를 포함합니다. 두 가지 측정항목을 모두 표시하려면 container_name="cr-asm-managed"에 대한 필터를 삭제합니다.
측정항목 탐색기에서 다음 필드를 검사하여 제어 영역 버전과 프록시 버전을 확인합니다.
- revision 필드는 제어 영역 버전을 나타냅니다.
- proxy_version 필드는 proxy_version을 나타냅니다.
- value 필드는 연결된 프록시 수를 나타냅니다.
현재 채널에서 Anthos Service Mesh로의 버전 매핑은 채널별 Anthos Service Mesh 버전을 참조하세요.

관리형 Anthos Service Mesh로 애플리케이션 마이그레이션

관리형 Anthos Service Mesh는 메시 CA를 사용하는 Anthos Service Mesh 1.9에서의 마이그레이션만 지원합니다.

관리형 Anthos Service Mesh로 마이그레이션하려면 다음 단계를 수행합니다.

Google 관리 제어 영역 적용 섹션에 설명된 대로 스크립트를 실행합니다.
Google 관리 제어 영역과 데이터 영역을 모두 배포한 경우 다음을 수행합니다.
1. 데이터 영역 관리를 사용 설정합니다.
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
2. Fleet에서 Anthos Service Mesh를 사용 설정합니다.
```
gcloud alpha container hub mesh enable --project=PROJECT_ID
```

현재 네임스페이스 라벨을 istio.io/rev:asm-managed-rapid 라벨로 바꿉니다.

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --overwrite

네임스페이스에서 배포를 순차적으로 업그레이드합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 각 네임스페이스에 이전 단계를 반복합니다.
멀티 클러스터 설정에서 애플리케이션을 배포한 경우 구성을 클러스터 하위 집합으로 제한하려는 경우를 제외하고 모든 클러스터에서 Kubernetes 및 Istio 구성을 복제합니다. 특정 클러스터에 적용되는 구성은 해당 클러스터에 대한 정보 소스입니다.
제어 영역 측정항목 확인의 단계를 수행하여 측정항목이 예상한 대로 표시되는지 확인합니다.

클러스터는 혼합된 버전을 포함할 수 있습니다. 예를 들어 Anthos Service Mesh 1.7 및 1.8과 클러스터 내 제어 영역을 함께 사용할 수 있습니다. 제한 없이 서로 다른 Anthos Service Mesh 제어 영역 버전을 사용하여 네임스페이스를 혼합할 수 있습니다.

애플리케이션이 예상한 대로 작동하면 모든 네임스페이스를 클러스터 내 제어 영역으로 전환한 후 클러스터 내 istiod를 삭제하거나 이를 백업으로 보존할 수 있습니다. istiod는 더 적은 리소스를 사용하도록 자동으로 축소됩니다. 삭제하려면 이전 제어 영역 삭제로 건너뜁니다.

문제가 발생하면 관리 제어 영역 문제 해결의 정보에 따라 식별하고 해결할 수 있고, 필요한 경우 이전 버전으로 롤백할 수 있습니다.

이전 제어 영역 삭제

설치를 수행하고 모든 네임스페이스에 Google 관리형 제어 영역이 사용되는지 확인한 후 이전 제어 영역을 삭제할 수 있습니다.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

자동 삽입 대신 istioctl kube-inject를 사용한 경우 또는 추가적인 게이트웨이를 설치한 경우, 제어 영역에 대해 측정항목을 확인하고 연결된 엔드포인트 수가 0인지 확인합니다.

롤백

이전 제어 영역 버전으로 롤백해야 할 경우 다음 단계를 수행합니다.

제어 영역의 이전 버전에 삽입할 워크로드를 업데이트합니다. 다음 명령어에서 버전 값 asm-191-1은 예시로만 사용되었습니다. 예시 값을 이전 제어 영역의 버전 라벨로 바꾸세요.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```

관리형 제어 영역이 자동으로 0으로 축소되고 사용 중이 아닐 때는 리소스를 사용하지 않습니다. 변형 웹훅 및 프로비저닝은 그대로 유지되고 클러스터 동작에 영향을 주지 않습니다.

이제 게이트웨이가 asm-managed 버전으로 설정되었습니다. 롤백하려면 Anthos Service Mesh install 명령어를 다시 실행합니다. 그러면 클러스터 내 제어 영역을 다시 가리키는 게이트웨이가 다시 배포됩니다.

kubectl -n istio-system rollout undo deploy istio-ingressgateway

성공하면 다음 출력이 표시됩니다.

deployment.apps/istio-ingressgateway rolled back

Google 관리 제어 영역으로 게이트웨이 마이그레이션

문서를 사용하여 새 버전의 게이트웨이에 대해 Kubernetes 배포를 만듭니다. 서비스 구성에서 selector 필드를 사용하여 이전 버전 및 새 버전을 모두 선택하도록 기존 Kubernetes 게이트웨이 서비스를 구성해야 합니다.
이러한 kubectl scale 명령어를 사용하여 새 배포를 점진적으로 수직 확장하고, 그러면서 이전 배포를 축소하고 서비스 중단/다운타임 증상을 확인합니다. 마이그레이션이 성공하면 서비스 중단 없이 이전 인스턴스 수가 0에 도달해야 합니다.

제거

Google 관리 제어 영역은 이를 사용하는 네임스페이스가 없을 때 0으로 자동 축소됩니다. 따라 설치를 제거할 필요가 없습니다.

문제 해결

관리형 제어 영역을 사용할 때의 문제를 식별하고 해결하려면 관리형 제어 영역 문제 해결을 참조하세요.

다음 단계

출시 채널 알아보기