• Ngày 3:

  • Sáng: Cấu hình Cluster EKS: Các loại worker node (Được quản lý so với tự quản lý), các tùy chọn mở rộng node.

  • Chiều: Lưu trữ EKS: Các tùy chọn (EBS, EFS, FSx), Persistent Volume (PV), Persistent Volume Claim (PVC).

  • Bài tập:

    1. Tạo một node group được quản lý trong cluster EKS của bạn.

    2. Triển khai một ứng dụng yêu cầu lưu trữ liên tục.

    3. Thử nghiệm với các loại volume EBS khác nhau.

Clusters

Một cluster Amazon EKS bao gồm hai thành phần chính: Control plane của Amazon EKS & Các nodes Amazon EKS được đăng ký với control plane

• Control plane Amazon EKS bao gồm các control plane nodes chạy phần mềm Kubernetes như etcd và API server.

• Control plane chạy trong tài khoản do AWS quản lý, API Kubernetes được truy cập qua Amazon EKS endpoint.

• Mỗi control plane cụm Amazon EKS là duy nhất, chạy trên tập hợp các instances EC2 riêng.

• Dữ liệu lưu trữ bởi nodes etcd và volumes EBS được mã hóa bằng AWS KMS.

• Control plane được cung cấp trên nhiều Availability Zones, sử dụng Elastic Load Balancing Network Load Balancer.

• Amazon EKS cung cấp elastic network interfaces trong subnets VPC để kết nối control plane instances và nodes.

Important:
Trong môi trường Amazon EKS, bộ nhớ etcd bị giới hạn ở mức 8 GiB theo hướng dẫn upstream. Bạn có thể theo dõi một metric cho database size hiện tại bằng cách chạy lệnh sau:

kubectl get --raw=/metrics | grep "apiserver_storage_size_bytes"

Các nodes Amazon EKS chạy trong tài khoản AWS của bạn.

Nodes kết nối với control plane thông qua API server endpoint và certificate file được tạo cho cụm.

Tạo 1 cluster

Điều kiện tiên quyết

• Yêu cầu một VPC và subnets đáp ứng các yêu cầu của Amazon EKS.

  • Nếu chưa có, có thể tạo chúng bằng AWS CloudFormation template do Amazon EKS cung cấp.

• Cần cài đặt công cụ dòng lệnh kubectl trên thiết bị hoặc AWS CloudShell.

  • Phiên bản có thể giống hoặc chênh lệch một minor version so với phiên bản Kubernetes của cụm.

• Cần cài đặt AWS CLI và cấu hình trên thiết bị/AWS CloudShell.

  • Kiểm tra phiên bản hiện tại bằng lệnh aws --version | cut -d / -f2 | cut -d ' ' -f1.

• Cần một IAM principal với quyền create và describe một cụm Amazon EKS.

Để tạo 1 EKS cluster:

1. Tạo IAM role cho cụm Amazon EKS (nếu chưa có hoặc không dùng eksctl):

   • Tạo tệp tin JSON chứa IAM trust policy.

    cat >eks-cluster-role-trust-policy.json <<EOF
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Service": "eks.amazonaws.com"
          },
          "Action": "sts:AssumeRole"
        }
      ]
    }
    EOF

• Tạo IAM role với trust policy đã tạo:

    aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
  

• Gán policy AmazonEKSClusterPolicy hoặc tạo custom policy với các quyền tối thiểu.

• Đính kèm policy AmazonEKSClusterPolicy vào IAM role:

    aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
  

2. Tạo cụm Amazon EKS bằng eksctl, AWS Management Console, hoặc AWS CLI.

   • Ví dụ sử dụng eksctl:

       eksctl create cluster --name my-cluster --region region-code --version 1.28 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
     

   • Các tùy chọn bổ sung khi tạo cụm: securityGroup, serviceIPv4CIDR, ipFamily.

3. Bật kubectl giao tiếp với cụm bằng cách thêm context mới vào tệp cấu hình kubectl:

    aws eks update-kubeconfig --region region-code --name my-cluster
   

4. Xác nhận giao tiếp với cụm:

    kubectl get svc
   

5. (Khuyến nghị) Tạo IAM OIDC provider cho cụm để sử dụng Amazon EKS add-ons hoặc gán quyền IAM cụ thể cho các workloads.

6. (Khuyến nghị) Cấu hình cụm cho Amazon VPC CNI plugin trước khi triển khai các nodes EC2. Đính kèm một trong các chính sách IAM sau vào IAM role:

   • AmazonEKS_CNI_Policy (nếu cụm sử dụng họ địa chỉ IPv4)

   • Chính sách IAM tùy chỉnh (nếu cụm sử dụng họ địa chỉ IPv6)

7. (Tùy chọn) Bật Prometheus metrics cho cụm và thiết lập aws-auth ConfigMap để cấp quyền in-cluster cho scraper.

8. Cài đặt Amazon EBS CSI driver nếu muốn triển khai các workloads sử dụng volumes EBS trên cụm 1.23 trở lên.

9. Các bước tiếp theo khuyến nghị:

   • Cấp quyền truy cập cụm cho các IAM principal khác.

   • Thêm quyền Amazon EKS bổ sung cho IAM principal đã tạo cụm.

   • Cấp quyền để các IAM principal xem tài nguyên Kubernetes trong Amazon EKS console.

   • Bật private endpoint cho cụm để truy cập từ trong VPC.

   • Bật mã hóa secrets cho cụm.

   • Cấu hình ghi log cho cụm.

   • Thêm nodes vào cụm.

Cluster insights

Amazon EKS cluster insights cung cấp các khuyến nghị giúp bạn tuân theo các best practice của Amazon EKS và Kubernetes. Mọi cluster Amazon EKS đều trải qua kiểm tra tự động, định kỳ dựa trên danh sách insights do Amazon EKS tuyển chọn. Các kiểm tra insight này được Amazon EKS quản lý hoàn toàn và đưa ra khuyến nghị về cách giải quyết mọi phát hiện.

Cách sử dụng cluster insights:

• Kiểm tra cluster insights trong bảng điều khiển EKS trước khi cập nhật phiên bản Kubernetes của cluster.

• Xem xét và sửa lỗi thích hợp nếu cluster có vấn đề được xác định.

• Đợi cluster insights làm mới sau khi sửa lỗi. Cập nhật cluster nếu tất cả vấn đề đã được giải quyết.

Hiện tại, Amazon EKS chỉ trả về insights liên quan đến tính sẵn sàng nâng cấp phiên bản Kubernetes.

Upgrade insights xác định các vấn đề có thể ảnh hưởng đến quá trình nâng cấp cluster Kubernetes, giúp giảm nỗ lực của quản trị viên và tăng độ tin cậy của ứng dụng trên các phiên bản Kubernetes mới hơn.

Cluster insights được cập nhật định kỳ và không thể làm mới thủ công. Sau khi sửa lỗi, cần thời gian để cluster insights cập nhật. So sánh thời gian triển khai thay đổi với "last refresh time" để xác định bản sửa lỗi có thành công hay không.

Xem cluster insights (Console):

1. Mở bảng điều khiển Amazon EKS.

2. Chọn tên của cluster Amazon EKS mà bạn muốn xem insights.

3. Chọn tab Upgrade Insights.

Xem cluster insights (AWS CLI):

1. Xác định cluster mà bạn muốn kiểm tra insights.

2. Chạy lệnh aws eks list-insights --region region-code --cluster-name my-cluster để liệt kê các insights cho một cluster cụ thể.

3. Chạy lệnh aws eks describe-insight --region region-code --id 123e4567-e89b-42d3-a456-579642341238 --cluster-name my-cluster để xem thông tin mô tả về một insight cụ thể.

Update K8s version của EKS cluster

Khi có phiên bản Kubernetes mới trong Amazon EKS, bạn có thể cập nhật cluster Amazon EKS lên phiên bản mới nhất.

Important:

• Sau khi nâng cấp cluster, bạn không thể hạ cấp xuống phiên bản trước đó.

Quy trình cập nhật:

1. So sánh phiên bản Kubernetes của control plane cluster với phiên bản Kubernetes của các nodes.

   • Lấy phiên bản Kubernetes của control plane cluster:

       kubectl version
     

   • Lấy phiên bản Kubernetes của các nodes:

       kubectl get nodes
     

2. Kiểm tra và đảm bảo có Pod security policies phù hợp để tránh các vấn đề bảo mật tiềm ẩn. Check default policy: kubectl get psp eks.privileged

3. Kiểm tra và xóa dòng chỉ có từ "upstream" trong manifest CoreDNS (nếu có). Lệnh tìm kiếm: kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream Sau đó chạy: kubectl edit configmap coredns -n kube-system -o yaml Xóa dòng gần đầu tệp chỉ chứa từ upstream trong tệp configmap. Đừng thay đổi bất cứ điều gì khác trong tệp. Sau khi xóa dòng, hãy lưu các thay đổi.

4. Cập nhật cluster bằng eksctl, AWS Management Console hoặc AWS CLI.

   • Sử dụng eksctl:

       eksctl upgrade cluster --name my-cluster --version 1.29 --approve
     

5. Sau khi cập nhật cluster xong, cập nhật các nodes lên cùng phiên bản Kubernetes minor với cluster đã cập nhật.

6. (Tùy chọn) Nếu đã triển khai Kubernetes Cluster Autoscaler trước khi cập nhật cluster, hãy cập nhật Cluster Autoscaler lên phiên bản mới nhất tương ứng với phiên bản Kubernetes major và minor mà bạn đã cập nhật.

7. (Chỉ áp dụng cho clusters có GPU nodes) Nếu cluster có các node groups hỗ trợ GPU, bạn phải cập nhật NVIDIA device plugin cho Kubernetes DaemonSet trên cluster.

8. Cập nhật Amazon VPC CNI plugin for Kubernetes, CoreDNS và kube-proxy add-ons lên phiên bản tối thiểu được liệt kê trong Service account tokens.

9. Nếu cần, cập nhật phiên bản kubectl. Bạn phải sử dụng phiên bản kubectl nằm trong khoảng chênh lệch một phiên bản minor so với control plane của cluster Amazon EKS.

Xem thêm chi tiết: https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

Delete một EKS cluster

Important:

• Nếu có các service đang hoạt động trong cluster và liên kết với load balancer, bạn phải xóa các service đó trước khi xóa cluster để load balancers được xóa đúng cách. Nếu không, có thể có orphaned resources trong VPC ngăn bạn xóa VPC.

• Nếu gặp lỗi do người tạo cluster đã bị xóa, hãy tham khảo bài viết này để giải quyết: https://repost.aws/knowledge-center/eks-api-server-unauthorized-error

• Tài nguyên Amazon Managed Service for Prometheus nằm ngoài vòng đời của cluster và cần được duy trì độc lập với cluster. Khi xóa cluster, đảm bảo xóa cả các scrapers liên quan để ngừng tính phí.

Bạn có thể xóa cluster bằng eksctl, AWS Management Console, hoặc AWS CLI.

Để xóa cluster Amazon EKS và nodes bằng eksctl:

1. Liệt kê tất cả services đang chạy trong cluster:

    kubectl get svc --all-namespaces
   

2. Xóa bất kỳ service nào có giá trị EXTERNAL-IP. Các service này được liên kết với Elastic Load Balancing load balancer và bạn phải xóa chúng trong Kubernetes.

    kubectl delete svc service-name
   

3. Xóa cluster và các nodes liên quan bằng lệnh sau, thay thế prod bằng tên cluster của bạn:

    eksctl delete cluster --name prod
   

Kiểm soát truy cập EKS cluster endpoint

Khi tạo cluster mới, Amazon EKS tạo một endpoint cho Kubernetes API server được quản lý. Theo mặc định, endpoint này được công khai trên internet và việc truy cập được bảo mật bằng IAM và Kubernetes RBAC.

Bạn có thể bật private access cho Kubernetes API server để tất cả giao tiếp giữa các node và API server đều nằm trong VPC. Bạn cũng có thể giới hạn các địa chỉ IP có thể truy cập API server từ internet hoặc tắt hoàn toàn truy cập internet.

Khi bật private access cho cluster, Amazon EKS tạo một Route 53 private hosted zone và liên kết nó với VPC của cluster. VPC phải có enableDnsHostnames và enableDnsSupport được đặt thành true, và tùy chọn DHCP cho VPC phải bao gồm AmazonProvidedDNS trong danh sách máy chủ tên miền.

Bạn có thể xác định yêu cầu truy cập endpoint API server khi tạo cluster mới và cập nhật cài đặt truy cập endpoint bất kỳ lúc nào.

Có 3 tùy chọn truy cập API server endpoint:

1. Chỉ bật truy cập công khai

2. Bật cả truy cập công khai và riêng tư

3. Chỉ bật truy cập riêng tư

Nếu tắt truy cập công khai, bạn chỉ có thể truy cập API server từ trong VPC hoặc mạng được kết nối. Một số cách truy cập:

• Kết nối mạng của bạn với VPC thông qua AWS transit gateway hoặc tùy chọn kết nối khác.

• Sử dụng Amazon EC2 bastion host trong subnet công khai của VPC.

• Sử dụng AWS Cloud9 IDE trong VPC của cluster.

Bật secret encryption trên cluster hiện tại

Đọc thêm về secret encryption: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ (

Để bật mã hóa secrets, secrets của Kubernetes được mã hóa bằng khóa AWS KMS mà bạn chọn. KMS key phải đáp ứng các điều kiện sau:

• Đối xứng (Symmetric)

• Có thể mã hóa và giải mã dữ liệu

• Được tạo trong cùng một AWS Region với cluster

• Nếu KMS key được tạo trong một tài khoản khác, IAM principal phải có quyền truy cập.

Warning:

• Bạn không thể tắt mã hóa secrets sau khi bật. Hành động này không thể đảo ngược.

Bạn có thể bật mã hóa theo hai cách:

1. Thêm mã hóa vào cluster bằng một lệnh duy nhất:

   • Để tự động mã hóa lại secrets:

       eksctl utils enable-secrets-encryption \
           --cluster my-cluster \
           --key-arn arn:aws:kms:region-code:account:key/key
     

   • Để opt-out tự động mã hóa lại secrets:

       eksctl utils enable-secrets-encryption 
           --cluster my-cluster \
           --key-arn arn:aws:kms:region-code:account:key/key \
           --encrypt-existing-secrets=false
     

2. Thêm mã hóa vào cluster bằng tệp kms-cluster.yaml:

    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig
   
    metadata:
      name: my-cluster
      region: region-code
   
    secretsEncryption:
      keyARN: arn:aws:kms:region-code:account:key/key
   

   • Để tự động mã hóa lại secrets:

       eksctl utils enable-secrets-encryption -f kms-cluster.yaml
     

   • Để opt out tự động mã hóa lại secrets:

       eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
     

Sau khi bật mã hóa trên cluster, bạn phải mã hóa tất cả secrets hiện có bằng khóa mới:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"

Note:

• Nếu bạn sử dụng eksctl, chạy lệnh trên chỉ cần thiết nếu bạn chọn không tự động mã hóa lại secrets.

Warning:

• Nếu bật mã hóa secrets cho cluster hiện có và KMS key bị xóa, không có cách nào để khôi phục cluster. Nếu xóa KMS key, cluster sẽ vĩnh viễn ở trạng thái degraded.

Note:

• Theo mặc định, lệnh create-key tạo một khóa mã hóa KMS đối xứng với chính sách khóa cấp quyền quản trị gốc tài khoản trên các hành động và tài nguyên KMS. Nếu muốn thu hẹp quyền, đảm bảo rằng các hành độngkms:DescribeKeyvàkms:CreateGrantđược cho phép trên policy cho principal gọi APIcreate-cluster.

• Đối với các cluster sử dụng KMS Envelope Encryption, cần có quyền kms:CreateGrant. Điều kiệnkms:GrantIsForAWSResourcekhông được hỗ trợ cho hành động CreateCluster và không nên được sử dụng trong các KMS policy để kiểm soát quyềnkms:CreateGrantcho users thực hiện CreateCluster.

Bật Windows support cho EKS cluster

Trước khi triển khai các nodes Windows, cần lưu ý:

• Có thể sử dụng host networking trên các nodes Windows bằng HostProcess Pods.

• Clusters Amazon EKS phải chứa một hoặc nhiều nodes Linux hoặc Fargate để chạy các Pods hệ thống cốt lõi chỉ chạy trên Linux, chẳng hạn như CoreDNS.

• Không thể sử dụng Security groups for Pods, custom networking, IPv6 với các nodes Windows.

• Các nodes Windows hỗ trợ một elastic network interface trên mỗi node.

• Trong một cluster Amazon EKS, một dịch vụ duy nhất với load balancer có thể hỗ trợ tối đa 1024 Pods back-end.

• Không thể truy xuất logs từ vpc-resource-controller Pod.

• Khi chỉ định custom AMI ID cho các managed node groups Windows, thêm eks:kube-proxy-windows vào AWS IAM Authenticator configuration map.

Điều kiện tiên quyết:

• Một cluster hiện có đang chạy một trong các phiên bản Kubernetes và platform sau:

• Cluster phải có ít nhất một node Linux hoặc Fargate Pod để chạy CoreDNS.

• Một IAM role cho existing Amazon EKS cluster.

Kích hoạt hỗ trợ Windows:

• Nếu cluster chưa đạt hoặc mới hơn các phiên bản Kubernetes và platform được liệt kê bên trên, phải bật legacy Windows support.

• Nếu đã bật hỗ trợ Windows trên cluster cũ hơn, phải xóa vpc-resource-controller và vpc-admission-webhook khỏi data plane trước.

Các bước để bật hỗ trợ Windows:

1. Xác nhận rằng AmazonEKSVPCResourceController policy được gắn vào cluster role: aws iam list-attached-role-policies --role-name eksClusterRole

2. Gắn AmazonEKSVPCResourceController policy vào Amazon EKS cluster IAM role nếu chưa có:

    aws iam attach-role-policy \
      --role-name eksClusterRole \
      --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
   

3. Tạo và apply ConfigMap vpc-resource-controller-configmap.yaml.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: amazon-vpc-cni
      namespace: kube-system
    data:
      enable-windows-ipam: "true"
   

    kubectl apply -f vpc-resource-controller-configmap.yaml
   

4. Xác minh rằng aws-auth ConfigMap có ánh xạ cho instance role của node Windows để bao gồm nhóm quyền eks:kube-proxy-windows RBAC: kubectl get configmap aws-auth -n kube-system -o yaml

Xóa hỗ trợ Windows kế thừa khỏi data plane:

• Gỡ cài đặt vpc-resource-controller:

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml
  

• Gỡ cài đặt vpc-admission-webhook.

    kubectl delete deployment -n kube-system vpc-admission-webhook
    kubectl delete service -n kube-system vpc-admission-webhook
    kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io vpc-admission-webhook-cfg
  

• Bật hỗ trợ Windows trên control plane.

Vô hiệu hóa hỗ trợ Windows:

1. Xóa chính sách IAM AmazonVPCResourceController khỏi cluster role.

    aws iam detach-role-policy \
        --role-name eksClusterRole \
        --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
   

2. Vô hiệu hóa Windows IPAM trong ConfigMap amazon-vpc-cni.

    kubectl patch configmap/amazon-vpc-cni \
                        -n kube-system \
                        --type merge \
                        -p '{"data":{"enable-windows-ipam":"false"}}'
   

Triển khai Pods:

• Đối với Pods Linux, sử dụng node selector:

    nodeSelector:
            kubernetes.io/os: linux
            kubernetes.io/arch: amd64
  

• Đối với Pods Windows, sử dụng node selector:

    nodeSelector:  
            kubernetes.io/os: windows
            kubernetes.io/arch: amd64
  

Kích hoạt legacy Windows support:

• Sử dụng eksctl, máy khách Windows, hoặc máy khách macOS/Linux để bật legacy Windows support cho data plane của cluster nếu phiên bản cluster hoặc platform cũ hơn các phiên bản được liệt kê bên trên: eksctl utils install-vpc-controllers --cluster my-cluster --approve

Gia hạn chứng chỉ VPC admission webhook:

• Chứng chỉ sử dụng bởi VPC admission webhook hết hạn sau một năm. Cần gia hạn trước khi hết hạn để tránh downtime.

• Có thể kiểm tra ngày hết hạn của chứng chỉ hiện tại bằng lệnh:

    kubectl get secret \
        -n kube-system \
        vpc-admission-webhook-certs -o json | \
        jq -r '.data."cert.pem"' | \
        base64 -decode | \
        openssl x509 \
        -noout \
        -enddate | \
        cut -d= -f2
  

• Có thể gia hạn bằng eksctl, máy tính Windows hoặc Linux/macOS.

  • Reinstall certificate: eksctl utils install-vpc-controllers -cluster my-cluster -approve

  • Restart webhook deployment: kubectl rollout restart deployment -n kube-system vpc-admission-webhook

  • Nếu chứng chỉ mà bạn đã gia hạn đã hết hạn và bạn có các Pods Windows bị kẹt ở trạng thái Container creating, thì bạn phải xóa và triển khai lại các Pods đó.

Hỗ trợ mật độ Pod cao hơn trên các nodes Windows:

• Mỗi Pod được cấp một địa chỉ IPv4 từ VPC. Số lượng Pods có thể triển khai lên một node bị hạn chế bởi địa chỉ IP khả dụng.

• Có thể bật mật độ Pod cao hơn trên các nodes Windows bằng cách enabling IP prefix delegation. Tính năng này cho phép gán /28IPv4 prefix cho network interface chính, thay vì gán các secondary IPv4 addresses.

Các yêu cầu đối với private cluster

Nếu cluster không có khả năng truy cập internet ra ngoài, nó phải đáp ứng các yêu cầu sau:

• Cluster phải kéo images từ container registry trong VPC.

• Cluster phải bật endpoint private access. Điều này là bắt buộc để nodes đăng ký với cluster endpoint. Endpoint public access là tùy chọn.

• Self-managed Linux và Windows nodes phải bao gồm cácbootstrap arguments trước khi launched. Các tham số bypass Amazon EKS introspection và không yêu cầu truy cập vào API Amazon EKS từ trong VPC.

• ConfigMap aws-auth của cluster phải được tạo từ trong VPC. Câu lệnh có thể sử dụng: eksctl create iamidentitymapping --help

• Các Pods được cấu hình với IAM roles for service accounts phải sử dụng AWS STS VPC endpoint trong VPC.

• Các subnets VPC của cluster phải có VPC interface endpoint cho bất kỳ dịch vụ AWS nào mà Pods cần truy cập.

Lưu ý:

• Bất kỳ self - managed nodes nào cũng phải được triển khai vào các subnets có VPC interface endpoints cần thiết.

• Nếu Pods sử dụng volumes Amazon EFS, tệp kustomization.yaml (https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) của Amazon EFS CSI driver phải được thay đổi để đặt container images sử dụng cùng AWS Region với cluster Amazon EKS.

• Bạn có thể sử dụng AWS Load Balancer Controller để triển khai ALB và NLB cho cluster private. Khi triển khai, bạn nên sử dụng các command line flag để đặt enable-shield, enable-waf và enable-wafv2 thành false.

• Certificate discovery (https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.7/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) bằng hostname từ các đối tượng Ingress không được hỗ trợ.

• Cluster Autoscaler được hỗ trợ. Khi triển khai Cluster Autoscaler Pods, hãy đảm bảo rằng dòng lệnh bao gồm --aws-use-static-instance-list=true.

• Một số container software sử dụng các lệnh gọi API truy cập AWS Marketplace Metering Service để giám sát việc sử dụng. Các cluster private không cho phép điều này, vì vậy bạn không thể sử dụng các loại container này trong các cluster private.

Autoscaling

Autoscaling là chức năng tự động điều chỉnh tài nguyên của bạn để đáp ứng nhu cầu thay đổi. Amazon EKS hỗ trợ hai sản phẩm autoscaling:

• Karpenter: Một bộ điều chỉnh quy mô cụm Kubernetes linh hoạt, hiệu suất cao giúp cải thiện tính khả dụng của ứng dụng và hiệu quả của cụm. Karpenter khởi chạy các tài nguyên điện toán có kích thước phù hợp (ví dụ: các Amazon EC2 instance) để đáp ứng tải ứng dụng thay đổi trong vòng chưa đầy một phút.

• Cluster Autoscaler: Tự động điều chỉnh số lượng nút trong cụm của bạn khi pod bị lỗi hoặc được lên lịch lại trên các nút khác. Cluster Autoscaler sử dụng các nhóm Auto Scaling.

Nodes

Managed node groups

Amazon EKS managed node groups tự động hóa việc cung cấp và quản lý vòng đời của các node (Amazon EC2 instances) cho các cụm Kubernetes của Amazon EKS.

Với Amazon EKS managed node groups:

• Bạn không cần cung cấp hoặc đăng ký riêng các Amazon EC2 instances.

• Có thể tạo, cập nhật tự động hoặc chấm dứt các node cho cụm bằng một thao tác duy nhất.

• Mỗi managed node được cung cấp như một phần của Amazon EC2 Auto Scaling group do Amazon EKS quản lý.

• Mỗi node group chạy trên nhiều Availability Zones mà bạn xác định.

• Các node được tự động gắn thẻ để tự động khám phá bởi Kubernetes cluster autoscaler.

• Có thể sử dụng node group để áp dụng Kubernetes labels cho các node và cập nhật chúng bất kỳ lúc nào.

• Pay as you go.

Các khái niệm quan trọng:

• Mỗi managed node là một phần của Amazon EC2 Auto Scaling group do Amazon EKS quản lý.

• Auto Scaling group của managed node group trải rộng trên mọi subnet mà bạn chỉ định khi tạo group.

• Amazon EKS gắn thẻ các tài nguyên managed node group để cấu hình sử dụng Kubernetes Cluster Autoscaler.

• Nếu chạy ứng dụng có trạng thái trên nhiều Availability Zones, được hỗ trợ bởi volumes EBS và sử dụng Kubernetes Autoscaling, bạn nên cấu hình nhiều node groups, mỗi group giới hạn trong một Availability Zone và bật tính năng --balance-similar-node-groups.

• Có thể sử dụng launch template custom để linh hoạt hơn khi triển khai managed nodes.

• Amazon EKS tuân theo mô hình trách nhiệm chung cho CVEs và bản vá bảo mật trên managed node groups.

• Managed node groups có thể được khởi chạy trong cả subnets công khai và riêng tư.

• Không thể triển khai managed node groups trên AWS Outposts, AWS Wavelength hoặc AWS Local Zones.

• Có thể tạo nhiều managed node groups trong một cụm duy nhất.

• Amazon EKS tự động drain nodes bằng Kubernetes API trong quá trình chấm dứt hoặc cập nhật.

• Cập nhật managed node groups tôn trọng Pod disruption budgets mà bạn đặt cho Pods.

Các loại dung lượng của managed node group:

• On-Demand: Trả tiền cho dung lượng tính toán theo giây, không có cam kết dài hạn.

• Spot: Sử dụng dung lượng Amazon EC2 dự phòng, cung cấp mức chiết khấu lớn so với giá On-Demand. Có thể bị gián đoạn với thông báo trước 2 phút.

• Spot phù hợp với các ứng dụng không trạng thái, chịu lỗi, linh hoạt. On-Demand phù hợp cho các ứng dụng không chịu lỗi, công cụ quản lý cụm, triển khai yêu cầu StatefulSets và các ứng dụng có trạng thái như cơ sở dữ liệu.

• Để tối đa hóa tính khả dụng của ứng dụng khi sử dụng Spot Instances, nên cấu hình Spot managed node group sử dụng nhiều loại instance.

Tạo một managed node group

Lưu ý:

• Các node Amazon EKS là các instances Amazon EC2 tiêu chuẩn. Bạn được tính phí dựa trên giá Amazon EC2 thông thường.

• Không thể tạo managed nodes trong một AWS Region có AWS Outposts, AWS Wavelength hoặc AWS Local Zones được bật.

• Managed node groups áp dụng một số lượng tối đa cho giá trị maxPods nếu không chỉ định AMI ID cho tệp boostrap.sh đi kèm với Amazon EKS optimized Linux hoặc Bottlerocket.

Điều kiện tiên quyết:

• Đã có 1 cluster Amazon EKS.

• Đã có một IAM role cho các node.

• (Tùy chọn, nhưng được khuyến nghị) Amazon VPC CNI plugin for Kubernetes add-on được cấu hình với IAM role riêng có các IAM policy cần thiết.

• Để thêm Windows managed node group, trước tiên bạn phải bật hỗ trợ Windows cho cluster.

Bạn có thể tạo managed node group bằng eksctl hoặc AWS Management Console.

Các bước tạo managed node group bằng eksctl:

1. Ví(Tùy chọn) Nếu chính sách IAM AmazonEKS_CNI_Policy được gắn vào Amazon EKS node IAM role, nên gán nó cho một IAM role mà bạn liên kết với Kubernetes aws-node service account.

2. Chỉ định thủ công launch template cho phép tùy chỉnh node group nhiều hơn.

   • Không có launch template: eksctl tạo một Amazon EC2 launch template mặc định và triển khai node group bằng launch template mà nó tạo dựa trên các tùy chọn bạn chỉ định.

   • Với launch template: Launch template phải tồn tại sẵn và đáp ứng các yêu cầu được chỉ định.

3. Triển khai nodegroup bằng lệnh eksctl create nodegroup. Ví dụ:

    eksctl create nodegroup \
      --cluster my-cluster \
      --region region-code \
      --name my-mng \
      --node-ami-family ami-family \
      --node-type m5.large \
      --nodes 3 \
      --nodes-min 2 \
      --nodes-max 4 \
      --ssh-access \
      --ssh-public-key my-key
   

Lưu ý:

• Nên chặn quyền truy cập của Pod vào IMDS nếu bạn dự định gán IAM roles cho tất cả Kubernetes service accounts và không có Pod nào trong cluster yêu cầu quyền truy cập vào IMDS.

• Nếu bạn chỉ định AMI ID trong launch template, hãy chỉ định số lượng tối đa Pods có thể chạy trên mỗi node của node group nếu bạn đang sử dụng custom network hoặc muốn tăng số lượng địa chỉ IP được gán cho instance của bạn.

• Principal IAM tạo cluster là principal duy nhất có thể thực hiện các lệnh gọi đến Kubernetes API server bằng kubectl hoặc AWS Management Console.

Update managed node group

Khi bạn initiate cập nhật managed node group, Amazon EKS tự động cập nhật các node cho bạn. Có một số tình huống mà việc cập nhật phiên bản hoặc cấu hình của Amazon EKS managed node group là hữu ích:

• Bạn đã cập nhật phiên bản Kubernetes cho cluster Amazon EKS và muốn cập nhật các node để sử dụng cùng phiên bản Kubernetes.

• Một phiên bản AMI mới khả dụng cho managed node group.

• Bạn muốn điều chỉnh số lượng tối thiểu, tối đa hoặc mong muốn của các instances trong managed node group.

• Bạn muốn thêm hoặc xóa Kubernetes labels khỏi các instances trong managed node group.

• Bạn muốn thêm hoặc xóa AWS tags khỏi managed node group.

• Bạn cần triển khai một phiên bản mới của launch template với các thay đổi cấu hình, chẳng hạn như AMI tùy chỉnh đã cập nhật.

• Bạn đã triển khai phiên bản 1.9.0 trở lên của Amazon VPC CNI add-on, bật add-on cho ủy quyền tiền tố, và muốn các instances AWS Nitro System mới trong node group hỗ trợ số lượng Pods tăng đáng kể.

• Bạn đã bật ủy quyền tiền tố IP cho các node Windows và muốn các instances AWS Nitro System mới trong node group hỗ trợ số lượng Pods tăng đáng kể.

Khi một node trong managed node group bị chấm dứt do hoạt động scaling hoặc cập nhật, các Pods trong node đó sẽ được drain trước.

Cập nhật phiên bản node group:

• Bạn có thể cập nhật phiên bản node group bằng eksctl hoặc AWS Management Console. Phiên bản cập nhật không được lớn hơn phiên bản của control plane. Câu lệnh sample:

    eksctl upgrade nodegroup \
      --name=node-group-name \
      --cluster=my-cluster \
      --region=region-code \
      --kubernetes-version=1.28
  

Chỉnh sửa cấu hình node group:

• Bạn có thể sửa đổi một số cấu hình của managed node group như:

  • Node group scaling configuration: kích thước mong muốn, tối thiểu, tối đa.

  • Thêm hoặc xóa Kubernetes labels vào các nodes trong node group.

  • Thêm hoặc xóa Kubernetes taints vào các nodes trong node group.

  • Thêm hoặc xóa Tags khỏi tài nguyên node group.

  • Node Group update configuration: số lượng hoặc tỷ lệ phần trăm các nodes có thể được cập nhật song song.

Managed node update behavior

1. Giai đoạn thiết lập (Setup phase):

   • Tạo một phiên bản Amazon EC2 launch template mới cho Auto Scaling group liên kết với node group.

   • Cập nhật Auto Scaling group để sử dụng phiên bản launch template mới nhất.

   • Xác định số lượng node tối đa có thể nâng cấp song song bằng thuộc tính updateConfig của node group.

2. Giai đoạn scale up:

   • Các node được nâng cấp sẽ được khởi chạy trong cùng Availability Zone với các node đang được nâng cấp.

   • Tăng kích thước tối đa và kích thước mong muốn của Auto Scaling group lên gấp đôi số lượng Availability Zones hoặc bằng giá trị maxUnavailable của quá trình nâng cấp.

   • Kiểm tra xem các node sử dụng cấu hình mới nhất có hiện diện trong node group hay không.

   • Đánh dấu các node là không thể lập lịch (unschedulable) và gắn nhãn để loại bỏ chúng khỏi load balancers trước khi chấm dứt.

Các lỗi có thể xảy ra trong giai đoạn này:

• Không đủ dung lượng trong Availability Zone.

• Giới hạn số lượng instances EC2 trong tài khoản.

• Custom user data có thể làm gián đoạn quá trình bootstrap.

• Các thay đổi khiến node không khỏe mạnh hoặc không sẵn sàng.

3. Giai đoạn nâng cấp (Upgrade phase):

   • Ngẫu nhiên chọn một node cần nâng cấp, tối đa bằng giá trị maxUnavailable.

   • Drain các Pods khỏi node. Nếu Pods không rời khỏi node trong 15 phút và không có cờ force, quá trình nâng cấp sẽ thất bại với lỗi PodEvictionFailure.

   • Cordon node sau khi mọi Pod được evicted và đợi 60 giây.

   • Gửi yêu cầu chấm dứt tới Auto Scaling Group cho node đã bị cordon.

   • Lặp lại các bước nâng cấp cho đến khi không còn node nào trong node group được triển khai với phiên bản launch template cũ.

Các lỗi có thể xảy ra trong giai đoạn này:

• Pod Disruption Budget (PDB): Aggressive PDB hoặc có nhiều PDB trỏ đến cùng một Pod.

• Deployment chấp nhận mọi taint, dẫn đến node không trống và evict Pod thất bại.

4. Giai đoạn scale down:

   • Giảm kích thước tối đa và kích thước mong muốn của Auto Scaling group xuống một đơn vị để trở về giá trị ban đầu trước khi cập nhật.

   • Nếu quy trình nâng cấp xác định rằng Cluster Autoscaler đang scale up node group trong giai đoạn scale down, nó sẽ thoát ngay lập tức mà không đưa node group trở lại kích thước ban đầu.

Node taints trên managed node groups

Amazon EKS hỗ trợ cấu hình Kubernetes taints thông qua managed node groups. Taints và tolerations đảm bảo rằng các Pods không được lên lịch trên các node không phù hợp.

Taints có thể được áp dụng cho các managed node groups mới và hiện có bằng AWS Management Console, Amazon EKS API hoặc AWS CLI.

Lưu ý:

• Taints có thể được cập nhật sau khi tạo node group bằng API UpdateNodegroupConfig.

• Key của taint phải bắt đầu bằng chữ cái hoặc số, có thể chứa chữ cái, số, dấu gạch ngang (-), dấu chấm (.) và dấu gạch dưới (_), có thể dài tối đa 63 ký tự.

• Value là tùy chọn và phải bắt đầu bằng chữ cái hoặc số, có thể chứa chữ cái, số, dấu gạch ngang (-), dấu chấm (.) và dấu gạch dưới (_), có thể dài tối đa 63 ký tự.

• Khi sử dụng trực tiếp Kubernetes hoặc AWS Management Console, effect của taint phải làNoSchedule,PreferNoSchedulehoặcNoExecute. Tuy nhiên, khi sử dụng AWS CLI hoặc API, effect phải làNO_SCHEDULE,PREFER_NO_SCHEDULEhoặcNO_EXECUTE.

• Tối đa 50 taints được cho phép trên mỗi node group.

• Nếu taints được tạo bằng managed node group bị xóa thủ công khỏi một node, Amazon EKS sẽ không thêm lại taints vào node ngay cả khi taints được chỉ định trong cấu hình của managed node group.

• Bạn có thể sử dụng lệnh AWS CLI aws eks update-nodegroup-config để thêm, xóa hoặc thay thế taints cho các managed node groups.

Ví dụ về việc tạo một node group với taint bằng AWS CLI:

aws eks create-nodegroup \
 --cli-input-json '
{
  "clusterName": "my-cluster",
  "nodegroupName": "node-taints-example",
  "subnets": [
     "subnet-1234567890abcdef0",
     "subnet-abcdef01234567890",
     "subnet-021345abcdef67890"
   ],
  "nodeRole": "arn:aws:iam::111122223333:role/AmazonEKSNodeRole",
  "taints": [
     {
         "key": "dedicated",
         "value": "gpuGroup",
         "effect": "NO_SCHEDULE"
     }
   ]
}'

Custom managed nodes với launch templates

Để có mức độ tùy chỉnh cao nhất, bạn có thể triển khai các managed nodes bằng launch template của riêng mình. Sử dụng launch template cho phép các khả năng như:

• Cung cấp các tham số bootstrap khi triển khai node, như các tham số kubelet bổ sung.

• Gán địa chỉ IP cho Pods từ một khối CIDR khác với địa chỉ IP được gán cho node.

• Triển khai AMI tùy chỉnh của riêng bạn cho các node.

• Triển khai CNI tùy chỉnh của riêng bạn cho các node.

Bạn có thể cập nhật lặp đi lặp lại node group với một phiên bản khác của cùng một launch template. Khi bạn cập nhật node group lên một phiên bản khác của launch template, tất cả các node trong nhóm sẽ được tái tạo để khớp với cấu hình mới của phiên bản launch template được chỉ định.

Khi bạn không cung cấp launch template, Amazon EKS API tự động tạo một launch template với các giá trị mặc định. Tuy nhiên, không nên sửa đổi các launch template được tự động tạo. Các node group hiện có không sử dụng launch template custom sẽ không thể được cập nhật trực tiếp mà phải tạo một node group mới với launch template custom.

Gắn thẻ cho Amazon EC2 instances:

• Bạn có thể sử dụng tham số TagSpecification của launch template để chỉ định các thẻ sẽ áp dụng cho Amazon EC2 instances trong node group.

Sử dụng security groups tùy chỉnh:

• Bạn có thể sử dụng launch template để chỉ định các Amazon EC2 security groups tùy chỉnh áp dụng cho các instances trong node group.

• Amazon EKS chỉ cho phép launch template có một network interface specification.

• Nếu bạn chỉ định các security groups tùy chỉnh trong launch template, Amazon EKS sẽ không thêm cluster security group. Bạn phải đảm bảo các quy tắc inbound và outbound của security groups cho phép giao tiếp với endpoint của cluster.

Amazon EC2 user data:

• Phần user data tùy chỉnh trong launch template có thể được sử dụng để thực hiện các thao tác cấu hình phổ biến mà không cần tạo thủ công từng AMI tùy chỉnh.

• User data trong launch template được sử dụng với managed node groups phải ở định dạng MIME multi-part (cho Amazon Linux AMIs) hoặc định dạng TOML (cho Bottlerocket AMIs).

• Nếu một AMI tùy chỉnh được chỉ định trong launch template, Amazon EKS sẽ không hợp nhất user data.

Chỉ định AMI:

• Nếu bạn cần cung cấp user data để truyền các tham số cho tệp bootstrap.sh (Linux/Bottlerocket AMI) hoặc Start-EKSBootstrap.ps1 (Windows AMI), hãy chỉ định ID AMI trong trường ImageId của launch template.

• Nếu bạn cần chạy AMI tùy chỉnh do các yêu cầu cụ thể về bảo mật, tuân thủ hoặc chính sách nội bộ, hãy tham khảo thêm thông tin trong Amazon Machine Images (AMI) và các tài nguyên liên quan.

Ví dụ: Cung cấp user data nhằm truyền các tham số cho tệp bootstrap.sh

Để cung cấp user data nhằm truyền các tham số cho tệp bootstrap.sh đi kèm với Amazon EKS optimized Linux/Bottlerocket AMI, bạn có thể sử dụng một trong hai cách:

1. Sử dụng eksctl mà không chỉ định launch template:

   • Tạo một tệp cấu hình eksctl (ví dụ: my-nodegroup.yaml) chứa các tham số bootstrap và thông tin node group.

   • Sử dụng lệnh eksctl create nodegroup --config-file=my-nodegroup.yaml để tạo node group.

Ví dụ tệp my-nodegroup.yaml:

    ---
    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig

    metadata:
      name: my-cluster
      region: region-code

    managedNodeGroups:
      - name: my-nodegroup
        ami: ami-1234567890abcdef0
        instanceType: m5.large
        privateNetworking: true
        disableIMDSv1: true
        labels: { x86-al2-specified-mng }
        overrideBootstrapCommand: |
          #!/bin/bash
          /etc/eks/bootstrap.sh my-cluster \
            --b64-cluster-ca certificate-authority \
            --apiserver-endpoint api-server-endpoint \
            --dns-cluster-ip service-cidr.10 \
            --kubelet-extra-args '--max-pods=my-max-pods-value' \
            --use-max-pods false

2. Sử dụng user data trong launch template:

   • Tạo launch template và chỉ định thông tin user data trong phần user data của launch template.

   • Thông tin user data phải ở định dạng MIME multi-part (cho Amazon Linux AMIs) hoặc định dạng TOML (cho Bottlerocket AMIs).

Ví dụ user data cho Amazon Linux 2:

    MIME-Version: 1.0
    Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

    --==MYBOUNDARY==
    Content-Type: text/x-shellscript; charset="us-ascii"

    #!/bin/bash
    set -ex
    /etc/eks/bootstrap.sh my-cluster \
      --b64-cluster-ca certificate-authority \
      --apiserver-endpoint api-server-endpoint \
      --dns-cluster-ip service-cidr.10 \
      --kubelet-extra-args '--max-pods=my-max-pods-value' \
      --use-max-pods false

    --==MYBOUNDARY==--

Đọc thêm:

https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html

Xóa managed node group

1. Khi xóa managed node group, EKS đầu tiên đặt kích thước tối thiểu, tối đa và mong muốn của Auto Scaling group về 0, khiến node group giảm quy mô.

2. Trước khi mỗi instance bị terminat, EKS gửi tín hiệu để drain các Pod khỏi node đó. Nếu Pod không drain trong vài phút, EKS cho phép Auto Scaling tiếp tục terminate instance.

3. Sau khi tất cả instance bị terminat, Auto Scaling group sẽ bị xóa.

4. Lưu ý: Nếu xóa managed node group sử dụng node IAM role không còn được sử dụng bởi các node group khác, role đó sẽ bị xóa khỏi ConfigMap aws-auth, có thể gây ảnh hưởng đến self-managed node groups.

5. Bạn có thể xóa managed node group bằng eksctl, AWS Console hoặc AWS CLI.

6. Với eksctl:

    eksctl delete nodegroup \
      --cluster my-cluster \
      --name my-mng \
      --region region-code
   

Self - managed nodes

1. Một cluster chứa một hoặc nhiều node Amazon EC2 mà các Pod được lên lịch chạy trên đó. Bạn phải trả phí cho các node này dựa trên giá của Amazon EC2.

2. Một cluster có thể chứa nhiều node group. Mỗi node group chứa một hoặc nhiều node được triển khai trong một Auto Scaling group của Amazon EC2. Các instance trong cùng node group có thể khác loại.

3. Amazon EKS cung cấp Amazon EKS optimized AMIs đã được cấu hình sẵn để làm việc với Amazon EKS, bao gồm containerd, kubelet, AWS IAM Authenticator và một bootstrap script.

4. Nếu bạn hạn chế truy cập công khai vào cluster, bạn nên bật tính năng private endpoint để node có thể giao tiếp với cluster.

5. Để thêm self-managed node vào cluster, bạn cần gán tag "kubernetes.io/cluster/tên-cluster=owned" cho chúng.

Tạo self-managed AMZ Linux nodes

1. Điều kiện tiên quyết:

   • Một Amazon EKS cluster đã tồn tại

   • IAM role cho node sử dụng

   • Cài đặt eksctl phiên bản 0.177.0 trở lên

2. Chuẩn bị:

   • Nếu đang sử dụng IRSA, gán IAM policy AmazonEKS_CNI_Policy cho IAM role của service account thay vì node IAM role

   • Xem xét lựa chọn loại instance EC2 phù hợp

3. Tạo node group bằng lệnh eksctl:

   • Cung cấp tên cluster, tên node group, loại instance, số lượng node, ssh key. Sample:

       eksctl create nodegroup \
         --cluster my-cluster \
         --name al-nodes \
         --node-type t3.medium \
         --nodes 3 \
         --nodes-min 1 \
         --nodes-max 4 \
         --ssh-access \
         --managed=false \
         --ssh-public-key my-key
     

   • Có thể tùy chỉnh các tùy chọn về mạng, runtime containerD, quyền truy cập internet

4. Sau khi triển khai:

   • Kiểm tra nếu có node nào không join được cluster

   • Có thể triển khai ứng dụng demo để kiểm tra

   • Khuyến nghị hạn chế quyền truy cập IMDS nếu không cần thiết

5. Lưu ý:

   • Khi triển khai trên Outposts/Wavelength/Local Zones cần sử dụng config file

   • eksctl hiện không hỗ trợ Amazon Linux 2023

Capacity Blocks cho ML

Cách sử dụng Capacity Blocks với Amazon EKS để dự trữ và quy mô tự động các self-managed node:

• Capacity Blocks chỉ khả dụng cho một số loại instance EC2 và vùng AWS nhất định. Không thể sử dụng với managed node groups hay Karpenter.

• Tạo một launch template trong AWS Console, bao gồm cấu hình instance type, AMI và liên kết với Capacity Block bằng ID dự trữ. Sample:

    NodeLaunchTemplate:
        Type: "AWS::EC2::LaunchTemplate"
        Properties:
          LaunchTemplateData:
            InstanceMarketOptions:
              MarketType: "capacity-block"
            CapacityReservationSpecification:
              CapacityReservationTarget:
                CapacityReservationId: "cr-02168da1478b509e0"
            IamInstanceProfile:
              Arn: iam-instance-profile-arn
            ImageId: image-id
            InstanceType: p5.48xlarge
            KeyName: key-name
            SecurityGroupIds:
            - sg-05b1d815d1EXAMPLE
            UserData: user-data
  

• Tạo Auto Scaling group với launch template đã liên kết, chỉ định subnet trong Availability Zone có dự trữ Capacity Block. Sample:

      NodeGroup:
        Type: "AWS::AutoScaling::AutoScalingGroup"
        Properties:
          DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity
          LaunchTemplate:
            LaunchTemplateId: !Ref NodeLaunchTemplate
            Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber
          MaxSize: !Ref NodeAutoScalingGroupMaxSize
          MinSize: !Ref NodeAutoScalingGroupMinSize
          VPCZoneIdentifier: !Ref Subnets
          Tags:
            - Key: Name
              PropagateAtLaunch: true
              Value: !Sub ${ClusterName}-${NodeGroupName}-Node
            - Key: !Sub kubernetes.io/cluster/${ClusterName}
              PropagateAtLaunch: true
              Value: owned
  

• Nếu tạo node group trước khi dự trữ kích hoạt, đặt desired capacity về 0 và chỉ chỉ định subnet tương ứng.

• Ghi lại NodeInstanceRole của node group để các node mới có thể join cluster.

• Khuyến nghị tạo scheduled scaling policy cho Auto Scaling group phù hợp thời gian dự trữ Capacity Block.

• Dự trữ sẽ được giải phóng sau 30 phút trước thời gian kết thúc, nên lên lịch scale về 0 trước đó để drain node.

• Nếu muốn scale lên bằng tay, cập nhật desired capacity khi dự trữ Active và scale xuống trước 30 phút kết thúc.

• Cài đặt AWS Node Termination Handler để drain Pod khi scale xuống, nếu không Pod sẽ bị treo.

• Nếu không sử dụng Handler, drain Pod thủ công trước 30 phút để đủ thời gian.

Bottlerocket

Cách triển khai node group với Bottlerocket nodes cho Amazon EKS cluster bằng eksctl:

1. Điều kiện tiên quyết:

   • Cài đặt eksctl phiên bản 0.177.0 trở lên

   • Cluster được tạo bằng eksctl

2. Chuẩn bị config file bottlerocket.yaml:

   • Chỉnh sửa tên cluster, node group, loại instance, số lượng node

   • Thêm các IAM policy cần thiết

   • Chỉ định SSH key để truy cập node

Sample:

    cat >bottlerocket.yaml <<EOF
    ---
    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig

    metadata:
      name: my-cluster
      region: region-code
      version: '1.29'

    iam:
      withOIDC: true

    nodeGroups:
      - name: ng-bottlerocket
        instanceType: m5.large
        desiredCapacity: 3
        amiFamily: Bottlerocket
        ami: auto-ssm
        iam:
           attachPolicyARNs:
              - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
              - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
              - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
              - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        ssh:
            allow: true
            publicKeyName: my-ec2-keypair-name
    EOF

3. Triển khai node group từ config file:

   • Chạy lệnh eksctl create nodegroup --config-file=bottlerocket.yaml

4. Lưu ý:

   • Để triển khai trên Outposts/Wavelength/Local Zones, chỉ định subnet tương ứng trong config file

   • Xem xét đặc biệt khi sử dụng instance type Arm

   • Có hướng dẫn xây dựng custom AMI Bottlerocket

5. Tùy chọn sau khi triển khai:

   • Tạo Kubernetes persistent volume với Amazon EBS CSI Plugin

   • Chỉnh sửa cấu hình kube-proxy để giữ nguyên giá trị nf_conntrack_max kubectl edit -n kube-system daemonset kube-proxy.

   • Triển khai ứng dụng demo để kiểm tra

   • Khuyến nghị hạn chế quyền truy cập IMDS nếu không cần thiết. Vi

Windows

Cách triển khai node group với Windows nodes cho Amazon EKS cluster bằng eksctl:

1. Điều kiện tiên quyết:

   • Cài đặt eksctl phiên bản 0.177.0 trở lên

   • Cluster EKS đã tồn tại (được tạo bằng eksctl)

   • Bật hỗ trợ Windows cho cluster

2. Chuẩn bị:

   • Nếu đang sử dụng IRSA, gán IAM policy AmazonEKS_CNI_Policy/AmazonEKS_CNI_IPv6_Policy cho IAM role của service account thay vì node IAM role

3. Tạo node group bằng lệnh eksctl:

   • Cung cấp region, tên cluster, tên node group

   • Chỉ định loại node, số lượng node, giá trị min/max

   • Sử dụng Windows Server 2019 hoặc 2022 AMI family

     Ví dụ:

       eksctl create nodegroup \
           --region region-code \
           --cluster my-cluster \
           --name ng-windows \
           --node-type t2.large \
           --nodes 3 \
           --nodes-min 1 \
           --nodes-max 4 \
           --managed=false \
           --node-ami-family WindowsServer2019FullContainer
     

4. Lưu ý:

   • Để triển khai trên Outposts/Wavelength/Local Zones, sử dụng config file và chỉ định subnet tương ứng

5. Sau khi triển khai:

   • Kiểm tra nếu có node nào không join được cluster

   • Có thể triển khai ứng dụng demo để kiểm tra

6. Khuyến nghị hạn chế quyền truy cập IMDS nếu không cần thiết

Ubuntu

Cách triển khai node group với Ubuntu hoặc Ubuntu Pro nodes cho Amazon EKS cluster bằng eksctl:

1. Điều kiện tiên quyết:

   • Cài đặt eksctl phiên bản 0.177.0 trở lên

   • Cluster EKS đã tồn tại (được tạo bằng eksctl)

2. Chuẩn bị config file ubuntu.yaml:

   • Chỉnh sửa tên cluster, node group, loại instance, số lượng node

   • Chọn amiFamily Ubuntu22.04 cho Ubuntu hoặc UbuntuPro2204 cho Ubuntu Pro

   • Thêm các IAM policy cần thiết

   • Chỉ định SSH key để truy cập node

Ví dụ:

    cat >ubuntu.yaml <<EOF
    ---
    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig

    metadata:
      name: my-cluster
      region: region-code
      version: '1.29'

    iam:
      withOIDC: true

    nodeGroups:
      - name: ng-ubuntu
        instanceType: m5.large
        desiredCapacity: 3
        amiFamily: Ubuntu22.04
        ami: auto-ssm
        iam:
           attachPolicyARNs:
              - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
              - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
              - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
              - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        ssh:
            allow: true
            publicKeyName: my-ec2-keypair-name
    EOF

3. Triển khai node group từ config file:

   • Chạy lệnh eksctl create nodegroup --config-file=ubuntu.yaml

4. Lưu ý:

   • Để triển khai trên Outposts/Wavelength/Local Zones, chỉ định subnet tương ứng trong config file

   • Xem xét đặc biệt khi sử dụng instance type Arm hoặc có Inferentia chip

5. Sau khi triển khai:

   • Có thể triển khai ứng dụng demo để kiểm tra

6. Khuyến nghị hạn chế quyền truy cập IMDS nếu không cần thiết

Self - managed node updates

1. Có hai cách cơ bản để cập nhật:

   • Di chuyển sang node group mới

   • Cập nhật node group hiện có

2. Di chuyển sang node group mới:

   • Tạo node group mới với AMI/Kubernetes version mới

   • Taint node group cũ thành NoSchedule và drain các node

   • Di chuyển Pod sang node group mới

   • Cách này được khuyến nghị vì ổn định hơn

3. Cập nhật node group hiện có:

   • Cập nhật AWS CloudFormation stack của node group để sử dụng AMI mới

   • Phương pháp này không áp dụng cho node group được tạo bằng eksctl

Nhìn chung, di chuyển sang node group mới được khuyến nghị hơn để đảm bảo quá trình cập nhật ổn định và không làm gián đoạn quá nhiều ứng dụng hiện có.

Di chuyển sang node group mới

Cách di chuyển ứng dụng sang node group mới trong Amazon EKS bằng eksctl:

1. Kiểm tra tên node group hiện tại bằng lệnh eksctl get nodegroups --cluster=my-cluster

2. Tạo node group mới với thông tin phiên bản Kubernetes, loại instance, số lượng node mong muốn

   • Phiên bản Kubernetes không được mới hơn control plane

   • Có tùy chọn --disable-pod-imds để chặn quyền truy cập IMDS

Ví dụ:

    eksctl create nodegroup \
      --cluster my-cluster \
      --version 1.29 \
      --name standard-nodes-new \
      --node-type t3.medium \
      --nodes 3 \
      --nodes-min 1 \
      --nodes-max 4 \
      --managed=false

3. Kiểm tra các node mới đã sẵn sàng bằng lệnh kubectl get nodes

4. Xóa node group cũ bằng lệnh eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old

Lưu ý:

• Quá trình chỉ áp dụng cho cluster và node group được tạo bằng eksctl

• Khi tạo node group mới, Pod sẽ tự động được lên lịch vào đó

• Xóa node group cũ sẽ taint các node đó thành NoSchedule và tiến hành drain

Cập nhật node group hiện có

Cách cập nhật self-managed node group trong Amazon EKS bằng cách cập nhật AWS CloudFormation stack với AMI mới:

1. Kiểm tra nhà cung cấp DNS của cluster (CoreDNS hay kube-dns): kubectl get deployments -l k8s-app=kube-dns -n kube-system và scale lên 2 replica: kubectl scale deployments/coredns --replicas=2 -n kube-system

2. Tạm dừng Cluster Autoscaler (nếu đang sử dụng): kubectl scale deployments/coredns --replicas=2 -n kube-system

3. Ghi lại loại instance và số lượng instance mong muốn của node group hiện tại

4. Mở AWS CloudFormation console, chọn stack của node group và "Update"

5. Cập nhật template bằng đường dẫn Amazon S3 mới nhất

6. Cấu hình các tham số:

   • DesiredCapacity, MaxSize với số lượng node mong muốn

   • NodeInstanceType với loại instance phù hợp

   • NodeImageIdSSMParam với tham chiếu đến AMI ID mới nhất cho phiên bản Kubernetes tương ứng

7. Có tùy chọn tắt IMDSv1 trên node mới

8. Xác nhận cập nhật stack

9. Đợi quá trình cập nhật node hoàn tất

10. Scale DNS provider về 1 replica: kubectl scale deployments/kube-dns --replicas=1 -n kube-system

11. Khởi động lại Cluster Autoscaler: kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system

12. Kiểm tra và cập nhật Amazon VPC CNI plugin nếu cần

Lưu ý: Phương pháp này không áp dụng cho node group được tạo bằng eksctl. Quá trình đảm bảo luôn có số lượng node mong muốn trong khi cập nhật từng node.

AWS Fargate

Cách bắt đầu chạy Pod trên AWS Fargate với Amazon EKS cluster:

1. Điều kiện tiên quyết: Một Amazon EKS cluster đã tồn tại

2. Đảm bảo các node hiện có có thể giao tiếp với Fargate Pod:

   • Kiểm tra và thêm cluster security group cho các self-managed node group: aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId

   • Managed node group đã được cấu hình sẵn

3. Tạo Fargate Pod execution role để cung cấp quyền IAM cho Fargate:

   • Nếu tạo cluster với eksctl --fargate thì role đã có sẵn

   • Nếu không thì tạo role mới

4. Tạo Fargate profile để định nghĩa Pod nào sẽ chạy trên Fargate:

   • Với eksctl: eksctl create fargateprofile. Sample:

       eksctl create fargateprofile \
           --cluster my-cluster \
           --name my-fargate-profile \
           --namespace my-kubernetes-namespace \
           --labels key=value
     

   • Hoặc sử dụng AWS Console

5. Cập nhật CoreDNS để chạy trên Fargate (nếu muốn):

   • Tạo Fargate profile cho CoreDNS. Sample:

       aws eks create-fargate-profile \
           --fargate-profile-name coredns \
           --cluster-name my-cluster \
           --pod-execution-role-arn arn:aws:iam::111122223333:role/AmazonEKSFargatePodExecutionRole \
           --selectors namespace=kube-system,labels={k8s-app=kube-dns} \
           --subnets subnet-0000000000000001 subnet-0000000000000002 subnet-0000000000000003
     

   • Xóa annotation eks.amazonaws.com/compute-type trên Pod CoreDNS:

       kubectl patch deployment coredns \
           -n kube-system \
           --type json \
           -p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'
     

6. Các bước tiếp theo:

   • Di chuyển ứng dụng để chạy trên Fargate

   • Triển khai Application Load Balancing

   • Sử dụng Vertical/Horizontal Pod Autoscaler

   • Thiết lập ADOT collector để giám sát

AWS Fargate profile

1. Fargate Profile định nghĩa Pod nào sẽ chạy trên Fargate khi được khởi tạo, thông qua selectors.

2. Mỗi profile có thể có tối đa 5 selectors, mỗi selector bao gồm:

   • Namespace (bắt buộc)

   • Labels (tùy chọn)

3. Nếu Pod khớp với bất kỳ selector nào trong profile thì sẽ được lên lịch trên Fargate.

4. Khi tạo profile, cần chỉ định:

   • Pod execution role để cấp quyền IAM

   • Private subnets để chạy Pod

5. Profile không thể thay đổi, nhưng có thể tạo mới để thay thế cũ rồi xóa cũ.

6. Có thể sử dụng wildcard * và ? cho namespace và labels trong selector.

7. Tạo profile bằng eksctl hoặc AWS Console. Ví dụ:

    eksctl create fargateprofile \
        --cluster my-cluster \
        --name my-fargate-profile \
        --namespace my-kubernetes-namespace \
        --labels key=value
   

8. Xóa profile sẽ dừng tất cả Pod đang chạy trên profile đó. Chỉ một profile cùng lúc có thể xóa. Lệnh xóa: eksctl delete fargateprofile --name my-profile --cluster my-cluster

9. Khi Pod khớp nhiều profile, thứ tự ưu tiên dựa vào tên profile theo bảng chữ cái.

10. Để di chuyển Pod sang profile mới với wildcard, tạo profile mới rồi xóa cũ hoặc tạo tên sắp xếp trước cũ.

Fargate Pod configuration

1. CPU và Memory:

   • Yêu cầu CPU và Memory trong Pod spec xác định lượng tài nguyên được cấp phát

   • Fargate chọn cấu hình CPU/Memory gần nhất lớn hơn tổng yêu cầu của containers

   • Thêm 256MB vào yêu cầu Memory để chạy các thành phần Kubernetes

   • Bảng liệt kê các tổ hợp CPU/Memory hợp lệ trên Fargate:

2. Lưu trữ:

   • Mỗi Pod được gắn kết với Amazon EFS tự động

   • Không hỗ trợ dynamic provisioning, chỉ static provisioning. Xem chi tiết: https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md

   • Mỗi Pod có 20GiB lưu trữ tạm thời mặc định, có thể tăng tối đa 175GiB

   • Ephermeral storage được mã hóa AES-256 bằng khóa do Fargate quản lý

   • Để cấu hình kích thước với Kubernetes, hãy chỉ định các yêu cầu về tài nguyên ephemeral-storage cho từng container trong một Pod. Khi Kubernetes lên lịch các Pod, nó đảm bảo rằng tổng các yêu cầu tài nguyên cho mỗi Pod nhỏ hơn khả năng của tác vụ Fargate.

3. Kiểm tra:

   • Sử dụng kubectl describe pod để kiểm tra dung lượng CPU/Memory thực tế

   • Annotation CapacityProvisioned cho biết việc cấp phát thực tế

Fargate tự động phân bổ tài nguyên CPU, Memory và lưu trữ cho Pod dựa trên yêu cầu trong Pod spec, nhưng luôn được làm tròn lên cấu hình sẵn có gần nhất lớn hơn.

Fargate OS patching

• Amazon EKS định kỳ vá lỗi bảo mật cho Fargate node bằng cách tái tạo node để cài đặt bản vá.

• Trong quá trình vá, nếu Pod không thể được đẩy ra thành công, chúng có thể bị xóa.

• Khuyến nghị:

  • Đặt Pod disruption budgets để kiểm soát số lượng Pod bị ngừng cùng lúc

  • Tạo Amazon EventBridge rules để xử lý sự cố đẩy Pod trước khi chúng bị xóa

  • Tạo cấu hình thông báo trong AWS User Notifications

• Amazon EKS luôn khởi tạo Pod với phiên bản Kubernetes mới nhất để đảm bảo an ninh.

• Sự cố đẩy Pod ra khỏi node sẽ gửi một sự kiện với chi tiết về Pod, lịch xóa dự kiến.

• Nhiều Pod disruption budget gây ra lỗi đẩy Pod.

• Tạo EventBridge rule với custom pattern để nhận sự kiện và thực hiện hành động mong muốn. Pattern:

    {
      "source": ["aws.eks"],
      "detail-type": ["EKS Fargate Pod Scheduled Termination"]
    }
  

• Cũng có thể tạo cấu hình thông báo trong AWS User Notifications.

Fargate metrics

1. Metric ứng dụng:

   • Sử dụng AWS Distro for OpenTelemetry (ADOT) để thu thập metric hệ thống

   • Metric được gửi tới CloudWatch Container Insights dashboards

2. Metric sử dụng:

   • CloudWatch usage metric cung cấp khả năng giám sát sử dụng tài nguyên Fargate. Metrics trong namespace AWS/Usage:

     | Metric | Description | | --- | --- | | ResourceCount | The total number of the specified resource running on your account. The resource is defined by the dimensions associated with the metric. |

   • Metric tương ứng với giới hạn dịch vụ (service quotas) của Fargate

   • Có thể cấu hình cảnh báo khi sử dụng đến gần giới hạn

3. Fargate công bố các metric sau trong namespace AWS/Usage:

   • ResourceCount: Số lượng tài nguyên đang chạy

   • Các dimensions: Service, Type, Resource, Class

4. Hiện tại chỉ có metric cho Fargate On-Demand resource usage.

5. Hướng dẫn tạo CloudWatch alarm để giám sát sử dụng Fargate dựa trên usage metric:

   • Truy cập Service Quotas console

   • Chọn giới hạn Fargate muốn giám sát

   • Tạo CloudWatch alarm với ngưỡng báo động

Fargate logging

1. Điều kiện tiên quyết:

   • Fargate profile và namespace để chạy Pod

   • Fargate Pod execution role

2. Tạo namespace aws-observability:

cat >aws-observability-namespace.yaml <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: aws-observability
  labels:
    aws-observability: enabled
EOF
kubectl apply -f aws-observability-namespace.yaml

3. Tạo ConfigMap với cấu hình Fluent Conf để định tuyến log:

   • Chỉ chấp nhận các section [FILTER], [OUTPUT], [PARSER]

   • Ví dụ cho CloudWatch:

aws-logging-cloudwatch-configmap.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: aws-observability
data:
  flb_log_cw: "false"  # Set to true to ship Fluent Bit process logs to CloudWatch.
  filters.conf: |
    [FILTER]
        Name parser
        Match *
        Key_name log
        Parser crio
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        Buffer_Size 0
        Kube_Meta_Cache_TTL 300s
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match   kube.*
        region region-code
        log_group_name my-logs
        log_stream_prefix from-fluent-bit-
        log_retention_days 60
        auto_create_group true
  parsers.conf: |
    [PARSER]
        Name crio
        Format Regex
        Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
        Time_Key    time
        Time_Format %Y-%m-%dT%H:%M:%S.%L%z

kubectl apply -f aws-logging-cloudwatch-configmap.yaml  
curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json
aws iam create-policy --policy-name eks-fargate-logging-policy --policy-document file://permissions.json
aws iam attach-role-policy \
  --policy-arn arn:aws:iam::111122223333:policy/eks-fargate-logging-policy \
  --role-name AmazonEKSFargatePodExecutionRole

4. Triển khai ứng dụng sample:

sample-app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
  namespace: same-namespace-as-your-fargate-profile
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - name: http
              containerPort: 80

kubectl apply -f sample-app.yaml

5. Kiểm tra log tại đích đã cấu hình

6. Xử lý sự cố:

   • Sử dụng kubectl describe pod để kiểm tra trạng thái logging

Lưu ý:

• Không hỗ trợ cấu hình động ConfigMap, chỉ áp dụng cho Pod mới

• Có thể gửi log Fluent Bit process tới CloudWatch bằng cấu hình bổ sung

Instance types

• Amazon EC2 cung cấp nhiều loại instance khác nhau cho worker nodes, mỗi loại có khả năng tính toán, bộ nhớ, lưu trữ và mạng khác nhau. Không phải tất cả AMI của EKS đều hỗ trợ các dòng instance g5g, mac, g3, g4, inf, p, a, c, hpc, m và t.

• Khi chọn loại instance, cần xem xét số lượng instances trong một node group (nên ít và lớn hơn là nhiều và nhỏ), hệ điều hành (Linux, Windows, Bottlerocket), kiến trúc phần cứng (x86, Arm, Nitro System), số Pods tối đa được hỗ trợ, dòng địa chỉ IP (IPv4, IPv6), phiên bản Amazon VPC CNI add-on, khu vực AWS và liệu có sử dụng security groups cho Pods hay không.

• Số Pods tối đa phụ thuộc vào số địa chỉ IP mà một instance hỗ trợ. Amazon EKS cung cấp script để tính toán số Pods tối đa được khuyến nghị cho từng loại instance. Script này sử dụng các thuộc tính phần cứng và tùy chọn cấu hình để xác định. Download curl -Ohttps://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/templates/al2/runtime/max-pods-calculator.sh Sau đó chmod +xmax-pods-calculator.sh . Ví dụ sử dụng: ./max-pods-calculator.sh--instance-type m5.large --cni-version 1.9.0-eksbuild.1

• Có thể sử dụng các tùy chọn trong script như --cni-custom-networking-enabled (gán IP cho Pods từ subnet khác với instance) và --cni-prefix-delegation-enabled (tăng đáng kể số IP cho mỗi ENI) để kiểm tra số Pods tối đa khi bật các khả năng tùy chọn.

EKS Optimized AMIs

Amazon EKS optimized Amazon Linux AMIs

Amazon EKS Optimized Amazon Linux AMI được xây dựng dựa trên Amazon Linux 2 (AL2) và Amazon Linux 2023 (AL2023). AMI này được cấu hình để làm hình ảnh cơ sở cho node Amazon EKS và bao gồm các thành phần như kubelet, AWS IAM Authenticator, Docker (cho Kubernetes 1.23 trở xuống), và containerd.

Đối với Kubernetes 1.25 trở lên, AMI tối ưu hóa sẽ hỗ trợ driver NVIDIA dòng 525 trở lên, không tương thích với instance P2 nhưng tương thích với P3, P4, P5. Từ EKS 1.30, node group mới mặc định sử dụng AL2023.

Khi nâng cấp lên AL2023 cho self-managed node groups hoặc sử dụng launch template, cần cung cấp metadata cụm rõ ràng:

---
apiVersion: node.eks.aws/v1alpha1  
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16

Docker không được hỗ trợ trên AL2023 cho EKS >=1.24. Yêu cầu Amazon VPC CNI >=1.16.2.

Với Kubernetes 1.23, có thể sử dụng BootstrapArguments để thử nghiệm containerd:

Self-managed:

--container-runtime containerd

Managed với eksctl:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-id  
    overrideBootstrapCommand: |
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd

eksctl create nodegroup -f my-nodegroup.yaml

AMI tối ưu hóa GPU hỗ trợ GPU, Inferentia, Trainium. Cần áp dụng plugin thiết bị NVIDIA:

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml

Kiểm tra GPU khả dụng:

kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

Kiểm tra Pod sử dụng GPU:

apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: nvidia/cuda:tag
    args:
    - "nvidia-smi"
    resources:
      limits:
        nvidia.com/gpu: 1

kubectl apply -f nvidia-smi.yaml
kubectl logs nvidia-smi

AMI ARM cung cấp tiết kiệm chi phí cho ứng dụng cơ bản dựa trên ARM. Cần xem xét khi thêm node ARM vào cụm như nâng cấp add-on, ứng dụng cần biên dịch cho ARM, đa kiến trúc DaemonSet và image container.

Amazon EKS optimized Bottlerocket AMIs

Bottlerocket là một phân phối Linux nguồn mở được tài trợ và hỗ trợ bởi AWS, được xây dựng để chạy các workload container. Nó chỉ bao gồm phần mềm cần thiết để chạy container, giúp cải thiện sử dụng tài nguyên, giảm mối đe dọa bảo mật và giảm chi phí vận hành. AMI Bottlerocket bao gồm containerd, kubelet và AWS IAM Authenticator.

Lợi ích:

• Uptime cao hơn với chi phí vận hành và phức tạp quản lý thấp hơn nhờ dấu chân tài nguyên nhỏ hơn.

• Cải thiện bảo mật từ cập nhật OS tự động dưới dạng một đơn vị đơn lẻ có thể hoàn tác.

• Hỗ trợ cao cấp từ AWS.

Cân nhắc:

• Chỉ hỗ trợ instance x86_64 và arm64, không khuyến khích cho Inferentia.

• Hiện không có AWS CloudFormation template.

• Không có SSH server hay shell, cần dùng phương pháp truy cập out-of-band.

• Sử dụng các container khác nhau: control container (chạy AWS Systems Manager agent) và admin container (với SSH key).

Bottlerocket được hỗ trợ bởi Karpenter, ngoài managed node groups và self-managed nodes.

Ubuntu Linux

Canonical đã hợp tác với Amazon EKS để tạo ra các AMI node Ubuntu có thể sử dụng trong các cụm EKS. AMI Ubuntu này là một bản phân phối Ubuntu tối giản, được tối ưu hóa cho EKS và bao gồm custom AWS kernel được phát triển chung với AWS.

Ưu điểm của AMI Ubuntu bao gồm:

• Hình ảnh Ubuntu tối thiểu, tối ưu cho EKS

• Bao gồm custom AWS kernel phát triển chung với AWS

• Có thể sử dụng cho cả managed node groups và self-managed nodes

Canonical cung cấp thông tin hỗ trợ cho AMI Ubuntu trên trang web của họ và trong phần Third-party software của tài liệu AWS Premium Support FAQs.

Amazon EKS optimized Windows AMIs

• Được xây dựng dựa trên Windows Server 2019 và 2022, cấu hình làm hình ảnh cơ sở cho node EKS

• Bao gồm các thành phần: kubelet, kube-proxy, AWS IAM Authenticator, csi-proxy, containerd

• Có các biến thể AMI: Core và Full cho cả Server 2019 và 2022

• Windows Server 20H2 Core AMI đã bị loại bỏ

• EKS duy trì các AMI Windows được tối ưu hóa trong vòng 4 tháng cuối, các AMI cũ hơn sẽ trở nên riêng tư

• Có lịch phát hành và ngừng hỗ trợ cho các phiên bản Windows

Khi tạo node, có bootstrap script cho phép cấu hình các tham số như tên cụm, endpoint API, CIDR dịch vụ, v.v.

Có thể sử dụng eksctl để tạo self-managed Windows Server 2022 node

EKS hỗ trợ xác thực domain-joined gMSA và domainless gMSA cho Windows Pod

Các AMI Windows được tối ưu hóa có cache các image container nhất định cho containerd runtime. Cached container images cho containerd runtime:

• amazonaws.com/eks/pause-windows

• mcr.microsoft.com/windows/nanoserver

• mcr.microsoft.com/windows/servercore

Storage

Amazon EBS CSI driver

• Amazon EBS CSI driver quản lý vòng đời của các volume EBS như bộ nhớ cho các Kubernetes Volume. Nó hỗ trợ các loại volume Kubernetes như generic ephemeral volume và persistent volume.

• Để sử dụng EBS CSI driver, cần lưu ý:

  • Plugin này yêu cầu quyền IAM để gọi API AWS.

  • Không thể mount volume EBS lên Fargate Pod.

  • Controller của driver có thể chạy trên node Fargate, nhưng DaemonSet của node chỉ chạy được trên EC2.

• EBS CSI driver không được cài đặt mặc định khi tạo cluster. Để dùng nó, bạn phải thêm vào dưới dạng EKS add-on hoặc tự cài đặt.

  • Để thêm như EKS add-on, xem hướng dẫn "Managing the Amazon EBS CSI driver as an Amazon EKS add-on".

  • Để tự cài đặt, xem https://github.com/kubernetes-sigs/aws-ebs-csi-driver.

• Sau khi cài xong, bạn có thể kiểm tra tính năng bằng một ứng dụng mẫu như hướng dẫn trong "Deploy a sample application and verify that the CSI driver is working".

Tạo Amazon EBS CSI driver IAM role:

Yêu cầu:

• EBS CSI plugin cần quyền IAM để gọi API AWS.

• Pod sẽ có quyền của IAM role trừ khi bạn chặn truy cập IMDS.

• Cần có cluster và IAM OIDC provider cho cluster.

Các bước tạo IAM role và gán policy (dùng eksctl, AWS Console hoặc AWS CLI):

1. Tạo IAM role và attach policy AWS managed hoặc custom.

   • Với AWS managed policy, chạy lệnh eksctl để tạo role "AmazonEKS_EBS_CSI_DriverRole" và attach policy "AmazonEBSCSIDriverPolicy":

    eksctl create iamserviceaccount \
        --name ebs-csi-controller-sa \
        --namespace kube-system \
        --cluster my-cluster \
        --role-name AmazonEKS_EBS_CSI_DriverRole \
        --role-only \
        --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
        --approve

2. Nếu dùng custom KMS key để mã hoá EBS volume:

   • Tạo file JSON policy với các quyền cần thiết và ARN của custom key:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "kms:CreateGrant",
            "kms:ListGrants",
            "kms:RevokeGrant"
          ],
          "Resource": ["custom-key-arn"],
          "Condition": {
            "Bool": {
              "kms:GrantIsForAWSResource": "true"
            }
          }
        },
        {
          "Effect": "Allow",
          "Action": [
            "kms:Encrypt",
            "kms:Decrypt",
            "kms:ReEncrypt*",
            "kms:GenerateDataKey*",
            "kms:DescribeKey"
          ],
          "Resource": ["custom-key-arn"]
        }
      ]
    }

• Tạo policy từ file JSON đó:

    aws iam create-policy \
      --policy-name KMS_Key_For_Encryption_On_EBS_Policy \
      --policy-document file://kms-key-for-encryption-on-ebs.json
  

• Attach policy vừa tạo vào role "AmazonEKS_EBS_CSI_DriverRole".

    aws iam attach-role-policy \
      --policy-arn arn:aws:iam::111122223333:policy/KMS_Key_For_Encryption_On_EBS_Policy \
      --role-name AmazonEKS_EBS_CSI_DriverRole
  

Sau khi tạo xong IAM role, tiếp tục thêm EBS CSI driver add-on. Khi triển khai, nó sẽ tạo service account "ebs-csi-controller-sa" và gán các quyền Kubernetes cần thiết thông qua clusterrole.

Quản lý EBS CSI driver như EKS add-on

Quản lý dưới dạng add-on giúp cải thiện bảo mật và giảm công sức so với cài đặt tự quản lý.

Điều kiện tiên quyết:

• Có sẵn cluster EKS với phiên bản nền tảng yêu cầu

• Có OIDC provider cho cluster

• Có IAM role cho EBS CSI driver

• Cấp đủ quyền nếu sử dụng PodSecurityPolicy hạn chế toàn cluster

Để thêm EBS CSI driver add-on (dùng eksctl, AWS Console, AWS CLI):

• Chạy lệnh eksctl với tên cluster, ID tài khoản và IAM role đã tạo. Ví dụ: eksctl create addon --name aws-ebs-csi-driver --cluster my-cluster --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole --force

Cập nhật EBS CSI add-on:

• Kiểm tra phiên bản hiện tại và phiên bản cập nhật khả dụng: eksctl get addon --name aws-ebs-csi-driver --cluster my-cluster

• Cập nhật add-on lên phiên bản mới bằng eksctl: eksctl update addon --name aws-ebs-csi-driver --version v1.11.4-eksbuild.1 --cluster my-cluster --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole --force

Gỡ bỏ EBS CSI add-on:

• Giữ lại phần mềm add-on trên cluster: chuyển về cài đặt tự quản lý

• Gỡ bỏ hoàn toàn add-on khỏi cluster: chỉ nên làm nếu không có tài nguyên phụ thuộc

• Các lệnh eksctl, AWS Console, AWS CLI đều hỗ trợ gỡ bỏ. Ví dụ: eksctl delete addon --cluster my-cluster --name aws-ebs-csi-driver --preserve

Deploy 1 sample app và verify CSI driver hoạt động

• Triển khai ứng dụng mẫu sử dụng external snapshotter để tạo snapshot của volume. Để biết thêm chi tiết, xem "Volume Snapshots" trên GitHub.

• Triển khai ứng dụng mẫu có sử dụng tính năng thay đổi kích thước volume. Để biết thêm, xem "Volume Resizing" trên GitHub.

Ví dụ này sử dụng ví dụ "Dynamic volume provisioning" từ GitHub repository của Amazon EBS Container Storage Interface (CSI) driver để tạo một EBS volume theo cơ chế dynamic.

1. Clone GitHub repository của EBS CSI driver về hệ thống local:

    git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver.git
   

2. Di chuyển đến thư mục ví dụ dynamic-provisioning:

    cd aws-ebs-csi-driver/examples/kubernetes/dynamic-provisioning/
   

3. (Tùy chọn) File manifests/storageclass.yaml mặc định cung cấp volume EBS loại gp2. Để sử dụng gp3, thêm dòng type: gp3 vào file đó:

    echo "parameters:
      type: gp3" >> manifests/storageclass.yaml
   

4. Triển khai StorageClass ebs-sc, PersistentVolumeClaim ebs-claim và ứng dụng mẫu app từ thư mục manifests:

    kubectl apply -f manifests/
   

5. Describe StorageClass ebs-sc:

    kubectl describe storageclass ebs-sc
   

6. Lưu ý: StorageClass sử dụng chế độ gắn volume WaitForFirstConsumer. Nghĩa là volume chỉ được cung cấp động khi Pod tạo một PVC. Xem thêm tại "Volume Binding Mode" trong tài liệu K8s.

7. Theo dõi các Pod trong namespace default. Sau vài phút, trạng thái Pod app chuyển thành Running:

    kubectl get pods --watch
   

8. Liệt kê các PersistentVolume trong namespace default:

    kubectl get pv
   

   Chú ý PV có claim là default/ebs-claim.

9. Describe PersistentVolume đó:

    kubectl describe pv pvc-37717cd6-d0dc-11e9-b17f-06fad4858a5a
   

   Thay ID PV ở trên bằng giá trị ở bước trước. VolumeHandle trong kết quả chính là ID volume EBS.

10. Xác minh Pod đang ghi dữ liệu vào volume:

    kubectl exec -it app -- cat /data/out.txt
    

Sau khi hoàn tất, xóa các tài nguyên của ứng dụng mẫu này:

kubectl delete -f manifests/

Tóm tắt các điểm chính về tính năng chuyển đổi Amazon EBS Container Storage Interface (CSI) trên Amazon EKS:

• Tính năng CSI migration chuyển việc xử lý các thao tác lưu trữ từ EBS in-tree provisioner sang Amazon EBS CSI driver.

• CSI driver thay thế các in-tree storage driver trong mã nguồn K8s, hợp tác với storage provider như EBS, đơn giản hóa mô hình plugin.

• Trên EKS 1.23+, các cờ CSIMigration và CSIMigrationAWS được bật mặc định để dịch API in-tree sang CSI tương đương. Cần cài EBS CSI driver trước khi update lên 1.23.

• Vẫn có thể mount và tạo volume với StorageClass kiểu kubernetes.io/aws-ebs trên EKS 1.23+ miễn là đã cài EBS CSI driver. Nên cài driver này khi tạo cluster mới.

• Nên cài EBS CSI driver dạng EKS add-on để EKS quản lý việc update. Có thể tự cài bằng Helm chart.

• EKS sẽ không ngăn update lên 1.23 nếu chưa cài driver. Có thể cài sau update nhưng các thao tác volume sẽ lỗi cho đến khi cài xong.

• StorageClass mặc định trên EKS 1.23+ vẫn là gp2 dựa trên kubernetes.io/aws-ebs. Với ebs.csi.aws.com, kiểu mặc định là gp3.

• Có thể dùng annotation trong PVC để sửa đổi EBS volume từ bản aws-ebs-csi-driver v1.19.0-eksbuild.2 trở đi.

• Tính năng migration được hỗ trợ cho cả workload Windows.

Amazon EFS CSI driver

Amazon Elastic File System (Amazon EFS) và Amazon EFS Container Storage Interface (CSI) Driver

Amazon EFS CSI driver cung cấp giao diện CSI để Kubernetes cluster trên AWS quản lý vòng đời của hệ thống file Amazon EFS.

Lưu ý:

• Không tương thích với images Windows

• Không thể dùng dynamic provisioning cho persistent volumes với Fargate nodes, nhưng có thể dùng static provisioning

• Dynamic provisioning yêu cầu driver 1.2 trở lên

• Phiên bản 1.3.2 trở lên hỗ trợ kiến trúc Arm64

• Phiên bản 1.4.2 trở lên hỗ trợ FIPS

• Chú ý resource quota của Amazon EFS

Điều kiện tiên quyết:

• Tồn tại IAM OpenID Connect (OIDC) provider cho cluster

• AWS CLI phiên bản 2.12.3 trở lên hoặc 1.27.160 trở lên

• kubectl được cài đặt

Tạo IAM role:

Amazon EFS CSI driver cần quyền IAM để tương tác với file system. Có thể dùng eksctl, AWS Management Console, hoặc AWS CLI.

Ví dụ dùng eksctl:

export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
eksctl create iamserviceaccount \
    --name efs-csi-controller-sa \
    --namespace kube-system \
    --cluster $cluster_name \
    --role-name $role_name \
    --role-only \
    --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
    --approve
TRUST_POLICY=$(aws iam get-role --role-name $role_name --query 'Role.AssumeRolePolicyDocument' | \
    sed -e 's/efs-csi-controller-sa/efs-csi-*/' -e 's/StringEquals/StringLike/')
aws iam update-assume-role-policy --role-name $role_name --policy-document "$TRUST_POLICY"

Cài đặt Amazon EFS CSI Driver:

Nên cài đặt qua Amazon EKS add-on. Nếu không, có thể tự cài đặt bằng hướng dẫn trên GitHub.

Tạo Amazon EFS File System:

Xem hướng dẫn.

Triển khai ứng dụng mẫu:

Có thể triển khai ứng dụng mẫu và tùy chỉnh theo nhu cầu.

Amazon FSx cho Lustre CSI driver

FSx for Lustre CSI Driver trên Amazon EKS

FSx for Lustre CSI driver cho phép EKS cluster quản lý vòng đời của file system FSx for Lustre.

Điều kiện:

• AWS CLI phiên bản 2.12.3 trở lên hoặc 1.27.160 trở lên

• eksctl phiên bản 0.179.0 trở lên

• kubectl tương thích với phiên bản Kubernetes của cluster

Các bước:

1. Tạo cluster thử nghiệm:

    export cluster_name=my-csi-fsx-cluster
    export region_code=region-code
    eksctl create cluster \
      --name $cluster_name \
      --region $region_code \
      --with-oidc \
      --ssh-access \
      --ssh-public-key my-key
   

   Chú ý lưu lại tên của AWS CloudFormation stack được triển khai.

2. Tạo Kubernetes service account và gắn policy:

    eksctl create iamserviceaccount \
      --name fsx-csi-controller-sa \
      --namespace kube-system \
      --cluster $cluster_name \
      --attach-policy-arn arn:aws:iam::aws:policy/AmazonFSxFullAccess \
      --approve \
      --role-name AmazonEKSFSxLustreCSIDriverFullAccess \
      --region $region_code
   

   Chú ý lưu lại ARN của role được tạo ra.

3. Triển khai driver:

    kubectl apply -k "github.com/kubernetes-sigs/aws-fsx-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-X.XX"
   

   Thay release-X.XX bằng phiên bản mong muốn.

4. Patch driver deployment:

    kubectl annotate serviceaccount -n kube-system fsx-csi-controller-sa \
      eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/AmazonEKSFSxLustreCSIDriverFullAccess --overwrite=true
   

   Thay ARN bằng ARN đã lưu lại ở bước 2.

5. Tạo storage class, persistent volume claim và ứng dụng mẫu:

   • Lưu lại security group của cluster.

   • Tạo security group cho FSx for Lustre file system.

   • Tải và chỉnh sửa file storageclass.yaml (subnet, security group,...).

   • Tạo storage class: kubectl apply -f storageclass.yaml

   • Tải và chỉnh sửa file claim.yaml (nếu cần).

   • Tạo persistent volume claim: kubectl apply -f claim.yaml

   • Kiểm tra file system được provision: kubectl describe pvc

   • Triển khai ứng dụng mẫu: kubectl apply -fhttps://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml

   • Kiểm tra ứng dụng đang chạy: kubectl get pods

   • Kiểm tra file system được mount: kubectl exec -ti fsx-app -- df -h

   • Kiểm tra dữ liệu được ghi: kubectl exec -it fsx-app -- ls /data

Lưu ý: Xóa file system FSx for Lustre trước khi xóa cluster.

Amazon FSx cho NetApp ONTAP CSI driver

• Astra Trident của NetApp:

  • Cung cấp dynamic storage orchestration.

  • Sử dụng Container Storage Interface (CSI) compliant driver.

  • Cho phép cụm Amazon EKS quản lý vòng đời của persistent volumes (PVs).

  • PVs được hỗ trợ bởi hệ thống tập tin Amazon FSx cho NetApp ONTAP.

• Amazon FSx cho NetApp ONTAP:

  • Là dịch vụ lưu trữ cho phép khởi chạy và vận hành hệ thống tập tin ONTAP được quản lý hoàn toàn trong đám mây.

  • ONTAP là file system technology của NetApp.

  • Cung cấp một bộ tính năng truy cập và quản lý dữ liệu phổ biến.

  • FSx cho ONTAP mang lại các tính năng, hiệu suất và API của hệ thống tập tin NetApp on premises.

  • Được quản lý hoàn toàn như một dịch vụ AWS với sự linh hoạt, có khả năng mở rộng và đơn giản.

Để bắt đầu sử dụng, bạn có thể tham khảo tài liệu Use Astra Trident with Amazon FSx for NetApp ONTAP trong hướng dẫn của Astra Trident và FSx for ONTAP User Guide để biết thêm thông tin chi tiết.

Amazon FSx for OpenZFS CSI driver

• Amazon FSx for OpenZFS:

  • Dịch vụ lưu trữ tập tin được quản lý hoàn toàn, dễ dàng chuyển dữ liệu từ ZFS on premise hoặc các Linux-based file servers sang AWS.

  • Không cần thay đổi mã ứng dụng hoặc cách quản lý dữ liệu.

  • File storage service đáng tin cậy, có thể mở rộng, hiệu quả, dựa trên open-source OpenZFS file system.

  • Kết hợp khả năng quản lý dữ liệu với sự linh hoạt, khả năng mở rộng và đơn giản của dịch vụ AWS được quản lý hoàn toàn.

• Amazon FSx for OpenZFS CSI Driver:

  • Cung cấp giao diện CSI cho phép các cụm Amazon EKS quản lý vòng đời của các tập tin lưu trữ OpenZFS.

  • Để triển khai trình điều khiển CSI cho Amazon FSx for OpenZFS vào cụm Amazon EKS của bạn, xem aws-fsx-openzfs-csi-driver trên GitHub.

Để biết thêm thông tin chi tiết, bạn có thể tham khảo Hướng dẫn Sử dụng FSx for OpenZFS.

Amazon File Cache CSI driver

• Amazon File Cache:

  • Là bộ nhớ đệm tốc độ cao, được quản lý hoàn toàn trên AWS.

  • Dùng để xử lý dữ liệu tập tin, không phụ thuộc vào vị trí lưu trữ dữ liệu.

  • Tự động tải dữ liệu vào bộ nhớ đệm khi truy cập lần đầu và giải phóng dữ liệu khi không sử dụng.

• Amazon File Cache CSI Driver:

  • Cung cấp giao diện CSI cho phép các cụm Amazon EKS quản lý vòng đời của bộ nhớ đệm tập tin Amazon.

  • Để triển khai trình điều khiển CSI cho Amazon File Cache vào cụm Amazon EKS của bạn, xem aws-file-cache-csi-driver trên GitHub.

Để biết thêm thông tin chi tiết, bạn có thể tham khảo Hướng dẫn Sử dụng Amazon File Cache.

Mountpoint cho Amazon S3 CSI driver

Mountpoint for Amazon S3 CSI Driver trên Amazon EKS

Driver này cho phép ứng dụng Kubernetes truy cập đối tượng Amazon S3 như file system.

Lưu ý:

• Không hỗ trợ image Windows và AWS Fargate.

• Chỉ hỗ trợ static provisioning.

Cài đặt:

1. Tạo IAM policy:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "MountpointFullBucketAccess",
                "Effect": "Allow",
                "Action": ["s3:ListBucket"],
                "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET1"]
            },
            {
                "Sid": "MountpointFullObjectAccess",
                "Effect": "Allow",
                "Action": ["s3:GetObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:DeleteObject"],
                "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*"]
            }
        ]
    }
   

   (Thay DOC-EXAMPLE-BUCKET1 bằng tên bucket của bạn)

2. Tạo IAM role:

   Bash

    CLUSTER_NAME=my-cluster
    REGION=region-code
    ROLE_NAME=AmazonEKS_S3_CSI_DriverRole
    POLICY_ARN=AmazonEKS_S3_CSI_DriverRole_ARN
    eksctl create iamserviceaccount \
        --name s3-csi-driver-sa \
        --namespace kube-system \
        --cluster $CLUSTER_NAME \
        --attach-policy-arn $POLICY_ARN \
        --approve \
        --role-name $ROLE_NAME \
        --region $REGION \
        --role-only
   

3. Cài đặt driver:

    eksctl create addon --name aws-mountpoint-s3-csi-driver --cluster my-cluster --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole --force
   

Xóa driver (nếu cần):

eksctl delete addon --cluster my-cluster --name aws-mountpoint-s3-csi-driver --preserve

CSI snapshot controller

• CSI Snapshot Controller:

  • Cho phép chức năng snapshotting trong các CSI drivers tương thích.

  • Cần được cài đặt cùng với tCSI driver có chức năng snapshotting.

• Amazon EBS CSI Driver:

  • Hỗ trợ tạo snapshot của các volume Amazon EBS được quản lý bởi Amazon EBS CSI.

  • Cần có StorageClass tham chiếu đến trình điều khiển CSI, ebs.csi.aws.com, để hỗ trợ snapshot.

• Cài đặt:

  • Khuyến nghị cài đặt CSI snapshot controller thông qua add-on được quản lý bởi Amazon EKS.

  • Đối với cài đặt tự quản lý, xem hướng dẫn sử dụng trong Kubernetes external-snapshotter.

• Lưu ý:

  • Kubernetes không hỗ trợ snapshotting cho các volume được serve thông qua CSI migration, như các volume Amazon EBS với StorageClass có provisioner kubernetes.io/aws-ebs.

  • Các volume phải được tạo ra với một StorageClass tham chiếu đến CSI driver provisioner: ebs.csi.aws.com.

Cluster management

Cost monitoring

Amazon EKS cung cấp hai giải pháp giám sát chi phí:

1. AWS Billing split cost allocation data cho Amazon EKS:

   • Tích hợp với AWS Billing Console.

   • Phân tích và phân bổ chi phí dựa trên CPU và bộ nhớ EC2 được sử dụng bởi ứng dụng Kubernetes.

   • Xem chi phí theo Pod, namespace, cluster và các Kubernetes primitives khác.

2. Kubecost:

   • Công cụ giám sát chi phí Kubernetes.

   • Phân tích chi phí chi tiết theo tài nguyên Kubernetes.

   • Đề xuất tối ưu hóa chi phí.

   • Tích hợp với AWS Cost and Usage Report để lấy dữ liệu giá chính xác.

   • Có phiên bản tùy chỉnh tối ưu cho AWS.

Cài đặt Kubecost:

1. Xác định phiên bản Kubecost từ Amazon ECR Public Gallery.

2. Chạy lệnh:

    helm upgrade -i kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version kubecost-version \
        --namespace kubecost --create-namespace \
        -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml
   

   (Thay kubecost-version bằng phiên bản đã chọn)

3. Kiểm tra pods: kubectl get pods -n kubecost

4. Mở cổng 9090 để truy cập dashboard: kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

Gỡ cài đặt Kubecost:

helm uninstall kubecost --namespace kubecost
kubectl delete ns kubecost

Metrics server

• Kubernetes Metrics Server:

  • Là một bộ tổng hợp dữ liệu sử dụng tài nguyên trong cụm.

  • Không được triển khai mặc định trong cụm Amazon EKS.

  • Thường được sử dụng bởi các tiện ích mở rộng khác của Kubernetes như Horizontal Pod Autoscaler hoặc Kubernetes Dashboard.

• Quan trọng:

  • Metrics chỉ dành cho phân tích tại thời điểm và không phải là nguồn chính xác cho phân tích lịch sử.

  • Không thể sử dụng làm giải pháp giám sát hoặc cho mục đích non-auto scaling.

  • Để biết thông tin về các công cụ giám sát, xem Observability in Amazon EKS.

• Triển khai Metrics Server:

  • Sử dụng câu lệnh sau để triển khai Metrics Server:

      kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
    

  • Nếu bạn sử dụng Fargate, bạn cần thay đổi file này. Trong cấu hình mặc định, metrics server sử dụng cổng 10250, cổng này reserved trên Fargate. Thay thế các tham chiếu đến cổng 10250 trong components.yaml bằng cổng khác, ví dụ 10251.

• Verify triển khai:

  • Sử dụng câu lệnh sau để kiểm tra xem triển khai metrics-server có đang chạy số lượng Pods mong muốn hay không:

      kubectl get deployment metrics-server -n kube-system
    

Sử dụng Helm với EKS

Windows (Chocolatey):

choco install kubernetes-helm

Linux:

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
chmod 700 get_helm.sh
./get_helm.sh

(Nếu cần, cài đặt openssl trước: sudo yum install openssl)

Kiểm tra phiên bản:

helm version | cut -d + -f 1

Lưu ý quan trọng:

• Cấu hình kubectl cho Amazon EKS trước khi cài Helm chart.

• Tham khảo hướng dẫn chi tiết trên trang tài liệu Helm.

Sau khi cài đặt, bạn có thể dùng các lệnh Helm để quản lý ứng dụng trên Kubernetes cluster.

Tagging EKS resources

Tag là nhãn bạn gán cho tài nguyên AWS để phân loại và quản lý chúng dễ dàng hơn.

Khái niệm cơ bản:

• Cấu trúc: key-value (giá trị tùy chọn).

• Mục đích: Phân loại tài nguyên theo mục đích, chủ sở hữu, môi trường,...

• Hành động: Thêm, sửa, xóa tag bất cứ lúc nào.

• Không có ý nghĩa ngữ nghĩa đối với Amazon EKS, chỉ là chuỗi ký tự.

Cách thêm tag:

• Amazon EKS console: Dùng tab "Tags" trên resource's page.

• eksctl: Dùng tùy chọn --tags khi tạo tài nguyên.

• AWS CLI/API/SDK: Dùng tham số tags hoặc API TagResource.

Lưu ý:

• Tag không tự động lan truyền sang các tài nguyên liên quan.

• Giới hạn 50 tag cho mỗi tài nguyên.

• Không dùng tiền tố aws: hoặc AWS:.

Tagging cho mục đích thanh toán:

• Sử dụng tag để phân bổ chi phí trong Cost & Usage Reports.

• Tag aws:eks:cluster-name giúp chia nhỏ chi phí EC2 theo từng cluster EKS (không bao gồm chi phí control plane).

Làm việc với tag:

• Console: Thêm/xóa tag trực tiếp từ trang tài nguyên.

• CLI/API/eksctl:

  • aws eks tag-resource: Thêm/ghi đè tag.

  • aws eks untag-resource: Xóa tag.

  • aws eks list-tags-for-resource: Liệt kê tag.

Ví dụ CLI:

aws eks tag-resource --resource-arn resource_ARN --tags team=devs  # Thêm tag
aws eks untag-resource --resource-arn resource_ARN --tag-keys tag_key  # Xóa tag
aws eks list-tags-for-resource --resource-arn resource_ARN  # Liệt kê tag

EKS service quotas

Amazon EKS tích hợp với Service Quotas để xem và quản lý quota sử dụng dịch vụ.

Xem quota: Sử dụng AWS Management Console hoặc AWS CLI

• AWS CLI:

  • EKS: aws service-quotas list-aws-default-service-quotas --query 'Quotas[*].{Adjustable:Adjustable,Name:QuotaName,Value:Value,Code:QuotaCode}' --service-code eks --output table

  • Fargate: aws service-quotas list-aws-default-service-quotas --query 'Quotas[*].{Adjustable:Adjustable,Name:QuotaName,Value:Value,Code:QuotaCode}' --service-code fargate --output table

Quota AWS Fargate:

• Fargate On-Demand vCPU resource count: Số lượng vCPU Fargate có thể chạy đồng thời ở chế độ On-Demand (có thể điều chỉnh).

Lưu ý:

• Các giá trị mặc định là quota ban đầu được AWS đặt, khác với quota thực tế được áp dụng và quota tối đa có thể có.

• Fargate còn áp dụng quota tốc độ khởi chạy task Amazon ECS và Pod Amazon EKS.

• Có thể yêu cầu tăng quota cho các giá trị được đánh dấu là "Adjustable".

Bài tập

1. Tạo một managed node group trong cluster EKS của bạn.

2. Triển khai một ứng dụng yêu cầu lưu trữ liên tục.

3. Thử nghiệm với các loại volume EBS khác nhau.

Để giải bài tập, cần thực hiện các bước sau

1. Tạo Managed Node Group trong Cluster EKS:

   • Đảm bảo rằng cluster EKS đang ở trạng thái ACTIVE.

   • Sử dụng Amazon EKS console, eksctl, AWS CLI, AWS API, hoặc công cụ mã hóa cơ sở hạ tầng như AWS CloudFormation để thêm managed node group.

   • Cài đặt và cấu hình IAM role cho nodes và cấu hình Amazon VPC CNI plugin cho Kubernetes nếu cần.

2. Triển khai Ứng Dụng Yêu Cầu Lưu Trữ:

   • Tạo PersistentVolume (PV) và PersistentVolumeClaim (PVC) để cung cấp lưu trữ cho ứng dụng.

   • Định nghĩa và triển khai Pods hoặc Deployments trong Kubernetes sử dụng PVC đã tạo để đảm bảo lưu trữ dữ liệu.

3. Thử Nghiệm với Các Loại Volume EBS Khác Nhau:

   • Tìm hiểu và so sánh các loại volume EBS như gp2, gp3, io1, io2, và st1 dựa trên yêu cầu về hiệu suất và chi phí của ứng dụng.

   • Thực hiện thử nghiệm bằng cách tạo các PV với các loại volume EBS khác nhau và gắn chúng vào Pods để đánh giá hiệu suất.

Bước 1: Tạo IAM Role cho Cluster EKS

Tạo IAM Trust Policy:

Tạo một file JSON cho IAM trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Lưu file này với tên eks-cluster-role-trust-policy.json.

Tạo IAM Role:

Chạy lệnh sau để tạo IAM role với trust policy:

aws iam create-role --role-name EKS-Cluster-Role --assume-role-policy-document file://eks-cluster-role-trust-policy.json

Gắn các policy cần thiết cho role này, chẳng hạn như AmazonEKSClusterPolicy:

aws iam attach-role-policy --role-name EKS-Cluster-Role --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Bước 2: Tạo Cluster EKS

Sử dụng eksctl hoặc AWS CLI để tạo cluster. Ví dụ sử dụng eksctl:

eksctl create cluster --name YourCluster --region ap-southeast-1 --version 1.29 --without-nodegroup

Đảm bảo bạn đã cài đặt eksctl và cấu hình AWS CLI với quyền IAM phù hợp.

Bước 3: Tạo Managed Node Group

Tạo managed Node Group: nodegroup-config.yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: YourCluster
  region: ap-southeast-1

managedNodeGroups:
  - name: YourManagedNodeGroup
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 4
    volumeSize: 80
    labels: 
      role: workers
    iam:
      withAddonPolicies:
        autoScaler: true
    privateNetworking: true

eksctl create nodegroup --config-file=nodegroup-config.yaml

Kết quả của câu lệnh trên sẽ có dạng như sau:

[ssm-user@ip-172-31-44-127 ~]$ eksctl create nodegroup --config-file=nodegroup-config.yaml
2024-05-27 11:01:56 [ℹ]  will use version 1.29 for new nodegroup(s) based on control plane version
2024-05-27 11:01:57 [ℹ]  nodegroup "YourManagedNodeGroup" will use "" [AmazonLinux2/1.29]
2024-05-27 11:01:57 [ℹ]  1 existing nodegroup(s) (YourNodeGroupName) will be excluded2024-05-27 11:01:57 [ℹ]  1 nodegroup (YourManagedNodeGroup) was included (based on the include/exclude rules)2024-05-27 11:01:57 [ℹ]  will create a CloudFormation stack for each of 1 managed nodegroups in cluster "YourCluster"
2024-05-27 11:01:57 [ℹ]2 sequential tasks: { fix cluster compatibility, 1 task: { 1 task: { create managed nodegroup "YourManagedNodeGroup" } }
}
2024-05-27 11:01:57 [ℹ]  checking cluster stack for missing resources
2024-05-27 11:01:57 [ℹ]  cluster stack has all required resources
2024-05-27 11:01:57 [ℹ]  building managed nodegroup stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:01:58 [ℹ]  deploying stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:01:58 [ℹ]  waiting for CloudFormation stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:02:28 [ℹ]  waiting for CloudFormation stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:03:06 [ℹ]  waiting for CloudFormation stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:04:25 [ℹ]  waiting for CloudFormation stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:05:49 [ℹ]  waiting for CloudFormation stack "eksctl-YourCluster-nodegroup-YourManagedNodeGroup"
2024-05-27 11:05:49 [ℹ]  no tasks
2024-05-27 11:05:49 [✔]  created 0 nodegroup(s) in cluster "YourCluster"
2024-05-27 11:05:49 [ℹ]  nodegroup "YourManagedNodeGroup" has 2 node(s)
2024-05-27 11:05:49 [ℹ]  node "ip-192-168-110-229.ap-southeast-1.compute.internal" is ready
2024-05-27 11:05:49 [ℹ]  node "ip-192-168-184-204.ap-southeast-1.compute.internal" is ready2024-05-27 11:05:49 [ℹ]  waiting for at least 1 node(s) to become ready in "YourManagedNodeGroup"
2024-05-27 11:05:49 [ℹ]  nodegroup "YourManagedNodeGroup" has 2 node(s)
2024-05-27 11:05:49 [ℹ]  node "ip-192-168-110-229.ap-southeast-1.compute.internal" is ready
2024-05-27 11:05:49 [ℹ]  node "ip-192-168-184-204.ap-southeast-1.compute.internal" is ready
2024-05-27 11:05:49 [✔]  created 1 managed nodegroup(s) in cluster "YourCluster"
2024-05-27 11:05:49 [ℹ]  checking security group configuration for all nodegroups
2024-05-27 11:05:49 [ℹ]  all nodegroups have up-to-date cloudformation templates

Trên console:

Kiểm tra:

aws eks --region ap-southeast-1 update-kubeconfig --name YourCluster
eksctl get nodegroup --cluster YourCluster
kubectl get nodes
kubectl get pods -A

Bước 4: Cài đặt AWS EBS CSI Driver

Tạo IAM Policy cho CSI Driver:

Tạo một file JSON cho IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AttachVolume",
        "ec2:CreateSnapshot",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:DeleteSnapshot",
        "ec2:DeleteTags",
        "ec2:DeleteVolume",
        "ec2:DescribeInstances",
        "ec2:DescribeSnapshots",
        "ec2:DescribeTags",
        "ec2:DescribeVolumes",
        "ec2:DetachVolume"
      ],
      "Resource": "*"
    }
  ]
}

Lưu file này với tên ebs-csi-driver-policy.json.

Tạo IAM Policy:

aws iam create-policy --policy-name AmazonEKS_EBS_CSI_Driver_Policy --policy-document file://ebs-csi-driver-policy.json

Gắn IAM Policy vào IAM Role của Node Group:

Tìm node group role name:

aws eks describe-nodegroup --cluster-name YourCluster --nodegroup-name YourManagedNodeGroup

Tìm thông tin: nodeRole để biết role name

aws iam attach-role-policy --policy-arn arn:aws:iam::<your-account-id>:policy/AmazonEKS_EBS_CSI_Driver_Policy --role-name <NodeInstanceRoleName>

Cài đặt AWS EBS CSI Driver:

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.16"

Kiểm tra xem CSI Driver đã được cài đặt thành công hay chưa:

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver

Kết quả trả về:

[ssm-user@ip-172-31-44-127 ~]$ kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver
NAME                                 READY   STATUS    RESTARTS   AGE
ebs-csi-controller-7797fb9b6-n9ql2   6/6     Running   0          29s
ebs-csi-controller-7797fb9b6-t7ccf   6/6     Running   0          29s
ebs-csi-node-2srvm                   3/3     Running   0          29s
ebs-csi-node-5469c                   3/3     Running   0          29s

Bước 7: Tạo và Gắn EBS Volume Tự Động bằng PVC

Tạo StorageClass:

Tạo một file YAML (ví dụ: gp3-storage-class.yaml) với nội dung sau:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer

Áp dụng file YAML để tạo StorageClass:

kubectl apply -f gp3-storage-class.yaml

Tạo PVC (Persistent Volume Claim):

Tạo một file YAML (ví dụ: YourClusterPVC.yaml) với nội dung sau:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: yourclusterpvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: gp3

Áp dụng file YAML để tạo PVC:

kubectl apply -f YourClusterPVC.yaml

Bước 8: Triển khai Ứng Dụng với PVC

Tạo một file YAML cho ứng dụng của bạn sử dụng PVC:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: yourappname
spec:
  selector:
    matchLabels:
      app: yourappname
  template:
    metadata:
      labels:
        app: yourappname
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - mountPath: "/data"
          name: yourclusterpv
      volumes:
      - name: yourclusterpv
        persistentVolumeClaim:
          claimName: yourclusterpvc

Áp dụng file YAML để triển khai ứng dụng:

kubectl apply -f app-with-pv.yaml

Kiểm tra trạng thái của pod:

kubectl get pods

Bạn sẽ thấy pod ở trạng thái "Running".

Bước 9: Kiểm tra Hiệu năng của EBS Volume

Trên pod đang chạy, cài đặt công cụ fio để kiểm tra hiệu năng:

Tạo một pod để kiểm tra hiệu năng:

apiVersion: v1
kind: Pod
metadata:
  name: fio-test
spec:
  containers:
  - name: fio
    image: xridge/fio
    command: ["sleep", "3600"]  # Sleep for 3600 seconds (1 hour)
    volumeMounts:
    - mountPath: "/data"
      name: yourclusterpv
  volumes:
  - name: yourclusterpv
    persistentVolumeClaim:
      claimName: yourclusterpvc

Áp dụng file YAML để tạo pod kiểm tra:

kubectl apply -f fio-test.yaml

Kiểm tra trạng thái của pod kiểm tra:

kubectl get pods

Đăng nhập vào pod kiểm tra:

kubectl exec -it fio-test -- /bin/sh

Chạy lệnh sau để kiểm tra hiệu năng ghi ngẫu nhiên:

fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=1G --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --directory=/data

Kết quả dạng như sau:

/data # fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=1G --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --directory=/data
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.13
Starting 1 process
random-write: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=26: Mon May 27 11:43:56 2024
  write: IOPS=7778, BW=30.4MiB/s (31.9MB/s)(2048MiB/67398msec); 0 zone resets
    slat (usec): min=25, max=20557, avg=77.45, stdev=187.39
    clat (nsec): min=214, max=19345k, avg=10547.51, stdev=78455.82
     lat (usec): min=35, max=20559, avg=87.99, stdev=208.10
    clat percentiles (nsec):
     |  1.00th=[    346],  5.00th=[    362], 10.00th=[    378],
     | 20.00th=[    426], 30.00th=[    540], 40.00th=[    580],
     | 50.00th=[    636], 60.00th=[   1752], 70.00th=[  10048],
     | 80.00th=[  15808], 90.00th=[  19328], 95.00th=[  24960],
     | 99.00th=[  91648], 99.50th=[ 162816], 99.90th=[ 700416],
     | 99.95th=[1204224], 99.99th=[3555328]
   bw (  KiB/s): min=11680, max=58112, per=100.00%, avg=43681.62, stdev=7331.20, samples=96
   iops        : min= 2920, max=14528, avg=10920.39, stdev=1832.80, samples=96
  lat (nsec)   : 250=0.01%, 500=27.05%, 750=28.68%, 1000=2.02%
  lat (usec)   : 2=4.12%, 4=0.78%, 10=7.21%, 20=21.20%, 50=6.82%
  lat (usec)   : 100=1.23%, 250=0.55%, 500=0.16%, 750=0.08%, 1000=0.03%
  lat (msec)   : 2=0.04%, 4=0.02%, 10=0.01%, 20=0.01%
  cpu          : usr=8.52%, sys=35.76%, ctx=762331, majf=0, minf=524306
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,524289,0,1 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=2048MiB (2147MB), run=67398-67398msec

Disk stats (read/write):
  nvme1n1: ios=2/239639, merge=0/3307, ticks=2/645014, in_queue=645015, util=88.02%
/data #

Chạy lệnh sau để kiểm tra hiệu năng đọc ngẫu nhiên:

fio --name=random-read --ioengine=posixaio --rw=randread --bs=4k --size=1G --numjobs=1 --iodepth=1 --runtime=60 --time_based --directory=/data

Giải thích kết quả và lệnh:

Lệnh fio và các tùy chọn

Lệnh bạn đã sử dụng:

fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=1G --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --directory=/data

• --name=random-write: Đặt tên cho job là random-write.

• --ioengine=posixaio: Sử dụng POSIX AIO (Asynchronous I/O) làm công cụ I/O.

• --rw=randwrite: Thực hiện các thao tác ghi ngẫu nhiên.

• --bs=4k: Đặt kích thước block là 4KB.

• --size=1G: Tổng dung lượng dữ liệu để ghi là 1GB.

• --numjobs=1: Chạy 1 job cho mỗi thread.

• --iodepth=1: Độ sâu hàng đợi I/O là 1.

• --runtime=60: Thực hiện kiểm tra trong 60 giây.

• --time_based: Dựa trên thời gian (runtime), không phải dung lượng.

• --end_fsync=1: Đảm bảo tất cả dữ liệu được ghi vào đĩa (sync) khi kết thúc.

• --directory=/data: Đường dẫn tới thư mục để thực hiện kiểm tra I/O.

Kết quả

• IOPS=7778: Số I/O operations per second (IOPS), trung bình 7778 IOPS.

• BW=30.4MiB/s (31.9MB/s): Băng thông ghi, trung bình 30.4 MiB/s hoặc 31.9 MB/s.

• slat (usec): Submission latency, độ trễ của việc gửi yêu cầu I/O.

  • min=25, max=20557, avg=77.45, stdev=187.39: Độ trễ nhỏ nhất, lớn nhất, trung bình và độ lệch chuẩn (standard deviation).

• clat (nsec): Completion latency, độ trễ hoàn thành I/O.

  • min=214, max=19345k, avg=10547.51, stdev=78455.82: Tương tự như trên, nhưng đơn vị là nanosecond (ns).

• lat (usec): Tổng độ trễ, tính bằng microsecond (us).

  • min=35, max=20559, avg=87.99, stdev=208.10: Độ trễ nhỏ nhất, lớn nhất, trung bình và độ lệch chuẩn.

• clat percentiles (nsec): Phân vị độ trễ hoàn thành (completion latency percentiles).

  • Ví dụ, 1% độ trễ hoàn thành là 346 ns, 5% là 362 ns, v.v.

• bw (KiB/s): Băng thông (bandwidth) theo KB/s.

  • min=11680, max=58112, per=100.00%, avg=43681.62, stdev=7331.20: Băng thông nhỏ nhất, lớn nhất, trung bình và độ lệch chuẩn.

• iops: Số IOPS, tương tự như trên nhưng chi tiết hơn theo từng mẫu (sample).

• lat (nsec), lat (usec), lat (msec): Phân tích độ trễ chi tiết theo nanosecond, microsecond, và millisecond.

• cpu: Sử dụng CPU.

  • usr=8.52%, sys=35.76%: Sử dụng CPU của user và system.

  • ctx=762331: Số lần chuyển ngữ cảnh (context switches).

  • majf=0, minf=524306: Số lần page faults chính và phụ.

• IO depths: Độ sâu I/O (I/O depth).

  • 1=100.0%: 100% các I/O có độ sâu là 1.

• submit: Phân phối độ trễ khi gửi yêu cầu I/O.

  • 0=0.0%, 4

\=100.0%: 100% các yêu cầu được gửi ngay lập tức (trong 4 ns).

• complete: Phân phối độ trễ khi hoàn thành I/O.

  • 0=0.0%, 4=100.0%: 100% các I/O hoàn thành trong 4 ns.

• issued rwts: Tổng số yêu cầu đọc (r), ghi (w), trim (t), sync (s) đã phát ra.

  • total=0,524289,0,1: Không có yêu cầu đọc, 524289 yêu cầu ghi, không có trim, 1 yêu cầu sync.

• latency: Phân tích độ trễ chi tiết.

Tóm tắt

• WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=2048MiB (2147MB), run=67398-67398msec: Tóm tắt về băng thông ghi, trung bình 30.4 MiB/s (31.9 MB/s) với tổng 2048 MiB ghi trong 67398 ms.

• Disk stats (read/write): Thống kê đĩa.

  • nvme1n1: ios=2/239639, merge=0/3307, ticks=2/645014, in_queue=645015, util=88.02%: Thống kê I/O của thiết bị nvme1n1.

Bước 10: Dọn dẹp tài nguyên

• Xoá các cloudformation template

• Xoá các IAM role, policy đã tạo