Container Service for Kubernetes：FAQ jaringan kontainer

Indeks

Apa saja mode jaringan utama Terway?

Terway memiliki dua mode jaringan utama: mode elastic network interface (ENI) bersama dan mode ENI eksklusif. Untuk informasi lebih lanjut tentang masing-masing mode, lihat Mode ENI bersama dan mode ENI eksklusif. Perhatikan bahwa hanya mode ENI bersama Terway yang mendukung akselerasi jaringan (DataPathv2 atau IPvlan+eBPF). DataPathv2 merupakan versi peningkatan dari mode akselerasi IPvlan+eBPF. Di Terway v1.8.0 dan yang lebih baru, DataPathv2 adalah satu-satunya opsi akselerasi yang tersedia saat membuat kluster dan menginstal plugin Terway.

Bagaimana cara mengetahui apakah Terway berada dalam mode ENI eksklusif atau mode ENI bersama?

• Di Terway v1.11.0 dan yang lebih baru, Terway menggunakan mode ENI bersama secara default. Anda dapat mengaktifkan mode ENI eksklusif dengan mengonfigurasi mode jaringan ENI eksklusif untuk kelompok node.

• Di versi sebelum Terway v1.11.0, Anda dapat memilih mode ENI eksklusif atau bersama saat membuat kluster. Setelah kluster dibuat, Anda dapat mengidentifikasi mode tersebut sebagai berikut:

  • Mode ENI eksklusif: Nama DaemonSet Terway di namespace kube-system adalah terway-eni.

  • Mode ENI bersama: Nama DaemonSet Terway di namespace kube-system adalah terway-eniip.

Bagaimana cara mengetahui apakah akselerasi jaringan Terway menggunakan DataPathv2 atau IPvlan+eBPF?

Hanya mode ENI bersama Terway yang mendukung akselerasi jaringan (DataPathv2 atau IPvlan+eBPF). DataPathv2 merupakan versi peningkatan dari mode akselerasi IPvlan+eBPF. Di Terway v1.8.0 dan yang lebih baru, DataPathv2 adalah satu-satunya opsi akselerasi yang tersedia saat membuat kluster dan menginstal plugin Terway.

Anda dapat memeriksa konfigurasi eniip_virtual_type di ConfigMap eni-config di namespace kube-system untuk menentukan apakah akselerasi jaringan diaktifkan. Nilainya adalah datapathv2 atau ipvlan.

Apakah routing dalam mode Terway DataPathv2 atau IPvlan+eBPF melewati IPVS?

Saat Anda mengaktifkan mode akselerasi (DataPathv2 atau IPvlan+eBPF) untuk Terway, ia menggunakan jalur penerusan lalu lintas yang berbeda dari mode ENI bersama biasa. Dalam skenario tertentu, seperti pod mengakses Service internal, lalu lintas dapat melewati tumpukan protokol jaringan node dan tidak perlu melewati rute IPVS node. Sebagai gantinya, eBPF menyelesaikan alamat Service ke alamat pod backend. Untuk informasi lebih lanjut tentang alur lalu lintas, lihat Akselerasi jaringan.

Dapatkah saya mengganti plugin jaringan untuk kluster ACK yang sudah ada?

Anda hanya dapat memilih plugin jaringan (Terway atau Flannel) saat membuat kluster. Plugin jaringan tidak dapat diubah setelah kluster dibuat. Untuk menggunakan plugin jaringan yang berbeda, Anda harus membuat kluster baru. Untuk informasi lebih lanjut, lihat Buat kluster ACK yang dikelola.

Apa yang harus saya lakukan jika kluster tidak dapat mengakses Internet setelah saya menambahkan vSwitch dalam mode jaringan Terway?

Gejala

Anda menambahkan vSwitch secara manual karena pod kehabisan sumber daya IP. Setelah menambahkan vSwitch, Anda menemukan bahwa kluster tidak dapat mengakses Internet.

Penyebab

vSwitch yang menyediakan alamat IP untuk pod tidak memiliki akses Internet.

Solusi

Anda dapat menggunakan fitur SNAT Gateway NAT untuk mengonfigurasi aturan SNAT untuk vSwitch yang menyediakan alamat IP untuk pod. Untuk informasi lebih lanjut, lihat Aktifkan akses Internet untuk kluster.

Setelah memperbarui versi citra Flannel secara manual, bagaimana cara mengatasi ketidakcocokan dengan kluster versi 1.16 atau yang lebih baru?

Gejala

Setelah memperbarui kluster ke versi 1.16, node kluster masuk ke status NotReady.

Penyebab

Masalah ini terjadi karena Anda memperbarui versi Flannel secara manual tetapi tidak memperbarui konfigurasi Flannel. Akibatnya, kubelet tidak dapat mengenali konfigurasi baru.

Solusi

1. Edit konfigurasi Flannel untuk menambahkan bidang cniVersion.

   kubectl edit cm kube-flannel-cfg -n kube-system 

   Tambahkan bidang cniVersion ke konfigurasi.

   "name": "cb0",   
   "cniVersion":"0.3.0",
   "type": "flannel",

2. Mulai ulang Flannel.

   kubectl delete pod -n kube-system -l app=flannel

Bagaimana cara mengatasi masalah latensi setelah pod dimulai?

Gejala

Setelah pod dimulai, terjadi penundaan sebelum jaringan tersedia.

Penyebab

Kebijakan Jaringan yang dikonfigurasi dapat menyebabkan latensi. Menonaktifkan Kebijakan Jaringan dapat mengatasi masalah ini.

Solusi

1. Modifikasi ConfigMap Terway untuk menambahkan konfigurasi yang menonaktifkan NetworkPolicy.

   kubectl edit cm -n kube-system eni-config 

   Tambahkan bidang berikut ke konfigurasi.

   disable_network_policy: "true"

2. Opsional:Jika Anda tidak menggunakan versi Terway terbaru, tingkatkan versinya di konsol.

   1. Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.

   2. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel sebelah kiri, pilih Operations > Add-ons.

   3. Di halaman Add-ons, klik tab Networking, lalu klik Upgrade untuk komponen Terway.

   4. Di kotak dialog yang muncul, ikuti petunjuk untuk menyelesaikan konfigurasi dan klik OK.

3. Mulai ulang semua pod Terway.

    kubectl delete pod -n kube-system -l app=terway-eniip

Bagaimana cara mengizinkan pod mengakses layanan yang di-expose-nya sendiri?

Gejala

Pod tidak dapat mengakses layanan yang di-expose-nya sendiri. Akses bersifat intermiten atau gagal saat pod dijadwalkan ke dirinya sendiri.

Penyebab

Solusi

• Gunakan Layanan Headless untuk mengekspos dan mengakses layanan. Untuk informasi lebih lanjut, lihat Layanan Headless.

  Catatan

  Ini adalah metode yang direkomendasikan.

• Buat ulang kluster dan gunakan plugin jaringan Terway. Untuk informasi lebih lanjut, lihat Gunakan plugin jaringan Terway.

• Modifikasi konfigurasi Flannel, lalu buat ulang plugin Flannel dan pod.

  Catatan

  Metode ini tidak direkomendasikan karena konfigurasi dapat ditimpa oleh peningkatan berikutnya.

  1. Edit cni-config.json.

     kubectl edit cm kube-flannel-cfg -n kube-system

  2. Dalam konfigurasi, tambahkan hairpinMode: true ke bagian delegate.

     Contoh:

     cni-conf.json: |
         {
           "name": "cb0",
           "cniVersion":"0.3.1",
           "type": "flannel",
           "delegate": {
             "isDefaultGateway": true,
             "hairpinMode": true
           }
         }

  3. Mulai ulang Flannel.

     kubectl delete pod -n kube-system -l app=flannel   

  4. Hapus dan buat ulang pod.

Bagaimana cara memilih antara plugin jaringan Terway dan Flannel untuk kluster Kubernetes?

Bagian ini menjelaskan dua plugin jaringan, Terway dan Flannel, yang tersedia saat Anda membuat kluster ACK.

Bagaimana cara merencanakan jaringan kluster?

Saat membuat kluster ACK, Anda perlu menentukan VPC, vSwitch, blok CIDR jaringan Pod, dan blok CIDR Service. Kami merekomendasikan Anda merencanakan alamat instance ECS, alamat pod Kubernetes, dan alamat Service terlebih dahulu. Untuk informasi lebih lanjut, lihat Rencanakan jaringan untuk kluster ACK yang dikelola.

Apakah ACK mendukung pemetaan hostPort?

• Hanya plugin Flannel yang mendukung hostPort. Plugin lain tidak mendukung fitur ini.

• Alamat pod di ACK dapat diakses langsung oleh sumber daya lain dalam VPC yang sama tanpa memerlukan pemetaan port tambahan.

• Untuk mengekspos layanan ke jaringan eksternal, gunakan Service tipe NodePort atau LoadBalancer.

Bagaimana cara melihat jenis jaringan kluster dan vSwitch yang sesuai?

ACK mendukung dua jenis jaringan kontainer: Flannel dan Terway.

• Untuk melihat jenis jaringan yang Anda pilih saat membuat kluster, lakukan langkah-langkah berikut:

  1. Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.

  2. Di halaman Clusters, temukan kluster target dan klik namanya. Di panel navigasi sebelah kiri, klik Cluster Information.

  3. Klik tab Basic Information. Di bagian Network, lihat jenis jaringan kontainer kluster, yaitu nilai di sebelah Network Plugin.

     • Jika Network Plugin diatur ke Terway, jenis jaringan kontainer adalah Terway.

     • Jika Network Plugin diatur ke Flannel, jenis jaringan kontainer adalah Flannel.

• Untuk melihat vSwitch node yang digunakan oleh jenis jaringan, lakukan langkah-langkah berikut:

  1. Di panel navigasi sebelah kiri, pilih Node Management > Node Pools.

  2. Di halaman Node Pools, temukan kelompok node target dan klik Details di kolom Actions. Lalu, klik tab Basic Information.

     Di bagian Node Configurations, lihat ID Node VSwitch.

• Untuk menanyakan ID vSwitch pod yang digunakan oleh jenis jaringan Terway, lakukan langkah-langkah berikut:

  Catatan

  Hanya jenis jaringan Terway yang menggunakan vSwitch pod. Jenis jaringan Flannel tidak menggunakannya.

  1. Di panel navigasi sebelah kiri, klik Add-ons.

  2. Di halaman Add-on, klik View Configurations di kartu terway-eniip. Opsi PodVswitchId menunjukkan vSwitch pod yang sedang digunakan.

Bagaimana cara melihat sumber daya cloud yang digunakan dalam kluster?

Bagaimana cara memodifikasi konfigurasi kube-proxy?

Secara default, kluster ACK yang dikelola menyebarkan DaemonSet kube-proxy-worker untuk load balancing. Anda dapat mengontrol parameternya menggunakan ConfigMap kube-proxy-worker. Jika Anda menggunakan kluster khusus ACK, DaemonSet kube-proxy-master dan ConfigMap yang sesuai juga diterapkan di kluster Anda dan berjalan di node master.

Konfigurasi kube-proxy kompatibel dengan standar KubeProxyConfiguration komunitas. Anda dapat menyesuaikan konfigurasi berdasarkan standar ini. Untuk informasi lebih lanjut, lihat Konfigurasi kube-proxy. Berkas konfigurasi kube-proxy memiliki persyaratan format yang ketat. Jangan menghilangkan titik dua atau spasi. Untuk memodifikasi konfigurasi kube-proxy, lakukan langkah-langkah berikut:

• Jika Anda menggunakan kluster yang dikelola, Anda harus memodifikasi konfigurasi kube-proxy-worker.

  1. Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.

  2. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel sebelah kiri, pilih Configurations > ConfigMaps.

  3. Di bagian atas halaman, pilih namespace kube-system. Lalu, temukan ConfigMap kube-proxy-worker dan klik Edit YAML di kolom Tindakan.

  4. Di panel Edit YAML, modifikasi parameter dan klik OK.

  5. Buat ulang semua kontainer kube-proxy-worker agar konfigurasi berlaku.

     Penting

     Memulai ulang kube-proxy tidak mengganggu layanan yang sedang berjalan. Jika layanan sedang dirilis secara bersamaan, layanan baru mungkin memerlukan waktu sedikit lebih lama untuk berlaku di kube-proxy. Kami merekomendasikan Anda melakukan operasi ini di luar jam sibuk.

     1. Di panel navigasi sebelah kiri halaman manajemen kluster, pilih Workloads > DaemonSets.

     2. Dalam daftar DaemonSet, temukan dan klik kube-proxy-worker.

     3. Di halaman kube-proxy-worker, di tab Pods, pilih More > Delete lalu klik OK.

        Ulangi operasi ini untuk menghapus semua pod. Sistem akan secara otomatis membuat ulang pod setelah dihapus.

• Jika Anda menggunakan kluster khusus, Anda harus memodifikasi konfigurasi kube-proxy-worker dan kube-proxy-master. Lalu, hapus pod kube-proxy-worker dan kube-proxy-master. Pod akan dibuat ulang secara otomatis, dan konfigurasi baru akan berlaku. Untuk informasi lebih lanjut, lihat langkah-langkah sebelumnya.

Bagaimana cara meningkatkan batas pelacakan koneksi Linux (conntrack)?

Bagaimana cara mengubah mode load balancing IPVS di kube-proxy?

Bagaimana cara mengubah waktu timeout persistensi sesi UDP IPVS di kube-proxy?

Jika kluster ACK Anda menggunakan kube-proxy dalam mode IPVS, kebijakan persistensi sesi IPVS default dapat menyebabkan kehilangan paket probabilistik untuk backend UDP hingga lima menit setelah dihapus. Jika layanan Anda bergantung pada CoreDNS, Anda mungkin mengalami latensi antarmuka bisnis, timeout permintaan, dan masalah lainnya hingga lima menit saat komponen CoreDNS ditingkatkan atau nodenya dimulai ulang.

Bagaimana cara mengatasi masalah umum dengan dual-stack IPv6?

• Symptom: Alamat IP pod yang ditampilkan di kubectl masih berupa alamat IPv4.

  Solution: Jalankan perintah berikut untuk menampilkan bidang Pod IPs. Output yang diharapkan adalah alamat IPv6.

  kubectl get pods -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.status.podIPs[*].ip} {"\n"}{end}'

• Symptom: IP Cluster yang ditampilkan di kubectl masih berupa alamat IPv4.

  Solution:

  1. Pastikan bahwa spec.ipFamilyPolicy tidak diatur ke SingleStack.

  2. Jalankan perintah berikut untuk menampilkan bidang Cluster IPs. Output yang diharapkan adalah alamat IPv6.

     kubectl get svc -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.spec.ipFamilyPolicy} {@.spec.clusterIPs[*]} {"\n"}{end}'

• Symptom: Tidak dapat mengakses pod menggunakan alamat IPv6-nya.

  Cause: Beberapa aplikasi, seperti kontainer Nginx, tidak mendengarkan alamat IPv6 secara default.

  Solution: Jalankan perintah netstat -anp untuk memastikan bahwa pod mendengarkan alamat IPv6.

  Output yang diharapkan:

  Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
  tcp        0      0 127.0.XX.XX:10248         0.0.0.0:*               LISTEN      8196/kubelet
  tcp        0      0 127.0.XX.XX:41935         0.0.0.0:*               LISTEN      8196/kubelet
  tcp        0      0 0.0.XX.XX:111             0.0.0.0:*               LISTEN      598/rpcbind
  tcp        0      0 0.0.XX.XX:22              0.0.0.0:*               LISTEN      3577/sshd
  tcp6       0      0 :::30500                :::*                    LISTEN      1916680/kube-proxy
  tcp6       0      0 :::10250                :::*                    LISTEN      8196/kubelet
  tcp6       0      0 :::31183                :::*                    LISTEN      1916680/kube-proxy
  tcp6       0      0 :::10255                :::*                    LISTEN      8196/kubelet
  tcp6       0      0 :::111                  :::*                    LISTEN      598/rpcbind
  tcp6       0      0 :::10256                :::*                    LISTEN      1916680/kube-proxy
  tcp6       0      0 :::31641                :::*                    LISTEN      1916680/kube-proxy
  udp        0      0 0.0.0.0:68              0.0.0.0:*                           4892/dhclient
  udp        0      0 0.0.0.0:111             0.0.0.0:*                           598/rpcbind
  udp        0      0 47.100.XX.XX:323           0.0.0.0:*                           6750/chronyd
  udp        0      0 0.0.0.0:720             0.0.0.0:*                           598/rpcbind
  udp6       0      0 :::111                  :::*                                598/rpcbind
  udp6       0      0 ::1:323                 :::*                                6750/chronyd
  udp6       0      0 fe80::216:XXXX:fe03:546 :::*                                6673/dhclient
  udp6       0      0 :::720                  :::*                                598/rpcbind

  Jika Proto adalah tcp, artinya layanan mendengarkan alamat IPv4. Jika tcp6, artinya layanan mendengarkan alamat IPv6.

• Symptom: Anda dapat mengakses pod dalam kluster menggunakan alamat IPv6-nya, tetapi tidak dapat mengaksesnya dari Internet.

  Cause: Bandwidth Internet mungkin belum dikonfigurasi untuk alamat IPv6.

  Solution: Konfigurasikan bandwidth Internet untuk alamat IPv6. Untuk informasi lebih lanjut, lihat Aktifkan dan kelola bandwidth Internet IPv6.

• Symptom: Tidak dapat mengakses pod menggunakan IP Cluster IPv6-nya.

  Solution:

  1. Pastikan bahwa spec.ipFamilyPolicy tidak diatur ke SingleStack.

  2. Jalankan perintah netstat -anp untuk memastikan bahwa pod mendengarkan alamat IPv6.

     Output yang diharapkan:

     Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
     tcp        0      0 127.0.XX.XX:10248         0.0.0.0:*               LISTEN      8196/kubelet
     tcp        0      0 127.0.XX.XX:41935         0.0.0.0:*               LISTEN      8196/kubelet
     tcp        0      0 0.0.XX.XX:111             0.0.0.0:*               LISTEN      598/rpcbind
     tcp        0      0 0.0.XX.XX:22              0.0.0.0:*               LISTEN      3577/sshd
     tcp6       0      0 :::30500                :::*                    LISTEN      1916680/kube-proxy
     tcp6       0      0 :::10250                :::*                    LISTEN      8196/kubelet
     tcp6       0      0 :::31183                :::*                    LISTEN      1916680/kube-proxy
     tcp6       0      0 :::10255                :::*                    LISTEN      8196/kubelet
     tcp6       0      0 :::111                  :::*                    LISTEN      598/rpcbind
     tcp6       0      0 :::10256                :::*                    LISTEN      1916680/kube-proxy
     tcp6       0      0 :::31641                :::*                    LISTEN      1916680/kube-proxy
     udp        0      0 0.0.0.0:68              0.0.0.0:*                           4892/dhclient
     udp        0      0 0.0.0.0:111             0.0.0.0:*                           598/rpcbind
     udp        0      0 47.100.XX.XX:323           0.0.0.0:*                           6750/chronyd
     udp        0      0 0.0.0.0:720             0.0.0.0:*                           598/rpcbind
     udp6       0      0 :::111                  :::*                                598/rpcbind
     udp6       0      0 ::1:323                 :::*                                6750/chronyd
     udp6       0      0 fe80::216:XXXX:fe03:546 :::*                                6673/dhclient
     udp6       0      0 :::720                  :::*                                598/rpcbind

     Jika Proto adalah tcp, artinya layanan mendengarkan alamat IPv4. Jika tcp6, artinya layanan mendengarkan alamat IPv6.

  3. Symptom: Pod tidak dapat mengakses Internet menggunakan IPv6.

     Solution: Untuk menggunakan IPv6 untuk akses Internet, Anda perlu mengaktifkan gateway IPv6 dan mengonfigurasi bandwidth Internet untuk alamat IPv6. Untuk informasi lebih lanjut, lihat Buat dan kelola gateway IPv6 dan Aktifkan dan kelola bandwidth Internet IPv6.

Apa yang harus saya lakukan jika vSwitch kehabisan sumber daya IP dalam mode jaringan Terway?

Deskripsi

Saat Anda mencoba membuat pod, pembuatan gagal. Masuk ke Konsol VPC, pilih Wilayah target, dan lihat informasi vSwitch yang digunakan oleh kluster. Anda menemukan bahwa Jumlah Alamat IP Tersedia vSwitch adalah 0. Untuk informasi lebih lanjut tentang cara mengonfirmasi masalah ini, lihat Informasi lebih lanjut.

Penyebab

vSwitch yang digunakan oleh Terway di node tidak memiliki alamat IP yang tersedia. Hal ini menyebabkan pod tetap dalam status ContainerCreating karena kekurangan sumber daya IP.

Solusi

Informasi lebih lanjut

kubectl get pod -l app=terway-eniip -n kube-system | grep [$Node_Name] # [$Node_Name] adalah nama node tempat pod berada. Gunakan untuk menemukan nama pod Terway di node tersebut.
kubectl logs --tail=100 -f [$Pod_Name] -n kube-system -c terway # [$Pod_Name] adalah nama pod Terway di node tempat pod berada.

time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

Apa yang harus saya lakukan jika pod dalam mode jaringan Terway diberi alamat IP yang tidak berada dalam blok CIDR vSwitch?

Gejala

Dalam jaringan Terway, pod yang dibuat diberi alamat IP yang tidak berada dalam blok CIDR vSwitch yang dikonfigurasi.

Penyebab

Alamat IP pod berasal dari VPC dan ditugaskan ke kontainer menggunakan ENI. Anda hanya dapat mengonfigurasi vSwitch saat membuat ENI baru. Jika ENI sudah ada, alamat IP pod terus dialokasikan dari vSwitch yang sesuai dengan ENI tersebut.

Masalah ini biasanya terjadi dalam dua skenario berikut:

• Anda menambahkan node ke kluster, tetapi node ini sebelumnya digunakan di kluster lain dan pod-nya tidak dikosongkan saat node dihapus. Dalam kasus ini, sumber daya ENI dari kluster sebelumnya mungkin masih ada di node.

• Anda menambahkan atau memodifikasi konfigurasi vSwitch yang digunakan oleh Terway secara manual. Karena ENI dengan konfigurasi asli mungkin masih ada di node, pod baru mungkin terus menggunakan alamat IP dari ENI asli.

Solusi

Anda dapat memastikan bahwa berkas konfigurasi berlaku dengan membuat node baru dan memutar node lama.

Untuk memutar node lama, lakukan langkah-langkah berikut:

1. Kosongkan dan hapus node lama. Untuk informasi lebih lanjut, lihat Hapus node.

2. Putuskan ENI dari node yang dihapus. Untuk informasi lebih lanjut, lihat Kelola ENI.

3. Setelah ENI diputus, tambahkan kembali node yang dihapus ke kluster ACK asli. Untuk informasi lebih lanjut, lihat Tambahkan node yang ada.

Apa yang harus saya lakukan jika pod masih tidak dapat diberi alamat IP setelah saya memperluas vSwitch dalam mode jaringan Terway?

Gejala

Dalam jaringan Terway, pod masih tidak dapat diberi alamat IP setelah vSwitch diperluas.

Penyebab

Alamat IP pod berasal dari VPC dan ditugaskan ke kontainer menggunakan ENI. Anda hanya dapat mengonfigurasi vSwitch saat membuat ENI baru. Jika ENI sudah ada, alamat IP pod terus dialokasikan dari vSwitch yang sesuai dengan ENI tersebut. Karena kuota ENI di node telah habis, tidak ada ENI baru yang dapat dibuat, sehingga konfigurasi baru tidak dapat berlaku. Untuk informasi lebih lanjut tentang kuota ENI, lihat Ikhtisar ENI.

Solusi

Anda dapat memastikan bahwa berkas konfigurasi berlaku dengan membuat node baru dan memutar node lama.

Untuk memutar node lama, lakukan langkah-langkah berikut:

1. Kosongkan dan hapus node lama. Untuk informasi lebih lanjut, lihat Hapus node.

2. Putuskan ENI dari node yang dihapus. Untuk informasi lebih lanjut, lihat Kelola ENI.

3. Setelah ENI diputus, tambahkan kembali node yang dihapus ke kluster ACK asli. Untuk informasi lebih lanjut, lihat Tambahkan node yang ada.

Bagaimana cara mengaktifkan load balancing dalam kluster untuk kluster Terway IPvlan?

Gejala

Dalam mode IPvlan, untuk Terway v1.2.0 dan yang lebih baru, load balancing dalam kluster diaktifkan secara default untuk kluster baru. Saat Anda mengakses ExternalIP atau LoadBalancer dari dalam kluster, lalu lintas diseimbangkan ke jaringan Service. Bagaimana cara mengaktifkan load balancing dalam kluster untuk kluster Terway IPvlan yang sudah ada?

Penyebab

Kube-proxy mempersingkat lalu lintas ke ExternalIP dan LoadBalancer dari dalam kluster. Artinya, saat Anda mengakses alamat eksternal ini dari dalam kluster, lalu lintas sebenarnya tidak keluar tetapi dialihkan langsung ke Endpoints backend yang sesuai. Dalam mode Terway IPvlan, lalu lintas ke alamat ini ditangani oleh Cilium, bukan kube-proxy. Versi Terway sebelum v1.2.0 tidak mendukung pemersingkatan ini. Setelah rilis Terway v1.2.0, fitur ini diaktifkan secara default untuk kluster baru tetapi tidak untuk kluster yang sudah ada.

Solusi

1. Jalankan perintah berikut untuk memodifikasi ConfigMap Terway.

   kubectl edit cm eni-config -n kube-system

2. Tambahkan konten berikut ke eni_conf.

   in_cluster_loadbalance: "true"

   Catatan

   Pastikan bahwa in_cluster_loadbalance dan eni_conf berada di tingkat yang sama.

3. Jalankan perintah berikut untuk membuat ulang pod Terway agar konfigurasi load balancing dalam kluster berlaku.

   kubectl delete pod -n kube-system -l app=terway-eniip

   Verify The Configuration

   Jalankan perintah berikut untuk memeriksa log kebijakan terway-ennip. Jika menunjukkan enable-in-cluster-loadbalance=true, konfigurasi telah berlaku.

   kubectl logs -n kube-system <nama pod terway> policy | grep enable-in-cluster-loadbalance

Bagaimana cara menambahkan blok CIDR tertentu ke daftar putih untuk pod di kluster ACK yang menggunakan Terway?

Gejala

Anda sering perlu menyiapkan daftar putih untuk layanan seperti database untuk memberikan kontrol akses yang lebih aman. Persyaratan ini juga ada di jaringan kontainer, di mana Anda perlu menyiapkan daftar putih untuk alamat IP pod yang berubah secara dinamis.

Penyebab

Solusi

Dengan menambahkan label ke node tertentu, Anda dapat menentukan vSwitch yang digunakan oleh pod. Saat pod dijadwalkan ke node dengan label tetap, pod tersebut dapat membuat alamat IP podnya menggunakan vSwitch khusus.

1. Di namespace kube-system, buat ConfigMap terpisah bernama eni-config-fixed, yang menentukan vSwitch khusus.

   Contoh ini menggunakan vsw-2zem796p76viir02c**** dan 10.2.1.0/24.

   apiVersion: v1
   data:
     eni_conf: |
       {
          "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
          "security_group": "sg-bp19k3sj8dk3dcd7****",
          "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
       }
   kind: ConfigMap
   metadata:
     name: eni-config-fixed
     namespace: kube-system
   
                           

2. Buat kelompok node dan tambahkan label terway-config:eni-config-fixed ke node. Untuk informasi lebih lanjut tentang cara membuat kelompok node, lihat Buat kelompok node.

   Untuk memastikan tidak ada pod lain yang dijadwalkan ke node di kelompok node ini, Anda juga dapat mengonfigurasi taint untuk kelompok node, seperti fixed=true:NoSchedule.

3. Perluas kelompok node. Untuk informasi lebih lanjut, lihat Perluas kelompok node secara manual.

   Node yang diperluas dari kelompok node ini akan memiliki label node dan taint yang ditetapkan pada langkah sebelumnya secara default.

4. Buat pod dan jadwalkan ke node yang memiliki label terway-config:eni-config-fixed. Anda perlu menambahkan toleransi.

   apiVersion: apps/v1 # Untuk versi sebelum 1.8.0, gunakan apps/v1beta1.
   kind: Deployment
   metadata:
     name: nginx-fixed
     labels:
       app: nginx-fixed
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx-fixed
     template:
       metadata:
         labels:
           app: nginx-fixed
       spec:
         tolerations:        # Tambahkan toleransi.
         - key: "fixed"
           operator: "Equal"
           value: "true"
           effect: "NoSchedule"
         nodeSelector:
           terway-config: eni-config-fixed
         containers:
         - name: nginx
           image: nginx:1.9.0 # Ganti dengan citra aktual Anda <nama_citra:tag>.
           ports:
           - containerPort: 80

   Verify The Result

   1. Jalankan perintah berikut untuk melihat alamat IP pod.

      kubectl get po -o wide | grep fixed

      Output yang diharapkan:

      nginx-fixed-57d4c9bd97-l****                   1/1     Running             0          39s    10.2.1.124    bj-tw.062149.aliyun.com   <none>           <none>
      nginx-fixed-57d4c9bd97-t****                   1/1     Running             0          39s    10.2.1.125    bj-tw.062148.aliyun.com   <none>           <none>

      Anda dapat melihat bahwa alamat IP pod ditugaskan dari vSwitch yang ditentukan.

   2. Jalankan perintah berikut untuk memperluas pod menjadi 30 replika.

      kubectl scale deployment nginx-fixed --replicas=30

      Output yang diharapkan:

      nginx-fixed-57d4c9bd97-2****                   1/1     Running     0          60s     10.2.1.132    bj-tw.062148.aliyun.com   <none>           <none>
      nginx-fixed-57d4c9bd97-4****                   1/1     Running     0          60s     10.2.1.144    bj-tw.062149.aliyun.com   <none>           <none>
      nginx-fixed-57d4c9bd97-5****                   1/1     Running     0          60s     10.2.1.143    bj-tw.062148.aliyun.com   <none>           <none>
      ...

      Anda dapat melihat bahwa semua alamat IP pod yang dihasilkan berada dalam vSwitch yang ditentukan. Lalu, Anda dapat menambahkan vSwitch ini ke daftar putih database untuk mengontrol akses untuk alamat IP pod dinamis.

Mengapa pod tidak dapat melakukan ping ke beberapa node ECS?

Gejala

Dalam mode jaringan Flannel, Anda memeriksa bahwa rute VPN normal, tetapi saat Anda masuk ke pod, Anda menemukan bahwa beberapa node ECS tidak dapat diping.

Penyebab

Solusi

Mengapa node kluster memiliki taint NodeNetworkUnavailable?

Gejala

Dalam mode jaringan Flannel, node kluster yang baru ditambahkan memiliki taint NodeNetworkUnavailable, yang mencegah pod dijadwalkan.

Penyebab

Cloud Controller Manager (CCM) tidak segera menghapus taint node, kemungkinan karena tabel rute penuh atau adanya beberapa tabel rute di VPC.

Solusi

Gunakan perintah kubectl describe node untuk melihat informasi event node dan tangani kesalahan berdasarkan output aktual. Untuk masalah dengan beberapa tabel rute, Anda perlu mengonfigurasi CCM secara manual untuk mendukungnya. Untuk informasi lebih lanjut, lihat Gunakan beberapa tabel rute di VPC.

Mengapa pod gagal dimulai dan melaporkan kesalahan "no IP addresses available in range"?

Gejala

Dalam mode jaringan Flannel, pod gagal dimulai. Saat Anda memeriksa event pod, Anda melihat pesan kesalahan yang mirip dengan failed to allocate for range 0: no IP addresses available in range set: 172.30.34.129-172.30.34.190.

Penyebab

Solusi

• Untuk kebocoran alamat IP yang disebabkan oleh versi ACK lama, Anda dapat meningkatkan kluster Anda ke versi 1.20 atau yang lebih baru. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual.

• Untuk kebocoran alamat IP yang disebabkan oleh versi Flannel lama, Anda dapat meningkatkan Flannel ke v0.15.1.11-7e95fe23-aliyun atau yang lebih baru. Lakukan langkah-langkah berikut:

  Di Flannel v0.15.1.11-7e95fe23-aliyun dan yang lebih baru, ACK memindahkan database alokasi rentang IP default di Flannel ke direktori sementara /var/run. Direktori ini secara otomatis dihapus saat restart, mencegah kebocoran alamat IP.

  1. Perbarui Flannel ke 0.15.1.11-7e95fe23-aliyun atau yang lebih baru. Untuk informasi lebih lanjut, lihat Kelola komponen.

  2. Jalankan perintah berikut untuk mengedit berkas kube-flannel-cfg. Lalu, tambahkan parameter dataDir dan ipam ke berkas kube-flannel-cfg.

     kubectl -n kube-system edit cm kube-flannel-cfg

     Berikut adalah contoh berkas kube-flannel-cfg.

     # Sebelum modifikasi
         {
           "name": "cb0",
           "cniVersion":"0.3.1",
           "plugins": [
             {
               "type": "flannel",
               "delegate": {
                 "isDefaultGateway": true,
                 "hairpinMode": true
                }
             },
             # portmap # Mungkin tidak ada di versi lama. Abaikan jika tidak digunakan.
             {
               "type": "portmap",
               "capabilities": {
                 "portMappings": true
               },
               "externalSetMarkChain": "KUBE-MARK-MASQ"
             }
           ]
         }
     
     # Setelah modifikasi
         {
           "name": "cb0",
           "cniVersion":"0.3.1",
           "plugins": [
             {
               "type": "flannel",
               "delegate": {
                 "isDefaultGateway": true,
                 "hairpinMode": true
                },
               # Perhatikan koma.
               "dataDir": "/var/run/cni/flannel",
               "ipam": {
                 "type": "host-local",
                 "dataDir": "/var/run/cni/networks"
                }
             },
             {
               "type": "portmap",
               "capabilities": {
                 "portMappings": true
               },
               "externalSetMarkChain": "KUBE-MARK-MASQ"
             }
           ]
         }

  3. Jalankan perintah berikut untuk memulai ulang pod Flannel.

     Memulai ulang pod Flannel tidak memengaruhi layanan yang sedang berjalan.

     kubectl -n kube-system delete pod -l app=flannel

  4. Hapus direktori IP di node dan mulai ulang node.

     1. Kosongkan Pod yang ada di node. Untuk informasi lebih lanjut, lihat Mengosongkan node dan mengelola status penjadwalannya.

     2. Masuk ke node dan jalankan perintah berikut untuk menghapus direktori IP.

        rm -rf /etc/cni/
        rm -rf /var/lib/cni/

     3. Mulai ulang node. Untuk informasi lebih lanjut, lihat Mulai ulang instance.

     4. Ulangi langkah-langkah di atas untuk menghapus direktori IP di semua node.

  5. Jalankan perintah berikut di node untuk memverifikasi apakah direktori sementara diaktifkan.

     if [ -d /var/lib/cni/networks/cb0 ]; then echo "not using tmpfs"; fi
     if [ -d /var/run/cni/networks/cb0 ]; then echo "using tmpfs"; fi
     cat /etc/cni/net.d/10-flannel.conf*

     Jika using tmpfs dikembalikan, artinya node saat ini telah mengaktifkan direktori sementara /var/run untuk database alokasi rentang IP, dan perubahan berhasil.

• Jika Anda tidak dapat meningkatkan ACK atau Flannel dalam waktu dekat, Anda dapat menggunakan metode berikut untuk penanganan darurat sementara. Perbaikan sementara ini berlaku untuk kebocoran yang disebabkan oleh kedua alasan di atas.

  Perbaikan sementara ini hanya membantu Anda membersihkan alamat IP yang bocor. Kebocoran alamat IP mungkin masih terjadi, jadi Anda tetap perlu meningkatkan versi Flannel atau kluster.

  Catatan

  • Perintah berikut tidak berlaku untuk Flannel v0.15.1.11-7e95fe23-aliyun dan versi yang lebih baru yang telah beralih ke penggunaan /var/run untuk menyimpan informasi alokasi alamat IP.

  • Skrip berikut hanya sebagai referensi. Jika node telah dikustomisasi, skrip mungkin tidak berfungsi dengan benar.

  1. Atur node yang bermasalah menjadi tidak dapat dijadwalkan. Untuk informasi selengkapnya, lihat Mengosongkan node dan mengelola status penjadwalannya.

  2. Gunakan skrip berikut untuk membersihkan node berdasarkan mesin runtime.

     • Jika Anda menggunakan runtime Docker, gunakan skrip berikut untuk membersihkan node.

       #!/bin/bash
       cd /var/lib/cni/networks/cb0;
       docker ps -q > /tmp/running_container_ids
       find /var/lib/cni/networks/cb0 -regex ".*/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" -printf '%f\n' > /tmp/allocated_ips
       for ip in $(cat /tmp/allocated_ips); do
         cid=$(head -1 $ip | sed 's/\r#g' | cut -c-12)
         grep $cid /tmp/running_container_ids > /dev/null || (echo removing leaked ip $ip && rm $ip)
       done

     • Jika Anda menggunakan runtime containerd, gunakan skrip berikut untuk membersihkan node.

       #!/bin/bash
       # install jq
       yum install -y jq
       
       # export all running pod's configs
       crictl -r /run/containerd/containerd.sock pods -s ready -q | xargs -n1 crictl -r /run/containerd/containerd.sock inspectp > /tmp/flannel_ip_gc_all_pods
       
       # export and sort pod ip
       cat /tmp/flannel_ip_gc_all_pods | jq -r '.info.cniResult.Interfaces.eth0.IPConfigs[0].IP' | sort > /tmp/flannel_ip_gc_all_pods_ips
       
       # export flannel's all allocated pod ip
       ls -alh /var/lib/cni/networks/cb0/1* | cut -f7 -d"/" | sort > /tmp/flannel_ip_gc_all_allocated_pod_ips
       
       # print leaked pod ip
       comm -13 /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_allocated_pod_ips > /tmp/flannel_ip_gc_leaked_pod_ip
       
       # clean leaked pod ip
       echo "Found $(cat /tmp/flannel_ip_gc_leaked_pod_ip | wc -l) leaked Pod IP, press <Enter> to clean."
       read sure
       
       # delete leaked pod ip
       for pod_ip in $(cat /tmp/flannel_ip_gc_leaked_pod_ip); do
           rm /var/lib/cni/networks/cb0/${pod_ip}
       done
       
       echo "Leaked Pod IP cleaned, removing temp file."
       rm /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_pods /tmp/flannel_ip_gc_leaked_pod_ip /tmp/flannel_ip_gc_all_allocated_pod_ips

  3. Atur node yang bermasalah ke status dapat dijadwalkan. Untuk informasi lebih lanjut, lihat Mengosongkan node dan mengelola status penjadwalannya.

Bagaimana cara mengubah jumlah IP node, blok CIDR IP Pod, atau blok CIDR IP Service?

Jumlah IP node, blok CIDR IP Pod, dan blok CIDR IP Service tidak dapat diubah setelah kluster dibuat. Rencanakan segmen jaringan Anda secara wajar saat membuat kluster.

Dalam skenario apa saya perlu mengonfigurasi beberapa tabel rute untuk kluster?

Dalam mode jaringan Flannel, berikut adalah skenario umum di mana Anda perlu mengonfigurasi beberapa tabel rute untuk cloud-controller-manager. Untuk informasi lebih lanjut tentang cara mengonfigurasi beberapa tabel rute untuk kluster, lihat Gunakan beberapa tabel rute di VPC.

Apakah plugin jaringan pihak ketiga didukung?

Kluster ACK tidak mendukung instalasi dan konfigurasi plugin jaringan pihak ketiga. Menginstalnya dapat menyebabkan jaringan kluster menjadi tidak tersedia.

Mengapa alamat CIDR Pod tidak mencukupi, menyebabkan kesalahan no IP addresses available in range set?

Kesalahan ini terjadi karena kluster ACK Anda menggunakan plugin jaringan Flannel. Flannel menentukan blok CIDR jaringan Pod, yang menyediakan kumpulan alamat IP terbatas untuk setiap node guna ditugaskan ke pod. Rentang ini tidak dapat diubah. Setelah alamat IP dalam rentang habis, pod baru tidak dapat dibuat di node tersebut. Anda harus melepaskan beberapa alamat IP atau membuat ulang kluster. Untuk informasi lebih lanjut tentang cara merencanakan jaringan kluster, lihat Rencanakan jaringan untuk kluster ACK yang dikelola.

Berapa jumlah pod yang didukung dalam mode jaringan Terway?

Jumlah pod yang didukung oleh kluster dalam mode jaringan Terway adalah jumlah alamat IP yang didukung oleh instance ECS. Untuk informasi lebih lanjut, lihat Gunakan plugin jaringan Terway.

Mode bidang data Terway DataPath V2

• Mulai dari Terway v1.8.0, saat Anda membuat kluster baru dan memilih opsi IPvlan, mode DataPath V2 diaktifkan secara default. Untuk kluster yang sudah ada yang telah mengaktifkan fitur IPvlan, bidang data tetap menggunakan metode IPvlan asli.

• DataPath V2 adalah jalur bidang data generasi baru. Dibandingkan dengan mode IPvlan asli, mode DataPath V2 memiliki kompatibilitas yang lebih baik. Untuk informasi lebih lanjut, lihat Gunakan plugin jaringan Terway.

Bagaimana cara melihat siklus hidup pod jaringan Terway?

1. Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.

2. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel sebelah kiri, pilih Workloads > DaemonSets.

3. Di bagian atas halaman DaemonSets, klik dan pilih namespace kube-system.

4. Di halaman DaemonSets, cari terway-eniip dan klik terway-eniip di bawah daftar Name.

   Berikut menjelaskan status saat ini dari pod:

   Jenis	Deskripsi
   Ready	Semua kontainer di pod telah dimulai dan berjalan normal.
   Pending	Pod sedang menunggu Terway mengonfigurasi sumber daya jaringan untuknya. Pod belum dijadwalkan ke node karena sumber daya node tidak mencukupi. Untuk informasi lebih lanjut, lihat Pemecahan masalah pengecualian pod.
   ContainerCreating	Pod telah dijadwalkan ke node, menunjukkan bahwa pod sedang menunggu inisialisasi jaringan selesai.

   Untuk informasi lebih lanjut, lihat Siklus Hidup Pod.

FAQ tentang kegagalan peningkatan komponen Terway

Dalam mode jaringan Terway, pembuatan pod gagal dengan kesalahan "cannot find MAC address"

 failed to do add; error parse config, can't found dev by mac 00:16:3e:xx:xx:xx: not found

Apa yang perlu saya ketahui tentang mengonfigurasi domain kluster (ClusterDomain)?

ClusterDomain default untuk kluster ACK adalah cluster.local. Anda juga dapat menyesuaikan domain kluster saat membuat kluster. Perhatikan hal-hal berikut:

• Anda hanya dapat mengonfigurasi ClusterDomain saat membuat kluster. ClusterDomain tidak dapat dimodifikasi setelah kluster dibuat.

• ClusterDomain kluster adalah domain tingkat atas untuk domain Service dalam kluster. Ini adalah zona resolusi nama domain independen untuk layanan internal kluster. ClusterDomain tidak boleh tumpang tindih dengan zona DNS pribadi atau publik di luar kluster untuk menghindari konflik resolusi DNS.

  Cara kerjanya

  ACK menggunakan CoreDNS sebagai server DNS-nya secara default. Jika Anda menyesuaikan ClusterDomain, konfigurasi Corefile CoreDNS default adalah sebagai berikut.

    Corefile: |
      .:53 {
          errors
          log
          health {
             lameduck 15s
          }
          ready
          kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          ...
          forward . /etc/resolv.conf {
            prefer_udp
          }
          ...
        }

  Jika ClusterDomain tidak didefinisikan, konfigurasi Corefile yang sesuai mirip dengan berikut.

          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          ...
          forward . /etc/resolv.conf {
            prefer_udp
          }

  Saat CoreDNS menangani resolusi nama domain untuk ClusterDomain, secara default tidak meneruskan permintaan ini ke server DNS hulu. Artinya, tidak memicu fallthrough ke plugin forward. Perilaku ini memastikan bahwa kueri DNS dalam kluster efisien, aman, dan tidak terpengaruh oleh jaringan eksternal. Jika permintaan DNS dari dalam kluster salah diteruskan ke server DNS hulu, permintaan tersebut akan terus diteruskan ke hulu, membentuk permintaan rekursif. Karena jalur permintaan rekursif terlalu panjang, permintaan resolusi DNS melebihi waktu timeout yang dikonfigurasi, yang akhirnya menyebabkan kegagalan resolusi.

  Jika ClusterDomain yang disesuaikan tumpang tindih dengan domain tingkat atas publik di luar kluster atau domain tingkat atas yang didefinisikan di Cloud DNS PrivateZone, dan semua pod di kluster menggunakan CoreDNS sebagai server DNS-nya, CoreDNS tidak meneruskan permintaan resolusi untuk ClusterDomain ke server DNS hulu dan karenanya tidak dapat menyelesaikannya dengan benar.

  Selain itu, jika ClusterDomain tumpang tindih dengan domain tingkat atas publik di luar kluster atau domain tingkat atas yang didefinisikan di Cloud DNS PrivateZone, dan nama Service dalam kluster juga tumpang tindih dengan subdomain di bawah zona publik atau PrivateZone, CoreDNS memprioritaskan penyelesaian ke alamat IP Service internal daripada domain eksternal. Hal ini menyebabkan kesalahan akses.