From 864a3808b851784a3460d20eca5b528bd703ac5c Mon Sep 17 00:00:00 2001 From: Steven Yan Date: Sun, 26 Sep 2021 10:59:27 +0800 Subject: [PATCH] [zh] translation for admin2 --- .../declare-network-policy.md | 2 + .../extended-resource-node.md | 4 +- .../namespaces-walkthrough.md | 4 +- .../antrea-network-policy.md | 49 ++++++++++ .../calico-network-policy.md | 4 +- .../cilium-network-policy.md | 75 ++++++++------- .../reserve-compute-resources.md | 96 +++++++++---------- 7 files changed, 147 insertions(+), 87 deletions(-) create mode 100644 content/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index 69454747d2..3d682a4cb8 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -30,6 +30,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do 你首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括： +* [Antrea](/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/) * [Calico](/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) * [Cilium](/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) * [Kube-router](/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) diff --git a/content/zh/docs/tasks/administer-cluster/extended-resource-node.md b/content/zh/docs/tasks/administer-cluster/extended-resource-node.md index 9eeb4e09bc..5c1d54b590 100644 --- a/content/zh/docs/tasks/administer-cluster/extended-resource-node.md +++ b/content/zh/docs/tasks/administer-cluster/extended-resource-node.md @@ -67,13 +67,13 @@ Host: k8s-master:8080 注意：Kubernetes 不需要了解 dongle 资源的含义和用途。 -前面的 PATCH 请求仅仅告诉 Kubernetes 你的节点拥有四个你称之为 dongle 的东西。 +前面的 PATCH 请求告诉 Kubernetes 你的节点拥有四个你称之为 dongle 的东西。 启动一个代理（proxy），以便你可以很容易地向 Kubernetes API server 发送请求： diff --git a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md index 7fbf132dcf..39f3f01718 100644 --- a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -345,9 +345,9 @@ Apply the manifest to create a Deployment 应用清单文件来创建 Deployment。 -我们刚刚创建了一个副本大小为 2 的 Deployment，该 Deployment 运行名为 `snowflake` 的 Pod， +我们创建了一个副本大小为 2 的 Deployment，该 Deployment 运行名为 `snowflake` 的 Pod， 其中包含一个仅提供主机名服务的基本容器。 ```shell diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md new file mode 100644 index 0000000000..d8dbecfcce --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md @@ -0,0 +1,49 @@ + +--- +title: 使用 Antrea 提供 NetworkPolicy +content_type: task +weight: 10 +--- + + + +本页展示了如何在 kubernetes 中安装和使用 Antrea CNI 插件。 +要了解 Antrea 项目的背景，请阅读 [Antrea 介绍](https://antrea.io/docs/)。 + +## {{% heading "prerequisites" %}} + + +你需要拥有一个 kuernetes 集群。 +遵循 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)自行创建一个。 + + + + +## 使用 kubeadm 部署 Antrea +遵循[入门](https://github.com/vmware-tanzu/antrea/blob/main/docs/getting-started.md)指南 +为 kubeadm 部署 Antrea 。 + +## {{% heading "whatsnext" %}} + + +一旦你的集群已经运行，你可以遵循 +[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) +来尝试 Kubernetes NetworkPolicy。 \ No newline at end of file diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 2b5e260c5c..9c0dee6fbb 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -29,9 +29,9 @@ Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-goog **先决条件**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts) -1. 启动一个带有 Calico 的 GKE 集群，只需加上参数 `--enable-network-policy`。 +1. 启动一个带有 Calico 的 GKE 集群，需要加上参数 `--enable-network-policy`。 **语法** ```shell diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index d75203b71e..697e102753 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -33,25 +33,25 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium. ## Deploying Cilium on Minikube for Basic Testing To get familiar with Cilium easily you can follow the -[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/) +[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/) to perform a basic DaemonSet installation of Cilium in minikube. -To start minikube, minimal version required is >= v1.3.1, run the with the +To start minikube, minimal version required is >= v1.5.2, run the with the following arguments: --> ## 在 Minikube 上部署 Cilium 用于基本测试 为了轻松熟悉 Cilium 你可以根据 -[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/stable/gettingstarted/minikube/) +[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/s) 在 minikube 中执行一个 cilium 的基本 DaemonSet 安装。 -要启动 minikube，需要的最低版本为 1.3.1，使用下面的参数运行： +要启动 minikube，需要的最低版本为 1.5.2，使用下面的参数运行： ```shell minikube version ``` ``` -minikube version: v1.3.1 +minikube version: v1.5.2 ``` ```shell @@ -59,36 +59,45 @@ minikube start --network-plugin=cni --memory=4096 ``` -挂载 BPF 文件系统： +对于 minikube 你可以使用 Cilium 的 CLI 工具安装它。 +Cilium 将自动检测集群配置并为成功的集群部署选择合适的组件。 ```shell -minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf +curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz +sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin +rm cilium-linux-amd64.tar.gz +cilium install ``` - - -在 minikube 环境中，你可以部署下面的"一体化" YAML 文件，其中包含 Cilium -的 DaemonSet 配置以及适当的 RBAC 配置： - - -```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` - -``` -configmap/cilium-config created -serviceaccount/cilium created -serviceaccount/cilium-operator created -clusterrole.rbac.authorization.k8s.io/cilium created -clusterrole.rbac.authorization.k8s.io/cilium-operator created -clusterrolebinding.rbac.authorization.k8s.io/cilium created -clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created -daemonset.apps/cilium create -deployment.apps/cilium-operator created +🔮 Auto-detected Kubernetes kind: minikube +✨ Running "minikube" validation checks +✅ Detected minikube version "1.20.0" +ℹ️ Cilium version not set, using default version "v1.10.0" +🔮 Auto-detected cluster name: minikube +🔮 Auto-detected IPAM mode: cluster-pool +🔮 Auto-detected datapath mode: tunnel +🔑 Generating CA... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642 +🔑 Generating certificates for Hubble... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574 +🚀 Creating Service accounts... +🚀 Creating Cluster roles... +🚀 Creating ConfigMap... +🚀 Creating Agent DaemonSet... +🚀 Creating Operator Deployment... +⌛ Waiting for Cilium to be installed... ``` 你将看到像这样的 Pods 列表： ```console -NAME READY STATUS RESTARTS AGE -cilium-6rxbd 1/1 Running 0 1m +NAME READY STATUS RESTARTS AGE +cilium-kkdhz 1/1 Running 0 3m23s ... ``` diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md index f03e2bde30..e0b2d8a6e8 100644 --- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -26,7 +26,7 @@ itself. Unless resources are set aside for these system daemons, pods and system daemons compete for resources and lead to resource starvation issues on the node. -The `kubelet` exposes a feature named `Node Allocatable` that helps to reserve +The `kubelet` exposes a feature named 'Node Allocatable' that helps to reserve compute resources for system daemons. Kubernetes recommends cluster administrators to configure `Node Allocatable` based on their workload density on each node. @@ -35,12 +35,11 @@ Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够 这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。 除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。 -`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。 +`kubelet` 公开了一个名为 'Node Allocatable' 的特性，有助于为系统守护进程预留计算资源。 Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 要想为系统守护进程上可选地实施 `system-reserved` 约束，请指定 kubelet 的 `--system-reserved-cgroup` 标志值为 OS 系统守护进程的父级控制组。 @@ -234,19 +232,19 @@ exist. Kubelet will fail if an invalid cgroup is specified. 推荐将 OS 系统守护进程放在一个顶级控制组之下（例如 systemd 机器上的 `system.slice`）。 -请注意，如果 `--system-reserved-cgroup` 不存在，Kubelet **不会** 创建它。 -如果指定了无效的 cgroup，Kubelet 将会失败。 +请注意，如果 `--system-reserved-cgroup` 不存在，`kubelet` **不会** 创建它。 +如果指定了无效的 cgroup，`kubelet` 将会失败。 ### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list} {{< feature-state for_k8s_version="v1.17" state="stable" >}} -- **Kubelet 标志**: `--reserved-cpus=0-3` +-**Kubelet 标志**: `--reserved-cpus=0-3` ### 实施节点可分配约束 {#enforcing-node-allocatable} -- **Kubelet 标志**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]` +-**Kubelet 标志**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]` -调度器将 `Allocatable` 视为 Pod 可用的 `capacity`（资源容量）。 +调度器将 'Allocatable' 视为 Pod 可用的 `capacity`（资源容量）。 -`kubelet` 默认对 Pod 执行 `Allocatable` 约束。 -无论何时，如果所有 Pod 的总用量超过了 `Allocatable`，驱逐 Pod 的措施将被执行。 +`kubelet` 默认对 Pod 执行 'Allocatable' 约束。 +无论何时，如果所有 Pod 的总用量超过了 'Allocatable'，驱逐 Pod 的措施将被执行。 有关驱逐策略的更多细节可以在 -[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)找到。 +[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)页找到。 可通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。 可选地，通过在同一标志中同时指定 `kube-reserved` 和 `system-reserved` 值， @@ -351,7 +351,7 @@ respectively. ## 一般原则 {#general-guidelines} -系统守护进程一般会被按照类似 `Guaranteed` Pod 一样对待。 +系统守护进程一般会被按照类似 'Guaranteed' Pod 一样对待。 系统守护进程可以在与其对应的控制组中出现突发资源用量，这一行为要作为 kubernetes 部署的一部分进行管理。 例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。 @@ -373,9 +373,9 @@ to critical system services being CPU starved, OOM killed, or unable to fork on the node. The recommendation is to enforce `system-reserved` only if a user has profiled their nodes exhaustively to come up with precise estimates and is confident in their -ability to recover if any process in that group is oom_killed. +ability to recover if any process in that group is oom-killed. -* To begin with enforce `Allocatable` on `pods`. +* To begin with enforce 'Allocatable' on `pods`. * Once adequate monitoring and alerting is in place to track kube system daemons, attempt to enforce `kube-reserved` based on usage heuristics. * If absolutely necessary, enforce `system-reserved` over time. @@ -386,7 +386,7 @@ ability to recover if any process in that group is oom_killed. 并且对该组中进程因内存不足而被杀死时，有足够的信心将其恢复时， 才可以强制执行 `system-reserved` 策略。 -* 作为起步，可以先针对 `pods` 上执行 `Allocatable` 约束。 +* 作为起步，可以先针对 `pods` 上执行 'Allocatable' 约束。 * 一旦用于追踪系统守护进程的监控和告警的机制到位，可尝试基于用量估计的 方式执行 `kube-reserved`策略。 * 随着时间推进，在绝对必要的时候可以执行 `system-reserved` 策略。 @@ -424,27 +424,27 @@ Here is an example to illustrate Node Allocatable computation: * `--eviction-hard` 被设置为 `memory.available<500Mi,nodefs.available<10%` -在这个场景下，`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。 -调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 `28.5Gi`， -存储不超过 `88Gi`。 -当 Pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时， +在这个场景下，'Allocatable' 将会是 14.5 CPUs、28.5Gi 内存以及 `88Gi` 本地存储。 +调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 28.5Gi， +存储不超过 '88Gi'。 +当 Pod 的内存使用总量超过 28.5Gi 或者磁盘使用总量超过 88Gi 时， kubelet 将会驱逐它们。 如果节点上的所有进程都尽可能多地使用 CPU，则 Pod 加起来不能使用超过 -`14.5 CPUs` 的资源。 +14.5 CPUs 的资源。 当没有执行 `kube-reserved` 和/或 `system-reserved` 策略且系统守护进程 -使用量超过其预留时，如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`， +使用量超过其预留时，如果节点内存用量高于 31.5Gi 或`存储`大于 90Gi， kubelet 将会驱逐 Pod。