[maintain] Merge main into dev-ja

.github/settings.yml

@@ -223,13 +223,13 @@ collaborators:
   - username: aliok
     permission: push
 
-  - username: symys
+  - username: canogluonur
     permission: push
 
-  - username: rwxdash
+  - username: mertssmnoglu
     permission: push
 
-  - username: eminalemdar
+  - username: alianait
     permission: push
 
   # l10n ru approvers
@@ -527,9 +527,9 @@ branches:
         # tr approvers
         users:
          - aliok
-         - symys
-         - rwxdash
-         - eminalemdar
+         - canogluonur
+         - mertssmnoglu
+         - alianait
         teams: []
       enforce_admins: null
       required_linear_history: null

.github/workflows/es-spellcheck.yml

@@ -29,6 +29,6 @@ jobs:
           set -o errexit
           diff content/es/.wordlist.txt <(LC_ALL= sort -f content/es/.wordlist.txt)
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.49.0
+        uses: rojopolis/spellcheck-github-actions@0.51.0
         with:
           config_path: content/es/.spellcheck.yml

.github/workflows/post-outdated-content-report.yaml

@@ -50,7 +50,7 @@ jobs:
 #     - name: Download output
 #       uses: actions/download-artifact@v3
     - name: Download output
-      uses: dawidd6/action-download-artifact@v9
+      uses: dawidd6/action-download-artifact@v11
       with:
         github_token: ${{secrets.GITHUB_TOKEN}}
         workflow: check-outdated-content.yaml

.github/workflows/spellcheck.yml

@@ -25,4 +25,4 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.49.0
+        uses: rojopolis/spellcheck-github-actions@0.51.0

CODEOWNERS

@@ -63,8 +63,8 @@
 /i18n/ru.toml @shurup @kirkonru @tym83
 
 # Approvers for Turkish contents
-/content/tr/ @aliok @symys @rwxdash @eminalemdar
-/i18n/tr.toml @aliok @symys @rwxdash @eminalemdar
+/content/tr/ @aliok @canogluonur @mertssmnoglu @alianait
+/i18n/tr.toml @aliok @canogluonur @mertssmnoglu @alianait
 
 # Approvers for Urdu contents
 /content/ur/ @Saim-Safdar @waleed318

content/en/operator.md

@@ -0,0 +1,40 @@
+---
+title: Kubernetes Operator
+status: Completed
+category: concept
+tags: ["infrastructure"]
+---
+
+A Kubernetes Operator is a helper program that runs inside a Kubernetes cluster 
+and extends its capabilities without modifying the core code, 
+enabling the automated installation and management of complex applications and resources.
+
+## Problem it addresses
+
+When we want to run a complex [stateful](/stateful-apps/) application like a database cluster for instance, 
+we need to take care of a lot of operational tasks in order to keep it up and running. 
+This is especially true for properties like the high availability and the zero downtime. 
+How does the cluster behave in case of an update or failure? 
+How can we securely scale it up or down? 
+These are things that are very specific to the type of technology, 
+because not every database cluster for instance behaves the same way in case of scaling or failure. 
+That is why Kubernetes cannot provide a general handling of these scenarios. 
+Also, this knowledge is usually known and executed by a human administrator or also called operator.  
+But in the highly automated cloud native world we cannot always afford to be dependent on manual interactions of a person to do these critical operations. 
+
+## How it helps
+
+The Kubernetes Operator is basically an abstraction, a model, 
+that allows us to build resources that can be used to help us with the above mentioned problems. 
+Typically, existing operators provide a set of new resources - known as CRDs (Custom Resource Definition) - 
+as well as components that are responsible for keeping the actual state of the cluster in sync with the desired state. 
+If we take a database cluster operator for instance, 
+these components know exactly how to scale this cluster up and down 
+and what to do if it crashes etc. 
+This way we don't need to be experts in that specific technology in order to use it in our Kubernetes cluster and make use of scaling or other specific features. 
+
+## Related terms
+
+* [Stateless applications](/stateless-apps/)
+* [Stateful applications](/stateful-apps/)
+* [Clusters](/cluster/)

content/vi/_index.md

@@ -48,7 +48,7 @@ và [Junya Okabe](https://www.linkedin.com/in/junya-okabe/).
 là những Maintainer Danh dự, và chúng tôi vô cùng biết ơn
 những đóng góp quý báu của họ trong suốt những năm qua.
 
-Bản dịch tiếng Việt của Cloud Native Glossary đã được khởi xướng nhờ sự đóng góp của [The Anh Nguyen](https://www.linkedin.com/in/ntheanh201/), [Thuan Pham Tien](https://www.linkedin.com/in/tienthuan05082002/), [Phuong Thao Nguyen](https://www.linkedin.com/in/nguyenphuongthao0/), [trieungoctam](https://www.linkedin.com/in/trieungoctam/), [Huan Nguyen Danh](https://www.linkedin.com/in/huannd2301/). Nếu bạn quan tâm đến việc dịch và bản địa hóa Cloud Native Glossary sang tiếng Việt, vui lòng tham gia kênh [#glossary-localization-vietnamese](https://cloud-native.slack.com/archives/C08NAHYA6KX).
+Bản dịch tiếng Việt của Cloud Native Glossary đã được khởi xướng nhờ sự đóng góp của [The Anh Nguyen](https://www.linkedin.com/in/ntheanh201/), [Thuan Pham Tien](https://www.linkedin.com/in/tienthuan05082002/), [Phuong Thao Nguyen](https://www.linkedin.com/in/nguyenphuongthao0/), [trieungoctam](https://www.linkedin.com/in/trieungoctam/), [Huan Nguyen Danh](https://www.linkedin.com/in/huannd2301/), [Trung Thi Phuong](https://www.linkedin.com/in/phuong-trung-thi-9bba12215/). Nếu bạn quan tâm đến việc dịch và bản địa hóa Cloud Native Glossary sang tiếng Việt, vui lòng tham gia kênh [#glossary-localization-vietnamese](https://cloud-native.slack.com/archives/C08NAHYA6KX).
 
 ## Giấy phép
 

content/vi/auto-scaling.md

@@ -0,0 +1,21 @@
+---
+title: Tự động mở rộng (Autoscaling)
+status: Completed
+category: property
+tags: ["infrastructure", "", ""]
+---
+
+Tự động mở rộng là khả năng của một hệ thống có thể [mở rộng](/scalability/) tự động, thường là về mặt tài nguyên tính toán. Với một hệ thống có khả năng tự động mở rộng, tài nguyên sẽ được bổ sung tự động khi cần và có thể mở rộng để đáp ứng sự biến động về lượng nhu cầu người dùng.
+Quy trình tự động mở rộng có thể khác nhau và có thể cấu hình để mở rộng dựa trên các chỉ số khác biệt, chẳng hạn như bộ nhớ hoặc thời gian xử lý. Các dịch vụ đám mây được quản lý thường đi kèm với chức năng tự động mở rộng vì có nhiều lựa chọn và cách triển khai hơn so với hầu hết các hệ thống triển khai tại chỗ (on-premise deployments).
+
+Trước đây, hạ tầng và ứng dụng được thiết kế để tính đến mức sử dụng hệ thống cao nhất. Kiến trúc này khiến nhiều tài nguyên bị sử dụng không hiệu quả và thiếu khả năng co giãn trước sự thay đổi lượng nhu cầu người dùng. Sự thiếu linh hoạt này dẫn đến chi phí cao hơn cho doanh nghiệp và mất doanh thu do hệ thống ngừng hoạt động khi vượt quá tải.
+
+Bằng cách tận dụng điện toán đám mây, [ảo hoá](/virtualization/) và [container hóa](/containerization/) các ứng dụng cùng các phần phụ thuộc, các tổ chức có thể xây dựng ứng dụng có khả năng mở rộng theo nhu cầu người dùng. Họ có thể theo dõi nhu cầu sử dụng ứng dụng và tự động mở rộng, mang lại trải nghiệm người dùng tối ưu.
+Lấy ví dụ về sự gia tăng lượt xem mà Netflix ghi nhận vào mỗi tối thứ Sáu. Mở rộng theo chiều ngang (autoscaling out) có nghĩa là tự động bổ sung thêm tài nguyên: ví dụ, tăng số lượng máy chủ để cho phép phát video nhiều hơn, và thu hẹp lại khi mức sử dụng trở về bình thường.
+
+## Thuật ngữ liên quan
+
+* [Mở rộng theo chiều ngang](/horizontal-scaling/)
+* [Mở rộng theo chiều dọc](/vertical-scaling/)
+
+{{% sign-language-section cGONmC1smaM %}}

content/vi/continuous-delivery.md

@@ -0,0 +1,35 @@
+---
+title: Phân phối liên tục (Continuous Delivery - CD)
+status: Completed
+category: concept
+tags: ["methodology", "application", ""]
+---
+
+Phân phối liên tục (Continuous delivery), thường được viết tắt là CD, là một tập hợp các phương pháp
+trong đó các thay đổi mã nguồn được tự động triển khai vào môi trường kiểm thử (acceptance environment)
+(hoặc, trong trường hợp triển khai liên tục, vào môi trường sản xuất).
+CD bao gồm các quy trình quan trọng để đảm bảo phần mềm được kiểm thử đầy đủ
+trước khi triển khai và cung cấp cách thức để hoàn tác các thay đổi nếu cần thiết.
+[Tích hợp liên tục](/continuous-integration/) (CI) là bước đầu tiên hướng tới
+phân phối liên tục (tức là, các thay đổi phải được hợp nhất một cách sạch sẽ trước khi được kiểm thử và
+triển khai).
+
+## Vấn đề nó giải quyết
+
+Triển khai các bản cập nhật [đáng tin cậy](/reliability/) trở thành vấn đề khi mở rộng quy mô.
+Lý tưởng nhất, chúng ta nên triển khai thường xuyên hơn để mang lại giá trị tốt hơn cho người dùng cuối.
+Tuy nhiên, thực hiện thủ công dẫn đến chi phí giao dịch cao cho mỗi thay đổi.
+Trong quá khứ, để tránh những chi phí này, các tổ chức đã phát hành ít thường xuyên hơn,
+triển khai nhiều thay đổi cùng một lúc và làm tăng nguy cơ xảy ra sự cố.
+
+## Lợi ích mang lại
+
+Các chiến lược CD tạo ra một lối đi hoàn toàn tự động đến môi trường sản xuất
+để kiểm thử và triển khai phần mềm bằng cách sử dụng các chiến lược triển khai khác nhau
+như [canary](/canary-deployment/) hoặc [blue-green](/blue-green-deployment/).
+Điều này cho phép các nhà phát triển triển khai mã nguồn thường xuyên, giúp họ yên tâm rằng phiên bản mới đã được kiểm thử.
+
+## Thuật ngữ liên quan
+
+* [Tích hợp liên tục](/continuous-integration/)
+* [Triển khai liên tục](/continuous-deployment/)

content/vi/continuous-deployment.md

@@ -0,0 +1,33 @@
+---
+title: Triển khai liên tục (Continuous Deployment - CD)
+status: Completed
+category: concept
+tags: ["application", "methodology", ""]
+---
+
+Triển khai liên tục (Continuous Deployment), thường được viết tắt là CD, là một bước xa hơn của [phân phối liên tục](/continuous-delivery/)
+bằng cách triển khai phần mềm hoàn chỉnh trực tiếp vào môi trường sản xuất.
+Triển khai liên tục (CD) đi đôi với [tích hợp liên tục](/continuous-integration/) (CI),
+và thường được gọi là CI/CD.
+Quy trình CI kiểm tra xem các thay đổi đối với một ứng dụng nhất định có hợp lệ hay không,
+và quy trình CD tự động triển khai các thay đổi mã nguồn qua các môi trường của tổ chức từ kiểm thử đến production.
+
+## Vấn đề nó giải quyết
+
+Phát hành các phiên bản phần mềm mới có thể là một quá trình tốn nhiều công sức và dễ xảy ra lỗi.
+Đây cũng thường là điều mà các tổ chức chỉ muốn thực hiện không thường xuyên để tránh các sự cố trên môi trường production
+và giảm số lượng thời gian kỹ sư cần phải làm việc ngoài giờ làm việc thông thường.
+Các mô hình triển khai phần mềm truyền thống khiến các tổ chức rơi vào một vòng luẩn quẩn
+trong đó quy trình phát hành phần mềm không đáp ứng được nhu cầu của tổ chức về cả tính ổn định và tốc độ phát triển tính năng.
+
+## Lợi ích mang lại
+
+Bằng cách tự động hóa chu kỳ phát hành và buộc các tổ chức phải phát hành lên môi trường sản xuất thường xuyên hơn,
+CD mang lại cho các nhóm vận hành những lợi ích tương tự như CI đã mang lại cho các nhóm phát triển.
+Cụ thể, nó buộc các nhóm vận hành phải tự động hóa các phần triển khai trên môi trường production khó khăn và dễ xảy ra lỗi, giảm rủi ro tổng thể.
+Nó cũng giúp các tổ chức chấp nhận và thích ứng tốt hơn với các thay đổi trên môi trường production, dẫn đến tính ổn định cao hơn.
+
+## Thuật ngữ liên quan
+
+* [Tích hợp liên tục](/continuous-integration/)
+* [Phân phối liên tục](/continuous-delivery/)

content/vi/continuous-integration.md

@@ -0,0 +1,31 @@
+---
+title: Tích hợp liên tục (Continuous integration - CI)
+status: Completed 
+category: concept
+tags: ["application", "methodology", ""]
+---
+
+Tích hợp liên tục (Continuous integration), thường được viết tắt là CI, là phương pháp tích hợp các thay đổi mã nguồn thường xuyên nhất có thể.
+CI là điều kiện tiên quyết cho [phân phối liên tục](/continuous-delivery/) (CD).
+Thông thường, quy trình CI bắt đầu khi các thay đổi mã nguồn được commit vào hệ thống kiểm soát mã nguồn (Git, Mercurial, hoặc Subversion)
+và kết thúc với một sản phẩm đã được kiểm thử sẵn sàng để được sử dụng bởi hệ thống CD.
+
+## Vấn đề nó giải quyết
+
+Các hệ thống phần mềm thường lớn và phức tạp, với nhiều nhà phát triển bảo trì và cập nhật chúng.
+Làm việc song song trên các phần khác nhau của hệ thống,
+các nhà phát triển này có thể tạo ra các thay đổi xung đột và vô tình phá vỡ công việc của nhau.
+Ngoài ra, với nhiều nhà phát triển làm việc trên cùng một dự án,
+bất kỳ công việc hàng ngày nào như kiểm thử và đánh giá chất lượng mã nguồn đều cần được lặp lại bởi mỗi nhà phát triển, lãng phí thời gian.
+
+## Lợi ích mang lại
+
+Phần mềm CI tự động kiểm tra xem các thay đổi mã nguồn có được hợp nhất một cách sạch sẽ hay không mỗi khi nhà phát triển commit một thay đổi.
+Đó là một phương pháp gần như phổ biến để sử dụng máy chủ CI để chạy đánh giá chất lượng mã nguồn, kiểm thử, và thậm chí là triển khai.
+Do đó, nó trở thành một cách triển khai cụ thể của quy trình kiểm soát chất lượng trong các nhóm.
+CI cho phép các nhóm phần mềm biến mỗi lần commit mã nguồn thành một thất bại rõ ràng hoặc một bản phát hành khả thi.
+
+## Thuật ngữ liên quan
+
+* [Phân phối liên tục](/continuous-delivery/)
+* [Triển khai liên tục](/continuous-deployment/)

content/vi/distributed-apps.md

@@ -0,0 +1,16 @@
+---
+title: Ứng dụng phân tán
+status: Completed
+category: concept
+tags: ["architecture", "", ""]
+---
+
+Một distributed application (ứng dụng phân tán) là ứng dụng mà chức năng được chia nhỏ thành nhiều thành phần độc lập. Các ứng dụng phân tán thường được cấu thành từ các [microservice](/microservices-architecture/), mỗi microservice đảm nhận một chức năng riêng biệt trong tổng thể ứng dụng. Trong môi trường cloud native, các thành phần này thường chạy dưới dạng [container](/container/) trên một [cluster](/cluster/).
+
+## Vấn đề nó giải quyết
+
+Một ứng dụng chạy trên một máy đơn lẻ sẽ trở thành single point of failure — nếu máy đó gặp sự cố, toàn bộ ứng dụng sẽ không thể truy cập được. Distributed application thường được so sánh với [monolithic application](/monolithic-apps/) (ứng dụng nguyên khối). Một ứng dụng monolithic thường khó mở rộng hơn vì các thành phần bên trong không thể mở rộng một cách độc lập. Ngoài ra, khi ứng dụng phát triển lớn dần, việc phát triển cũng trở nên chậm hơn do nhiều lập trình viên phải cùng làm việc trên một shared codebase (mã nguồn dùng chung) mà không nhất thiết phải có các rằng buộc được định nghĩa rõ ràng 
+
+## Lợi ích mang lại
+
+Khi tách một ứng dụng thành nhiều thành phần khác nhau và chạy chúng ở nhiều nơi, hệ thống tổng thể có thể chịu được nhiều lỗi hơn. Cách tiếp cận này cũng cho phép ứng dụng tận dụng các khả năng scaling mà một phiên bản đơn lẻ không có, đặc biệt là khả năng [horizontal scaling](/horizontal-scaling/) (mở rộng theo chiều ngang). Tuy nhiên, điều này cũng đi kèm với cái giá phải trả: độ phức tạp và gánh nặng vận hành tăng lên — thay vì chỉ chạy một ứng dụng duy nhất, bạn giờ phải quản lý nhiều thành phần ứng dụng riêng biệt. 

content/vi/immutable-infrastructure.md

@@ -0,0 +1,10 @@
+---
+title: Hạ tầng bất biến (Immutable Infrastructure)
+status: Completed
+category: property
+tags: ["infrastructure", "property", ""]
+---
+
+Hạ tầng bất biến (Immutable Infrastructure) đề cập đến hạ tầng máy tính (như [máy ảo](/virtual-machine/), [containers](/container/), thiết bị mạng) không thể thay đổi sau khi đã được triển khai. Điều này có thể đạt được thông qua thực thi một quy trình tự động ghi đè các thay đổi không được phép hoặc thông qua một hệ thống không cho phép thay đổi ngay từ đầu. Containers là một ví dụ điển hình của Immutable Infrastructure vì mọi thay đổi bền vững lên container chỉ có thể thực hiện bằng cách tạo một phiên bản mới của container hoặc khởi tạo lại container hiện tại từ image của nó.
+
+Bằng cách ngăn chặn hoặc phát hiện các thay đổi trái phép, Immutable Infrastructure giúp việc nhận diện và giảm thiểu rủi ro bảo mật trở nên dễ dàng hơn. Việc vận hành hệ thống này cũng trở nên đơn giản hơn vì quản trị viên có thể đưa ra các giả định về hệ thống, bởi họ biết rằng không ai thực hiện thay đổi hoặc mắc lỗi mà quên thông báo. Immutable Infrastructure thường đi đôi với [infrastructure as code](/infrastructure-as-code/), nơi toàn bộ tự động hoá cần thiết để tạo ra hạ tầng đều được lưu trữ trong version control (ví dụ: Git). Sự kết hợp giữa tính bất biến và version control này đảm bảo rằng luôn có một audit log bền vững cho mọi thay đổi được phép trên hệ thống.