Kamu sedang menampilkan dokumentasi untuk Kubernetes versi: v1.25
Kubernetes v1.25 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terbaru.
NetworkPolicy
Sebuah NetworkPolicy adalah spesifikasi dari sekelompok Pod atau endpoint yang diizinkan untuk saling berkomunikasi.
NetworkPolicy
menggunakan label untuk memilih Pod serta mendefinisikan serangkaian rule yang digunakan
untuk mendefinisikan trafik yang diizinkan untuk suatu Pod tertentu.
Prasyarat
NetworkPolicy diimplementasikan dengan menggunakan plugin jaringan,
dengan demikian kamu harus memiliki penyedia jaringan yang mendukung NetworkPolicy
-
membuat resource tanpa adanya controller tidak akan berdampak apa pun.
Pod yang terisolasi dan tidak terisolasi
Secara default, Pod bersifat tidak terisolasi; Pod-Pod tersebut menerima trafik dari resource apa pun.
Pod menjadi terisolasi apabila terdapat NetworkPolicy
yang dikenakan pada Pod-Pod tersebut.
Apabila terdapat NetworkPolicy
di dalam namespace yang dikenakan pada suatu Pod, Pod tersebut
akan menolak koneksi yang tidak diizinkan NetworkPolicy
. (Pod lain dalam namespace
yang tidak dikenakan NetworkPolicy
akan tetap menerima trafik dari semua resource.)
Resource NetworkPolicy
Lihat NetworkPolicy
untuk definisi lengkap resource.
Sebuah contoh NetworkPolicy
akan terlihat seperti berikut:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
Mengirimkan ini ke API server dengan metode POST tidak akan berdampak apa pun kecuali penyedia jaringan mendukung network policy.
Field-field yang bersifat wajib: Sama dengan seluruh config Kubernetes lainnya, sebuah NetworkPolicy
membutuhkan field-field apiVersion
, kind
, dan metadata
. Informasi generik mengenai
bagaimana bekerja dengan file config
, dapat dilihat di
Konfigurasi Kontainer menggunakan ConfigMap
,
serta Manajemen Objek.
spec: NetworkPolicy
spec memiliki semua informasi yang harus diberikan untuk memberikan definisi network policy yang ada pada namespace tertentu.
podSelector: Setiap NetworkPolicy
memiliki sebuah podSelector
yang bertugas memfilter Pod-Pod yang dikenai policy tersebut. Contoh yang ada memfilter Pod dengan label "role=db"
. Sebuah podSelector
yang empty akan memilih semua Pod yang ada di dalam namespace.
policyTypes: Setiap NetworkPolicy
memiliki sebuah daftar policyTypes
yang dapat berupa Ingress
, Egress
, atau keduanya. Field policyTypes
mengindikasikan apakah suatu policy diberikan pada trafik ingress, egress, atau camputan ingress dan egress pada Pod tertentu. Jika tidak ada policyTypes
tyang diberikan pada NetworkPolicy
maka Ingress
default akan diterapkan dan Egress
akan diterapkan apabila policy tersebut memberikan spesifikasi egress.
ingress: Setiap NetworkPolicy
bisa saja memberikan serangkaian whitelist rule-rule ingress
. Setiap rule mengizinkan trafik yang sesuai dengan section from
dan ports
. Contoh policy yang diberikan memiliki sebuah rule, yang sesuai dengan trafik pada sebuah port
single, bagian pertama dispesifikasikan melalui ipBlock
, yang kedua melalui namespaceSelector
dan yang ketiga melalui podSelector
.
egress: Setiap NetworkPolicy
bisa saja meliputi serangkaian whitelist rule-rule egress
. Setiap rule mengizinkan trafik yang sesuai dengan section to
dan ports
. Contoh policy yang diberikan memiliki sebuah rule, yang sesuai dengan port
single pada destinasi 10.0.0.0/24
.
Pada contoh, NetworkPolicy
melakukan hal berikut:
Mengisolasi Pod-Pod dengan label
"role=db"
pada namespace"default"
baik untukingress
atauegress
.(Rule
Ingress
) mengizinkan koneksi ke semua Pod pada namespace“default”
dengan label“role=db”
untuk protokol TCPport
6379
dari:- semua Pod pada namespace
"default"
dengan label"role=frontend"
- semua Pod dalam sebuah namespace dengan label
"project=myproject"
- alamat IP pada range
172.17.0.0–172.17.0.255
dan172.17.2.0–172.17.255.255
(yaitu, semua172.17.0.0/16
kecuali172.17.1.0/24
)
- semua Pod pada namespace
(Rule Egress) mengizinkan koneksi dari semua Pod pada namespace
"default"
dengan label"role=db"
ke CIDR10.0.0.0/24
untuk protokol TCP padaport
5978
Lihat mekanisme Deklarasi Network Policy untuk penjelasan lebih mendalam.
Perilaku selektor to
dan from
Terdapat empat jenis selektor yang dapat dispesifikasikan dalam section
ingress
from
atau section
egress
to
:
podSelector: Ini digunakan untuk memfilter Pod tertentu pada namespace dimana NetworkPolicy
berada yang akan mengatur destinasi ingress atau egress.
namespaceSelector: Ini digunakan untuk memfilter namespace tertentu dimana semua Pod diperbolehkan sebagai source ingress
atau destinasi egress
.
namespaceSelector and podSelector: Sebuah entri to
/from
yang memberikan spesifikasi namespaceSelector
dan podSelector
serta memilih Pod-Pod tertentu yang ada di dalam namespace. Pastikan kamu menggunakan sintaks YAML yang tepat; policy
ini:
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
podSelector:
matchLabels:
role: client
...
mengandung sebuah elemen from
yang mengizinkan koneksi dari Pod-Pod dengan label role=client
di namespace dengan label user=alice
. Akan tetapi, policy ini:
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
- podSelector:
matchLabels:
role: client
...
mengandung dua elemen pada array from
, dan mengizinkan koneksi dari Pod pada Namespace lokal dengan label
role=client
, atau dari Pod di namespace apa pun dengan label user=alice
.
Ketika kamu merasa ragu, gunakan kubectl describe
untuk melihat bagaimana Kubernetes
menginterpretasikan policy tersebut.
ipBlock: Ini digunakan untuk memilih range IP CIDR tertentu untuk berperan sebagai source ingress atau destinasi egress. Alamat yang digunakan harus merupakan alamat IP eksternal klaster, karena alamat IP Pod bersifat ephemeral dan tidak dapat ditebak.
Mekanisme ingress dan egress klaster seringkali membutuhkan mekanisme rewrite alamat IP source dan destinasi
paket. Pada kasus-kasus dimana hal ini, tidak dapat dipastikan bahwa apakah hal ini
terjadi sebelum atau setelah pemrosesan NetworkPolicy
, dan perilaku yang ada mungkin saja berbeda
untuk kombinasi plugin jaringan, penyedia layanan cloud, serta implementasi Service
yang berbeda.
Pada ingress, artinya bisa saja kamu melakukan filter paket yang masuk berdasarkan source IP
,
sementara di kasus lain "source IP" yang digunakan oleh Network Policy adalah alamat IP LoadBalancer
,
node dimana Pod berada, dsb.
Pada egress, bisa saja sebuah koneksi dari Pod ke IP Service
di-rewrite ke IP eksternal klaster
atau bahkan tidak termasuk di dalam ipBlock
policy.
Policy Default
Secara default, jika tidak ada policy yang ada dalam suatu namespace, maka semua trafik ingress dan egress yang diizinkan ke atau dari Pod dalam namespace. Contoh di bawah ini akan memberikan gambaran bagaimana kamu dapat mengubah perilaku default pada sebuah namespace.
Default: tolak semua trafik ingress
Kamu dapat membuat policy isolasi "default"
untuk sebuah namespace
dengan membuat sebuah NetworkPolicy
yang memilih semua Pod tapi tidak mengizinkan
trafik ingress masuk ke Pod-Pod tersebut.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh NetworkPolicy
lain masih terisolasi.
Policy ini tidak mengubah perilaku default dari egress.
Default: izinkan semua trafik ingress
Jika kamu ingin mengizinkan semua trafik ingress pada semua Pod dalam sebuah namespace (bahkan jika policy ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi namespace tersebut.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
ingress:
- {}
policyTypes:
- Ingress
Default: tolak semua trafik egress
Kamu dapat membuat policy isolasi "default"
untuk sebuah namespace
dengan membuat sebuah NetworkPolicy
yang memilih semua Pod tapi tidak mengizinkan
trafik egress keluar dari Pod-Pod tersebut.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Egress
Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh NetworkPolicy
lain masih terisolasi.
Policy ini tidak mengubah perilaku default dari ingress.
Default: izinkan semua trafik egress
Jika kamu ingin mengizinkan semua trafik egress pada semua Pod dalam sebuah namespace (bahkan jika policy ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi namespace tersebut.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
egress:
- {}
policyTypes:
- Egress
Default: tolak semua trafik ingress dan egress
Kamu dapat membuat sebuah policy "default" jika kamu ingin menolak semua trafik ingress maupun egress pada semua Pod dalam sebuah namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh NetworkPolicy
tidak akan mengizinkan trafik ingress atau egress.
Dukungan terhadap SCTP
Kubernetes v1.12 [alpha]
Kubernetes mendukung SCTP sebagai value protocol
pada definisi NetworkPolicy
sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator klaster harus mengaktifkan gerbang fitur SCTPSupport
pada apiserver
, contohnya “--feature-gates=SCTPSupport=true,...”
. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan value
dari field protocol
pada NetworkPolicy
menjadi SCTP
. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP.
Plugin CNI harus mendukung SCTP sebagai value dari protocol
pada NetworkPolicy
.
Selanjutnya
- Lihat Deklarasi Network Policy untuk melihat lebih banyak contoh penggunaan.
- Baca lebih lanjut soal panduan bagi skenario generik resource
NetworkPolicy
.