Pengaturan Proxy di Kluster Kubernetes: Panduan Lengkap untuk Insinyur DevOps

Saat menerapkan Kubernetes di lingkungan perusahaan atau di balik firewall, sering kali diperlukan pengaturan server proxy untuk mengakses sumber daya eksternal. Ini sangat penting untuk mengunduh gambar kontainer, memperbarui paket, dan berinteraksi dengan API eksternal. Dalam panduan ini, kita akan membahas semua tingkat pengaturan proxy di Kubernetes — dari konfigurasi node hingga pod individu.

Mengapa perlu proxy di cluster Kubernetes

Cluster Kubernetes di lingkungan perusahaan sering kali beroperasi di jaringan terisolasi dengan akses internet yang terbatas. Server proxy menyelesaikan beberapa tugas kritis:

• Pengunduhan gambar kontainer — Docker Hub, Google Container Registry, dan registry pribadi memerlukan akses eksternal
• Pembaruan paket — instalasi dependensi melalui apt, yum, pip di dalam kontainer
• Akses ke API eksternal — integrasi dengan layanan cloud, pemantauan, dan pencatatan
• Keamanan — kontrol lalu lintas, penyaringan domain, pencatatan permintaan
• Cache — mempercepat permintaan berulang ke sumber daya yang sama

Tanpa pengaturan proxy yang benar, Anda akan menghadapi kesalahan seperti "image pull failed", "connection timeout", atau "network unreachable" saat mencoba menerapkan aplikasi. Ini sangat kritis untuk pipeline CI/CD otomatis, di mana setiap detik downtime berharga.

Tingkat pengaturan proxy di Kubernetes

Kubernetes memiliki arsitektur bertingkat, dan proxy perlu diatur di setiap tingkat tergantung pada tugas:

Setiap tingkat memerlukan pengaturan terpisah, dan melewatkan salah satu dari mereka dapat menyebabkan masalah. Misalnya, jika Anda hanya mengatur proxy untuk Docker, tetapi tidak untuk pod, maka gambar akan diunduh, tetapi aplikasi di dalam kontainer tidak dapat mengakses API eksternal.

Pengaturan proxy untuk Docker dan containerd

Container runtime adalah komponen pertama yang perlu diatur, karena ia bertanggung jawab untuk mengunduh gambar kontainer dari registry eksternal. Mari kita lihat pengaturan untuk kedua runtime populer ini.

Pengaturan proxy untuk Docker

Untuk Docker, Anda perlu membuat file drop-in systemd yang akan menambahkan variabel lingkungan ke layanan Docker:

# Membuat direktori untuk konfigurasi
sudo mkdir -p /etc/systemd/system/docker.service.d

# Membuat file dengan pengaturan proxy
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# Memuat ulang konfigurasi systemd
sudo systemctl daemon-reload

# Memulai ulang Docker
sudo systemctl restart docker

# Memeriksa apakah pengaturan diterapkan
sudo systemctl show --property=Environment docker

Setelah itu, Docker akan dapat mengunduh gambar melalui server proxy. Anda dapat memeriksa fungsinya dengan perintah:

docker pull nginx:latest

Pengaturan proxy untuk containerd

Containerd digunakan di cluster Kubernetes modern sebagai container runtime utama. Pengaturan proxy untuknya sedikit berbeda:

# Membuat direktori untuk konfigurasi
sudo mkdir -p /etc/systemd/system/containerd.service.d

# Membuat file dengan pengaturan proxy
sudo tee /etc/systemd/system/containerd.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# Memuat ulang konfigurasi
sudo systemctl daemon-reload
sudo systemctl restart containerd

# Memeriksa status
sudo systemctl status containerd

Konfigurasi proxy untuk kubelet

Kubelet adalah agen Kubernetes yang berjalan di setiap node cluster. Ia juga memerlukan akses ke server API dan sumber daya eksternal. Pengaturan tergantung pada cara instalasi Kubernetes.

Untuk cluster kubeadm

Jika Anda menggunakan kubeadm, atur proxy melalui systemd:

# Membuat direktori untuk konfigurasi kubelet
sudo mkdir -p /etc/systemd/system/kubelet.service.d

# Membuat file dengan pengaturan proxy
sudo tee /etc/systemd/system/kubelet.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"
EOF

# Memuat ulang kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Untuk Kubernetes yang dikelola (EKS, GKE, AKS)

Di layanan Kubernetes yang dikelola, pengaturan kubelet biasanya dilakukan melalui parameter peluncuran node atau skrip user data. Misalnya, untuk AWS EKS:

#!/bin/bash
# Skrip user data untuk node pekerja EKS

# Pengaturan proxy untuk sistem
cat <<EOF >> /etc/environment
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local
EOF

# Pengaturan untuk kubelet
mkdir -p /etc/systemd/system/kubelet.service.d
cat <<EOF > /etc/systemd/system/kubelet.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local"
EOF

systemctl daemon-reload
systemctl restart kubelet

Perhatikan penambahan 169.254.169.254 ke NO_PROXY — ini adalah alamat layanan metadata AWS yang harus dapat diakses tanpa proxy.

Pengaturan proxy di tingkat pod

Bahkan jika Anda telah mengatur proxy untuk Docker dan kubelet, aplikasi di dalam pod tidak akan secara otomatis menggunakan proxy. Anda perlu secara eksplisit menentukan variabel lingkungan dalam manifest Kubernetes.

Pengaturan melalui manifest Deployment

Cara paling sederhana adalah menambahkan variabel lingkungan ke spesifikasi kontainer:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        env:
        - name: HTTP_PROXY
          value: "http://proxy.company.com:8080"
        - name: HTTPS_PROXY
          value: "http://proxy.company.com:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"
        ports:
        - containerPort: 8080

Menggunakan ConfigMap untuk pengaturan terpusat

Agar tidak menduplikasi pengaturan proxy di setiap Deployment, buatlah ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: default
data:
  HTTP_PROXY: "http://proxy.company.com:8080"
  HTTPS_PROXY: "http://proxy.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

Kemudian gunakan ConfigMap ini dalam Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        envFrom:
        - configMapRef:
            name: proxy-config

Pendekatan ini menyederhanakan manajemen: ketika alamat proxy berubah, cukup perbarui ConfigMap, dan setelah pod di-restart, pengaturan baru akan diterapkan secara otomatis.

Injeksi otomatis melalui MutatingWebhook

Untuk menambahkan variabel proxy secara otomatis ke semua pod, Anda dapat menggunakan MutatingAdmissionWebhook. Ini adalah pendekatan yang lebih maju yang memerlukan pengembangan layanan webhook Anda sendiri, tetapi memungkinkan pengelolaan pengaturan secara terpusat tanpa mengubah manifest aplikasi.

Konfigurasi NO_PROXY yang benar

Variabel NO_PROXY menentukan alamat dan domain mana yang harus melewati server proxy. Pengaturan NO_PROXY yang salah adalah penyebab paling umum masalah di cluster Kubernetes.

Pengecualian wajib untuk Kubernetes

Alamat dan rentang berikut SELALU harus ada di NO_PROXY:

Contoh konfigurasi NO_PROXY lengkap

NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,10.96.0.0/12,.cluster.local,.svc,.default.svc,.default.svc.cluster.local,kubernetes.default.svc,kubernetes.default.svc.cluster.local

Pengaturan kubectl untuk bekerja melalui proxy

Jika Anda mengelola cluster dari workstation yang berada di belakang proxy, atur variabel lingkungan untuk kubectl:

# Untuk Linux/macOS - tambahkan ke ~/.bashrc atau ~/.zshrc
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,kubernetes.default.svc,.cluster.local

# Untuk Windows PowerShell
$env:HTTP_PROXY="http://proxy.company.com:8080"
$env:HTTPS_PROXY="http://proxy.company.com:8080"
$env:NO_PROXY="localhost,127.0.0.1,kubernetes.default.svc,.cluster.local"

Setelah itu, kubectl akan dapat terhubung ke server API cluster melalui proxy. Periksa fungsinya:

kubectl cluster-info
kubectl get nodes

Pengaturan proxy dengan otentikasi

Jika server proxy memerlukan otentikasi, tambahkan kredensial ke URL:

export HTTP_PROXY=http://username:password@proxy.company.com:8080
export HTTPS_PROXY=http://username:password@proxy.company.com:8080

Diagnostik dan pemecahan masalah umum

Bahkan dengan pengaturan yang benar, masalah dapat muncul. Mari kita lihat kesalahan yang paling umum dan cara mengatasinya.

Kesalahan "ImagePullBackOff" saat mengunduh gambar

Gejala: Pod tidak dapat dijalankan, di event menunjukkan kesalahan "Failed to pull image" atau "connection timeout".

Diagnostik:

# Periksa event pod
kubectl describe pod <pod-name>

# Periksa pengaturan proxy di Docker/containerd
sudo systemctl show --property=Environment docker
sudo systemctl show --property=Environment containerd

# Coba unduh gambar secara manual di node
sudo docker pull nginx:latest
sudo crictl pull nginx:latest

Penyelesaian: Pastikan proxy diatur untuk container runtime dan domain registry gambar tidak ada di NO_PROXY.

Masalah dengan resolusi DNS di dalam cluster

Gejala: Pod tidak dapat saling menghubungi melalui nama DNS (misalnya, service-name.namespace.svc.cluster.local).

Diagnostik:

# Periksa DNS dari pod
kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default

# Periksa variabel proxy di pod
kubectl exec -it <pod-name> -- env | grep PROXY

Penyelesaian: Tambahkan .cluster.local dan .svc ke NO_PROXY.

Kinerja lambat atau timeout saat mengakses API eksternal

Gejala: Aplikasi berjalan lambat atau mendapatkan timeout saat melakukan permintaan ke layanan eksternal.

Diagnostik:

# Periksa ketersediaan proxy dari pod
kubectl exec -it <pod-name> -- curl -v -x http://proxy.company.com:8080 https://www.google.com

# Ukur waktu respons
kubectl exec -it <pod-name> -- time curl -x http://proxy.company.com:8080 https://api.example.com

Penyelesaian: Masalah mungkin terletak pada kinerja server proxy. Pertimbangkan untuk menggunakan proxy residensial dengan lokasi geografis yang dekat untuk mengurangi latensi.

Kesalahan SSL/TLS saat bekerja melalui proxy

Gejala: Kesalahan seperti "certificate verify failed" atau "SSL handshake failed".

Penyebab: Beberapa server proxy melakukan inspeksi SSL (dekripsi lalu lintas HTTPS), yang memerlukan pemasangan sertifikat root proxy.

Penyelesaian:

# Buat ConfigMap dengan sertifikat proxy
kubectl create configmap proxy-ca-cert --from-file=ca.crt=/path/to/proxy-ca.crt

# Pasang sertifikat di pod dan tambahkan ke penyimpanan sistem
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        volumeMounts:
        - name: proxy-ca
          mountPath: /usr/local/share/ca-certificates/proxy-ca.crt
          subPath: ca.crt
      volumes:
      - name: proxy-ca
        configMap:
          name: proxy-ca-cert

Praktik terbaik untuk proxy di produksi

Berdasarkan pengalaman menjalankan cluster Kubernetes di lingkungan perusahaan, berikut adalah rekomendasi untuk bekerja dengan proxy yang andal:

1. Gunakan server proxy yang sangat tersedia

Proxy menjadi titik kegagalan tunggal untuk seluruh cluster. Atur beberapa server proxy di belakang load balancer:

HTTP_PROXY=http://proxy-lb.company.com:8080

Di mana proxy-lb.company.com adalah load balancer di depan beberapa server proxy.

2. Pengelolaan konfigurasi terpusat

Gunakan ConfigMap atau Secret untuk menyimpan pengaturan proxy daripada menghardcode di setiap manifest:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-proxy-config
  namespace: kube-system
data:
  HTTP_PROXY: "http://proxy-lb.company.com:8080"
  HTTPS_PROXY: "http://proxy-lb.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

3. Pemantauan dan peringatan

Atur pemantauan ketersediaan server proxy dan peringatan saat terjadi masalah:

• Waktu respons proxy (harus < 100ms untuk proxy lokal)
• Jumlah kesalahan koneksi ke proxy
• Jumlah event ImagePullBackOff di cluster
• Penggunaan CPU dan jaringan di server proxy

4. Dokumentasikan pengecualian NO_PROXY

Simpan dokumentasi tentang domain dan alamat IP yang ditambahkan ke NO_PROXY dan alasannya. Ini akan membantu dalam pemecahan masalah dan audit keamanan.

5. Uji perubahan di lingkungan dev

Sebelum mengubah pengaturan proxy di produksi, selalu uji di cluster dev/staging:

# Pod uji untuk memeriksa proxy
apiVersion: v1
kind: Pod
metadata:
  name: proxy-test
spec:
  containers:
  - name: test
    image: curlimages/curl:latest
    command: ["sleep", "3600"]
    env:
    - name: HTTP_PROXY
      value: "http://new-proxy.company.com:8080"
    - name: HTTPS_PROXY
      value: "http://new-proxy.company.com:8080"

# Periksa ketersediaan sumber daya eksternal
kubectl exec -it proxy-test -- curl -v https://registry.k8s.io
kubectl exec -it proxy-test -- curl -v https://docker.io

6. Gunakan berbagai jenis proxy untuk berbagai tugas

Untuk komponen kritis (pengunduhan gambar, API cluster), gunakan proxy cepat data center, dan untuk aplikasi yang memerlukan keragaman geografis IP — gunakan proxy residensial atau mobile.

7. Secara teratur perbarui daftar NO_PROXY

Saat menambahkan layanan baru atau mengubah topologi jaringan, perbarui NO_PROXY. Otomatiskan ini melalui Helm charts atau Kustomize:

# values.yaml untuk Helm chart
proxy:
  enabled: true
  http: "http://proxy.company.com:8080"
  https: "http://proxy.company.com:8080"
  noProxy:
    - localhost
    - 127.0.0.1
    - .cluster.local
    - .svc
    - 10.0.0.0/8
    - internal-service.company.com

Kesimpulan

Pengaturan proxy di cluster Kubernetes adalah tugas bertingkat yang memerlukan perhatian terhadap detail di setiap tingkat: dari sistem operasi dan container runtime hingga pod individu. Konfigurasi yang benar memastikan operasi cluster yang lancar, akses aman ke sumber daya eksternal, dan kepatuhan terhadap kebijakan keamanan perusahaan.

Poin-poin kunci yang perlu diingat:

• Atur proxy di semua tingkat: OS, container runtime, kubelet, pod
• Konfigurasikan NO_PROXY dengan benar, termasuk semua jaringan internal cluster
• Gunakan pengelolaan terpusat melalui ConfigMap
• Pantau ketersediaan dan kinerja server proxy
• Uji perubahan sebelum menerapkannya di produksi

Untuk cluster Kubernetes yang kritis, disarankan untuk menggunakan proxy data center yang andal dengan ketersediaan tinggi dan latensi rendah. Ini akan memastikan operasi infrastruktur yang stabil dan meminimalkan risiko downtime akibat masalah akses jaringan.

Jika terjadi masalah, gunakan pendekatan sistematis untuk diagnostik: periksa pengaturan di setiap tingkat, analisis log dan event, uji koneksi secara manual. Sebagian besar masalah dengan proxy di Kubernetes dapat diselesaikan dengan pengaturan variabel lingkungan dan NO_PROXY yang benar.