Container Service for Kubernetes：Gunakan penjadwalan ulang hot spot berbasis beban

Batasan

• Hanya kluster Pro yang dikelola ACK yang didukung.

• Komponen terkait harus memenuhi persyaratan versi berikut.

  Component	Version requirements
  ACK Scheduler	v1.22.15-ack-4.0 atau yang lebih baru, v1.24.6-ack-4.0 atau yang lebih baru
  ack-koordinator	v1.1.1-ack.1 atau yang lebih baru
  Helm	v3.0 atau yang lebih baru

Penagihan

Komponen ack-koordinator dapat diinstal dan digunakan secara gratis. Namun, biaya tambahan mungkin dikenakan dalam skenario berikut:

• ack-koordinator adalah komponen yang dikelola sendiri dan mengonsumsi sumber daya node pekerja setelah instalasi. Anda dapat mengonfigurasi permintaan sumber daya untuk setiap modul saat menginstal komponen.

• Secara default, ack-koordinator mengekspos metrik pemantauan untuk fitur seperti profiling sumber daya dan penjadwalan detail halus dalam format Prometheus. Jika Anda memilih opsi Enable Prometheus Monitoring for ACK-Koordinator saat mengonfigurasi komponen dan menggunakan layanan Alibaba Cloud Prometheus, metrik ini dianggap sebagai custom metrics dan dikenai biaya. Biaya tergantung pada faktor seperti ukuran kluster dan jumlah aplikasi. Sebelum mengaktifkan fitur ini, baca dengan cermat dokumentasi Billing of Prometheus instances untuk Alibaba Cloud Prometheus guna memahami kuota gratis dan kebijakan penagihan untuk custom metrics. Anda dapat memantau dan mengelola penggunaan sumber daya dengan querying usage data.

Pengantar penjadwalan ulang hot spot berbasis beban

Penjadwalan berbasis beban

Penjadwal ACK mendukung penjadwalan berbasis beban yang dapat menjadwalkan pod ke node dengan beban rendah. Karena lingkungan kluster, lalu lintas, dan permintaan terus berubah, pemanfaatan node juga berubah secara dinamis. Hal ini dapat mengganggu keseimbangan beban antar node dalam kluster bahkan menyebabkan ketidakseimbangan beban yang parah, yang berdampak pada kualitas waktu proses workload. Komponen ack-koordinator dapat mengidentifikasi perubahan beban node dan secara otomatis menjadwalkan ulang pod dari node yang melebihi ambang batas beban aman untuk mencegah ketidakseimbangan beban yang parah. Anda dapat menggabungkan penjadwalan berbasis beban dengan penjadwalan ulang hot spot guna mencapai keseimbangan beban optimal di antara node. Untuk informasi selengkapnya, lihat Use load-aware pod scheduling.

Cara kerja modul Koordinator Descheduler

Komponen ack-koordinator menyediakan modul Koordinator Descheduler. Dalam modul ini, plugin LowNodeLoad mendeteksi tingkat beban dan melakukan penjadwalan ulang hot spot berbasis beban. Berbeda dengan plugin LowNodeUtilization dari descheduler Kubernetes native yang membuat keputusan berdasarkan tingkat alokasi sumber daya, plugin LowNodeLoad membuat keputusan penjadwalan ulang berdasarkan pemanfaatan sumber daya aktual node.

Prosedur eksekusi

Modul Koordinator Descheduler berjalan secara berkala. Setiap siklus eksekusi terdiri dari tiga tahap berikut.

1. Pengumpulan data: Mendapatkan informasi tentang node dan workload dalam kluster serta data pemanfaatan sumber daya terkaitnya.

2. Eksekusi plugin kebijakan.

   Langkah-langkah berikut menggunakan plugin LowNodeLoad sebagai contoh.

   1. Mengidentifikasi node hot spot. Untuk informasi lebih lanjut tentang klasifikasi node, lihat LowNodeLoad load threshold parameters.

   2. Menelusuri semua node hot spot, mengidentifikasi pod yang dapat dimigrasikan, dan mengurutkan pod tersebut. Untuk informasi lebih lanjut tentang cara penilaian dan pengurutan pod, lihat Pod scoring policy.

   3. Menelusuri semua pod yang akan dimigrasikan dan memeriksa apakah pod tersebut memenuhi persyaratan migrasi berdasarkan kendala seperti ukuran kluster, pemanfaatan sumber daya, dan rasio replika. Untuk informasi lebih lanjut, lihat Load-aware hot spot descheduling policies.

   4. Jika sebuah pod memenuhi kondisi, pod tersebut diklasifikasikan sebagai replika yang akan dimigrasikan. Jika tidak, proses melanjutkan penelusuran pod dan node hot spot lainnya.

3. Pengusiran dan migrasi pod: Mengusir pod yang memenuhi persyaratan migrasi. Untuk informasi lebih lanjut, lihat API-initiated Eviction.

LowNodeLoad Load Threshold Parameters

Sebagai contoh, pada gambar berikut, lowThresholds diatur ke 45% dan highThresholds diatur ke 70%. Node diklasifikasikan berdasarkan kriteria berikut. Demikian pula, jika nilai lowThresholds dan highThresholds berubah, kriteria klasifikasi node juga berubah sesuai.

Secara default, data pemanfaatan sumber daya diperbarui setiap menit dengan granularitas berupa nilai rata-rata selama 5 menit terakhir.

• Idle Node: Node dengan pemanfaatan sumber daya di bawah 45%.

• Normal Node: Node dengan pemanfaatan sumber daya lebih besar atau sama dengan 45% dan kurang dari atau sama dengan 70%. Tingkat beban ini merupakan rentang yang diinginkan.

• Hot Spot Node: Node dengan pemanfaatan sumber daya di atas 70%. Beberapa pod pada node hot spot diusir untuk menurunkan tingkat bebannya menjadi 70% atau kurang.

Kebijakan penjadwalan ulang hot spot berbasis beban

kubectl get event | grep stress-demo-588f9646cf-7****
55s         Normal    Evicting           podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
22s         Normal    EvictComplete      podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" has been evicted
55s         Normal    Descheduled        pod/stress-demo-588f9646cf-7****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
55s         Normal    Killing            pod/stress-demo-588f9646cf-7****                       Stopping container stress

Langkah 1: Aktifkan penjadwalan ulang di ack-koordinator

• Jika komponen ack-koordinator belum diinstal di kluster, instal komponen tersebut dan pilih Enable Descheduling For Ack-koordinator pada halaman konfigurasi komponen. Untuk informasi lebih lanjut, lihat Install the ack-koordinator component.

• Jika komponen ack-koordinator sudah diinstal di kluster Anda, pada halaman konfigurasi komponen, pilih Enable Descheduling For Ack-koordinator. Untuk prosedurnya, lihat Modify the ack-koordinator component.

Langkah 2: Aktifkan plugin penjadwalan ulang hot spot berbasis beban

1. Buat file `koord-descheduler-config.yaml` menggunakan konten YAML berikut.

   File `koord-descheduler-config.yaml` adalah objek ConfigMap yang digunakan untuk mengaktifkan plugin penjadwalan ulang LowNodeLoad.

   Klik untuk melihat konten file YAML

   # koord-descheduler-config.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: koord-descheduler-config
     namespace: kube-system
   data:
     koord-descheduler-config: |
       # Konten berikut adalah konfigurasi sistem koord-descheduler. Jangan ubah konfigurasi ini.
       apiVersion: descheduler/v1alpha2
       kind: DeschedulerConfiguration
       leaderElection:
         resourceLock: leases
         resourceName: koord-descheduler
         resourceNamespace: kube-system
       deschedulingInterval: 120s # Interval eksekusi. Plugin penjadwalan ulang berjalan setiap 120 detik.
       dryRun: false # Saklar mode read-only global. Jika diaktifkan, Koordinator Descheduler tidak melakukan operasi apa pun.
       # Akhir konfigurasi sistem.
   
       profiles:
       - name: koord-descheduler
         plugins:
           balance:
             enabled:
               - name: LowNodeLoad # Aktifkan plugin LowNodeLoad untuk penjadwalan ulang hot spot berbasis beban.
           evict:
             enabled:
               - name: MigrationController # Aktifkan pengontrol pengusiran dan migrasi.
   
         pluginConfig:
         - name: MigrationController # Parameter untuk kontrol penjadwalan ulang dan migrasi.
           args:
             apiVersion: descheduler/v1alpha2
             kind: MigrationControllerArgs
             defaultJobMode: EvictDirectly
   
         - name: LowNodeLoad # Konfigurasi plugin LowNodeLoad.
           args:
             apiVersion: descheduler/v1alpha2
             kind: LowNodeLoadArgs
   
             lowThresholds:  # lowThresholds menentukan ambang batas penerimaan untuk node idle. Sebuah node dianggap idle jika penggunaan semua sumber dayanya di bawah ambang batas ini.
               cpu: 20 # Pemanfaatan CPU adalah 20%.
               memory: 30  # Pemanfaatan Memori adalah 30%.
             highThresholds: # highThresholds menentukan ambang batas penerimaan untuk node hot spot. Sebuah node dianggap hot spot jika penggunaan salah satu sumber dayanya di atas ambang batas ini.
               cpu: 50  # Pemanfaatan CPU adalah 50%.
               memory: 60 # Pemanfaatan Memori adalah 60%.
   
             evictableNamespaces: # Namespace yang dapat dijadwalkan ulang. Parameter include dan exclude saling eksklusif. Anda hanya dapat mengonfigurasi salah satunya.
               include the following: # Parameter include menentukan bahwa hanya namespace berikut yang diproses.
                 - default
               # exclude: # Parameter exclude menentukan namespace yang dikecualikan.
                 # - "kube-system"
                 # - "koordinator-system"

2. Jalankan perintah berikut untuk menerapkan konfigurasi ke kluster.

   kubectl apply -f koord-descheduler-config.yaml

3. Jalankan perintah berikut untuk me-restart modul Koordinator Descheduler.

   Setelah Anda me-restart modul Koordinator Descheduler, Koordinator Descheduler menggunakan konfigurasi yang paling baru dimodifikasi.

   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0
   deployment.apps/ack-koord-descheduler scaled
   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1
   deployment.apps/ack-koord-descheduler scaled

Langkah 3 (Opsional): Aktifkan plugin load balancing penjadwal

Untuk mengaktifkan Plugin penyeimbang beban penjadwal demi keseimbangan beban optimal antar node, lihat Langkah 1: Aktifkan penjadwalan sadar beban.

Langkah 4: Verifikasi fitur penjadwalan ulang

Contoh berikut menggunakan kluster yang memiliki tiga node, masing-masing dengan 104 core dan memori 396 GiB.

1. Buat file `stress-demo.yaml` menggunakan konten YAML berikut.

   Click to view the YAML file content.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. Buat pod uji stres.

   kubectl create -f stress-demo.yaml
   deployment.apps/stress-demo created

3. Amati status pod hingga berjalan.

   kubectl get pod -o wide

   Output yang diharapkan:

   NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Running   0          82s   10.XX.XX.53   cn-beijing.10.XX.XX.53   <none>           <none>

   Output menunjukkan bahwa pod stress-demo-588f9646cf-s**** dijadwalkan ke node cn-beijing.10.XX.XX.53.

4. Tingkatkan tingkat beban node cn-beijing.10.XX.XX.53 lalu periksa beban setiap node.

   kubectl top node

   Output yang diharapkan:

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.215   17611m       17%    24358Mi         6%
   cn-beijing.10.XX.XX.53    63472m       63%    11969Mi         3%

   Output menunjukkan bahwa beban node cn-beijing.10.XX.XX.53 tinggi pada 63%, yang melebihi ambang batas hot spot yang dikonfigurasi sebesar 50%. Beban node cn-beijing.10.XX.XX.215 rendah pada 17%, yang berada di bawah ambang batas idle yang dikonfigurasi sebesar 20%.

5. Aktifkan penjadwalan ulang hot spot berbasis beban. Untuk informasi selengkapnya, lihat Langkah 2: Mengaktifkan Plugin penjadwalan ulang hot spot berbasis beban.

6. Amati perubahan pod.

   Tunggu descheduler memeriksa node hot spot dan melakukan pengusiran serta migrasi.

   Catatan

   Secara default, sebuah node diidentifikasi sebagai hot spot jika melebihi ambang batas hot spot selama lima pemeriksaan berturut-turut, yang membutuhkan waktu 10 menit.

   kubectl get pod -w

   Output yang diharapkan:

   NAME                           READY   STATUS               RESTARTS   AGE     IP           NODE                     NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Terminating          0          59s   10.XX.XX.53    cn-beijing.10.XX.XX.53     <none>           <none>
   stress-demo-588f9646cf-7****   1/1     ContainerCreating    0          10s   10.XX.XX.215   cn-beijing.10.XX.XX.215    <none>           <none>

7. Amati event.

   kubectl get event | grep stress-demo-588f9646cf-s****

   Output yang diharapkan:

   2m14s       Normal    Evicting            podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   101s        Normal    EvictComplete       podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" has been evicted
   2m14s       Normal    Descheduled         pod/stress-demo-588f9646cf-s****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   2m14s       Normal    Killing             pod/stress-demo-588f9646cf-s****                       Stopping container stress

   Output yang diharapkan adalah catatan migrasi, yang menunjukkan bahwa hasilnya sesuai harapan. Pod pada node hot spot dijadwalkan ulang ke node lain.

Konfigurasi lanjutan

Parameter konfigurasi lanjutan modul Koordinator Descheduler

Semua konfigurasi parameter untuk Koordinator Descheduler disediakan dalam ConfigMap. Berikut ini menunjukkan format parameter konfigurasi lanjutan untuk penjadwalan ulang hot spot berbasis beban.

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # Konten berikut adalah konfigurasi sistem koord-descheduler. Jangan ubah konfigurasi ini.
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s # Interval eksekusi. Plugin penjadwalan ulang berjalan setiap 120 detik.
    dryRun: false # Saklar mode read-only global. Jika diaktifkan, koord-descheduler tidak melakukan operasi apa pun.
    # Akhir konfigurasi sistem.

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule: 
          disabled:
            - name: "*" # Semua plugin dinonaktifkan secara default. Anda tidak perlu mengonfigurasi ini secara eksplisit. Ini hanya untuk tujuan demonstrasi.
        balance:
          enabled:
            - name: LowNodeLoad # Aktifkan plugin LowNodeLoad untuk penjadwalan ulang hot spot berbasis beban.
        evict:
          disabled:
            - name: "*" # Semua plugin dinonaktifkan secara default. Anda tidak perlu mengonfigurasi ini secara eksplisit. Ini hanya untuk tujuan demonstrasi.
          enabled:
            - name: MigrationController # Aktifkan pengontrol pengusiran dan migrasi.

      pluginConfig:
      - name: MigrationController # Parameter untuk kontrol penjadwalan ulang dan migrasi.
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1 # Jumlah maksimum pod yang dapat dalam status migrasi pada setiap node.
          maxMigratingPerNamespace: 1  # Jumlah maksimum pod yang dapat dalam status migrasi di setiap namespace.
          maxMigratingPerWorkload: 1 # Jumlah maksimum pod yang dapat dalam status migrasi di setiap workload, seperti deployment.
          maxUnavailablePerWorkload: 2 # Jumlah maksimum replika yang tidak tersedia untuk setiap workload, seperti deployment.
          evictLocalStoragePods: false # Menentukan apakah pod yang dikonfigurasi dengan HostPath atau EmptyDir diizinkan dijadwalkan ulang.
          objectLimiters:
            workload: # Throttling untuk migrasi pod di tingkat workload. Secara default, maksimal satu replika dapat dimigrasikan dalam 5 menit setelah pengusiran pertama.
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad # Konfigurasi plugin LowNodeLoad.
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:  # lowThresholds menentukan ambang batas penerimaan untuk node idle. Sebuah node dianggap idle jika penggunaan semua sumber dayanya di bawah ambang batas ini.
            cpu: 20 # Pemanfaatan CPU adalah 20%.
            memory: 30  # Pemanfaatan Memori adalah 30%.
          highThresholds: # highThresholds menentukan ambang batas penerimaan untuk node hot spot. Sebuah node dianggap hot spot jika penggunaan salah satu sumber dayanya di atas ambang batas ini.
            cpu: 50  # Pemanfaatan CPU adalah 50%.
            memory: 60 # Pemanfaatan Memori adalah 60%.

          anomalyCondition: # Konfigurasi pemeriksaan node hot spot.
            consecutiveAbnormalities: 5 # Sebuah node diidentifikasi sebagai hot spot hanya jika melebihi highThresholds selama beberapa siklus eksekusi berturut-turut. Penghitung direset setelah node hot spot diusir.

          detectorCacheTimeout: "5m" # Durasi timeout untuk cache pemeriksaan anomali. Nilai default: 5 menit. Pastikan nilai ini tidak kurang dari interval eksekusi yang ditentukan dalam deschedulingInterval.

          evictableNamespaces: # Namespace yang dapat dijadwalkan ulang. Parameter include dan exclude saling eksklusif. Anda hanya dapat mengonfigurasi salah satunya.
            include the following: # Parameter include menentukan bahwa hanya namespace berikut yang diproses.
              - default
            # exclude: # Parameter exclude menentukan namespace yang dikecualikan.
              # - "kube-system"
              # - "koordinator-system"

          nodeSelector: # Proses hanya node yang ditentukan.
            matchLabels:
              alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****

          podSelectors: # Proses hanya beberapa jenis pod.
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

Konfigurasi sistem Koordinator Descheduler

Konfigurasi kontrol pengusiran dan migrasi

type MigrationObjectLimiter struct {
    Duration time.Duration `json:"duration,omitempty"`
    MaxMigrating *intstr.IntOrString `json:"maxMigrating,omitempty"`
}

objectLimiters:
  workload:
    duration: 5m
    maxMigrating: 1

Konfigurasi plugin LowNodeLoad

highThresholds:
  cpu: 55 # Ambang batas hot spot pemanfaatan CPU adalah 55%.
  memory: 75 # Ambang batas hot spot pemanfaatan Memori adalah 75%.

lowThresholds:
  cpu: 25 # Ambang batas idle pemanfaatan CPU adalah 25%.
  memory: 25 # Ambang batas idle pemanfaatan Memori adalah 25%.

evictableNamespaces:
  exclude:
    - "kube-system"
    - "koordinator-system"

type PodSelector struct {
    name     string
    selector metav1.LabelSelector
}

# Proses hanya pod tipe LS.
podSelectors:
- name: lsPods
  selector:
    matchLabels:
      koordinator.sh/qosClass: "LS"

FAQ

Apa yang harus saya lakukan jika pemanfaatan node mencapai ambang batas tetapi pod pada node tersebut tidak diusir?

Masalah ini dapat terjadi karena alasan berikut. Anda dapat merujuk ke solusi yang sesuai untuk mengatasi masalah tersebut.

Mengapa descheduler sering restart?

Descheduler mungkin sering restart jika ConfigMap-nya tidak valid atau tidak ada. Untuk informasi lebih lanjut, lihat Advanced configuration. Periksa konten dan format ConfigMap, modifikasi ConfigMap, lalu restart descheduler. Untuk informasi lebih lanjut tentang cara me-restart descheduler, lihat Step 2: Enable the load-based hot spot descheduling plug-in.

Bagaimana cara menggunakan penjadwalan berbasis beban dan penjadwalan ulang hot spot berbasis beban secara bersamaan?

Setelah Anda mengaktifkan penjadwalan ulang hot spot berbasis beban, Pod pada node hot spot dievakuasi. Penjadwal ACK memilih node yang sesuai untuk Pod yang dibuat oleh controller lapisan atas, seperti Deployment. Untuk mencapai keseimbangan beban optimal, kami merekomendasikan Anda mengaktifkan penjadwalan sadar beban pada saat yang bersamaan. Untuk informasi lebih lanjut, lihat Gunakan penjadwalan sadar beban.

Kami merekomendasikan Anda untuk mengatur parameter loadAwareThreshold untuk penjadwalan berbasis beban ke nilai yang sama dengan parameter highThresholds dari K8s Spot Rescheduler. Untuk informasi selengkapnya, lihat Kebijakan Penjadwalan. Ketika beban node melebihi highThresholds, K8s Spot Rescheduler akan mengevakuasi pod pada node tersebut. Penjadwal kemudian menggunakan loadAwareThreshold untuk mencegah pod baru dijadwalkan ke node hot spot. Jika Anda tidak mengatur parameter ke nilai yang sama, pod yang dievakuasi mungkin akan dijadwalkan ulang ke node hot spot. Masalah ini lebih mungkin terjadi jika sebuah pod memiliki cakupan yang ditentukan untuk node yang dapat dijadwalkan, tetapi hanya sejumlah kecil node yang tersedia dan pemanfaatan sumber daya node-node tersebut serupa.

Apa algoritma pemanfaatan yang dirujuk oleh penjadwalan ulang?

Descheduler terus memantau penggunaan sumber daya untuk periode tertentu dan menghitung nilai rata-rata. Sebuah node dijadwalkan ulang hanya jika rata-rata penggunaan sumber dayanya tetap di atas ambang batas untuk periode tertentu, yaitu 10 menit secara default. Untuk memori, perhitungan penggunaan descheduler mengecualikan page cache karena sistem operasi dapat mereklaim sumber daya ini. Sebaliknya, nilai penggunaan yang dikembalikan oleh perintah kubectl top node mencakup page cache. Anda dapat menggunakan Managed Service for Prometheus untuk melihat penggunaan memori aktual.