Konsep core Kube untuk Azure Kubernetes Service (AKS)

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:

  • Komponen infrastruktur core Kube:
    • sarana kontrol
    • simpul
    • kumpulan simpul
  • Sumber daya beban kerja:
    • pod
    • penyebaran
    • set
  • Cara mengelompokkan sumber daya ke dalam namespace.

Apa yang dimaksud dengan Kube?

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. AKS dibangun di atas sumber terbuka Mesin Azure Kubernetes Service: aks-engine.

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.

Komponen sarana kontrol dan simpul Kube

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 Manajer Pengontrol 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 langsung mengakses sarana kontrol, sebarkan kluster Kube Anda sendiri menggunakan aks-engine.

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

Simpul dan kumpulan simpul

Untuk menjalankan aplikasi dan layanan pendukung, Anda memerlukan simpul 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 Kube yang memproses permintaan pengaturan dari sarana kontrol dan penjadwalan menjalankan 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 dan 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.

Komputer virtual Azure dan sumber daya pendukung untuk simpul Kube

Ukuran komputer virtual Azure untuk simpul Anda menentukan CPU penyimpanan, memori, ukuran, dan jenis yang tersedia (seperti SSD berperforma 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.

Di AKS, gambar komputer virtual untuk simpul kluster Anda didasarkan pada Ubuntu 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.

Sebarkan kluster Kube Anda sendiri dengan aks-engine jika menggunakan OS host yang berbeda, runtime bahasa umum kontainer, atau menyertakan paket kustom yang berbeda. Upstream aks-engine merilis fitur dan menyediakan opsi konfigurasi sebelum dukungan dalam kluster AKS. Jadi, jika Anda ingin menggunakan runtime kontainer selain containerd atau Docker, Anda dapat menjalankan aks-engine untuk mengonfigurasi dan menerapkan kluster Kubernetes yang memenuhi kebutuhan Anda saat ini.

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.

    1. kubelet daemon
      Daemon kubelet dipasang pada semua node agen Kube untuk mengelola pembuatan dan penghentian kontainer.

      Secara default pada AKS, kubelet daemon memiliki aturan penggusuran memori.available<750Mi, yang memastikan simpul harus selalu memiliki setidaknya 750 Mi 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 4 GB pertama
      • 20% dari memori 4 GB berikutnya (hingga 8 GB)
      • 10% dari memori 8 GB berikutnya (hingga 16 GB)
      • 6% dari memori 112 GB berikutnya (hingga 128 GB)
      • 2% dari memori apa pun di atas 128 GB

Aturan alokasi memori dan CPU:

  • Jaga agar simpul agen tetap sehat, termasuk beberapa pod sistem hosting yang penting bagi kesehatan kluster.
  • Menyebabkan simpul melaporkan memori dan CPU yang kurang dapat dimakserasi daripada yang seharusnya jika bukan bagian dari kluster Kube.

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

Simpul dengan konfigurasi yang sama dikelompokkan bersama ke dalam kumpulan simpul. Kluster Kube berisi setidaknya satu kumpulan simpul. Jumlah awal simpul dan ukuran didefinisikan ketika Anda membuat kluster AKS, yang membuat kumpulan simpul 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 dan mengelola 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.

Pod

Kube 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

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, seperti penyimpanan.
  • 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 koleksi atau pemantauan log tertentu, Anda mungkin perlu menjalankan pod pada semua simpul atau simpul yang dipilih. Anda dapat menggunakan DaemonSet untuk menyebarkan satu atau beberapa pod yang identik, namun Pengontrol DaemonSet memastikan bahwa setiap simpul yang ditentukan menjalankan sebuah instans dari 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.

Namaspace

Sumber daya Kube, seperti pod dan penyebaran, secara logis dikelompokkan menjadi namespace untuk membagi kluster AKS dan membatasi pembuatan, 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 Kube untuk membagi sumber daya dan aplikasi secara logis

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

Langkah berikutnya

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