Konsep Kubernetes untuk Azure
Tinjau konstruksi inti Kubernetes — pod, penerapan, layanan, dan namespace — lalu pahami cara AKS mengelola bidang kontrol untuk Anda.
Konsep Kubernetes untuk Azure adalah pelajaran Azure Fundamentals gratis di CoddyKit. Ini adalah pelajaran 3 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Azure Fundamentals, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Azure Fundamentals mencakup 4 pelajaran total.
Apa Itu Kubernetes?
Kubernetes (K8s) adalah platform orkestrasi kontainer sumber terbuka yang awalnya dikembangkan oleh Google. Platform ini mengotomatiskan deployment, penskalaan, dan pengelolaan aplikasi dalam kontainer. Alih-alih menjalankan kontainer secara manual, Anda mendeklarasikan keadaan yang diinginkan dari aplikasi dalam manifes YAML, lalu Kubernetes terus berupaya menyamakan keadaan aktual dengan keadaan yang diinginkan — memulai ulang kontainer yang gagal, menjadwalkan beban kerja pada node yang sehat, dan menskalakan replika.
Arsitektur Klaster: Control Plane dan Node
Klaster Kubernetes terdiri dari control plane dan worker node. Control plane berisi server API (titik masuk untuk semua perintah kubectl), etcd (penyimpanan keadaan terdistribusi), scheduler (menetapkan pod ke node), dan pengelola controller (mempertahankan keadaan yang diinginkan). Worker node menjalankan kubelet (agen node), kube-proxy (aturan jaringan), dan runtime kontainer (containerd). Di AKS, Microsoft mengelola control plane — Anda hanya perlu mengelola worker node.
# Kubernetes control plane components
# kube-apiserver - REST API for all cluster operations
# etcd - Distributed key-value store (cluster state)
# kube-scheduler - Assigns pending pods to nodes
# kube-controller-manager - Runs reconciliation controllers
# Worker node components
# kubelet - Node agent, ensures containers run
# kube-proxy - Network routing for services
# containerd - Container runtime (runs containers)Pod: Unit Terkecil yang Dapat Di-deploy
Pod adalah unit terkecil yang dapat di-deploy di Kubernetes. Pod membungkus satu atau beberapa kontainer yang berbagi ruang nama jaringan (alamat IP yang sama), volume penyimpanan, dan siklus hidup. Kontainer dalam pod berkomunikasi melalui localhost. Pod bersifat sementara — saat gagal, pod tersebut digantikan oleh pod baru dengan IP berbeda. Anda jarang membuat pod secara langsung; sebagai gantinya, buat sumber daya tingkat lebih tinggi yang mengelola pod.
# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80
resources:
requests:
cpu: '100m'
memory: '128Mi'
limits:
cpu: '500m'
memory: '512Mi'Deployment: Mengelola Replica Set
Deployment adalah cara standar untuk menjalankan aplikasi tanpa status di Kubernetes. Deployment membuat dan mengelola ReplicaSet yang mempertahankan jumlah replika pod identik sesuai keinginan. Deployment mendukung rolling update — mengganti pod lama secara bertahap dengan pod baru — serta rollback ke versi sebelumnya. Anda menjelaskan templat pod dan jumlah replika yang diinginkan; Kubernetes menangani sisanya.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Create 1 extra pod during update
maxUnavailable: 0 # Never reduce below desired count
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80Service: Titik Akhir Jaringan yang Stabil
Karena pod bersifat sementara dan IP-nya berubah, Service menyediakan titik akhir jaringan yang stabil untuk melakukan penyeimbangan beban lalu lintas ke pod yang sesuai. Service menggunakan pemilih label untuk menemukan pod. Jenis Service: ClusterIP (hanya internal, default), NodePort (mengekspos port pada setiap node), LoadBalancer (menyediakan Azure Load Balancer dengan IP publik), dan ExternalName (alias DNS ke layanan eksternal).
# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
type: LoadBalancer # Creates Azure Load Balancer
selector:
app: myapp # Routes traffic to pods with this label
ports:
- port: 80 # Service port
targetPort: 80 # Pod/container port
# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svcNamespace untuk Multi-Penyewaan
Namespace mempartisi satu klaster Kubernetes menjadi beberapa klaster virtual. Sumber daya dalam namespace yang berbeda diisolasi berdasarkan nama — Anda dapat memiliki Deployment myapp di namespace development dan production secara bersamaan. Namespace adalah unit utama untuk menerapkan RBAC, kuota sumber daya, dan kebijakan jaringan pada tim atau lingkungan. Namespace default mencakup default, kube-system, dan kube-public.
# Create a namespace for the dev team
kubectl create namespace dev-team
# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team
# List all resources in a namespace
kubectl get all --namespace dev-team
# Set default namespace for current context
kubectl config set-context --current --namespace dev-teamConfigMaps dan Secrets
ConfigMaps menyimpan data konfigurasi non-sensitif sebagai pasangan kunci-nilai atau berkas, yang disuntikkan ke pod sebagai variabel lingkungan atau pemasangan volume. Secrets menyimpan data sensitif (kata sandi, token) yang dikodekan dengan base64 (secara default tidak dienkripsi — gunakan Azure Key Vault Provider for Secrets Store CSI Driver untuk enkripsi saat tidak digunakan). Keduanya dibatasi oleh namespace dan dirujuk dalam spesifikasi pod berdasarkan nama.
# Create a ConfigMap from literal values
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=info
# Create a Secret
kubectl create secret generic db-secret \
--from-literal=DB_PASSWORD='super-secret'
# Reference in a pod spec
# env:
# - name: APP_ENV
# valueFrom:
# configMapKeyRef:
# name: app-config
# key: APP_ENV
# - name: DB_PASSWORD
# valueFrom:
# secretKeyRef:
# name: db-secret
# key: DB_PASSWORDVolume Persisten di Azure
Aplikasi stateful memerlukan penyimpanan yang tetap ada melampaui siklus hidup pod individual. Kubernetes menggunakan PersistentVolumes (PVs) dan PersistentVolumeClaims (PVCs) untuk memisahkan penyimpanan dari siklus hidup pod. Di AKS, kelas penyimpanan bawaan Azure Disk dan Azure Files secara otomatis menyediakan disk terkelola dan berbagi berkas saat PVC dibuat. Azure Disk ditujukan untuk akses satu pod; Azure Files mendukung beberapa pod untuk membaca dan menulis secara bersamaan.
# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-disk-pvc
spec:
accessModes:
- ReadWriteOnce # Single-node read/write (Azure Disk)
storageClassName: managed-csi
resources:
requests:
storage: 10Gi
# Mount in a pod
# volumes:
# - name: data
# persistentVolumeClaim:
# claimName: my-disk-pvc
# volumeMounts:
# - name: data
# mountPath: /dataHorizontal Pod Autoscaler
Horizontal Pod Autoscaler (HPA) secara otomatis menyesuaikan jumlah replika pod dalam Deployment berdasarkan pemanfaatan CPU/memori yang diamati atau metrik khusus. Controller HPA meminta data dari server metrik setiap 15 detik dan menaikkan atau menurunkan skala replika agar pemanfaatan tetap mendekati target. Anda menetapkan jumlah replika minimum dan maksimum sebagai batas pengaman untuk mencegah penskalaan yang tidak terkendali.
# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50Pemeriksaan Kesehatan: Probe Liveness dan Readiness
Kubernetes menggunakan probe untuk memantau kesehatan kontainer. Probe liveness memeriksa apakah kontainer masih berjalan — jika gagal, Kubernetes memulai ulang kontainer. Probe readiness memeriksa apakah kontainer siap melayani lalu lintas — jika gagal, pod dikeluarkan dari penyeimbangan beban Service tanpa dimulai ulang. Probe startup menunda probe lainnya sampai aplikasi selesai diinisialisasi, sehingga mencegah mulai ulang terlalu dini selama startup yang lambat.
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 15
periodSeconds: 20
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet:
path: /startup
port: 80
failureThreshold: 30
periodSeconds: 10 # Allow 300s for slow startupRequest dan Limit Sumber Daya
Setiap kontainer di Kubernetes sebaiknya mendeklarasikan request sumber daya (alokasi minimum yang dijamin dan digunakan oleh scheduler) serta limit (batas maksimum yang diizinkan, setelah itu kontainer akan dibatasi atau dihentikan). Request CPU dinyatakan dalam milicore (m) — 1000m = 1 inti CPU. Menetapkan request dan limit secara akurat mencegah masalah tetangga yang berisik serta memungkinkan scheduler menempatkan pod secara efisien pada node tanpa mengalokasikan sumber daya secara berlebihan.
resources:
requests:
cpu: '250m' # 0.25 CPU core guaranteed
memory: '256Mi' # 256 MiB guaranteed
limits:
cpu: '1' # Max 1 CPU core
memory: '512Mi' # Max 512 MiB (OOMKilled if exceeded)Pemeriksaan Singkat
Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.
Ringkasan Pelajaran
Dalam pelajaran ini, Anda telah mempelajari bahwa pod adalah unit terkecil yang dapat diterapkan dan berbagi jaringan serta penyimpanan, Deployment mengelola set replika tanpa status dengan dukungan pembaruan bergulir, dan Service menyediakan titik akhir stabil yang menyeimbangkan lalu lintas di antara pod sementara. Selanjutnya, kita akan mempelajari penerapan beban kerja di AKS.
Belajar Azure Fundamentals dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 30
- Pelajaran
- 120
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Konsep Kubernetes untuk Azure” gratis?
Ya — teks lengkap “Konsep Kubernetes untuk Azure” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Azure Fundamentals, upgrade ke CoddyKit PRO. Kursus Azure Fundamentals mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Konsep Kubernetes untuk Azure”?
Tinjau konstruksi inti Kubernetes — pod, penerapan, layanan, dan namespace — lalu pahami cara AKS mengelola bidang kontrol untuk Anda. Kamu berlatih Azure Fundamentals dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai Azure Fundamentals?
Tidak diperlukan pengalaman sebelumnya. Azure Fundamentals di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 3 dari 4.
Berapa lama pelajaran “Konsep Kubernetes untuk Azure” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran Azure Fundamentals ini?
Ya. Setiap pelajaran Azure Fundamentals menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Azure Container Registry
- Azure Container Instances
- Konsep Kubernetes untuk Azure
- Menerapkan Beban Kerja di AKS