Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Menggunakan GKE Dataplane V2

Autopilot Standard

Halaman ini menjelaskan cara mengaktifkan dan memecahkan masalah GKE Dataplane V2 untuk cluster Google Kubernetes Engine (GKE).

GKE Dataplane V2 selalu diaktifkan di cluster Autopilot baru. Jika Anda mengalami masalah saat menggunakan GKE Dataplane V2, lanjutkan ke Pemecahan masalah.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

Aktifkan Google Kubernetes Engine API.

Aktifkan Google Kubernetes Engine API

Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda terutama menggunakan cluster zona, tetapkan compute/zone. Dengan menyetel lokasi default, Anda dapat menghindari error di gcloud CLI yang seperti ini: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan default yang Anda tetapkan.

Peran yang diperlukan

Untuk mendapatkan izin yang diperlukan guna membuat cluster GKE, minta administrator untuk memberi Anda peran IAM Kubernetes Engine Cluster Admin (container.clusterAdmin) di project Anda. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Membuat cluster GKE dengan GKE Dataplane V2

Anda hanya dapat mengaktifkan GKE Dataplane V2 saat membuat cluster GKE baru. Anda tidak dapat mengubah setelan ini untuk cluster yang ada.

Untuk membuat cluster Standard yang menggunakan GKE Dataplane V2, pilih salah satu opsi berikut:

Konsol

Di konsol Google Cloud , buka halaman Create a Kubernetes cluster.
Buka Membuat cluster Kubernetes
Di menu navigasi, klik Networking.
Luaskan bagian Container Network Interface (CNI).
Centang kotak Dataplane V2.
Klik Create.

gcloud

Jalankan perintah berikut:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-dataplane-v2

Ganti kode berikut:

CLUSTER_NAME: nama untuk cluster baru Anda.
CONTROL_PLANE_LOCATION: lokasi untuk bidang kontrol cluster.

API

Untuk membuat cluster baru dengan GKE Dataplane V2, tentukan kolom datapathProvider di objek networkConfig di permintaan create cluster Anda.

Cuplikan JSON berikut menunjukkan konfigurasi yang diperlukan untuk mengaktifkan GKE Dataplane V2:

"cluster":{
    "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
    }
}

Memecahkan masalah pada GKE Dataplane V2

Bagian ini menunjukkan cara menyelidiki dan menyelesaikan masalah pada GKE Dataplane V2.

Pastikan GKE Dataplane V2 telah diaktifkan:
```
kubectl -n kube-system get pods -l k8s-app=cilium -o wide
```
Jika GKE Dataplane V2 berjalan, output-nya akan menyertakan Pod dengan awalan anetd-. anetd adalah pengontrol jaringan untuk GKE Dataplane V2.
Jika masalah ini terkait dengan penerapan kebijakan jaringan atau layanan, periksa log Pod anetd. Gunakan pemilih log berikut di Cloud Logging:
```
resource.type="k8s_container"
labels."k8s-pod/k8s-app"="cilium"
resource.labels.cluster_name="CLUSTER_NAME"
```
Jika pembuatan Pod gagal, periksa log kubelet untuk mendapatkan petunjuk. Gunakan pemilih log berikut di Cloud Logging:
```
resource.type="k8s_node"
log_name=~".*/logs/kubelet"
resource.labels.cluster_name="CLUSTER_NAME"
```
Ganti CLUSTER_NAME dengan nama cluster, atau hapus seluruhnya untuk melihat log semua cluster.
Jika Pod anetd tidak berjalan, periksa modifikasi apa pun pada cilium-config ConfigMap. Hindari mengubah kolom yang ada dalam ConfigMap ini, karena perubahan tersebut dapat mengganggu stabilitas cluster dan mengganggu anetd. ConfigMap akan di-patch kembali ke status default hanya jika kolom baru ditambahkan ke ConfigMap. Perubahan apa pun pada kolom yang ada tidak akan ditambal kembali, dan sebaiknya jangan mengubah atau menyesuaikan ConfigMap.

Masalah umum

Saat menggunakan GKE Dataplane V2, Anda mungkin mengalami masalah umum berikut.

Waktu tunggu koneksi habis untuk Pod yang belum siap

Jika Pod tidak siap, koneksi ke Service terkait dapat mengalami waktu tunggu habis. Ini adalah perilaku yang diharapkan untuk GKE Dataplane V2, dan berbeda dengan kube-proxy, yang dapat menampilkan error connection refused lebih cepat.

Pemfilteran Label yang Relevan dengan Identitas untuk Identitas Cilium tidak berlaku dan Pod macet dalam status ContainerCreating

Versi yang terpengaruh: 1.34, 1.35

Di cluster GKE Dataplane V2, penggunaan darurat pemfilteran Label yang Relevan dengan Identitas melalui ConfigMap kube-system/cilium-config-emergency-override tidak diterapkan dengan benar pada versi yang terpengaruh.

Pendekatan ini membatasi label Pod yang digunakan untuk pembuatan Identitas Cilium.

Jika mekanisme lain untuk mencegah/menghapus nilai/kunci label kardinalitas tinggi dari Pod tidak tersedia (seperti saat label diterapkan oleh alat atau framework), pemfilteran Label yang Relevan dengan Identitas dapat digunakan untuk mengecualikan kunci label dari penghitungan Identitas Cilium. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi aturan ini, lihat Label yang Relevan dengan Identitas dalam dokumentasi Cilium.

Untuk versi GKE yang terpengaruh, identitas Cilium yang dibuat oleh operator terus menyertakan label yang dikecualikan.

Gejala

Pod dengan label yang harus difilter untuk pembuatan Identitas Cilium mungkin gagal dimulai dan macet dalam status ContainerCreating. Peristiwa pod mungkin menampilkan error waktu tunggu:

  {"level":"warning", "msg":"Error changing endpoint identity", "error":"unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key ...;, error: exponential backoff cancelled via context: context canceled", "k8sPodName":"...", "subsys":"endpoint"}

Daripada membagikan identitas berdasarkan label yang difilter, Pod dengan nilai label unik terus menghasilkan Identitas Cilium yang unik. Hal ini dapat menyebabkan peningkatan tajam jumlah identitas, yang berpotensi menghabiskan Identitas Cilium yang tersedia (hingga batas 65.536) dan menyebabkan masalah skalabilitas.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

1.34.6-gke.1307000 atau yang lebih baru
1.35.2-gke.1962000 atau yang lebih baru

Solusi

Sebagai solusi sementara, terapkan aturan pemfilteran label ke kolom data.labels di ConfigMap cilium-config utama dan hapus dari cilium-config-emergency-override. Situasi ini berlanjut melalui operasi bidang kontrol, seperti upgrade, karena GKE mempertahankan modifikasi pengguna pada kolom yang tidak dikelolanya dalam ConfigMap cilium-config.

Hapus kunci labels dari bagian data di ConfigMap cilium-config-emergency-override jika ada.

Edit ConfigMap cilium-config dengan menambahkan atau mengubah kunci labels di bagian data. Misalnya, untuk mencegah label bernama uuid digunakan untuk pembuatan identitas:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  # ... other existing keys
  labels: "!uuid"
  # ... other existing keys

Mulai ulang anet-operator di bidang kontrol dengan mengupgrade bidang kontrol ke versi yang sama dengan yang dijalankannya. Tindakan ini akan memaksa operator untuk memulai ulang dan memuat ulang konfigurasinya:

gcloud container clusters upgrade CLUSTER_NAME \
    --location CLUSTER_LOCATION \
    --project PROJECT_ID \
    --cluster-version $(gcloud container clusters describe CLUSTER_NAME --location CLUSTER_LOCATION --project PROJECT_ID --format="value(currentMasterVersion)") \
    --master

Setelah bidang kontrol dimulai ulang, mulai ulang DaemonSet anetd untuk memastikan agen node juga menerapkan perubahan yang diperlukan:
```
kubectl rollout restart daemonset anetd -n kube-system
```

Masalah konektivitas terputus-putus yang terkait dengan konflik rentang `NodePort` di cluster GKE Dataplane V2

Di cluster GKE Dataplane V2, masalah konektivitas yang tidak rutin dapat terjadi untuk traffic yang di-masquerade atau dengan penggunaan port sementara. Masalah ini disebabkan oleh potensi konflik port dengan rentang NodePort yang dicadangkan dan biasanya terjadi dalam skenario berikut:

ip-masq-agent Kustom: Jika Anda menggunakan ip-masq-agent kustom (versi 2.10 atau yang lebih baru), dan cluster memiliki layanan NodePort atau Load Balancer, Anda mungkin mengalami masalah konektivitas yang tidak stabil karena konflik dengan rentang NodePort. Sejak versi 2.10 dan yang lebih baru, argumen --random-fully di ip-masq-agent diterapkan secara internal secara default. Untuk mengurangi risiko ini, setel --random-fully=false secara eksplisit (berlaku sejak versi 2.11) di bagian argumen dalam konfigurasi ip-masq-agent Anda. Untuk mengetahui detail konfigurasi, lihat Mengonfigurasi agen penyamaran IP di cluster Standard.
Tumpang-tindih rentang port efemeral: Jika rentang port efemeral yang ditentukan oleh net.ipv4.ip_local_port_range di node GKE Anda tumpang-tindih dengan rentang NodePort (30000-32767), hal ini juga dapat memicu masalah konektivitas. Untuk mencegah masalah ini, pastikan kedua rentang ini tidak tumpang-tindih.

Tinjau konfigurasi ip-masq-agent dan setelan rentang port sementara Anda untuk memastikan tidak bertentangan dengan rentang NodePort. Jika Anda mengalami masalah konektivitas yang tidak konsisten, pertimbangkan kemungkinan penyebab ini dan sesuaikan konfigurasi Anda.

Masalah konektivitas dengan `hostPort` di cluster GKE Dataplane V2

Versi GKE yang terpengaruh: 1.29 dan yang lebih baru

Di cluster yang menggunakan GKE Dataplane V2, Anda mungkin mengalami kegagalan konektivitas saat traffic menargetkan IP:Port node dengan port adalah hostPort yang ditentukan di Pod. Masalah ini muncul dalam dua skenario utama:

Node dengan hostPort di belakang Load Balancer Jaringan passthrough:

hostPort mengikat Pod ke port node tertentu, dan Network Load Balancer passthrough mendistribusikan traffic di semua node. Saat Anda mengekspos Pod ke internet menggunakan hostPort dan Load Balancer Jaringan passthrough, load balancer mungkin mengirimkan traffic ke node tempat Pod tidak berjalan, sehingga menyebabkan kegagalan koneksi. Hal ini disebabkan oleh batasan umum di GKE Dataplane V2 tempat traffic Load Balancer Jaringan passthrough tidak diteruskan secara konsisten ke Pod hostPort.

Solusi: Saat mengekspos hostPort Pod di node dengan Load Balancer Jaringan passthrough, tentukan alamat IP internal atau eksternal Load Balancer Jaringan di kolom hostIP Pod.
```
ports:
- containerPort: 62000
  hostPort: 62000
  protocol: TCP
  hostIP: 35.232.62.64
- containerPort: 60000
  hostPort: 60000
  protocol: TCP
  hostIP: 35.232.62.64
  # Assuming 35.232.62.64 is the external IP address of a passthrough Network Load Balancer.
```
Konflik hostPort dengan rentang NodePort yang dicadangkan:

Jika hostPort Pod bertentangan dengan rentang NodePort yang dicadangkan (30000-32767), Cilium mungkin gagal meneruskan traffic ke Pod. Perilaku ini telah diamati di cluster versi 1.29 dan yang lebih baru karena Cilium kini mengelola kemampuan hostPort, menggantikan metode Portmap sebelumnya. Hal ini adalah perilaku yang diharapkan untuk Cilium dan disebutkan dalam dokumentasi publiknya.

Kami tidak berencana memperbaiki batasan ini di versi berikutnya. Akar penyebab masalah ini terkait dengan perilaku Cilium dan berada di luar kontrol langsung GKE.

Rekomendasi: Sebaiknya Anda bermigrasi ke Layanan NodePort, bukan hostPort, untuk meningkatkan keandalan. Layanan NodePort menyediakan kemampuan yang serupa.

Rentang port untuk kebijakan jaringan tidak diterapkan

Versi GKE yang terpengaruh: lebih lama dari 1.32

Jika Anda menentukan kolom endPort dalam objek NetworkPolicy di cluster yang telah mengaktifkan GKE Dataplane V2 dan menjalankan GKE versi yang lebih lama dari 1.32, Kubernetes akan mengabaikan kolom tersebut.

Kubernetes NetworkPolicy API memungkinkan Anda menentukan rentang port tempat Kubernetes menerapkan kebijakan jaringan. API ini didukung di cluster dengan Kebijakan Jaringan Calico, dan di cluster dengan GKE Dataplane V2 yang menjalankan GKE versi 1.32 atau yang lebih baru. API tidak didukung di cluster GKE Dataplane V2 yang menjalankan versi sebelum 1.32.

Untuk memverifikasi perilaku objek NetworkPolicy, baca kembali objek tersebut setelah menulisnya ke server API. Jika objek masih berisi kolom endPort, Kubernetes akan menerapkan fitur ini. Jika kolom endPort tidak ada, Kubernetes tidak akan menerapkan fitur tersebut. Objek yang disimpan di server API adalah sumber tepercaya untuk kebijakan jaringan.

Untuk mengetahui informasi selengkapnya, lihat KEP-2079: Kebijakan Jaringan untuk mendukung Rentang Port.

Versi tetap

Untuk mengatasi masalah ini, upgrade cluster Anda ke GKE versi 1.32 atau yang lebih baru.

Kebijakan Jaringan memutuskan koneksi karena pencarian pelacakan koneksi salah

Saat Pod klien terhubung ke dirinya sendiri menggunakan Service atau alamat IP virtual dari Load Balancer Jaringan passthrough internal, paket balasan tidak akan diidentifikasi sebagai bagian dari koneksi yang ada karena pencarian conntrack yang salah di dataplane. Ini berarti Kebijakan Jaringan yang membatasi traffic masuk untuk Pod diterapkan secara tidak benar pada paket.

Dampak masalah ini bergantung pada jumlah Pod yang dikonfigurasi untuk Service. Misalnya, jika Service memiliki 1 Pod backend, koneksi akan selalu gagal. Jika Service memiliki 2 Pod backend, koneksi akan gagal 50% dari waktu tersebut.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

1.28.3-gke.1090000 atau yang lebih baru.

Solusi

Anda dapat mengurangi masalah ini dengan mengonfigurasi port dan containerPort di manifes Service ke nilai yang sama.

Penurunan paket untuk alur koneksi hairpin

Saat Pod membuat koneksi TCP ke dirinya sendiri menggunakan Service—Pod tersebut menjadi sumber sekaligus tujuan koneksi—maka pelacakan koneksi eBPF GKE Dataplane V2 akan salah melacak status koneksi sehingga menyebabkan kebocoran entri conntrack.

Jika tuple koneksi (protokol, alamat IP sumber atau tujuan, dan port sumber atau tujuan) bocor, koneksi baru yang menggunakan tuple koneksi yang sama dapat mengakibatkan paket yang ditampilkan dihapus.

Versi tetap

Untuk memperbaiki masalah ini, upgrade cluster Anda ke salah satu versi GKE berikut:

1.28.3-gke.1090000 atau yang lebih baru
1.27.11-gke.1097000 atau yang lebih baru

Solusi

Gunakan salah satu dari solusi sementara berikut:

Mengaktifkan penggunaan ulang TCP (keep-alive) untuk aplikasi yang berjalan di Pod yang dapat berkomunikasi dengan dirinya sendiri melalui Service. Tindakan ini akan mencegah flag TCP FIN dikeluarkan dan menghindari kebocoran entri conntrack.
Saat menggunakan koneksi dengan durasi aktif pendek, ekspos Pod akan menggunakan load balancer proxy, seperti Gateway, untuk mengekspos Service. Akibatnya, tujuan permintaan koneksi ditetapkan ke alamat IP load balancer sehingga mencegah GKE Dataplane V2 melakukan SNAT ke alamat IP loopback.

Upgrade bidang kontrol GKE menyebabkan kebuntuan Pod `anetd`

Saat mengupgrade cluster GKE yang telah mengaktifkan GKE Dataplane V2 (jalur data lanjutan) dari versi 1.27 ke 1.28, Anda mungkin mengalami situasi kebuntuan. Workload mungkin mengalami gangguan karena tidak dapat menghentikan Pod lama atau menjadwalkan komponen yang diperlukan seperti anetd.

Penyebab

Proses upgrade cluster meningkatkan persyaratan resource untuk komponen GKE Dataplane V2. Peningkatan ini dapat menyebabkan perebutan resource, yang mengganggu komunikasi antara plugin Cilium Container Network Interface (CNI) dan daemon Cilium.

Gejala

Anda mungkin melihat gejala berikut:

anetd Pod tetap terjebak dalam status Pending.
Pod Workload macet dalam status Terminating.
Error yang menunjukkan kegagalan komunikasi Cilium, seperti failed to connect to Cilium daemon.

Error selama pembersihan resource jaringan untuk sandbox Pod, misalnya:

1rpc error: code = Unknown desc = failed to destroy network for sandbox "[sandbox_id]": plugin type="cilium-cni" failed (delete): unable to connect to Cilium daemon... connection refused

Solusi

Cluster standar: Untuk mengatasi masalah ini dan mengizinkan Pod anetd dijadwalkan, tingkatkan sementara resource yang dapat dialokasikan pada node yang terpengaruh dengan mengikuti langkah-langkah berikut:

Identifikasi node yang terpengaruh dan periksa CPU dan memori yang dapat dialokasikan:

kubectl get nodes NODE_NAME -o json | jq '.status.allocatable | {cpu, memory}'

Tingkatkan CPU dan memori yang dapat dialokasikan untuk sementara:
```
kubectl patch node NODE_NAME -p '{"status":{"allocatable":{"cpu":CPU_VALUE, "memory":MEMORY_VALUE}}}'
```
Ganti kode berikut:
- NODE_NAME: nama node yang terpengaruh.
- CPU_VALUE: nilai CPU baru. Tambahkan buffer 500m ke nilai CPU saat ini yang diidentifikasi pada langkah sebelumnya. Misalnya, jika nilai saat ini adalah 1500m, gunakan 2 (yang setara dengan 2000m).
- MEMORY_VALUE: nilai memori baru. Tambahkan buffer 512Mi (yang setara dengan 0.5Gi) ke nilai memori saat ini yang diidentifikasi pada langkah sebelumnya. Misalnya, jika nilai saat ini adalah 3.5Gi, gunakan 4Gi.
Misalnya, untuk meningkatkan CPU yang dapat dialokasikan menjadi 2 dan memori menjadi 4Gi di node gke-cluster-node-1, jalankan:
```
kubectl patch node gke-cluster-node-1 -p '{"status":{"allocatable":{"cpu":"2", "memory":"4Gi"}}}'
```

Cluster Autopilot: Untuk mengatasi masalah kebuntuan pada cluster Autopilot, bebaskan resource dengan menghapus Pod yang terpengaruh secara paksa:

kubectl delete pod POD_NAME -n NAMESPACE --grace-period=0 --force

Ganti kode berikut:

POD_NAME: nama Pod.
NAMESPACE: namespace Pod.

Setelah Anda meningkatkan resource yang dapat dialokasikan di node dan saat upgrade dari GKE versi 1.27 ke 1.28 selesai, Pod anetd akan berjalan di versi yang lebih baru.

Node dalam status `NodeNotReady` karena error `containerID` yang tidak ada

Saat diupgrade ke GKE versi 1.35.1-gke.1616000 dan yang lebih baru, node dapat langsung memasuki status NodeNotReady jika GKE Dataplane V2 dan Cloud Service Mesh diaktifkan.

Penyebab

Mulai GKE versi 1.35.1-gke.1616000, cluster GKE Dataplane V2 menggunakan CNI versi 1.1.0 dalam file konfigurasi CNI-nya. Perubahan ini mengharuskan plugin CNI hilir, seperti Istio yang Dikelola Google, untuk juga mendukung CNI versi 1.1.0. Karena adanya penundaan dalam peluncuran Managed Istio, beberapa cluster belum menerima versi yang kompatibel (1.23), sehingga menyebabkan kegagalan inisialisasi.

Gejala

Node yang terpengaruh akan langsung ditampilkan sebagai NodeNotReady. Pesan error berikut muncul di log containerd:

NetworkPluginNotReady message:Network plugin returns error: missing containerID

Solusi

Untuk mengatasi masalah ini, downgrade cluster yang terpengaruh ke versi GKE sebelum 1.35.1-gke.1616000.

Interferensi program eBPF kustom

GKE menggunakan program eBPF untuk mengelola jaringan untuk GKE Dataplane V2. Jika Anda men-deploy program eBPF kustom pada antarmuka jaringan node yang dikelola GKE, program ini dapat mengganggu program eBPF yang dikelola GKE dan menyebabkan masalah jaringan.

GKE tidak mendukung program eBPF kustom yang terpasang ke antarmuka jaringan berikut:

eth*
ens4
lo
cilium*
gke*
veth*

Keberadaan program eBPF kustom pada antarmuka ini dapat mengganggu program yang diinstal agen anetd GKE Dataplane V2, yang dapat mengganggu jaringan cluster. Sebaiknya hapus program eBPF kustom atau workload yang menyuntikkan program tersebut dari cluster Anda.

Menemukan program eBPF kustom

Untuk menemukan program eBPF kustom yang berjalan di node cluster, Anda dapat membuat DaemonSet yang dikonfigurasi dengan setelan hostNetwork: true, yang menggunakan bpftool untuk mengkueri program eBPF tersebut:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: bpftool-logger
  labels:
    app: bpftool-logger
spec:
  selector:
    matchLabels:
      app: bpftool-logger
  template:
    metadata:
      labels:
        app: bpftool-logger
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: bpftool
        image: ubuntu:22.04
        securityContext:
          privileged: true
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        command:
        - /bin/bash
        - -c
        - |
          echo "Installing dependencies..."
          apt-get update -y > /dev/null 2>&1
          apt-get install -y curl tar > /dev/null 2>&1

          echo "Downloading and setting up bpftool..."
          curl -sL https://github.com/libbpf/bpftool/releases/download/v7.7.0/bpftool-v7.7.0-amd64.tar.gz | tar xz
          chmod +x bpftool
          mv bpftool /usr/local/bin/

          echo "========== $(date) | Node: ${NODE_NAME} =========="
          bpftool net | grep -E '^(eth|ens4|lo|cilium|gke|veth)' | grep -v ' cil_'
          sleep infinity

Simpan manifes sebagai ebpf-discovery.yaml dan terapkan DaemonSet:
```
kubectl apply -f ebpf-discovery.yaml
```

Tunggu hingga Pod berjalan:

kubectl rollout status ds/bpftool-logger

Periksa log dari Pod untuk menemukan program eBPF:
```
kubectl logs -l app=bpftool-logger
```
Setelah selesai, hapus DaemonSet:
```
kubectl delete -f ebpf-discovery.yaml
```

Langkah berikutnya

Pelajari cara menggunakan logging kebijakan jaringan.
Pelajari cara mengontrol komunikasi antara Pod dan Service menggunakan kebijakan jaringan.
Pelajari lebih lanjut GKE Dataplane V2.
Pelajari lebih lanjut kemampuan observasi GKE Dataplane V2.
Pelajari cara mengonfigurasi kemampuan observasi GKE Dataplane V2.

Menggunakan GKE Dataplane V2 Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Sebelum memulai

Peran yang diperlukan

Membuat cluster GKE dengan GKE Dataplane V2

Konsol

gcloud

API

Memecahkan masalah pada GKE Dataplane V2

Masalah umum

Waktu tunggu koneksi habis untuk Pod yang belum siap

Pemfilteran Label yang Relevan dengan Identitas untuk Identitas Cilium tidak berlaku dan Pod macet dalam status ContainerCreating

Masalah konektivitas terputus-putus yang terkait dengan konflik rentang NodePort di cluster GKE Dataplane V2

Masalah konektivitas dengan hostPort di cluster GKE Dataplane V2

Rentang port untuk kebijakan jaringan tidak diterapkan

Versi tetap

Kebijakan Jaringan memutuskan koneksi karena pencarian pelacakan koneksi salah

Versi tetap

Solusi

Penurunan paket untuk alur koneksi hairpin

Versi tetap

Solusi

Upgrade bidang kontrol GKE menyebabkan kebuntuan Pod anetd

Penyebab

Gejala

Solusi

Node dalam status NodeNotReady karena error containerID yang tidak ada

Penyebab

Gejala

Solusi

Interferensi program eBPF kustom

Menemukan program eBPF kustom

Langkah berikutnya

Menggunakan GKE Dataplane V2

Masalah konektivitas terputus-putus yang terkait dengan konflik rentang `NodePort` di cluster GKE Dataplane V2

Masalah konektivitas dengan `hostPort` di cluster GKE Dataplane V2

Upgrade bidang kontrol GKE menyebabkan kebuntuan Pod `anetd`

Node dalam status `NodeNotReady` karena error `containerID` yang tidak ada