Konsep Core Kubernetes untuk Azure Kubernetes Service

  • Artikel

Pengembangan aplikasi terus bergerak menuju pendekatan berbasis kontainer, meningkatkan kebutuhan kita untuk mengatur dan mengelola sumber daya. Sebagai platform terdepan, Kube menyediakan penjadwalan beban kerja aplikasi yang toleran terhadap kesalahan. Azure Kubernetes Service (AKS), penawaran Kube terkelola, semakin menyederhanakan penyebaran dan manajemen aplikasi berbasis kontainer.

Artikel ini memperkenalkan konsep inti:

  • Komponen infrastruktur Kubernetes:

    • sarana kontrol
    • simpul
    • kumpulan simpul

  • Sumber daya beban kerja:

    • pod
    • penyebaran
    • set

  • Mengelompokkan sumber daya menggunakan namespace layanan.

Apa itu Kubernetes?

Kube adalah platform yang berkembang pesat yang mengelola aplikasi berbasis kontainer serta komponen jaringan dan penyimpanan yang terkait. Kube berfokus pada beban kerja aplikasi, bukan komponen infrastruktur yang mendasarinya. 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 Kube untuk mengatur dan mengelola ketersediaan komponen aplikasi. Kube mendukung aplikasi stateless dan stateful seiring kemajuan tim melalui adopsi aplikasi berbasis layanan mikro.

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 Kube terkelola yang mengurangi kompleksitas tugas penyebaran dan manajemen core, seperti meningkatkan koordinasi. 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: menyediakan layanan core Kube dan pengaturan beban kerja aplikasi.
  • Simpul: Menjalankan beban kerja aplikasi Anda.

Kubernetes control plane and node components

Sarana kontrol

Saat Anda membuat kluster AKS, sebuah sarana kontrol akan dibuat dan dikonfigurasi secara otomatis. Pesawat kontrol 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 adalah bagaimana API Kube yang mendasarinya diekspos. Komponen ini menyediakan interaksi untuk alat manajemen, seperti kubectl atau dasbor Kube.
etcd Untuk mempertahankan status kluster dan konfigurasi Kube, etcd yang sangat tersedia adalah penyimpanan nilai kunci dalam Kube.
penjadwal kube Saat Anda membuat atau menskalakan aplikasi, Scheduler menentukan simpul apa yang dapat menjalankan beban kerja dan memulainya.
manajer pengontrol kube Controller Manager mengawasi sejumlah pengontrol yang lebih kecil yang melakukan tindakan seperti mereplikasi pod dan menangani operasi simpul.

AKS menyediakan sarana kontrol penyewa tunggal, dengan server API khusus, penjadwal, dll. Anda menentukan jumlah dan ukuran simpul, dan platform Azure mengonfigurasi komunikasi aman antara sarana kontrol dan simpul. Interaksi dengan sarana kontrol terjadi melalui API Kube, seperti kubectl atau dasbor Kube.

Meskipun Anda tidak perlu mengonfigurasi komponen (seperti penyimpanan etcd yang sangat tersedia) dengan sarana kontrol terkelola ini, Anda tidak dapat mengakses sarana kontrol secara langsung. Peningkatan sarana kontrol dan simpul Kube diatur melalui Azure CLI atau portal Microsoft Azure. Untuk memecahkan masalah yang mungkin terjadi, Anda dapat mengulas log sarana kontrol melalui log Azure Monitor.

Untuk mengonfigurasi atau mengakses langsung sarana kontrol, sebarkan kluster Kubernetes yang dikelola sendiri menggunakan Penyedia API Kluster Azure.

Untuk praktik terbaik terkait, lihat Praktik terbaik untuk peningkatan dan keamanan kluster di AKS.

Untuk informasi manajemen biaya AKS, lihat Dasar biaya AKS dan Harga untuk AKS.

Simpul dan kumpulan simpul

Untuk menjalankan aplikasi dan layanan pendukung, Anda memerlukan Node kube. Kluster AKS memiliki setidaknya satu kesimpulan, yaitu komputer virtual Azure yang menjalankan komponen simpul Kube dan runtime bahasa umum kontainer.

Komponen Deskripsi
kubelet Agen Kubernetes yang memproses permintaan pengaturan dari sarana kontrol bersama dengan penjadwalan dan eksekusi kontainer yang diminta.
proksi kube Menangani jaringan virtual pada setiap simpul. Proksi merutekan lalu lintas jaringan dan mengelola alamat IP untuk layanan dan pod.
runtime bahasa umum kontainer Memungkinkan aplikasi kontainer untuk menjalankan dan berinteraksi dengan sumber daya tambahan, seperti jaringan virtual atau penyimpanan. Kluster AKS yang menggunakan Kubernetes versi 1.19+ untuk pool node Linux menggunakan containerd sebagai runtime kontainernya. Dimulai pada Kubernetes versi 1.20 untuk pool node Windows, containerd dapat digunakan dalam pratinjau untuk runtime kontainer, tetapi Docker masih menjadi runtime kontainer default. Kluster AKS yang menggunakan Kubernetes versi sebelumnya untuk pool node menggunakan Docker sebagai runtime kontainer.

Azure virtual machine and supporting resources for a Kubernetes node

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 CPU dan memori dalam jumlah besar atau penyimpanan berperforma 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 2019. 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 komputer virtual standar, sehingga potongan ukuran komputer virtual apa pun (termasuk reservasi Azure) diterapkan secara otomatis.

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

Jika Anda memerlukan konfigurasi dan kontrol tingkat lanjut pada runtime bahasa umum dan OS kontainer node Kubernetes Anda, Anda dapat menyebarkan kluster yang dikelola sendiri menggunakan Penyedia API Kluster Azure.

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 simpul yang dapat dialokasikan, jalankan:

kubectl describe node [NODE_NAME]

Untuk mempertahankan performa dan fungsionalitas simpul, AKS mencadangkan sumber daya 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.

Catatan

Menggunakan add-on AKS seperti Insight Kontainer (OMS) akan mengonsumsi sumber daya simpul tambahan.

Dua jenis sumber daya dicadangkan:

CPU

CPU yang dicadangkan tergantung pada jenis simpul dan konfigurasi kluster, yang dapat menyebabkan CPU kurang dapat dialokasikan karena menjalankan fitur tambahan.

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

Memori

Memori yang digunakan oleh AKS mencakup penjumlahan dari dua nilai.

Penting

Pratinjau AKS 1.29 pada Januari 2024 dan mencakup perubahan tertentu pada reservasi memori. Perubahan ini dirinci di bagian berikut.

AKS 1.29 dan yang lebih baru

  1. kubelet daemon memiliki aturan pengeluaran memory.available<100Mi secara default. Ini memastikan bahwa node selalu 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 diinstal pada semua node agen Kubernetes untuk mengelola pembuatan dan penghentian kontainer. Secara default pada AKS, kubelet daemon memiliki aturan pengeluaran memory.available<750Mi , memastikan node harus selalu memiliki setidaknya 750Mi yang dapat dialokasikan setiap saat. Ketika host berada di bawah ambang memori yang tersedia, kubelet akan memicu untuk mengakhiri salah satu Pod yang sedang berjalan dan membebaskan memori pada mesin 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 di atas 128GB

Catatan

AKS mencadangkan 2GB tambahan untuk proses sistem di node Windows yang bukan bagian dari memori terhitung.

Aturan alokasi memori dan CPU dirancang untuk melakukan hal berikut:

  • 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.

Reservasi sumber daya di atas tidak dapat diubah.

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

Catatan

Kumpulan simpul Azure Linux sekarang tersedia secara umum (GA). Untuk mempelajari tentang manfaat dan langkah-langkah penyebaran, lihat Pengantar Host Kontainer Azure Linux untuk AKS.

Node dengan konfigurasi yang sama dikelompokkan menjadi kumpulan node. Kluster Kube berisi setidaknya satu kumpulan simpul. Jumlah dan ukuran awal node ditentukan saat Anda membuat kluster AKS, yang membuat kumpulan node default. Kumpulan simpul default dalam AKS ini berisi VM yang mendasari yang menjalankan simpul agen Anda.

Catatan

Untuk memastikan kluster beroperasi dengan andal, Anda harus menjalankan setidaknya 2 (dua) simpul dalam kumpulan simpul default.

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 tentang cara menggunakan beberapa kumpulan simpul di AKS, lihat Membuat beberapa kumpulan simpul untuk kluster di AKS.

Pemilih simpul

Dalam kluster AKS dengan beberapa pool simpul, kamu mungkin perlu memberitahu Scheduler Kube terkait kumpulan simpul mana yang akan digunakan untuk sumbar daya tertentu. Misalnya, kontroler ingress tidak boleh berjalan pada simpul Windows Server.

Pemilih simpul memungkinkan Anda menentukan berbagai parameter, seperti OS simpul, untuk mengontrol di mana sebuah 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 tentang cara mengontrol di mana Pod dijadwalkan, lihat Praktik terbaik untuk fitur penjadwal tingkat lanjut di AKS.

Grup sumber daya simpul

Saat membuat kluster AKS, Anda perlu menentukan grup sumber daya untuk membuat sumber daya kluster. Selain grup sumber daya ini, penyedia sumber daya AKS juga 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, seperti MC_myResourceGroup_myAKSCluster_eastus. Selama pembuatan kluster, Anda juga memiliki opsi untuk menentukan nama yang ditetapkan ke grup sumber daya simpul Anda. 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.

Jika Anda memodifikasi atau menghapus tag yang dibuat Azure dan properti sumber daya lainnya di grup sumber daya simpul, Anda bisa mendapatkan hasil yang tidak terduga, seperti kesalahan penskalakan dan peningkatan. Karena AKS mengelola siklus hidup infrastruktur di Grup Sumber Daya Simpul, setiap perubahan akan memindahkan kluster Anda ke status yang tidak didukung.

Skenario umum di mana pelanggan ingin memodifikasi sumber daya adalah melalui tag. 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 memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Ini juga dapat dicapai dengan membuat Kebijakan Azure dengan cakupan pada grup sumber daya terkelola.

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). Untuk informasi selengkapnya, lihat Apakah AKS menawarkan SLA?

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. Informasi lebih lanjut dapat ditemukan dalam Konfigurasi kluster di AKS.

Peringatan

Jika Anda tidak mengaktifkan penguncian grup sumber daya simpul, Anda dapat langsung memodifikasi sumber daya apa pun di grup sumber daya simpul. Memodifikasi sumber daya secara langsung dalam grup sumber daya simpul dapat menyebabkan kluster Anda menjadi tidak stabil atau tidak responsif.

Pod

Kubernetes menggunakan pod untuk menjalankan instans aplikasi Anda. Sebuah Pod mewakili satu instans aplikasi anda.

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

Ketika membuat pod, Anda dapat menentukan permintaan sumber daya untuk meminta sejumlah CPU atau sumber daya 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 terbaiknya adalah memasukkan batas resource untuk semua pod untuk membantu Scheduler Kube 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. Sebagai gantinya, pod disebarkan dan dikelola oleh Pengontrol Kube, seperti Pengontrol Penyebaran.

Penyebaran dan manifes YAML

Penyebaran mewakili pod identik yang dikelola oleh Pengontrol Penyebaran Kube. Penyebaran mendefinisikan jumlah replika pod yang akan dibuat. Scheduler Kube memastikan bahwa pod tambahan dijadwalkan pada simpul yang sehat jika pod atau simpul mengalami masalah.

Anda dapat memperbarui penyebaran untuk mengubah konfigurasi pod, citra kontainer yang digunakan, atau penyimpanan yang dilampirkan. Pengontrol Penyebaran:

  • 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 secara individual, pod tidak dimulai ulang jika mengalami masalah, dan tidak dijadwalkan ulang pada simpul sehat jika simpul 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 memiliki lima (5) replika dalam penyebaran, Anda dapat menentukan sebuah gangguan pod 4 (empat) untuk hanya mengizinkan satu replika dihapus atau dijadwal ulang pada satu waktu. Seperti halnya batas sumber daya pod, praktik terbaiknya adalah menentukan anggaran gangguan pod pada aplikasi yang membutuhkan jumlah replika minimum untuk selalu ada.

Penyebaran biasanya dibuat dan dikelola dengan kubectl create atau kubectl apply. Buat penyebaran dengan mendefinisikan file manifes dalam format YAML.

Contoh berikut membuat penyebaran dasar server web NGINX. Penyebaran menentukan tiga (3) replika yang akan dibuat, dan mengharuskan port 80 terbuka pada kontainer. Permintaan dan batasan sumber daya juga didefinisikan untuk CPU dan memori.

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. File ini akan menjalankan gambar nginx dari Docker Hub.
.spec.replicas Menentukan berapa banyak pod yang akan dibuat. File ini akan 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. Batas ini diberlakukan oleh kubelet.
.spec.spec.resources.limits.cpu Menentukan jumlah maksimum CPU yang diizinkan. Batas ini diberlakukan oleh kubelet.
.spec.spec.resources.limits.memory Menentukan jumlah maksimum memori yang diizinkan. Batas ini diberlakukan oleh kubelet.

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

Dengan menggunakan Scheduler Kube, Pengontrol Penyebaran menjalankan replika pada setiap simpul yang tersedia dengan sumber daya yang tersedia. Meskipun pendekatan ini mungkin cukup untuk aplikasi stateless, Pengontrol Penyebaran tidak ideal untuk aplikasi yang memerlukan:

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

Namun, dua sumber daya Kube memungkinkan Anda mengelola jenis aplikasi ini:

  • StatefulSets mempertahankan status aplikasi di luar siklus hidup pod individual.
  • DaemonSet memastikan instans yang berjalan pada setiap simpul, di awal proses bootstrap Kube.

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 penyebaran, skala, peningkatan, dan penghentian. Konvensi penamaan, nama jaringan, dan penyimpanan bertahan karena replika dijadwalkan ulang dengan StatefulSet.

Tentukan aplikasi dalam format YAML menggunakan kind: StatefulSet. Dari sana, Pengontrol StatefulSet menangani penyebaran dan manajemen replika yang diperlukan. Data ditulis ke penyimpanan persisten, disediakan oleh Disk Terkelola Azure atau Azure Files. Dengan StatefulSets, penyimpanan persisten yang mendasarinya tetap ada, bahkan ketika StatefulSet dihapus.

Untuk informasi lebih lanjut, lihat StatefulSets Kube.

Replika dalam StatefulSet dijadwalkan dan dijalankan di seluruh simpul yang tersedia dalam kluster AKS. Untuk memastikan setidaknya satu pod dalam set berjalan pada sebuah simpul, gunakan DaemonSet sebagai gantinya.

DaemonSets

Untuk pengumpulan atau pemantauan log tertentu, Anda mungkin perlu menjalankan pod pada semua simpul atau set 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 Kube default dimulai. Kemampuan ini memastikan bahwa pod dalam DaemonSet dimulai sebelum pod tradisional dalam Penyebaran atau StatefulSet dijadwalkan.

Seperti StatefulSets, DaemonSet didefinisikan sebagai bagian dari definisi YAML menggunakan kind: DaemonSet.

Untuk informasi lebih lanjut, lihat DaemonSets Kube.

Catatan

Jika menggunakan add-on Simpul Virtual , DaemonSets tidak akan membuat pod pada simpul virtual.

Namespace

Sumber daya Kubernetes, seperti pod dan penyebaran, secara logis dikelompokkan ke dalam namespace layanan 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.

Kubernetes namespaces to logically divide resources and applications

Saat Anda membuat kluster AKS, namespace berikut tersedia:

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, tetapi dapat digunakan untuk sumber daya agar terlihat di seluruh kluster, dan dapat dilihat oleh pengguna mana pun.

Untuk informasi lebih lanjut, lihat Namespace Layanan Kube.

Langkah berikutnya

Artikel ini mencakup beberapa komponen inti Kube dan cara penerapannya pada kluster AKS. Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut: