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

Fix en language misspell (#18201)

Browse Source 
* fix misspell

Signed-off-by: Xiang Dai <764524258@qq.com>

* clean white noise

Signed-off-by: Xiang Dai <764524258@qq.com>
This commit is contained in:
Xiang Dai
2019-12-20 22:49:32 +08:00
committed by Kubernetes Prow Robot
parent 746a659723
commit f21f4b2257
14 changed files with 80 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/access-cluster-api.md
+3 -3
View File
@@ -94,7 +94,7 @@ kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{
# Select name of cluster you want to interact with from above output:
export CLUSTER_NAME="some_server_name"
# Point to the API server refering the cluster name
# Point to the API server referring the cluster name
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
# Gets the token value
@@ -215,7 +215,7 @@ for i in ret.items:
#### Java client
* To install the [Java Client](https://github.com/kubernetes-client/java), simply execute :
* To install the [Java Client](https://github.com/kubernetes-client/java), simply execute :
```shell
# Clone java library
@@ -382,7 +382,7 @@ securely with the API server.
#### Directly accessing the REST API
While running in a Pod, the Kubernetes apiserver is accessible via a Service named
`kubernetes` in the `default` namespace. Therefore, Pods can use the
`kubernetes` in the `default` namespace. Therefore, Pods can use the
`kubernetes.default.svc` hostname to query the API server. Official client libraries
do this automatically.
content/en/docs/tasks/administer-cluster/cpu-management-policies.md
+1 -1
View File
@@ -86,7 +86,7 @@ This policy manages a shared pool of CPUs that initially contains all CPUs in th
node. The amount of exclusively allocatable CPUs is equal to the total
number of CPUs in the node minus any CPU reservations by the kubelet `--kube-reserved` or
`--system-reserved` options. From 1.17, the CPU reservation list can be specified
explictly by kubelet `--reserved-cpus` option. The explicit CPU list specified by
explicitly by kubelet `--reserved-cpus` option. The explicit CPU list specified by
`--reserved-cpus` takes precedence over the CPU reservation specified by
`--kube-reserved` and `--system-reserved`. CPUs reserved by these options are taken, in
integer quantity, from the initial shared pool in ascending order by physical
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+1 -1
View File
@@ -105,7 +105,7 @@ If you are running an HA cluster, this command needs to be executed on all the c
The Kubernetes certificates normally reach their expiration date after one year.
- `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
- `--csr-only` can be used to renew certificates with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
- It's also possible to renew a single certificate instead of all.
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+5 -5
View File
@@ -146,14 +146,14 @@ control group (`system.slice` on systemd machines for example).
Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified.
### Explictly Reserved CPU List
### Explicitly Reserved CPU List
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
- **Kubelet Flag**: `--reserved-cpus=0-3`
`reserved-cpus` is meant to define an explict CPU set for OS system daemons and
`reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
kubernetes system daemons. This option is added in 1.17 release. `reserved-cpus`
is for systems that do not intent to define seperate top level cgroups for
is for systems that do not intent to define separate top level cgroups for
OS system daemons and kubernetes system daemons with regard to cpuset resource.
If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved-cgroup`,
the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
@@ -161,10 +161,10 @@ defined by `--kube-reserved` and `--system-reserved` options.
This option is specifically designed for Telco/NFV use cases where uncontrolled
interrupts/timers may impact the workload performance. you can use this option
to define the explict cpuset for the system/kubernetes daemons as well as the
to define the explicit cpuset for the system/kubernetes daemons as well as the
interrupts/timers, so the rest CPUs on the system can be used exclusively for
workloads, with less impact from uncontrolled interrupts/timers. To move the
system daemon, kubernetes daemons and interrupts/timers to the explict cpuset
system daemon, kubernetes daemons and interrupts/timers to the explicit cpuset
defined by this option, other mechanism outside Kubernetes should be used.
For example: in Centos, you can do this using the tuned toolset.