Penyelaman Kernel Linux Mendalam - Cgroups dan Namespaces

#Pengantar

Di Episode 1, kami mengeksplorasi fondasi Linux dan sejarahnya. Sekarang kami menyelam lebih dalam ke kernel—inti Linux yang membuat containerisasi modern mungkin.

Jika Anda pernah bertanya-tanya bagaimana container Docker dapat menjalankan proses terisolasi pada mesin yang sama, atau bagaimana Kubernetes mengelola ribuan container tanpa saling mengganggu, jawabannya terletak pada dua teknologi kernel yang kuat: namespaces dan cgroups.

Ini bukan hanya konsep akademis. Mereka adalah fondasi dari Docker, Kubernetes, infrastruktur cloud, arsitektur microservices, dan praktik DevOps modern.

Memahami namespaces dan cgroups sangat penting bagi siapa pun yang bekerja dengan container, platform cloud, atau infrastruktur. Dalam episode ini, kami akan mendemistifikasi teknologi ini dan menunjukkan cara kerjanya di balik layar.

Pada akhirnya, Anda akan memahami bagaimana kernel mengisolasi proses, membatasi sumber daya, dan memungkinkan dunia yang dikontainerisasi tempat kami tinggal hari ini.

#Memahami Arsitektur Kernel Linux

#Apa yang Dilakukan Kernel?

Kernel Linux adalah perangkat lunak inti yang mengelola semua sumber daya perangkat keras dan memediasi akses antara aplikasi dan perangkat keras. Tanggung jawab utamanya meliputi:

Manajemen proses: Membuat, menjadwalkan, dan menghentikan proses
Manajemen memori: Mengalokasikan dan mengelola RAM, memori virtual, dan paging
Sistem file: Mengelola file, direktori, dan perangkat penyimpanan
Driver perangkat: Antarmuka dengan perangkat keras
Jaringan: Menangani protokol jaringan dan komunikasi
Keamanan: Menegakkan izin, isolasi pengguna, dan kontrol akses
Penanganan interrupt: Merespons interrupt perangkat keras dan perangkat lunak

Kernel berjalan dalam mode istimewa yang disebut "kernel space" dan melindungi dirinya dari aplikasi pengguna.

#Kernel Space vs. User Space

Linux membagi memori dan eksekusi menjadi dua ruang yang berbeda:

Kernel Space

Mode eksekusi istimewa dengan akses perangkat keras langsung
Hanya kernel yang berjalan di sini
Dapat menjalankan instruksi CPU apa pun
Akses langsung ke semua memori dan perangkat
Crash di sini akan crash seluruh sistem

User Space

Mode eksekusi terbatas untuk aplikasi
Semua aplikasi pengguna berjalan di sini
Akses perangkat keras terbatas (melalui system calls)
Isolasi memori—tidak dapat mengakses memori proses lain
Crash di sini tidak akan crash sistem

Pemisahan ini sangat penting untuk stabilitas dan keamanan sistem. Aplikasi tidak dapat langsung mengakses perangkat keras; mereka harus meminta kernel untuk melakukannya.

#System Calls: Jembatan Antar Dunia

Ketika aplikasi pengguna perlu melakukan sesuatu yang istimewa (seperti membaca file atau mengalokasikan memori), aplikasi membuat system call. Ini adalah antarmuka antara user space dan kernel space.

System calls umum meliputi:

open(): Buka file
read(): Baca dari file descriptor
write(): Tulis ke file descriptor
fork(): Buat proses baru
exec(): Jalankan program
exit(): Hentikan proses
mmap(): Peta memori
socket(): Buat socket jaringan

Ketika system call dibuat, CPU beralih dari mode pengguna ke mode kernel, kernel melakukan operasi, dan kemudian beralih kembali ke mode pengguna. Perubahan konteks ini memiliki biaya performa, itulah mengapa meminimalkan system calls penting untuk kode yang kritis terhadap performa.

#Manajemen Proses dan Penjadwalan

#Apa itu Proses?

Proses adalah instance yang sedang berjalan dari program. Setiap proses memiliki:

Process ID (PID): Pengenal unik untuk proses
Parent Process ID (PPID): Proses yang membuat proses ini
User ID (UID): Pengguna yang memiliki proses
Ruang memori: Memori terisolasi untuk proses
File descriptors: File terbuka dan koneksi jaringan
Variabel lingkungan: Konfigurasi yang diteruskan ke proses
Direktori kerja: Direktori saat ini untuk proses

Proses terisolasi satu sama lain. Satu proses crash tidak mempengaruhi yang lain (dalam kebanyakan kasus).

#Status Proses dan Siklus Hidup

Proses melalui beberapa status selama masa hidupnya:

plaintext

Running → Waiting → Stopped → Zombie → Terminated

Running: Sedang dieksekusi di CPU
Waiting/Sleeping: Menunggu I/O atau event
Stopped: Dijeda oleh signal
Zombie: Proses telah keluar tetapi parent belum mengumpulkannya
Terminated: Proses telah keluar dan dibersihkan

#Penjadwal Proses

Penjadwal proses kernel memutuskan proses mana yang berjalan di CPU pada waktu tertentu. Pada sistem multi-core, beberapa proses dapat berjalan secara bersamaan (satu per core).

Penjadwal menggunakan:

Tingkat prioritas: Proses memiliki prioritas berbeda (nilai nice dari -20 hingga 19)
Time slices: Setiap proses mendapat sejumlah kecil waktu CPU (quantum)
Preemption: Penjadwal dapat mengganggu proses yang berjalan untuk memberikan waktu CPU ke proses lain

Itulah mengapa sistem single-core dapat menjalankan ribuan proses—mereka dengan cepat beralih di antara mereka.

#Hierarki Proses dan Sistem Init

Proses membentuk hierarki pohon:

plaintext

init (PID 1)
├── systemd-journal
├── systemd-logind
├── sshd
│   └── bash (user session)
│       └── vim
└── nginx
    ├── nginx (worker)
    └── nginx (worker)

Proses pertama adalah init (PID 1), yang merupakan induk dari semua proses lainnya. Sistem Linux modern menggunakan systemd sebagai sistem init, yang mengelola layanan, dependensi, dan startup sistem.

Ketika proses induk dihentikan, anak-anaknya menjadi yatim piatu dan diadopsi oleh init. Ini mencegah proses zombie dari terakumulasi.

#Manajemen Memori

#Memori Virtual

Setiap proses memiliki ruang alamat virtual sendiri. Ini adalah fitur Linux kunci yang menyediakan:

Isolasi: Proses tidak dapat mengakses memori satu sama lain
Perlindungan: Kernel mencegah akses memori yang tidak sah
Fleksibilitas: Program dapat menggunakan lebih banyak memori daripada yang tersedia secara fisik

Alamat virtual dipetakan ke memori fisik oleh Memory Management Unit (MMU). Proses berpikir memiliki akses ke ruang memori besar dan kontinu, tetapi kernel memetakannya ke memori fisik yang terfragmentasi.

#Alokasi Memori dan Paging

Ketika proses membutuhkan memori:

Alokasi: Kernel mengalokasikan memori virtual
Demand paging: Memori fisik dialokasikan hanya ketika proses benar-benar menggunakannya
Page faults: Jika proses mengakses memori yang tidak ada di RAM fisik, page fault terjadi
Paging: Kernel memuat halaman dari disk (swap) ke RAM

Ini memungkinkan sistem menjalankan proses yang secara kolektif menggunakan lebih banyak memori daripada yang tersedia secara fisik.

#Ruang Swap

Swap adalah ruang disk yang digunakan sebagai perpanjangan RAM. Ketika memori fisik penuh:

Halaman yang paling jarang digunakan dipindahkan ke swap (disk)
Ketika diperlukan lagi, mereka dipindahkan kembali ke RAM
Ini memungkinkan sistem menangani tekanan memori

Namun, swap jauh lebih lambat daripada RAM (I/O disk ~1000x lebih lambat). Swapping berlebihan menyebabkan degradasi performa yang parah. Sistem modern mencoba meminimalkan swapping melalui manajemen memori yang lebih baik dan batas cgroup.

#Pengenalan Namespaces

#Apa itu Namespaces?

Namespaces adalah fitur kernel yang mempartisi sumber daya sistem sehingga proses dapat memiliki tampilan terisolasi dari sistem. Alih-alih semua proses melihat sumber daya sistem yang sama, setiap namespace menyediakan tampilan terpisah.

Pikirkan namespaces seperti dunia virtual. Beberapa proses dapat ada di namespace yang berbeda, masing-masing melihat versi sistem yang berbeda. Proses di satu namespace tidak dapat melihat atau berinteraksi dengan sumber daya di namespace lain.

Namespaces adalah fondasi isolasi container. Docker dan Kubernetes menggunakan namespaces untuk membuat lingkungan terisolasi untuk container.

#Jenis-Jenis Namespaces

Linux menyediakan beberapa jenis namespaces, masing-masing mengisolasi sumber daya sistem yang berbeda:

#PID Namespace

Mengisolasi ID proses. Setiap PID namespace memiliki pohon proses sendiri dengan PID 1 sendiri (proses init).

Kasus penggunaan: Container melihat pohon proses mereka sendiri, bukan proses host Contoh: Proses init container memiliki PID 1 di dalam container, tetapi mungkin PID 12345 di host

#Network Namespace

Mengisolasi sumber daya jaringan: antarmuka jaringan, alamat IP, tabel routing, aturan firewall.

Kasus penggunaan: Setiap container memiliki stack jaringan sendiri Contoh: Container dapat memiliki alamat IP sendiri, port, dan konfigurasi jaringan terpisah dari host

#Mount Namespace

Mengisolasi sistem file. Setiap namespace dapat memiliki tampilan berbeda dari hierarki sistem file.

Kasus penggunaan: Container memiliki sistem file root sendiri Contoh: / container menunjuk ke image container, bukan sistem file root host

#IPC Namespace

Mengisolasi sumber daya Inter-Process Communication: antrian pesan, memori bersama, semaphore.

Kasus penggunaan: Proses di namespace IPC berbeda tidak dapat berkomunikasi via IPC Contoh: Dua container tidak dapat berbagi memori atau antrian pesan

#UTS Namespace

Mengisolasi nama host dan nama domain.

Kasus penggunaan: Setiap container dapat memiliki nama host sendiri Contoh: Container dapat memiliki nama host "web-server" sementara host adalah "production-01"

#User Namespace

Mengisolasi ID pengguna dan grup. Proses dapat menjadi root (UID 0) di dalam user namespace tetapi pengguna biasa di host.

Kasus penggunaan: Container dapat berjalan sebagai root di dalam tetapi tidak istimewa di host Contoh: Root container (UID 0 di namespace) dipetakan ke UID 1000 di host

#Cgroup Namespace

Mengisolasi hierarki cgroup (kami akan membahas cgroups selanjutnya).

Kasus penggunaan: Proses melihat tampilan cgroup yang disederhanakan Contoh: Container melihat cgroup-nya sebagai / alih-alih /docker/container-id

#Bagaimana Namespaces Memungkinkan Isolasi

Namespaces bekerja dengan menyediakan tampilan terpisah dari sumber daya sistem. Ketika proses dibuat di namespace:

Ini mewarisi namespace dari induknya
Ini hanya dapat melihat sumber daya di namespace-nya
Ini tidak dapat mengakses sumber daya di namespace lain
Kernel menegakkan isolasi ini

Inilah cara container Docker dapat:

Menjalankan proses init mereka sendiri (PID 1)
Memiliki antarmuka jaringan dan alamat IP mereka sendiri
Memiliki sistem file mereka sendiri
Memiliki nama host mereka sendiri
Semuanya pada mesin fisik yang sama tanpa saling mengganggu

#Pengenalan Cgroups

#Apa itu Cgroups?

Cgroups (control groups) adalah fitur kernel yang membatasi, memprioritaskan, dan mengisolasi penggunaan sumber daya dari kelompok proses. Sementara namespaces menyediakan isolasi (Anda tidak dapat melihat sumber daya lain), cgroups menyediakan batas sumber daya (Anda tidak dapat menggunakan lebih dari yang diizinkan).

Cgroups memungkinkan Anda untuk:

Membatasi penggunaan CPU
Membatasi penggunaan memori
Membatasi bandwidth I/O
Membatasi bandwidth jaringan
Mengontrol akses perangkat
Memprioritaskan alokasi sumber daya

Tanpa cgroups, satu proses dapat mengkonsumsi semua CPU atau memori, membuat proses lain kelaparan. Cgroups mencegah ini.

#Cgroups v1 vs. Cgroups v2

Cgroups v1 (legacy)

Beberapa hierarki independen
Setiap jenis sumber daya (CPU, memori, I/O) memiliki hierarki sendiri
Kompleks untuk dikelola
Masih banyak digunakan

Cgroups v2 (modern)

Hierarki terpadu tunggal
Semua jenis sumber daya dalam satu pohon
Lebih sederhana untuk dikelola
Performa lebih baik
Menjadi standar (systemd menggunakannya)

Sebagian besar sistem modern sedang bertransisi ke cgroups v2, tetapi v1 masih umum dalam produksi.

#Batas Sumber Daya dengan Cgroups

#Batas CPU

Kontrol berapa banyak waktu CPU yang dapat digunakan kelompok proses:

plaintext

cpu.max = "50000 100000"  # 50% dari satu core CPU
cpu.weight = 100          # Bobot penjadwalan CPU (1-10000)

#Batas Memori

Kontrol berapa banyak memori yang dapat digunakan kelompok proses:

plaintext

memory.max = "512M"       # Batas keras: 512 MB
memory.high = "256M"      # Batas lunak: memicu reclaim pada 256 MB
memory.swap.max = "0"     # Nonaktifkan swap untuk cgroup ini

#Batas I/O

Kontrol bandwidth I/O disk:

plaintext

io.max = "8:0 rbps=10485760 wbps=10485760"  # 10 MB/s baca dan tulis

#Kontrol Akses Perangkat

Kontrol perangkat mana yang dapat diakses proses:

plaintext

devices.allow = "c 1:3 rw"   # Izinkan /dev/null (perangkat karakter 1:3)
devices.deny = "b 8:* rwm"   # Tolak semua perangkat blok

#Hierarki Cgroup

Cgroups membentuk hierarki pohon. Setiap cgroup dapat memiliki cgroup anak, dan batas sumber daya diwarisi dan ditegakkan di setiap level:

plaintext

/
├── system.slice
│   ├── systemd-logind.service
│   └── sshd.service
├── user.slice
│   └── user-1000.slice
│       └── session-1.scope
└── docker
    ├── container-1
    │   └── memory.max = 512M
    └── container-2
        └── memory.max = 1G

Batas aktual proses ditentukan oleh semua cgroups di jalurnya dari root ke leaf.

#Container: Namespaces dan Cgroups dalam Aksi

#Bagaimana Docker Menggunakan Namespaces dan Cgroups

Docker menggabungkan namespaces dan cgroups untuk membuat container terisolasi dan terbatas sumber daya:

Namespaces menyediakan isolasi: Setiap container memiliki namespace PID, jaringan, mount, IPC, UTS, dan pengguna sendiri
Cgroups menyediakan batas: Setiap container dibatasi pada sumber daya CPU, memori, dan I/O tertentu
Union filesystems menyediakan penyimpanan berlapis: Image container dibangun dari lapisan

Ketika Anda menjalankan docker run, Docker:

Membuat namespace baru untuk container
Menyiapkan batas cgroup
Memasang sistem file container
Memulai proses container di namespace baru

Proses container berpikir sedang berjalan di mesin sendiri, tetapi sebenarnya berbagi kernel host dengan container lain.

#Isolasi Container dalam Praktik

Mari lacak apa yang terjadi ketika Anda menjalankan container:

bash

docker run --name web --cpus 1 --memory 512m nginx

PID Namespace: Proses nginx mendapat PID 1 di dalam container (tetapi mungkin PID 5432 di host)
Network Namespace: Container mendapat antarmuka jaringan sendiri dengan alamat IP sendiri
Mount Namespace: Container melihat / sebagai root image nginx, bukan root host
Batas cgroup: Container dibatasi pada 1 core CPU dan 512 MB memori
User Namespace: Root container dipetakan ke pengguna tidak istimewa di host (jika dikonfigurasi)

Container sepenuhnya terisolasi dari container lain dan host, namun semuanya berbagi kernel yang sama.

#Batasan Sumber Daya dalam Container

Ketika Anda menentukan batas sumber daya di Docker atau Kubernetes, Anda menetapkan batas cgroup:

bash

# Docker: Batasi ke 2 CPU dan 1 GB memori
docker run --cpus 2 --memory 1g myapp
 
# Kubernetes: Tetapkan permintaan dan batas sumber daya
resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1000m"
    memory: "512Mi"

Batas ini ditegakkan oleh cgroups. Jika container mencoba melampaui batas memorinya, kernel membunuh proses (OOMKill). Jika mencoba menggunakan lebih banyak CPU daripada yang dialokasikan, itu dibatasi.

#Contoh Praktis: Bekerja dengan Namespaces dan Cgroups

#Melihat Namespaces

Anda dapat memeriksa namespaces di sistem Anda:

# Daftar semua namespaces untuk proses
ls -la /proc/1/ns/
 
# Tampilkan ID namespace
readlink /proc/1/ns/*
 
# Bandingkan namespaces antara proses
diff <(readlink /proc/1/ns/*) <(readlink /proc/self/ns/*)
 
# Daftar semua proses dan namespace mereka
ps aux | head -5

# Daftar semua namespaces untuk proses
ls -la /proc/1/ns/
 
# Tampilkan ID namespace
readlink /proc/1/ns/*
 
# Bandingkan namespaces antara proses
diff <(readlink /proc/1/ns/*) <(readlink /proc/self/ns/*)
 
# Daftar semua proses dan namespace mereka
ps aux | head -5

#Membuat Proses Terisolasi

Anda dapat membuat proses di namespace baru menggunakan unshare:

# Buat PID namespace baru
sudo unshare --pid --fork /bin/bash
 
# Di dalam namespace baru, PID 1 adalah bash
ps aux
 
# Buat network namespace baru
sudo unshare --net /bin/bash
 
# Di dalam, Anda memiliki antarmuka jaringan terisolasi
ip link show

# Buat PID namespace baru
sudo unshare --pid --fork /bin/bash
 
# Di dalam namespace baru, PID 1 adalah bash
ps aux
 
# Buat network namespace baru
sudo unshare --net /bin/bash
 
# Di dalam, Anda memiliki antarmuka jaringan terisolasi
ip link show

#Menetapkan Batas Sumber Daya

Anda dapat menetapkan batas cgroup menggunakan systemd-run:

# Jalankan proses dengan batas CPU (50% dari satu core)
systemd-run --scope -p CPUQuota=50% stress-ng --cpu 1
 
# Jalankan proses dengan batas memori (256 MB)
systemd-run --scope -p MemoryLimit=256M myapp
 
# Jalankan dengan kedua batas
systemd-run --scope -p CPUQuota=50% -p MemoryLimit=512M myapp

# Jalankan proses dengan batas CPU (50% dari satu core)
systemd-run --scope -p CPUQuota=50% stress-ng --cpu 1
 
# Jalankan proses dengan batas memori (256 MB)
systemd-run --scope -p MemoryLimit=256M myapp
 
# Jalankan dengan kedua batas
systemd-run --scope -p CPUQuota=50% -p MemoryLimit=512M myapp

#Memantau Penggunaan Cgroup

Pantau penggunaan sumber daya cgroups:

# Lihat penggunaan memori cgroup v2
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max
 
# Lihat penggunaan CPU
cat /sys/fs/cgroup/cpu.stat
 
# Pantau secara real-time
watch -n 1 'cat /sys/fs/cgroup/memory.current'
 
# Untuk container Docker
docker stats

# Lihat penggunaan memori cgroup v1
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
 
# Lihat penggunaan CPU
cat /sys/fs/cgroup/cpuacct/cpuacct.usage
 
# Pantau secara real-time
watch -n 1 'cat /sys/fs/cgroup/memory/memory.usage_in_bytes'
 
# Untuk container Docker
docker stats

Tip

Jalur ke file cgroup berbeda antara cgroups v1 dan v2. Sebagian besar sistem modern menggunakan cgroups v2 di /sys/fs/cgroup/, sementara sistem yang lebih lama menggunakan v1 di /sys/fs/cgroup/<resource>/.

#Kesalahan Umum dan Jebakan

#Salah Konfigurasi Batas Sumber Daya

Kesalahan: Menetapkan batas memori terlalu rendah, menyebabkan OOMKill

yaml

# BURUK: 128 MB terlalu rendah untuk sebagian besar aplikasi
resources:
  limits:
    memory: "128Mi"

Mengapa terjadi: Meremehkan kebutuhan memori aplikasi atau mencoba mengemas terlalu banyak container

Cara menghindarinya:

Pantau penggunaan memori aktual sebelum menetapkan batas
Tetapkan permintaan dan batas dengan tepat
Gunakan docker stats atau metrik Kubernetes untuk memahami penggunaan

#Tidak Memahami Warisan Namespace

Kesalahan: Menganggap proses di container dapat mengakses jaringan host

Mengapa terjadi: Salah memahami cara kerja network namespaces

Cara menghindarinya: Ingat bahwa container memiliki network namespaces terisolasi. Untuk mengakses jaringan host, gunakan --network host di Docker atau hostNetwork: true di Kubernetes.

#Mengabaikan Tekanan Memori

Kesalahan: Tidak memperhitungkan tekanan memori dan penggunaan swap

Mengapa terjadi: Menganggap batas memori adalah pemberhentian keras (mereka tidak—swap dapat memperpanjangnya)

Cara menghindarinya:

Nonaktifkan swap di container (memory.swap.max = 0)
Pantau penggunaan swap
Tetapkan batas memori yang sesuai

#Lupa Tentang Swap

Kesalahan: Mengizinkan swap unlimited, menyebabkan degradasi performa

Mengapa terjadi: Konfigurasi sistem default memungkinkan swap

Cara menghindarinya:

Secara eksplisit nonaktifkan swap untuk container
Pantau penggunaan swap di host
Pastikan memori fisik yang cukup untuk beban kerja Anda

#Praktik Terbaik untuk Manajemen Sumber Daya Tingkat Kernel

#Konfigurasi Tingkat Produksi

Tetapkan permintaan dan batas sumber daya yang sesuai:

yaml

# Contoh Kubernetes
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Permintaan adalah apa yang digunakan penjadwal untuk penempatan. Batas adalah batas keras yang ditegakkan oleh cgroups.

Nonaktifkan swap untuk performa yang dapat diprediksi:

bash

# Di Docker
docker run --memory-swap 0 myapp
 
# Di Kubernetes
securityContext:
  capabilities:
    add:
      - SYS_RESOURCE

Gunakan resource quotas di Kubernetes:

yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

#Pemantauan dan Observabilitas

Pantau metrik cgroup:

Penggunaan CPU dan throttling
Penggunaan memori dan event OOMKill
Bandwidth dan latensi I/O
Bandwidth jaringan

Gunakan alat seperti:

docker stats: Metrik container real-time
kubectl top: Penggunaan sumber daya Kubernetes
Prometheus: Pengumpulan dan alerting metrik
cAdvisor: Pengumpulan metrik container

Atur alert untuk:

Memori mendekati batas
Throttling CPU
Event OOMKill
Penggunaan swap

#Pertimbangan Keamanan

Gunakan user namespaces: Petakan root container ke pengguna tidak istimewa di host

bash

docker run --userns-remap=default myapp

Batasi akses perangkat: Hanya izinkan perangkat yang diperlukan

yaml

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

Gunakan filesystem read-only: Cegah container memodifikasi filesystem-nya

yaml

securityContext:
  readOnlyRootFilesystem: true

#Kapan TIDAK Secara Manual Mengonfigurasi Cgroups

#Gunakan Container Orchestration Sebagai Gantinya

Jangan secara manual mengonfigurasi cgroups. Gunakan Docker atau Kubernetes sebagai gantinya:

bash

# JANGAN lakukan ini secara manual
echo "512M" > /sys/fs/cgroup/memory/myapp/memory.limit_in_bytes
 
# LAKUKAN ini sebagai gantinya
docker run --memory 512m myapp

Alat orkestrasi container menangani konfigurasi cgroup untuk Anda, dengan abstraksi yang lebih baik dan penanganan kesalahan.

#Kubernetes Menangani Ini untuk Anda

Di Kubernetes, Anda menentukan permintaan dan batas sumber daya, dan Kubernetes mengelola cgroups:

yaml

# Kubernetes menangani konfigurasi cgroup
resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"

Anda tidak perlu tahu tentang cgroups untuk menggunakan Kubernetes secara efektif. Orchestrator mengabstraksi kompleksitasnya.

#Poin-Poin Kunci

Namespaces menyediakan isolasi: Setiap container memiliki tampilan terisolasi dari PID, jaringan, filesystem, IPC, hostname, dan pengguna
Cgroups menyediakan batas sumber daya: CPU, memori, I/O, dan akses perangkat dikendalikan dan dibatasi
Container menggabungkan keduanya: Docker dan Kubernetes menggunakan namespaces untuk isolasi dan cgroups untuk manajemen sumber daya
Kernel menegakkan isolasi: Proses di namespace berbeda tidak dapat saling melihat atau mengganggu
Memahami konsep ini sangat penting: Untuk pekerjaan DevOps, cloud engineering, dan infrastruktur
Jangan secara manual mengonfigurasi cgroups: Gunakan Docker atau Kubernetes sebagai gantinya—mereka menangani kompleksitasnya

#Langkah Selanjutnya

Jelajahi namespaces: Gunakan ls /proc/1/ns/ untuk melihat namespaces di sistem Anda
Bereksperimen dengan container: Jalankan container Docker dan periksa namespace mereka
Pantau cgroups: Gunakan docker stats untuk melihat penggunaan sumber daya
Baca dokumentasi kernel: /usr/share/doc/linux-doc/ atau kernel.org
Lanjutkan seri: Pindah ke Episode 3: Izin, Pengguna & Grup untuk memahami isolasi pengguna

Memahami namespaces dan cgroups adalah kunci untuk menguasai containerisasi. Konsep ini berlaku apakah Anda menggunakan Docker, Kubernetes, atau platform container lainnya.

Siap untuk episode berikutnya? Lanjutkan dengan Episode 3: Izin, Pengguna & Grup untuk menguasai manajemen izin file dan pengguna, yang sangat penting untuk keamanan container.

Penyelaman Kernel Linux Mendalam - Cgroups dan Namespaces - Episode 2 dari Seri Linux Mastery

Related Posts