AKS 클러스터 구성

AKS 클러스터를 만드는 과정에서 필요에 따라 클러스터 구성을 사용자 지정해야 할 수 있습니다. 이 문서에서는 AKS 클러스터를 사용자 지정하기 위한 몇 가지 옵션을 소개합니다.

OS 구성

AKS는 클러스터에 대한 GA(일반 공급)의 기본 OS(노드 운영 체제)로 Ubuntu 18.04를 지원합니다.

컨테이너 런타임 구성

컨테이너 런타임은 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리하는 소프트웨어입니다. 런타임은 Linux 또는 Windows에서 컨테이너를 실행하기 위해 sys-calls 또는 OS(운영 체제) 특정 기능을 추상화하는 데 도움이 됩니다. Linux 노드 풀의 경우 containerd는 Kubernetes 버전 1.19 이상을 사용하는 노드 풀에 사용됩니다. Windows Server 2019 노드 풀의 경우 containerd가 일반 공급되며 Kubernetes 1.21 이상에서 유일한 컨테이너 런타임 옵션이 됩니다. Docker는 2022년 9월부터 더 이상 지원되지 않습니다. 이 사용 중단에 대한 자세한 내용은 AKS 릴리스 정보를 참조하세요.

Containerd는 노드에서 컨테이너를 실행하고 이미지를 관리하는 데 필요한 최소한의 기능 세트를 제공하는 OCI(Open Container Initiative) 준수 핵심 컨테이너 런타임입니다. 이는 2017년 3월의 CNCF(Cloud Native Compute Foundation)에 기증되었습니다. AKS가 사용하는 현재 Moby(업스트림 Docker) 버전은 위에 표시된 것처럼 이미 containerd를 사용하고 있으며 그 위에 빌드됩니다.

containerd 기반 노드 및 노드 풀을 사용하면 kubelet은 dockershim과 대화하는 대신 CRI(컨테이너 런타임 인터페이스) 플러그 인을 통해 containerd와 직접 대화하여 Docker CRI 구현과 비교할 때 흐름의 추가 홉을 제거합니다. 따라서 Pod 시작 대기 시간이 단축되고 리소스(CPU 및 메모리) 사용량이 줄어듭니다.

AKS 노드에 containerd를 사용하면 Pod 시작 대기 시간이 개선되고 컨테이너 런타임에 의한 노드 리소스 사용량이 감소합니다. 이러한 개선은 Moby/docker 아키텍처에서 Kubelet이 containerd에 도달하기 전에 dockershim 및 Docker 엔진과 대화하는 동안 CRI 플러그 인을 통해 containerd에 직접 대화하는 이 새로운 아키텍처에 의해 사용되므로, 흐름에 홉이 추가됩니다.

Docker CRI 2

Containerd는 AKS의 모든 GA 버전과 v1.19 이상의 모든 업스트림 Kubernets 버전에서 작동하며 모든 Kubernetes 및 AKS 기능을 지원합니다.

중요

Kubernetes v1.19 이상에서 생성된 Linux 노드 풀이 있는 클러스터는 컨테이너 런타임에 대해 기본적으로 containerd로 설정됩니다. 이전에 지원되던 Kubernetes 버전의 노드 풀이 포함된 클러스터는 해당하는 컨테이너 런타임에 대한 Docker를 수신합니다. Linux 노드 풀은 노드 풀 Kubernetes 버전이 containerd를 지원하는 버전으로 업데이트되고 나면 containerd로 업데이트됩니다.

Windows Server 2019 노드 풀의 containerd는 일반적으로 사용할 수 있으며 Kubernetes 1.21 이상에서 유일한 컨테이너 런타임 옵션입니다. 1.23 이전 버전에서 Docker 노드 풀 및 클러스터를 계속 사용할 수 있지만 Docker는 2022년 9월부터 더 이상 지원되지 않습니다. 자세한 내용은 containerd로 Windows Server 노드 풀 추가를 참조하세요.

노드 풀에 대해 containerd를 지원하는 Kubernetes 버전이 있는 클러스터를 사용하기 전에 containerd로 AKS 노드 풀에서 워크로드를 테스트하는 것이 좋습니다.

Containerd 제한 사항/차이점

  • containerd의 경우, Kubernetes 노드에서 Pod, 컨테이너, 컨테이너 이미지의 문제 해결을 위해 Docker CLI 대신 crictl를 대체 CLI로 사용하는 것이 좋습니다(예: crictl ps).

    • Docker CLI의 전체 기능을 제공하지 않습니다. 문제 해결을 위한 용도로만 사용됩니다.
    • crictl은 Pod 등과 같은 개념이 있는 컨테이너에 대한 Kubernetes 친화적 보기를 제공합니다.
  • Containerd는 표준화된 cri 로깅 형식을 사용하여 로깅을 설정합니다(현재 Docker의 json 드라이버에서 가져오는 것과는 다름). 로깅 솔루션은 cri 로깅 형식(예: Azure Monitor for Containers)을 지원해야 합니다.

  • 더 이상 Docker 엔진 /var/run/docker.sock에 액세스하거나 DinD(Docker-in-Docker)를 사용할 수 없습니다.

    • 현재 Docker 엔진에서 애플리케이션 로그 또는 모니터링 데이터를 추출하는 경우 대신 Container Insights를 사용합니다. AKS는 불안정을 일으킬 수 있는 에이전트 노드에서 대역 외 명령을 실행하는 것을 지원하지 않습니다.
    • 위의 방법을 사용하여 이미지를 빌드하고 Docker 엔진을 직접 사용하는 것은 권장되지 않습니다. Kubernetes는 사용된 리소스를 완전히 인식하지 못하며, 이러한 방법은 여기여기에 설명된 대로 수많은 문제를 제시합니다.
  • 이미지 빌드 - AKS 클러스터 내에서 이미지를 빌드하지 않는 한 현재 Docker 빌드 워크플로를 정상적으로 계속 사용할 수 있습니다. 이 경우 ACR 작업을 사용하여 이미지를 빌드하는 데 권장되는 방법 또는 Docker Buildx와 같은 보다 안전한 클러스터 내 옵션으로 전환하는 것이 좋습니다.

2세대 가상 컴퓨터

Azure는 Gen2(2세대) VM(가상 머신)을 지원합니다. 2세대 VM은 1세대 VM(Gen1)에서 지원되지 않는 주요 기능을 지원합니다. 이러한 기능에는 메모리 증가, Intel SGX(Software Guard Extensions) 및 vPMEM(가상화된 영구 메모리)이 포함됩니다.

2세대 VM은 1세대 VM에서 사용되는 BIOS 기반 아키텍처 대신 새 UEFI 기반 부팅 아키텍처를 사용합니다. 특정 SKU 및 크기만 Gen2 VM을 지원합니다. SKU가 Gen2를 지원하거나 요구하는지 알아보려면 지원되는 크기 목록을 확인하세요.

또한 모든 VM 이미지가 Gen2를 지원하는 것은 아닙니다. AKS Gen2 VM에서는 새로운 AKS Ubuntu 18.04 이미지를 사용합니다. 이 이미지는 모든 Gen2 SKU 및 크기를 지원합니다.

기본 OS 디스크 크기 조정

기본적으로 새 클러스터를 만들거나 기존 클러스터에 새 노드 풀을 추가할 때 OS 디스크 크기는 vCPU 수에 따라 결정됩니다. vCPU 수는 VM SKU를 기반으로 하며 기본값은 다음 표에 나와 있습니다.

VM SKU 코어(vCPU) 수 기본 OS 디스크 계층 프로비전되는 IOPS 프로비전되는 처리량(Mpbs)
1~7 P10/128G 500 100
8~15 P15/256G 1100 125
16~63 P20/512G 2300 150
64 이상 P30/1024G 5,000 200

중요

기본 OS 디스크 크기 조정은 임시 OS 디스크가 지원되지 않고 기본 OS 디스크 크기가 지정되지 않은 경우에만 새 클러스터 또는 노드 풀에서 사용됩니다. 기본 OS 디스크 크기는 클러스터의 성능 또는 비용에 영향을 미칠 수 있으며 클러스터 또는 노드 풀을 만든 후에는 OS 디스크 크기를 변경할 수 없습니다. 이 기본 디스크 크기 조정은 2022년 7월 이상에서 만든 클러스터 또는 노드 풀에 영향을 줍니다.

임시 OS

기본적으로 Azure는 VM을 다른 호스트로 재배치해야 하는 경우 데이터 손실을 방지하기 위해 가상 머신의 운영 체제 디스크를 Azure 스토리지에 자동으로 복제합니다. 그러나 컨테이너는 로컬 상태를 유지하도록 설계되지 않았기 때문에 이 동작은 제한된 가치를 제공하는 동시에 노드 프로비저닝이 느려지고 읽기/쓰기 지연 시간이 길어지는 몇 가지 단점을 제공합니다.

이와 반대로 임시 OS 디스크는 임시 디스크처럼 호스트 머신에만 저장됩니다. 이 구성은 더 빠른 노드 크기 조정 및 클러스터 업그레이드와 함께 읽기/쓰기 대기 시간을 낮춥니다.

임시 디스크와 마찬가지로 임시 OS 디스크는 가상 머신 가격에 포함되어 있으므로 추가 스토리지 비용이 발생하지 않습니다.

중요

OS에 대한 관리 디스크를 명시적으로 요청하지 않는 경우 AKS는 지정된 노드 풀 구성에 대해 가능한 경우 임시 OS로 기본 설정됩니다.

임시 OS를 사용하도록 선택한 경우 OS 디스크가 VM 캐시에 맞아야 합니다. VM 캐시에 대한 크기 요구 사항 및 권장 사항은 Azure VM 설명서에서 사용할 수 있습니다.

기본 OS 디스크 크기가 100GB인 AKS 기본 VM 크기 Standard_DS2_v2 SKU를 사용하도록 선택한 경우 기본 VM 크기는 임시 OS를 지원하지만 캐시 크기는 86GB입니다. 명시적으로 지정하지 않으면 이 구성은 관리 디스크로 기본 설정됩니다. 임시 OS를 요청하면 유효성 검사 오류가 발생합니다.

60GB OS 디스크가 있는 동일한 Standard_DS2_v2 SKU를 요청하는 경우 이 구성은 기본적으로 임시 OS로 설정됩니다. 요청된 크기 60GB는 최대 캐시 크기인 86GB보다 작습니다.

100GB OS 디스크가 포함된 Standard_D8s_v3 SKU를 선택하면 이 VM 크기는 임시 OS를 지원하고 200GB의 캐시 공간이 있습니다. OS 디스크 형식을 지정하지 않으면 노드 풀은 기본적으로 임시 OS를 수신합니다.

최신 세대의 VM 시리즈에는 전용 캐시가 없고 임시 스토리지만 있습니다. 예를 들어 기본 OS 디스크 크기가 100GiB인 Standard_E2bds_v5 VM 크기를 사용한다고 가정해 보겠습니다. 이 VM 크기는 임시 OS 디스크를 지원하지만 75GiB의 임시 스토리지만 있습니다. 이 구성은 명시적으로 지정하지 않으면 기본적으로 관리되는 OS 디스크가 됩니다. 임시 OS 디스크를 요청하면 유효성 검사 오류가 발생합니다.

60GiB OS 디스크가 포함된 동일한 Standard_E2bds_v5 VM 크기를 요청하는 경우 이 구성은 임시 OS 디스크로 기본 설정됩니다. 요청된 크기 60GiB는 최대 임시 스토리지인 75GiB보다 작습니다.

100GiB OS 디스크와 함께 Standard_E4bds_v5 SKU를 사용하기로 선택한 경우 이 VM 크기는 임시 OS를 지원하고 150GiB의 임시 스토리지가 있습니다. OS 디스크 형식을 지정하지 않으면 노드 풀은 기본적으로 임시 OS로 프로비전됩니다.

임시 OS에는 Azure CLI 버전 2.15.0 이상이 필요합니다.

새 클러스터에서 임시 OS 사용

클러스터가 생성될 때 임시 OS 디스크를 사용하도록 클러스터를 구성합니다. --node-osdisk-type 플래그를 사용하여 임시 OS를 새 클러스터의 OS 디스크 유형으로 설정합니다.

az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type Ephemeral

네트워크에 연결된 OS 디스크를 사용하여 일반 클러스터를 만들려면 --node-osdisk-type=Managed를 지정하면 됩니다. 아래에 설명된 대로 임시 OS 노드 풀을 더 추가하도록 선택할 수도 있습니다.

기존 클러스터에서 임시 OS 사용

새 노드 풀을 구성하여 임시 OS 디스크를 사용합니다. --node-osdisk-type 플래그를 사용하여 OS 디스크 유형을 해당 노드 풀의 OS 디스크 유형으로 설정합니다.

az aks nodepool add --name ephemeral --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type Ephemeral

중요

임시 OS를 사용하면 VM 캐시 크기까지 VM 및 인스턴스 이미지를 배포할 수 있습니다. AKS의 경우 기본 노드 OS 디스크 구성은 128GB를 사용하므로 캐시가 128GB보다 큰 VM 크기가 필요합니다. 기본 Standard_DS2_v2의 캐시 크기는 86GB이며 이는 충분히 크지 않습니다. Standard_DS3_v2는 캐시 크기가 172GiB로 충분합니다. --node-osdisk-size를 사용하여 OS 디스크의 기본 크기를 줄일 수도 있습니다. AKS 이미지의 최소 크기는 30GB입니다.

네트워크에 연결된 OS 디스크로 노드 풀을 생성하려면 --node-osdisk-type Managed를 지정하면 됩니다.

Mariner OS

Mariner는 Azure CLI 또는 ARM 템플릿을 통해 AKS에 배포할 수 있습니다.

필수 구성 요소

  1. 최신 버전의 Azure CLI가 필요합니다. az --version을 실행하여 버전을 찾습니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.
  2. Mariner 2.0 운영 체제 SKU를 선택하려면 aks-preview Azure CLI 확장이 필요합니다. az extension remove --name aks-preview를 실행하여 이전 버전을 지운 다음 az extension add --name aks-preview를 실행합니다.
  3. 아직 kubectl을 설치하지 않은 경우 az aks install-cli를 사용하여 Azure CLI를 통해 설치하거나 업스트림 지침을 따릅니다.

Azure CLI를 사용하여 AKS Mariner 클러스터 배포

다음 예 명령을 사용하여 Mariner 클러스터를 만듭니다.

az group create --name MarinerTest --location eastus

az aks create --name testMarinerCluster --resource-group MarinerTest --os-sku mariner

az aks get-credentials --resource-group MarinerTest --name testMarinerCluster

kubectl get pods --all-namespaces

ARM 템플릿을 사용하여 AKS Mariner 클러스터 배포

기존 ARM 템플릿에 Mariner를 추가하려면 agentPoolProfiles"osSKU": "mariner""mode": "System"을 추가하고 apiVersion을 2021-03-01 이상("apiVersion": "2021-03-01")으로 설정해야 합니다. 다음 배포에서는 ARM 템플릿 "marineraksarm.yml"을 사용합니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.1",
  "parameters": {
    "clusterName": {
      "type": "string",
      "defaultValue": "marinerakscluster",
      "metadata": {
        "description": "The name of the Managed Cluster resource."
      }
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]",
      "metadata": {
        "description": "The location of the Managed Cluster resource."
      }
    },
    "dnsPrefix": {
      "type": "string",
      "metadata": {
        "description": "Optional DNS prefix to use with hosted Kubernetes API server FQDN."
      }
    },
    "osDiskSizeGB": {
      "type": "int",
      "defaultValue": 0,
      "minValue": 0,
      "maxValue": 1023,
      "metadata": {
        "description": "Disk size (in GB) to provision for each of the agent pool nodes. This value ranges from 0 to 1023. Specifying 0 will apply the default disk size for that agentVMSize."
      }
    },
    "agentCount": {
      "type": "int",
      "defaultValue": 3,
      "minValue": 1,
      "maxValue": 50,
      "metadata": {
        "description": "The number of nodes for the cluster."
      }
    },
    "agentVMSize": {
      "type": "string",
      "defaultValue": "Standard_DS2_v2",
      "metadata": {
        "description": "The size of the Virtual Machine."
      }
    },
    "linuxAdminUsername": {
      "type": "string",
      "metadata": {
        "description": "User name for the Linux Virtual Machines."
      }
    },
    "sshRSAPublicKey": {
      "type": "string",
      "metadata": {
        "description": "Configure all linux machines with the SSH RSA public key string. Your key should include three parts, for example 'ssh-rsa AAAAB...snip...UcyupgH azureuser@linuxvm'"
      }
    },
    "osType": {
      "type": "string",
      "defaultValue": "Linux",
      "allowedValues": [
        "Linux"
      ],
      "metadata": {
        "description": "The type of operating system."
      }
    },
    "osSKU": {
      "type": "string",
      "defaultValue": "mariner",
      "allowedValues": [
        "mariner",
        "Ubuntu",
      ],
      "metadata": {
        "description": "The Linux SKU to use."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2021-03-01",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('location')]",
      "properties": {
        "dnsPrefix": "[parameters('dnsPrefix')]",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "mode": "System",
            "osDiskSizeGB": "[parameters('osDiskSizeGB')]",
            "count": "[parameters('agentCount')]",
            "vmSize": "[parameters('agentVMSize')]",
            "osType": "[parameters('osType')]",
            "osSKU": "[parameters('osSKU')]",
            "storageProfile": "ManagedDisks"
          }
        ],
        "linuxProfile": {
          "adminUsername": "[parameters('linuxAdminUsername')]",
          "ssh": {
            "publicKeys": [
              {
                "keyData": "[parameters('sshRSAPublicKey')]"
              }
            ]
          }
        }
      },
      "identity": {
          "type": "SystemAssigned"
      }
    }
  ],
  "outputs": {
    "controlPlaneFQDN": {
      "type": "string",
      "value": "[reference(parameters('clusterName')).fqdn]"
    }
  }
}

시스템에 이 파일을 만들고 Mariner AKS YAML 파일의 콘텐츠로 채웁니다.

az group create --name MarinerTest --location eastus

az deployment group create --resource-group MarinerTest --template-file marineraksarm.yml --parameters clusterName=testMarinerCluster dnsPrefix=marineraks1 linuxAdminUsername=azureuser sshRSAPublicKey=`<contents of your id_rsa.pub>`

az aks get-credentials --resource-group MarinerTest --name testMarinerCluster

kubectl get pods --all-namespaces

Terraform을 사용하여 AKS Mariner 클러스터 배포

Terraform을 사용하여 Mariner 클러스터를 배포하려면 먼저 공급자를 버전 2.76 이상으로 설정해야 합니다 azurerm .

required_providers {
  azurerm = {
    source = "hashicorp/azurerm"
    version = "~> 2.76"
  }
}

공급자를 업데이트 azurerm 한 후에는 에서 default_node_poolMariner os_sku 를 지정할 수 있습니다.

default_node_pool {
  name = "default"
  node_count = 2
  vm_size = "Standard_D2_v2"
  os_sku = "CBLMariner"
}

마찬가지로 에서 Mariner os_skuazurerm_kubernetes_cluster_node_pool를 지정할 수 있습니다.

사용자 지정 리소스 그룹 이름

Azure에서 Azure Kubernetes Service 클러스터를 배포하면 작업자 노드에 대해 두 번째 리소스 그룹이 만들어집니다. 기본적으로 AKS는 노드 리소스 그룹의 MC_resourcegroupname_clustername_location이름을 로 지정하지만 사용자 지정 이름을 지정할 수도 있습니다.

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

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

자체 구독에서 Azure 리소스 공급자가 자동으로 보조 리소스 그룹을 만듭니다. 클러스터가 생성될 때만 사용자 지정 리소스 그룹 이름을 지정할 수 있습니다.

노드 리소스 그룹으로 작업할 때는 다음을 수행할 수 없습니다.

  • 노드 리소스 그룹에 기존 리소스 그룹을 지정합니다.
  • 노드 리소스 그룹에 다른 구독을 지정합니다.
  • 클러스터를 만든 후 노드 리소스 그룹 이름을 변경합니다.
  • 노드 리소스 그룹 내에서 관리 리소스의 이름을 지정합니다.
  • 노드 리소스 그룹 내에서 관리 리소스의 Azure에서 만든 태그를 수정하거나 삭제합니다.

노드 제한(미리 보기)

노드 제한 허용 컨트롤러는 kubelet에서 수정할 수 있는 Node 및 Pod 개체를 제한합니다. 노드 제한은 AKS 1.24 이상 클러스터에서 기본적으로 설정됩니다. 이전 버전을 사용하는 경우 아래 명령을 사용하여 노드 제한이 있는 클러스터를 만들거나 기존 클러스터를 업데이트하여 노드 제한을 추가합니다.

중요

AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.

시작하기 전에

다음 리소스가 설치되어 있어야 합니다.

  • Azure CLI
  • aks-preview 확장 버전 0.5.95 이상

aks-preview CLI 확장 설치

# Install the aks-preview extension
az extension add --name aks-preview

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

노드 제한이 있는 AKS 클러스터 만들기

노드 제한을 사용하여 클러스터를 만들려면 다음을 수행합니다.

az aks create -n aks -g myResourceGroup --enable-node-restriction

노드 제한이 있는 AKS 클러스터 업데이트

클러스터를 업데이트하려면 노드 제한을 사용합니다.

az aks update -n aks -g myResourceGroup --enable-node-restriction

AKS 클러스터에서 노드 제한 제거

클러스터에서 노드 제한를 제거하려면 다음을 수행합니다.

az aks update -n aks -g myResourceGroup --disable-node-restriction

OIDC 발급자

공급자의 OIDC 발급자 URL을 사용하도록 설정하면 API 서버에서 공개 서명 키를 검색할 수 있습니다. OIDC 공급자가 발급한 토큰의 최대 수명은 1일입니다.

경고

OIDC 발급자를 사용 또는 사용하지 않도록 설정하면 현재 서비스 계정 토큰 발급자가 새 값으로 변경되어 가동 중지 시간이 발생하고 API 서버가 다시 시작됩니다. OIDC 발급자를 사용 또는 사용하지 않도록 설정한 후에도 서비스 토큰을 사용하는 애플리케이션 Pod가 실패 상태로 남아 있으면 Pod를 수동으로 다시 시작하는 것이 좋습니다.

필수 구성 요소

  • Azure CLI 버전 2.42.0 이상. az --version를 실행하여 버전을 찾습니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.
  • AKS 버전 1.22 이상. 클러스터가 버전 1.21을 실행 중이고 OIDC 발급자 미리 보기가 사용하도록 설정된 경우 클러스터를 지원되는 최소 필수 버전으로 업그레이드하는 것이 좋습니다.

OIDC 발급자를 사용하여 AKS 클러스터 만들기

OIDC 발급자(미리 보기)를 사용하려면 --enable-oidc-issuer 매개 변수와 함께 az aks create 명령을 사용하여 AKS 클러스터를 만듭니다. 다음 예에서는 myResourceGroup에 하나의 노드가 있는 myAKSCluster라는 클러스터를 만듭니다.

az aks create -g myResourceGroup -n myAKSCluster --node-count 1 --enable-oidc-issuer

OIDC 발급자를 사용하여 AKS 클러스터 업데이트

OIDC 발급자(미리 보기)를 사용하려면 --enable-oidc-issuer 매개 변수와 함께 az aks update 명령을 사용하여 AKS 클러스터를 업데이트합니다. 다음 예에서는 myAKSCluster라는 클러스터를 업데이트합니다.

az aks update -g myResourceGroup -n myAKSCluster --enable-oidc-issuer 

OIDC 발급자 URL 표시

OIDC 발급자 URL을 가져오려면 다음 명령을 실행합니다. 클러스터 이름 및 리소스 그룹 이름의 기본값을 바꿉니다.

az aks show -n myAKScluster -g myResourceGroup --query "oidcIssuerProfile.issuerUrl" -otsv

OIDC 키 회전

OIDC 키를 회전하려면 다음 명령을 수행합니다. 클러스터 이름 및 리소스 그룹 이름의 기본값을 바꿉니다.

az aks oidc-issuer rotate-signing-keys -n myAKSCluster -g myResourceGroup

중요

키를 회전하면 이전 키(key1)는 24시간 후에 만료됩니다. 이는 이전 키(key1)와 새 키(key2)가 24시간 동안에는 둘 다 유효함을 의미합니다. 이전 키(key1)를 즉시 무효화하려면 OIDC 키를 두 번 회전해야 합니다. 그러면 key2와 key3은 유효하고 key1은 유효하지 않습니다.

다음 단계