AWS Study Group

Đơn giản hóa quản lý cụm Kubernetes bằng ACK, kro và Amazon EKS

Tác giả: Islam Mahgoub, Kumudhan Cherarajan, Markos Kandylis, Ramesh Mathikumar, and Sébastien Allamand
Ngày phát hành: 22 JAN 2026
Chuyên mục: Amazon Elastic Kubernetes Service, Containers, Expert (400)

Khi các tổ chức mở rộng việc áp dụng Kubernetes cho ngày càng nhiều trường hợp sử dụng, số lượng quy trình vận hành liên quan đến việc cung cấp và vận hành các cụm Kubernetes cũng tăng theo. Quá trình tạo một cụm, khởi động nó với các add-on dành riêng cho tổ chức, và sau đó quản lý nó theo thời gian là phức tạp và dễ xảy ra lỗi. Thông thường, các tác vụ này liên quan đến việc sử dụng hỗn hợp các pipeline Infrastructure as Code (IaC) rời rạc, Kubernetes manifests và Helm charts, điều này thường dẫn đến thời gian tạo cụm mới kéo dài, tăng chi phí vận hành để quản lý cụm và rủi ro thất bại hoặc thời gian ngừng hoạt động cao hơn.

Trong bài đăng này, chúng tôi sẽ trình bày cách tạo và quản lý một đội hình các cụm Amazon Elastic Kubernetes Service (Amazon EKS) bằng cách sử dụng Kube Resource Orchestrator (kro), AWS Controllers for Kubernetes (ACK), và Argo CD. Các công cụ này cho phép bạn triển khai giải pháp quản lý cụm dựa trên GitOps để tăng năng suất và cải thiện tính nhất quán, tiêu chuẩn hóa bằng cách sử dụng Kubernetes API cho các hoạt động từ đầu đến cuối.

Tổng quan giải pháp

ACK là một công cụ cho phép bạn quản lý các tài nguyên AWS trực tiếp từ Kubernetes bằng cách sử dụng các cấu trúc YAML khai báo quen thuộc – nó là một tập hợp các custom resource definitions (CRD) của Kubernetes và các custom controller hoạt động cùng nhau để mở rộng Kubernetes API và quản lý các tài nguyên AWS thay mặt bạn. Sau khi một ACK service controller được cài đặt, người dùng Kubernetes có thể tạo một Custom Resource (CR) tương ứng với một trong các tài nguyên được controller này cung cấp để tạo một tài nguyên AWS.

Trong giải pháp được mô tả trong bài đăng này, chúng tôi sử dụng các ACK controller để tạo các tài nguyên AWS cần thiết cho một cụm EKS. Bằng cách đó, chúng tôi cho phép quản lý cụm thông qua Kubernetes API và loại bỏ nhu cầu sử dụng một công cụ IaC riêng biệt và xây dựng một pipeline riêng biệt cho trường hợp sử dụng này. Ngoài ra, cách tiếp cận này cho phép xây dựng một luồng GitOps để quản lý cụm bằng các công cụ như Argo CD.

Tuy nhiên, có một số thách thức liên quan đến cách tiếp cận này:

  • Để tạo một cụm EKS, bạn cần cung cấp một số tài nguyên AWS, bao gồm virtual private cloud (VPC), subnets, route tables, NAT gateways, một IAM role cho cụm, một IAM role cho node và bản thân cụm EKS.
  • Các tài nguyên AWS này có sự phụ thuộc lẫn nhau. Ví dụ, VPC cần được tạo trước các subnets, và các IAM role của cụm phải được tạo trước bản thân cụm EKS. Để tính đến các phụ thuộc này, bạn cần áp dụng các CR theo một thứ tự cụ thể. Đầu tiên, bạn áp dụng các CR cho các IAM role của cụm và đợi chúng đồng bộ. Sau đó, bạn có thể áp dụng các CR cho bản thân cụm EKS. Điều này đảm bảo các điều kiện tiên quyết cần thiết đã được thiết lập trước khi tạo cụm.
  • Ngoài ra, bạn cần trích xuất các trường được tạo ra từ các CR và sử dụng thông tin đó làm đầu vào cho các CR phụ thuộc. Ví dụ, bạn phải trích xuất VPC ID từ VPC CR và sau đó cung cấp nó làm đầu vào cho Subnet CR.

Với các mối liên hệ phụ thuộc và yêu cầu theo thứ tự được nêu bật ở trên, rõ ràng là việc tạo các tài nguyên AWS của cụm EKS bằng cách áp dụng các Custom Resources (CR) tương ứng đòi hỏi một cách tiếp cận được điều phối tốt.

kro (mà chúng tôi phát âm là “crow”) cung cấp một lớp trừu tượng xử lý tất cả các phụ thuộc và thứ tự cấu hình của các tài nguyên của bạn, sau đó tạo và quản lý các tài nguyên bạn cần. Khái niệm ResourceGraphDefinition (RGD) của kro cung cấp một cách dễ dàng để tạo một Custom Resource Definition (CRD) bao gồm tất cả các tài nguyên AWS và Kubernetes cần thiết cho một cụm hoạt động đầy đủ (ví dụ: VPC, Subnets, IAM roles, cụm EKS, v.v.). RGD cho phép kro controller theo dõi các phụ thuộc tài nguyên và áp dụng tài nguyên phù hợp. Với kro, bạn có thể sử dụng Common Expression Language (CEL) để trích xuất các trường được tạo ra từ tài nguyên (ví dụ: vpcID trong trường hợp VPC CR) và chuyển nó cho các tài nguyên khác.

Sơ đồ sau đây mô tả kiến trúc giải pháp:

  • Các ACK controller được sử dụng để tạo các tài nguyên AWS.
  • kro điều phối việc tạo và phụ thuộc của các tài nguyên ACK.
  • Argo CD được sử dụng làm GitOps controller sẽ khởi động cụm quản lý, cung cấp các cụm workload và các add-on tương ứng.
Sơ đồ kiến trúc giải pháp sử dụng ACK, kro và Argo CD để quản lý cụm Kubernetes.

Trong giải pháp này, chúng tôi sử dụng Amazon EKS Capabilities cung cấp trải nghiệm được quản lý hoàn toàn cho ACK, kro và Argo CD. Nó loại bỏ nhu cầu cài đặt, bảo trì và mở rộng các công cụ này.

Trong các phần sau, chúng tôi sẽ giải thích các phần chính của giải pháp.

Tạo ResourceGraphDefinitions bao gồm các tài nguyên AWS để tạo cụm EKS.

CRD ResourceGraphDefinition là một khối xây dựng cơ bản trong kro. Nó cung cấp một cách để định nghĩa, tổ chức và quản lý các tập hợp tài nguyên Kubernetes được kết nối với nhau như một đơn vị duy nhất, có thể tái sử dụng. kro sử dụng cú pháp thân thiện với con người, dễ đọc và tương thích với OpenAPI để định nghĩa RGD. Ở trên cùng, chúng ta có phần schema chỉ định giao diện của CRD mới được định nghĩa bởi RGD. Sau đó, chúng ta có phần resources chỉ định các tài nguyên cần được kro áp dụng khi một instance của RGD đó được tạo trong cụm.

Hãy xem xét RGD cho một cụm EKS để hiểu rõ hơn về khái niệm này.

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: eksclusterbasic.kro.run
spec:
  schema:
    apiVersion: v1alpha1
    kind: EksClusterBasic
    spec:
      name: string
      region: string
      k8sVersion: string
      network:
      ... (removed for brevity)
  resources:
    - id: clusterRole
      ... (removed for brevity)
    - id: nodeRole
      ... 
    - id: ekscluster 
      template:
        apiVersion: eks.services.k8s.aws/v1alpha1
        kind: Cluster
        metadata:
          namespace: "${schema.spec.name}"
          name: "${schema.spec.name}"
        spec:
          name: "${schema.spec.name}"
          roleARN: "${clusterRole.status.ackResourceMetadata.arn}"
          version: "${schema.spec.k8sVersion}"
          accessConfig:
             ... 
          computeConfig:
            nodeRoleARN: ${nodeRole.status.ackResourceMetadata.arn}
            ... 
          ...

Để biết thêm chi tiết về cú pháp này, hãy tham khảo Simple Schema trong tài liệu kro.

Một trong những khả năng của kro là kết hợp bất kỳ tài nguyên Kubernetes nào có thể được chấp nhận vào cụm của bạn trong một RGD. Điều này bao gồm việc kết hợp các instance của các RGD hiện có khác, cho phép tạo một hệ thống phân cấp các RGD.

Các cụm EKS yêu cầu một VPC và các tài nguyên mạng khác làm cơ sở hạ tầng lưu trữ của chúng. Có hai kịch bản phổ biến: tạo một cụm EKS trong một VPC hiện có hoặc tạo một EKS cùng với VPC lưu trữ nó.

Để hỗ trợ hai kịch bản này, chúng tôi tạo ba RGD riêng biệt – một cho các tài nguyên mạng (VPC, Subnets, v.v.) được gọi là Vpc, một cho bản thân cụm EKS được gọi là EksClusterBasic, và cuối cùng là một RGD bao quát được gọi là EksCluster được tạo thành từ các instance của RGD Vpc và EksClusterBasic. RGD EksCluster được sử dụng để tạo cụm EKS trong hai kịch bản — các tài nguyên được tạo của nó được hiển thị tùy chọn bằng cách sử dụng includeWhen dựa trên các giá trị trường đầu vào như sau:

  • Nếu người dùng đặt trường đầu vào vpc.create thành true, chỉ các tài nguyên vpc (loại Vpc) và eksWithVpc (loại EksClusterBasic) được hiển thị. Các trường đầu vào cho tài nguyên eksWithVpc được điền từ trường status của tài nguyên vpc.
  • Nếu người dùng đặt trường đầu vào vpc.create thành false, chỉ tài nguyên eksExistingVpc (loại EksClusterBasic) được hiển thị. Các trường đầu vào cho tài nguyên eksExistingVpc (ví dụ: VPC ID, Subnets ID, v.v.) được điền từ các trường đầu vào của instance RGD.

Sơ đồ sau đây mô tả cấu trúc RGD:

Sơ đồ cấu trúc RGD cho cụm EKS, bao gồm Vpc, EksClusterBasic và EksCluster.

Sau đây là một đoạn trích đơn giản hóa của manifest cho RGD EksCluster (RGD bao quát):

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: ekscluster.kro.run
  annotations:
spec:
  schema:
    apiVersion: v1alpha1
    kind: EksCluster
    spec:
      name: string
      region: string | default="us-west-2"
      k8sVersion: string | default="1.32"
      ...
      vpc:
        create: boolean | default=true
      ...
  resources:
  - id: vpc
    includeWhen:
       - ${schema.spec.vpc.create}
    template:
      apiVersion: kro.run/v1alpha1
      kind: Vpc
      metadata:
        name: ${schema.spec.name}
        namespace: ${schema.spec.name}
        ...
  - id: eksWithVpc
    includeWhen:
       - ${schema.spec.vpc.create}
    template:
      apiVersion: kro.run/v1alpha1
      kind: EksClusterBasic
      metadata:
        name: ${schema.spec.name}
        namespace: ${schema.spec.name}
      spec:
      ...
        network:
          vpcID: "${vpc.status.vpcID}"
          subnets:
            controlplane:
              subnet1ID: "${vpc.status.privateSubnet1ID}"
              subnet2ID: "${vpc.status.privateSubnet2ID}"
            workers:
              subnet1ID: "${vpc.status.privateSubnet1ID}"
              subnet2ID: "${vpc.status.privateSubnet2ID}"
    ...
  - id: eksExistingVpc
    includeWhen:
       - ${!schema.spec.vpc.create}
    template:
      apiVersion: kro.run/v1alpha1
      kind: EksClusterBasic
      metadata:
        name: ${schema.spec.name}
        namespace: ${schema.spec.name}
      spec:
      ...
        network:
          vpcID: "${schema.spec.vpc.vpcId}"
            subnets:
              controlplane:
                subnet1ID: "${schema.spec.vpc.privateSubnet1Id}"
                subnet2ID: "${schema.spec.vpc.privateSubnet2Id}"
              workers:
                subnet1ID: "${schema.spec.vpc.privateSubnet1Id}"
                subnet2ID: "${schema.spec.vpc.privateSubnet2Id}"
    ...

Sử dụng biểu thức CEL để trích xuất các trường được tạo

Trong RGD, chúng tôi sử dụng các biểu thức Common Expression Language (CEL) để trích xuất các giá trị trường được tạo từ một Custom Resource (CR), và đưa nó làm đầu vào cho các CR phụ thuộc khác.

Đoạn manifest sau đây minh họa cách các biểu thức CEL được sử dụng trong RGD. Trong ví dụ này, một biểu thức CEL được sử dụng để trích xuất VPC ID từ VPC CR, và sau đó giá trị đó được đưa làm đầu vào cho InternetGateway CR.

Các biểu thức CEL trong kro cũng phục vụ để suy ra các phụ thuộc tài nguyên. Biểu thức CEL được cung cấp trong ví dụ này chỉ ra rằng InternetGateway CR phụ thuộc vào tài nguyên VPC, dẫn đến việc kro controller tạo thứ tự topo phù hợp, nghĩa là tài nguyên VPC sẽ được tạo trước và ID của nó sẽ có sẵn cho tài nguyên InternetGateway phụ thuộc.

  - id: vpc
    ... (removed for brevity)
  - id: internetGateway
    template:
      apiVersion: ec2.services.k8s.aws/v1alpha1
      kind: InternetGateway
      metadata:
        namespace: ${schema.spec.name}
        name: ${schema.spec.name}-igw
        annotations:
          services.k8s.aws/region: ${schema.spec.region}
      spec:
        vpc: ${vpc.status.vpcID}
        ... (removed for brevity)

Tạo tài nguyên AWS đa tài khoản bằng ACK

AWS khuyến nghị sử dụng chiến lược đa tài khoản và AWS Organizations để giúp cô lập và quản lý các ứng dụng và dữ liệu kinh doanh của bạn. Do đó, điều quan trọng là có khả năng cấu hình các ACK controller trong cụm/tài khoản quản lý, để chúng có thể tạo các tài nguyên cụm workload trong một tài khoản khác (tài khoản workload). Để đạt được điều đó, chúng tôi tận dụng IAM Role Selectors sử dụng một CRD phạm vi cụm để ánh xạ động các IAM role tới các namespace và tài nguyên bằng cách sử dụng các bộ chọn nhãn Kubernetes.

Sơ đồ sau đây minh họa cách ACK hoạt động đa tài khoản. Các bước chính như sau:

  1. Một ACK CR được tạo trong một namespace cụ thể. ACK controller giám sát các CR tương ứng phát hiện CR mới.
  2. ACK controller xác định IAM role tương ứng với namespace nơi ACK CR cư trú dựa trên các IAMRoleSelector CR đã áp dụng.
  3. ACK controller đảm nhận IAM role đã xác định, có thể nằm trong một tài khoản AWS khác.
  4. Với IAM role đã đảm nhận, ACK controller hiện có thể gọi AWS API để tạo tài nguyên trong tài khoản workload.
Sơ đồ minh họa cách ACK hoạt động đa tài khoản, từ việc tạo CR đến việc tạo tài nguyên AWS.

Để sử dụng cơ chế này để tạo một cụm workload đa tài khoản, chúng tôi tạo một namespace cho cụm workload trong cụm quản lý (đây là nơi tất cả các tài nguyên ACK liên quan đến cụm được tạo). Chúng tôi tạo một IAMRoleSelector ánh xạ namespace tới IAM role được sử dụng để tạo các tài nguyên cụm. IAM role này tồn tại trong tài khoản đích, nơi cụm workload được tạo.

Đoạn mã sau đây mô tả cấu trúc của IAMRoleSelector CR:

apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
  name: workload-cluster1-namespace-config
spec:
  arn: arn:aws:iam::112234567890:role/ack
  namespaceSelector:
    names:
    - workload-cluster1

Dựa trên cấu hình trước đó, các ACK controller đảm nhận IAM role arn:aws:iam::112234567890:role/ack để đồng bộ hóa các tài nguyên ACK trong namespace workload-cluster1.

IAM role liên kết với các ACK controller trong cụm quản lý phải được cấp các quyền cần thiết để đảm nhận các IAM role trong các tài khoản workload khác nhau. Ngoài ra, các chính sách tin cậy của các IAM role trong các tài khoản workload phải được cấu hình để cho phép IAM role từ tài khoản quản lý đảm nhận chúng.

Khởi động cụm workload với các add-on

Với Argo CD, chúng ta có thể sử dụng controller ApplicationSets để tăng tính linh hoạt và tự động hóa trong việc quản lý các ứng dụng Argo CD. Controller ApplicationSets cho phép người dùng sử dụng một Kubernetes manifest duy nhất để nhắm mục tiêu nhiều cụm Kubernetes với Argo CD. Điều này hợp lý hóa quá trình triển khai các ứng dụng Argo CD trên các cụm khác nhau, đơn giản hóa việc quản lý các môi trường đa cụm phức tạp.

Để cài đặt các add-on trên các cụm workload, một tài nguyên Argo CD ApplicationSet được áp dụng cho mỗi add-on. ApplicationSet sử dụng Cluster Generator để tạo động các Argo CD Application để triển khai add-on trên các cụm workload khác nhau.

Để Cluster Generator tạo một Application cho một add-on nhất định nhắm mục tiêu một cụm workload, chúng ta cần đăng ký cụm workload làm cụm từ xa trong Argo CD chạy trong cụm quản lý. Hoạt động này liên quan đến việc tạo một Secret với các chi tiết cụm workload như được nêu trong tài liệu về khả năng của EKS.

Trong giải pháp này, Secret được tạo như một phần của tài nguyên RGD EksClusterBasic. Trường server được điền với ARN của cụm workload.

    - id: argocdSecret
      template:
        apiVersion: v1
        kind: Secret
        metadata:
          name: "${schema.spec.name}"
          namespace: argocd
          labels:
            ... (removed for brevity)
           annotations:
            ... (removed for brevity)
        type: Opaque
        stringData:
           name: "${schema.spec.name}"
           server: "${ekscluster.status.ackResourceMetadata.arn}"
           project: "default"

IAM role được đảm nhận bởi Argo CD controller cần được cấp quyền truy cập vào cụm workload. Cách tiếp cận được khuyến nghị là sử dụng EKS access entries để liên kết một tập hợp các quyền Kubernetes với IAM identity. Trong giải pháp này, chúng tôi bao gồm EKS access entry cần thiết trong tài nguyên RGD EksClusterBasic như được mô tả trong đoạn mã sau:

    - id: accessEntry
      template:
        apiVersion: eks.services.k8s.aws/v1alpha1
        kind: AccessEntry
        metadata:
          namespace: "${schema.spec.name}"
          name: "${schema.spec.name}-access-entry"
          ... (removed for brevity)
        spec:
          clusterName: "${schema.spec.name}"
          accessPolicies:
            - accessScope:
                type: "cluster"
              policyARN: "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          principalARN: "arn:aws:iam::${schema.spec.managementAccountId}:role/hub-cluster-argocd-controller"
          type: STANDARD

Cấp quyền IAM cho các add-on

Một số add-on, chẳng hạn như External Secrets Operator, yêu cầu các quyền IAM cụ thể để hoạt động đúng cách. Để cấp các quyền đó bằng cách sử dụng EKS Pod Identity (cơ chế được khuyến nghị để cấp quyền IAM cho một pod), chúng ta cần tạo một IAM policy, một IAM role và một liên kết giữa ServiceAccount của add-on và IAM role. Trong giải pháp này, chúng tôi sử dụng các ACK controller để tạo các tài nguyên đã đề cập.

Thiết lập IAM phải được hoàn thành trước khi add-on được cài đặt, nếu không các pod của add-on có thể gặp sự cố. Một cách để đạt được điều đó là bao gồm các tài nguyên EKS Pod Identity của add-on trong tài nguyên RGD EksClusterBasic.

Tổng hợp lại

Hãy xem xét lại kiến trúc giải pháp (xem sơ đồ sau) và đi qua các bước liên quan đến việc tạo một cụm workload.

Bước 1: Nhà phát triển tạo một pull request (PR) với manifest của cụm workload (instance RGD), chỉ định tên cụm, phiên bản Kubernetes, các add-on cần thiết và các chi tiết liên quan khác.
Bước 2-3: Argo CD lấy instance RGD của cụm và áp dụng nó vào cụm quản lý.
Bước 4: kro controller phân tách instance RGD của cụm thành các tài nguyên ACK riêng lẻ (custom resources), và áp dụng chúng vào cụm quản lý theo đúng thứ tự. Điều này bao gồm việc tạo một Secret với các chi tiết cụm mà Argo CD mong đợi để có thể đồng bộ hóa vào cụm workload đích.
Bước 5: ACK controller sau đó đảm nhận một role trong tài khoản workload và tạo các tài nguyên AWS tương ứng (ví dụ: cụm EKS, VPC, IAM roles).
Bước 6: ApplicationSets của Argo CD tạo các Argo CD Application cho mỗi add-on được kích hoạt cho cụm. Các Application này sau đó được sử dụng để cài đặt các add-on cần thiết trong cụm workload.

Sơ đồ tổng hợp các bước tạo cụm workload bằng ACK, kro và Argo CD.

Mã nguồn

Việc triển khai giải pháp được nêu trong bài đăng này có sẵn trong kho lưu trữ này. Thực hiện theo các bước trong tệp README để thử nghiệm giải pháp trong môi trường của riêng bạn.

Kết luận

Trong bài đăng này, chúng tôi đã trình bày cách kro, kết hợp với các controller cơ sở hạ tầng như ACK và Argo CD, cho phép tiêu chuẩn hóa việc cung cấp và khởi động các cụm thông qua một Kubernetes API duy nhất, và triển khai giải pháp quản lý cụm dựa trên GitOps. Điều này loại bỏ nhu cầu sử dụng hỗn hợp các pipeline Infrastructure as Code (IaC) và Kubernetes API cho mục đích đó.

Chúng tôi đã giải thích một số tính năng chính của kro đã đóng vai trò quan trọng trong việc triển khai này:

  1. Cung cấp một schema đơn giản để tạo các custom resource (CR) mới.
  2. Cho phép quản lý các phụ thuộc giữa các tài nguyên.
  3. Hỗ trợ các biểu thức dựa trên Common Expression Language (CEL) cho các điều kiện và truyền giá trị từ tài nguyên này sang tài nguyên khác.

Những khả năng này của kro cho phép một cách tiếp cận hợp lý và dễ bảo trì hơn để quản lý việc cung cấp và khởi động các cụm Kubernetes, so với việc dựa vào sự kết hợp của các pipeline IaC và tương tác trực tiếp với Kubernetes API. Chúng tôi cũng đã chứng minh khả năng đa tài khoản của ACK, và cách nó cho phép chiến lược đa tài khoản cho các cụm Kubernetes.

Điều quan trọng cần lưu ý là dự án kro đang trong giai đoạn phát triển tích cực và chưa được thiết kế để sử dụng trong môi trường sản xuất. CRD ResourceGraphDefinition (RGD) và các API khác được sử dụng trong dự án này chưa được củng cố và có thể thay đổi nhiều.

Về tác giả


Islam Mahgoub là Kiến trúc sư Giải pháp Cấp cao tại AWS với hơn 15 năm kinh nghiệm về kiến trúc ứng dụng, tích hợp và công nghệ. Tại AWS, anh giúp khách hàng xây dựng các giải pháp mới tập trung vào đám mây và hiện đại hóa các ứng dụng kế thừa của họ bằng cách sử dụng các dịch vụ AWS. Ngoài công việc, Islam thích đi bộ, xem phim và nghe nhạc.


Kumudhan là Chuyên gia tư vấn DevOps tại AWS Professional Services, có trụ sở tại Thụy Sĩ. Anh đam mê giúp khách hàng áp dụng các quy trình và dịch vụ giúp tăng hiệu quả của họ với AWS Cloud. Khi không làm việc, anh thích đi du lịch, chơi cricket và âm nhạc.


Markos Kandylis là Chuyên gia tư vấn DevOps cấp cao tại AWS Professional Services. Anh thích xây dựng các nền tảng tự động hóa và cloud-native giúp khách hàng hiện đại hóa và vận hành các môi trường có khả năng mở rộng, với trọng tâm mạnh mẽ vào Amazon EKS và Kubernetes. Sở thích của anh bao gồm DevOps, GitOps, infrastructure as code, công nghệ mã nguồn mở và tự động hóa nền tảng.


Ramesh Mathikumar là Chuyên gia tư vấn chính trong bộ phận Dịch vụ Tài chính Toàn cầu. Anh đã làm việc với các khách hàng dịch vụ tài chính trong 25 năm qua. Tại AWS, anh giúp khách hàng thành công trong hành trình đám mây của họ bằng cách triển khai các công nghệ AWS mỗi ngày.


Sébastien là Kiến trúc sư Giải pháp Chuyên gia Cấp cao tại AWS, nơi anh đã thúc đẩy thành công của khách hàng kể từ năm 2019. Anh mang đến chuyên môn sâu rộng về các giải pháp container của AWS và công nghệ cloud-native, đặc biệt tập trung vào Kubernetes, hệ thống AI/ML và kiến trúc phân tán quy mô lớn. Trong suốt nhiệm kỳ của mình, Sébastien đã hợp tác với các tổ chức thuộc nhiều phân khúc ngành khác nhau ở EMEA và Pháp, giúp họ áp dụng công nghệ container và triển khai các phương pháp hay nhất cho cơ sở hạ tầng đám mây hiện đại.

←
→

Leave a comment