Konsep Core Kubernetes untuk Azure Kubernetes Service (AKS)

Artikel ini menjelaskan konsep inti Azure Kubernetes Service (AKS), layanan Kubernetes terkelola yang dapat Anda gunakan untuk menyebarkan dan mengoperasikan aplikasi kontainer dalam skala besar di Azure. Ini membantu Anda mempelajari tentang komponen infrastruktur Kubernetes dan mendapatkan pemahaman yang lebih mendalam tentang cara kerja Kubernetes di AKS.

Apa itu Kubernetes?

Kube adalah platform yang berkembang pesat yang mengelola aplikasi berbasis kontainer serta komponen jaringan dan penyimpanan yang terkait. Kubernetes berfokus pada beban kerja aplikasi dan bukan komponen infrastruktur yang mendasar. Kube menyediakan pendekatan deklaratif untuk penyebaran, didukung oleh set API yang kuat untuk operasi manajemen.

Anda dapat membangun dan menjalankan aplikasi modern, portabel, berbasis layanan mikro menggunakan Kubernetes untuk mengatur dan mengelola ketersediaan komponen aplikasi. Kubernetes mendukung aplikasi stateless dan stateful.

Sebagai platform terbuka, Kube memungkinkan Anda untuk membangun aplikasi dengan bahasa komputer, OS, pustaka, atau bus Olahpesan pilihan Anda. Alat integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) yang ada dapat diintegrasikan dengan Kube untuk menjadwalkan dan menyebarkan rilis.

AKS menyediakan layanan Kubernetes terkelola yang mengurangi kompleksitas tugas penyebaran dan manajemen inti. Platform Azure mengelola sarana kontrol AKS, dan Anda hanya membayar simpul AKS yang menjalankan aplikasi Anda.

Arsitektur kluster Kube

Kluster Kube dibagi menjadi dua komponen:

• Sarana kontrol, yang menyediakan layanan inti Kubernetes dan orkestrasi beban kerja aplikasi, dan
• Simpul, yang menjalankan beban kerja aplikasi Anda.

Sarana kontrol

Saat Anda membuat kluster AKS, platform Azure secara otomatis membuat dan mengonfigurasi sarana kontrol terkait. Sarana kontrol penyewa tunggal ini disediakan tanpa biaya sebagai sumber daya Azure terkelola yang diabstraksi dari pengguna. Anda hanya membayar simpul yang terlampir pada kluster AKS. Sarana kontrol dan sumber dayanya hanya berada di wilayah tempat Anda membuat kluster.

Sarana kontrol mencakup komponen core Kube berikut:

Komponen	Deskripsi
kube-apiserver	Server API mengekspos API Kubernetes yang mendasar dan menyediakan interaksi untuk alat manajemen, seperti kubectl atau dasbor Kubernetes.
etcd	etcd adalah penyimpanan nilai kunci yang sangat tersedia dalam Kubernetes yang membantu mempertahankan status kluster dan konfigurasi Kubernetes Anda.
penjadwal kube	Saat Anda membuat atau menskalakan aplikasi, penjadwal menentukan simpul apa yang dapat menjalankan beban kerja dan memulai simpul yang diidentifikasi.
manajer pengontrol kube	Manajer pengontrol mengawasi sejumlah pengontrol yang lebih kecil yang melakukan tindakan seperti mereplikasi pod dan menangani operasi simpul.

Perlu diingat bahwa Anda tidak dapat langsung mengakses sarana kontrol. Peningkatan sarana kontrol dan simpul Kube diatur melalui Azure CLI atau portal Microsoft Azure. Untuk memecahkan masalah yang mungkin terjadi, Anda dapat meninjau log sarana kontrol menggunakan Azure Monitor.

Simpul

Untuk menjalankan aplikasi dan layanan pendukung, Anda memerlukan Node kube. Setiap kluster AKS memiliki setidaknya satu simpul, komputer virtual Azure (VM) yang menjalankan komponen node Kubernetes, dan runtime kontainer.

Simpul mencakup komponen Kubernetes inti berikut:

Komponen	Deskripsi
kubelet	Agen Kubernetes yang memproses permintaan pengaturan dari sarana kontrol bersama dengan penjadwalan dan eksekusi kontainer yang diminta.
proksi kube	Proksi menangani jaringan virtual pada setiap simpul, merutekan lalu lintas jaringan, dan mengelola alamat IP untuk layanan dan pod.
runtime bahasa umum kontainer	Runtime kontainer memungkinkan aplikasi kontainer untuk menjalankan dan berinteraksi dengan sumber daya lain, seperti jaringan virtual atau penyimpanan. Untuk informasi selengkapnya, lihat Konfigurasi runtime kontainer.

Ukuran Azure VM untuk simpul Anda menentukan CPU, memori, ukuran, dan jenis penyimpanan yang tersedia, seperti SSD berkinerja tinggi atau HDD reguler. Rencanakan ukuran simpul di sekitar apakah aplikasi Anda mungkin memerlukan sejumlah besar CPU dan memori atau penyimpanan berkinerja tinggi. Luaskan skala jumlah simpul di kluster AKS Anda untuk memenuhi permintaan. Untuk informasi selengkapnya tentang penskalaan, lihat Opsi penskalaan untuk aplikasi di AKS.

Di AKS, gambar VM untuk simpul kluster Anda didasarkan pada Ubuntu Linux, Azure Linux, atau Windows Server 2022. Saat Anda membuat kluster AKS atau meluaskan skala jumlah simpul, platform Azure secara otomatis membuat dan mengonfigurasi jumlah komputer virtual yang diminta. Simpul agen ditagih sebagai VM standar, sehingga diskon ukuran VM apa pun, termasuk reservasi Azure, diterapkan secara otomatis.

Untuk disk terkelola, ukuran dan performa disk default ditetapkan sesuai dengan jumlah SKU dan vCPU VM yang dipilih. Untuk mengetahui informasi selengkapnya, lihat Ukuran disk OS default.

Konfigurasi OS

AKS mendukung Ubuntu 22.04 dan Azure Linux 2.0 sebagai sistem operasi node (OS) untuk kluster dengan Kubernetes 1.25 dan yang lebih tinggi. Ubuntu 18.04 juga dapat ditentukan pada pembuatan kumpulan simpul untuk Kubernetes versi 1.24 ke bawah.

AKS mendukung Windows Server 2022 sebagai OS default untuk kumpulan simpul Windows dalam kluster dengan Kubernetes 1.25 dan yang lebih tinggi. Windows Server 2019 juga dapat ditentukan pada pembuatan kumpulan simpul untuk Kubernetes versi 1.32 ke bawah. Windows Server 2019 dihentikan setelah Kubernetes versi 1.32 mencapai akhir masa pakai dan tidak didukung dalam rilis mendatang. Untuk informasi selengkapnya tentang penghentian ini, lihat catatan rilis AKS.

Konfigurasi runtime bahasa umum kontainer

Runtime bahasa umum kontainer adalah perangkat lunak yang menjalankan kontainer dan mengelola citra kontainer pada simpul. Runtime membantu mengabstraksi panggilan sys atau fungsionalitas khusus OS untuk menjalankan kontainer di Linux atau Windows. Untuk kumpulan simpul Linux, containerd digunakan pada Kubernetes versi 1.19 dan yang lebih tinggi. Untuk kumpulan simpul Windows Server 2019 dan 2022, containerd umumnya tersedia dan merupakan satu-satunya opsi runtime pada Kubernetes versi 1.23 dan yang lebih tinggi. Pada Mei 2023, Docker dihentikan dan tidak lagi didukung. Untuk informasi selengkapnya tentang penghentian ini, lihat catatan rilis AKS.

Containerd adalah runtime bahasa umum kontainer inti yang sesuai dengan OCI (Open kontainer Initiative/Inisiatif Kontainer Terbuka) yang menyediakan set minimum fungsionalitas yang diperlukan untuk menjalankan kontainer dan mengelola citra pada simpul. Dengancontainerd simpul berbasis dan kumpulan simpul, kubelet berbicara langsung dengan containerd menggunakan plugin CRI (antarmuka runtime kontainer), menghapus hop tambahan dalam aliran data jika dibandingkan dengan implementasi Docker CRI. Dengan demikian, Anda melihat latensi startup pod yang lebih baik dan lebih sedikit penggunaan sumber daya (CPU dan memori).

Containerd bekerja pada setiap versi GA Kubernetes di AKS, di setiap versi Kubernetes mulai dari v1.19, dan mendukung semua fitur Kubernetes dan AKS.

containerd batasan/perbedaan

• Untuk containerd, sebaiknya gunakan crictl sebagai pengganti Docker CLI untuk memecahkan masalah pod, kontainer, dan gambar kontainer pada simpul Kubernetes. Untuk informasi selengkapnya tentang crictl, lihat opsi penggunaan umum dan konfigurasi klien.

  • Containerd tidak menyediakan fungsionalitas lengkap Docker CLI. Ini hanya tersedia untuk pemecahan masalah.
  • crictl menawarkan tampilan kontainer yang lebih ramah kubernetes, dengan konsep seperti pod, dll. hadir.

• Containerd menyiapkan pengelogan menggunakan format pengelogan standar cri . Solusi pengelogan Anda perlu mendukung format pengelogan cri , seperti Azure Monitor untuk Kontainer.

• Anda tidak dapat lagi mengakses mesin Docker, /var/run/docker.sock, atau menggunakan Docker-in-Docker (DinD).

  • Jika saat ini Anda mengekstrak log aplikasi atau memantau data dari mesin Docker, gunakan Container Insights sebagai gantinya. AKS tidak mendukung menjalankan perintah di luar band pada simpul agen yang dapat menyebabkan ketidakstabilan.
  • Kami tidak merekomendasikan untuk membuat gambar atau langsung menggunakan mesin Docker. Kubernetes tidak sepenuhnya menyadari sumber daya yang dikonsumsi, dan metode tersebut menyajikan banyak masalah seperti yang dijelaskan di sini dan di sini.

• Saat membuat gambar, Anda dapat terus menggunakan alur kerja build Docker saat ini seperti biasa, kecuali Anda membangun gambar di dalam kluster AKS Anda. Dalam hal ini, pertimbangkan untuk beralih ke pendekatan yang direkomendasikan untuk membangun gambar menggunakan Tugas ACR, atau opsi dalam kluster yang lebih aman seperti Docker Buildx.

Reservasi sumber daya

AKS menggunakan sumber daya simpul untuk membantu fungsi simpul sebagai bagian dari kluster Anda. Penggunaan ini dapat membuat perbedaan antara total sumber daya simpul Anda dan sumber daya yang dapat dialokasikan di AKS. Ingat informasi ini saat mengatur permintaan dan batasan untuk pod yang disebarkan pengguna.

Untuk menemukan sumber daya yang dapat dialokasikan node, Anda dapat menggunakan kubectl describe node perintah :

kubectl describe node [NODE_NAME]

Untuk mempertahankan performa dan fungsionalitas simpul, AKS mencadangkan dua jenis sumber daya, CPU dan memori, pada setiap simpul. Ketika simpul tumbuh lebih besar dalam sumber daya, reservasi sumber daya tumbuh karena kebutuhan yang lebih tinggi untuk manajemen pod yang disebarkan pengguna. Perlu diingat bahwa reservasi sumber daya tidak dapat diubah.

CPU

CPU yang dicadangkan tergantung pada jenis node dan konfigurasi kluster, yang dapat menyebabkan CPU yang kurang dapat dialokasikan karena menjalankan fitur tambahan. Tabel berikut ini memperlihatkan reservasi CPU dalam milikore:

Core CPU pada host	1	2	4	8	16	32	64
Kube-dicadangkan (milicore)	60	100	140	180	260	420	740

Memori

Memori yang dipesan dalam AKS mencakup jumlah dua nilai:

AKS 1.29 dan yang lebih baru

1. kubelet daemon memiliki aturan pengeluaran memory.available<100Mi secara default. Aturan ini memastikan bahwa node memiliki setidaknya 100Mi yang dapat dialokasikan setiap saat. Ketika host berada di bawah ambang memori yang tersedia, kubelet pemicu penghentian salah satu pod yang sedang berjalan dan membebaskan memori pada komputer host.

2. Tingkat reservasi memori yang ditetapkan sesuai dengan nilai yang lebih rendah: 20MB * Pod Maks yang didukung pada Node + 50MB atau 25% dari total sumber daya memori sistem.

   Contoh:

   • Jika VM menyediakan memori 8GB dan simpul mendukung hingga 30 pod, AKS mencadangkan 20MB * 30 Pod Maks + 50MB = 650MB untuk kube yang dicadangkan. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Jika VM menyediakan memori 4GB dan simpul mendukung hingga 70 pod, AKS mencadangkan 25% * 4GB = 1000MB untuk kube-reserved, karena ini kurang dari 20MB * 70 Pod Maks + 50MB = 1450MB.

   Untuk informasi selengkapnya, lihat Mengonfigurasi pod maksimum per simpul dalam kluster AKS.

Versi AKS sebelum 1.29

1. kubelet daemon memiliki aturan pengeluaran memory.available<750Mi secara default. Aturan ini memastikan bahwa node memiliki setidaknya 750Mi yang dapat dialokasikan setiap saat. Ketika host berada di bawah ambang memori yang tersedia, kubelet pemicu penghentian salah satu pod yang sedang berjalan dan membebaskan memori pada komputer host.
2. Tingkat regresif reservasi memori untuk daemon kubelet berfungsi dengan baik (kube-dicadangkan).
   • 25% dari memori 4GB pertama
   • 20% dari memori 4GB berikutnya (hingga 8GB)
   • 10% dari memori 8GB berikutnya (hingga 16GB)
   • 6% dari memori 112GB berikutnya (hingga 128GB)
   • 2% dari memori apa pun lebih dari 128GB

Aturan alokasi memori dan CPU dirancang untuk:

• Jaga agar simpul agen tetap sehat, termasuk beberapa pod sistem hosting yang penting bagi kesehatan kluster.
• Menyebabkan node melaporkan lebih sedikit memori yang dapat dialokasikan dan CPU daripada yang akan dilaporkan jika bukan bagian dari kluster Kubernetes.

Misalnya, jika simpul menawarkan 7 GB, simpul akan melaporkan 34% memori yang tidak dapat ditampilkan termasuk ambang penggusuran keras 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Selain reservasi untuk Kube sendiri, OS simpul yang mendasarinya juga mencadangkan sejumlah sumber daya CPU dan memori untuk mempertahankan fungsi OS.

Untuk praktik terbaik terkait, lihat Praktik terbaik untuk fitur penjadwal dasar di AKS.

Kumpulan simpul

Node dengan konfigurasi yang sama dikelompokkan menjadi kumpulan node. Setiap kluster Kubernetes berisi setidaknya satu kumpulan simpul. Anda menentukan jumlah awal simpul dan ukuran saat membuat kluster AKS, yang membuat kumpulan simpul default. Kumpulan simpul default dalam AKS ini berisi VM yang mendasari yang menjalankan simpul agen Anda.

Anda menskalakan atau meningkatkan kluster AKS terhadap kumpulan simpul default. Anda dapat memilih untuk menskalakan atau meningkatkan kumpulan simpul tertentu. Untuk operasi peningkatan, kontainer yang berjalan dijadwalkan pada simpul lain di kumpulan simpul sampai semua simpul berhasil ditingkatkan.

Untuk informasi selengkapnya, lihat Membuat kumpulan simpul dan Mengelola kumpulan simpul.

Ukuran disk OS default

Saat Anda membuat kluster baru atau menambahkan kumpulan simpul baru ke kluster yang ada, angka untuk vCPU secara default menentukan ukuran disk OS. Jumlah vCPU didasarkan pada SKU VM. Tabel berikut mencantumkan ukuran disk OS default untuk setiap SKU VM:

Inti SKU mesin virtual (vCPU)	Tingkat Disk OS default	IOPS yang diprovisikan	Throughput yang Disediakan (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2.300	150
64+	P30/1024G	5000	200

Pemilih simpul

Dalam kluster AKS dengan beberapa kumpulan simpul, Anda mungkin perlu memberi tahu Kubernetes Scheduler kumpulan simpul mana yang akan digunakan untuk sumber daya tertentu. Misalnya, kontroler ingress tidak boleh berjalan pada simpul Windows Server. Anda menggunakan pemilih simpul untuk menentukan berbagai parameter, seperti OS simpul, untuk mengontrol di mana pod harus dijadwalkan.

Contoh dasar berikut menjadwalkan instans NGINX pada simpul Linux menggunakan pemilih simpul "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Untuk informasi selengkapnya, lihat Praktik terbaik untuk fitur penjadwal tingkat lanjut di AKS.

Grup sumber daya simpul

Saat membuat kluster AKS, Anda menentukan grup sumber daya Azure untuk membuat sumber daya kluster. Selain grup sumber daya ini, penyedia sumber daya AKS membuat dan mengelola grup sumber daya terpisah yang disebut grup sumber daya simpul. Grup sumber daya simpul berisi sumber daya infrastruktur berikut:

• Set skala komputer virtual dan VM untuk setiap simpul di kumpulan simpul
• Jaringan virtual untuk kluster
• Penyimpanan untuk kluster

Grup sumber daya simpul diberi nama secara default dengan format berikut: MC_resourceGroupName_clusterName_location. Selama pembuatan kluster, Anda dapat menentukan nama yang ditetapkan ke grup sumber daya simpul Anda. Saat menggunakan templat Azure Resource Manager, Anda dapat menentukan nama menggunakan nodeResourceGroup properti . Saat menggunakan Azure CLI, Anda menggunakan --node-resource-group parameter dengan az aks create perintah , seperti yang ditunjukkan dalam contoh berikut:

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

Saat Anda menghapus kluster AKS, penyedia sumber daya AKS secara otomatis menghapus grup sumber daya simpul.

Grup sumber daya simpul memiliki batasan berikut:

• Anda tidak dapat menentukan grup sumber daya yang ada untuk grup sumber daya simpul.
• Anda tidak dapat menentukan langganan yang berbeda untuk grup sumber daya simpul.
• Anda tidak dapat mengubah nama grup sumber daya simpul setelah kluster dibuat.
• Anda tidak dapat menentukan nama untuk sumber daya terkelola dalam grup sumber daya simpul.
• Anda tidak dapat mengubah atau menghapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya simpul.

Memodifikasi tag yang dibuat Azure pada sumber daya di bawah grup sumber daya simpul di kluster AKS adalah tindakan yang tidak didukung, yang merusak tujuan tingkat layanan (SLO). Jika Anda memodifikasi atau menghapus tag yang dibuat Azure atau properti sumber daya lainnya di grup sumber daya simpul, Anda mungkin mendapatkan hasil yang tidak terduga, seperti kesalahan penskalakan dan peningkatan. AKS mengelola siklus hidup infrastruktur dalam grup sumber daya simpul, sehingga membuat perubahan apa pun memindahkan kluster Anda ke status yang tidak didukung. Untuk informasi selengkapnya, lihat Apakah AKS menawarkan SLA?

AKS memungkinkan Anda membuat dan memodifikasi tag yang disebarkan ke sumber daya di grup sumber daya simpul, dan Anda dapat menambahkan tag tersebut saat membuat atau memperbarui kluster. Anda mungkin ingin membuat atau mengubah tag kustom untuk menetapkan unit bisnis atau pusat biaya, misalnya. Anda juga dapat membuat Kebijakan Azure dengan cakupan pada grup sumber daya terkelola.

Untuk mengurangi kemungkinan perubahan dalam grup sumber daya simpul yang memengaruhi kluster Anda, Anda dapat mengaktifkan penguncian grup sumber daya simpul untuk menerapkan penugasan penolakan ke sumber daya AKS Anda. untuk informasi selengkapnya, lihat Grup sumber daya yang dikelola sepenuhnya (pratinjau).

Pod

Kubernetes menggunakan pod untuk menjalankan instans aplikasi Anda. Satu pod mewakili satu instans aplikasi Anda.

Pod biasanya memiliki pemetaan 1:1 dengan kontainer. Dalam skenario lanjutan, pod mungkin berisi beberapa kontainer. Pod multi-kontainer dijadwalkan bersama pada simpul yang sama dan memungkinkan kontainer berbagi sumber daya terkait.

Saat membuat pod, Anda dapat menentukan permintaan sumber daya untuk sejumlah CPU atau memori tertentu. Kubernetes Scheduler mencoba memenuhi permintaan dengan menjadwalkan pod untuk berjalan pada simpul dengan sumber daya yang tersedia. Anda juga dapat menentukan batas sumber daya maksimum untuk mencegah pod mengonsumsi terlalu banyak sumber daya komputasi dari simpul yang mendasarinya. Praktik terbaik yang kami rekomendasikan adalah menyertakan batas sumber daya untuk semua pod untuk membantu Penjadwal Kubernetes mengidentifikasi sumber daya yang diperlukan dan diizinkan.

Untuk informasi lebih lanjut, lihat Pod Kube dan siklus hidup pod Kube.

Sebuah pod adalah sumber daya yang logis, tetapi beban kerja aplikasi berjalan pada kontainer. Pod biasanya merupakan sumber daya yang sementara dan sekali pakai. Pod yang dijadwalkan secara individual melewatkan beberapa fitur Kube ketersediaan tinggi dan redundansi. Sebaliknya, Pengontrol Kubernetes, seperti Pengontrol Penyebaran, menyebarkan dan mengelola pod.

Penyebaran dan manifes YAML

Penyebaran mewakili pod identik yang dikelola oleh Pengontrol Penyebaran Kube. Penyebaran mendefinisikan jumlah replika pod yang akan dibuat. Penjadwal Kubernetes memastikan bahwa pod tambahan dijadwalkan pada simpul yang sehat jika pod atau node mengalami masalah. Anda dapat memperbarui penyebaran untuk mengubah konfigurasi pod, gambar kontainer, atau penyimpanan yang terpasang.

Pengontrol Penyebaran mengelola siklus hidup penyebaran dan melakukan tindakan berikut:

• Mengosongkan dan mengakhiri sejumlah replika.
• Membuat replika dari definisi penyebaran baru.
• Melanjutkan proses hingga semua replika dalam penyebaran diperbarui.

Sebagian besar aplikasi stateless dalam AKS harus menggunakan model penyebaran daripada menjadwalkan masing-masing pod. Kube dapat memantau kesehatan dan status penyebaran untuk memastikan bahwa jumlah replika yang diperlukan berjalan dalam kluster. Ketika dijadwalkan satu per satu, pod tidak dimulai ulang jika mengalami masalah, dan tidak dijadwalkan ulang pada simpul sehat jika node mereka saat ini mengalami masalah.

Anda tidak ingin mengganggu keputusan manajemen dengan proses pembaruan jika aplikasi Anda memerlukan jumlah minimum instans yang tersedia. Anggaran Gangguan Pod mendefinisikan berapa banyak replika dalam penyebaran yang dapat diturunkan selama pembaruan atau peningkatan simpul. Misalnya, jika Anda memiliki lima replika dalam penyebaran, Anda dapat menentukan gangguan pod empat untuk hanya memungkinkan satu replika dihapus atau dijadwalkan ulang pada satu waktu. Seperti halnya batas sumber daya pod, praktik terbaik yang kami rekomendasikan adalah menentukan anggaran gangguan pod pada aplikasi yang memerlukan jumlah minimum replika untuk selalu ada.

Penyebaran biasanya dibuat dan dikelola dengan kubectl create atau kubectl apply. Anda dapat membuat penyebaran dengan menentukan file manifes dalam format YAML. Contoh berikut menunjukkan file manifes penyebaran dasar untuk server web NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Perincian spesifikasi penyebaran dalam file manifes YAML adalah sebagai berikut:

Spesifikasi	Deskripsi
.apiVersion	Menentukan grup API dan sumber daya API yang ingin Anda gunakan saat membuat sumber daya.
.kind	Menentukan jenis sumber daya yang ingin Anda buat.
.metadata.name	Menentukan nama penyebaran. Contoh file YAML ini menjalankan gambar nginx dari Docker Hub.
.spec.replicas	Menentukan berapa banyak pod yang akan dibuat. Contoh file YAML ini membuat tiga pod duplikat.
.spec.selector	Menentukan pod mana yang akan terpengaruh oleh penyebaran ini.
.spec.selector.matchLabels	Berisi peta pasangan {key, value} yang memungkinkan penyebaran menemukan dan mengelola pod yang dibuat.
.spec.selector.matchLabels.app	Harus cocok .spec.template.metadata.labelsdengan .
.spec.template.labels	Menentukan pasangan {key, value} yang dilampirkan ke objek.
.spec.template.app	Harus cocok .spec.selector.matchLabelsdengan .
.spec.spec.containers	Menentukan daftar kontainer milik pod.
.spec.spec.containers.name	Menentukan nama kontainer yang ditentukan sebagai label DNS.
.spec.spec.containers.image	Menentukan nama gambar kontainer.
.spec.spec.containers.ports	Menentukan daftar port yang akan diekspos dari kontainer.
.spec.spec.containers.ports.containerPort	Menentukan jumlah port yang akan diekspos pada alamat IP pod.
.spec.spec.resources	Menentukan sumber daya komputasi yang diperlukan oleh kontainer.
.spec.spec.resources.requests	Menentukan jumlah minimum sumber daya komputasi yang diperlukan.
.spec.spec.resources.requests.cpu	Menentukan jumlah minimum CPU yang diperlukan.
.spec.spec.resources.requests.memory	Menentukan jumlah minimum memori yang diperlukan.
.spec.spec.resources.limits	Menentukan jumlah maksimum sumber daya komputasi yang diizinkan. Kubelet memberlakukan batas ini.
.spec.spec.resources.limits.cpu	Menentukan jumlah maksimum CPU yang diizinkan. Kubelet memberlakukan batas ini.
.spec.spec.resources.limits.memory	Menentukan jumlah maksimum memori yang diizinkan. Kubelet memberlakukan batas ini.

Aplikasi yang lebih kompleks dapat dibuat dengan menyertakan layanan, seperti load balancer, dalam manifes YAML.

Untuk informasi lebih lanjut, lihat Penyebaran Kube.

Manajemen paket dengan Helm

Helm umumnya digunakan untuk mengelola aplikasi di Kube. Anda dapat menyebarkan sumber daya dengan membangun dan menggunakan bagan Helm publik yang ada yang berisi versi yang dipaketkan dari kode aplikasi dan manifes YAML Kube. Anda dapat menyimpan bagan Helm baik secara lokal maupun di repositori jarak jauh, seperti repositori bagan Azure Container Registry Helm.

Untuk menggunakan Helm, pasang klien Helm di komputer Anda, atau gunakan klien Helm di Azure Cloud Shell. Cari atau buat chart Helm, lalu pasang ke kluster Kube. Untuk informasi selengkapnya, lihat Memasang aplikasi yang ada dengan Helm di AKS.

StatefulSet dan DaemonSets

Pengontrol Penyebaran menggunakan Penjadwal Kubernetes dan menjalankan replika pada simpul yang tersedia dengan sumber daya yang tersedia. Meskipun pendekatan ini mungkin cukup untuk aplikasi stateless, Pengontrol Penyebaran tidak ideal untuk aplikasi yang memerlukan spesifikasi berikut:

• Konvensi atau penyimpanan penamaan yang persisten.
• Replika yang ada pada setiap simpul pilih dalam kluster.

Namun, dua sumber daya Kubernetes memungkinkan Anda mengelola jenis aplikasi ini: StatefulSets dan DaemonSets.

StatefulSets mempertahankan status aplikasi di luar siklus hidup pod individual. DaemonSets memastikan instans yang sedang berjalan pada setiap simpul di awal proses bootstrap Kubernetes.

StatefulSets

Pengembangan aplikasi modern sering bertujuan untuk aplikasi stateless. Untuk aplikasi stateful, seperti yang menyertakan komponen database, Anda dapat menggunakan StatefulSets. Seperti penyebaran, sebuah StatefulSet membuat dan mengelola setidaknya satu pod yang identik. Replika dalam StatefulSet mengikuti pendekatan yang anggun dan berurutan untuk operasi penyebaran, penskalaan, peningkatan, dan penghentian. Konvensi penamaan, nama jaringan, dan penyimpanan bertahan karena replika dijadwalkan ulang dengan StatefulSet.

Anda dapat menentukan aplikasi dalam format YAML menggunakan kind: StatefulSet. Dari sana, Pengontrol StatefulSet menangani penyebaran dan manajemen replika yang diperlukan. Penulisan data ke penyimpanan persisten, disediakan oleh Azure Managed Disks atau Azure Files. Dengan StatefulSets, penyimpanan persisten yang mendasarinya tetap ada, bahkan ketika StatefulSet dihapus.

Untuk informasi lebih lanjut, lihat StatefulSets Kube.

DaemonSets

Untuk pengumpulan atau pemantauan log tertentu, Anda mungkin perlu menjalankan pod pada semua simpul atau sekumpulan simpul tertentu. Anda dapat menggunakan DaemonSets untuk menyebarkan ke satu atau beberapa pod yang identik. Pengontrol DaemonSet memastikan bahwa setiap simpul yang ditentukan menjalankan instans pod.

Pengontrol DaemonSet dapat menjadwalkan pod pada simpul di awal proses boot kluster sebelum penjadwal Kubernetes default dimulai. Kemampuan ini memastikan bahwa pod dalam status DaemonSet sebelum pod tradisional dalam Deployment atau StatefulSet dijadwalkan.

Seperti StatefulSets, Anda dapat menentukan DaemonSet sebagai bagian dari definisi YAML menggunakan kind: DaemonSet.

Untuk informasi lebih lanjut, lihat DaemonSets Kube.

Namaspace

Sumber daya Kubernetes, seperti pod dan penyebaran, secara logis dikelompokkan ke dalam namespace untuk membagi kluster AKS dan membuat, melihat, atau mengelola akses ke sumber daya. Misalnya, Anda dapat membuat namespace untuk memisahkan grup bisnis. Pengguna hanya dapat berinteraksi dengan sumber daya dalam namespace yang ditetapkan.

Namespace berikut tersedia saat Anda membuat kluster AKS:

Ruang nama	Deskripsi
Default	Di mana pod dan penyebaran dibuat secara default ketika tidak ada yang disediakan. Di lingkungan yang lebih kecil, Anda dapat menyebarkan aplikasi langsung ke namespace default tanpa membuat pemisahan logis tambahan. Ketika berinteraksi dengan Kube API, seperti dengan kubectl get pods, namespace default digunakan ketika tidak ada yang ditentukan.
kube-sistem	Di mana ada sumber daya inti, seperti fitur jaringan seperti DNS dan proksi, atau dasbor Kube. Anda biasanya tidak menyebarkan aplikasi Anda sendiri ke dalam namespace ini.
kube-publik	Biasanya tidak digunakan, Anda dapat menggunakannya agar sumber daya terlihat di seluruh kluster, dan dapat dilihat oleh pengguna mana pun.

Untuk informasi lebih lanjut, lihat Namespace Layanan Kube.

Langkah berikutnya

Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut:

• Akses dan identitas AKS
• Keamanan AKS
• Jaringan virtual AKS
• Penyimpanan AKS
• Skala AKS