☰

ARM/Bicep 템플릿을 통해 AKS 클러스터에 네트워크 기여자 역할을 할당하는 올바른 방법은 무엇입니까?

tag-icon • tag-icon azure kubernetes azure-networking aks azure-arm-template
ARM/Bicep 템플릿을 통해 AKS 클러스터에 네트워크 기여자 역할을 할당하는 올바른 방법은 무엇입니까?

Bicep/ARM을 사용하여 AKS 서버용 Load Balancer를 구성하려고 합니다. kubernetes에서 NGinx Ingress Controller를 사용하고 있는데 제대로 작동하는 것 같지만 처음 가동할 때 오류가 발생합니다.

주로 Azure 설명서의 이 단계에 해당하는 ARM 또는 Bicep 템플릿이 무엇인지 궁금합니다.

https://docs.microsoft.com/en-us/azure/aks/static-ip#create-a-service-using-the-static-ip-address

az role assignment create \
    --assignee <Client ID> \
    --role "Network Contributor" \
    --scope /subscriptions/<subscription id>/resourceGroups/<resource group name>

저는 Bicep을 사용하고 있으며 다음과 같은 AKS 서버를 만들었습니다.

resource ExampleKubernetes 'Microsoft.ContainerService/managedClusters@2021-07-01' = {
  // ...
}

그런 다음 다음과 같이 kubelet ID에 역할 할당을 추가합니다.

var NetworkContibutor = '4d97b98b-1d4f-4787-a291-c67834d212e7'
resource AssignNetworkContributorToKubelet 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = {
  name: guid(resourceGroup().id, ExampleKubernetes.id, NetworkContibutor)
  dependsOn: [
    ExampleKubernetes
  ]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', NetworkContibutor)
    principalType: 'ServicePrincipal'
    principalId: ExampleKubernetes.properties.identityProfile.kubeletidentity.objectId
  }
}

작동하는 것 같습니다. 대시보드에서 관리되는 주체에 할당된 역할을 볼 수 있습니다... 하지만 kubernetes의 서비스는 여전히 권한 문제로 인해 실패하는 것 같습니다.

  Error syncing load balancer: failed to ensure load balancer: Retriable: false,
  RetryAfter: 0s, HTTPStatusCode: 403, RawError: Retriable: false, RetryAfter:
  0s, HTTPStatusCode: 403, RawError:
  {"error":{"code":"AuthorizationFailed","message":"The client
  '<some guid A>' with object id
  '<some buid A>' does not have authorization to perform
  action 'Microsoft.Network/publicIPAddresses/read' over scope
  '/subscriptions/<subid>/resourceGroups/example/providers/Microsoft.Network/publicIPAddresses/example'
  or the scope is invalid. If access was recently granted, please refresh your
  credentials."}}

이상한 점은 나중에 어느 시점에서는 마법처럼 작동하는 것처럼 보인다는 것입니다. 해당 오류에는 "retriable false"라고 표시되며 서비스가 재시도하지 않는 것처럼 보이지만 이후에 kubernetes에 NGinx를 배포하면그 다음에재시도하고 갑자기 작동이 붐을 일으키게 만듭니다.

역할 전파에 비결정적 지연이 있다는 오류 메시지가 표시되는 것 같습니다. 따라서 제 질문은 다음과 같습니다.

  • 그렇죠? 실제로는 지연일 뿐이고 내 코드는 기본적으로 맞습니까?
  • 올바른 주체 ID를 사용하고 있나요? 아니면 실제로 불필요한가요?
  • 해당 역할 업데이트를 강제로 전파할 수 있는 방법이 있나요? 필요한 경우 그 사이에 CLI 단계를 둘 수 있습니다. 권한이 준비된 후 LB에 연결되는 수신 컨트롤러 설치를 어떻게 기다릴 수 있나요?

답변1

이전 답변이 올바른 것으로 간주되는 이유가 확실하지 않습니다. 여기서는 kubelet ID를 사용했습니다. 이는 인증하는 데 사용됩니다.Azure 컨테이너 레지스트리, 그러나 귀하의 경우에는 클러스터(제어판) ID를 사용해야 하며 시스템 관리 ID를 할당하는 방법을 찾을 수 없습니다. 나는 현재 유일한 방법은 자신의 것을 가져오는 것이라고 믿습니다.

1 관리 ID 추가창조ARM 템플릿에:

resource managedidentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: aksManIdentityName
  location: location
}

2 AKS ID 속성을 업데이트합니다.

  identity:{
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${managedidentity.id}': {}
    }
  }

3 네트워크 기여자 권한 부여

resource RBAC_Network_Contributor 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: resourceGroup()
  name: guid(resourceGroup().id, '${aksClusterName}-NetworkContributor') 
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', '4d97b98b-1d4f-4787-a291-c67834d212e7')
    principalId: managedidentity.properties.principalId
    principalType: 'ServicePrincipal'
  }
}

답변2

귀하의 질문에 대한 답변은 (직접적이지는 않지만)여기.

설명하는 동작은 다음에서 논의됩니다.이 구역. Azure Resource Manager는 성능 향상을 위해 구성과 데이터를 캐시하는 경우도 있으므로 역할을 할당하거나 역할 할당을 제거할 때 변경 내용이 적용되는 데 최대 30분이 걸릴 수 있습니다.

Azure CLI를 사용하면 역할 할당 변경 사항을 강제로 새로 고칠 수 있습니다.로그아웃 및 로그인.

관련 정보