diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index d1fde6c86c..36e27269f7 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -51,12 +51,12 @@ Before choosing a guide, here are some considerations: 在选择一个指南前,有一些因素需要考虑: ## 保护集群 {#securing-a-cluster} -* [证书](/zh/docs/concepts/cluster-administration/certificates/) +* [生成证书](/zh/docs/tasks/administer-cluster/certificates/) 节描述了使用不同的工具链生成证书的步骤。 * [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 diff --git a/content/zh/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md index fe2d6e4ba1..b900e77ec9 100644 --- a/content/zh/docs/concepts/cluster-administration/certificates.md +++ b/content/zh/docs/concepts/cluster-administration/certificates.md @@ -12,508 +12,7 @@ weight: 20 -当使用客户端证书进行认证时,用户可以使用现有部署脚本,或者通过 `easyrsa`、`openssl` 或 -`cfssl` 手动生成证书。 - - - -### easyrsa - - -使用 **easyrsa** 能够手动地为集群生成证书。 - - - -1. 下载、解压并初始化 easyrsa3 的补丁版本。 - - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki - ``` - -1. 生成 CA(通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN) - - ``` - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass - ``` - -1. 生成服务器证书和密钥。 - 参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 - `MASTER_CLUSTER_IP` 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址, - `--service-cluster-ip-range` 同时用于 API 服务器和控制器管理器组件。 - `--days` 参数用于设置证书的有效期限。 - 下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。 - - ``` - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass - ``` - -1. 拷贝 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。 - -1. 填充并在 API 服务器的启动参数中添加以下参数: - - ``` - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key - ``` - -### openssl - - - -使用 **openssl** 能够手动地为集群生成证书。 - -1. 生成密钥位数为 2048 的 ca.key: - - ``` - openssl genrsa -out ca.key 2048 - ``` - -1. 依据 ca.key 生成 ca.crt (使用 -days 参数来设置证书有效时间): - - ``` - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt - ``` - -1. 生成密钥位数为 2048 的 server.key: - - ``` - openssl genrsa -out server.key 2048 - ``` -1. 创建用于生成证书签名请求(CSR)的配置文件。 - 确保在将其保存至文件(如 `csr.conf`)之前将尖括号标记的值(如 ``) - 替换为你想使用的真实值。 注意:`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP - (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 - - ``` - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn - - [ dn ] - C = <国家> - ST = <州/省> - L = <市> - O = <组织> - OU = <部门> - CN = - - [ req_ext ] - subjectAltName = @alt_names - - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = - - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names - ``` - -1. 基于配置文件生成证书签名请求: - - ``` - openssl req -new -key server.key -out server.csr -config csr.conf - ``` - -1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书: - - ``` - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf - ``` - -1. 查看证书: - - ``` - openssl x509 -noout -text -in ./server.crt - ``` - - -最后,添加同样的参数到 API 服务器的启动参数中。 - -### cfssl - - -**cfssl** 是用来生成证书的另一种工具。 - - -1. 按如下所示的方式下载、解压并准备命令行工具。 - 注意:你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。 - - ``` - curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl - chmod +x cfssl - curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson - chmod +x cfssljson - curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo - chmod +x cfssl-certinfo - ``` - -1. 创建目录来存放物料,并初始化 cfssl: - - ``` - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json - ``` - -1. 创建用来生成 CA 文件的 JSON 配置文件,例如 `ca-config.json`: - - ``` - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } - ``` - -1. 创建用来生成 CA 证书签名请求(CSR)的 JSON 配置文件,例如 `ca-csr.json`。 - 确保将尖括号标记的值替换为你想使用的真实值。 - - ``` - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } - ``` - -1. 生成 CA 密钥(`ca-key.pem`)和证书(`ca.pem`): - - ``` - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca - ``` - -1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。 - 确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的 - API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。 - - ``` - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } - ``` - -1. 为 API 服务器生成密钥和证书,生成的秘钥和证书分别默认保存在文件 `server-key.pem` - 和 `server.pem` 中: - - ``` - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ - --config=ca-config.json -profile=kubernetes \ - server-csr.json | ../cfssljson -bare server - ``` - - -## 分发自签名 CA 证书 - -客户端节点可能拒绝承认自签名 CA 证书有效。 -对于非生产环境的部署,或运行在企业防火墙后的部署,用户可以向所有客户端分发自签名 CA 证书, -并刷新本地的有效证书列表。 - -在每个客户端上执行以下操作: - -```bash -sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt -sudo update-ca-certificates -``` - -``` -Updating certificates in /etc/ssl/certs... -1 added, 0 removed; done. -Running hooks in /etc/ca-certificates/update.d.... -done. -``` - - -## 证书 API - -您可以按照[这里](/zh/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式, -使用 `certificates.k8s.io` API 来准备 x509 证书,用于认证。 - +要了解如何为集群生成证书,参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。 diff --git a/content/zh/docs/concepts/cluster-administration/flow-control.md b/content/zh/docs/concepts/cluster-administration/flow-control.md index 7dde282034..dd994b358b 100644 --- a/content/zh/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh/docs/concepts/cluster-administration/flow-control.md @@ -762,7 +762,7 @@ poorly-behaved workloads that may be harming system health. histogram vector of queue lengths for the queues, broken down by the labels `priority_level` and `flow_schema`, as sampled by the enqueued requests. Each request that gets queued contributes one - sample to its histogram, reporting the length of the queue just + sample to its histogram, reporting the length of the queue immediately after the request was added. Note that this produces different statistics than an unbiased survey would. --> diff --git a/content/zh/docs/concepts/cluster-administration/manage-deployment.md b/content/zh/docs/concepts/cluster-administration/manage-deployment.md index 71ece48b8a..e28da08081 100644 --- a/content/zh/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh/docs/concepts/cluster-administration/manage-deployment.md @@ -72,7 +72,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/ @@ -80,7 +80,7 @@ A URL can also be specified as a configuration source, which is handy for deploy 建议的做法是,将同一个微服务或同一应用层相关的资源放到同一个文件中, 将同一个应用相关的所有文件按组存放到同一个目录中。 -如果应用的各层使用 DNS 相互绑定,那么你可以简单地将堆栈的所有组件一起部署。 +如果应用的各层使用 DNS 相互绑定,那么你可以将堆栈的所有组件一起部署。 还可以使用 URL 作为配置源,便于直接使用已经提交到 Github 上的配置文件进行部署: @@ -113,7 +113,7 @@ service "my-nginx-svc" deleted ``` 在仅有两种资源的情况下,可以使用"资源类型/资源名"的语法在命令行中 同时指定这两个资源: @@ -138,13 +138,14 @@ service "my-nginx-svc" deleted ``` 由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同, -所以很容易使用 `$()` 或 `xargs` 进行链式操作: +你可以使用 `$()` 或 `xargs` 进行链式操作: ```shell kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) +kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {} ``` ``` @@ -399,13 +400,13 @@ For a more concrete example, check the [tutorial of deploying Ghost](https://git ## Updating labels Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. -For example, if you want to label all your nginx pods as frontend tier, simply run: +For example, if you want to label all your nginx pods as frontend tier, run: --> ## 更新标签 {#updating-labels} 有时,现有的 pod 和其它资源需要在创建新资源之前重新标记。 这可以用 `kubectl label` 完成。 -例如,如果想要将所有 nginx pod 标记为前端层,只需运行: +例如,如果想要将所有 nginx pod 标记为前端层,运行: ```shell kubectl label pods -l app=nginx tier=fe @@ -419,7 +420,7 @@ pod/my-nginx-2035384211-u3t6x labeled 首先用标签 "app=nginx" 过滤所有的 Pod,然后用 "tier=fe" 标记它们。 想要查看你刚才标记的 Pod,请运行: @@ -482,11 +483,11 @@ For more information, please see [annotations](/docs/concepts/overview/working-w ## 扩缩你的应用 -当应用上的负载增长或收缩时,使用 `kubectl` 能够轻松实现规模的扩缩。 +当应用上的负载增长或收缩时,使用 `kubectl` 能够实现应用规模的扩缩。 例如,要将 nginx 副本的数量从 3 减少到 1,请执行以下操作: ```shell @@ -505,6 +506,7 @@ Now you only have one pod managed by the deployment. ```shell kubectl get pods -l app=nginx ``` + ``` NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m @@ -653,13 +655,13 @@ JSON merge patch、以及 strategic merge patch。 请参考 ## 破坏性的更新 {#disruptive-updates} 在某些情况下,你可能需要更新某些初始化后无法更新的资源字段,或者你可能只想立即进行递归更改, 例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段,请使用 `replace --force`, -它将删除并重新创建资源。在这种情况下,你可以简单地修改原始配置文件: +它将删除并重新创建资源。在这种情况下,你可以修改原始配置文件: ```shell kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force @@ -700,7 +702,7 @@ deployment.apps/my-nginx created ``` 要更新到 1.16.1 版本,只需使用我们前面学到的 kubectl 命令将 `.spec.template.spec.containers[0].image` 从 `nginx:1.14.2` 修改为 `nginx:1.16.1`。 diff --git a/content/zh/docs/concepts/cluster-administration/proxies.md b/content/zh/docs/concepts/cluster-administration/proxies.md index 808d8b31ec..be933ccc9c 100644 --- a/content/zh/docs/concepts/cluster-administration/proxies.md +++ b/content/zh/docs/concepts/cluster-administration/proxies.md @@ -73,7 +73,7 @@ There are several different proxies you may encounter when using Kubernetes: - proxies UDP, TCP and SCTP - does not understand HTTP - provides load balancing - - is just used to reach services + - is only used to reach services --> 3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips): diff --git a/content/zh/docs/concepts/cluster-administration/system-logs.md b/content/zh/docs/concepts/cluster-administration/system-logs.md index 799b566f6a..4fb9ba7c89 100644 --- a/content/zh/docs/concepts/cluster-administration/system-logs.md +++ b/content/zh/docs/concepts/cluster-administration/system-logs.md @@ -59,7 +59,7 @@ Migration to structured log messages is an ongoing process. Not all log messages Log formatting and value serialization are subject to change. --> -{{}} +{{< warning >}} 到结构化日志消息的迁移是一个持续的过程。 在此版本中,并非所有日志消息都是结构化的。 解析日志文件时,你也必须要处理非结构化日志消息。 @@ -68,22 +68,25 @@ Log formatting and value serialization are subject to change. {{< /warning>}} -结构化日志记录旨在日志消息中引入统一结构,以方便提取信息,使日志的存储和处理更容易、成本更低。 +结构化日志记录旨在日志消息中引入统一结构,以便以编程方式提取信息。 +你可以方便地用更小的开销来处理结构化日志。 新的消息格式向后兼容,并默认启用。 结构化日志的格式: -``` + +```ini "" ="" ="" ... ``` 示例: -``` + +```ini I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" ```