diff --git a/content/vi/docs/reference/glossary/addons.md b/content/vi/docs/reference/glossary/addons.md new file mode 100644 index 0000000000000..d9994a1a74381 --- /dev/null +++ b/content/vi/docs/reference/glossary/addons.md @@ -0,0 +1,16 @@ +--- +title: Add-ons +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + Tài nguyên mở rộng chức năng của Kubernetes. + +aka: +tags: +- tool +--- + Tài nguyên mở rộng chức năng của Kubernetes. + + +[Cài đặt addons](/docs/concepts/cluster-administration/addons/) giải thích thêm về việc sử dụng add-on với cluster của bạn, và liệt kê một số add-on phổ biến. diff --git a/content/vi/docs/reference/glossary/ingress.md b/content/vi/docs/reference/glossary/ingress.md new file mode 100644 index 0000000000000..fe0f537bb8218 --- /dev/null +++ b/content/vi/docs/reference/glossary/ingress.md @@ -0,0 +1,19 @@ +--- +title: Ingress +id: ingress +date: 2018-04-12 +full_link: /docs/concepts/services-networking/ingress/ +short_description: > + Một đối tượng API quản lý truy cập bên ngoài đến các dịch vụ trong cluster, thường là HTTP. + +aka: +tags: +- networking +- architecture +- extension +--- + Một đối tượng API quản lý truy cập bên ngoài đến các dịch vụ trong cluster, thường là HTTP. + + + +Ingress có thể cung cấp các tính năng như cân bằng tải, SSL termination và virtual hosting dựa trên tên miền. diff --git a/content/vi/docs/reference/glossary/persistent-volume.md b/content/vi/docs/reference/glossary/persistent-volume.md new file mode 100644 index 0000000000000..4839ff7ab7987 --- /dev/null +++ b/content/vi/docs/reference/glossary/persistent-volume.md @@ -0,0 +1,18 @@ +--- +title: Persistent Volume +id: persistent-volume +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + Một đối tượng API đại diện cho một phần lưu trữ trong cluster. Được cung cấp như một tài nguyên chung có thể kết nối được và tồn tại độc lập với vòng đời của bất kỳ Pod riêng lẻ nào. + +aka: +tags: +- core-object +- storage +--- + Một đối tượng API đại diện cho một phần lưu trữ trong cluster. Được cung cấp như một tài nguyên chung có thể kết nối được và tồn tại độc lập với vòng đời của bất kỳ {{< glossary_tooltip text="Pod" term_id="pod" >}} riêng lẻ nào. + + + +PersistentVolumes (PVs) cung cấp một API trừu tượng hóa chi tiết về cách lưu trữ được cung cấp và cách nó được sử dụng. PVs được sử dụng trực tiếp trong các tình huống mà lưu trữ có thể được tạo trước (cấp phát tĩnh). Đối với các tình huống yêu cầu lưu trữ theo nhu cầu (cấp phát động), PersistentVolumeClaims (PVCs) được sử dụng thay thế. diff --git a/content/vi/docs/reference/glossary/storage-class.md b/content/vi/docs/reference/glossary/storage-class.md new file mode 100644 index 0000000000000..0c2311957befb --- /dev/null +++ b/content/vi/docs/reference/glossary/storage-class.md @@ -0,0 +1,18 @@ +--- +title: Storage Class +id: storageclass +date: 2018-04-12 +full_link: /docs/concepts/storage/storage-classes +short_description: > + StorageClass cung cấp cách để quản trị viên mô tả các loại lưu trữ khác nhau có sẵn trong hệ thống. + +aka: +tags: +- core-object +- storage +--- + StorageClass cung cấp cách để quản trị viên mô tả các loại lưu trữ khác nhau có sẵn trong hệ thống. + + + +StorageClass có thể được ánh xạ tới các cấp độ chất lượng dịch vụ, chính sách sao lưu, hoặc các chính sách tùy chỉnh được xác định bởi quản trị viên cluster. Mỗi StorageClass chứa các trường `provisioner`, `parameters` và `reclaimPolicy`, được sử dụng khi cần cấp phát động một {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}} thuộc về class đó. Người dùng có thể yêu cầu một class cụ thể bằng cách sử dụng tên của đối tượng StorageClass. diff --git a/content/vi/docs/reference/glossary/toleration.md b/content/vi/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000000..e6ea984c658c3 --- /dev/null +++ b/content/vi/docs/reference/glossary/toleration.md @@ -0,0 +1,18 @@ +--- +title: Toleration +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + Một đối tượng cốt lõi gồm ba thuộc tính bắt buộc: key, value và effect. Toleration cho phép lập lịch các pod trên các node hoặc nhóm node có taint tương ứng. + +aka: +tags: +- core-object +- fundamental +--- + Một đối tượng cốt lõi gồm ba thuộc tính bắt buộc: key, value và effect. Toleration cho phép lập lịch các pod trên các node hoặc nhóm node có {{< glossary_tooltip text="taint" term_id="taint" >}} tương ứng. + + + +Toleration và {{< glossary_tooltip text="taint" term_id="taint" >}} hoạt động cùng nhau để đảm bảo rằng các pod không được lập lịch trên những node không phù hợp. Một hoặc nhiều toleration có thể được áp dụng cho một {{< glossary_tooltip text="pod" term_id="pod" >}}. Một toleration chỉ ra rằng {{< glossary_tooltip text="pod" term_id="pod" >}} được phép (nhưng không bắt buộc) lập lịch trên các node hoặc nhóm node có {{< glossary_tooltip text="taint" term_id="taint" >}} tương ứng. diff --git a/content/vi/docs/setup/best-practices/certificates.md b/content/vi/docs/setup/best-practices/certificates.md new file mode 100644 index 0000000000000..ecab0cf58cc45 --- /dev/null +++ b/content/vi/docs/setup/best-practices/certificates.md @@ -0,0 +1,264 @@ +--- +title: Chứng chỉ PKI và các yêu cầu +content_type: concept +weight: 50 +--- + + + +Kubernetes yêu cầu chứng chỉ PKI để xác thực qua TLS. +Nếu bạn cài đặt Kubernetes với [kubeadm](/docs/reference/setup-tools/kubeadm/), các chứng chỉ +mà cluster của bạn cần sẽ được tạo tự động. +Bạn cũng có thể tự tạo chứng chỉ của riêng mình -- ví dụ, để giữ các khóa riêng tư an toàn hơn +bằng cách không lưu trữ chúng trên API server. +Trang này giải thích các chứng chỉ mà cluster của bạn yêu cầu. + + + +## Cách chứng chỉ được sử dụng bởi cluster của bạn + +Kubernetes yêu cầu PKI cho các hoạt động sau: + +### Chứng chỉ server + +* Chứng chỉ server cho điểm truy cập API server +* Chứng chỉ server cho etcd server +* [Chứng chỉ server](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) + cho mỗi kubelet (mỗi {{< glossary_tooltip text="node" term_id="node" >}} chạy một kubelet) +* Chứng chỉ server tùy chọn cho [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + +### Chứng chỉ client + +* Chứng chỉ client cho mỗi kubelet, được sử dụng để xác thực với API server với tư cách là client của + Kubernetes API +* Chứng chỉ client cho mỗi API server, được sử dụng để xác thực với etcd +* Chứng chỉ client cho controller manager để giao tiếp an toàn với API server +* Chứng chỉ client cho scheduler để giao tiếp an toàn với API server +* Chứng chỉ client, một cho mỗi node, để kube-proxy xác thực với API server +* Chứng chỉ client tùy chọn cho quản trị viên của cluster để xác thực với API server +* Chứng chỉ client tùy chọn cho [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + +### Chứng chỉ server và client của kubelet + +Để thiết lập kết nối an toàn và xác thực với kubelet, API Server cần một cặp chứng chỉ và khóa client. + +Trong trường hợp này, có hai cách tiếp cận cho việc sử dụng chứng chỉ: + +* Chứng chỉ dùng chung: kube-apiserver có thể sử dụng cùng một cặp chứng chỉ và khóa mà nó sử dụng để xác thực các client của mình. Điều này có nghĩa là các chứng chỉ hiện có như `apiserver.crt` và `apiserver.key` có thể được sử dụng để giao tiếp với các kubelet server. + +* Chứng chỉ riêng biệt: Hoặc kube-apiserver có thể tạo một cặp chứng chỉ và khóa client mới để xác thực khi giao tiếp với các kubelet server. Trong trường hợp này, một chứng chỉ riêng biệt có tên `kubelet-client.crt` và khóa riêng tư tương ứng `kubelet-client.key` được tạo ra. + +{{< note >}} +Chứng chỉ `front-proxy` chỉ được yêu cầu nếu bạn chạy kube-proxy để hỗ trợ +[một extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/). +{{< /note >}} + +etcd cũng triển khai TLS hai chiều để xác thực các client và các etcd peer (các node etcd khác trong cụm). + +## Nơi lưu trữ chứng chỉ + +Nếu bạn cài đặt Kubernetes với kubeadm, hầu hết các chứng chỉ được lưu trữ trong `/etc/kubernetes/pki`. +Tất cả các đường dẫn trong tài liệu này đều tương đối so với thư mục đó, ngoại trừ chứng chỉ tài khoản người dùng +mà kubeadm đặt trong `/etc/kubernetes`. + +## Cấu hình chứng chỉ thủ công + +Nếu bạn không muốn kubeadm tạo các chứng chỉ cần thiết, bạn có thể tạo chúng bằng +một CA gốc duy nhất hoặc bằng cách cung cấp tất cả các chứng chỉ. Xem [Chứng chỉ](/docs/tasks/administer-cluster/certificates/) +để biết chi tiết về cách tạo cơ quan chứng nhận riêng của bạn. Xem +[Quản lý chứng chỉ với kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) +để biết thêm về quản lý chứng chỉ. + +### CA gốc duy nhất + +Bạn có thể tạo một CA gốc duy nhất do quản trị viên kiểm soát. CA gốc này sau đó có thể tạo nhiều CA trung gian và ủy quyền tất cả việc tạo chứng chỉ tiếp theo cho Kubernetes. + +Các CA bắt buộc: + +| Đường dẫn | CN mặc định | Mô tả | +|------------------------|---------------------------|----------------------------------| +| ca.crt,key | kubernetes-ca | CA chung của Kubernetes | +| etcd/ca.crt,key | etcd-ca | Cho tất cả các chức năng liên quan đến etcd | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | Cho [proxy front-end](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | + +Ngoài các CA trên, cũng cần có một cặp khóa công khai/riêng tư để quản lý tài khoản dịch vụ, +`sa.key` và `sa.pub`. +Ví dụ sau minh họa các tệp khóa và chứng chỉ CA được hiển thị trong bảng trước: + +``` +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-ca.key +``` + +### Tất cả chứng chỉ + +Nếu bạn không muốn sao chép các khóa riêng tư CA vào cluster của mình, bạn có thể tự tạo tất cả các chứng chỉ. + +Các chứng chỉ bắt buộc: + +| CN mặc định | CA cha | O (trong Subject) | loại | hosts (SAN) | +|-------------------------------|---------------------------|-------------------|------------------|-----------------------------------------------------| +| kube-etcd | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-healthcheck-client | etcd-ca | | client | | +| kube-apiserver-etcd-client | etcd-ca | | client | | +| kube-apiserver | kubernetes-ca | | server | ``, ``, ``[^1] | +| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | +| front-proxy-client | kubernetes-front-proxy-ca | | client | | + +{{< note >}} +Thay vì sử dụng nhóm siêu người dùng `system:masters` cho `kube-apiserver-kubelet-client`, +một nhóm có ít đặc quyền hơn có thể được sử dụng. kubeadm sử dụng nhóm `kubeadm:cluster-admins` +cho mục đích đó. +{{< /note >}} + +[^1]: bất kỳ IP hoặc tên DNS nào khác mà bạn liên hệ với cluster của mình (như được sử dụng bởi [kubeadm](/docs/reference/setup-tools/kubeadm/)) +IP ổn định của bộ cân bằng tải và/hoặc tên DNS, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, +`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) + +trong đó `loại` ánh xạ đến một hoặc nhiều mục đích sử dụng khóa x509, cũng được ghi trong +`.spec.usages` của một [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest): + +| loại | Mục đích sử dụng khóa | +|--------|--------------------------------------------------------------------------| +| server | chữ ký số, mã hóa khóa, xác thực server | +| client | chữ ký số, mã hóa khóa, xác thực client | + +{{< note >}} +Hosts/SAN được liệt kê ở trên là những khuyến nghị để có một cluster hoạt động; nếu cần thiết cho +một thiết lập cụ thể, có thể thêm SAN bổ sung vào tất cả các chứng chỉ server. +{{< /note >}} + +{{< note >}} +Chỉ dành cho người dùng kubeadm: + +* Kịch bản khi bạn sao chép chứng chỉ CA vào cluster mà không có khóa riêng tư được gọi là CA bên ngoài trong tài liệu kubeadm. +* Nếu bạn so sánh danh sách trên với PKI được tạo bởi kubeadm, lưu ý rằng các chứng chỉ `kube-etcd`, `kube-etcd-peer` và `kube-etcd-healthcheck-client` không được tạo trong trường hợp sử dụng etcd bên ngoài. +{{< /note >}} + +### Đường dẫn chứng chỉ + +Chứng chỉ nên được đặt trong đường dẫn được khuyến nghị (như được sử dụng bởi [kubeadm](/docs/reference/setup-tools/kubeadm/)). +Đường dẫn nên được chỉ định bằng đối số đã cho bất kể vị trí. + +| DefaultCN | recommendedkeypath | recommendedcertpath | command | keyargument | certargument | +| --------- | ------------------ | ------------------- | ------- | ----------- | ------------ | +| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file | +| kube-apiserver | apiserver.key | apiserver.crt| kube-apiserver | --tls-private-key-file | --tls-cert-file | +| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | +| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file,--peer-trusted-ca-file | +| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | +| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | +| etcd-ca| | etcd/ca.crt | etcdctl | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert | + +Các cân nhắc tương tự áp dụng cho cặp khóa tài khoản dịch vụ: + +| đường dẫn khóa riêng tư | đường dẫn khóa công khai | command | argument | +|-------------------|------------------|-------------------------|--------------------------------------| +| sa.key | | kube-controller-manager | --service-account-private-key-file | +| | sa.pub | kube-apiserver | --service-account-key-file | + +Ví dụ sau minh họa đường dẫn tệp [từ các bảng trước](#certificate-paths) +mà bạn cần cung cấp nếu bạn đang tạo tất cả các khóa và chứng chỉ của riêng mình: + +``` +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/apiserver-etcd-client.key +/etc/kubernetes/pki/apiserver-etcd-client.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/apiserver.key +/etc/kubernetes/pki/apiserver.crt +/etc/kubernetes/pki/apiserver-kubelet-client.key +/etc/kubernetes/pki/apiserver-kubelet-client.crt +/etc/kubernetes/pki/front-proxy-ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-client.key +/etc/kubernetes/pki/front-proxy-client.crt +/etc/kubernetes/pki/etcd/server.key +/etc/kubernetes/pki/etcd/server.crt +/etc/kubernetes/pki/etcd/peer.key +/etc/kubernetes/pki/etcd/peer.crt +/etc/kubernetes/pki/etcd/healthcheck-client.key +/etc/kubernetes/pki/etcd/healthcheck-client.crt +/etc/kubernetes/pki/sa.key +/etc/kubernetes/pki/sa.pub +``` + +## Cấu hình chứng chỉ cho tài khoản người dùng + +Bạn phải cấu hình thủ công các tài khoản quản trị viên và tài khoản dịch vụ này: + +| Tên tệp | Tên thông tin xác thực | CN mặc định | O (trong Subject) | +|-------------------------|----------------------------|-------------------------------------|------------------------| +| admin.conf | default-admin | kubernetes-admin | `` | +| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | +| kubelet.conf | default-auth | system:node:`` (xem ghi chú) | system:nodes | +| controller-manager.conf | default-controller-manager | system:kube-controller-manager | | +| scheduler.conf | default-scheduler | system:kube-scheduler | | + +{{< note >}} +Giá trị của `` cho `kubelet.conf` **phải** khớp chính xác với giá trị của tên node +được cung cấp bởi kubelet khi nó đăng ký với apiserver. Để biết thêm chi tiết, hãy đọc +[Node Authorization](/docs/reference/access-authn-authz/node/). +{{< /note >}} + +{{< note >}} +Trong ví dụ trên, `` là đặc thù cho triển khai. Một số công cụ ký +chứng chỉ trong `admin.conf` mặc định để là một phần của nhóm `system:masters`. +`system:masters` là một nhóm siêu người dùng khẩn cấp có thể bỏ qua lớp ủy quyền +của Kubernetes, chẳng hạn như RBAC. Ngoài ra, một số công cụ không tạo ra +`super-admin.conf` riêng biệt với chứng chỉ ràng buộc với nhóm siêu người dùng này. + +kubeadm tạo hai chứng chỉ quản trị viên riêng biệt trong các tệp kubeconfig. +Một là trong `admin.conf` và có `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`. +`kubeadm:cluster-admins` là một nhóm tùy chỉnh ràng buộc với ClusterRole `cluster-admin`. +Tệp này được tạo trên tất cả các máy control plane được quản lý bởi kubeadm. + +Một tệp khác là `super-admin.conf` có `Subject: O = system:masters, CN = kubernetes-super-admin`. +Tệp này chỉ được tạo trên node nơi `kubeadm init` được gọi. +{{< /note >}} + +1. Đối với mỗi cấu hình, tạo một cặp chứng chỉ/khóa x509 với + Common Name (CN) và Organization (O) đã cho. + +1. Chạy `kubectl` như sau cho mỗi cấu hình: + + ``` + KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs + KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs + KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user + KUBECONFIG= kubectl config use-context default-system + ``` + +Các tệp này được sử dụng như sau: + +| Tên tệp | Command | Ghi chú | +|-------------------------|-------------------------|-----------------------------------------------------------------------| +| admin.conf | kubectl | Cấu hình người dùng quản trị cho cluster | +| super-admin.conf | kubectl | Cấu hình người dùng siêu quản trị cho cluster | +| kubelet.conf | kubelet | Một tệp được yêu cầu cho mỗi node trong cluster. | +| controller-manager.conf | kube-controller-manager | Phải được thêm vào manifest trong `manifests/kube-controller-manager.yaml` | +| scheduler.conf | kube-scheduler | Phải được thêm vào manifest trong `manifests/kube-scheduler.yaml` | + +Các tệp sau minh họa đường dẫn đầy đủ đến các tệp được liệt kê trong bảng trước: + +``` +/etc/kubernetes/admin.conf +/etc/kubernetes/super-admin.conf +/etc/kubernetes/kubelet.conf +/etc/kubernetes/controller-manager.conf +/etc/kubernetes/scheduler.conf +``` diff --git a/content/vi/docs/setup/best-practices/cluster-large.md b/content/vi/docs/setup/best-practices/cluster-large.md new file mode 100644 index 0000000000000..2a7e18c43d063 --- /dev/null +++ b/content/vi/docs/setup/best-practices/cluster-large.md @@ -0,0 +1,83 @@ +--- +title: Những lưu ý cho cluster lớn +weight: 10 +--- + +Một cluster là một tập hợp các {{< glossary_tooltip text="node" term_id="node" >}} (máy vật lý hoặc máy ảo) chạy các agent Kubernetes, được quản lý bởi {{< glossary_tooltip text="control plane" term_id="control-plane" >}}. Kubernetes {{< param "version" >}} hỗ trợ các cluster có tối đa 5.000 node. Cụ thể hơn, Kubernetes được thiết kế để đáp ứng *tất cả* các tiêu chí sau: + +* Không quá 110 pod trên mỗi node +* Không quá 5.000 node +* Không quá 150.000 pod tổng cộng +* Không quá 300.000 container tổng cộng + +Bạn có thể mở rộng cluster bằng cách thêm hoặc xóa các node. Cách thực hiện điều này phụ thuộc vào phương thức triển khai cluster của bạn. + +## Hạn mức tài nguyên của nhà cung cấp đám mây {#quota-issues} + +Để tránh gặp phải vấn đề về hạn mức tài nguyên của nhà cung cấp đám mây khi tạo cluster với nhiều node, bạn nên cân nhắc: + +* Yêu cầu tăng hạn mức cho các tài nguyên đám mây như: + * Số lượng máy ảo + * CPU + * Ổ đĩa lưu trữ + * Địa chỉ IP đang sử dụng + * Bộ quy tắc lọc gói tin + * Số lượng bộ cân bằng tải + * Mạng con + * Luồng log +* Triển khai các node mới theo từng đợt, với thời gian nghỉ giữa các đợt, vì một số nhà cung cấp đám mây giới hạn tốc độ tạo máy ảo mới. + +## Các thành phần control plane + +Đối với cluster lớn, bạn cần một control plane với đủ tài nguyên tính toán và các tài nguyên khác. + +Thông thường, bạn nên chạy một hoặc hai instance control plane cho mỗi vùng sự cố (failure zone), mở rộng theo chiều dọc trước, sau đó mở rộng theo chiều ngang khi việc mở rộng theo chiều dọc không còn hiệu quả. + +Bạn nên chạy ít nhất một instance cho mỗi vùng sự cố để đảm bảo khả năng chịu lỗi. Các node Kubernetes không tự động điều hướng lưu lượng đến các điểm cuối control-plane trong cùng vùng sự cố; tuy nhiên, nhà cung cấp đám mây của bạn có thể có cơ chế riêng để thực hiện điều này. + +Ví dụ, khi sử dụng dịch vụ cân bằng tải do nhà cung cấp đám mây quản lý, bạn cấu hình dịch vụ này để điều hướng lưu lượng phát sinh từ kubelet và Pod trong vùng sự cố _A_, và chỉ chuyển lưu lượng đó đến các máy chủ control plane cũng nằm trong vùng _A_. Nếu một máy chủ control-plane hoặc một điểm truy cập trong vùng sự cố _A_ ngừng hoạt động, điều này đồng nghĩa với việc toàn bộ lưu lượng control-plane của các node trong vùng _A_ sẽ phải đi xuyên vùng. Việc vận hành nhiều máy chủ control plane trong mỗi vùng sẽ giúp giảm khả năng xảy ra tình huống này. + +### Lưu trữ etcd + +Để cải thiện hiệu năng của các cluster lớn, bạn có thể lưu trữ các đối tượng Event trong một instance etcd riêng biệt và chuyên dụng. + +Khi tạo cluster, bạn có thể thực hiện các bước sau (sử dụng công cụ tùy chỉnh): + +* Khởi động và cấu hình thêm một instance etcd +* Cấu hình {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} để sử dụng instance này cho việc lưu trữ các event + +Xem [Vận hành các cluster etcd cho Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) và [Thiết lập cluster etcd Highly Available với kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) để biết chi tiết về cách cấu hình và quản lý etcd cho cluster lớn. + +## Tài nguyên cho addon + +[Giới hạn tài nguyên](/docs/concepts/configuration/manage-resources-containers/) của Kubernetes giúp giảm thiểu tác động của rò rỉ bộ nhớ và các cách mà pod và container có thể ảnh hưởng đến các thành phần khác. Các giới hạn tài nguyên này áp dụng cho tài nguyên {{< glossary_tooltip text="addon" term_id="addons" >}} giống như chúng áp dụng cho các workload ứng dụng. + +Ví dụ, bạn có thể đặt giới hạn CPU và bộ nhớ cho thành phần ghi log: + +```yaml + ... + containers: + - name: fluentd-cloud-logging + image: fluent/fluentd-kubernetes-daemonset:v1 + resources: + limits: + cpu: 100m + memory: 200Mi +``` + +Giới hạn mặc định của các addon thường dựa trên dữ liệu thu thập từ kinh nghiệm chạy mỗi addon trên các cluster Kubernetes nhỏ hoặc trung bình. Khi chạy trên các cluster lớn, các addon thường tiêu thụ nhiều tài nguyên hơn so với giới hạn mặc định của chúng. Nếu một cluster lớn được triển khai mà không điều chỉnh các giá trị này, (các) addon có thể liên tục bị kill vì chúng liên tục chạm đến giới hạn bộ nhớ. Ngoài ra, addon có thể chạy nhưng với hiệu suất kém do bị giới hạn thời gian sử dụng CPU. + +Để tránh gặp phải vấn đề về tài nguyên của addon trong cluster, khi tạo cluster với nhiều node, hãy cân nhắc những điều sau: + +* Một số addon mở rộng theo chiều dọc - chỉ có một bản sao của addon cho toàn bộ cluster hoặc phục vụ cho một vùng sự cố. Đối với các addon này, hãy tăng yêu cầu và giới hạn khi bạn mở rộng cluster. +* Nhiều addon mở rộng theo chiều ngang - bạn thêm năng lực bằng cách chạy nhiều pod hơn - nhưng với một cluster rất lớn, bạn cũng có thể cần tăng nhẹ giới hạn CPU hoặc bộ nhớ. [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) có thể chạy ở chế độ _recommender_ để đề xuất các con số phù hợp cho yêu cầu và giới hạn. +* Một số addon chạy một bản sao trên mỗi node, được kiểm soát bởi {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}: ví dụ, một trình tổng hợp log cấp node. Tương tự như trường hợp với các addon mở rộng theo chiều ngang, bạn cũng có thể cần tăng nhẹ giới hạn CPU hoặc bộ nhớ. + +## {{% heading "whatsnext" %}} + +* `VerticalPodAutoscaler` là một tài nguyên tùy chỉnh mà bạn có thể triển khai vào cluster để giúp quản lý yêu cầu và giới hạn tài nguyên cho pod. +Tìm hiểu thêm về [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) và cách bạn có thể sử dụng nó để mở rộng các thành phần của cluster, bao gồm cả các addon quan trọng. + +* Đọc về [Node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/) + +* [Addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) giúp bạn tự động điều chỉnh kích thước các addon khi quy mô cluster thay đổi. diff --git a/content/vi/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/vi/docs/setup/best-practices/enforcing-pod-security-standards.md new file mode 100644 index 0000000000000..4bad11a9d45c4 --- /dev/null +++ b/content/vi/docs/setup/best-practices/enforcing-pod-security-standards.md @@ -0,0 +1,54 @@ +--- +title: Thực thi các tiêu chuẩn bảo mật Pod +weight: 40 +--- + + + +Trang này cung cấp tổng quan về các phương pháp tốt nhất khi thực thi +[Tiêu chuẩn bảo mật Pod](/docs/concepts/security/pod-security-standards). + + + +## Sử dụng Pod Security Admission Controller tích hợp sẵn + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +[Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +được tạo ra để thay thế PodSecurityPolicies đã bị loại bỏ. + +### Cấu hình tất cả các namespace trong cluster + +Các namespace không có bất kỳ cấu hình nào nên được xem là những lỗ hổng đáng kể trong mô hình bảo mật cluster của bạn. Chúng tôi khuyến nghị bạn nên dành thời gian phân tích các loại workload trong mỗi namespace, và bằng cách tham khảo Tiêu chuẩn bảo mật Pod, quyết định mức độ phù hợp cho từng namespace. Các namespace chưa được gắn nhãn chỉ nên được hiểu là chúng chưa được đánh giá. + +Trong trường hợp tất cả các workload trong tất cả các namespace đều có cùng yêu cầu bảo mật, chúng tôi cung cấp một [ví dụ](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) minh họa cách áp dụng đồng loạt các nhãn PodSecurity. + +### Áp dụng nguyên tắc đặc quyền tối thiểu + +Trong một thế giới lý tưởng, mọi pod trong mọi namespace đều đáp ứng các yêu cầu của chính sách `restricted`. Tuy nhiên, điều này không khả thi và không thực tế, vì một số workload sẽ cần các đặc quyền nâng cao vì những lý do chính đáng. + +- Các namespace cho phép workload `privileged` cần thiết lập và thực thi các kiểm soát truy cập phù hợp. +- Đối với các workload chạy trong những namespace có tính permissive, hãy duy trì tài liệu về các yêu cầu bảo mật đặc thù của chúng. Nếu có thể, hãy xem xét cách các yêu cầu đó có thể được giới hạn thêm. + +### Áp dụng chiến lược đa chế độ + +Các chế độ `audit` và `warn` của Pod Security Standards admission controller giúp dễ dàng thu thập các thông tin bảo mật quan trọng về pod của bạn mà không ảnh hưởng đến các workload hiện có. + +Một thực hành tốt là bật các chế độ này cho tất cả các namespace, đặt chúng ở mức độ và phiên bản _mong muốn_ mà bạn cuối cùng muốn `enforce`. Các cảnh báo và chú thích audit được tạo ra trong giai đoạn này có thể hướng dẫn bạn đạt được trạng thái đó. Nếu bạn mong đợi các tác giả workload thực hiện thay đổi để phù hợp với mức độ mong muốn, hãy bật chế độ `warn`. Nếu bạn dự định sử dụng nhật ký audit để theo dõi/thúc đẩy các thay đổi phù hợp với mức độ mong muốn, hãy bật chế độ `audit`. + +Khi bạn đã đặt chế độ `enforce` ở giá trị mong muốn, các chế độ này vẫn có thể hữu ích theo một số cách khác nhau: + +- Bằng cách đặt `warn` ở cùng mức với `enforce`, các client sẽ nhận được cảnh báo khi cố gắng tạo Pod (hoặc tài nguyên có Pod template) không vượt qua validation. Điều này sẽ giúp họ cập nhật các tài nguyên đó để tuân thủ. +- Trong các Namespace gắn `enforce` vào một phiên bản cụ thể không phải latest, việc đặt các chế độ `audit` và `warn` ở cùng mức với `enforce`, nhưng ở phiên bản `latest`, giúp hiển thị các cài đặt được phép bởi các phiên bản trước nhưng không được phép theo best practices hiện tại. + +## Các giải pháp thay thế từ bên thứ ba + +{{% thirdparty-content %}} + +Các giải pháp thay thế khác để thực thi security profile đang được phát triển trong hệ sinh thái Kubernetes: + +- [Kubewarden](https://github.com/kubewarden) +- [Kyverno](https://kyverno.io/policies/) +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + +Quyết định sử dụng giải pháp _tích hợp sẵn_ (ví dụ: Pod Security admission controller) hay công cụ của bên thứ ba hoàn toàn phụ thuộc vào tình huống cụ thể của bạn. Khi đánh giá bất kỳ giải pháp nào, sự tin tưởng vào chuỗi cung ứng của bạn là yếu tố then chốt. Cuối cùng, việc sử dụng _bất kỳ_ phương pháp nào trong số các phương pháp đã đề cập sẽ tốt hơn là không làm gì cả. diff --git a/content/vi/docs/setup/best-practices/multiple-zones.md b/content/vi/docs/setup/best-practices/multiple-zones.md new file mode 100644 index 0000000000000..1d56e20111df5 --- /dev/null +++ b/content/vi/docs/setup/best-practices/multiple-zones.md @@ -0,0 +1,73 @@ +--- +title: Vận hành Kubernetes trên nhiều vùng +weight: 20 +content_type: concept +--- + + + +Trang này mô tả cách vận hành Kubernetes trên nhiều vùng khác nhau. + + + +## Tổng quan + +Kubernetes được thiết kế để một cluster Kubernetes duy nhất có thể hoạt động trên nhiều vùng sự cố (failure zone), thường là khi các vùng này nằm trong một nhóm logic được gọi là _region_. Các nhà cung cấp đám mây lớn định nghĩa một region là một tập hợp các vùng sự cố (còn được gọi là _availability zone_) cung cấp một tập hợp tính năng nhất quán: trong một region, mỗi zone cung cấp cùng một API và dịch vụ. + +Kiến trúc đám mây thông thường nhằm giảm thiểu khả năng sự cố ở một zone ảnh hưởng đến dịch vụ ở zone khác. + +## Cách hoạt động của control plane + +Tất cả [các thành phần control plane](/docs/concepts/architecture/#control-plane-components) đều hỗ trợ chạy như một nhóm tài nguyên có thể thay thế lẫn nhau, được nhân bản cho mỗi thành phần. + +Khi triển khai control plane của cluster, hãy đặt các bản sao của các thành phần control plane trên nhiều vùng sự cố khác nhau. Nếu tính sẵn sàng là một yếu tố quan trọng, hãy chọn ít nhất ba vùng sự cố và nhân bản mỗi thành phần control plane riêng lẻ (API server, scheduler, etcd, cluster controller manager) trên ít nhất ba vùng sự cố. Nếu bạn đang chạy cloud controller manager, bạn cũng nên nhân bản nó trên tất cả các vùng sự cố mà bạn đã chọn. + +{{< note >}} +Kubernetes không cung cấp khả năng phục hồi xuyên vùng cho các điểm truy cập API server. Bạn có thể sử dụng nhiều kỹ thuật khác nhau để cải thiện tính sẵn sàng cho API server của cluster, bao gồm DNS round-robin, bản ghi SRV, hoặc giải pháp cân bằng tải của bên thứ ba với tính năng kiểm tra sức khỏe. +{{< /note >}} + +## Cách hoạt động của node + +Kubernetes tự động phân tán các Pod cho các tài nguyên workload (như {{< glossary_tooltip text="Deployment" term_id="deployment" >}} hoặc {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}) trên các node khác nhau trong cluster. Việc phân tán này giúp giảm tác động của các sự cố. + +Khi các node khởi động, kubelet trên mỗi node tự động thêm {{< glossary_tooltip text="labels" term_id="label" >}} vào đối tượng Node đại diện cho kubelet cụ thể đó trong Kubernetes API. Các nhãn này có thể bao gồm [thông tin về zone](/docs/reference/labels-annotations-taints/#topologykubernetesiozone). + +Nếu cluster của bạn trải rộng trên nhiều zone hoặc region, bạn có thể sử dụng nhãn node kết hợp với [ràng buộc phân tán topology của Pod](/docs/concepts/scheduling-eviction/topology-spread-constraints/) để kiểm soát cách các Pod được phân tán trong cluster giữa các miền chịu lỗi: region, zone, và thậm chí là các node cụ thể. Những gợi ý này cho phép {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} đặt Pod để có tính sẵn sàng tốt hơn, giảm nguy cơ sự cố liên quan ảnh hưởng đến toàn bộ workload của bạn. + +Ví dụ, bạn có thể thiết lập một ràng buộc để đảm bảo rằng 3 bản sao của một StatefulSet đều chạy ở các zone khác nhau, bất cứ khi nào điều đó khả thi. Bạn có thể định nghĩa điều này một cách khai báo mà không cần xác định rõ ràng zone nào đang được sử dụng cho mỗi workload. + +### Phân phối node trên các zone + +Phần core của Kubernetes không tự tạo node cho bạn; bạn cần tự làm điều đó, hoặc sử dụng công cụ như [Cluster API](https://cluster-api.sigs.k8s.io/) để quản lý node thay mặt bạn. + +Sử dụng các công cụ như Cluster API, bạn có thể định nghĩa các tập hợp máy để chạy như các node worker cho cluster của bạn trên nhiều miền chịu lỗi khác nhau, và các quy tắc để tự động phục hồi cluster trong trường hợp gián đoạn dịch vụ toàn zone. + +## Gán zone thủ công cho Pod + +Bạn có thể áp dụng [ràng buộc node selector](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) cho các Pod mà bạn tạo, cũng như cho các template Pod trong các tài nguyên workload như Deployment, StatefulSet, hoặc Job. + +## Truy cập lưu trữ cho các zone + +Khi persistent volume được tạo, Kubernetes tự động thêm nhãn zone vào bất kỳ PersistentVolume nào được liên kết với một zone cụ thể. {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}} sau đó đảm bảo, thông qua predicate `NoVolumeZoneConflict`, rằng các pod yêu cầu một PersistentVolume cụ thể chỉ được đặt vào cùng zone với volume đó. + +Lưu ý rằng phương thức thêm nhãn zone có thể phụ thuộc vào nhà cung cấp đám mây và provisioner lưu trữ mà bạn đang sử dụng. Luôn tham khảo tài liệu cụ thể cho môi trường của bạn để đảm bảo cấu hình chính xác. + +Bạn có thể chỉ định một {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} cho PersistentVolumeClaim xác định các miền chịu lỗi (zone) mà lưu trữ trong lớp đó có thể sử dụng. Để tìm hiểu về cách cấu hình StorageClass nhận biết về miền chịu lỗi hoặc zone, xem [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies). + +## Mạng + +Tự bản thân Kubernetes không bao gồm mạng nhận biết zone. Bạn có thể sử dụng [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) để cấu hình mạng cluster, và giải pháp mạng đó có thể có các yếu tố đặc thù cho từng zone. Ví dụ, nếu nhà cung cấp đám mây của bạn hỗ trợ Service với `type=LoadBalancer`, bộ cân bằng tải có thể chỉ gửi lưu lượng đến các Pod chạy trong cùng zone với phần tử cân bằng tải xử lý kết nối cụ thể. Kiểm tra tài liệu của nhà cung cấp đám mây để biết chi tiết. + +Những cân nhắc tương tự cũng áp dụng cho các triển khai tùy chỉnh hoặc on-premises. Cách hoạt động của {{< glossary_tooltip text="Service" term_id="service" >}} và {{< glossary_tooltip text="Ingress" term_id="ingress" >}}, bao gồm cả cách xử lý khi có sự cố ở các vùng khác nhau, sẽ phụ thuộc vào cách bạn thiết lập cluster. + +## Khôi phục sau sự cố + +Khi thiết lập cluster, bạn cũng cần cân nhắc liệu hệ thống của mình có khả năng và phương án khôi phục dịch vụ khi tất cả các vùng trong một region cùng ngừng hoạt động hay không. Ví dụ: liệu bạn có phụ thuộc vào việc phải có ít nhất một node có khả năng chạy Pod trong một vùng không? + +Hãy đảm bảo rằng các công việc sửa chữa quan trọng của cluster không phụ thuộc vào việc phải có ít nhất một node hoạt động bình thường trong cluster. Ví dụ: khi tất cả các node đều không hoạt động bình thường, bạn có thể cần chạy một Job sửa chữa với một {{< glossary_tooltip text="toleration" term_id="toleration" >}} đặc biệt để đảm bảo việc sửa chữa có thể hoàn thành và đưa ít nhất một node trở lại hoạt động. + +Kubernetes không cung cấp sẵn giải pháp cho thách thức này, tuy nhiên đây là điều bạn nên cân nhắc. + +## {{% heading "whatsnext" %}} + +Để tìm hiểu cách scheduler đặt Pod trong cluster, tuân thủ các ràng buộc đã cấu hình, hãy truy cập [Scheduling and Eviction](/docs/concepts/scheduling-eviction/). diff --git a/content/vi/docs/setup/best-practices/node-conformance.md b/content/vi/docs/setup/best-practices/node-conformance.md new file mode 100644 index 0000000000000..efe789ccfd16a --- /dev/null +++ b/content/vi/docs/setup/best-practices/node-conformance.md @@ -0,0 +1,77 @@ +--- +title: Xác thực cấu hình node +weight: 30 +--- + +## Kiểm tra tính tương thích của Node + +*Kiểm tra tính tương thích của Node* là một framework kiểm tra được đóng gói trong container, cung cấp khả năng xác thực hệ thống và kiểm tra chức năng cho node. Bài kiểm tra này xác nhận xem node có đáp ứng các yêu cầu tối thiểu của Kubernetes hay không; một node vượt qua bài kiểm tra này sẽ đủ điều kiện để tham gia vào một cluster Kubernetes. + +## Điều kiện tiên quyết của Node + +Để chạy kiểm tra tính tương thích của node, một node phải đáp ứng các điều kiện tiên quyết giống như một node Kubernetes tiêu chuẩn. Tối thiểu, node cần có các daemon sau được cài đặt: + +* Container runtime tương thích với CRI như Docker, containerd và CRI-O +* kubelet + +## Chạy kiểm tra tính tương thích của Node + +Để chạy kiểm tra tính tương thích của node, thực hiện các bước sau: + +1. Xác định giá trị của tùy chọn `--kubeconfig` cho kubelet; ví dụ: + `--kubeconfig=/var/lib/kubelet/config.yaml`. + Do framework kiểm tra sẽ khởi động một control plane cục bộ để kiểm tra kubelet, + hãy sử dụng `http://localhost:8080` làm URL của API server. + Có một số tham số dòng lệnh khác của kubelet mà bạn có thể muốn sử dụng: + + * `--cloud-provider`: Nếu bạn đang sử dụng `--cloud-provider=gce`, bạn cần + gỡ bỏ cờ này để chạy bài kiểm tra. + +1. Chạy kiểm tra tính tương thích của node với lệnh: + + ```shell + # $CONFIG_DIR là đường dẫn manifest của pod cho kubelet của bạn. + # $LOG_DIR là đường dẫn lưu kết quả kiểm tra. + sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + registry.k8s.io/node-test:0.2 + ``` + +## Chạy kiểm tra tính tương thích của Node cho các kiến trúc khác + +Kubernetes cũng cung cấp các image docker để kiểm tra tính tương thích của node cho các kiến trúc khác: + +| Kiến trúc | Image | +|-------------|:-----------------:| +| amd64 | node-test-amd64 | +| arm | node-test-arm | +| arm64 | node-test-arm64 | + +## Chạy bài kiểm tra được chọn + +Để chạy các bài kiểm tra cụ thể, hãy ghi đè biến môi trường `FOCUS` với biểu thức chính quy của các bài kiểm tra bạn muốn chạy. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e FOCUS=MirrorPod \ # Chỉ chạy bài kiểm tra MirrorPod + registry.k8s.io/node-test:0.2 +``` + +Để bỏ qua các bài kiểm tra cụ thể, hãy ghi đè biến môi trường `SKIP` với biểu thức chính quy của các bài kiểm tra bạn muốn bỏ qua. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e SKIP=MirrorPod \ # Chạy tất cả các bài kiểm tra tương thích nhưng bỏ qua bài kiểm tra MirrorPod + registry.k8s.io/node-test:0.2 +``` + +Kiểm tra tính tương thích của node là phiên bản được đóng gói trong container của [bài kiểm tra node e2e](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). Mặc định, nó sẽ chạy tất cả các bài kiểm tra tương thích. + +Về mặt lý thuyết, bạn có thể chạy bất kỳ bài kiểm tra node e2e nào nếu bạn cấu hình container và gắn kết các volume cần thiết một cách chính xác. Tuy nhiên, **chúng tôi đặc biệt khuyến nghị chỉ chạy bài kiểm tra tương thích**, vì việc chạy các bài kiểm tra không tương thích đòi hỏi cấu hình phức tạp hơn nhiều. + +## Lưu ý + +* Bài kiểm tra sẽ để lại một số image docker trên node, bao gồm image kiểm tra tính tương thích của node và các image của container được sử dụng trong bài kiểm tra chức năng. +* Bài kiểm tra sẽ để lại các container đã dừng trên node. Các container này được tạo ra trong quá trình kiểm tra chức năng.