whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge master into dev-1.21 to keep in sync, plus latest API reference

Browse Source 
This sync merge includes API reference updates.
This commit is contained in:
Tim Bannister
2021-04-06 20:53:30 +01:00
parent 8dbf6671db d2bf43be4d 41f8e9da78
commit 965aa51daf
266 changed files with 72690 additions and 4933 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/nodes.md
+8 -4
View File
@@ -432,14 +432,16 @@ ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting
all the pods from the node (using graceful termination) if the node continues
to be unreachable. (The default timeouts are 40s to start reporting
ConditionUnknown and 5m after that to start evicting pods.) The node controller
checks the state of each node every `-node-monitor-period` seconds.
ConditionUnknown and 5m after that to start evicting pods.)
The node controller checks the state of each node every `-node-monitor-period` seconds.
-->
第三个是监控节点的健康情况。节点控制器负责在节点不可达
（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时，
将节点状态的 `NodeReady` 状况更新为 "`Unknown`"。
如果节点接下来持续处于不可达状态，节点控制器将逐出节点上的所有 Pod（使用体面终止）。
默认情况下 40 秒后开始报告 "`Unknown`"，在那之后 5 分钟开始逐出 Pod。
节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
<!--
@@ -506,8 +508,9 @@ the same time. If the fraction of unhealthy nodes is at least
if the cluster is small (i.e. has less than or equal to
`-large-cluster-size-threshold` nodes - default 50) then evictions are
stopped, otherwise the eviction rate is reduced to
`-secondary-node-eviction-rate` (default 0.01) per second. The reason these
policies are implemented per availability zone is because one availability zone
`-secondary-node-eviction-rate` (default 0.01) per second.
The reason these policies are implemented per availability zone is because one availability zone
might become partitioned from the master while the others remain connected. If
your cluster does not span multiple cloud provider availability zones, then
there is only one availability zone (the whole cluster).
@@ -518,6 +521,7 @@ there is only one availability zone (the whole cluster).
驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold`
个节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒
`--secondary-node-eviction-rate` 个（默认为 0.01）。
在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域
可能仍然保持连接。
如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。
content/zh/docs/concepts/cluster-administration/_index.md
+5 -5
View File
@@ -51,12 +51,12 @@ Before choosing a guide, here are some considerations:
在选择一个指南前，有一些因素需要考虑：
<!--
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
- Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
latter, choose an actively-developed distro. Some distros only use binary releases, but
offer a greater variety of choices.
- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
@@ -70,7 +70,7 @@ Before choosing a guide, here are some considerations:
- **如果你在本地配置 Kubernetes**，需要考虑哪种
[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？
- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？
- 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？
如果是后者，请选择一个处于开发状态的发行版。
某些发行版只提供二进制发布版，但提供更多的选择。
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
@@ -91,7 +91,7 @@ Before choosing a guide, here are some considerations:
<!--
## Securing a cluster
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
@@ -102,7 +102,7 @@ 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 管理的容器的环境。
content/zh/docs/concepts/cluster-administration/certificates.md
+2 -503
View File
@@ -12,508 +12,7 @@ weight: 20
<!-- overview -->
<!--
When using client certificate authentication, you can generate certificates
manually through `easyrsa`, `openssl` or `cfssl`.
To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/).
-->
当使用客户端证书进行认证时，用户可以使用现有部署脚本，或者通过 `easyrsa`、`openssl` 或
`cfssl` 手动生成证书。
<!-- body -->
### easyrsa
<!--
**easyrsa** can manually generate certificates for your cluster.
-->
使用 **easyrsa** 能够手动地为集群生成证书。
<!--
1. Download, unpack, and initialize the patched version of 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. Generate a new certificate authority (CA). `--batch` sets automatic mode;
`--req-cn` specifies the Common Name (CN) for the CA's new root certificate.
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
1. Generate server certificate and key.
The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will
be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR
that is specified as the `--service-cluster-ip-range` argument for both the API server and
the controller manager component. The argument `--days` is used to set the number of days
after which the certificate expires.
The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
./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. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory.
1. Fill in and add the following parameters into the API server start parameters:
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
-->
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** can manually generate certificates for your cluster.
1. Generate a ca.key with 2048bit:
openssl genrsa -out ca.key 2048
1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time):
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
1. Generate a server.key with 2048bit:
openssl genrsa -out server.key 2048
1. Create a config file for generating a Certificate Signing Request (CSR).
Be sure to substitute the values marked with angle brackets (e.g. `<MASTER_IP>`)
with real values before saving this to a file (e.g. `csr.conf`).
Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the
API server as described in previous subsection.
The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
[ 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 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
1. Generate the certificate signing request based on the config file:
openssl req -new -key server.key -out server.csr -config csr.conf
1. Generate the server certificate using the ca.key, ca.crt and 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. View the certificate:
openssl x509 -noout -text -in ./server.crt
-->
使用 **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_IP>`）
替换为你想使用的真实值。 注意：`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 = <MASTER_IP>
[ 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 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ 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
```
<!--
Finally, add the same parameters into the API server start parameters.
-->
最后，添加同样的参数到 API 服务器的启动参数中。
### cfssl
<!--
**cfssl** is another tool for certificate generation.
-->
**cfssl** 是用来生成证书的另一种工具。
<!--
1. Download, unpack and prepare the command line tools as shown below.
Note that you may need to adapt the sample commands based on the hardware
architecture and cfssl version you are using.
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. Create a directory to hold the artifacts and initialize cfssl:
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
1. Create a JSON config file for generating the CA file, for example, `ca-config.json`:
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
1. Create a JSON config file for CA certificate signing request (CSR), for example,
`ca-csr.json`. Be sure to replace the values marked with angle brackets with
real values you want to use.
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`):
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
1. Create a JSON config file for generating keys and certificates for the API
server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with
real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster
IP for the API server as described in previous subsection.
The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. Generate the key and certificate for the API server, which are by default
saved into file `server-key.pem` and `server.pem` respectively:
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
--config=ca-config.json -profile=kubernetes \
server-csr.json | ../cfssljson -bare server
-->
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": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
```
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",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
```
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
```
<!--
## Distributing Self-Signed CA Certificate
A client node may refuse to recognize a self-signed CA certificate as valid.
For a non-production deployment, or for a deployment that runs behind a company
firewall, you can distribute a self-signed CA certificate to all clients and
refresh the local list for valid certificates.
On each client, perform the following operations:
-->
## 分发自签名 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.
```
<!--
## Certificates API
You can use the `certificates.k8s.io` API to provision
x509 certificates to use for authentication as documented
[here](/docs/tasks/tls/managing-tls-in-a-cluster).
-->
## 证书 API
您可以按照[这里](/zh/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式，
使用 `certificates.k8s.io` API 来准备 x509 证书，用于认证。
要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。
content/zh/docs/concepts/cluster-administration/flow-control.md
+1 -1
View File
@@ -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.
-->
content/zh/docs/concepts/cluster-administration/manage-deployment.md
+15 -13
View File
@@ -72,7 +72,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
<!--
`kubectl` will read any files with suffixes `.yaml`, `.yml`, or `.json`.
It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, then you can then simply deploy all of the components of your stack en masse.
It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, then you can deploy all of the components of your stack together.
A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github:
-->
@@ -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
```
<!--
In the case of just two resources, it's also easy to specify both on the command line using the resource/name syntax:
In the case of two resources, it's also easy to specify both on the command line using the resource/name syntax:
-->
在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中
同时指定这两个资源：
@@ -138,13 +138,14 @@ service "my-nginx-svc" deleted
```
<!--
Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`:
Because `kubectl` outputs resource names in the same syntax it accepts, you can chain operations using `$()` or `xargs`:
-->
由于 `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
<!--
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
To see the pods you just labeled, run:
To see the pods you labeled, run:
-->
首先用标签 "app=nginx" 过滤所有的 Pod，然后用 "tier=fe" 标记它们。
想要查看你刚才标记的 Pod，请运行：
@@ -482,11 +483,11 @@ For more information, please see [annotations](/docs/concepts/overview/working-w
<!--
## Scaling your application
When load on your application grows or shrinks, it's easy to scale with `kubectl`. For instance, to decrease the number of nginx replicas from 3 to 1, do:
When load on your application grows or shrinks, use `kubectl` to scale you application. For instance, to decrease the number of nginx replicas from 3 to 1, do:
-->
## 扩缩你的应用
当应用上的负载增长或收缩时，使用 `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
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may just want to make a recursive change immediately, such as to fix broken pods created by a Deployment. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can simply modify your original configuration file:
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may want to make a recursive change immediately, such as to fix broken pods created by a Deployment. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can modify your original configuration file:
-->
## 破坏性的更新 {#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
```
<!--
To update to version 1.16.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`, with the kubectl commands we learned above.
To update to version 1.16.1, change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`, with the previous kubectl commands.
-->
要更新到 1.16.1 版本，只需使用我们前面学到的 kubectl 命令将
`.spec.template.spec.containers[0].image` 从 `nginx:1.14.2` 修改为 `nginx:1.16.1`。
content/zh/docs/concepts/cluster-administration/proxies.md
+1 -1
View File
@@ -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)：
content/zh/docs/concepts/cluster-administration/system-logs.md
+8 -5
View File
@@ -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>}}
{{< warning >}}
到结构化日志消息的迁移是一个持续的过程。
在此版本中，并非所有日志消息都是结构化的。
解析日志文件时，你也必须要处理非结构化日志消息。
@@ -68,22 +68,25 @@ Log formatting and value serialization are subject to change.
{{< /warning>}}
<!--
Structured logging is a effort to introduce a uniform structure in log messages allowing for easy extraction of information, making logs easier and cheaper to store and process.
Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost.
New message format is backward compatible and enabled by default.
Format of structured logs:
-->
结构化日志记录旨在日志消息中引入统一结构，以方便提取信息，使日志的存储和处理更容易、成本更低。
结构化日志记录旨在日志消息中引入统一结构，以便以编程方式提取信息。
你可以方便地用更小的开销来处理结构化日志。
新的消息格式向后兼容，并默认启用。
结构化日志的格式：
```
```ini
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
```
<!-- Example: -->
示例：
```
```ini
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
```
content/zh/docs/concepts/overview/components.md
+4 -4
View File
@@ -82,18 +82,18 @@ the same machine, and do not run user containers on this machine. See
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
<!--
These controllers include:
Some types of these controllers are:
* Node controller: Responsible for noticing and responding when nodes go down.
* Replication controller: Responsible for maintaining the correct number of pods for every replication
controller object in the system.
* Job controller: Watches for Job objects that represent one-off tasks, then creates
Pods to run those tasks to completion.
* Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
* Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
-->
这些控制器包括:
* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
* 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod
* 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
content/zh/docs/concepts/security/overview.md
+7 -4
View File
@@ -164,7 +164,7 @@ areas of security concerns and recommendations for securing workloads running in
Area of Concern for Workload Security | Recommendation |
------------------------------ | --------------------- |
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/
Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Pod Security Policies | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
@@ -178,10 +178,10 @@ TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networ
容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。
下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载：
工作负载安全性关注领域 | 建议 |
工作负载安全性关注领域 | 建议 |
------------------------------ | --------------------- |
RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
认证方式 | https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
认证方式 | https://kubernetes.io/zh/docs/concepts/security/controlling-access/
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/
Pod 安全策略 | https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/
服务质量（和集群资源管理）| https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
@@ -199,6 +199,7 @@ Area of Concern for Containers | Recommendation |
Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provider stronger isolation
-->
## 容器
@@ -209,7 +210,7 @@ Disallow privileged users | When constructing containers, consult your documenta
容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，您应该扫描您的容器里的已知漏洞。
镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。
禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。
使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。
<!--
## Code
@@ -262,6 +263,7 @@ Learn about related Kubernetes security topics:
* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
* [Runtime class](/docs/concepts/containers/runtime-class)
-->
学习了解相关的 Kubernetes 安全主题：
@@ -272,4 +274,5 @@ Learn about related Kubernetes security topics:
* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/)
* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/)
* [运行时类](/zh/docs/concepts/containers/runtime-class)
content/zh/docs/concepts/services-networking/connect-applications-service.md
+5 -5
View File
@@ -44,8 +44,8 @@ Create an nginx Pod, and note that it has a container port specification:
-->
## 在集群中暴露 Pod
我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。
创建一个 Nginx Pod，指示它具有一个容器端口的说明：
我们在之前的示例中已经做过，然而让我们以网络连接的视角再重做一遍。
创建一个 Nginx Pod，并且注意，它有一个容器端口的规范：
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
@@ -314,9 +314,9 @@ The rest of this section will assume you have a Service with a long lived IP
本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），
一个为该 IP 指派名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（应用名为 `kube-dns`），
所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：`gethostbyname()`）。
如果 CoreDNS 没有在运行，你可以参照
[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 或者
[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
如果 CoreDNS 没有在运行，你可以参照
[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 或者
[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
让我们运行另一个 curl 应用来进行测试：
```shell
content/zh/docs/concepts/storage/persistent-volumes.md
+14 -3
View File
@@ -69,7 +69,7 @@ Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求
模式之一来挂载，参见[访问模式](#access-modes)）。
<!--
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
-->
@@ -935,9 +935,9 @@ The following volume types support mount options:
* iSCSI
<!--
Mount options are not validated, so mount will simply fail if one is invalid.
Mount options are not validated, If a mount option is invalid, the mount fails.
-->
Kubernetes 不对挂载选项执行合法性检查，因此非法的挂载选项只是会导致挂载失败。
Kubernetes 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。
<!--
In the past, the annotation `volume.beta.kubernetes.io/mount-options` was used instead
@@ -1211,6 +1211,17 @@ PersistentVolume 卷的绑定是排他性的。
由于 PersistentVolumeClaim 是名字空间作用域的对象，使用
"Many" 模式（`ROX`、`RWX`）来挂载申领的操作只能在同一名字空间内进行。
<!--
### PersistentVolumes typed `hostPath`
A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage.
See [an example of `hostPath` typed volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
-->
### 类型为 `hostpath` 的 PersistentVolume {#persistentvolumes-typed-hostpath}
`hostPath` PersistentVolume 使用节点上的文件或目录来模拟网络附加（network-attached）存储。
相关细节可参阅[`hostPath` 卷示例](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)。
<!--
## Raw Block Volume Support
-->
content/zh/docs/concepts/storage/storage-classes.md
+4 -4
View File
@@ -225,14 +225,14 @@ mount options specified in the `mountOptions` field of the class.
If the volume plugin does not support mount options but mount options are
specified, provisioning will fail. Mount options are not validated on either
the class or PV, so mount of the PV will simply fail if one is invalid.
the class or PV, If a mount option is invalid, the PV mount fails.
-->
### 挂载选项
由 StorageClass 动态创建的 PersistentVolume 将使用类中 `mountOptions` 字段指定的挂载选项。
如果卷插件不支持挂载选项，却指定了该选项，则制备操作会失败。
挂载选项在 StorageClass 和 PV 上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。
如果卷插件不支持挂载选项，却指定了选项，则制备操作会失败。
挂载选项在 StorageClass 和 PV 上都不会做验证，如果其中一个挂载选项无效，那么这个 PV 挂载就会失败。
<!--
### Volume Binding Mode
@@ -1279,7 +1279,7 @@ parameters:
通常存在的 `default` 池。
* `description`：指定给动态创建的卷的描述。所有卷描述对于存储类而言都是相同的，
但不同的 storage class 可以使用不同的描述，以区分不同的使用场景。
默认为 `Kubernetas volume`。
默认为 `Kubernetes volume`。
* `fsType`：请求的默认文件系统类型。
请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
* `adminSecretNamespace`：API 配置 secret 所在的命名空间。
content/zh/docs/concepts/workloads/_index.md
+1 -2
View File
@@ -38,7 +38,7 @@ all the pods on that node fail. Kubernetes treats that level of failure as final
would need to create a new `Pod` to recover, even if the node later becomes healthy.
-->
Kubernetes Pods 有[确定的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
例如，一旦某 Pod 在你的集群中运行，Pod 运行所在的
例如，当某 Pod 在你的集群中运行时，Pod 运行所在的
{{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时，
所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：
即使该节点后来恢复正常运行，你也需要创建新的 Pod 来恢复应用。
@@ -172,4 +172,3 @@ using an [`Ingress`](/docs/concepts/services-networking/ingress).
[`Service`](/zh/docs/concepts/services-networking/service/)
的形式使之可在互联网上访问；或者对于 Web 应用而言，使用
[`Ingress`](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
content/zh/docs/concepts/workloads/controllers/cron-jobs.md
+8
View File
@@ -154,6 +154,14 @@ at least once.
如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且
`concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。
{{< caution >}}
<!--
If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds.
-->
如果 `startingDeadlineSeconds` 的设置值低于 10 秒钟，CronJob 可能无法被调度。
这是因为 CronJob 控制器每 10 秒钟执行一次检查。
{{< /caution >}}
<!--
For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
-->
content/zh/docs/concepts/workloads/controllers/daemonset.md
+2 -2
View File
@@ -278,8 +278,8 @@ the related features.
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | DaemonSet Pod 被默认调度器调度时能够容忍磁盘压力属性。 |
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | DaemonSet Pod 被默认调度器调度时能够容忍内存压力属性。 |
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet Pod 能够容忍默认调度器所设置的 `unschedulable` 属性. |
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet 在使用宿主网络时，能够容忍默认调度器所设置的 `network-unavailable` 属性。 |
content/zh/docs/concepts/workloads/controllers/deployment.md
+14 -13
View File
@@ -102,24 +102,25 @@ In this example:
<!--
* The `selector` field defines how the Deployment finds which Pods to manage.
In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
In this case, you select a label that is defined in the Pod template (`app: nginx`).
However, more sophisticated selection rules are possible,
as long as the Pod template itself satisfies the rule.
-->
* `selector` 字段定义 Deployment 如何查找要管理的 Pods。
在这里，你只需选择在 Pod 模板中定义的标签（`app: nginx`）。
在这里，你选择在 Pod 模板中定义的标签（`app: nginx`）。
不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可。
{{< note >}}
<!--
The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
and the values array contains only "value".
The `spec.selector.matchLabels` field is a map of {key,value} pairs.
A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value".
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
-->
{{< note >}}
`matchLabels` 字段是 `{key,value}` 偶对的映射。在 `matchLabels` 映射中的单个 `{key,value}`
映射等效于 `matchExpressions` 中的一个元素，即其 `key` 字段是 “key”，operator 为 “In”，`value`
数组仅包含 “value”。在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
`spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
在 `matchLabels` 映射中的每个 `{key,value}` 映射等效于 `matchExpressions` 中的一个元素，
即其 `key` 字段是 “key”，`operator` 为 “In”，`values` 数组仅包含 “value”。
在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
{{< /note >}}
<!--
@@ -347,7 +348,7 @@ is changed, for example if the labels or container images of the template are up
deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
<!--
or simply use the following command:
or use the following command:
-->
或者使用下面的命令：
@@ -355,7 +356,7 @@ is changed, for example if the labels or container images of the template are up
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
```
<!-- The output is similar to this: -->
<!-- The output is similar to: -->
输出类似于：
```
@@ -429,7 +430,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
kubectl get rs
```
<!-- The output is similar to this: -->
<!-- The output is similar to: -->
输出类似于：
```
@@ -1179,7 +1180,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。
<!--
* For example, with a Deployment that was just created:
* For example, with a Deployment that was created:
Get the Deployment details:
-->
* 例如，对于一个刚刚创建的 Deployment：
content/zh/docs/concepts/workloads/controllers/job.md
+1 -1
View File
@@ -139,7 +139,7 @@ pi-5rwd7
<!--
Here, the selector is the same as the selector for the Job. The `-output=jsonpath` option specifies an expression
that just gets the name from each Pod in the returned list.
with the name from each Pod in the returned list.
View the standard output of one of the pods:
-->
content/zh/docs/concepts/workloads/controllers/replicaset.md
+3 -3
View File
@@ -345,7 +345,7 @@ pod2 1/1 Running 0 36s
## Writing a ReplicaSet Spec
As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields.
For ReplicaSets, the kind is always just ReplicaSet.
For ReplicaSets, the `kind` is always a ReplicaSet.
In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
Refer to the first lines of the `frontend.yaml` example for guidance.
@@ -357,7 +357,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
## 编写 ReplicaSet 的 spec
与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。
对于 ReplicaSets 而言，其 kind 始终是 ReplicaSet。
对于 ReplicaSets 而言，其 `kind` 始终是 ReplicaSet。
在 Kubernetes 1.9 中，ReplicaSet 上的 API 版本 `apps/v1` 是其当前版本，且被
默认启用。API 版本 `apps/v1beta2` 已被废弃。
参考 `frontend.yaml` 示例的第一行。
@@ -375,7 +375,7 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-temp
required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
For the template's [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) field,
For the template's [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) field,
`.spec.template.spec.restartPolicy`, the only allowed value is `Always`, which is the default.
-->
### Pod 模版
content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
+14 -11
View File
@@ -174,10 +174,10 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
<!--
Here, the selector is the same as the selector for the ReplicationController (seen in the
`kubectl describe` output), and in a different form in `replication.yaml`. The `--output=jsonpath` option
specifies an expression that just gets the name from each pod in the returned list.
specifies an expression with the name from each pod in the returned list.
-->
这里，选择算符与 ReplicationController 的选择算符相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。
`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 Pod 中获取名称。
`--output=jsonpath` 选项指定了一个表达式，仅从返回列表中的每个 Pod 中获取名称。
<!--
## Writing a ReplicationController Spec
@@ -305,7 +305,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
command is interrupted, it can be restarted.
When using the REST API or go client library, you need to do the steps explicitly (scale replicas to
When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
0, wait for pod deletions, then delete the ReplicationController).
-->
## 使用 ReplicationController {#working-with-replicationcontrollers}
@@ -317,16 +317,17 @@ When using the REST API or go client library, you need to do the steps explicitl
kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
如果这个 kubectl 命令被中断，可以重新启动它。
当使用 REST API 或 go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。
当使用 REST API 或 Go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、
等待 Pod 删除，之后删除 ReplicationController 资源）。
<!--
### Deleting just a ReplicationController
### Deleting only a ReplicationController
You can delete a ReplicationController without affecting any of its pods.
Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
When using the REST API or go client library, simply delete the ReplicationController object.
When using the REST API or Go client library, simply delete the ReplicationController object.
-->
### 只删除 ReplicationController
@@ -334,7 +335,7 @@ When using the REST API or go client library, simply delete the ReplicationContr
使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。
当使用 REST API 或 go 客户端库时，只需删除 ReplicationController 对象。
当使用 REST API 或 Go 客户端库时，只需删除 ReplicationController 对象。
<!--
Once the original is deleted, you can create a new ReplicationController to replace it. As long
@@ -373,11 +374,13 @@ As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
<!--
### Scaling
The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
The ReplicationController scales the number of replicas up or down by setting the `replicas` field.
You can configure the ReplicationController to manage the replicas manually or by an auto-scaling control agent.
-->
### 扩缩容 {#scaling}
通过简单地更新 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量，或手动或通过自动缩放控制代理。
通过设置 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量。
你可以手动或通过自动缩放控制代理来控制 ReplicationController 执行此操作。
<!--
### Rolling updates
@@ -463,11 +466,11 @@ Pods created by a ReplicationController are intended to be fungible and semantic
<!--
## Responsibilities of the ReplicationController
The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
The ReplicationController ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
-->
## ReplicationController 的职责
ReplicationController 只需确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。
ReplicationController 仅确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。
目前，它的计数中只排除终止的 Pod。
未来，可能会考虑系统提供的[就绪状态](https://issue.k8s.io/620)和其他信息，
我们可能会对替换策略添加更多控制，
content/zh/docs/concepts/workloads/pods/_index.md
+1 -1
View File
@@ -54,7 +54,7 @@ for debugging if your cluster offers this.
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/)
的情况外，为调试的目的注入临时性容器。
的情况下，为调试的目的注入临时性容器。
<!-- body -->
content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md
+4 -4
View File
@@ -43,7 +43,7 @@ Controller Manager. The tokens are also used to create a signature for a
specific ConfigMap used in a "discovery" process through a BootstrapSigner
controller.
-->
启动引导令牌被定义成一个特定类型的 Secret （`bootstrap.kubernetes.io/token`），
启动引导令牌被定义成一个特定类型的 Secret（`bootstrap.kubernetes.io/token`），
并存在于 `kube-system` 名字空间中。
这些 Secret 会被 API 服务器上的启动引导认证组件（Bootstrap Authenticator）读取。
控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。
@@ -66,9 +66,9 @@ only be shared with trusted parties.
启动引导令牌使用 `abcdef.0123456789abcdef` 的形式。
更加规范地说，它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。
令牌的第一部分是 "Token ID"，它是一种公开信息，用于引用令牌并确保不会
令牌的第一部分是 “Token ID”，它是一种公开信息，用于引用令牌并确保不会
泄露认证所使用的秘密信息。
第二部分是"令牌秘密（Token Secret）"，它应该被共享给受信的第三方。
第二部分是“令牌秘密（Token Secret）”，它应该被共享给受信的第三方。
## 启用启动引导令牌
@@ -275,7 +275,7 @@ verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
`07401b.f395accd246ae52d`) as the shared secret. Users _must_ verify that HS256
is used.
-->
签名是一个使用 "detached" 模式生成的 JWS 签名。
签名是一个使用 “detached” 模式生成的 JWS 签名。
为了检验签名，用户应该按照 JWS 规则（base64 编码且丢掉结尾的 `=`）对
`kubeconfig` 的载荷进行编码。完成编码的载荷会被插入到两个句点中间，形成完整的
JWS。你可以使用完整的令牌（比如 `07401b.f395accd246ae52d`）作为共享密钥，
content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+1 -1
View File
@@ -130,7 +130,7 @@ kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
extraArgs:
address: 0.0.0.0
bind-address: 0.0.0.0
config: /home/johndoe/schedconfig.yaml
kubeconfig: /home/johndoe/kubeconfig.yaml
```
content/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+1 -1
View File
@@ -128,7 +128,7 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
<!--
### Installing kubeadm on your hosts
-->
### 在你的主机上安装安装 kubeadm
### 在你的主机上安装 kubeadm
<!--
See ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+52 -47
View File
@@ -30,14 +30,7 @@ For information how to create a cluster with kubeadm once you have performed thi
## {{% heading "prerequisites" %}}
<!--
* One or more machines running one of:
- Ubuntu 16.04+
- Debian 9+
- CentOS 7+
- Red Hat Enterprise Linux (RHEL) 7+
- Fedora 25+
- HypriotOS v1.0.1+
- Flatcar Container Linux (tested with 2512.3.0)
* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
* 2 CPUs or more
* Full network connectivity between all machines in the cluster (public or private network is fine)
@@ -45,14 +38,8 @@ For information how to create a cluster with kubeadm once you have performed thi
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
-->
* 一台或多台运行着下列系统的机器：
- Ubuntu 16.04+
- Debian 9+
- CentOS 7+
- Red Hat Enterprise Linux (RHEL) 7+
- Fedora 25+
- HypriotOS v1.0.1+
- Flatcar Container Linux （使用 2512.3.0 版本测试通过）
* 一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux
发行版以及一些不提供包管理器的发行版提供通用的指令
* 每台机器 2 GB 或更多的 RAM （如果少于这个数字将会影响你应用的运行内存)
* 2 CPU 核或更多
* 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以)
@@ -211,7 +198,7 @@ The following table lists container runtimes and their associated socket paths:
| Runtime | Domain Socket |
|------------|---------------------------------|
| Docker | /var/run/docker.sock |
| Docker | /var/run/dockershim.sock |
| containerd | /run/containerd/containerd.sock |
| CRI-O | /var/run/crio/crio.sock |
-->
@@ -225,7 +212,7 @@ The following table lists container runtimes and their associated socket paths:
| 运行时 | 域套接字 |
|------------|----------------------------------|
| Docker | /var/run/docker.sock |
| Docker | /var/run/dockershim.sock |
| containerd | /run/containerd/containerd.sock |
| CRI-O | /var/run/crio/crio.sock |
@@ -289,7 +276,7 @@ kubelet and the control plane is supported, but the kubelet version may never ex
server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
but not vice versa.
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/).
-->
## 安装 kubeadm、kubelet 和 kubectl
@@ -308,7 +295,7 @@ kubeadm **不能** 帮你安装或者管理 `kubelet` 或 `kubectl`，所以你
的版本不可以超过 API 服务器的版本。
例如，1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 服务器，反之则不可以。
有关安装 `kubectl` 的信息，请参阅[安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)文档。
有关安装 `kubectl` 的信息，请参阅[安装和设置 kubectl](/zh/docs/tasks/tools/)文档。
{{< warning >}}
<!--
@@ -332,22 +319,50 @@ For more information on version skews, see:
* Kubeadm 特定的[版本偏差策略](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
{{% tab name="基于 Debian 的发行版" %}}
```bash
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
<!--
1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
-->
1. 更新 `apt` 包索引并安装使用 Kubernetes `apt` 仓库所需要的包：
```shell
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
```
<!--
2. Download the Google Cloud public signing key:
-->
2. 下载 Google Cloud 公开签名秘钥：
```shell
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
```
<!--
3. Add the Kubernetes `apt` repository:
-->
3. 添加 Kubernetes `apt` 仓库：
```shell
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
<!--
4. Update `apt` package index, install kubelet, kubeadm and kubectl, and pin their version:
-->
4. 更新 `apt` 包索引，安装 kubelet、kubeadm 和 kubectl，并锁定其版本：
```shell
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
{{% /tab %}}
{{% tab name="CentOS、RHEL 或 Fedora" %}}
{{% tab name="基于 Red Hat 的发行版" %}}
```bash
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
@@ -391,7 +406,7 @@ systemctl enable --now kubelet
配置是 kubeadm 所不支持的。
{{% /tab %}}
{{% tab name="Fedora CoreOS 或 Flatcar Container Linux" %}}
{{% tab name="无包管理器的情况" %}}
<!--
Install CNI plugins (required for most pod network):
@@ -411,11 +426,11 @@ Define the directory to download command files
{{< note >}}
<!--
The DOWNLOAD_DIR variable must be set to a writable directory.
If you are running Flatcar Container Linux, set DOWNLOAD_DIR=/opt/bin.
The `DOWNLOAD_DIR` variable must be set to a writable directory.
If you are running Flatcar Container Linux, set `DOWNLOAD_DIR=/opt/bin`.
-->
DOWNLOAD_DIR 变量必须被设置为一个可写入的目录。
如果你在运行 Flatcar Container Linux，可将 DOWNLOAD_DIR 设置为 /opt/bin。
`DOWNLOAD_DIR` 变量必须被设置为一个可写入的目录。
如果你在运行 Flatcar Container Linux，可将 `DOWNLOAD_DIR` 设置为 `/opt/bin`。
{{< /note >}}
```bash
@@ -531,16 +546,6 @@ or `/etc/default/kubelet`(`/etc/sysconfig/kubelet` for RPMs), please remove it a
`/var/lib/kubelet/config.yaml` 文件中）。
{{< /note >}}
<!--
Restarting the kubelet is required:
-->
需要重新启动 kubelet：
```bash
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
<!--
The automatic detection of cgroup driver for other container runtimes
like CRI-O and containerd is work in progress.
content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+1 -1
View File
@@ -104,7 +104,7 @@ In summary, `kubeadm alpha selfhosting` works as follows:
for secrets.
-->
2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
它还会在必要时修改这些清单，例如添加新的秘密卷。
它还会在必要时修改这些清单，例如添加新的 secrets 卷。
<!--
1. Creates DaemonSets in the `kube-system` namespace and waits for the
content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
+1 -1
View File
@@ -153,7 +153,7 @@ data:
ttl 30
}
prometheus :9153
forward ./etc/resolv.conf
forward . /etc/resolv.conf
cache 30
loop
reload
content/zh/docs/tasks/administer-cluster/kms-provider.md
+1 -1
View File
@@ -79,7 +79,7 @@ Refer to your cloud provider for instructions on enabling the cloud provider-spe
-->
### 启用由云服务驱动支持的 KMS
有关启用云服务驱动特定的 KMS 插件的说明，请咨询你的云服务驱动。
有关启用云服务驱动特定的 KMS 插件的说明，请咨询你的云服务驱动商。
<!--
### Developing a KMS plugin gRPC server
content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+1 -1
View File
@@ -269,7 +269,7 @@ to do so are available at [Install Docker Engine - Enterprise on Windows Servers
All code snippets in Windows sections are to be run in a PowerShell environment
with elevated permissions (Administrator) on the Windows worker node.
-->
### 加入 Windows 工作节点 {joining-a-windows-worker-node}
### 加入 Windows 工作节点 {#joining-a-windows-worker-node}
你必须安装 `Containers` 功能特性并安装 Docker 工具。相关的指令可以在
[Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)
content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
+4 -3
View File
@@ -160,20 +160,21 @@ kubernetes 系统守护进程记述其资源预留值。
kubernetes 系统守护进程预留指定数量的进程 ID。
<!--
To optionally enforce `kube-reserved` on system daemons, specify the parent
To optionally enforce `kube-reserved` on kubernetes system daemons, specify the parent
control group for kube daemons as the value for `--kube-reserved-cgroup` kubelet
flag.
It is recommended that the kubernetes system daemons are placed under a top
level control group (`runtime.slice` on systemd machines for example). Each
system daemon should ideally run within its own child control group. Refer to
[this doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
[this
doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
for more details on recommended control group hierarchy.
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified.
-->
要选择性地对系统守护进程上执行 `kube-reserved` 保护，需要把 kubelet 的
要选择性地对 kubernetes 系统守护进程上执行 `kube-reserved` 保护，需要把 kubelet 的
`--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的
content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md
+1 -1
View File
@@ -360,7 +360,7 @@ By default, they are set to 3 and 1 respectively. Setting a limit to `0` corres
### 任务历史限制
`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit`是可选的。
这两个域声明了有多少执行完成和失败的任务会被保留。
这两个字段指定应保留多少已完成和失败的任务。
默认设置为3和1。限制设置为0代表相应类型的任务完成后不会保留。
content/zh/docs/tasks/tls/manual-rotation-of-ca-certificates.md
+10 -10
View File
@@ -98,12 +98,12 @@ Configurations with a single API server will experience unavailability while the
也会获得此更新并且同时信任老的和新的 CA 证书。
<!--
```shell
base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
base64_encoded_ca="$(base64 -w0 <path to file containing both old and new CAs>)"
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
done
done
@@ -111,12 +111,12 @@ Configurations with a single API server will experience unavailability while the
-->
```shell
base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
base64_encoded_ca="$(base64 -w0 <path to file containing both old and new CAs>)"
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
done
done
@@ -205,13 +205,13 @@ Configurations with a single API server will experience unavailability while the
<!--
To generate certificates and private keys for your cluster using the `openssl`
command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl).
You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).
-->
{{< note >}}
要使用 `openssl` 命令行为集群生成新的证书和私钥，可参阅
[证书（`openssl`）](/zh/docs/concepts/cluster-administration/certificates/#openssl)。
你也可以使用[`cfssl`](/zh/docs/concepts/cluster-administration/certificates/#cfssl).
[证书（`openssl`）](/zh/docs/tasks/administer-cluster/certificates/#openssl)。
你也可以使用[`cfssl`](/zh/docs/tasks/administer-cluster/certificates/#cfssl).
{{< /note >}}
<!--
@@ -249,10 +249,10 @@ Configurations with a single API server will experience unavailability while the
ConfigMap `cluster-info`，使之包含新的 CA 证书。
```shell
base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
kubectl get cm/cluster-info --namespace kube-public -o yaml | \
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
```
<!--
content/zh/docs/tasks/tools/included/install-kubectl-gcloud.md
+37
View File
@@ -0,0 +1,37 @@
---
title: "通过 gcloud 安装 kubectl"
description: "用各个特定操作系统标签页中包含的 gcloud 指令片段安装 kubectl。"
headless: true
---
<!--
---
title: "gcloud kubectl install"
description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab."
headless: true
---
-->
<!--
You can install kubectl as part of the Google Cloud SDK.
-->
kubectl 可以作为 Google Cloud SDK 的一部分被安装。
<!--
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
1. Run the `kubectl` installation command:
-->
1. 安装 [Google Cloud SDK](https://cloud.google.com/sdk/)。
1. 运行安装 `kubectl` 的命令：
```shell
gcloud components install kubectl
```
<!--
1. Test to ensure the version you installed is up-to-date:
-->
1. 验证一下，确保安装的是最新的版本：
```shell
kubectl version --client
```
content/zh/docs/tasks/tools/included/kubectl-whats-next.md
+27
View File
@@ -0,0 +1,27 @@
---
title: "后续内容"
description: "安装 kubectl 之后，还可以做些什么？"
headless: true
---
<!--
---
title: "What's next?"
description: "What's next after installing kubectl."
headless: true
---
-->
<!--
* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/)
* See the [getting started guides](/docs/setup/) for more about creating clusters.
* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* If you need access to a cluster you didn't create, see the
[Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
-->
* [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/)
* 有关创建集群的更多信息，请参阅[入门指南](/zh/docs/setup/).
* [学习如何启动并对外公开你的应用程序。](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 如果你需要访问其他人创建的集群，请参阅
[共享集群接入文档](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* 阅读 [kubectl 参考文档](/zh/docs/reference/kubectl/kubectl/)
content/zh/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
+109
View File
@@ -0,0 +1,109 @@
---
title: "Linux 系统中的 bash 自动补全功能"
description: "Linux 系统中 bash 自动补全功能的一些可选配置。"
headless: true
---
<!--
---
title: "bash auto-completion on Linux"
description: "Some optional configuration for bash auto-completion on Linux."
headless: true
---
-->
<!--
### Introduction
-->
### 简介 {#introduction}
<!--
The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
-->
kubectl 的 Bash 补全脚本可以用命令 `kubectl completion bash` 生成。
在 shell 中导入（Sourcing）补全脚本，将启用 kubectl 自动补全功能。
然而，补全脚本依赖于工具 [**bash-completion**](https://github.com/scop/bash-completion)，
所以要先安装它（可以用命令 `type _init_completion` 检查 bash-completion 是否已安装）。
<!--
### Install bash-completion
-->
### 安装 bash-completion {#install-bash-comletion}
<!--
bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
-->
很多包管理工具均支持 bash-completion（参见[这里](https://github.com/scop/bash-completion#installation)）。
可以通过 `apt-get install bash-completion` 或 `yum install bash-completion` 等命令来安装它。
上述命令将创建文件 `/usr/share/bash-completion/bash_completion`，它是 bash-completion 的主脚本。
依据包管理工具的实际情况，你需要在 `~/.bashrc` 文件中手工导入此文件。
要查看结果，请重新加载你的 shell，并运行命令 `type _init_completion`。
如果命令执行成功，则设置完成，否则将下面内容添加到文件 `~/.bashrc` 中：
```bash
source /usr/share/bash-completion/bash_completion
```
<!--
Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
-->
重新加载 shell，再输入命令 `type _init_completion` 来验证 bash-completion 的安装状态。
<!--
### Enable kubectl autocompletion
-->
### 启动 kubectl 自动补全功能 {#enable-kubectl-autocompletion}
<!--
You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
-->
你现在需要确保一点：kubectl 补全脚本已经导入（sourced）到 shell 会话中。
这里有两种验证方法：
<!--
- Source the completion script in your `~/.bashrc` file:
-->
- 在文件 `~/.bashrc` 中导入（source）补全脚本：
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
<!--
- Add the completion script to the `/etc/bash_completion.d` directory:
-->
- 将补全脚本添加到目录 `/etc/bash_completion.d` 中：
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
<!--
If you have an alias for kubectl, you can extend shell completion to work with that alias:
-->
如果 kubectl 有关联的别名，你可以扩展 shell 补全来适配此别名：
```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
<!--
bash-completion sources all completion scripts in `/etc/bash_completion.d`.
-->
bash-completion 负责导入 `/etc/bash_completion.d` 目录中的所有补全脚本。
{{< /note >}}
<!--
Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
-->
两种方式的效果相同。重新加载 shell 后，kubectl 自动补全功能即可生效。
content/zh/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md
+173
View File
@@ -0,0 +1,173 @@
---
title: "macOS 系统上的 bash 自动补全"
description: "在 macOS 上实现 Bash 自动补全的一些可选配置。"
headless: true
---
<!--
---
title: "bash auto-completion on macOS"
description: "Some optional configuration for bash auto-completion on macOS."
headless: true
---
-->
<!--
### Introduction
-->
### 简介
<!--
The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
-->
kubectl 的 Bash 补全脚本可以通过 `kubectl completion bash` 命令生成。
在你的 shell 中导入（Sourcing）这个脚本即可启用补全功能。
此外，kubectl 补全脚本依赖于工具 [**bash-completion**](https://github.com/scop/bash-completion)，
所以你必须先安装它。
{{< warning>}}
<!--
There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
-->
bash-completion 有两个版本：v1 和 v2。v1 对应 Bash3.2（也是 macOS 的默认安装版本），v2 对应 Bash 4.1+。
kubectl 的补全脚本**无法适配** bash-completion v1 和 Bash 3.2。
必须为它配备 **bash-completion v2** 和 **Bash 4.1+**。
有鉴于此，为了在 macOS 上使用 kubectl 补全功能，你必须要安装和使用 Bash 4.1+
([*说明*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba))。
后续说明假定你用的是 Bash 4.1+（也就是 Bash 4.1 或更新的版本）
{{< /warning >}}
<!--
### Upgrade Bash
-->
### 升级 Bash
<!--
The instructions here assume you use Bash 4.1+. You can check your Bash's version by running:
-->
后续说明假定你已使用 Bash 4.1+。你可以运行以下命令检查 Bash 版本：
```bash
echo $BASH_VERSION
```
<!--
If it is too old, you can install/upgrade it using Homebrew:
-->
如果版本太旧，可以用 Homebrew 安装/升级：
```bash
brew install bash
```
<!--
Reload your shell and verify that the desired version is being used:
-->
重新加载 shell，并验证所需的版本已经生效：
```bash
echo $BASH_VERSION $SHELL
```
<!--
Homebrew usually installs it at `/usr/local/bin/bash`.
-->
Homebrew 通常把它安装为 `/usr/local/bin/bash`。
<!--
### Install bash-completion
-->
### 安装 bash-completion
{{< note >}}
<!--
As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
-->
如前所述，本说明假定你使用的 Bash 版本为 4.1+，这意味着你要安装 bash-completion v2
（不同于 Bash 3.2 和 bash-completion v1，kubectl 的补全功能在该场景下无法工作）。
{{< /note >}}
<!--
You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
-->
你可以用命令 `type _init_completion` 测试 bash-completion v2 是否已经安装。
如未安装，用 Homebrew 来安装它：
```bash
brew install bash-completion@2
```
<!--
As stated in the output of this command, add the following to your `~/.bash_profile` file:
-->
如命令的输出信息所显示的，将如下内容添加到文件 `~/.bash_profile` 中：
```bash
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
<!--
Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
-->
重新加载 shell，并用命令 `type _init_completion` 验证 bash-completion v2 已经恰当的安装。
<!--
### Enable kubectl autocompletion
-->
### 启用 kubectl 自动补全功能
<!--
You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
- Source the completion script in your `~/.bash_profile` file:
-->
你现在需要确保在所有的 shell 环境中均已导入（sourced） kubectl 的补全脚本，
有若干种方法可以实现这一点：
- 在文件 `~/.bash_profile` 中导入（Source）补全脚本：
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
<!--
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
-->
- 将补全脚本添加到目录 `/usr/local/etc/bash_completion.d` 中：
```bash
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
<!--
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
-->
- 如果你为 kubectl 定义了别名，则可以扩展 shell 补全来兼容该别名：
```bash
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
<!--
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
-->
- 如果你是用 Homebrew 安装的 kubectl（[如上所述](#install-with-homebrew-on-macos)），
那么 kubectl 补全脚本应该已经安装到目录 `/usr/local/etc/bash_completion.d/kubectl` 中了。
这种情况下，你什么都不需要做。
{{< note >}}
<!--
The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
-->
用 Hommbrew 安装的 bash-completion v2 会初始化 目录 `BASH_COMPLETION_COMPAT_DIR` 中的所有文件，这就是后两种方法能正常工作的原因。
{{< /note >}}
<!--
In any case, after reloading your shell, kubectl completion should be working.
-->
总之，重新加载 shell 之后，kubectl 补全功能将立即生效。
content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md
+50
View File
@@ -0,0 +1,50 @@
---
title: "zsh 自动补全"
description: "zsh 自动补全的一些可选配置"
headless: true
---
<!--
---
title: "zsh auto-completion"
description: "Some optional configuration for zsh auto-completion."
headless: true
---
-->
<!--
The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion.
To do so in all your shell sessions, add the following to your `~/.zshrc` file:
-->
kubectl 通过命令 `kubectl completion zsh` 生成 Zsh 自动补全脚本。
在 shell 中导入（Sourcing）该自动补全脚本，将启动 kubectl 自动补全功能。
为了在所有的 shell 会话中实现此功能，请将下面内容加入到文件 `~/.zshrc` 中。
```zsh
source <(kubectl completion zsh)
```
<!--
If you have an alias for kubectl, you can extend shell completion to work with that alias:
-->
如果你为 kubectl 定义了别名，可以扩展脚本补全，以兼容该别名。
```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
```
<!--
After reloading your shell, kubectl autocompletion should be working.
If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
-->
重新加载 shell 后，kubectl 自动补全功能将立即生效。
如果你收到 `complete:13: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头：
```zsh
autoload -Uz compinit
compinit
```
content/zh/docs/tasks/tools/included/verify-kubectl.md
+62
View File
@@ -0,0 +1,62 @@
---
title: "验证 kubectl 的安装效果"
description: "如何验证 kubectl。"
headless: true
---
<!--
---
title: "verify kubectl install"
description: "How to verify kubectl."
headless: true
---
-->
<!--
In order for kubectl to find and access a Kubernetes cluster, it needs a
[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/),
which is created automatically when you create a cluster using
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
or successfully deploy a Minikube cluster.
By default, kubectl configuration is located at `~/.kube/config`.
Check that kubectl is properly configured by getting the cluster state:
-->
为了让 kubectl 能发现并访问 Kubernetes 集群，你需要一个
[kubeconfig 文件](/docs/zh/concepts/configuration/organize-cluster-access-kubeconfig/)，
该文件在
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
创建集群时，或成功部署一个 Miniube 集群时，均会自动生成。
通常，kubectl 的配置信息存放于文件 `~/.kube/config` 中。
通过获取集群状态的方法，检查是否已恰当的配置了 kubectl：
```shell
kubectl cluster-info
```
<!--
If you see a URL response, kubectl is correctly configured to access your cluster.
If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster.
-->
如果返回一个 URL，则意味着 kubectl 成功的访问到了你的集群。
如果你看到如下所示的消息，则代表 kubectl 配置出了问题，或无法连接到 Kubernetes 集群。
```
The connection to the server <server-name:port> was refused - did you specify the right host or port?
（访问 <server-name:port> 被拒绝 - 你指定的主机和端口是否有误？）
```
<!--
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above.
If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
-->
例如，如果你想在自己的笔记本上（本地）运行 Kubernetes 集群，你需要先安装一个 Minikube 这样的工具，然后再重新运行上面的命令。
如果命令 `kubectl cluster-info` 返回了 url，但你还不能访问集群，那可以用以下命令来检查配置是否妥当：
```shell
kubectl cluster-info dump
```
content/zh/docs/tasks/tools/install-kubectl-linux.md
+262
View File
@@ -0,0 +1,262 @@
---
title: 在 Linux 系统中安装并设置 kubectl
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: 在 Linux 系统中安装 kubectl
---
<!--
---
reviewers:
- mikedanese
title: Install and Set Up kubectl on Linux
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Install kubectl on Linux
---
-->
## {{% heading "prerequisites" %}}
<!--
You must use a kubectl version that is within one minor version difference of your cluster.
For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
Using the latest version of kubectl helps avoid unforeseen issues.
-->
kubectl 版本和集群版本之间的差异必须在一个小版本号内。
例如：v1.2 版本的客户端只能与 v1.1、v1.2 和 v1.3 版本的集群一起工作。
用最新版的 kubectl 有助于避免不可预见的问题。
<!--
## Install kubectl on Linux
-->
## 在 Linux 系统中安装 kubectl {#install-kubectl-on-linux}
<!--
The following methods exist for installing kubectl on Linux:
-->
在 Linux 系统中安装 kubectl 有如下几种方法：
- [{{% heading "prerequisites" %}}](#{{% heading "prerequisites" %}})
- [在 Linux 系统中安装 kubectl](#install-kubectl-on-linux)
- [用 curl 在 Linux 系统中安装 kubectl](#install-kubectl-binary-with-curl-on-linux)
- [用原生包管理工具安装](#install-using-native-package-management)
- [用其他包管理工具安装](#install-using-other-package-management)
- [作为谷歌云 SDK 的一部分，在 Linux 中安装](#install-on-linux-as-part-of-the-google-cloud-sdk)
- [验证 kubectl 配置](#verify-kubectl-configration)
- [可选的 kubectl 配置](#optional-kubectl-configurations)
- [启用 shell 自动补全功能](#enable-shell-autocompletion)
- [{{% heading "whatsnext" %}}](#{{% heading "whatsnext" %}})
<!--
### Install kubectl binary with curl on Linux
-->
### 用 curl 在 Linux 系统中安装 kubectl {#install-kubectl-binary-with-curl-on-linux}
<!--
1. Download the latest release with the command:
-->
1. 用以下命令下载最新发行版：
```bash
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
```
{{< note >}}
<!--
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on Linux, type:
-->
如需下载某个指定的版本，请用指定版本号替换该命令的这一部分： `$(curl -L -s https://dl.k8s.io/release/stable.txt)`。
例如，要在 Linux 中下载 {{< param "fullversion" >}} 版本，请输入：
```bash
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
{{< /note >}}
<!--
1. Validate the binary (optional)
Download the kubectl checksum file:
-->
1. 验证该可执行文件（可选步骤）
下载 kubectl 校验和文件：
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
```
<!--
Validate the kubectl binary against the checksum file:
-->
基于校验和文件，验证 kubectl 的可执行文件：
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
```
<!--
If valid, the output is:
-->
验证通过时，输出为：
```console
kubectl: OK
```
<!--
If the check fails, `sha256` exits with nonzero status and prints output similar to:
-->
验证失败时，`sha256` 将以非零值退出，并打印如下输出：
```bash
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
<!--
Download the same version of the binary and checksum.
-->
下载的 kubectl 与校验和文件版本必须相同。
{{< /note >}}
<!--
1. Install kubectl
-->
1. 安装 kubectl
```bash
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
```
{{< note >}}
<!--
If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
-->
即使你没有目标系统的 root 权限，仍然可以将 kubectl 安装到目录 `~/.local/bin` 中：
```bash
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH
```
{{< /note >}}
<!--
1. Test to ensure the version you installed is up-to-date:
-->
1. 执行测试，以保障你安装的版本是最新的：
```bash
kubectl version --client
```
<!--
### Install using native package management
-->
### 用原生包管理工具安装 {#install-using-native-package-management}
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu、Debian 或 HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
{{< tab name="CentOS、RHEL 或 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl
{{< /tab >}}
{{< /tabs >}}
<!--
### Install using other package management
-->
### 用其他包管理工具安装 {#install-using-other-package-management}
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
<!--
If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
-->
如果你使用的 Ubuntu 或其他 Linux 发行版，内建支持 [snap](https://snapcraft.io/docs/core/install) 包管理工具，
则可用 [snap](https://snapcraft.io/) 命令安装 kubectl。
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
<!--
If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
-->
如果你使用 Linux 系统，并且装了 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 包管理工具，
则可以使用这种方式[安装](https://docs.brew.sh/Homebrew-on-Linux#install) kubectl。
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
<!--
### Install on Linux as part of the Google Cloud SDK
-->
### 作为谷歌云 SDK 的一部分，在 Linux 上安装 {#install-on-linux-as-part-of-the-google-cloud-sdk}
{{< include "included/install-kubectl-gcloud.md" >}}
<!--
## Verify kubectl configuration
-->
## 验证 kubectl 配置 {#verify-kubectl-configration}
{{< include "included/verify-kubectl.md" >}}
## kubectl 的可选配置 {#optional-kubectl-configurations}
### 启用 shell 自动补全功能 {#enable-shell-autocompletion}
<!--
kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash and Zsh.
-->
kubectl 为 Bash 和 Zsh 提供自动补全功能，可以减轻许多输入的负担。
下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}
content/zh/docs/tasks/tools/install-kubectl-macos.md
+263
View File
@@ -0,0 +1,263 @@
---
title: 在 macOS 系统上安装和设置 kubectl
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: 在 macOS 系统上安装 kubectl
---
<!--
---
reviewers:
- mikedanese
title: Install and Set Up kubectl on macOS
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Install kubectl on macOS
---
-->
## {{% heading "prerequisites" %}}
<!--
You must use a kubectl version that is within one minor version difference of your cluster.
For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
Using the latest version of kubectl helps avoid unforeseen issues.
-->
kubectl 版本和集群之间的差异必须在一个小版本号之内。
例如：v1.2 版本的客户端只能与 v1.1、v1.2 和 v1.3 版本的集群一起工作。
用最新版本的 kubectl 有助于避免不可预见的问题。
<!--
## Install kubectl on macOS
-->
## 在 macOS 系统上安装 kubectl {#install-kubectl-on-macos}
<!--
The following methods exist for installing kubectl on macOS:
-->
在 macOS 系统上安装 kubectl 有如下方法：
- [{{% heading "prerequisites" %}}](#{{% heading "prerequisites" %}})
- [在 macOS 系统上安装 kubectl](#install-kubectl-on-macos)
- [用 curl 在 macOS 系统上安装 kubectl](#install-kubectl-binary-with-curl-on-macos)
- [用 Homebrew 在 macOS 系统上安装](#install-with-homebrew-on-macos)
- [用 Macports 在 macOS 上安装](#install-with-macports-on-macos)
- [作为谷歌云 SDK 的一部分，在 macOS 上安装](#install-on-macos-as-part-of-the-google-cloud-sdk)
- [验证 kubectl 配置](#verify-kubectl-configuration)
- [可选的 kubectl 配置](#optional-kubectl-configurations)
- [启用 shell 自动补全功能](#enable-shell-autocompletion)
- [{{% heading "whatsnext" %}}](#{{% heading "whatsnext" %}})
<!--
### Install kubectl binary with curl on macOS {#install-kubectl-binary-with-curl-on-macos}
-->
### 用 curl 在 macOS 系统上安装 kubectl {#install-kubectl-binary-with-curl-on-macos}
<!--
1. Download the latest release:
-->
1. 下载最新的发行版：
```bash
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
```
{{< note >}}
<!--
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on macOS, type:
-->
如果需要下载某个指定的版本，用该指定版本号替换掉命令的这个部分：`$(curl -L -s https://dl.k8s.io/release/stable.txt)`。
例如：要在 macOS 系统中下载 {{< param "fullversion" >}} 版本，则输入：
```bash
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
{{< /note >}}
<!--
1. Validate the binary (optional)
Download the kubectl checksum file:
-->
1. 验证可执行文件（可选操作）
下载 kubectl 的校验和文件：
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
```
<!--
Validate the kubectl binary against the checksum file:
-->
根据校验和文件，验证 kubectl：
```bash
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
```
<!--
If valid, the output is:
-->
验证通过时，输出如下：
```console
kubectl: OK
```
<!--
If the check fails, `shasum` exits with nonzero status and prints output similar to:
-->
验证失败时，`shasum` 将以非零值退出，并打印如下输出：
```
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
<!--
Download the same version of the binary and checksum.
-->
下载的 kubectl 与校验和文件版本要相同。
{{< /note >}}
<!--
1. Make the kubectl binary executable.
-->
1. 将 kubectl 置为可执行文件：
```bash
chmod +x ./kubectl
```
<!--
1. Move the kubectl binary to a file location on your system `PATH`.
-->
1. 将可执行文件 kubectl 移动到系统可寻址路径 `PATH` 内的一个位置：
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
```
<!--
1. Test to ensure the version you installed is up-to-date:
-->
1. 测试一下，确保你安装的是最新的版本：
```bash
kubectl version --client
```
<!--
### Install with Homebrew on macOS {#install-with-homebrew-on-macos}
-->
### 用 Homebrew 在 macOS 系统上安装 {#install-with-homebrew-on-macos}
<!--
If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
-->
如果你是 macOS 系统，且用的是 [Homebrew](https://brew.sh/) 包管理工具，
则可以用 Homebrew 安装 kubectl。
<!--
1. Run the installation command:
-->
1. 运行安装命令：
```bash
brew install kubectl
```
或
```bash
brew install kubernetes-cli
```
<!--
1. Test to ensure the version you installed is up-to-date:
-->
1. 测试一下，确保你安装的是最新的版本：
```bash
kubectl version --client
```
<!--
### Install with Macports on macOS {#install-with-macports-on-macos}
-->
### 用 Macports 在 macOS 上安装 {#install-with-macports-on-macos}
<!--
If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
-->
如果你用的是 macOS，且用 [Macports](https://macports.org/) 包管理工具，则你可以用 Macports 安装kubectl。
<!--
1. Run the installation command:
-->
1. 运行安装命令：
```bash
sudo port selfupdate
sudo port install kubectl
```
<!--
1. Test to ensure the version you installed is up-to-date:
-->
1. 测试一下，确保你安装的是最新的版本：
```bash
kubectl version --client
```
<!--
### Install on macOS as part of the Google Cloud SDK {#install-on-macos-as-part-of-the-google-cloud-sdk}
-->
### 作为谷歌云 SDK 的一部分，在 macOS 上安装 {#install-on-macos-as-part-of-the-google-cloud-sdk}
{{< include "included/install-kubectl-gcloud.md" >}}
<!--
## Verify kubectl configuration {#verify-kubectl-configuration}
-->
## 验证 kubectl 配置 {#verify-kubectl-configuration}
{{< include "included/verify-kubectl.md" >}}
<!--
## Optional kubectl configurations {#optional-kubectl-configurations}
### Enable shell autocompletion {#enable-shell-autocompletion}
-->
## 可选的 kubectl 配置 {#optional-kubectl-configurations}
### 启用 shell 自动补全功能 {#enable-shell-autocompletion}
<!--
kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash and Zsh.
-->
kubectl 为 Bash 和 Zsh 提供自动补全功能，这可以节省许多输入的麻烦。
下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}
content/zh/docs/tutorials/services/source-ip.md
+2 -2
View File
@@ -35,7 +35,7 @@ Kubernetes 集群中运行的应用通过 Service 抽象来互相查找、通信
你必须拥有一个正常工作的 Kubernetes 1.5 集群来运行此文档中的示例。该示例使用一个简单的 nginx webserver，通过一个HTTP消息头返回它接收到请求的源IP。你可以像下面这样创建它：
```console
kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
```
输出结果为
```
@@ -387,7 +387,7 @@ __跨平台支持__
删除服务：
```console
$ kubectl delete svc -l run=source-ip-app
$ kubectl delete svc -l app=source-ip-app
```