[บันทึกช่วยจำ] มาลอง Avi Kubernetes Operator (AKO) หรือ Ingress Controller จาก NSX ALB กันเถอะ

Kritsadanshon Sadeewong
7 min readJul 25, 2021

สารบัญ

หลังจากที่ได้ที่ได้เล่น vSphere with Tanzu เวอร์ชั่นล่าสุดบน vCenter และ vSphere 7.0 U2 แล้วที่รองรับ NSX ALB (Avi) แล้ว คราวนี้ก็มาถึงเรื่องหนึ่งนอกจากที่เราจะใช้ Service ที่เป็น LoadBalancer ยังมีอีก Service หนึ่งที่นิยมใช้งานกันนั้นก็คือ Service แบบ Ingress นั้นเอง ซึ่ง Service แบบ Ingress ก็มีมากมายให้เราเลือกใช้งานไม่ว่าจะเป็น NGINX Ingress Controller ที่ดูแลโดย Google, NGINX Ingress Controller for Kubernetes ที่ดูแลโดย NGINX Inc. เอง หรือจะเป็นอีกตัวที่นิยมกันที่ชื่อ Traefik Kubernetes Ingress แต่คราวนี้บน Tanzu เราใช้ Avi มาจัดการในเรื่อง LoadBalancer แล้วก็มาลองใช้งานฟังก์ Ingress Controller จากทาง Avi ดูกันดีกว่าจะเป็นอย่างไรบ้าง โดยฟังก์ชั่นนี้จะมีชื่อว่า Avi Kubernetes Operator หรือชื่อย่อเป็น AKO นั้นเอง

Avi Kubernetes Operator (AKO) คือ Service ตัวหนึ่งที่จะทำงานเป็น Ingress Controller และ หน้าสื่อสารไปยัง Avi Controller ผ่าน API เพื่อที่จะทำการ Config ค่าต่างๆ ลงไปที่ Avi Service Engines (SE) โดยที่จะถูก Deploy ติดตั้งลงไปบน Kubernetes Cluster ที่เราใช้งานอยู่ โดยในบนความนี้จะใช้เป็น Tanzu Kubernetes Cluster (TKC) ที่อยู่บน vSphere โดยสามารถดูได้จากบทความ [บันทึกช่วยจำ] ลองเล่น VMware vSphere with Tanzu + NSX ALB (Avi) ก่อนหน้าได้เลย

แต่เราจะมี Config เพิ่มเติมไปอีกนิดหน่อยเพื่อให้ได้ฟังก์ชั่นที่สามารถทำงานได้สมบูรณ์มากขึ้น โดนในส่วนนี้จะเป็นเรื่อง DNS นั้นเอง หากเราสั่งเกตุอยู่ทุกครั้งเวลาเราใช้งาน Service แบบ Ingress ซึ่งหนึ่งทุกครั้งที่ต้องทำเพิ่มหลังจากที่เราได้ Deploy Application ไปแล้วนั้นก็คือการจด DNS Record บน DNS ใน Envoriment ของเราเองเพื่อให้สามารถเรียกใช้งานได้ แต่จะดีกว่าไหมถ้าระบบทำการจด DNS Recordให้อัตโนมัติตามที่ Operator หรือ Developer มีการ Deploy Application ลงไปให้เอง เรามาดูในการ Config เพื่อเตรียมในส่วนนี้กันเถอะ

ตั้งค่าที่เกี่ยว DNS Service

ในส่วนจะเป็นการตั้งค่าเพื่อให้ระบบรองรับในการจัดการเกี่ยวกับ DNS Record เวลาที่มีการสร้าง Service Ingress ขึ้นมา

ขั้นตอนที่ 1 — ทำเรา Login เข้าไปหน้าเว็บ Avi Controller แล้วไปที่เมนู Administration -> Setting ->DNS Service

ขั้นตอนที่ 2— แล้วทำการคลิ้กไปที่เครื่องหมายชี้ลง (1) แล้วเลือก Create Vitual Service (2)

ขั้นตอนที่ 3— ทำการตั้งค่าในส่วนนี้ตามค่าดังต่อไปนี้

  • Name = dns-vs
  • Network for VIP Address Allocation = DPortGroup-172.17.37.x
  • IPv4 Subnet = 172.17.37.0/24
  • Application Domain Name = dns-vs.lab.local

ขั้นตอนที่ 4— ต่อมาเป็นส่วนของ Advanced ให้ตั้งค่าในส่วนของ

  • SE Group = Default-Group

แล้วทำการกด Save เพื่อบันทึก

ขั้นตอนที่ 5 — ในส่วนนี้หากเราไปที่เมนู Applications -> Virtual Services เราจะพบ dns-vs จากที่เราสร้างขึ้นมา และจะแสดง IP Adress สำหรับ Service นี้ด้วย

ขั้นตอนที่ 6 — ต่อมาเราจะไปตั้งค่าที่ฝั่ง DNS Server โดยเราได้ใช้เป็น DNS Server จาก Windows Server โดยไปที่ DNS Manager แล้วไปที่ domain ที่เราใช้งาน เราจะทำการเพิ่ม DNS Record ให้กับ dns-sv ที่เราได้สร้างบน Avi Controller ก่อน โดยการคลิ้กขวาที่ Domain แล้วเลือก New Host (A or AAAA)

ขั้นตอนที่ 7— ใส่ข้อมูลดังต่อไปนี้

  • Name = avi-dns
  • IP Address = 172.17.37.105

** IP Address จาก Virtual Service ที่เราได้สร้าง dns-sv ขึ้นมา

เมื่อใส่ข้อมูลครบแล้วให้กด Add Host

ขั้นตอนที่ 8— จากนั้นให้คลิ้กขวาที่ Domain ที่เราใช้งานแล้วเลือกไปที่ New Delegation

ขั้นตอนที่ 9 — คลิ้ก Next

ขั้นตอนที่ 10 — ใส่ข้อมูลสำหรับ Delegted Domain แล้วกด Next

  • Delegted Domain = tanzu

ขั้นตอนที่ 11 — ทำการคลิ้กปุ่ม Add

ขั้นตอนที่ 12 — ใส่ข้อมูล DNS Record ขอ dns-sv ที่ได้สร้างไปในขั้นตอนที่ 6 และ 7 แล้วทำคลิ้กปุ่ม OK

ขั้นตอนที่ 13 — คลิ้ก Next

ขั้นตอนที่ 14 — คลิ้ก Finish เป็นอันเสร็จสิ้น

ตั้งค่า Service Engine Group สำหรับ AKO

ต่อมาจะเป็นเตรียม Service Engine Group สำหรับใช้งาน AKO ในส่วนนี้สำคัญมากต้องมีสร้างแยกจาก Default-Group

ขั้นตอนที่ 1— กลับมา Avi Controller ให้ไปที่เมนู Infrastructure -> Service Engine Group คลิ้กไปที่ CREATE

ขั้นตอนที่ 2 — ทำการตั้งชื่อให้กับ Service Engine Group ที่จะสร้าง แล้วกด Save

  • SEG-AKO

ขั้นตอนที่ 3 — หน้าจอจะสร้างรายการ Service Engine Group ที่เราได้สร้างขึ้นมา

ตั้งค่าเพิ่มเติมสำหรับ Clouds

ต่อมาจะเป็นการตั้งค่าให้ระบบรองรับในการเพิ่ม Static Routes เวลาที่มีการติดตั้ง AKO ลงไปใน Tanzu Kubenetes Cluster

ขั้นตอนที่ 1 — ไปที่เมนู Ingrastructure -> Clouds ให้คลิ้กที่เครื่องหมายรูปดินสอหลัง Default-Cloud ที่เราได้ตั้งค่าไปในบทความก่อนหน้านี้

ขั้นตอนที่ 2— ให้มา Tab Data Center แล้วทำการ Check Box ให้ส่วนของ
Prefer Static Routes vs Directly Connected Network และ Use Static Routes for Network Resolution of VIP แล้วทำการกด Save

ติดตั้ง AKO ลงบน Tanzu Kevernetes Cluster

ในการติดตั้ง AKO เราจะทำการติดตั้งผ่าน Helm โดยทาง VMware ได้จัดเตรียมไว้หมดแล้วเราเพียงแค่โหลดไฟล์ value.yaml มาแก้ไขค่าต่างๆ ก่อนติดตั้งเท่านั้น

** เครื่องที่จะว่าใช้ Remote เพื่อไว้ใช้งาน Deploy ต่างๆ ตั้งติดตั้ง Helm และเครื่องมือที่จำเป็นไว้หมด รวมทั้งการใช้งาน Tanzu Kubernetes Cluster ในบทความนี้จะไม่ขอพูดถึงในส่วนนั้นแล้ว

ขั้นตอนที่ 1 — Download ไฟล์ values.yaml ได้จาก values.yaml

$ wget https://github.com/avinetworks/avi-helm-charts/blob/master/charts/stable/ako/values.yaml

ขั้นตอนที่ 2 — ทำการแก้ไขไฟล์ values.yaml ตามใน Envoriment ที่เราใช้งาน

ตัวอย่าง

ขั้นตอนที่ 3 — สร้าง Namesapce ชื่อ avi-system และตรวจสอบ Namesace ที่ได้สร้าง

$ kubectl create ns avi-system$ kubectl get ns

ขั้นตอนที่ 4 — เพิ่ม repository สำหรับติดตั้ง AKO และตรวจสอบ repository

$ helm repo add ako https://projects.registry.vmware.com/chartrepo/ako$ helm search repo | grep ako$ helm repo list

ขั้นตอนที่ 5 — ติดตั้ง AKO ผ่าน Helm

** ก่อนเริ่มการติดตั้งต้องจัดการสิทธิ์ RoleBinding ด้วย

$ helm install ako/ako --generate-name --version 1.3.1 -f values.yaml --namespace=avi-system

ขั้นตอนที่ 6 — ตรวจสอบสถานะการติดตั้ง

$ kubectl get all -n avi-system$ kubectl get event --sort-by=.metadata.creationTimestamp -n avi-system$ kubectl logs -f pod/ako-0 -n avi-system

ขั้นตอนที่ 7 — หากติดตั้งเรียบร้อยกลับไปตรวจสอบที่ Avi Controller ไปที่เมนู Infrastructure -> Routing เราจะพบว่ามีรายการ Static Route เพิ่มเข้ามาเอง

ทดลอง Deploy Application

ต่อมาเราจะมาติดตั้ง Application ง่ายๆ ที่ใช้งาน Service เป็น Ingress กัน

ขั้นตอนที่ 1 — เรียมจากเตรียม YAML file กันก่อน

ขั้นตอนที่ 2 — ทดลอง Deploy Appplication

$ kubectl apply -f tz-nginx-ingress.yaml

ขั้นตอนที่ 3 — ตรวจสอบ pod, deployment, service และ ingress ดูซิ

$ kubectl get all,ingressNAME                          READY   STATUS    RESTARTS   AGE
pod/nginx-f77dcc66b-8ksc5 1/1 Running 0 30m
pod/nginx-f77dcc66b-fjw2t 1/1 Running 0 30m
pod/nginx-f77dcc66b-slxqb 1/1 Running 0 30m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/nginx ClusterIP 198.48.131.214 <none> 80/TCP 53m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 3/3 3 3 53m
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-f77dcc66b 3 3 3 48m
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.extensions/demo-ingress <none> ingress.tanzu.lab.local 172.17.37.106 80 53m

ขั้นตอนที่ 4— ดูรายละเอียดของ ingress และที่ Avi Controller

$ kubectl describe ingressName:             demo-ingress
Namespace: default
Address: 172.17.37.106
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
ingress.tanzu.lab.local
/nginx nginx:80 192.0.1.31:80,192.0.2.32:80,192.0.3.32:80)
Annotations: kubernetes.io/ingress.class: avi
Events: <none>

บน Avi Controller มีข้อมูล Service ที่ได้สร้างขึ้นมา

ขั้นตอนที่ 5— ลองเรียก Application ตามที่ rule ที่ได้กำหนดทั้งแบบชื่อ FQDN และ IP Address เพื่อดูผล

จะเห็นได้ว่าเราสามารถเรียก FQDN ที่เรากำหนดได้เลยไม่ต้องรอให้ Operator ทำการเพิ่ม DNS Record เลยตัวระบบจะจัดการในส่วนนี้ให้เลย

ขั้นตอนที่ 6 — ลองทดสอบการทำงาน LoadBalance

ทำไม Hostname ของ Application แสดงแค่ชื่อด้วยเหมือน LoadBalance จะเตะไปเครื่องเดียวตลอดลองตรวจสอบที่ Avi Controller แล้วพบว่า LoadBalance Algorithm เป็น Last Connections นี้เองแล้วทำยังไงถึงจะให้ Operator หรือ Developer เปลี่ยนได้เองละ ???

ขั้นตอนที่ 7— หลังจากหาข้อมูลเพิ่มก็พบว่า Avi สามารถกำหนด LoadBalance Algorithm ผ่าน Resource Type ประเภท HTTPRule ได้ โดยดูตัวอย่างได้ดังนี้

หลังจาก Apply เข้าไปดูซิบน Avi Controller เปลี่ยนตามที่กำหนดไหม

$ kubectl apply -f HTTPrule.yaml

ดูผลลัพธ์ที่ได้บน Avi Controller

และทดสอบการทำงาน LoadBalance อีกครั้ง

ในส่วนของ LoadBalance Algorithm สามารถกำหนดได้ตามรายการดังต่อไปนี้

  • LB_ALGORITHM_CONSISTENT_HASH
  • LB_ALGORITHM_CORE_AFFINITY
  • LB_ALGORITHM_FASTEST_RESPONSE
  • LB_ALGORITHM_FEWEST_SERVERS
  • LB_ALGORITHM_FEWEST_TASKS
  • LB_ALGORITHM_LEAST_CONNECTIONS
  • LB_ALGORITHM_LEAST_LOAD
  • LB_ALGORITHM_NEAREST_SERVER
  • LB_ALGORITHM_RANDOM
  • LB_ALGORITHM_ROUND_ROBIN
  • LB_ALGORITHM_TOPOLOGY

** บ้าง Algorithm จะต้องมีการกำหนดค่าอื่นๆ เพิ่มเติมด้วย

ขั้นตอนที่ 8— มาลองเพิ่มอีกสัก Service ดูว่าจะเป็นยังไง

$ kubectl apply -f tz-nginx-ingress.yaml

ขั้นตอนที่ 9— ตรวจสอบ pod, deployment, service และ ingress ดูซิ

$ kubectl get all,ingressNAME                          READY   STATUS    RESTARTS   AGE
pod/google-6d95cc4774-lg6cm 1/1 Running 0 3m1s
pod/google-6d95cc4774-pl7q2 1/1 Running 0 3m1s
pod/google-6d95cc4774-w7b45 1/1 Running 0 3m1s
pod/nginx-f77dcc66b-fxnt7 1/1 Running 0 20m
pod/nginx-f77dcc66b-j49jq 1/1 Running 0 20m
pod/nginx-f77dcc66b-l4z56 1/1 Running 0 20m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/google ClusterIP 198.59.218.73 <none> 80/TCP 3m2s
service/nginx ClusterIP 198.63.200.59 <none> 80/TCP 20m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/google 3/3 3 3 3m2s
deployment.apps/nginx 3/3 3 3 20m
NAME DESIRED CURRENT READY AGE
replicaset.apps/google-6d95cc4774 3 3 3 3m1s
replicaset.apps/nginx-f77dcc66b 3 3 3 20m
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.extensions/ingress-3 <none> ingress.tanzu.lab.local 172.17.37.106 80 19m

ขั้นตอนที่ 10 — ดูรายละเอียดของ ingress และที่ Avi Controller

$ kubectl describe ingressName:             ingress-3
Namespace: ingress-3
Address: 172.17.37.106
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
ingress.tanzu.lab.local
/nginx nginx:80 192.0.1.31:80,192.0.2.32:80,192.0.3.32:80)
/google google:80 192.0.1.32:80,192.0.2.33:80,192.0.3.33:80)
Annotations: kubernetes.io/ingress.class: avi
Events: <none>

บน Avi Controller มีข้อมูล Service ที่เพิ่มเข้ามา

ขั้นตอนที่ 11 — ลองเรียก pplication ทั้งแบบชื่อ FQDN และ IP Address เพื่อดูผล

เพียงที่เท่านี้เราก็ได้ Ingress Controller ที่ไว้ใช้งานอีกตัวแล้ว และที่สะดวกขึ้นมาก็จะเปลี่ยน Operator ไม่ต้องมาค่อยเพิ่ม DNS Record เวลาที่มีการ Deploy Application ใหม่ด้วย

และเช่นเดิมบทความนี้เป็นเพียงแค่การ Config เบื้องต้น ยังไม่เหมาะกับนำไปใช้งานบน Production ควรจะต้องศึกษาเพิ่มเติมในอีกหลายๆ ส่วน

สุดท้ายแล้วหากท่านไหนหลงเข้ามาอ่านแล้วเห็นเป็นประโยชน์ก็สามารถนำไปต่อยอดได้เลย หรือหากมีคำแนะนำดีๆ ก็สามารถบอกกล่าวให้ทราบได้เช่นกันครับ

.

Ref: https://avinetworks.com/docs/ako/1.3/ako-installation/

Ref: https://avinetworks.com/docs/ako/1.4/custom-resource-definitions/

Ref: https://avinetworks.com/docs/18.1/load-balancing-algorithms/

Ref: https://rts.se/vsphere-with-tanzu-supervisor-and-tkg-tanzu-kubernetes-grid/

Ref: https://docs.vmware.com/en/VMware-Tanzu/services/tanzu-adv-deploy-config/GUID-avi-ako-tkg.html

Ref: https://yallavirtual.com/2020/11/23/tanzu-kubernetes-cluster-ingress-with-nsx-alb/

.

--

--

Kritsadanshon Sadeewong

นายช่างระบบระบบคอมพิวเตอร์ ที่ชอบทดลอง และเรียนรู้สิ่งใหม่ไปเรื่อยๆ