Container Service for Kubernetes：FAQ Layanan

Tujuan spesifik instance SLB dalam kluster ACK

Jika Anda menginstal komponen Nginx Ingress saat membuat kluster Kubernetes, kluster tersebut membuat dua instance SLB secara default.

Kedua instance SLB tersebut memiliki tujuan sebagai berikut:

• SLB API Server: Instance SLB ini merupakan titik akhir akses untuk API Server. Semua permintaan akses ke kluster harus melewati instance SLB ini. Instance ini mendengarkan pada port TCP 6443. Server backend-nya adalah pod API Server atau instance ECS master.

• SLB Nginx Ingress Controller: Instance SLB ini dikaitkan dengan layanan nginx-ingress-controller di namespace kube-system. Kelompok vServer secara dinamis mengikat pod Nginx Ingress Controller untuk melakukan load balancing dan meneruskan permintaan eksternal. Instance ini mendengarkan pada port 80 dan 443 melalui TCP.

Cara memilih antara kebijakan lalu lintas eksternal Local dan Cluster saat membuat layanan

Kebijakan lalu lintas eksternal Local dan Cluster menyediakan fitur berbeda untuk plug-in jaringan yang berbeda. Untuk informasi selengkapnya tentang perbedaan antara kebijakan lalu lintas eksternal Local dan Cluster, lihat Kebijakan lalu lintas eksternal.

Mengapa peristiwa untuk proses sinkronisasi layanan dan LoadBalancer tidak terlihat?

Jika tidak ada informasi peristiwa yang ditampilkan setelah Anda menjalankan perintah kubectl -n {your-namespace} describe svc {your-svc-name}, periksa versi komponen CCM Anda.

• Versi sebelum v1.9.3.276-g372aa98-aliyun: Komponen CCM tidak menampilkan peristiwa untuk sinkronisasi layanan dan LoadBalancer. Tingkatkan komponen tersebut. Untuk informasi selengkapnya tentang cara melihat dan meningkatkan versi CCM, lihat Tingkatkan komponen CCM.

• Untuk versi v1.9.3.276-g372aa98-aliyun dan yang lebih baru, Anda dapat mengajukan tiket.

Apa yang harus dilakukan jika instance SLB tetap berada dalam status Pending selama pembuatan

1. Jalankan perintah kubectl -n {your-namespace} describe svc {your-svc-name} untuk melihat informasi peristiwa.

2. Selesaikan kesalahan yang dilaporkan dalam peristiwa tersebut. Untuk informasi tentang cara menangani berbagai pesan kesalahan dalam peristiwa, lihat Peristiwa kesalahan dan solusinya.

   Jika tidak ada pesan kesalahan yang ditampilkan, lihat Mengapa peristiwa untuk proses sinkronisasi layanan dan LoadBalancer tidak terlihat?.

Apa yang harus dilakukan jika kelompok vServer SLB tidak diperbarui

1. Jalankan perintah kubectl -n {your-namespace} describe svc {your-svc-name} untuk melihat informasi peristiwa.

2. Selesaikan kesalahan yang dilaporkan dalam peristiwa tersebut. Untuk informasi tentang cara menangani berbagai pesan kesalahan dalam peristiwa, lihat Peristiwa kesalahan dan solusinya.

   Jika tidak ada pesan kesalahan yang ditampilkan, lihat Mengapa peristiwa untuk proses sinkronisasi layanan dan LoadBalancer tidak terlihat?.

Apa yang harus dilakukan jika anotasi layanan tidak berlaku

1. Periksa pesan kesalahan.

   1. Jalankan perintah kubectl -n {your-namespace} describe svc {your-svc-name} untuk melihat informasi peristiwa.

   2. Selesaikan kesalahan yang dilaporkan dalam peristiwa tersebut. Untuk informasi tentang cara menangani berbagai pesan kesalahan dalam peristiwa, lihat Peristiwa kesalahan dan solusinya.

2. Jika tidak ada pesan kesalahan yang ditampilkan, selesaikan masalah berdasarkan salah satu skenario berikut:

   • Pastikan versi CCM Anda memenuhi persyaratan versi untuk anotasi tersebut. Untuk informasi selengkapnya tentang pemetaan antara anotasi dan versi CCM, lihat Gunakan anotasi untuk mengonfigurasi instance Classic Load Balancer (CLB).

   • Masuk ke Konsol Manajemen Container Service. Pada halaman Services, klik nama layanan target dan pastikan bahwa Layanan memiliki anotasi yang sesuai. Jika Layanan tidak memiliki anotasi, konfigurasikan anotasi tersebut.

     Untuk informasi selengkapnya tentang cara menambahkan anotasi, lihat Gunakan anotasi untuk mengonfigurasi instance Classic Load Balancer (CLB).

     Untuk informasi selengkapnya tentang cara melihat daftar layanan, lihat Kelola layanan.

   • Periksa apakah anotasi dikonfigurasi dengan benar.

Mengapa konfigurasi instance SLB saya dimodifikasi?

CCM menggunakan API deklaratif dan secara otomatis memperbarui konfigurasi SLB berdasarkan konfigurasi layanan dalam kondisi tertentu. Setiap konfigurasi yang Anda modifikasi di konsol SLB berisiko ditimpa. Kami menyarankan agar Anda mengonfigurasi instance SLB menggunakan anotasi. Untuk informasi selengkapnya tentang cara menggunakan anotasi, lihat Gunakan anotasi untuk mengonfigurasi instance Classic Load Balancer (CLB).

Mengapa alamat IP SLB tidak dapat diakses dari dalam kluster?

• Skenario 1: Jika Anda menggunakan alamat IP pribadi untuk instance SLB yang tidak dibuat oleh layanan, akses dari dalam kluster mungkin gagal. Kegagalan ini terjadi jika pod yang mengakses instance SLB berada di node yang sama dengan pod backend.

  Untuk layanan load balancing lapisan 4, instance ECS tidak dapat bertindak sebagai server backend sekaligus klien yang mengakses layanan. Untuk mengatasi masalah ini dan mencegah klien dan tujuan berada di node yang sama, gunakan salah satu metode berikut.

  • Ubah alamat IP SLB menjadi alamat IP publik.

  • Buat instance SLB menggunakan layanan dan atur kebijakan lalu lintas eksternal ke Cluster. Dalam kasus ini, kube-proxy mencegat lalu lintas yang dikirim ke instance SLB dari dalam kluster, sehingga menghindari batasan SLB.

• Skenario 2: Anda mengatur kebijakan lalu lintas eksternal ke Local saat mengekspos layanan. Hal ini menyebabkan akses ke alamat IP SLB dari dalam kluster gagal.

  Untuk informasi selengkapnya tentang penyebab dan solusi masalah ini, lihat Bagaimana cara mengatasi masalah di mana alamat SLB yang diekspos oleh layanan LoadBalancer tidak dapat diakses dari dalam kluster Kubernetes?.

Bagaimana cara mengatasi masalah di mana alamat SLB yang diekspos oleh layanan LoadBalancer tidak dapat diakses dari dalam kluster Kubernetes?

Kapan instance SLB dihapus secara otomatis?

Apakah menghapus layanan juga menghapus instance SLB?

Jika Anda menggunakan kembali instance SLB yang ada (layanan memiliki anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id}), menghapus layanan tidak akan menghapus instance SLB. Jika tidak, menghapus layanan juga akan menghapus instance SLB yang sesuai.

Jika Anda mengubah tipe layanan (misalnya, dari LoadBalancer ke NodePort), instance SLB yang sesuai yang dibuat otomatis oleh CCM juga akan dihapus.

Apa yang harus dilakukan jika saya tidak sengaja menghapus instance SLB

• Skenario 1: Apa yang harus dilakukan jika Anda tidak sengaja menghapus instance SLB API Server

  Instance tersebut tidak dapat dipulihkan. Anda harus membuat ulang kluster. Untuk informasi selengkapnya, lihat Buat kluster ACK Pro.

• Skenario 2: Apa yang harus dilakukan jika Anda tidak sengaja menghapus instance SLB Ingress

  Langkah-langkah berikut menggunakan Nginx Ingress sebagai contoh untuk menunjukkan cara membuat ulang instance SLB.

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

  2. Pada halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Network > Services.

  3. Di bagian atas halaman Service, pilih kube-system dari daftar drop-down Namespace.

     1. Dalam daftar layanan, temukan layanan target nginx-ingress-lb, klik YAML Edit di kolom Actions, hapus bidang status.loadBalancer dan isinya, lalu klik OK untuk memicu CCM membuat ulang SLB.

     2. Jika nginx-ingress-lb tidak muncul dalam daftar layanan, klik Create From YAML di pojok kiri atas halaman dan gunakan templat berikut untuk membuat Layanan bernama nginx-ingress-lb.

        apiVersion: v1
        kind: Service
        metadata:
          labels:
            app: nginx-ingress-lb
          name: nginx-ingress-lb
          namespace: kube-system
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: 80
          - name: https
            port: 443
            protocol: TCP
            targetPort: 443
          selector:
            app: ingress-nginx
          type: LoadBalancer

• Skenario 3: Apa yang harus dilakukan jika Anda tidak sengaja menghapus instance SLB khusus aplikasi

  • Jika layanan yang sesuai dengan instance SLB tidak lagi diperlukan, hapus layanan tersebut.

  • Jika layanan yang sesuai masih digunakan, lakukan langkah-langkah berikut:

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

    2. Pada halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Network > Services.

    3. Dari daftar drop-down Namespace di bagian atas halaman Service, klik All Namespaces, lalu temukan layanan Anda dalam daftar layanan.

    4. Di kolom YAML Edit untuk layanan target, klik YAML Edit, hapus konten status, dan klik Update untuk memungkinkan CCM membuat ulang SLB.

Cara mengaktifkan penggantian nama SLB untuk versi CCM yang lebih lama

1. Masuk ke node master kluster Kubernetes. Untuk informasi selengkapnya, lihat Hubungkan ke kluster ACK menggunakan kubectl.

2. Jalankan perintah kubectl get svc -n ${namespace} ${service} untuk melihat tipe layanan dan alamat IP.

   Catatan

   Ganti namespace dan service dengan namespace dan nama layanan kluster Anda.

3. Jalankan perintah berikut untuk menghasilkan tag yang diperlukan untuk instance SLB.

   kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'

   

4. Masuk ke konsol Server Load Balancer. Berdasarkan alamat IP yang diambil pada Langkah 2, cari instance SLB di wilayah yang sesuai.

5. Tambahkan tag ke instance SLB menggunakan kunci dan nilai yang dihasilkan pada Langkah 3. Kunci dan nilai tersebut sesuai dengan 1 dan 2 pada gambar di atas. Untuk informasi selengkapnya, lihat Buat dan kelola instance CLB.

Bagaimana bobot node diatur secara otomatis dalam mode Local?

Bagian ini menggunakan skenario di mana pod aplikasi (app=nginx) diterapkan pada tiga instance ECS dan diekspos melalui Layanan A untuk menjelaskan cara menghitung bobot node dalam mode Local.

Cara mengkueri alamat IP, nama, dan jenis semua instance SLB dalam kluster?

1. Hubungkan ke kluster ACK menggunakan kubectl.

2. Jalankan perintah berikut untuk mengambil nama, alamat IP, dan tipe alamat setiap layanan LoadBalancer di semua namespace.

   kubectl get services -A -ojson | jq '.items[] | select(.spec.type == "LoadBalancer") | {name: .metadata.name, namespace: .metadata.namespace, ip: .status.loadBalancer.ingress[0].ip, lb_type: .metadata.annotations."service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type"}'

   Output yang diharapkan adalah sebagai berikut:

   {
     "name": "test",
     "namespace": "default",
     "ip": "192.168.*.*",
     "lb_type": "intranet"
   }
   {
     "name": "nginx-ingress-lb",
     "namespace": "kube-system",
     "ip": "47.97.*.*",
     "lb_type": "null"
   }

Bagaimana cara memastikan bahwa LoadBalancer dapat menutup koneksi yang ada secara elegan saat server backend layanan LoadBalancer diganti?

Anda dapat mengonfigurasi pengurasan koneksi menggunakan anotasi service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain dan service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout. Setelah server backend dihapus dari layanan, LoadBalancer terus memproses koneksi yang ada dalam periode drain-timeout. Untuk informasi selengkapnya, lihat Aktifkan pengurasan koneksi untuk pendengar.

Mengapa penggunaan kembali instance SLB yang ada gagal?

• Periksa versi CCM. Versi CCM sebelum v1.9.3.105-gfd4e547-aliyun tidak mendukung penggunaan kembali instance SLB. Untuk informasi selengkapnya tentang cara melihat dan meningkatkan versi CCM, lihat Tingkatkan komponen CCM.

• Periksa apakah instance SLB yang ingin Anda gunakan kembali dibuat oleh kluster. Anda tidak dapat menggunakan kembali instance SLB yang dibuat oleh kluster.

• Periksa apakah instance SLB tersebut adalah instance SLB untuk API Server. Anda tidak dapat menggunakan kembali instance SLB untuk API Server.

• Jika Anda ingin menggunakan kembali instance SLB akses internal, pastikan bahwa instance SLB dan kluster berada dalam VPC yang sama. Anda tidak dapat menggunakan kembali instance SLB lintas VPC.

Mengapa pendengar tidak dikonfigurasi saat saya menggunakan kembali instance SLB yang ada?

Apa yang harus dilakukan jika peningkatan CCM gagal

Untuk informasi selengkapnya tentang cara mengatasi kegagalan peningkatan komponen CCM, lihat Pemeriksaan peningkatan Cloud Controller Manager (CCM) gagal.

Pesan kesalahan layanan dan solusinya

Cara mengonfigurasi pendengar untuk layanan NodePort

CCM hanya mendukung konfigurasi pendengar untuk layanan LoadBalancer. Anda perlu mengubah tipe layanan dari NodePort menjadi LoadBalancer.

Cara mengakses layanan NodePort

• Untuk mengakses Layanan dari dalam kluster (pada node kluster), Anda dapat menggunakan ClusterIP + Port atau IP Node + NodePort Layanan. Nomor port default yang diekspos oleh Layanan NodePort lebih besar dari 30000.

• Untuk mengakses Layanan dari luar kluster (di luar node kluster), Anda dapat menggunakan alamat IP node dan NodePort Layanan. Nomor port default yang diekspos oleh Layanan NodePort lebih besar dari 30000.

• Untuk mengakses layanan dari luar VPC (dari VPC lain atau Internet), Anda perlu mengekspos layanan LoadBalancer lalu mengakses layanan melalui titik akhir eksternalnya.

  Catatan

  Jika Anda mengatur kebijakan lalu lintas eksternal layanan Anda ke Local, pastikan bahwa node yang Anda akses meng-host pod backend layanan tersebut. Untuk informasi selengkapnya tentang kebijakan lalu lintas eksternal, lihat Kebijakan lalu lintas eksternal.

Cara mengonfigurasi rentang NodePort dengan benar

Di Kubernetes, API Server menyediakan parameter ServiceNodePortRange ( --service-node-port-range parameter baris perintah). Parameter ini membatasi rentang NodePort yang dapat didengarkan oleh layanan NodePort atau LoadBalancer. Nilai defaultnya adalah 30000 hingga 32767. Di kluster ACK Pro, Anda dapat memodifikasi rentang port ini dengan menyesuaikan parameter lapisan kontrol. Untuk informasi selengkapnya, lihat Sesuaikan parameter lapisan kontrol untuk kluster ACK Pro.

• Anda harus sangat berhati-hati saat memodifikasi rentang NodePort. Pastikan bahwa rentang NodePort tidak bertentangan dengan rentang port yang ditentukan oleh parameter kernel net.ipv4.ip_local_port_range pada node kluster. Parameter kernel ip_local_port_range mengontrol rentang nomor port lokal yang dapat digunakan oleh aplikasi apa pun di sistem Linux. Nilai default ip_local_port_range adalah 32768 hingga 60999.

• Dengan konfigurasi default kluster ACK Anda, parameter ServiceNodePortRange dan parameter ip_local_port_range tidak bertentangan. Jika Anda sebelumnya telah menyesuaikan salah satu parameter ini untuk meningkatkan batas port, sehingga rentangnya tumpang tindih, pengecualian jaringan sporadis dapat terjadi pada node. Dalam kasus parah, hal ini dapat menyebabkan kegagalan pemeriksaan kesehatan bisnis dan node kluster offline. Kami menyarankan agar Anda mengembalikan nilai default atau menyesuaikan kedua rentang port tersebut agar tidak tumpang tindih sama sekali.

• Setelah Anda menyesuaikan rentang port, beberapa layanan NodePort atau LoadBalancer di kluster mungkin masih menggunakan port dalam rentang parameter ip_local_port_range sebagai NodePort. Anda perlu mengonfigurasi ulang layanan ini untuk menghindari konflik. Anda dapat menjalankan perintah kubectl edit <service-name> untuk langsung mengubah nilai bidang spec.ports.nodePort menjadi NodePort yang tidak digunakan.

Cara menambahkan izin yang diperlukan saat Anda meningkatkan komponen CCM ke versi yang lebih baru di kluster khusus ACK

Untuk meningkatkan kinerja, versi CCM yang lebih baru secara bertahap memperkenalkan API Alibaba Cloud yang memerlukan izin RAM tambahan (misalnya, v2.11.2 untuk manajemen rute di jaringan Flannel dan v2.12.1 untuk manajemen batch NLB).

Oleh karena itu, jika Anda ingin meningkatkan komponen ke v2.11.2 atau yang lebih baru di kluster khusus ACK, Anda harus memberikan izin yang diperlukan ke peran RAM-nya sebelum peningkatan untuk memastikan komponen berfungsi sebagaimana mestinya.

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

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

3. Klik tab Basic Information. Di area Cluster Resources, klik nama peran untuk Master RAM Role.

4. Pada halaman detail peran di konsol Resource Access Management, klik Permission Management, temukan kebijakan kustom yang namanya dimulai dengan k8sMasterRolePolicy-Ccm- dalam daftar kebijakan, lalu klik nama kebijakan tersebut untuk membuka halaman manajemen kebijakan akses.

   Untuk kluster yang dibuat pada waktu yang lebih awal, kebijakan tersebut mungkin tidak ada. Anda dapat memilih kebijakan kustom yang namanya dimulai dengan k8sMasterRolePolicy-.

5. Klik Edit Policy dan tambahkan izin nlb:ListAsynJobs ke izin NLB.

   

Jika Anda menggunakan kluster Flannel, Anda juga harus menambahkan izin vpc:CreateRouteEntries dan vpc:DeleteRouteEntries ke izin terkait VPC.

Setelah Anda menambahkan izin, kirimkan kebijakan tersebut sesuai petunjuk di halaman. Setelah perubahan disimpan, Anda dapat meningkatkan komponen CCM.