Aktifkan atau nonaktifkan penyediaan otomatis node (NAP) di Azure Kubernetes Service (AKS)

Artikel ini menjelaskan cara mengaktifkan atau menonaktifkan provisi otomatis simpul (NAP) di Azure Kubernetes Service (AKS) menggunakan templat Azure CLI atau Azure Resource Manager (ARM).

Jika Anda ingin membuat kluster AKS dengan dukungan NAP dengan jaringan virtual kustom (VNet) dan subnet, lihat Membuat kluster provisi otomatis simpul (NAP) di jaringan virtual kustom.

Sebelum Anda mulai

Sebelum memulai, tinjau Ikhtisar provisi otomatis simpul (NAP) pada artikel di AKS, yang merinci cara kerja NAP, prasyarat, dan batasan.

Mengaktifkan provisi otomatis simpul (NAP) pada kluster AKS

Bagian berikut menjelaskan cara mengaktifkan NAP pada kluster AKS baru atau yang sudah ada:

Nota

Anda dapat mengaktifkan metrik control plane untuk melihat log dan operasi dari penyediaan otomatis node dengan layanan terkelola Azure Monitor untuk add-on Prometheus.

Mengaktifkan NAP pada kluster baru

  • Aktifkan auto-provisioning node pada kluster baru dengan menggunakan perintah az aks create dan flag --node-provisioning-mode diatur ke Auto. Perintah berikut juga mengatur --network-plugin ke azure, --network-plugin-mode ke overlay, dan --network-dataplane ke cilium.

    az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Auto \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --generate-ssh-keys

  1. Buat file bernama nap.json dan tambahkan konfigurasi templat ARM berikut dengan bidang properties.nodeProvisioningProfile.mode diatur ke Auto untuk mengaktifkan NAP. (Pengaturan defaultnya adalah Manual.)

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Auto"
        }
      }
    }
  ]
}

  2. Aktifkan provisi otomatis node pada kluster baru menggunakan az deployment group create perintah dengan flag --template-file yang diatur ke path file templat ARM.

    az deployment group create --resource-group $RESOURCE_GROUP --template-file ./nap.json

Mengaktifkan NAP pada kluster yang ada

  • Aktifkan provisi otomatis node pada kluster yang ada menggunakan perintah dengan bendera disetel ke .

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --node-provisioning-mode Auto

Menonaktifkan penyediaan otomatis node (NAP) pada cluster AKS

Penting

Anda hanya dapat menonaktifkan NAP pada kluster jika kondisi berikut terpenuhi:

  • Tidak ada simpul NAP yang ada. Anda dapat menggunakan perintah kubectl get nodes -l karpenter.sh/nodepool untuk memeriksa simpul yang dikelola NAP yang ada.
  • Semua Karpenter NodePools yang ada memiliki bidang spec.limits.cpu diatur ke 0. Tindakan ini mencegah simpul baru dibuat, tetapi tidak mengganggu simpul yang sedang berjalan.

  1. Atur spec.limits.cpu bidang ke 0 untuk setiap Karpenter NodePoolyang ada. Contohnya:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  limits:
    cpu: 0

    Penting

    Jika Anda tidak ingin memastikan bahwa setiap pod yang sebelumnya berjalan pada simpul NAP dimigrasikan dengan aman ke node non-NAP sebelum menonaktifkan NAP, Anda dapat melewati langkah 2 dan 3 dan sebaliknya menggunakan kubectl delete node perintah untuk setiap simpul yang dikelola NAP. Namun, kami tidak menyarankan untuk melewati langkah-langkah ini, karena ini dapat menyebabkan beberapa pod tertunda dan tidak menghormati Anggaran Gangguan Pod (PDB).

    Saat menggunakan kubectl delete node perintah , berhati-hatilah untuk hanya menghapus simpul yang dikelola NAP. Anda dapat mengidentifikasi simpul yang dikelola NAP menggunakan kubectl get nodes -l karpenter.sh/nodepool perintah .

  2. karpenter.azure.com/disable:NoSchedule Tambahkan taint ke setiap Karpenter NodePool. Contohnya:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      ...
      taints:
        - key: karpenter.azure.com/disable
          effect: NoSchedule

    Tindakan ini memulai proses migrasi beban kerja di simpul yang dikelola NAP ke simpul non-NAP, mematuhi PDB dan batas gangguan. Pod bermigrasi ke node non-NAP jika bisa ditampung. Jika kapasitas berukuran tetap tidak mencukupi, beberapa simpul yang dikelola NAP akan tetap ada.

  3. Ukuran tetap yang ada tingkatkan skalanya ManagedClusterAgentPools atau buat ukuran tetap baru AgentPools untuk mengambil beban dari simpul-simpul yang dikelola oleh NAP. Karena simpul ini ditambahkan ke kluster, simpul yang dikelola oleh NAP dikosongkan, dan pekerjaan dipindahkan ke simpul berukuran tetap.

  4. Hapus semua simpul yang dikelola NAP menggunakan perintah kubectl get nodes -l karpenter.sh/nodepool. Jika simpul yang dikelola NAP masih ada, kluster kemungkinan tidak memiliki kapasitas ukuran tetap. Dalam hal ini, Anda harus menambahkan lebih banyak simpul sehingga beban kerja yang tersisa dapat dimigrasikan.

  1. Perbarui mode NAP ke Manual menggunakan perintah az aks update Azure CLI dengan bendera --node-provisioning-mode diatur ke Manual.

    az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Manual

  1. Perbarui bidang properties.nodeProvisioningProfile.mode menjadi Manual di dalam templat ARM Anda dan lakukan penerapan ulang.

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Manual"
        }
      }
    }
  ]
}

Bermigrasi dari Karpenter open source yang dihosting sendiri ke provisioning otomatis node terkelola (NAP)

Jika Karpenter diinstal dari chart Helm sumber terbuka, Anda masih dapat mengaktifkan NAP di kluster Anda. Langkah-langkah ini mengasumsikan bahwa bagan Karpenter Helm diinstal.

Penting

Pastikan Anda menjalankan versi latest Karpenter sebelum memulai migrasi. NAP selalu menjalankan versi terbaru.

Penting

Berhati-hatilah untuk tidak menghapus CRD Karpenter saat melakukan proses migrasi ini. Jika CRD dihapus, CRD akan menghapus NodeClaims yang mendasar, yang dapat mengganggu beban kerja Anda.

  1. Untuk memastikan CRD Karpenter tidak dihapus instalannya di langkah 2, hapus managed-by=Helm label dan anotasi.:

    kubectl get crds -l app.kubernetes.io/managed-by=Helm -o name | grep karpenter.azure.com | xargs -I{} kubectl patch {} --type=json -p '
[
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-name"},
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-namespace"},
  {"op":"remove","path":"/metadata/labels/app.kubernetes.io~1managed-by"}
]'

  2. Hapus instalan bagan Helm untuk menghapus Penyebaran, Layanan, Peran, dan sumber daya lain yang digunakan oleh sumber terbuka Karpenter. Pada titik ini, Karpenter tidak lagi bereaksi terhadap peristiwa penskalakan, tetapi simpul yang ada terus berfungsi.

    helm uninstall karpenter -n kube-system  # If you installed Karpenter into a different namespace than kube-system, specify that here instead of kube-system

  3. Aktifkan NAP pada kluster Anda:

    az aks update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --node-provisioning-mode Auto --node-provisioning-default-pools None

    Perintah ini menonaktifkan NodePools default karena Anda memiliki NodePools yang ada dan ingin terus menggunakannya. Jika Anda ingin mengaktifkan pool default node auto-provisioning, Anda dapat menghilangkan --node-provisioning-default-pools None dari perintah az aks update.

  4. Verifikasi migrasi selesai: Ketika az aks update dari langkah 3 berhasil diselesaikan, migrasi dilakukan. Anda juga dapat mengonfirmasi bahwa migrasi dilakukan dengan memeriksa anotasi pada CRD Karpenter. Anda harus melihat:

        meta.helm.sh/release-name: aks-managed-karpenter-overlay-base
    meta.helm.sh/release-namespace: kube-system

    Pada titik ini, NAP diaktifkan dan penskalakan otomatis harus dilanjutkan.

Pemantauan penyediaan otomatis Node

Mengambil log dan status Karpenter

Anda dapat mengambil log dan pembaruan status dari Karpenter untuk membantu mendiagnosis dan men-debug peristiwa terkait NAP. AKS mengelola penyediaan otomatis node atas nama Anda dan menjalankannya di control plane yang dikelola. Anda dapat mengaktifkan log plane kontrol untuk melihat log dan operasi Karpenter dari provisi otomatis node. Untuk informasi selengkapnya tentang log sarana kontrol, lihat dokumentasi log sarana kontrol AKS

  1. Siapkan aturan log sumber daya untuk mengirim log provisi otomatis simpul ke Log Analytics menggunakan instruksi di sini. Pastikan Anda mencentang kotak node-auto-provisioning saat memilih opsi untuk Log.

  2. Pilih bagian Log pada kluster Anda.

  3. Masukkan contoh kueri berikut ke dalam Log Analytics:

    AKSControlPlane
| where Category == "karpenter-events"

  4. Lihat peristiwa provisi otomatis simpul di CLI:

    kubectl get events --field-selector source=karpenter-events

Metrik provisi otomatis node

Anda dapat mengaktifkan metrik control plane (Pratinjau) untuk melihat metrik Karpenter dan operasi tertentu dari provisi otomatis node dengan add-on Prometheus pada layanan Azure Monitor yang terkelola.

Langkah selanjutnya

Untuk informasi selengkapnya tentang node auto-provisioning di AKS, lihat artikel berikut ini:

  • Last updated on