AKS(Azure Kubernetes Service)에 대한 질문과 대답

  • 아티클

이 문서에서는 AKS(Azure Kubernetes Service)에 대한 질문과 대답을 다룹니다.

현재 AKS를 제공하는 Azure 지역은 무엇입니까?

사용 가능한 지역의 전체 목록은 AKS 지역 및 가용성을 참조 하세요.

AKS 클러스터를 지역에 분산할 수 있나요?

아니요. AKS 클러스터는 지역 리소스로, 여러 지역에 걸쳐 있을 수 없습니다. 여러 지역을 포함하는 아키텍처를 만드는 방법에 대한 지침은 비즈니스 연속성 및 재해 복구에 대한 모범 사례를 참조하세요.

AKS 클러스터를 가용성 영역에 분산할 수 있나요?

예. 지원하는 지역에 있는 하나 이상의 가용성 영역에서 AKS 클러스터를 배포할 수 있습니다.

Kubernetes API 서버에 대한 액세스 권한이 있는 사용자를 제한할 수 있나요?

예. API 서버에 대한 액세스를 제한하는 두 가지 옵션이 있습니다.

  • API 서버에 대한 퍼블릭 엔드포인트를 유지하지만 신뢰할 수 있는 IP 범위 세트로 액세스를 제한하려는 경우 API Server 권한 있는 IP 범위를 사용합니다.
  • API 서버를 가상 네트워크 내에서만 액세스할 수 있도록 제한하려면 프라이빗 클러스터를 사용합니다.

단일 클러스터에서 다른 VM 크기를 가질 수 있나요?

예, 여러 노드 풀을 만들어 AKS 클러스터에서 서로 다른 가상 머신 크기를 사용할 수 있습니다.

AKS 에이전트 노드에 보안 업데이트가 적용되어 있나요?

AKS는 매주 "공급업체 수정"이 있는 CVE를 패치합니다. 수정이 없는 CVE는 수정하기 전에 "공급업체 수정"을 기다리고 있습니다. AKS 이미지는 30일 이내에 자동으로 업데이트됩니다. 업데이트된 노드 이미지를 정기적으로 적용하여 최신 패치 이미지 및 OS 패치가 모두 적용되고 최신인지 확인하는 것이 좋습니다. 다음 방법 중 하나를 사용하여 이 작업을 수행할 수 있습니다.

  • Azure Portal 또는 Azure CLI를 통해 수동으로.
  • AKS 클러스터를 업그레이드하여. 클러스터는 코돈 및 드레이닝 노드를 자동으로 업그레이드한 다음, 최신 Ubuntu 이미지와 새 패치 버전 또는 부 Kubernetes 버전으로 새 노드를 온라인 상태로 만듭니다. 자세한 내용은 AKS 클러스터 업그레이드를 참조 하세요.
  • 노드 이미지 업그레이드를 사용합니다.

AKS의 컨테이너 이미지 크기 제한은 얼마인가요?

AKS는 컨테이너 이미지 크기에 대해 제한을 설정하지 않습니다. 그러나 이미지가 클수록 메모리 수요가 높다는 것을 이해하는 것이 중요합니다. 크기가 클수록 잠재적으로 리소스 제한 또는 작업자 노드의 사용 가능한 전체 메모리를 초과할 수 있습니다. 기본적으로 AKS 클러스터의 VM 크기 Standard_DS2_v2 메모리는 7GiB로 설정됩니다.

컨테이너 이미지가 TB(테라바이트) 범위와 같이 지나치게 큰 경우 디스크 공간이 부족하여 kubelet이 컨테이너 레지스트리에서 노드로 이미지를 끌어오지 못할 수 있습니다.

Windows Server 노드

Windows Server 노드의 경우 Windows 업데이트 자동으로 실행되고 최신 업데이트를 적용하지 않습니다. Windows 업데이트 릴리스 주기와 사용자 고유의 유효성 검사 프로세스에 대한 정기적인 일정에 따라, 클러스터에서 업그레이드를 수행하고 AKS 클러스터에서 Windows Server 노드 풀을 업그레이드해야 합니다. 이 업그레이드 프로세스는 최신 Windows Server 이미지 및 패치를 실행하는 노드를 만든 다음, 이전 노드를 제거합니다. 이 프로세스에 대한 자세한 내용은 AKS에서 노드 풀 업그레이드를 참조하세요.

알아야 할 AKS를 대상으로 하는 보안 위협이 있나요?

Microsoft는 컨테이너용 Microsoft Defender와 같은 서비스를 통해 워크로드를 보호하기 위해 수행할 수 있는 추가 작업에 대한 지침을 제공합니다. 다음은 알아야 할 AKS 및 Kubernetes와 관련된 보안 위협입니다.

관리되는 컨트롤 플레인은 내 노드와 어떻게 통신하나요?

AKS는 보안 터널 통신을 사용하여 api-서버 및 개별 노드 kubelets가 별도의 가상 네트워크에서도 통신할 수 있도록 합니다. 터널은 mTLS 암호화를 통해 보호됩니다. AKS에서 사용되는 현재 주 터널은 이전에 apiserver-network-proxy로 알려진 Konnectivity입니다. 모든 네트워크 규칙이 Azure 필수 네트워크 규칙 및 FQDN을 따르는지 확인하세요.

내 Pod가 클러스터 IP 대신 API 서버 FQDN을 사용할 수 있나요?

예, Pod에 kubernetes.azure.com/set-kube-service-host-fqdn 주석을 추가하여 KUBERNETES_SERVICE_HOST 변수를 클러스터 내 서비스 IP 대신 API 서버의 도메인 이름으로 설정할 수 있습니다. 이는 애플리케이션 규칙과 함께 Azure Firewall을 사용하는 경우와 같이 계층 7 방화벽을 통해 클러스터 송신이 수행되는 경우에 유용합니다.

AKS를 사용하여 두 개의 리소스 그룹을 만드는 이유는 무엇인가요?

AKS는 Virtual Machine Scale Sets, 가상 네트워크 및 Managed Disks를 포함하는 여러 Azure 인프라 리소스를 기준으로 합니다. 이러한 통합을 통해 AKS에서 제공하는 관리되는 Kubernetes 환경 내에서 Azure 플랫폼의 다양한 핵심 기능을 적용할 수 있습니다. 예를 들어, 대부분의 Azure Virtual Machine 유형은 AKS에서 직접 사용할 수 있으며, Azure Reservations를 사용하여 이러한 리소스에 대해 자동으로 할인 혜택을 받을 수 있습니다.

이 아키텍처를 사용하도록 설정하기 위해 각 AKS 배포는 두 개의 리소스 그룹에 걸쳐 있습니다.

  1. 첫 번째 리소스 그룹을 만듭니다. 이 그룹에는 Kubernetes 서비스 리소스만 포함됩니다. AKS 리소스 공급자는 배포 중에 두 번째 리소스 그룹을 자동으로 만듭니다. 두 번째 리소스 그룹의 예는 MC_myResourceGroup_myAKSCluster_eastus. 이 두 번째 리소스 그룹의 이름을 지정하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

  2. 노드 리소스 그룹이라고 하는 두 번째 리소스 그룹에는 클러스터와 연결된 모든 인프라 리소스가 포함됩니다. 이러한 리소스에는 Kubernetes 노드 VM, 가상 네트워킹 및 스토리지가 포함됩니다. 기본적으로 노드 리소스 그룹에는 MC_myResourceGroup_myAKSCluster_eastus 같은 이름이 있습니다. AKS는 클러스터를 삭제할 때마다 노드 리소스 그룹을 자동으로 삭제합니다. 클러스터의 수명 주기를 공유하는 리소스에만 이 클러스터를 사용해야 합니다.

    참고 항목

    AKS 클러스터의 노드 리소스 그룹 아래에 있는 리소스를 수정하는 것은 지원되지 않는 작업이며 클러스터 작업 오류가 발생합니다. AKS 클러스터에서 관리하는 사용자가 리소스를 수정하지 못하도록 차단하여 노드 리소스 그룹이 변경되는 것을 방지할 수 있습니다.

AKS 노드 리소스 그룹에 고유한 이름을 지정할 수 있나요?

예. 기본적으로 AKS는 노드 리소스 그룹의 이름을 MC_resourcegroupname_clustername_location으로 지정하지만 사용자가 고유한 이름을 제공할 수도 있습니다.

고유한 리소스 그룹 이름을 지정하려면 aks-preview Azure CLI 확장 버전 0.3.2 이상을 설치합니다. az aks create 명령을 사용하여 AKS 클러스터를 만들 때 --node-resource-group 매개 변수를 사용하고 리소스 그룹의 이름을 지정합니다. Azure Resource Manager 템플릿을 사용하여 AKS 클러스터를 배포하는 경우 nodeResourceGroup 속성을 사용하여 리소스 그룹 이름을 정의할 수 있습니다.

  • Azure 리소스 공급자는 자동으로 보조 리소스 그룹을 만듭니다.
  • 클러스터를 만들 때만 사용자 지정 리소스 그룹 이름을 지정할 수 있습니다.

노드 리소스 그룹을 사용할 때는 다음을 수행할 수 없습니다.

  • 노드 리소스 그룹에 대한 기존 리소스 그룹을 지정합니다.
  • 노드 리소스 그룹에 대해 다른 구독을 지정합니다.
  • 클러스터를 만든 후 노드 리소스 그룹 이름을 변경합니다.
  • 노드 리소스 그룹 내에서 관리되는 리소스의 이름을 지정합니다.
  • 노드 리소스 그룹 내에서 관리되는 리소스의 Azure에서 만든 태그를 수정하거나 삭제합니다. 다음 섹션에서 추가 정보를 참조하세요.

노드 리소스 그룹에서 태그 및 AKS 리소스의 다른 속성을 수정할 수 있나요?

노드 리소스 그룹에서 Azure에서 만든 태그 및 기타 리소스 속성을 수정하거나 삭제하는 경우 예기치 않은 크기 조정 및 업그레이드 오류가 발생할 수 있습니다. AKS를 사용하면 최종 사용자가 만든 사용자 지정 태그를 만들고 수정할 수 있으며 노드 풀을 만들 때 해당 태그를 추가할 수 있습니다. 예를 들어 비즈니스 단위 또는 비용 센터를 할당하기 위해 사용자 지정 태그를 만들거나 수정할 수 있습니다. 또 다른 옵션은 관리되는 리소스 그룹에 범위가 있는 Azure Policy를 만드는 것입니다.

Azure에서 만든 태그는 해당 Azure 서비스에 대해 생성되며 항상 허용되어야 합니다. AKS의 경우 태그와 k8s-azure 태그가 aks-managed 있습니다. AKS 클러스터의 노드 리소스 그룹 아래에 있는 리소스에서 Azure에서 만든 태그를 수정하는 것은 지원되지 않는 작업으로, SLO(서비스 수준 목표)를 중단합니다. 자세한 내용은 AKS에서 서비스 수준 계약을 제공하나요?

참고 항목

과거에는 태그 이름 "소유자"가 부하 분산 장치의 프런트 엔드 IP에 할당된 공용 IP를 관리하기 위해 AKS에 예약되었습니다. 이제 서비스는 접두사를 aks-managed 사용합니다. 레거시 리소스의 경우 Azure 정책을 사용하여 "소유자" 태그 이름을 적용하지 마세요. 그렇지 않으면 AKS 클러스터 배포 및 업데이트 작업의 모든 리소스가 중단됩니다. 새로 만든 리소스에는 적용되지 않습니다.

AKS에서 지원하는 Kubernetes 허용 컨트롤러는 무엇인가요? 허용 컨트롤러를 추가하거나 제거할 수 있나요?

AKS는 다음과 같은 허용 컨트롤러를 지원합니다.

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultIngressClass
  • DefaultStorageClass
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

현재 AKS에서 허용 컨트롤러 목록을 수정할 수 없습니다.

AKS에서 허용 컨트롤러 웹후크를 사용할 수 있나요?

예, AKS에서 허용 컨트롤러 웹후크를 사용할 수 있습니다. 컨트롤 플레인 레이블로 표시된 내부 AKS 네임스페이스를 제외하는 것이 좋습니다. 예를 들어:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS는 API 서버 송신을 방화벽으로 설정하므로 허용 컨트롤러 웹후크는 클러스터 내에서 액세스할 수 있어야 합니다.

허용 컨트롤러 웹후크가 kube-system 및 내부 AKS 네임스페이스에 영향을 미칠 수 있나요?

시스템의 안정성을 보호하고 사용자 지정 허용 컨트롤러가 kube-system의 내부 서비스에 영향을 주지 않도록 하기 위해 네임스페이스 AKS에는 kube-system 및 AKS 내부 네임스페이스를 자동으로 제외하는 Admissions Enforcer가 있습니다. 이 서비스는 사용자 지정 허용 컨트롤러가 kube-system에서 실행되는 서비스에 영향을 주지 않도록 합니다.

사용자 지정 허용 웹후크를 지원하기 위해 kube-system에 항목을 배포하는 데 중요한 사용 사례(권장되지 않음)가 있는 경우 허용 집행자에서 무시되도록 다음 레이블 또는 주석을 추가할 수 있습니다.

레이블: "admissions.enforcer/disabled": "true" 또는 주석: "admissions.enforcer/disabled": true

Azure Key Vault는 AKS와 통합되나요?

비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자는 AKS에 Azure Key Vault의 네이티브 통합을 제공합니다.

AKS에서 Windows Server 컨테이너를 실행할 수 있나요?

예, Windows Server 컨테이너는 AKS에서 사용할 수 있습니다. AKS에서 Windows Server 컨테이너를 실행하려면 Windows Server를 게스트 OS로 실행하는 노드 풀을 만듭니다. Windows Server 컨테이너는 Windows Server 2019만 사용할 수 있습니다. 시작하려면 Windows Server 노드 풀을 사용하여 AKS 클러스터 만들기를 참조하세요.

노드 풀에 대한 Windows Server 지원에는 Kubernetes 프로젝트의 업스트림 Windows Server의 일부인 몇 가지 제한 사항이 포함되어 있습니다. 이러한 제한 사항에 대한 자세한 내용은 AKS의 Windows Server 컨테이너 제한 사항을 참조하세요.

AKS는 서비스 수준 계약을 제공하나요?

AKS는 표준 가격 책정 계층에서 가동 시간 SLA 기능을 사용하여 SLA 보증을 제공합니다.

무료 가격 책정 계층에는 연결된 서비스 수준 계약이 없지만 서비스 수준 목표는 99.5%입니다. 일시적인 연결 문제는 업그레이드, 비정상 언더레이 노드, 플랫폼 유지 관리, 애플리케이션 요청으로 인한 API 서버에 과부하가 발생하는 경우 등으로 관찰됩니다. 중요 업무용 및 프로덕션 워크로드의 경우 또는 워크로드가 API 서버 다시 시작을 허용하지 않는 경우 가동 시간 SLA가 포함된 표준 계층을 사용하는 것이 좋습니다.

AKS 에이전트 노드에 Azure 예약 할인을 적용할 수 있나요?

AKS 에이전트 노드는 표준 Azure 가상 머신으로 요금이 청구됩니다. AKS에서 사용하는 VM 크기에 대해 Azure Reservations를 구매한 경우 해당 할인이 자동으로 적용됩니다.

Azure 테넌트 간에 클러스터를 이동/마이그레이션할 수 있나요?

테넌트 간에 AKS 클러스터를 이동하는 것은 현재 지원되지 않습니다.

구독 간에 클러스터를 이동/마이그레이션할 수 있나요?

구독 간의 클러스터 이동은 현재 지원되지 않습니다.

AKS 클러스터를 현재 Azure 구독에서 다른 구독으로 이동할 수 있나요?

AKS 클러스터와 연결된 리소스를 Azure 구독 간에 이동하는 것은 지원되지 않습니다.

AKS 클러스터 또는 AKS 인프라 리소스를 다른 리소스 그룹으로 이동하거나 이름을 바꿀 수 있나요?

AKS 클러스터 및 연결된 리소스를 이동하거나 이름을 바꾸는 것은 지원되지 않습니다.

클러스터 삭제 시간이 너무 오래 걸리는 이유는 무엇인가요?

대부분의 클러스터는 사용자 요청 시 삭제됩니다. 일부 경우, 특히 자체 리소스 그룹을 가져오거나 RG 간 작업을 수행하는 경우 삭제에 더 많은 시간이 걸리거나 실패할 수도 있습니다. 삭제 시 문제가 발생하면 RG에 잠금이 없는지와 RG 외부의 모든 리소스와 RG의 연결이 끊어져 있는지를 다시 확인합니다.

클러스터 만들기/업데이트에 시간이 오래 걸리는 이유는 무엇인가요?

클러스터 작업 만들기 및 업데이트에 문제가 있는 경우 AKS 클러스터가 VM, 부하 분산 장치, 태그 등과 같은 리소스를 관리하는 것을 차단할 수 있는 할당된 정책이나 서비스 제약 조건이 없는지 확인합니다.

클러스터를 삭제한 후 복원할 수 있나요?

아니요, 클러스터를 삭제한 후에는 복원할 수 없습니다. 클러스터를 삭제하면 노드 리소스 그룹 및 해당 리소스도 모두 삭제됩니다. 두 번째 리소스 그룹의 예는 MC_myResourceGroup_myAKSCluster_eastus.

리소스를 유지하려면 클러스터를 삭제하기 전에 다른 리소스 그룹으로 이동합니다. 실수로 인한 삭제로부터 보호하려는 경우 노드 리소스 그룹 잠금을 사용하여 클러스터 리소스를 호스트하는 AKS 관리되는 리소스 그룹을 잠글 수 있습니다.

플랫폼 지원이란 무엇이며, 여기에는 무엇이 포함되나요?

플랫폼 지원은 지원되지 않는 "N-3" 버전 클러스터에 대한 축소된 지원 계획입니다. 플랫폼 지원에는 Azure 인프라 지원만 포함됩니다. 플랫폼 지원에는 다음과 관련된 내용이 포함되지 않습니다.

  • Kubernetes 기능 및 구성 요소
  • 클러스터 또는 노드 풀 만들기
  • 핫픽스
  • 버그 수정
  • 보안 패치
  • 사용 중지된 구성 요소

제한 사항에 대한 자세한 내용은 플랫폼 지원 정책을 참조하세요.

AKS는 세 가지 부 버전의 슬라이딩 윈도우만 지원하는 오픈 소스 프로젝트인 Kubernetes의 릴리스와 패치를 사용합니다. AKS는 해당 버전이 업스트림으로 서비스되는 동안에만 완전한 지원을 보장할 수 있습니다. 더 이상 업스트림으로 생성되는 패치가 없으므로 AKS는 해당 버전을 패치되지 않은 상태로 두거나 포크할 수 있습니다. 이러한 제한 사항으로 인해 플랫폼 지원은 kubernetes 업스트림에 의존하는 어떤 것도 지원하지 않습니다.

AKS는 지원되지 않는 클러스터를 자동으로 업그레이드하나요?

AKS는 지원되지 않는 클러스터에 대해 자동 업그레이드를 시작합니다. n-3 버전의 클러스터(여기서 n은 지원되는 최신 AKS GA 부 버전)가 n-4로 떨어질 경우 AKS는 자동으로 클러스터를 n-2로 업그레이드하여 AKS 지원 정책을 유지합니다. 플랫폼 지원 클러스터를 지원되는 버전으로 자동으로 업그레이드하는 것은 기본적으로 사용하도록 설정됩니다.

예를 들어, kubernetes v1.25는 v1.29 GA 릴리스 중에 v1.26으로 업그레이드됩니다. 중단을 최소화하려면 유지 관리 기간을 설정합니다. 자동 업그레이드 채널에 대한 자세한 내용은 자동 업그레이드를 참조하세요.

'NodeLost' 또는 'Unknown' 상태의 Pod/배포가 있는 경우 클러스터를 업그레이드할 수 있나요?

가능하지만 권장하지는 않습니다. 클러스터 상태가 알려져 있고 정상일 때 업데이트를 수행해야 합니다.

노드가 하나 이상 있는 클러스터가 비정상 상태이거나 종료된 경우 업그레이드를 수행할 수 있나요?

아니요, 업그레이드하기 전에 실패한 상태의 노드 또는 클러스터에서 노드를 삭제/제거합니다.

클러스터 삭제를 실행했지만 오류가 표시됩니다. [Errno 11001] getaddrinfo failed

가장 일반적으로 이 오류는 클러스터와 연결되어 아직 사용 중인 NSG(네트워크 보안 그룹)가 하나 이상 있는 경우에 발생합니다. 제거한 후 삭제를 다시 시도합니다.

업그레이드를 실행했지만 pod이 충돌 루프에 있습니다. 준비 상태 프로브가 실패하나요?

서비스 주체가 만료되지 않았는지 확인합니다. 참조 항목: AKS 서비스 주체 및 AKS 업데이트 자격 증명.

클러스터가 작동 중이었지만 갑자기 LoadBalancer, 탑재 PVC 등을 프로비전할 수 없습니다.

서비스 주체가 만료되지 않았는지 확인합니다. 참조 항목: AKS 서비스 주체 및 AKS 업데이트 자격 증명.

AKS 클러스터의 크기를 0으로 조정할 수 있나요?

실행 중인 AKS 클러스터를 완전히 중지하여 각 컴퓨팅 비용을 절감할 수 있습니다. 또한 필요한 클러스터 구성만 기본 모든 또는 특정 User 노드 풀의 크기를 0으로 조정하거나 자동 크기 조정하도록 선택할 수도 있습니다.

시스템 노드 풀을 0으로 직접 조정할 수 없습니다.

Virtual Machine Scale Set API를 사용하여 수동으로 크기를 조정할 수 있나요?

아니요, Virtual Machine Scale Set API를 사용한 크기 조정 작업은 지원되지 않습니다. AKS API(az aks scale)를 사용합니다.

Virtual Machine Scale Sets를 사용하여 수동으로 노드 0으로 확장할 수 있나요?

아니요, Virtual Machine Scale Set API를 사용한 크기 조정 작업은 지원되지 않습니다. AKS API를 사용하여 0개의 비시스템 노드 풀로 확장하거나 클러스터를 대신 중지할 수 있습니다.

모든 VM을 중지하거나 할당을 해제할 수 있나요?

AKS에는 이러한 구성을 견디고 복구할 수 있는 복원 메커니즘이 있지만 지원되는 구성은 아닙니다. 대신 클러스터 를 중지합니다.

사용자 지정 VM 확장을 사용할 수 있나요?

아니요, AKS는 관리형 서비스이며, IaaS 리소스 조작은 지원되지 않습니다. 사용자 지정 구성 요소를 설치하려면 Kubernetes API 및 메커니즘을 사용하세요. 예를 들어 DaemonSets를 사용하여 필요한 구성 요소를 설치합니다.

AKS는 클러스터 지역 외부에 고객 데이터를 저장하나요?

아니요. 모든 데이터는 클러스터의 지역에 저장됩니다.

AKS 이미지가 루트로 실행되어야 하나요?

다음 이미지에는 "루트로 실행"에 대한 기능 요구 사항이 있으며 모든 정책에 대해 예외를 제출해야 합니다.

  • mcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprod
  • mcr.microsoft.com/oss/calico/node
  • mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Azure CNI 투명 모드와 브리지 모드는 무엇인가요?

1.2.0 버전부터 Azure CNI에서는 단일 테넌시 Linux CNI 배포에 대해 기본적으로 투명 모드를 설정합니다. 투명 모드가 브리지 모드를 대체합니다. 다음 브리지 모드 및 투명 모드 섹션에서는 두 모드 간의 차이점과 Azure CNI의 투명 모드에 대한 이점 및 제한 사항에 대해 자세히 설명합니다.

브리지 모드

Azure CNI 브리지 모드는 "Just-In-Time" 방식으로 "azure0"이라는 L2 브리지를 만듭니다. 모든 호스트 쪽 Pod veth 쌍 인터페이스가 이 브리지에 연결됩니다. Pod-Pod 내부 VM 통신과 나머지 트래픽은 이 브리지를 통과합니다. 브리지는 하나 이상의 실제 디바이스에 바인딩하지 않는 한 자체적으로 수신하거나 전송할 수 없는 레이어 2 가상 디바이스입니다. 이러한 이유로 Linux VM의 eth0은 "azure0" 브리지의 하위 브리지로 변환되어야 하며, 이로 인해 Linux VM 내에 복잡한 네트워크 토폴로지가 만들어집니다. 이에 따라 CNI는 DNS 서버 업데이트와 같은 다른 네트워킹 함수를 처리해야 했습니다.

Bridge mode topology

다음 예제에서는 브리지 모드에서 IP 경로 설정의 모양을 보여 둡니다. 노드에 얼마나 많은 Pod가 있는지에 관계없이 경로는 두 개만 있습니다. 첫 번째 경로는 트래픽(azure0의 로컬 제외)이 노드 기본 IP인 "src 10.240.0.4" IP와의 인터페이스를 통해 서브넷의 기본 게이트웨이로 이동함을 나타냅니다. 두 번째 경로는 커널이 결정할 수 있는 커널에 대한 "10.20.x.x" Pod 공간을 나타냅니다.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

투명 모드

투명 모드는 Linux 네트워킹 설정에 대한 간단한 방식을 사용합니다. 이 모드에서 Azure CNI는 Linux VM에서 eth0 인터페이스의 속성을 변경하지 않습니다. Linux 네트워킹 속성을 변경하는 이러한 방식은 클러스터가 브리지 모드에서 직면할 수 있는 복잡한 코너 사례 문제를 줄이는 데 도움이 됩니다. 투명 모드에서 Azure CNI는 호스트 네트워크에 추가되는 호스트 쪽 Pod veth 쌍 인터페이스를 만들고 추가합니다. VM 내 Pod 간 통신은 CNI에서 추가한 IP 경로를 통해 이루어집니다. 기본적으로 Pod 간 통신은 계층 3을 통해 이루어지며, Pod 트래픽은 L3 라우팅 규칙에 의해 라우팅됩니다.

Transparent mode topology

다음 예에서는 투명 모드의 ip 경로 설정을 보여 줍니다. 각 Pod의 인터페이스에는 고정 경로가 연결되어 대상 IP가 Pod인 트래픽이 Pod의 호스트 쪽 veth 쌍 인터페이스로 직접 전송됩니다.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

투명 모드의 이점

  • 노드 로컬 DNS를 conntrack 설정할 필요 없이 DNS 병렬 경합 상태를 완화하고 5초 DNS 대기 시간 문제를 방지합니다(성능상의 이유로 노드 로컬 DNS를 계속 사용할 수 있음).
  • "Just-In-Time" 브리지 설정으로 인해 현재 도입된 초기 5초 DNS 대기 시간 CNI 브리지 모드를 제거합니다.
  • 브리지 모드의 코너 케이스 중 하나는 Azure CNI에서 사용자가 VNET 또는 NIC에 추가하는 사용자 지정 DNS 서버 목록을 계속 업데이트할 수 없다는 것입니다. 이 시나리오에서는 CNI가 DNS 서버 목록의 첫 번째 인스턴스만 선택하게 됩니다. CNI는 eth0 속성을 변경하지 않으므로 이 문제는 투명 모드에서 해결됩니다. 여기에서 자세한 내용을 알아보세요.
  • UDP 트래픽의 효과적인 처리 및 ARP 시간이 초과될 때 UDP 플러드 폭풍 완화 기능을 제공합니다. 브리지 모드에서는 브리지가 VM 내 Pod 간 통신에서 대상 Pod의 MAC 주소를 인식하지 못하는 경우 기본적으로 모든 포트에 대한 패킷 폭풍이 발생합니다. 경로에 L2 디바이스가 없으므로 이 문제는 투명 모드에서 해결됩니다. 여기에서 자세한 내용을 알아보세요.
  • 투명 모드는 브리지 모드와 비교할 때 처리량 및 대기 시간 측면에서 VM Pod 간 통신에 더 나은 성능을 보입니다.

볼륨에 파일이 많을 때 권한 소유권 설정 속도 저하 문제를 방지하는 방법은 무엇인가요?

일반적으로 Pod가 비루트 사용자로 실행되는 경우(수행해야 하는 경우) Pod에서 볼륨을 읽고 쓸 수 있도록 Pod의 보안 컨텍스트 내부에 지정 fsGroup 해야 합니다. 이 요구 사항은 여기에서 자세히 설명합니다.

fsGroup 설정의 부작용은 볼륨이 탑재될 때마다 Kubernetes가 볼륨 내부의 모든 파일과 디렉터리에 대해 재귀적으로 chown() 및 chmod()를 사용해야 한다는 것입니다(아래에 몇 가지 예외가 있음). 이 시나리오는 볼륨의 그룹 소유권이 이미 요청된 fsGroup과 일치하는 경우에도 발생합니다. 작은 파일이 많은 대용량 볼륨의 경우 비용이 많이 들 수 있으며 이로 인해 Pod 시작에 오랜 시간이 걸릴 수 있습니다. 이 시나리오는 v1.20 이전에 알려진 문제이며 해결 방법은 Pod 실행을 루트로 설정하는 것입니다.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

이 이슈는 Kubernetes 1.20 버전에서 해결되었습니다. 자세한 내용은 Kubernetes 1.20: 볼륨 권한 변경에 대한 세분화된 제어를 참조하세요.

AKS에서 배포와 함께 FIPS 암호화 라이브러리를 사용할 수 있나요?

FIPS 사용 노드는 이제 Linux 기반 노드 풀에서 지원됩니다. 자세한 내용은 FIPS 사용 노드 풀 추가를 참조하세요.

AKS를 통해 NSG를 구성할 수 있나요?

AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. AKS는 네트워크 인터페이스 NSG 설정만 수정합니다. CNI를 사용하는 경우 NSG의 보안 규칙이 노드와 Pod CIDR 범위 간의 트래픽을 허용하는지 확인해야 합니다. kubenet을 사용하는 경우 NSG의 보안 규칙이 노드와 Pod CIDR 간의 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

AKS에서 시간 동기화는 어떻게 작동하나요?

AKS 노드는 localhost에서 시간을 끌어오는 "chrony" 서비스를 실행합니다. Pod에서 실행되는 컨테이너는 AKS 노드에서 시간을 얻습니다. 컨테이너 내에서 시작된 애플리케이션은 Pod의 컨테이너에서 시간을 사용합니다.

AKS 추가 기능은 어떻게 업데이트되나요?

보안 패치를 포함한 모든 패치는 AKS 클러스터에 자동으로 적용됩니다. 새 릴리스를 사용할 수 있는 경우 클러스터를 업데이트할 때 주요 또는 부 버전 변경(배포된 개체에 호환성이 손상될 수 있음)처럼 패치보다 큰 항목이 업데이트됩니다. AKS 릴리스 정보를 방문하여 새 릴리스를 사용할 수 있는 시기를 확인할 수 있습니다.

Linux Virtual Machine Scale Sets 인스턴스에 설치된 AKS Linux 확장의 목적은 무엇인가요?

AKS Linux 확장은 Kubernetes 작업자 노드에 모니터링 도구를 설치하고 구성하는 Azure VM 확장입니다. 확장은 모든 신규 및 기존 Linux 노드에 설치됩니다. 다음 모니터링 도구를 구성합니다.

  • Node-exporter: 가상 머신에서 하드웨어 원격 분석을 수집하고 메트릭 엔드포인트를 사용하여 사용할 수 있도록 합니다. 그런 다음 Prometheus와 같은 모니터링 도구를 사용하여 이러한 메트릭을 스크랩할 수 있습니다.
  • Node-problem-detector: 클러스터 관리 스택의 업스트림 계층에 다양한 노드 문제를 표시하는 것을 목표로 합니다. 각 노드에서 실행되고, 노드 문제를 검색하고, 이벤트 및 NodeConditions를 사용하여 클러스터의 API 서버에 보고하는 시스템 단위입니다.
  • ig: Linux 및 Kubernetes 시스템을 디버깅하고 관찰하기 위한 eBPF 기반 오픈 소스 프레임워크입니다. 사용자가 성능 문제, 충돌 또는 기타 변칙의 원인을 식별할 수 있도록 관련 정보를 수집하도록 설계된 도구(또는 가젯)를 제공합니다. 특히 Kubernetes의 독립성을 통해 사용자는 컨트롤 플레인 문제를 디버깅하는 데도 사용할 수 있습니다.

이러한 도구는 다음과 같은 많은 노드 상태 관련 문제에 대한 가시성을 제공하는 데 도움이 됩니다.

  • 인프라 디먼 문제: NTP 서비스 다운
  • 하드웨어 문제: 잘못된 CPU, 메모리 또는 디스크
  • 커널 문제: 커널 교착 상태, 손상된 파일 시스템
  • 컨테이너 런타임 문제: 응답하지 않는 런타임 디먼

확장은 문서화된 AKS 송신 요구 사항을 넘어서는 URL, IP 주소 또는 포트에 대한 추가 아웃바운드 액세스를 요구하지 않습니다. Azure에서 부여된 특별 권한은 필요하지 않습니다. kubeconfig를 사용하여 API 서버에 연결하여 수집된 모니터링 데이터를 보냅니다.