Azure Arc 지원 Kubernetes를 사용하는 CI/CD 및 GitOps 분야

클라우드 네이티브 구문인 Kubernetes에는 배포 및 작업에 대한 클라우드 네이티브 접근 방식이 필요합니다. GitOps를 사용하여 Git 리포지토리에 저장된 파일에서 원하는 애플리케이션 기반 배포 상태를 선언합니다. 애플리케이션에는 실행해야 하는 Kubernetes 개체가 있으며 배포, Horizontal-Pod-Autoscalers, 서비스, ConfigMaps를 포함할 수 있습니다. Kubernetes 연산자는 클러스터에서 실행되며 Git 리포지토리에서 선언된 원하는 상태와 각 클러스터의 상태를 지속적으로 조정합니다. 이러한 연산자는 Git 리포지토리에서 파일을 가져와서 원하는 상태를 클러스터에 적용합니다. 또한 연산자는 클러스터가 원하는 상태로 유지되도록 지속적으로 보장합니다.

GitOps를 구현하면 다음을 수행할 수 있습니다.

• Kubernetes 클러스터 상태 및 구성의 전반적인 가시성을 향상시킵니다.
• 변경한 사용자, 변경한 시기 및 그 이유를 보여 주는 Git 변경 기록을 통해 클러스터 변경 내용에 대한 간단한 감사 및 버전 기록을 확인합니다.
• 클러스터에 발생할 수 있는 드리프트를 자동으로 수정합니다.
• Git 되돌리기 또는 Git 롤백 명령을 통해 Kubernetes 구성을 이전 버전으로 롤백합니다. 재해 복구 시나리오에 대한 클러스터 배포 다시 만들기는 Kubernetes에서 원하는 클러스터 구성이 Git에 저장되기 때문에 빠르고 간단한 프로세스가 됩니다.
• 클러스터 배포 권한을 갖는 데 필요한 서비스 계정 수를 줄여 보안을 개선합니다.
• 클러스터에 애플리케이션을 배포하기 위한 CI/CD 파이프라인을 구현합니다.

Azure Arc 지원 Kubernetes의 GitOps는 인기 있는 오픈 소스 도구 집합인 Flux를 구현하는 확장을 사용합니다. Flux는 클러스터에서 GitOps 구성 배포를 자동화하는 연산자입니다. Flux는 일반적인 파일 원본(Git 리포지토리, Helm 리포지토리, 버킷) 및 템플릿 형식(YAML, Helm 및 Kustomize)을 지원합니다. Flux는 다른 기능 간에 다중 테넌트 및 배포 종속성 관리도 지원합니다.

아키텍처

다음 다이어그램에서는 클러스터의 Flux 클러스터 확장 설치 프로비저닝, Azure Arc 지원 Kubernetes 클러스터에 대한 GitOps 구성 프로세스, GitOps 흐름을 강조 표시하는 개념 참조 아키텍처를 보여 줍니다.

Flux v2 클러스터 확장 프로비저닝 프로세스:

GitOps 구성 프로세스:

애플리케이션 업데이트를 보여 주는 GitOps 흐름:

디자인 고려 사항

Azure Arc 지원 Kubernetes용 GitOps 구현을 계획할 때 다음 디자인 고려 사항을 검토합니다.

구성

Kubernetes 클러스터의 다양한 구성 계층과 이를 프로비저닝하는 것과 관련된 책임을 고려합니다.

구성 계층

• 배포, 서비스, HPA 및 ConfigMap 리소스와 같은 애플리케이션 및 관련 Kubernetes 개체를 클러스터에 배포하려면 애플리케이션 구성이 필요합니다. 애플리케이션 구성은 일반적으로 네임스페이스 수준 GitOps 구성에 적용되며 애플리케이션 구성 요소는 단일 네임스페이스 내에서만 구성되어야 합니다.
• Namespaces, ServiceAccounts, Roles 및 RoleBindings, 기타 클러스터 전체 정책과 같은 Kubernetes 개체 만들기를 위한 클러스터 전체 구성입니다.
• 수신 컨트롤러, 모니터링 및 보안 스택, 클러스터 전체에서 작동하는 다양한 에이전트와 같은 클러스터 전체 구성 요소입니다.

담당 작업

• 애플리케이션 개발자는 소스 코드를 푸시하고, 빌드를 트리거하고, 컨테이너 이미지를 만들 책임이 있습니다.
• 애플리케이션 운영자는 애플리케이션 리포지토리, 구성, 환경 변수, 앱별 helm 차트, Kustomizations 등을 유지 관리할 책임이 있습니다.
  • Azure CLI를 사용하여 Flux 구성 적용
  • Flux2 helm 및 kustomize 예
• 클러스터 운영자는 클러스터 기준 설정을 담당합니다. 일반적으로 클러스터 전체의 구성 요소 및 정책을 설정하는 데 관심이 있습니다. 네임스페이스, 서비스 계정, RoleBindings, CRD, 클러스터 전체 정책, 수신 구성 요소 등과 같은 공통 인프라 도구가 포함된 Git 리포지토리 디렉터리 또는 디렉터리를 유지 관리합니다.

리포지토리 구조

Git 리포지토리 구조를 선택할 때 절충을 고려합니다. 선택한 구조는 애플리케이션 및 클러스터 전체 구성 요소를 포함하는 Kubernetes 클러스터 상태를 정의합니다. 식별하는 책임과 페르소나에 따라 다양한 리포지토리 구조 옵션에 필요한 협업 또는 원하는 팀 독립성을 고려하는 것이 중요합니다.

CI(연속 통합) 프로세스에서만 사용하기 때문에 코드 리포지토리에 대해 원하는 분기 전략을 사용할 수 있습니다.

GitOps 구성 리포지토리의 경우 조직의 비즈니스 요구 사항, 규모 및 도구에 따라 다음 전략을 고려합니다.

• 단일 리포지토리(환경별 분기):
  • 환경을 나타내는 각 분기에 대한 Git 정책 및 권한을 제어하는 데 가장 유연합니다.
  • 단점은 Kustomize와 같은 도구가 Git 분기와 작동하지 않기 때문에 환경 간에 공통 구성을 공유할 수 없다는 것입니다.
• 단일 리포지토리(환경별 디렉터리):
  • Kustomize와 같은 도구를 사용하여 이 방법을 구현할 수 있습니다. 이를 통해 Kubernetes 개체에 대한 기본 구성과 기본 구성을 재정의하는 환경에 대한 아티팩트 집합(예: 패치)을 정의할 수 있습니다.
  • 이 방법은 각 환경에 대한 중복 YAML 파일을 줄일 수 있지만 환경 간의 구성 분리도 줄일 수 있습니다. 리포지토리를 한 번만 변경하면 모든 환경에서 한 번에 영향을 미칠 수 있으므로 기본 디렉터리 변경의 영향을 완전히 이해하고 주의해야 합니다.
• 여러 리포지토리(각각 특정 용도로 사용):
  • 이는 각 애플리케이션, 팀, 계층 또는 테넌트에 대한 구성 리포지토리를 분리하는 데 사용할 수 있습니다.
  • 이를 통해 팀은 보다 독립적으로 제어할 수 있지만 단일 리포지토리에서 시스템 상태를 정의하는 원칙에서 벗어나 클러스터에 대한 배포의 중앙 구성, 표시 유형 및 제어를 개선할 수 있습니다.
  • 다중 테넌트 요구 사항을 위해 여러 리포지토리 설정을 고려해야 합니다. 특정 리포지토리에 할당된 팀/테넌트가 적용할 수 있는 구성(예: 특정 네임스페이스에만 배포 허용)을 제한하기 위해 RBAC(역할 기반 액세스 제어) 및 보안이 기본 제공되어 있습니다.

Flux 가이드에서 리포지토리를 구성하는 더 많은 방법을 참조하세요.

애플리케이션 및 플랫폼 구성

플랫폼 운영자 및 애플리케이션 운영자에게는 Kubernetes 구성을 관리하기 위한 몇 가지 옵션이 있습니다.

• 배포하는 각 Kubernetes API 개체의 YAML 사양을 나타내는 원시 Kubernetes YAML 파일은 단일 환경에서 잘 작동할 수 있습니다. 원시 YAML 파일을 사용할 때의 단점은 YAML 파일을 복제해야 하고 재사용 방법이 좋지 않기 때문에 여러 환경을 통합하기 시작할 때 사용자 지정이 어려워진다는 것입니다.
• Helm은 Kubernetes 개체용 패키지 관리 도구입니다. 클러스터 운영자가 타사 상용 애플리케이션을 설치하는 데 사용할 수 있는 유효한 옵션입니다. 템플릿이 커짐에 따라 관리하기가 복잡해질 수 있으므로 내부 애플리케이션용 구성 관리 도구로 템플릿을 너무 많이 사용하지 않도록 합니다.
  • Helm을 사용하는 경우 Flux에는 Kubernetes 매니페스트를 사용하여 Helm 차트 릴리스를 선언적으로 관리할 수 있는 Helm 컨트롤러가 포함되어 있습니다. HelmRelease 개체를 만들어 해당 프로세스를 관리할 수 있습니다.
• Kustomize는 템플릿 없는 방식을 도입하여 애플리케이션 구성을 사용자 지정하는 Kubernetes 네이티브 구성 관리 도구입니다.
  • Kustomize를 사용하는 경우 Flux에는 Kubernetes 매니페스트로 정의되고 Kustomize로 어셈블된 인프라 및 워크로드의 지속적인 배달 파이프라인을 실행하는 것을 전문으로 하는 Kustomize 컨트롤러가 포함되어 있습니다. Kustomization 개체를 만들어 해당 프로세스를 관리할 수 있습니다.
• Azure Arc 지원 Kubernetes를 사용하면 구성 요소의 수명 주기 및 지원을 직접 관리할 필요 없이 Microsoft에서 관리하고 지원하는 사용 가능한 확장 목록을 사용할 수 있습니다. 이러한 확장은 Azure Resource Manager를 통해 관리됩니다. 이러한 확장 중 일부에는 Azure Key Vault 비밀 공급자와 같은 오픈 소스 대안이 있습니다. 확장 프로세스 외부에서 구성 요소를 관리하면 구성 요소를 보다 효과적으로 제어할 수 있지만 지원 및 수명 주기 관리를 위해 더 많은 오버헤드가 필요합니다.

연속 통합 및 지속적인 업데이트(CI/CD) 흐름

다음 섹션에서는 애플리케이션 파이프라인 및 구성 요소 업데이트 프로세스에 대한 고려 사항을 제공합니다.

애플리케이션 파이프라인

• CI 프로세스에 포함해야 하는 애플리케이션 빌드, 테스트, 유효성 검사를 고려합니다. 여기에는 환경 배포를 위한 RC(릴리스 후보)를 만드는 데 필요한 보안, 통합, 성능과 관련된 린팅 및 테스트가 포함될 수 있습니다.
• 기존 푸시 배포 방법을 사용하여 배포 파이프라인에서 Kubernetes API를 직접 호출한 후 CI 파이프라인의 빌드 컨테이너 이미지와 클러스터의 배포 간의 격차를 해소할 수 있습니다.

GitOps 리포지토리에 대한 수동 구성 수정을 방지하려면 CD 파이프라인을 서비스 계정으로 실행하여 PR(끌어오기 요청)을 열거나 새 컨테이너 이미지 변경을 구성 리포지토리에 직접 커밋하면 됩니다. 이러한 변경 내용은 애플리케이션에 필요한 모든 YAML 개체를 프로비전할 수도 있습니다.

다음 프로세스 다이어그램에서는 GitOps를 지원하는 변경 내용과 통합된 기존 애플리케이션 CI 프로세스를 보여 줍니다.

클러스터 전체 구성 요소 업데이트 프로세스

• 클러스터 운영자는 클러스터 전체 구성 요소를 관리해야 하므로 애플리케이션 및 서비스를 배포하는 데 사용되는 CD 파이프라인에서 시작되지 않을 수 있습니다. 변경 내용이 한 환경에서 다른 환경으로 원활하게 전환할 수 있도록 클러스터 운영자와 관련된 승격 프로세스를 정의하는 것이 좋습니다.
• Azure Arc 지원 Kubernetes 클러스터에 대규모로 동일한 GitOps 구성을 적용해야 하는 경우 Flux 확장을 자동으로 설치하고 GitOps 구성을 기존 Azure Arc 지원 Kubernetes 클러스터 또는 Azure Arc에 온보딩된 새 클러스터에 적용할 수 있는 Azure Policy를 적용하는 것이 좋습니다.

구성을 업데이트할 때 변경 내용이 원하는 환경에 적용되었는지 확인할 수 있습니다. Flux에서 알림을 정의하여 CI/CD 도구, 메일 또는 ChatOps 도구와 통합하고 변경 및 배포 실패에 대한 경고를 자동으로 보낼 수 있습니다. 또한 Azure Portal에서 k8s 구성 CLI 및 ARM API를 통해 배포 상태 정보를 찾을 수 있습니다.

보안 고려 사항

Azure Arc 지원 Kubernetes용 GitOps 구현을 계획할 때 다음 보안 고려 사항을 검토합니다.

리포지토리 인증

• GitOps에서 퍼블릭 또는 프라이빗 Git 리포지토리를 사용할 수 있지만 Kubernetes 구성의 중요한 특성으로 인해 SSH 키 또는 API 키로 인증해야 하는 프라이빗 리포지토리를 사용하는 것이 좋습니다. 또한 GitOps는 Kubernetes 클러스터가 액세스할 수 있는 한 프라이빗 네트워크 내에서만 액세스할 수 있는 Git 리포지토리와 함께 작동하지만, 이 설정은 Azure Repos 또는 GitHub와 같은 클라우드 기반 Git 공급자를 사용하는 기능을 제한합니다.
• HTTPS 및 SSH 프로토콜은 원본 제어 도구에 연결하는 데 사용할 수 있는 안정적이고 안전한 연결을 제공합니다. 그러나 HTTPS는 설정하기 쉬운 경우가 더 많으며 방화벽에서 추가 포트를 열 필요가 거의 없는 포트를 사용합니다.

리포지토리 및 분기 보안

• 구성 리포지토리에 대한 분기 권한 및 정책을 설정합니다. Git 리포지토리가 Kubernetes 배포의 중심 부분이 되므로 분기에서 코드를 읽고 업데이트할 수 있는 사용자를 제어할 수 있는 권한을 설정하고 팀의 코드 품질 및 변경 관리를 적용하는 정책을 구현하는 것이 중요합니다. 그렇지 않으면 GitOps 워크플로가 조직의 표준에 맞지 않는 코드를 제공할 수 있습니다.
• PR(끌어오기 요청) 파이프라인은 분기 정책과 함께 작동하여 YAML 구성의 유효성을 검사하거나 필요에 따라 테스트 환경을 배포할 수 있습니다. 게이트는 구성 오류를 제거하고 배포 보안 및 신뢰를 높이는 데 도움이 됩니다.
• 액세스 권한을 할당할 때 조직의 어떤 사용자에게 리포지토리 읽기 액세스, PR 만들기 액세스, PR 승인 액세스 권한이 있어야 하는지 고려합니다.

비밀 관리

• Git 리포지토리에 일반 텍스트 또는 base64로 인코딩된 비밀을 저장하지 마세요. 대신 Azure Key Vault와 같은 외부 비밀 공급자를 사용하는 것이 좋습니다. 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자를 사용하면 Azure Key Vault를 CSI 볼륨을 사용하여 AKS(Azure Kubernetes Service) 클러스터와 비밀 저장소로 통합할 수 있습니다. 이 서비스는 Azure Arc 지원 Kubernetes 확장을 통해 사용할 수 있습니다. HashiCorp Vault는 타사 관리형 비밀 공급자 대안입니다.
• 비밀을 관리하는 또 다른 방법은 공개 및 개인 키의 개념에서 작동하는 Bitnami의 봉인된 비밀을 사용하는 것입니다. 이를 통해 운영자는 Git에서 공개 키를 사용하여 단방향으로 암호화된 비밀을 저장할 수 있습니다. 이 암호는 클러스터에서 실행되는 SealedSecrets 컨트롤러에서 사용하는 프라이빗 키를 통해서만 암호를 해독할 수 있습니다.

디자인 권장 사항

Azure Arc 지원 Kubernetes용 GitOps 구현을 계획할 때 다음 디자인 권장 사항을 검토합니다.

다음 다이어그램에는 Azure Arc 지원 Kubernetes Flux 확장을 사용하여 GitOps 프로세스를 구현하는 데 필요한 책임, 리포지토리, 파이프라인을 보여 주는 참조 아키텍처가 포함되어 있습니다.

리포지토리

세 개의 Git 리포지토리가 디자인에 포함됩니다.

• 애플리케이션 코드 리포지토리
  • 이 리포지토리는 애플리케이션 코드, 파이프라인 정의, 구성 스크립트를 저장합니다.
  • 이해하기 쉽고 원치 않는 장기 실행 분기 수를 제한하는 개발 분기 전략을 사용합니다.
• 애플리케이션 구성 리포지토리
  • 이 리포지토리는 ConfigMaps, Deployments, Services, HPA 개체와 같은 Kubernetes 개체를 비롯한 애플리케이션 구성을 저장합니다. 이 리포지토리는 각 애플리케이션에 대해 서로 다른 디렉터리를 사용하여 구성합니다. Flux는 이 리포지토리 및 대상 분기의 변경 내용을 클러스터에 동기화합니다.
  • 애플리케이션 개발자와 운영자가 환경별로 초기 구성을 쉽게 빌드할 수 있도록 하는 도구를 통합합니다. 애플리케이션 운영자는 Helm과 같은 패키지 관리자 또는 Kustomize와 같은 구성 도구를 사용하여 구성을 더 간단하게 만드는 Kubernetes별 애플리케이션 구성을 정의해야 합니다.
  • 각 환경 형식을 나타내는 분기를 만듭니다. 이를 통해 비 프로덕션 및 프로덕션 환경과 같은 각 특정 환경의 변경 내용을 세밀하게 제어할 수 있습니다.
  • 애플리케이션이 특정 네임스페이스에 배포되면 GitOps 구성 내에서 네임스페이스 범위 기능을 사용하여 특정 네임스페이스에 대해서만 구성을 적용합니다.
• 클러스터 전체 구성 리포지토리
  • 클러스터 운영자 관리를 위한 수신 컨트롤러, 네임스페이스, RBAC, 모니터링, 보안 스택과 같은 클러스터 전체 구성 요소를 정의합니다. Flux는 이 리포지토리 및 대상 분기의 변경 내용을 클러스터에 동기화합니다.
  • 서로 다른 구성 요소를 나타내는 서로 다른 디렉터리를 사용하여 이 리포지토리를 구성합니다.
  • 각 환경 형식을 나타내는 분기를 만듭니다. 이를 통해 비 프로덕션 및 프로덕션 환경과 같은 각 특정 환경의 변경 내용을 세밀하게 제어할 수 있습니다.
  • 클러스터 운영자는 Helm과 같은 패키지 관리자 또는 Kustomize 오버레이와 같은 구성 도구를 사용하여 구성을 더 간단하게 만들어야 합니다.

CI/CD 및 구성 업데이트 프로세스

CI/CD 및 컨테이너 이미지 업데이트

• CI 파이프라인
  • 개발 팀은 컨테이너 레지스트리에 애플리케이션을 빌드, 린팅, 테스트, 푸시하는 프로세스를 통해 CI 파이프라인을 정의해야 합니다.
• CD 파이프라인
  • 애플리케이션 구성 리포지토리의 변경 내용을 대상으로 하는 스크립트를 실행하는 CD 파이프라인을 만듭니다. 이 스크립트는 대상 환경에서 가져온 임시 분기를 만들고, 이미지 태그 버전을 변경하고, 변경 내용을 커밋하고, 대상 환경 분기에 대한 끌어오기 요청을 엽니다. 이 CD 파이프라인에는 올바른 GitOps 구성 리포지토리 및 분기를 대상으로 하는 적절한 환경 변수가 있는 환경 단계가 있을 수 있습니다.
  • 모든 환경에서 원치 않는 끌어오기 요청을 제한하도록 환경 단계에 대한 수동 승인 단계를 정의합니다.
• 애플리케이션 구성 리포지토리에서 분기 정책을 사용하도록 설정하여 환경에 대한 피어 검토 또는 승인을 적용합니다. 여기에는 최소 개수의 필수 검토 또는 낮은 환경에 대한 자동 승인이 포함될 수 있습니다. 또한 조직의 표준을 충족하기 위해 필요에 따라 타사 통합 및 승인을 고려합니다.

클러스터 전체 및 애플리케이션 구성 업데이트

• 클러스터 운영자와 애플리케이션 운영자는 각각 해당 구성 리포지토리에서 구성을 정의합니다. 이러한 사용자는 구성을 푸시하기 위해 파이프라인 도구가 필요하지 않습니다. 대신 네이티브 Git 커밋 및 PR 프로세스를 사용하여 구성을 정의하고 환경을 나타내는 분기에 변경 내용을 푸시합니다.
• 새 구성 정의의 경우 먼저 Dev와 같은 하위 환경에서 구성을 정의한 다음, 병합 및 끌어오기 요청을 통해 더 높은 환경으로 승격합니다. 필요에 따라 특정 환경과 관련된 cherry-pick 구성 업데이트입니다.

피드백 및 경고

• GitOps 구성을 동기화할 수 없거나 오류를 throw할 때 경고하도록 Flux 알림을 구성합니다. 애플리케이션 운영자는 애플리케이션 배포에 성공하고 정상 상태인지 확인하기 위해 경고를 구성해야 합니다. 클러스터 운영자는 클러스터 전체 구성 요소 조정에 실패한 시기와 Git 리포지토리와 동기화 문제가 있는 시기를 확인하도록 경고를 구성해야 합니다.
• GitOps 커넥터를 구현하여 Flux 에이전트의 피드백을 CI/CD 도구에 통합합니다.

보안 권장 사항

• Azure Arc 지원 Kubernetes 클러스터에 대한 거버넌스 및 보안 권장 사항을 검토합니다.
• 모든 구성 리포지토리를 정의하는 데 사용할 수 있는 인증 및 권한 부여와 함께 프라이빗 Git 리포지토리를 사용하여 클러스터 구성에 원치 않는 액세스를 방지합니다.
  • SSH를 사용하여 GitHub에 연결
  • Azure DevOps에 적합한 인증 메커니즘 선택
• Git 공급자가 지원하는 경우 SSH 프로토콜 및 SSH 키를 통해 Git 리포지토리에 액세스합니다. 아웃바운드 연결 제한으로 인해 SSH를 사용할 수 없거나 Git 공급자가 필요한 SSH 라이브러리를 지원하지 않는 경우 전용 서비스 계정을 사용하고 Flux에서 사용할 해당 계정에 API 키를 연결합니다. GitHub를 사용할 때 SSH에 대한 대안이 필요한 경우 인증을 위해 개인용 액세스 토큰을 만들 수 있습니다.
• 클러스터의 책임과 일치하는 분기 정책 및 권한을 구성합니다. 변경 내용을 승인할 최소 검토자 수를 설정합니다.
• YAML 구성 및 구문의 유효성을 검사하고 필요에 따라 테스트 Kubernetes 클러스터를 배포하도록 PR 파이프라인을 구성합니다. 병합을 수락하기 전에 이 파이프라인을 실행해야 하는 분기 정책을 설정합니다.
• 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자를 사용하여 비밀을 구현하면 Azure Key Vault를 CSI 볼륨을 통해 Azure Arc 지원 Kubernetes 클러스터와 비밀 저장소로 통합할 수 있습니다.
• Flux 확장은 네임스페이스 및 클러스터 범위 구성을 지원합니다. 구성에 단일 네임스페이스 이외의 액세스 권한이 없어야 하는 경우 네임스페이스 범위를 선택합니다.

다음 단계

하이브리드 및 다중 클라우드 경험에 대한 자세한 내용은 다음 문서를 참조하세요.

• Azure Arc 지원 Kubernetes의 필수 조건을 검토합니다.
• Azure Arc 지원 Kubernetes에 대해 유효성이 검사된 Kubernetes 배포를 검토합니다.
• 하이브리드 및 다중 클라우드 환경을 관리하는 방법을 알아봅니다.
• Azure Arc 지원 Kubernetes를 사용하여 GitOps에 대해 자세히 알아보려면 다음을 수행합니다.
  • Flux v2를 사용하여 개념적 GitOps를 검토합니다.
  • Flux v2에서 GitOps를 사용하는 방법을 알아봅니다.
  • 개념적 GitOps Flux v2 CI/CD 프로세스를 검토합니다.
  • 자습서에 따라 Flux v2 CI/CD를 구현합니다.
• Azure Arc Jumpstart에서 GitOps 흐름을 사용하여 Azure Arc 지원 Kubernetes를 경험해 보세요.
• Azure Arc 학습 경로를 통해 Azure Arc에 대해 알아봅니다.
• 가장 일반적인 질문에 대한 답변을 찾으려면 자주 묻는 질문 - Azure Arc 사용을 참조하세요.