AWS EKS Primer

What is Container?

จากการที่ Docker ได้ทำให้แนวคิดในการพัฒนา แอปพลิเคชั่นไปอย่างมาก การทำให้แอปพลิเคชั่น สามารถใช้งาน container ได้อย่างแพร่หลาย การ containerized ทำให้การพัฒนาแอปพลิเคชั่น ที่แตกย่อยออกเป็น Microservices ได้รับความสนใจมากขึ้นอย่างต่อเนื่อง การจัดการและควบคุมระบบที่ซับซ้อนมากขึ้นมีความจำเป็นขึ้นเป็นอย่างมาก ทั้งการจัดการ container และระบบแวดล้อม (server, networking, storage) ในระดับเบื้องต้น docker container/compose สามารถตอบโจทย์ของการทำแอปพลิเคชั่นที่ไม่ซับซ้อนได้ แต่หากต้องการการทำระบบที่ซับซ้อนมากขึ้นและสามารถรองรับการทำงานในระดับที่มีการเข้าถึงชุดข้อมูลหรือตัวโปรแกรมในระดับที่จำเป็นต้องจัดการกับความต้องการในระดับนั้นเป็นเรื่องที่ทำได้ไม่ง่ายนัก จึงจำเป็นอย่างยิ่งที่จะต้องมี ระบบจัดการและควบคุม (orchestration) ระบบดังกล่าวมีตัวเลือกให้เลือกใช้งานได้ตามลักษณะของความต้องการของระบบ อย่างเช่น docker swarm/AWS ECS/Google Containers/Azure Container Apps/Kubernetes ในบทความนี้จะเน้นไปที่ตัว Kubernetes ซึ่งมีความยืดหยุ่นสอดรับกับลักษณะงานได้หลากหลาย ตัว API ค่อนข้างเปิดกว้าง สามารถใช้งานได้แม้ไม่ใช่บน Public Cloud Provider (AWS/Azure/GCP) แต่เนื่องจากประสบการณ์ของผู้เขียนใช้งานกับทาง AWS เป็นหลักจึงจะขอยึดที่ EKS (Elastic Kubernetes Service) เป็นหลัก

Container Orchestration on AWS (ECS/EKS)

สำหรับการบริหารจัดการ container บน AWS นั้นหาก service ไม่ได้มีความสลับซับซ้อนจนเกินไป อยากแนะนำให้ลองใช้ ECS โดยการกำหนด Task/Service และกำหนดสเปคพื้นฐานก็จะสามารถใช้งานได้อย่างคร่าวๆได้แล้ว (หมายเหตุ AWS มี solution เช่น Elastic Beanstalk, App Runner ก็สามารถใช้เป็นทางลัดในการพัฒนาและสามารถใช้ container ได้เช่นกัน)

Kubernetes (K8s) เป็น Container Orchestration Project ที่ Google ได้บริจาคให้กับ Cloud Native Computing Foundation (CNCF) ซึ่งเป็นส่วนหนึ่งของ Linux Foundation (ดูแล Linux Project)
การทำงานของ Kubernetes เป็นการบริหารจัดการระบบ container ด้วย API โดยการทำงานของ Kubernetes cluster จะประกอบด้วยองค์ประกอบหลักๆดังนี้

1. api-server รับชุดคำสั่งของ API ผ่าน HTTP endpoint
2. kube-proxy เชื่อมต่อระหว่างชุดคำสั่งกับ worker node
3. kube-controller main loop ที่คอยจัดการกับชุดคำสั่งกับสถานะปัจจุบัน
4. kubelet computing resource ที่จัดการกับ container บนคอมพิวเตอร์ปลายทาง
5. kube-scheduler จัดการนำ workload ที่ได้รับคำสั่งไป deploy บน pod/node (kubelet) ปลายทาง

อ้างอิง: https://kubernetes.io/docs/concepts/overview/components/

AWS Networking (VPC, CIDR, Subnets)

VPC - Virtual Private Cloud สำหรับการสร้างโครงข่ายเสมือนแบบจำกัดการเข้าถึงโดยสาธารณะ กล่าวคือ การเข้าถึงจากสาธารณะสามารถทำได้หรือไม่ก็ขึ้นอยู่กับแบบร่างของโครงข่ายดังกล่าว แต่การบริหารจัดการนั้นเป็นแบบจำกัดสิทธิ์โดยผู้ใช้ AWS account นั้นๆ

CIDR - Classless Inter-Domain Routing จำเป็นสำหรับการสร้าง VPC เพื่อกำหนด IP address สำหรับ hosts/services ใน VPC
ข้อจำกัดของการใช้ CIDR ใน VPC สำหรับ Private IP address สำหรับโครงสร้างเครือข่ายขนาดใหญ่ https://aws.amazon.com/th/what-is/cidr/

Regions - สำหรับโครงข่ายในระดับโลก ของ AWS มีการแบ่งการเข้าถึงออกเป็นหลายระดับ ในระดับใหญ่สุดแบ่งจาก สถานที่บนโลกของประเทศต่างๆ เพื่อช่วยให้ความเร็วในการเข้าถึงโครงข่ายเป็นไปได้อย่างมีประสิทธิภาพสูงสุด อย่างเช่น หากการเชื่อมต่อจากประเทศไทย ไปยัง ยุโรป การเชื่อมต่อดังกล่าวจะต้องผ่านโครงข่ายข้ามประเทศหลายต่อ ซึ่งทำให้เกิดความล่าช้าที่ไม่สามารถหลีกเลี่ยงได้ กล่าวคือ หากผู้ใช้งานเชื่อมต่อกับระบบโครงสร้างที่ใกล้กว่าความเร็วของการเชื่อมต่อก็จะมีความเร็วในการเข้าใช้งานที่สูงกว่า อย่างเช่นหากระบบโครงข่ายตั้งบน สิงคโปร์แทนที่จะเป็นยุโรป ความเร็วในการเข้าถึงก็จะมากกว่าการเชื่อมต่อไปยังยุโรป
อนึ่ง ระบบโครงข่ายที่รองรับการเชื่อมต่อไปยังปลายทางเช่น CloudFront, Global Accelerator สามารถทำให้ความเร็วในการเชื่อมต่อดังกล่าวดีขึ้นได้ แต่ยังไงซะการตั้งระบบโครงสร้างเครือข่ายที่ใกล้กับฐานผู้ใช้งาน ก็จะดีกว่าในกรณีทั่วๆไป และรวมไปถึงหากมีการต้องเก็บข้อมูลที่จำเป็นต้องผ่านมาตรฐานการกำกับการเก็บข้อมูลเช่น PDPA, GDPR, HIPAA ก็จะเป็นส่วนหนึ่งในตัวแปรที่จำเป็นต้องคำนึงถึงก่อนวางโครงสร้างเครือข่าย

Availability Zones (AZ) - ในแต่ละ Region นั้นก็มีการแบ่ง data center ออกเป็นอย่างน้อย 3 ที่เพื่อการันตีว่า การให้บริการของ AWS จะไม่สะดุด เมื่อ data center หนึ่งล่มลง

Subnet - เพื่อรองรับการเชื่อมต่อไปยังแต่ละ AZ และควบคุมการเข้าถึงของ host ทั้งแบบเปิดสาธารณะ และแบบปิดการเข้าถึงแบบเป็นส่วนตัว

Security Groups + NACL

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

1. Security Group - สามารถระบุการเข้าถึงเครื่องคอมพิวเตอร์ได้แบบเป็นคู่ของ Address + Port โดยที่ Address สามารถที่จะเป็น
   • IPv4
   • IPv6
   • "Prefix-List" แบ่งย่อยได้เป็น AWS Managed กับ Customer Managed สำหรับ AWS Managed ใช้สำหรับการจัดการกับการเข้าถึงบริการของ AWS ที่อาจมีการเปลี่ยนแปลง IP Address จากภายนอกได้ ส่วน Customer Managed ไว้สำหรับการจัดการกับ IP Address ใน VPC ของผู้ใช้เองซึ่งอาจจะเป็นใน VPC ในบัญชีผู้ใช้ หรือ ภายในองค์กรเดียวกันของผู้ใช้ หรือแม้แต่ IP สาธารณะอื่นๆที่ต้องการจัดการก็สามารถทำได้

การใช้ Prefix-List จะทำให้การจัดการแบบรวมศูนย์ง่ายขึ้น อย่างเช่นการเปลี่ยนแปลงบนลิสต์จะสามารถส่งผ่านต่อไปได้โดยไม่ต้องแก้กลับไปยังปลายทาง อย่างเช่น หากมีการ shared service บน subnet เฉพาะ หาก service subnet มีการเปลี่ยนแปลง ปกติแล้วจะต้องแก้ที่ปลายทางทุกรายการ การใช้ Prefix-List จะทำให้การเปลี่ยนแปลงที่จุดตั้งต้นที่จุดเดียวก็สามารถนำไปปรับใช้ได้ทันที

• "Security Group Reference" เพื่อให้การอ้างอิงไปยัง Security Group อื่นๆ สามารถทำได้โดยง่าย อย่างเช่น ต้องการกำหนดให้สามารถรับได้เพียงจาก SGR เฉพาะเพียงอันเดียว ซึ่งแม้ว่าตัว networking ข้างล่างจะมีการเปลี่ยนแปลงไป แต่ความหมายในการระบุถึง Security Group นั้นก็จะยังคงอยู่ ทำให้การระบุต้นทาง/ปลายทาง มีความแน่นอน

Note: Security Group เป็น Stateful (หากมีการตอบรับ connection ไปแล้ว คู่ของ connection นั้นก็จะถูกตอบรับไปด้วยกัน) และ Security Group สามารถคอบรับได้อย่างเดียวไม่สามารถปฎิเสธการเข้าถึงได้จากกฎของ Security Group

1. Network Access Control List (NACL) เป็นการสร้างความปลอดภัยให้กับโครงข่ายในระดับ subnet สามารถตั้งให้ subnet ตอบรับหรือปฎิเสธ connection ได้ด้วย สำหรับ NACL สามารถกำหนด
   • Rule number
   • IP Address v4,v6 (CIDR)
   • Port number
   • Allow/Deny โดยปกติ ค่าเริ่มต้นของ NACL จะไม่ได้มีการบล็อค กล่าวคือ Allow all หรือปล่อยผ่านให้จัดการบน Security Group เพียงอย่างเดียว

Create EKS cluster

สำหรับบทความนี้เราจะทำการสร้าง EKS Cluster ผ่านหน้า eksctl หากไม่ถนัดสามารถใช้ AWS Management console แทนได้ options จะมีความคล้ายเคียงกัน

สำหรับการ install eksctl ให้อ้างอิงจาก https://eksctl.io/installation/ โดยให้เลือก ระบบปฎิบัติการให้เหมาะสมกับเครื่องคอมพิวเตอร์ของผู้ใช้งานเป็นหลัก

สำหรับการสร้าง cluster ใหม่
eksctl create cluster -n NAME -r REGION --with-oidc --without-nodegroup --vpc-nat-mode Disable --vpc-cidr "VPC-CIDR"

Note

• หากต้องการตรวจสอบความถูกต้องสามารถใส่ option --dry-run ลงไปในคำสั่งได้
• หากใช้ AWS CLI จำเป็นต้องมี programmable key/session ที่ใช้งานได้เพื่อให้ eksctl คุยกับ AWS API ได้ (สามารถสร้างชุดใหม่ได้จาก User โดยที่สิทธิ์ในการเข้าถึงของ Programmable Key จะเท่ากันกับ User ที่เป็นผู้ออกชุดกุญแจดังกล่าว)
• สามารถระบุ option --vpc-cidr เพื่อให้ cluster ที่สร้างใหม่แชร์ address space กับ vpc ได้โดยตรง ทำให้การบริหารจัดการจะขึ้นตรงกับการจัดการ VPC
• ในทางกลับกัน --vpc-private-subnets, --vpc-public-subnets เพื่อให้ cluster ระบุให้ cluster ใช้ subnet ที่ระบุไว้ใน VPC->Subnets private-subnets, public-subnets
• สำหรับการทดลองตามบทความนี้ขอแนะนำให้ใช้ --vpc-nat-mode Disable ควบคู่ไปด้วย เพราะว่า เราจะสร้างเพียง EKS Control Plane ซึ่งไม่จำเป็นต้องใช้ NAT Gateway ทั้งนี้เพื่อจะได้สะดวกในการทำลายภายหลังจากเราสามารถยืนยันได้ว่าการสร้าง Cluster ได้สำเร็จลงแล้ว
• การสร้าง EKS Cluster มีค่าใช้จ่าย ทางผู้เขียนไม่สามารถรับผิดชอบกับค่าใช้จ่ายที่อาจเกิดขึ้นได้ กรุณาตรวจสอบข้อมูลของการสร้าง ก่อนที่จะทำการสร้างจริงด้วย --dry-run

Access EKS endpoints (public)

สำหรับบทความนี้ เราจะเช็คว่ามีการสร้าง EKS Cluster ที่สามารถเข้าถึงได้ผ่าน public subnet เท่านั้น (สำหรับการเข้าถึงแบบ private จะมีความซับซ้อนมากขึ้นในการจัดการ network เพื่อความง่ายต่อการจัดการ จะกล่าวถึงในบทความถัดไปด้วยการใช้ IaC Terraform)

เมื่อสร้าง Cluster เสร็จจากขั้นตอนที่แล้ว สามารถเช็คจาก การเข้าถึง Cluster endpoint ที่ทาง AWS สร้างเป็น DNS record ไว้ให้ เนื่องจากเราเปิดการเข้าถึงแบบเป็น public ตัว endpoint ที่ถูกสร้างจะสามารถเข้าถึงได้จาก public Internet (ซึ่งโดยปกติไม่แนะนำ เนื่องจากมาตรฐานด้านความปลอดภัย) เราสามารถทำ nslookup ENDPOINT โดยที่ endpoint จะมีหน้าตาประมาณนี้ EKS-CLUSTER.REGION.eks.amazonaws.com

ตรวจสอบว่า endpoint สามารถเข้าถึงได้ผ่านพอร์ต 443 (https)
สามารถใช้ nslookup, dig เพื่อตรวจสอบว่า DNS record ที่ทาง AWS จัดเตรียมให้สามารถแปลงเป็น IP Address ที่ผู้ใช้สามารถเข้าถึงได้, curl เพื่อตรวจสอบว่า endpoint สามารถตอบกลับเป็น http message ของ api ได้ (การเข้าถึง api จำเป็นจะต้องใช้ key และมีการยืนยันสิทธิ์การเข้าถึงของผู้ใช้ก่อน) ซึ่งเพื่อให้การใช้งาน api มีความสะดวกมากขึ้นบน CLI จะขอแนะนำให้ใช้งาน kubectl

kubectl ลงโปรแกรมตามลิ้งค์นี้ตามระบบปฎิบัติการ https://kubernetes.io/docs/tasks/tools/ ข้อควรระวังของเวอร์ชั่น ไม่ควรให้ kubectl version กับ EKS control plane version ห่างกันเกิน 1 เวอร์ชั่นย่อย (+/- 1) อย่างเช่นหาก EKS version 1.30, kubectl version ควรจะเป็น 1.29, 1.30, 1.31 เป็นต้น

หลังจากลง kubectl เรียบร้อยแล้ว สามารถใช้ aws eks update-kubeconfig --name NAME ไฟล์ kubeconfig จะถูก update หลังจากนั้นจะสามารถเรียก Kubernetes API ไปยัง EKS endpoint ได้
kubectl get nodes เพื่อเรียกดู worker node ในคลัสเตอร์เป็นต้น

Destroy stuffs (EKS cluster cost money)

eksctl delete cluster -n NAME -r REGION เพื่อทำการลบ Cluster ที่สร้างไว้ด้านบน
หาก ไม่ได้สร้าง NAT Gateway ตามที่แนะนำไว้ด้านบน (สร้าง Control Plane ไว้บน VPC CIDR, การลบเพียง cluster ด้วย eksctl ก็เพียงพอ

ในบทความถัดไป เราจะพูดถึง IaC (Terraform) ในการสร้าง EKS Cluster ที่สามารถรองรับ Private Networking ได้