Hetzner
- Việc chuyển sang Hetzner chủ yếu nhằm cắt giảm chi phí. Mức giá của Hetzner có sức cạnh tranh trên toàn cầu.
- Hetzner cung cấp máy ảo và máy bare metal; tuy hạn chế hơn so với AWS nhưng bù lại bằng giá cả.
- Khi chuyển sang Hetzner, chi phí hạ tầng đã giảm hơn 75%.
Kubernetes trên Hetzner
Kubernetes tự quản lý
- Đã vận hành Kubernetes trên DigitalOcean và trên Hetzner cũng vận hành theo cách tự quản lý.
- Hetzner không cung cấp control plane Kubernetes được quản lý, nên phải tự quản trị.
- Sử dụng Terraform và Puppet để quản lý và cấu hình các node.
Vai trò của node
- Sử dụng quy tắc đặt tên node để giữ vai trò trong cụm đơn giản:
control-plane,worker,database. - Việc thêm vai trò thì đơn giản, nhưng có thể làm giảm hiệu quả sử dụng tài nguyên.
Xây dựng node
- Sử dụng Terraform để bootstrap cụm.
- Hetzner cung cấp tường lửa và mạng được quản lý, có thể cấu hình dễ dàng bằng Terraform.
- Máy chủ được quản lý hoàn toàn bằng Terraform, và việc viết module theo từng vai trò giúp thêm máy chủ trở nên đơn giản.
Mạng
- Sử dụng VPN Tailscale để thực hiện kết nối quản trị tới các node.
- Tailscale hỗ trợ NAT hole punching, cho phép kết nối an toàn ngay cả khi đã đóng các cổng.
- Sử dụng tường lửa được quản lý của Hetzner và UFW của Ubuntu để chặn cổng.
- Sử dụng Calico để cấu hình container networking interface.
Lưu trữ
- Hetzner cung cấp block storage dựa trên nVME SSD và SSD.
- Volume của Hetzner không có tính năng snapshot, vì vậy phải sao lưu dữ liệu thủ công.
- Trên các node cơ sở dữ liệu, sử dụng Local Persistence Volume Static Provisioner để pre-provision local volume.
Sao lưu
- Hetzner không cung cấp sao lưu volume nhưng có cung cấp sao lưu toàn bộ máy chủ.
- Sử dụng Velero của VMware để sao lưu namespace và PVC.
- Với Postgres, sử dụng pgBackRest.
Tính năng bổ sung
- Sử dụng SealedSecrets để quản lý bí mật.
- Sử dụng Node Exporter, Prometheus, Grafana, Loki để giám sát cụm.
- Sử dụng Alertmanager để tích hợp cảnh báo với Slack.
Suy nghĩ về việc vận hành Kubernetes trên Hetzner
- Việc chuyển sang Hetzner mất khoảng 1 tuần, và cần thêm 4 tuần để kiểm thử và tinh chỉnh.
- Giá của Hetzner là hợp lý và được tin là sẽ tiếp tục thấp hơn so với các nhà cung cấp khác.
- Hetzner có một số hạn chế về chất lượng IP và dịch vụ khách hàng.
- Hetzner phát hành tính năng mới khá nhanh, nhưng cũng có thể nhanh chóng ngừng các dịch vụ có lợi nhuận thấp.
- Các trung tâm dữ liệu ở Trung Âu nằm tại Falkenstein, Nuremberg của Đức và Helsinki của Phần Lan.
Tóm tắt
- Quá trình chuyển đổi diễn ra suôn sẻ, giúp giảm hơn 75% chi phí hạ tầng và tăng gấp đôi tài nguyên tính toán của cụm.
- Hetzner là một lựa chọn rất có lợi khi cần cắt giảm chi phí.
- Các controller mã nguồn mở của Hetzner giúp việc quản lý load balancer và gắn volume bền vững trở nên dễ dàng.
1 bình luận
Ý kiến trên Hacker News
Trong vài năm qua, chúng tôi đã cung cấp các cụm Kubernetes cho khách hàng bằng máy chủ dedicated của Hetzner, và hiệu năng rõ ràng rất tốt, thường giảm thời gian request xuống khoảng một nửa.
Vì phần cứng rẻ nên cũng có thể cung cấp thời gian kỹ thuật DevOps chuyên trách cho từng khách hàng, nhưng có vài điều kiện tiên quyết. Cụm staging để kiểm thử cập nhật gần như là bắt buộc, và không ai muốn đẩy cập nhật production vào Chủ nhật theo kiểu cầu may. Sao chép ở tầng ứng dụng là quan trọng nhất, tiếp theo là sao chép ở tầng block; chúng tôi đang dùng OpenEBS/Mayastor. Sau khi thử nhiều Postgres operator, hiện tại tôi thấy StackGres là tốt nhất.
Ansible playbook là tài sản; nếu được sắp xếp tốt và chú thích đầy đủ cho một dịch vụ cụ thể, sau này sẽ dễ triển khai lại cùng dịch vụ đó ở nơi khác. Nếu có thể, tôi khuyên dùng mạng 10G chuyên dụng để kết nối các máy chủ. 1G là không đủ khi gộp traffic production, image pull và traffic giữa các dịch vụ; độ trễ cũng cải thiện 10 lần so với liên lạc nội bộ trong availability zone của AWS.
Nếu cần dự phòng mạng, có thể tạo vSwitch (VLAN) 1G nội bộ trên cổng 1G, gán loopback IP cho từng máy chủ rồi phân phối route bằng BGP (bird). Cụm MinIO nếu vận hành đúng chuẩn qua operator thì không quá khó, và cung cấp object storage cục bộ có băng thông cao, độ trễ thấp. Khoản đầu tư ban đầu cần khoảng 2–4 tháng thời gian kỹ thuật của kỹ sư có kinh nghiệm và không bị gián đoạn; các việc phụ trợ phiền phức như cân bằng tải HTTP vẫn có thể chuyển cho nhà cung cấp cloud như CloudFlare.
Tài liệu công khai có tùy chọn uplink 10G nhưng là cho mạng bên ngoài, và giới hạn 20TB có vẻ khá chặt. Nếu là I/O nội bộ của cụm thì 20TB có thể dễ dàng trở thành vấn đề.
Tôi là nhân viên công ty đó, và chúng tôi đã xây dựng một nền tảng cung cấp cụm sẵn sàng production chỉ trong vài phút.
Nếu là công ty tư vấn thì hẳn họ muốn bán công việc đó, nhưng từ góc nhìn khách hàng, trừ khi chi phí AWS hằng tháng dự kiến khoảng 10.000 USD, việc này trông chẳng đáng chút nào. Làm tôi nhớ đến xkcd: https://xkcd.com/1319/
Tôi từng vận hành cụm Kubernetes trên máy chủ dedicated của Hetzner, và cũng từng làm việc với các dịch vụ được quản lý hoàn toàn hoặc ở mức cao như Aurora, S3, ECS Fargate.
Theo kinh nghiệm của tôi, hóa đơn cloud của Hetzner đôi khi có thể giảm xuống chỉ còn khoảng 20% so với AWS tương đương, nhưng lợi thế chi phí đó đi kèm đánh đổi lớn.
Trên Kubernetes của Hetzner, tôi đã quản lý cụm Ceph dùng lưu trữ NVMe, MariaDB operator, Cilium cho networking và ArgoCD để triển khai Helm chart. Cập nhật cụm Kubernetes cũng phải tự xử lý, và có lần tôi còn gặp sự cố sập toàn bộ cụm. Tôi gặp nhiều bug ở cả Kubernetes lẫn Ceph, nhiều bug trong số đó đã được ghi nhận trong GitHub issue và Ceph tracker. Danh sách việc cần quản lý và giám sát là vô tận; tùy vào số lượng workload và độ phức tạp của môi trường, việc duy trì cấu hình như vậy có thể trở thành công việc toàn thời gian của đội DevOps.
Ngược lại, dùng AWS hoặc các nhà cung cấp cloud lớn khác cho phép cấu hình ít phải động tay hơn nhiều. Dùng dịch vụ được quản lý giúp giảm đáng kể công sức bảo trì, từ đó giảm gánh nặng vận hành cho đội ngũ. Rốt cuộc, AWS giảm mạnh khối lượng công việc DevOps, còn Hetzner giảm mạnh hóa đơn cloud. Bên nào hiệu quả chi phí hơn cần được phân tích tổng chi phí sở hữu (TCO); dù ban đầu Hetzner trông rẻ, thời gian DevOps phát sinh có thể bù hết khoản tiết kiệm.
Ví dụ, nếu so sánh cấu hình 2 vCPU, 4GB với cấu hình tương tự trên AWS thì AWS đắt hơn rất nhiều; tôi muốn xem phân tích chi phí. Cũng có công cụ giúp giảm gánh nặng vận hành như https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner.
Việc tìm nguyên nhân gốc cũng không dễ, trên mạng có nhiều lệnh kiểu bùa chú cần dùng để khôi phục, nhưng tôi chỉ xóa sạch và tạo lại cụm. Sau đó cứ vài tuần tôi lại làm vậy. Người vận hành Kubernetes thực thụ hẳn sẽ có tự động nâng cấp chứng chỉ và nhiều công cụ khác, nhưng nếu là công ty thì có lẽ phải trả tiền cho những người vận hành như vậy.
Tôi biết có nơi dùng nó, nhưng so với các hệ thống trưởng thành như Lustre hay GPFS thì đúng là lãng phí thời gian khủng khiếp. Thà xuất nhiều filesystem nhỏ qua NFS và đảm bảo sao chép ở tầng block còn hơn. Filesystem có không gian địa chỉ đơn nhất thì tiện, nhưng trong nhiều trường hợp không đáng gánh chi phí quản trị để làm cho nó ổn định ở quy mô lớn. Giống như sharding cơ sở dữ liệu, filesystem cũng nên được sharding, và có thể dễ dàng thêm logic ánh xạ trong Kubernetes để gắn đúng storage vào đúng image.
Nó giảm đáng kể gánh nặng DevOps trong khi vẫn có được cả hiệu năng và độ linh hoạt của bare metal. Đây là một mô hình hybrid tuyệt vời giữa dịch vụ đắt đỏ được quản lý hoàn toàn và tự dựng hoàn toàn. Chi phí khá cao nên có thể không phải lựa chọn tốt cho startup, nhưng nếu là cụm cỡ từ 72GB RAM hoặc 36 CPU trở lên, khoảng 9 node cỡ trung, thì chắc chắn đáng cân nhắc thứ như OpenShift.
Vấn đề volume của Hetzner quá chậm cho cơ sở dữ liệu production thực ra có thể giải quyết dễ hơn tưởng. Chỉ cần dùng các máy bare-metal rất rẻ của Hetzner làm node là được
Các máy có lưu trữ NVMe thường cho hiệu năng cơ sở dữ liệu rất tốt và cũng hay có RAM dồi dào. Thậm chí thay vì chạy cơ sở dữ liệu trong Kubernetes, có khi tốt hơn là đặt ít nhất hai máy bare-metal vững chắc cho cấu hình master-replica. Nếu ngại cấu hình, có thể dùng các gói hiện đại như Pigsty: https://pigsty.cc/
Có thể ghim database pod vào một node cụ thể và dùng LocalPathProvisioner, hoặc dùng các giải pháp phân tán như JuiceFS, OpenEBS
Hướng dẫn tôi viết cho khách hàng ở đây: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
Tôi đã dùng Hetzner hơn 10 năm và khá hài lòng; trước đây dùng server dedicated ở các datacenter Đức, rồi chuyển sang Cloud US VM để giảm độ trễ tại Mỹ
Gần đây việc 20TB traffic miễn phí vốn rất rộng rãi bị giảm còn 3TB và tính thêm €1,19 cho mỗi TB bổ sung thì hơi thất vọng, nhưng so với các nhà cung cấp cloud ở Mỹ khác mà tôi đã đánh giá, họ vẫn có vẻ đáng tiền hơn nhiều
Tôi sẽ không nhất thiết chọn Kubernetes, nhưng đã chuyển thành công quy trình triển khai SSH/Docker Compose hiện có sang GitHub Actions và kamal-deploy.org. Việc cấu hình dễ, và các công cụ UX để theo dõi ứng dụng triển khai từ xa cũng tốt: https://servicestack.net/posts/kamal-deployments
Datacenter ở Đức vẫn cung cấp 20TB băng thông: https://www.hetzner.com/cloud/
Nhưng ở Mỹ thì cùng mức giá lại ít hơn hơn một bậc độ lớn
Trước đây tôi tự sửa xe vì muốn tiết kiệm tiền và cũng thấy vui, nhưng nó phức tạp hơn tưởng và theo thời gian tôi làm hỏng hoặc làm gãy chỗ này chỗ kia
Tôi đã mất rất nhiều thời gian để “sửa lại”, và có lẽ đã chi vài nghìn đô la cho dụng cụ trong vài năm. Còn có cả chi phí thay thế vì dụng cụ rẻ tiền bị gãy hoặc nhanh rỉ sét, và xe thì thỉnh thoảng lại nằm trên giá đỡ. Dù vậy tôi học được nhiều bài học tuyệt vời, trong đó bài học lớn nhất là có những việc không đáng tự làm. Nếu đó là thứ ảnh hưởng đến sinh kế, tốt hơn nên giao cho thợ hoặc thuê xe dài hạn
Ngay cả việc đơn giản như thay dầu cũng không mấy đáng để tự làm. Bạn phải mua các dụng cụ như khay hứng dầu, cờ lê lọc dầu, phễu, ván nằm sửa xe, sắp xếp thời gian, tìm quần áo lao động bẩn, ra cửa hàng mua dầu và lọc mới, về nhà thay, rồi trong ngày đó hoặc ngày khác mang dầu thải đến cửa hàng nhận xử lý. Trong khi đó ở garage, chỉ cần trả thêm khoảng 15 đô la so với tiền dầu và lọc là xong trong 20 phút
Kubernetes là cả một chiếc xe, lại còn là một chiếc xe phức tạp. Nếu không làm vì vui thì thật sự không đáng tự bảo trì
Phần thưởng khá đáng kể và đây là kỹ năng đáng học. Việc hàng xóm có cầu nâng ô tô rõ ràng cũng giúp nhiều
Điểm mấu chốt là tìm được cân bằng giữa việc tự làm và việc thuê ngoài, và nó không dễ hay gọn gàng như ở đây nói
Từ góc nhìn của một consultant thường xuyên tham gia Kubernetes, tốt nhất là vừa có kênh hỗ trợ ban đầu và hỗ trợ liên tục, vừa có người trong nội bộ đủ hứng thú để cùng học
Consultant và chuyên gia có thể giúp tránh các quyết định tệ lúc đầu và giảm việc đâm đầu vào tường suốt vài tháng. Khi còn phải tập trung vào mảng kinh doanh cốt lõi, không dễ gì nắm được trong thời gian hợp lý các góc khuất và cạm bẫy phổ biến của một công nghệ hay hệ sinh thái. Hãy nhận trợ giúp, nhưng cũng phải học cách bắt cá và nhóm lửa
Bài viết thú vị, nhưng có cảm giác thiếu phần mô tả cụm và workload chạy trên đó
Tôi tò mò có bao nhiêu node, nhận bao nhiêu traffic, yêu cầu về uptime và độ trễ là gì. Và số tiền tiết kiệm tuyệt đối cũng quan trọng. Tiết kiệm 75% của 100.000 đô la/tháng và 75% của 100 đô la/tháng là hai chuyện hoàn toàn khác nhau
Thực tế tôi xem 100.000 đô la/tháng là điểm rẽ. Tức 1,2 triệu đô la/năm
Để hỗ trợ đúng nghĩa một triển khai bare-metal tinh vi, lương kỹ sư sẽ tốn khoảng 400.000 đô la/năm, cộng với cam kết datacenter, khấu hao phần cứng và băng thông khoảng 100.000 đô la/năm. Những người này thường trong khi làm việc đó cũng tạo ra giá trị lớn cho các phần khác của doanh nghiệp, nên chi phí thực tế có thể thấp hơn. Như vậy tiết kiệm được 700.000 đô la/năm là rất tốt, và khi mức chi tiêu cloud tương đương càng cao hơn thì lợi ích càng lớn
Hơn 10 năm trước, khi còn làm ở mảng web hosting, tôi thường phải blackhole IP của Hetzner vì các hành vi xấu
Các nhà cung cấp VM giá rẻ khác cũng tương tự, hoàn toàn do hành vi chứ không liên quan gì đến cơ sở dữ liệu địa lý. Rẻ là có lý do
Tôi thích tính năng của sản phẩm, nhưng uy tín IP của gói miễn phí thì tệ hại, đặc biệt email gần như không được Hotmail hay Yahoo chấp nhận. Dịch vụ hosting miễn phí bị spammer và kẻ lừa đảo áp đảo; dịch vụ giá rẻ cũng tương tự, chỉ là mức độ nhẹ hơn. Giá càng cao thì càng ít bị dùng cho lừa đảo và spam
AWS, Google, DigitalOcean, Linode, Contabo, v.v. cũng host rất nhiều cuộc tấn công brute-force đăng nhập và quét các lỗ hổng phổ biến
Tôi làm ở một công ty tư vấn hỗ trợ doanh nghiệp xây dựng hạ tầng và bảo mật, và có nhiều khách hàng vận hành Kubernetes trên các nhà cung cấp giá rẻ như Hetzner, các nhà cung cấp tầm trung trong khu vực, cũng như ba cloud lớn AWS/GCP/Azure
Cũng có các công ty chính phủ, tài chính, y tế không thể hoặc không muốn vận hành trên public cloud, nên thường host on-premise
Nếu Hetzner mỗi tháng có một sự cố hoặc lỗi, thì nhà cung cấp tầm trung khoảng 2–3 tháng một lần, còn nơi như AWS khoảng 5–6 tháng một lần. Tuy nhiên giá cũng biến động tương tự với quan sát đó, nên cần cân nhắc kỹ theo từng trường hợp xem việc bổ sung thiết bị, backup và kịch bản sự cố có phải là lựa chọn đáng hơn không
Một lợi thế lớn của việc dùng dịch vụ hosting cơ bản là khả năng dự đoán chi phí cao hơn nhiều. Bạn trả tiền thiết bị và mở rộng khi cần. Nếu bị buộc vào các dịch vụ bổ sung của nhà cung cấp như AWS, bạn có thể nhận hóa đơn lớn ngoài dự kiến và cũng khó thoát ra hơn nhiều. Nếu là công ty nhỏ, tốt nhất đừng vì giải pháp dễ dàng ban đầu hay “credit miễn phí” mà đưa ra quyết định thiển cận đe dọa khả năng tồn tại lâu dài
Ở đây không có đáp án đúng, chỉ có đánh đổi
Tôi chưa tự dùng, nhưng https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner có vẻ là một cách tuyệt vời để thiết lập và quản lý Kubernetes trên Hetzner
Hiện tôi đang dùng gói miễn phí của Oracle, nhưng vẫn luôn nghĩ đến việc chuyển sang hướng này để rời khỏi Oracle
Nó hoạt động khá tốt. Tôi cũng đặt lịch reboot máy vào Chủ nhật hằng tuần để cập nhật bảo mật tự động trên SuSE MicroOS. Tôi đã thử mở rộng máy theo mức tăng workload. Bạn nhất thiết phải rà soát mọi thay đổi mà Terraform định thực hiện, nhưng nếu làm vậy thì khá an toàn
Nhược điểm duy nhất là mọi node đều cần IP công khai dù chúng nằm sau firewall, nhưng phần này đang được xử lý
Chỉ sau một đêm cluster đã chạy và hoạt động khá tốt. Một vấn đề nhỏ là cập nhật tự động không chạy trên node arm; lúc đó tôi chỉ chạy một node duy nhất và do taint của control plane nên update pod không chạy được và bị kẹt
https://github.com/syself/cluster-api-provider-hetzner
Hoạt động rất ổn định
Tôi tò mò không biết có điểm bất tiện cụ thể nào khiến bạn muốn chuyển đi không
Tôi không nghĩ nhận định rằng DigitalOcean, giống các nhà cung cấp khác, cung cấp control plane được quản lý miễn phí nhưng thường cộng markup 100% vào node của managed cluster là đúng
Trên DigitalOcean, chi phí worker node bằng với Droplet thông thường và không có phí bổ sung. Vì vậy cách DigitalOcean cung cấp khá hấp dẫn: control plane miễn phí không cần lo, nâng cấp miễn phí, cùng các tích hợp bổ sung như load balancer và storage. Tôi khó nghĩ ra lý do để không chọn nó thay vì tự quản lý
CPU chia sẻ 8GB RAM của Hetzner khoảng 10 đô la, còn cấu hình tương đương của DigitalOcean là 48 đô la
Nếu muốn trải nghiệm managed trên Hetzner, bạn có thể xem https://syself.com. Tôi là nhân viên của công ty đó