Score:0

วิธีที่ถูกต้องในการกำหนดบทบาทผู้สนับสนุนเครือข่ายให้กับคลัสเตอร์ AKS ผ่านเทมเพลต ARM / Bicep คืออะไร

ธง cn

ฉันกำลังพยายามกำหนดค่า Load Balancer สำหรับเซิร์ฟเวอร์ AKS ของฉันโดยใช้ Bicep/ARM ฉันใช้ NGinx Ingress Controller ใน kubernetes และดูเหมือนว่าจะใช้งานได้ แต่เมื่อฉันหมุนสิ่งต่างๆ เป็นครั้งแรก ฉันพบข้อผิดพลาด

ส่วนใหญ่ฉันสงสัยว่าเทมเพลต ARM หรือ Bicep ที่เทียบเท่าสำหรับขั้นตอนนี้ในเอกสาร Azure คืออะไร

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

สร้างการกำหนดบทบาท az \
    --ผู้รับมอบสิทธิ์ <รหัสลูกค้า> \
    --บทบาท "ผู้สนับสนุนเครือข่าย" \
    --scope /subscriptions/<subscription id>/resourceGroups/<ชื่อกลุ่มทรัพยากร>

ฉันใช้ Bicep และสร้างเซิร์ฟเวอร์ AKS ของฉันดังนี้:

ทรัพยากร ExampleKubernetes 'Microsoft.ContainerService/managedClusters@2021-07-01' = {
  // ...
}

ฉันจะเพิ่มการกำหนดบทบาทให้กับตัวตนของ kubelet ดังนี้:

var NetworkContibutor = '4d97b98b-1d4f-4787-a291-c67834d212e7'
ทรัพยากร AssignNetworkContributorToKubelet 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = {
  ชื่อ: guid(resourceGroup().id, ExampleKubernetes.id, NetworkContibutor)
  ขึ้นอยู่กับ: [
    ตัวอย่างKubernetes
  ]
  คุณสมบัติ: {
    roleDefinitionId: subscribeResourceId('Microsoft.Authorization/roleDefinitions', NetworkContibutor)
    ประเภทหลัก: 'ServicePrincipal'
    รหัสหลัก: ExampleKubernetes.properties.identityProfile.kubeletidentity.objectId
  }
}

ซึ่งดูเหมือนว่าจะใช้งานได้ ฉันเห็นบทบาทที่กำหนดให้กับตัวหลักที่ได้รับการจัดการในแดชบอร์ด... แต่ดูเหมือนว่าบริการใน kubernetes จะล้มเหลวโดยที่ยังมีปัญหาการอนุญาตอยู่:

  ข้อผิดพลาดในการซิงค์โหลดบาลานเซอร์: ล้มเหลวในการตรวจสอบโหลดบาลานเซอร์: เรียกคืนได้: เท็จ
  RetryAfter: 0s, HTTPStatusCode: 403, RawError: Retriable: เท็จ, RetryAfter:
  0s, HTTPStatusCode: 403, RawError:
  {"ข้อผิดพลาด":{"code":"การอนุญาตล้มเหลว","ข้อความ":"ไคลเอนต์
  '<some guid A>' พร้อมรหัสวัตถุ
  '<some buid A>' ไม่ได้รับอนุญาตให้ดำเนินการ
  การดำเนินการ 'Microsoft.Network/publicIPAddresses/read' ในขอบเขต
  '/subscriptions/<subid>/resourceGroups/example/providers/Microsoft.Network/publicIPAddresses/example'
  หรือขอบเขตไม่ถูกต้อง หากเพิ่งได้รับสิทธิ์การเข้าถึง โปรดรีเฟรช
  ข้อมูลประจำตัว"}}

ที่แปลกคือเมื่อถึงจุดหนึ่งดูเหมือนว่าจะใช้งานได้อย่างน่าอัศจรรย์ ข้อผิดพลาดนั้นระบุว่า "retriable false" และดูเหมือนว่าบริการจะไม่ลองใหม่ แต่การปรับใช้ NGinx กับ kubernetes ในภายหลังจะ แล้ว ทำให้มันลองใหม่และมันก็ทำงานได้อย่างกระทันหัน

ดูเหมือนว่าข้อความแสดงข้อผิดพลาดจะบอกฉันว่ามีความล่าช้าในการเผยแพร่บทบาทที่ไม่ได้กำหนด ... ดังนั้นคำถามของฉันคือ:

  • นั่นถูกต้องใช่ไหม? จริง ๆ แล้วเป็นเพียงความล่าช้าและรหัสของฉันถูกต้องหรือไม่
  • ฉันใช้รหัสหลักที่ถูกต้องหรือไม่ หรือว่าไม่จำเป็นจริง ๆ ?
  • มีวิธีที่ฉันบังคับให้การอัปเดตบทบาทเหล่านั้นเผยแพร่หรือไม่ ฉันสามารถมีขั้นตอนระหว่าง CLI ได้หากต้องการ ฉันจะรอติดตั้งตัวควบคุมขาเข้าซึ่งเชื่อมต่อกับ LB หลังจากสิทธิ์พร้อมได้อย่างไร
Score:0
ธง us

คำถามของคุณ (แม้ว่าจะไม่ตรง) ได้รับคำตอบแล้ว ที่นี่.

พฤติกรรมที่คุณกำลังอธิบายถูกกล่าวถึงใน ส่วนนี้. เนื่องจากบางครั้ง Azure Resource Manager จะแคชการกำหนดค่าและข้อมูลเพื่อปรับปรุงประสิทธิภาพ บางครั้งอาจใช้เวลาถึง 30 นาทีเพื่อให้การเปลี่ยนแปลงมีผลเมื่อคุณกำหนดบทบาทหรือลบการมอบหมายบทบาท

เมื่อใช้ Azure CLI คุณสามารถบังคับให้รีเฟรชการเปลี่ยนแปลงการมอบหมายบทบาทของคุณได้ ออกจากระบบและลงชื่อเข้าใช้.

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา