다음을 통해 공유


AKS(Azure Kubernetes Service)를 사용한 Pod 샌드박싱

신뢰할 수 없거나 잠재적으로 악성 코드로부터 컨테이너 워크로드를 보호하고 보호하기 위해 AKS에는 이제 Pod Sandboxing이라는 메커니즘이 포함되어 있습니다. Pod 샌드박싱은 컨테이너 애플리케이션과 CPU, 메모리 및 네트워킹 같은 컨테이너 호스트의 컴퓨팅 리소스 및 공유 커널 간에 격리 경계를 제공합니다. 애플리케이션은 격리된 경량 파드 VM(가상 머신)에서 작동합니다. Pod 샌드박싱은 전체 아키텍처에서 다른 보안 조치 또는 데이터 보호 제어를 보완하여 중요한 정보를 보호하기 위한 규정, 산업 또는 거버넌스 규정 준수 요구 사항을 충족하는 데 도움을 줍니다.

이 문서는 이 새로운 기능과 그 구현 방법을 이해하는 데 도움이 됩니다.

필수 구성 요소

  • Azure CLI 버전 2.80.0 이상. 실행 az --version 하여 Azure CLI의 버전을 찾고 업그레이드하려면 실행 az upgrade 합니다. 자세한 내용은 Azure CLI 설치의 단계를 참조하세요.

  • AKS는 Kubernetes 버전 1.27.0 이상에서 Pod 샌드박싱을 지원합니다.

  • Kubernetes 클러스터를 관리하려면 Kubernetes 명령줄 클라이언트인 kubectl을 사용합니다. Azure Cloud Shell은 kubectl과 함께 제공됩니다. az aks install-cli 명령을 사용하여 kubectl을 로컬로 설치할 수 있습니다.

제한 사항

다음은 Pod Sandboxing에 적용할 수 있는 제약 조건입니다.

  • Kata 컨테이너는 기존 컨테이너가 Azure Files 및 고성능 로컬 SSD에서 도달할 수 있는 IOPS 성능 제한에 도달하지 못할 수 있습니다.

  • 컨테이너용 Microsoft Defender는 Kata 런타임 Pod 평가를 지원하지 않습니다.

  • Kata 호스트 네트워크 액세스는 지원되지 않습니다. VM 내에서 호스트 네트워킹 구성에 직접 액세스할 수 없습니다.

  • Pod 샌드박싱을 사용한 CPU 및 메모리 할당은 runc와 비교하여 다른 고려 사항이 있습니다. 고려 사항 페이지에서 메모리 관리 섹션을 참조하세요.

작동 방법

AKS의 Pod 샌드박싱은 오픈 소스 Kata Containers 프로젝트를 기반으로 빌드됩니다. AKS용 Azure Linux 컨테이너 호스트에서 실행되는 Kata Containers는 VM 기반 격리 및 각 Pod에 대해 별도의 커널을 제공합니다. Pod 샌드박싱을 사용하면 사용자가 각 Pod에 대한 리소스를 할당할 수 있으며 동일한 호스트에서 실행되는 다른 Kata 컨테이너 또는 네임스페이스 컨테이너와 공유하지 않습니다.

솔루션 아키텍처는 다음과 같은 주요 구성 요소를 기반으로 합니다.

Kata 컨테이너를 사용하여 Pod 샌드박싱을 배포하는 것은 컨테이너를 배포하는 표준 containerd 워크플로와 유사합니다. Pod 샌드박싱이 사용하도록 설정된 클러스터에는 Pod 매니페스트(runtimeClassName: kata-vm-isolation)에서 참조할 수 있는 특정 런타임 클래스가 함께 제공됩니다.

이 기능을 Pod와 함께 사용하려면 Pod 사양에 runtimeClassNamekata-vm-isolation을 추가하는 것이 유일한 차이점입니다. Pod가 runtimeClass를 kata-vm-isolation 사용하는 경우 하이퍼바이저는 워크로드가 작동할 수 있도록 자체 커널을 사용하여 경량 가상 머신을 회전합니다.

새 클러스터 배포

Azure CLI를 사용하여 Azure Linux AKS 클러스터를 배포하려면 다음 단계를 수행합니다.

  1. az aks create 명령을 사용하고 다음 매개 변수를 지정하여 AKS 클러스터를 만듭니다.

    • --workload-runtime: 노드 풀에서 Pod 샌드박싱 기능을 사용하도록 설정하려면 KataVmIsolation 을 지정합니다. 이 매개 변수를 사용하면 이러한 다른 매개 변수가 다음 요구 사항을 충족해야 합니다. 그렇지 않으면 명령이 실패하고 해당 매개 변수와 관련된 문제를 보고합니다.
    • --os-sku: AzureLinux. Azure Linux os-sku만 이 기능을 지원합니다.
    • --node-vm-size: 2세대 VM이고 중첩된 가상화 작업을 지원하는 모든 Azure VM 크기입니다. 예로 Dsv3 VM을 들 수 있습니다.

    다음 예에서는 myResourceGroup에 하나의 노드가 있는 myAKSCluster라는 클러스터를 만듭니다.

    az aks create
        --name myAKSCluster \
        --resource-group myResourceGroup \
        --os-sku AzureLinux \
        --workload-runtime KataVmIsolation \
        --node-vm-size Standard_D4s_v3 \
        --node-count 3 \
        --generate-ssh-keys
    
  2. 다음 명령을 실행하여 Kubernetes 클러스터에 대한 액세스 자격 증명을 가져옵니다. az aks get-credentials 명령을 사용하고 클러스터 이름과 리소스 그룹 이름의 값을 바꿉니다.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
    
  3. kubectl get pods 명령을 사용하여 모든 네임스페이스에 Pod를 전부 나열합니다.

    kubectl get pods --all-namespaces
    

기존 클러스터에 배포

기존 AKS 클러스터에서 이 기능을 사용하려면 다음 요구 사항을 충족해야 합니다.

  • 클러스터가 Kubernetes 버전 1.27.0 이상을 실행하고 있는지 확인합니다.

다음 명령을 사용하여 호스트할 노드 풀을 만들어 Pod Sandboxing을 사용하도록 설정합니다.

  1. az aks nodepool add 명령을 사용하여 AKS 클러스터에 노드 풀을 추가합니다. 다음 매개 변수를 지정합니다.

    • --resource-group: AKS 클러스터를 만들 기존 리소스 그룹의 이름을 입력합니다.
    • --cluster-name: AKS 클러스터의 고유한 이름(예: myAKSCluster)을 입력합니다.
    • --name: 클러스터 노드 풀의 고유한 이름(예: nodepool2)을 입력합니다.
    • --workload-runtime: 노드 풀에서 Pod 샌드박싱 기능을 사용하도록 설정하려면 KataVmIsolation 을 지정합니다. --workload-runtime 매개 변수와 함께 이러한 다른 매개 변수는 다음 요구 사항을 충족해야 합니다. 그렇지 않으면 명령이 실패하고 해당 매개 변수와 관련된 문제를 보고합니다.
      • --os-sku: AzureLinux. Azure Linux os-sku만 이 기능을 지원합니다.
      • --node-vm-size: 2세대 VM이고 중첩된 가상화 작업을 지원하는 모든 Azure VM 크기입니다. 예로 Dsv3 VM을 들 수 있습니다.

    다음 예제에서는 myResourceGroupnodepool2에 노드가 한 개 있는 myAKSCluster에 노드 풀을 추가합니다.

    az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataVmIsolation --node-vm-size Standard_D4s_v3
    
  2. az aks update 명령을 실행하여 클러스터에서 Pod 샌드박싱을 사용하도록 설정합니다.

    az aks update --name myAKSCluster --resource-group myResourceGroup
    

애플리케이션 배포

Pod Sandboxing을 사용하면 런타임을 활용하는 Kata Pod와 함께 Kata 런타임을 활용하지 않는 "일반" Pod를 함께 배포할 수 있습니다. 둘 사이의 주요 차이점은 배포할 때 Kata Pod의 사양에 선 runtimeClassName: kata-vm-isolation 이 있다는 사실에 있습니다.

Kata 런타임을 사용하여 애플리케이션 배포

AKS 클러스터에서 Kata 런타임을 사용하여 Pod를 배포하려면 다음 단계를 수행합니다.

  1. kata-app.yaml이라는 파일을 만들어 kata Pod를 설명한 다음 다음 매니페스트를 붙여넣습니다.

    kind: Pod
    apiVersion: v1
    metadata:
      name: isolated-pod
    spec:
      runtimeClassName: kata-vm-isolation
      containers:
      - name: kata
        image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
        command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
    

    runtimeClassNameSpec 값은 kata-vm-isolation입니다.

  2. kubectl apply 명령을 실행하여 Kubernetes Pod를 배포하고 kata-app.yaml 파일을 지정합니다.

    kubectl apply -f kata-app.yaml
    

    명령의 출력은 다음 예제와 유사합니다.

    pod/isolated-pod created
    

(선택 사항) 커널 격리 구성 확인

Kata의 커널과 Kata Pod가 아닌 커널 간의 차이를 확인하려면 Kata 런타임이 없는 다른 워크로드를 스핀업할 수 있습니다.

kind: Pod
apiVersion: v1
metadata:
  name: normal-pod
spec:
  containers:
  - name: non-kata
    image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
  1. AKS 클러스터 내의 컨테이너에 액세스하려면 kubectl exec 명령을 실행하여 셸 세션을 시작합니다. 이 예제에서는 kata-pod 내의 컨테이너에 액세스합니다.

    kubectl exec -it isolated-pod -- /bin/sh
    

    Kubectl은 클러스터에 연결하고, /bin/sh 내 첫 번째 컨테이너에서 isolated-pod을(를) 실행하며, 터미널의 입력 및 출력 스트림을 컨테이너의 프로세스로 전달합니다. Kata가 아닌 Pod를 호스팅하는 컨테이너에 대한 셸 세션을 시작하여 차이점을 확인할 수도 있습니다.

  2. kata-Pod에서 컨테이너에 대한 셸 세션을 시작한 후 명령을 실행하여 kata 컨테이너가 Pod 샌드박스에서 실행되고 있는지 확인할 수 있습니다. 샌드박스 외부의 비Kata 컨테이너와 비교해 보면 다른 커널 버전이 있음을 알 수 있습니다.

    커널 버전을 보려면 다음 명령을 실행합니다.

    uname -r
    

    다음 예제는 Pod 샌드박스 커널의 출력과 유사합니다.

    [user]/# uname -r
    6.6.96.mshv1
    
  3. normal-Pod에서 컨테이너에 대한 셸 세션을 시작하여 커널 출력을 확인합니다.

    kubectl exec -it normal-pod -- /bin/bash
    

    커널 버전을 보려면 다음 명령을 실행합니다.

    uname -r
    

    다음 예제는 Pod 샌드박스 내에서 실행되는 Kata Pod와 다른 커널인 normal-Pod를 실행하는 VM의 출력과 유사합니다.

    6.6.100.mshv1-1.azl3
    

정리

이 기능 평가를 마쳤으면 Azure 요금이 청구되지 않도록 불필요한 리소스를 정리합니다. 평가 또는 테스트의 일부로 새 클러스터를 배포한 경우 az aks delete 명령을 사용하여 클러스터를 삭제할 수 있습니다.

az aks delete --resource-group myResourceGroup --name myAKSCluster

기존 클러스터에 Pod 샌드박싱을 배포한 경우 kubectl delete Pod 명령을 사용하여 Pod를 제거할 수 있습니다.

kubectl get pods
kubectl delete pod <kata-pod-name>

다음 단계

  • 하드웨어 격리를 사용하고 Azure 플랫폼 유지 관리 이벤트를 제어하기 위한 AKS 클러스터가 있는 노드용 Azure Dedicated Host에 대해 자세히 알아봅니다.
  • Pod 샌드박싱 격리를 추가로 탐색하고 워크로드 시나리오를 살펴보려면 Pod 샌드박싱 랩을 사용해 보세요.