- Figma đã chuyển các dịch vụ lõi vốn đã được container hóa từ ECS sang Kubernetes dựa trên EKS, với mục tiêu giảm các giới hạn nền tảng dài hạn mà không có downtime
- Trên ECS, các hạn chế lớn gồm thiếu StatefulSets, khó vận hành OSS dựa trên Helm chart và hạn chế trong việc cô lập node; Kubernetes mở ra các lựa chọn như hệ sinh thái CNCF, Keda, Karpenter và Istio
- Quá trình migration được thu hẹp phạm vi bằng cách giữ nguyên các abstraction về chạy dịch vụ, triển khai và công cụ, chỉ thay phần orchestration; định nghĩa dịch vụ dựa trên Bazel và cấu hình 3 cụm EKS được đưa vào phạm vi ban đầu
- Trong quá trình chuyển đổi, Figma đảm bảo khả năng rollback thông qua kiểm thử tải, chuyển traffic dần dần bằng Weighted DNS, chuyển sớm dịch vụ thực tế, che giấu YAML thô và phối hợp với chủ sở hữu dịch vụ
- Đến tháng 1/2024, phần lớn các dịch vụ ưu tiên cao nhất đã được chuyển sang EKS; sau khi giảm chi phí over-provisioning, cải thiện độ tin cậy và trải nghiệm developer, Figma tiếp tục triển khai logging, autoscaling và chuyển sang Graviton
Lý do chuyển từ ECS sang Kubernetes
- Vào đầu năm 2023, Figma đã chạy toàn bộ dịch vụ dưới dạng container và đang dùng AWS Elastic Container Service(ECS) làm nền tảng orchestration
- Khi xem xét nền tảng compute thế hệ tiếp theo, Figma cho rằng tiếp tục xây dựng chồng lên ECS sẽ khó tạo ra các tính năng mong muốn về dài hạn
- Figma không phải là công ty vận hành hàng nghìn microservice, nên phạm vi chuyển sang Kubernetes có thể được quản lý một cách thực tế
- Có những trường hợp cần dịch vụ mới vì lý do cô lập hoặc hiệu năng, nhưng các dịch vụ lõi đã cung cấp mức module hóa và cô lập traffic cơ bản
- Nhiều sản phẩm mới cũng thường được hỗ trợ bằng cách thêm logic vào các dịch vụ lõi hiện có, thay vì tạo dịch vụ mới
Những tính năng ECS còn thiếu
- ECS không hỗ trợ StatefulSets của Kubernetes, khiến việc vận hành kho dữ liệu đồng thuận có tính nhất quán mạnh như etcd trở nên khó khăn
- Figma đã обход bằng mã tùy chỉnh để cập nhật động membership của cluster tại thời điểm container etcd khởi động
- Cách này mong manh và khó bảo trì; trong Kubernetes, cách phổ biến là dùng cấp phát mạng có trạng thái của StatefulSets
- Trên ECS, việc chạy các nhóm dịch vụ được định nghĩa bằng Helm charts rất khó
- Việc tắt một máy EC2 đơn lẻ có vấn đề một cách êm ái trong ECS on EC2 cũng phiền phức
- Trên EKS, nếu cordon node xấu, API server có thể tôn trọng quy trình shutdown và chuyển Pod sang máy khác
Hệ sinh thái CNCF và lựa chọn nền tảng
- Nếu tiếp tục dùng ECS, Figma khó tận dụng các công nghệ mã nguồn mở trong hệ sinh thái Cloud Native Computing Foundation(CNCF)
- Autoscaling là một mối quan tâm quan trọng đối với nền tảng compute thế hệ tiếp theo
- Khi đó Figma chưa áp dụng autoscaling cho các dịch vụ container hóa
- Dịch vụ được provision để chịu được tải đỉnh ngay cả vào những thời điểm traffic thấp như ban đêm và cuối tuần, gây chi phí không cần thiết
- Keda trong hệ sinh thái Kubernetes hỗ trợ scale không chỉ dựa trên mức sử dụng CPU mà còn dựa trên độ dài queue AWS SQS và custom metric của Datadog
- Service mesh cũng có khả năng cần thiết về dài hạn
- Traffic giữa các dịch vụ hiện được routing qua AWS Application Load Balancers(ALB) và Network Load Balancers(NLB)
- NLB mất vài phút để đăng ký target mới và loại bỏ target cũ, làm chậm các đợt triển khai khẩn cấp và tăng thời gian khôi phục trung bình khi sự cố
- Envoy cung cấp khả năng tùy biến cao hơn và chạy custom filter
- Figma đã từng đặt một cụm máy Envoy độc lập làm proxy trước các dịch vụ chính và dùng custom filter để giảm tải trong sự cố
- Trên EKS có nhiều lựa chọn mã nguồn mở như Istio, nhưng trên ECS Figma sẽ phải tự xây dựng lại các chức năng tương tự
Lợi thế vận hành từ một nền tảng phổ biến
- Figma không muốn trở thành người dùng lớn nhất của bất kỳ dịch vụ hay phần mềm nào
- Người dùng lớn nhất thường dễ là bên đầu tiên va phải các phần thô ráp và giới hạn mở rộng
- Kubernetes được nhiều tập đoàn lớn dùng cho các nền tảng compute khổng lồ, nên Figma thuộc nhóm người dùng nhỏ hơn rất nhiều
- Kubernetes giúp giảm vendor lock-in
- EKS cung cấp lợi thế của control plane do vendor hỗ trợ
- Vì dịch vụ được viết để chạy trên Kubernetes phổ thông, việc chuyển sang nền tảng Kubernetes do vendor khác hỗ trợ hoặc nền tảng tự host không phải là gánh nặng quá lớn
- Dễ tuyển kỹ sư có kinh nghiệm Kubernetes hơn
- Kỹ sư có kinh nghiệm sẵn có có thể thích nghi nhanh và cung cấp bối cảnh cho những lĩnh vực có thể là quyết định mới với Figma
Nguyên tắc xác định phạm vi migration
- Trong một migration lớn, an toàn nhất là chỉ thay thế hệ thống lõi muốn thay đổi, và giữ tối đa các abstraction mà người dùng nền tảng nhìn thấy
- Figma thu hẹp phạm vi theo hướng chuyển để chạy trên EKS thay vì ECS, nhưng không thay đổi cách chạy dịch vụ, cách triển khai và công cụ tương tác giữa dịch vụ
- Ngay cả công việc tưởng như không thay đổi tính năng cũng có thể tạo ra hiệu ứng bậc hai, khiến lịch trình migration quy mô lớn dễ phình to
- Có hai ngoại lệ
- Nếu cần quá nhiều công việc bổ sung để làm hệ thống mới hành xử như hệ thống cũ, có thể chấp nhận hiệu ứng bậc hai và chọn cách mới
- Với các quyết định kiểu one-way door, sau này khó hoặc tốn kém để thay đổi, có thể áp dụng cách mới ngay từ đầu
Các cải tiến được đưa vào phạm vi
-
Trải nghiệm developer
- Các định nghĩa dịch vụ ECS hiện có chủ yếu được tạo và chỉnh sửa bằng Terraform
- Việc apply Terraform tạo một template ECS task set với 0 instance, sau đó trong quá trình deploy sẽ sao chép template, thay thế image hash rồi deploy task set có số instance khác 0 lên ECS
- Ngay cả khi thêm một biến môi trường, cũng phải viết và apply Terraform rồi chạy deploy; nếu không đúng thứ tự, code không thể dùng biến môi trường một cách an toàn và có thể phát sinh bug
- Trên EKS, Figma chuyển sang đặt định nghĩa dịch vụ ở một nơi và deploy thay đổi trong một bước
- Figma tạo một cách nội bộ đơn giản để định nghĩa dịch vụ bằng file cấu hình Bazel, rồi tự động tạo YAML định nghĩa dịch vụ và YAML cấu hình như Ingress
- YAML được công cụ CI tạo khi commit code và được áp dụng thông qua hệ thống deploy nội bộ
-
Độ tin cậy
- Với mỗi dịch vụ, Figma cấu hình để 3 cụm EKS chạy Pod và nhận traffic
- Nếu mọi vận hành diễn ra ở cấp cluster, một sự cố toàn phần có thể được giảm xuống còn ảnh hưởng đến một phần ba dịch vụ
- Với các dịch vụ có thể retry request hoặc xử lý bất đồng bộ, gián đoạn với người dùng thường được giảm thiểu
- Cấu hình này làm tăng đáng kể độ phức tạp vận hành, như pipeline deploy, nhưng Figma cho rằng đáng để áp dụng ngay tại thời điểm migration hơn là thêm sau này
-
Hiệu quả chi phí
- Figma không đưa nhiều công việc tối ưu chi phí phức tạp vào phạm vi migration, nhưng hỗ trợ node autoscaling ngay từ đầu
- Trong các dịch vụ ECS on EC2, Figma over-provision máy để xử lý mức tăng đột biến trong quá trình deploy
- Trên EKS, Figma dùng Karpenter để tự động scale node lên/xuống theo nhu cầu
Các công việc bị loại khỏi phạm vi
- Pipeline logging hiện có khá phức tạp
- Tất cả log trước tiên được ghi vào CloudWatch
- Lambda đọc log và thực hiện các biến đổi như xóa một số pattern nhất định và thêm tag
- Sau đó log được ghi vào Datadog và Snowflake
- Chi phí CloudWatch làm kho trung gian ngày càng lớn
- Figma lên kế hoạch đưa vào dự án CNCF Vector, có thể xử lý và chuyển tiếp log dưới dạng sidecar trong stack EKS
- Tuy nhiên, Figma cho rằng không đáng chấp nhận hiệu ứng bậc hai của việc port logic log forwarder sang cấu hình Vector, nên loại khỏi phạm vi migration
- Autoscaling cấp Pod cũng không được đưa vào migration
- Figma đánh giá độ phức tạp quá cao
- Đây được xem là công việc có thể dễ dàng thêm sau
- Các công việc bị loại trừ sau đó trở thành hạng mục tiếp theo, và có thể mang lại cải tiến song song với việc chuyển các dịch vụ khác sang EKS
Cách thực thi an toàn
- Vì stack ECS hiện có tương đối ổn định, stack EKS mới và quá trình migration cũng phải đáng tin cậy ít nhất ở mức đó
-
Kiểm thử tải
- Figma tạo một dịch vụ “Hello, World” và scale để chạy số Pod tương đương dịch vụ lớn nhất của Figma
- Bài test này cho thấy cần điều chỉnh kích thước và scale các dịch vụ compute lõi hỗ trợ toàn bộ nền tảng
- Kyverno là công cụ kiểm tra bảo mật cluster; nếu không được cấu hình đủ lớn, nó có thể làm chậm việc khởi động Pod mới
-
Rollout dần dần
- Figma dùng bản ghi Weighted DNS để chuyển từng chút traffic từ dịch vụ ECS hiện có sang dịch vụ tương ứng trên EKS
- Khả năng kiểm soát chuyển traffic tinh vi và đảo ngược là cốt lõi của một migration an toàn
- Tác động không lường trước có thể xảy ra tại các điểm uốn chưa biết, nên cần giảm phạm vi ảnh hưởng và có thể rollback nhanh
-
Chạy sớm dịch vụ thực tế
- Khi đưa workload thực tế lên hệ thống, có thể học được nhiều điều mà chỉ staging không thể cho biết
- Figma đã chuyển một dịch vụ trước cả khi hoàn tất xây dựng môi trường staging
- Lần chuyển sớm này giúp kiểm chứng end-to-end khả năng chạy workload và tìm ra bottleneck cùng bug
-
Abstraction YAML
- Nếu để người dùng tự định nghĩa dịch vụ trực tiếp bằng Kubernetes YAML thô, điều đó có thể gây rối
- Figma cung cấp cho người dùng một golden path, chỉ cho phép tùy biến trong các trường hợp đặc biệt
- Bằng cách làm rõ người dùng có thể và nên tùy biến gì, đồng thời cưỡng chế tính nhất quán mặc định, việc bảo trì và thay đổi về sau trở nên đơn giản hơn
-
Phối hợp với chủ sở hữu dịch vụ và bố trí nhân sự
- Thiết lập dịch vụ mới do đội platform phụ trách; việc cập nhật monitoring và alert được thực hiện với sự phối hợp chặt chẽ của chủ sở hữu dịch vụ, những người hiểu rõ nhất trạng thái dịch vụ
- Ngay cả trước khi bắt đầu migration, Figma đã thảo luận đầy đủ với chủ sở hữu dịch vụ về các lựa chọn và trade-off
- Migration quy mô lớn có thể tạo ra vấn đề bất ngờ, tương tác phức tạp và bug thông thường, nên cần một đội có chuyên môn kỹ thuật sâu và năng lực debugging
Lịch trình và kết quả migration thực tế
- Trong Q1/2023, Figma lập kế hoạch và nhận được đồng thuận để tiến hành migration
- Trong Q2/2023, Figma tạo môi trường staging và chuyển một dịch vụ đơn lẻ
- Trong Q3/2023, Figma tập trung vào production hóa, kiểm thử tải và chuẩn bị chuyển thêm dịch vụ
- Từ Q4/2023 đến tuần đầu tiên của tháng 1/2024, Figma từ từ chuyển traffic dịch vụ
- Đến tháng 1/2024, phần lớn các dịch vụ ưu tiên cao nhất đã được chuyển sang các cụm EKS mới
- Monolith chứa logic kinh doanh lõi
- Dịch vụ phức tạp xử lý khía cạnh multiplayer của việc chỉnh sửa file Figma
- Các dịch vụ cấu thành Livegraph 100x, đẩy cập nhật thời gian thực tới mọi client
- Kết quả là Figma giảm chi phí over-provisioning cho deploy, tăng độ tin cậy nhờ chạy trên 3 cluster, và cải thiện tính dễ dùng cho developer
- Toàn bộ công việc diễn ra với các sự cố nhỏ và tác động thấp tới khách hàng
- Có một sự cố trong đó một operator vô tình phá hủy và tái tạo CoreDNS trên một production cluster
- Với cấu hình trước đây, tình huống đó sẽ gây sự cố toàn phần
- Với cấu hình 3 cluster, tác động được giới hạn ở một phần ba số request
- Phần lớn dịch vụ downstream retry request và cuối cùng thành công
Cải tiến công cụ sau khi ra mắt
- Figma xây dựng công cụ để chủ sở hữu dịch vụ có thể debug những gì xảy ra trong cluster
- Kiểm tra số instance đang chạy
- Truy cập shell của container
- Thực hiện tác vụ vận hành như scale khẩn cấp
- Ngay sau khi ra mắt, Figma nhận phản hồi rằng công cụ truy cập này chưa đủ thân thiện với người dùng
- Có hai nguyên nhân gây phức tạp
- Việc đưa vào 3 cluster khiến người dùng phải chạy lệnh trên nhiều cluster và thêm tên cluster cho từng lệnh
- Khi tận dụng vai trò RBAC của Kubernetes để cung cấp quyền chi tiết hơn, người dùng phải hiểu mình có vai trò nào và một tác vụ cụ thể cần vai trò nào
- Figma lập tức dừng các công việc khác và sửa công cụ để tự suy luận cluster và vai trò phù hợp
- Người dùng không còn phải mất thời gian tìm vai trò, đặc biệt trong tình huống khẩn cấp lúc nửa đêm
Bước tiếp theo
- Figma tiếp tục chuyển các dịch vụ còn lại, đồng thời cải tiến nền tảng compute mới song song
- Các lĩnh vực hiện đang tập trung gồm
- Đơn giản hóa thiết kế pipeline logging
- Hỗ trợ horizontal Pod autoscaling thông qua Keda
- Chuyển các dịch vụ tốn chi phí nhất tại Figma sang bộ xử lý Graviton để giảm chi phí, đồng thời mở đường để các dịch vụ khác chạy trên Graviton trong tương lai
- Figma cũng dự định khám phá những lĩnh vực chưa đầu tư sâu
- Xem xét các dịch vụ service mesh để cải thiện độ tin cậy và khả năng quan sát của networking stack
- Quản lý nhiều resource hơn bằng AWS Controllers for Kubernetes(ACKs) để giảm phụ thuộc vào Terraform, đơn giản hóa và hợp nhất stack
- Phối hợp với đội trải nghiệm developer để thống nhất cách chạy dịch vụ trong môi trường phát triển với cách chạy trong các môi trường khác
1 bình luận
Ý kiến trên Hacker News
Cá nhân tôi thích Kubernetes. Tôi vận hành vài cửa hàng thương mại điện tử tùy biến nhỏ nhưng phức tạp, đồng thời kiêm luôn marketing, tài chính và hỗ trợ khách hàng
Trước đây chúng tôi chạy trên máy chủ riêng, nhưng stack khá phức tạp nên việc triển khai là một cơn ác mộng, và cuối cùng gánh nặng triển khai đang làm chậm tốc độ của một công ty nhỏ
Tôi mất một tháng để học Kubernetes và di chuyển sang đó; hiện vận hành khoảng 25 dịch vụ như frontend, trình quản lý sản phẩm, dashboard logistics, tối ưu hóa tuyến giao hàng, OSRM, ERP, engine gợi ý, tìm kiếm, v.v.
Khi gom cấu hình cluster về một nơi, chúng tôi đã sắp xếp lại thành một cấu trúc có thể lặp lại, và có thể biết chính xác trạng thái của từng dịch vụ cũng như phiên bản đang chạy. Chúng tôi cũng có thể rolling deploy không gián đoạn; đúng là phức tạp, nhưng lập trình viên vốn xử lý những thứ phức tạp. File cấu hình Nginx cũng phức tạp vậy
Càng đào sâu, bạn càng hiểu vì sao kiến trúc của Kubernetes là hợp lý, và nó buộc bạn tuân thủ nghiêm ngặt 12-factor. Nếu doanh thu gắn trực tiếp với tính sẵn sàng và độ ổn định của stack, thì high availability không chỉ là thứ “có thì tốt”. Chi phí hosting cũng chỉ khoảng 400 USD/tháng nên không quá đắt
Tôi thuộc phe tin vào Kubernetes, nhưng nó thực sự phức tạp. Đây là công cụ giải các bài toán khó. Nếu bạn chạy multi-cloud thì không cần phải lăn tăn; nếu muốn hạ tầng phức tạp ánh xạ 1:1 với môi trường local thì nó rất phù hợp
Nhưng nếu có dưới 100 developer và chỉ triển khai container lên AWS, thì năm 2024 mà dùng EKS thay vì ECS + Fargate thì tôi cho là không tỉnh táo
Bản thân việc migration để cải thiện nền tảng hạ tầng là tốt. Tuy nhiên, việc một trong các động cơ là muốn các team dùng Helm chart thay vì chuyển đổi sang Terraform khiến tôi khá bất ngờ
Thực tế tôi hiếm khi thấy ai dùng ổn định các Helm chart tùy ý mà không chỉnh sửa; nếu khuyến khích dùng, cuối cùng các team sẽ fork và sửa chart. Helm là một công cụ tệ đến mức tôi không muốn duy trì Helm chart tùy biến của riêng mình
Tôi nghĩ viết lại bằng Terraform còn dễ duy trì phiên bản local hơn. Nếu có phản ví dụ thì tôi muốn nghe. Có thể giờ đây sự điên rồ của
indent 4trong Helm và vấn đề template chuỗi nhiều tầng đã biến mất rồi cũng nênBạn cũng có thể quản lý workload Kubernetes bằng Terraform, nhưng tôi không khuyến nghị. Kubernetes tự nó đã có state, nếu Terraform cũng có state thì kết hợp Terraform + Kubernetes sẽ rất đau khổ. Helm được tạo ra cho Kubernetes, còn Terraform thì không
Nói vậy không có nghĩa là tôi thích Helm. YAML được template hóa không hay ho gì, và sự điên rồ
indent 4vẫn còn. Kustomize thì tốt khi đơn giản, nhưng khi app phức tạp lên, tôi thấy nó còn tệ hơn Helm. Ví dụ, nếu triển khai một app có Ingress, chứng chỉ TLS và external-dns cho nhiều môi trường, thay vì dùng một biến ở ba chỗ, bạn phải patch resource ba lầnHelm và Terraform đều rất phổ biến nên được nhắc đến nhiều, nhưng cuối cùng tôi nghĩ sẽ xuất hiện một công cụ thay thế cả hai mà hiện vẫn chưa đại chúng
Vấn đề của Terraform là bạn phải thiết kế workspace sao cho không vượt quá số resource khuyến nghị cho mỗi workspace, khoảng 100–200. Nếu không, plan sẽ chậm đi rất nhiều vì phải kiểm tra cả những database hay network mà bạn không hề động tới và cũng không có ý định động tới, khiến thời gian triển khai tăng lên
Trên thực tế, bạn sẽ tạo ra một mạng lưới Terraform workspace kích hoạt lẫn nhau, nhưng hiện không có công cụ open source tốt nào hỗ trợ việc này đúng cách
Theo tôi hiện cách tốt nhất là để Terraform cài đặt một công cụ continuous deployment như ArgoCD như một phần của hạ tầng, rồi để CD tool xử lý các triển khai hằng ngày. Và hầu hết CD tool yêu cầu đóng gói deployment bằng thứ gì đó như Helm
Nhưng nó có quá nhiều cạm bẫy, khiến tôi phải tốn thời gian làm lại và debug công việc do các engineer khác tạo ra
Tôi hy vọng công cụ mới tên
timonisẽ có đà phát triển. Nó giải quyết gần như mọi phàn nàn của tôi về Helm. Nếu bạn đang tìm một giải pháp tốt hơn, timoni đáng để xem thửChúng tôi chọn cách dùng nguyên các Helm chart công khai, còn phần tùy biến thì xử lý bằng
kustomize —enable-helmTrường hợp của chúng tôi là có một Helm chart nền tảng theo từng ứng dụng/dịch vụ, cung cấp các giá trị mặc định hợp lý, và mọi deployment đều mở rộng từ đó. Phía sử dụng chỉ cần cấu hình Helm values tối thiểu, và hầu như chưa từng phải nhét template riêng vào, vì chart nền tảng đã để lộ đủ các điểm điều chỉnh
Với chart bên thứ ba, chúng tôi có thể triển khai nguyên trạng khá nhiều; thỉnh thoảng thêm tính năng cần thiết bằng PR lên upstream. Hiếm khi phải bọc lại hoặc fork, còn số chart bên thứ ba triển khai nguyên trạng thì nhiều hơn hẳn
Khi bảo trì chart tùy biến, helm unittest (https://github.com/helm-unittest/helm-unittest) giúp rất nhiều trong việc tránh regression
Chúng tôi có quản lý một vài resource Kubernetes, bao gồm ArgoCD, bằng Terraform, nhưng nhìn chung triển khai Helm chart thông qua ArgoCD dễ quản lý và năng suất hơn nhiều
Tôi thấy lạ là trên HN lại có nhiều tâm lý chống Kubernetes như vậy. Không rõ có phải vì đa số người bình luận là các developer quen với những dịch vụ như Heroku, fly.io, render.com, hay vì họ chạy ứng dụng trên VM
Đây không phải là vấn đề chỉ giới hạn ở một trường hợp cụ thể, mà là vấn đề do các incentive lệch lạc nghiêm trọng trên toàn ngành, cùng phần nào là cơn sốt vàng của thời kỳ lãi suất thấp tạo ra
Thành thật mà nói, với tình trạng hiện tại, trong các lĩnh vực khác có lẽ chúng ta sẽ trông như những thợ thủ công khá vô dụng. Chúng ta ám ảnh một cách không lành mạnh với công cụ và meta-work, trong khi liên tục ném việc sử dụng tài nguyên hợp lý ra ngoài cửa sổ chỉ để dùng một công cụ cụ thể. Kiểu như tình cảnh “kỹ sư FAANG tạm thời gặp khó khăn” vậy
Rất khó giải thích rằng nếu xây trên Kubernetes thay vì các mô hình triển khai có thể chọn trên AWS, như VM image của EC2, Elastic Beanstalk, ECS/Fargate, Lambda, thì sẽ mất thêm bao lâu, cần thêm bao nhiêu chuyên môn, trở nên mong manh hơn bao nhiêu và tốn thêm bao nhiêu tiền
Tôi không muốn tự cài đặt và duy trì ELK stack hay Prometheus. Cũng không muốn vật lộn với CNI plugin, Kafka, Postgres high availability, Argo, Helm, hay nâng cấp control plane. Với các dịch vụ tương ứng của AWS, gần như có thể bắt đầu ngay, gần như không cần bảo trì, và chi phí cũng thường bắt đầu tuyến tính từ mức gần 0
Có thể giải quyết bài toán kinh doanh nhanh hơn và hiệu quả hơn nhiều. Đó là khác biệt giữa việc có thể vượt xa kỳ vọng và việc cả team bị chậm mất nhiều quý
Tuy nhiên, nếu thực sự có yêu cầu multi-cloud hoặc on-premises thì tôi không muốn dùng gì ngoài Kubernetes. Với một công ty lớn có nhiều kỹ sư lành nghề hiểu Kubernetes, có thể nó cũng không tệ đến vậy. Ít nhất những nơi tôi từng làm thì không như thế
Thật tốt khi thấy các doanh nghiệp chủ yếu chuyển sang hạ tầng mã nguồn mở. Một phần đáng kể trong đó đến từ CNCF (https://landscape.cncf.io), ASF và nhiều dự án trên GitHub
kata-containers có thể giải quyết nỗi bất an đó và khiến tôi thích Kubernetes hơn
Nhìn chung, cá nhân tôi không thấy Kubernetes có gì ngầu. Container, load balancer, YAML tính bằng megabyte thì tôi đã thấy cả rồi, và nó không tạo cảm giác đủ thú vị để thử
Có thể điều này là bình thường với một công ty ở quy mô này, nhưng tôi khó theo dõi quá trình ra quyết định của những migration hay dự án kỹ thuật khổng lồ như vậy. Vì quyết định không có vẻ xuất phát từ nhu cầu của người dùng hay của công ty
Tôi cũng có cảm giác tương tự với một bài viết trước đây của Figma về database
Ví dụ, nếu lý do muốn chuyển sang Kubernetes là vì không thể dùng etcd/Helm trên ECS, thì trước hết nên hỏi tại sao lại muốn dùng etcd/Helm. Nó có thật sự quan trọng đến vậy không? Cách đạt mục tiêu của công ty có thật sự chỉ đúng là theo cách đó không?
Khi quyết định dựa trên nhu cầu của người dùng, việc kiểm chứng các quyết định cấp dưới có hợp lý hay không sẽ dễ hơn; nhưng nếu dựa trên nhu cầu kỹ thuật, thì dù các quyết định cấp dưới trông có vẻ hợp lý trong bối cảnh nhu cầu kỹ thuật đó, vẫn không chắc chúng có hợp lý trong bối cảnh người dùng hay không
Có lẽ hoặc là tôi không hiểu các tổ chức ở quy mô này, hoặc là bản thân việc xác định và suy luận về những việc có giá trị trong tổ chức ở quy mô này về căn bản là khó
Về bản chất, chúng tôi là một platform team, và thường xây công cụ cho các platform team khác, những người lại xây công cụ hỗ trợ các developer Figma tạo ra trải nghiệm sản phẩm thực tế. Càng xa người dùng cuối, việc suy luận để đưa ra quyết định đúng càng khó hơn, nhưng đồng thời cũng tạo ra đòn bẩy lớn
Nếu xây platform đúng cách, tác động của nó ảnh hưởng đến khả năng làm việc hiệu quả và hiệu suất của tất cả kỹ sư khác. Nhiều tác động trong số đó là gián tiếp
Chắc chắn cũng có lựa chọn là nói rằng chúng tôi không thể hỗ trợ etcd và Helm, nên hãy tìm cách vòng tránh khác. Nhưng hai thứ này là các điểm dữ liệu bổ sung đẩy chúng tôi đến kết luận rằng chúng tôi đang vận hành Compute platform trên những khối nền tảng mặc định sai
Dù việc suy luận khó, nó vẫn rất đáng để cố gắng làm tốt. Vì với tư cách platform team, đó là cách để đảm bảo rằng chúng tôi đang làm đúng việc nhằm đạt được platform tốt nhất. Vì vậy chúng tôi đã dành nhiều thời gian cho quyết định này, và tôi nghĩ đây là chủ đề thú vị để viết ra
Nhiều cuộc migration sang Kubernetes ở các công ty lớn có khả năng được thúc đẩy bởi mong muốn multi-cloud hoặc hybrid on-premises, cũng như giảm thiểu chi phí, rủi ro về availability và lock-in
Phải lo đồng bộ nâng cấp VM, chứng thực, backup, log rotation, v.v.
Trong Kubernetes, có thể cấp namespace, policy, volume cho từng bên, và nhờ DaemonSet cùng stack Kubernetes/cloud-native, cũng có thể tự động gom log
Còn có self-healing và nhiều thứ khác, tốt hơn đến mức khó giải thích hết
Chẳng hạn, không có nhiều kho dữ liệu vừa có high availability vừa nhất quán để dùng như tương đương với file
.pidtrong môi trường phân tán. Thứ tôi nghĩ đến là Zookeeper, nhưng về mặt vận hành thì nó thực sự đau đớn, đòi các phiên bản JVM cũ, và dù vậy nhìn chung vẫn bất ổnKhi mã Terraform được áp dụng, nó tạo một ECS task set với 0 instance để dựng template dịch vụ; sau đó khi developer triển khai dịch vụ, họ phải sao chép template task set này và thực hiện nhiều thao tác thủ công. Phần này nghe giống như đã làm cách quản lý triển khai Terraform + ECS trở nên quá phức tạp, hơn là vấn đề của ECS
Mình hiểu việc tạo template để kiểm chứng trước khi triển khai thực tế. Nhưng chuyện này hơi mơ hồ
Vì vậy tôi cố ý phân loại mục này là một việc đã quyết định đưa vào quá trình migration, chứ không đưa vào các lý do căn bản khiến chúng tôi bắt đầu migration
Tuy vậy tôi có thể hình dung vài kịch bản khiến cách làm này trở nên cần thiết. Ví dụ khi có nhiều dịch vụ triển khai lên ECS khiến kích thước Terraform state phình to. Khi đó plan và apply chậm đi đáng kể, và việc shard Terraform state bằng cách sao chép nguyên cấu hình theo template có thể an toàn hơn nhiều
Tất cả chỉ là thêm biến môi trường vào file Terraform, merge, rồi để CI triển khai. Hầu hết các thay đổi cấu hình của chúng tôi đều được xử lý theo quy trình đó
“Migration sang Kubernetes có thể mất vài năm” — tôi không biết mình đang đọc cái gì nữa
Với ai thì như vậy? Tôi cũng không rõ vì sao các công ty cứ phải thực hiện những migration kiểu này. Giá trị kinh doanh ở đâu, lợi ích cho khách hàng ở đâu? Có phải đây là dự án “nghệ thuật vị nghệ thuật” vì Figma có khả năng làm được không?
Ở một công ty rất lâu đời, khoảng 30 năm tuổi, với đủ thứ gánh nặng đi kèm, chúng tôi đã chuyển sang Kubernetes trong thời gian ngắn hơn nhiều. Tuy nhiên chúng tôi không cố chuyển mọi thứ sang Kubernetes, mà chỉ chuyển những gì có lợi
Đề xuất của chúng tôi đại khái là: nếu chuyển sang Kubernetes, khi di dời datacenter đã lên kế hoạch vào cuối năm, bạn gần như không phải làm gì ngoài kiểm tra. Còn không thì phải triển khai lại ứng dụng lên máy mới hoặc VM mới và xử lý đủ loại rắc rối đi kèm. Nếu ứng dụng chưa được container hóa, hãy container hóa ngay bây giờ, phần còn lại chúng tôi sẽ lo
Phần lớn đã chuyển và rất hài lòng với kết quả. Ngược lại, các dịch vụ nhạy cảm với độ trễ hoặc thuộc mảng tính toán hiệu năng cao thì không có lý do gì để ép chuyển, và chúng tôi cũng không cố nhồi nhét chúng vào
Mất bao lâu để thoát khỏi thứ này?
Nếu ứng dụng đã được microservice hóa rồi thì quay ngược lại cũng không đơn giản
Khi đọc một bài blog thản nhiên nhắc tới 6 dự án CNCF có tên nghe rất ngầu mà tôi chưa từng nghe, chỉ để đạt được một chức năng nhìn bề ngoài có vẻ đơn giản, tôi thấy mình như bị thời đại bỏ lại
Tôi nghiêm túc tự hỏi liệu đã đến lúc mình già đi và rời khỏi ngành phát triển phần mềm chuyên nghiệp chưa
Chỉ là bạn chưa quen với một cách tiếp cận để mở rộng tổ chức, tức cách các platform team trừu tượng hóa phần cứng, logging, retry, v.v.
Đây không phải cách tiếp cận duy nhất, nên có thể bạn quen với những cách khác
Tôi thích bài này vì nó giải thích rõ ràng và mạch lạc về lợi ích và lý do khi dùng Kubernetes
Nhiều team lao vào mà không biết mình sẽ nhận được gì, hay ban đầu có cần nó không; những lý do được đưa ra ở đây trông khá ổn
Các bình luận khác đã nêu điểm này: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Chỉ tò mò thật sự thôi, còn hệ thống hay dịch vụ hiện đại nào khác mà một người tỉnh táo có thể khoe rằng mình đã migration trong vòng 1 năm?
Những hệ thống như Kubernetes thường là lõi của hạ tầng, nên ảnh hưởng đến mọi thứ đang chạy. Cộng thêm các ràng buộc về đội ngũ được nêu trong bài, 1 năm nghe cũng không quá tệ
Ví dụ tôi nghĩ ra ngay là việc trước đây Amazon chuyển hoàn toàn khỏi Oracle sang cơ sở dữ liệu quan hệ của Amazon/mã nguồn mở. Nhưng tôi nhớ việc đó mất nhiều năm. Nếu hoàn tất trong vòng 1 năm thì chắc chắn họ đã khoe rồi
Thường vấn đề không nằm ở bản thân công nghệ, mà ở nợ kỹ thuật, độ phức tạp tích hợp và nhân lực được投入 vào