#134 - Hiểu rõ về Rolling Update một Deployment trong Kubernetes
Kính gửi các quý độc giả của Grokking Newsletter
Vậy là đã hơn hai năm kể từ ngày Grokking Newsletter ra mắt với bạn đọc và tới nay đã gửi tới quý bạn đọc hơn 130 số. Grokking Newsletter được lập ra với mục đích ban đầu nhằm nâng cao văn hóa đọc/viết của các bạn kỹ sư phần mềm. Tính từ những ngày đầu tiên ra mắt chỉ với 1500 bạn đọc, tới nay chúng tôi đã có hơn 7500 bạn đọc, và trung bình 30% trong số đó đọc email mỗi tuần. Đó thực sự là một trách nhiệm rất lớn để có thể cung cấp những bài viết hay và chất lượng tới các bạn đọc.
Từ những ngày đầu chỉ có một người, tới sau này đã có thêm nhiều bạn khác tham gia hỗ trợ trong việc chuẩn bị các nội dung. Các thành viên mới giúp cung cấp những bài viết đa dạng và phong phú hơn như mobile, frontend, machine learning. Thời gian đầu, mỗi tuần chỉ cần 5-7 tiếng để chuẩn bị newsletter, tới hiện tại trung bình một tuần, chúng tôi cần tối thiểu 10-15 tiếng để chuẩn bị nội dung của 1 số newsletter, với sự tham gia của 4-5 bạn trong team biên tập. Với một quy trình bắt đầu từ việc các thành viên sẽ đọc và tìm kiếm các bài viết hay. Sau đó các sẽ viết nội dung, và 1-2 bạn sẽ tổng hợp lại và soạn thành newsletter. Sau cùng 1 thành viên chính sẽ chịu trách nhiệm review và gửi đi tới hơn 7500 độc giả. Quy trình nhằm hạn chế tối đa các lỗi sai sót trong khâu biên tập cũng như đảm bảo được chất lượng tốt nhất.
Chúng tôi cũng nhận được sự hỗ trợ từ một số công ty trong việc sponsor, có thể kể tên như VNG, KMS, Kaligo. Xin cảm ơn quý công ty đã hỗ trợ chúng tôi rất nhiều trong thời gian qua.
Chúng tôi cũng đã nhận được khá nhiều những phản hồi từ bạn đọc, mong muốn đọc những bài viết có nội dung chuyên sâu hơn về kỹ thuật. Chúng tôi đã thêm một chuyên mục chuyên sâu hơn đó là "Góc Database", bắt đầu từ số 108. Chúng tôi cũng dự định sắp tới thêm các chuyên mục về Distributed System, Góc Machine Learning, v.v... Bên cạnh đó cũng là các bài viết của các thành viên core trong Grokking với các nội dung tự viết, và đào sâu về kỹ thuật, hoặc dịch lại phần lớn ý chính của các bài viết gốc từ tiếng Anh. Bên cạnh đó, chúng tôi cũng thực hiện Project Survey, để khảo sát nhóm bạn đọc của Newsletter, từ đó cung cấp các insight về cộng đồng, như về nhu cầu chuyển việc hay quy trình phỏng vấn.
Để làm được những việc này tốt hơn, chúng tôi tất nhiên sẽ cần những tài nguyên về mặt con người, đó là quan trọng nhất. Bên cạnh đó, chúng tôi cũng mong muốn nhận được sự giúp đỡ từ các bạn đọc của Grokking.
Vì thế chúng tôi dự định sẽ đưa ra phương án "Newsletter cho người dùng trả phí". Theo đó, những người dùng trả 1 khoản phí nhỏ sẽ trở thành người hỗ trợ cho team Grokking Newsletter, nhận được các bài viết sâu hơn và chi tiết hơn, được mời tham gia các meetup/workshop của team Core Grokking, cũng như tiếp cận các nội dung tới từ các team research của Grokking. Hiện tại, chúng tôi vẫn đang chỉ ở giai đoạn phác thảo kế hoạch. Mời các bạn dành 2 phút tham gia khảo sát sau để chúng tôi có thể xây dựng kế hoạch tốt hơn và phù hợp với nhu cầu thực tế của các bạn đọc.
https://forms.gle/Qo3rH2MxjNsvNekMA
Ngoài ra, các bạn cũng có thể cung cấp các ý kiến đóng góp trực tiếp tới email newsletter@grokking.org
Sau hơn 130 số của Grokking Newsletter, mặc dù vẫn còn nhiều điểm cần phải cải thiện, nhưng chúng tôi hy vọng đó là bằng chứng cho những nỗ lực của chúng tôi mang tới cho các bạn, cho một cộng đồng kỹ sư phần mềm tại Việt Nam với chất lượng ngày càng nâng cao.
Ban biên tập Grokking Newsletter
Những bài viết hay
Hiểu rõ về Rolling Update một Deployment trong Kubernetes — www.bluematador.com
Deployment Controllers là 1 loại Pod controller trong Kubernetes, giúp chúng ta kiểm soát một cách chi tiết việc thiết lập Pod, số lượng Pod, hay update các Pod như thế nào, … Trong quá trình phát triển ứng dụng, việc nâng cấp (Rolling Update) là không thể tránh khỏi. Vì vậy, việc nắm rõ các thiết lập để quá trình rolling update một cách chính xác là điều rất cần thiết.
Một lợi ích của việc sử dụng Deployment là giúp ta có thể kiểm soát quá trình rolling update. Rolling update cho phép ta thay đổi các thiết lập của Pods một cách từ từ và Deployment cung cấp nhiều lựa chọn cho quá tình này:
RollingUpdate: Pods mới (chứa những update của ứng dụng) sẽ được deployed dần và các pods cũ cũng sẽ được terminated dần.
Recreate: Tất cả pods cũ sẽ được terminated trước khi pods mới được deployed.
Khi sử dụng RollingUpdate strategy, có 2 lựa chọn giúp chúng ta giúp ta tránh việc downtime của ứng dụng:
maxSurge: số lượng pods được tạo ra vượt quá số lượng pods mong muốn
maxAvailable: số lượng pods tối đa có thể không hoạt động trong quá trình update
Ngoài ra, những lưu ý quan trọng cần phải được lưu ý trong quá trình RollingUpdate:
Thiết lập Readiness probe và liveness probe: chúng ta không nên để Pod trở nên ready ngay khi container bắt đầu chạy
Pod Affinity và Anti-affinity: cần hiểu rõ và cơ chế này trong Kubernetes. Một ứng dụng của thiết lập này là khi ta cần các Pods của ứng dụng chạy trên các node khác nhau. Tuy nhiên, việc không nắm rõ bản chất của Pod Affinity và Anti-affinity có thể khiến tất cả các pods chạy trên 1 node sau quá trình RollingUpdate.
A Multithreaded Fork of Redis That’s 5X Faster Than Redis — docs.keydb.dev
Kiến trúc tập trung vào sự đơn giản và đơn luồng của Redis đã khiến cho một số kĩ sư gặp khó khăn khi sử dụng Redis trong các hệ thống có lượng tải lớn của họ. Để tận dụng tối đa resource của server thường phải sử dụng cluster mode - làm tăng thêm độ phức tạp hạ tầng và thêm độ trễ cho các request tới Redis (vì phải đi qua thêm một đơn vị cân bằng tải).
Bài viết chia sẻ về KeyDB - một bản fork của Redis được phát triển từ năm 2019 với một trong những tính năng then chốt là khả năng chạy đa luồng có thể là một sự lựa chọn tốt để thay thế Redis trong các hệ thống lớn.
Let's build a Full-Text Search engine - Artem Krylysov — artem.krylysov.com
Hàng ngày ai cũng sẽ sử dụng full-text search (FTS) engine bằng cách này hay cách khác. Ví dụ như bạn search google hay search trên các trang e-commerce, tất cả đấy đều là các dạng FTS engine.
Với các bạn engineers thì chắc hầu như ai cũng đã sử dụng hoặc nghe tới Elasticsearch, Solr. Nhưng các bạn có bao giờ tò mò 1 FTS hoạt động như nào, hay muốn build 1 FTS đơn giản thì phải làm những gì.
Bài viết này tác giả hướng dẫn cách build 1 FTS đơn giản bằng Golang.
Code & Tools
Góc Database
What every developer should know about database consistency
Tính nhất quán (consistency) là một trong những tính chất quan trọng của một database transaction. Khi bạn thực hiện một write và sau đó là một read request đến hệ thống cơ sở dữ liệu phân tán, bạn mong muốn nhận được giá trị mới và chính xác nhất.
Việc đảm bảo tính nhất quán này được thực hiện bởi các database, tuy nhiên mỗi database sẽ có những phương án khác nhau.
Ví dụ như Cassandra cho phép bạn lựa chọn giữa một hiệu suất tốt hay khả năng đảm bảo nhất quán dữ liệu tốt nhất. Trong Cassandra, consistency level được định nghĩa là một số node tối thiểu công nhận một read/write operation trước khi operation đó được coi là thành công. Nếu số lượng node càng lớn, thời gian chờ để một request được coi là thành công sẽ càng lớn hơn.
Quotes
Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
- Antoine de Saint-Exupery