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/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+1 -1
View File
@@ -200,7 +200,7 @@ message NUMANode {
int64 ID = 1; int64 ID = 1;
} }
``` ```
Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assingment decisions. Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assignment decisions.
`TopologyInfo` supports a `nodes` field that is either `nil` (the default) or a list of NUMA nodes. This lets the Device Plugin publish that can span NUMA nodes. `TopologyInfo` supports a `nodes` field that is either `nil` (the default) or a list of NUMA nodes. This lets the Device Plugin publish that can span NUMA nodes.
content/en/docs/concepts/services-networking/service-topology.md
+1 -1
View File
@@ -41,7 +41,7 @@ By using Node label matching between the source and destination, the operator
may designate groups of Nodes that are "closer" and "farther" from one another, may designate groups of Nodes that are "closer" and "farther" from one another,
using whatever metric makes sense for that operator's requirements. For many using whatever metric makes sense for that operator's requirements. For many
operators in public clouds, for example, there is a preference to keep service operators in public clouds, for example, there is a preference to keep service
traffic withing the same zone, because interzonal traffic has a cost associated traffic within the same zone, because interzonal traffic has a cost associated
with it, while intrazonal traffic does not. Other common needs include being able with it, while intrazonal traffic does not. Other common needs include being able
to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
Nodes connected to the same top-of-rack switch for the lowest latency. Nodes connected to the same top-of-rack switch for the lowest latency.
content/en/docs/contribute/style/content-guide.md
+1 -1
View File
@@ -73,7 +73,7 @@ Below are general categories of non-Kubernetes project content along with guidel
- Including instructions for installing Kubernetes on production environments using various projects: - Including instructions for installing Kubernetes on production environments using various projects:
- Kubernetes Rebar Integrated Bootstrap (KRIB) is a vendor-specific project and content belongs in the vendor's documentation - Kubernetes Rebar Integrated Bootstrap (KRIB) is a vendor-specific project and content belongs in the vendor's documentation
- [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) has installation instructions and tutorials in its GitHub repository - [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) has installation instructions and tutorials in its GitHub repository
- [Kubespray](https://kubespray.io) has its own documenation - [Kubespray](https://kubespray.io) has its own documentation
- Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations - Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
- Adding a tutorial on how to use a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations if the project has its own documentation - Adding a tutorial on how to use a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations if the project has its own documentation
1. Detailed technical content about how to use a non-Kubernetes project or how that project is designed 1. Detailed technical content about how to use a non-Kubernetes project or how that project is designed
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+1 -1
View File
@@ -1134,7 +1134,7 @@ webhooks:
Webhooks typically operate only on the content of the `AdmissionReview` sent to them. Webhooks typically operate only on the content of the `AdmissionReview` sent to them.
Some webhooks, however, make out-of-band changes as part of processing admission requests. Some webhooks, however, make out-of-band changes as part of processing admission requests.
Webhooks that make out-of-band changes ("side effects") must also have a reconcilation mechanism Webhooks that make out-of-band changes ("side effects") must also have a reconciliation mechanism
(like a controller) that periodically determines the actual state of the world, and adjusts (like a controller) that periodically determines the actual state of the world, and adjusts
the out-of-band data modified by the admission webhook to reflect reality. the out-of-band data modified by the admission webhook to reflect reality.
This is because a call to an admission webhook does not guarantee the admitted object will be persisted as is, or at all. This is because a call to an admission webhook does not guarantee the admitted object will be persisted as is, or at all.
content/en/docs/reference/glossary/proxy.md
+1 -1
View File
@@ -3,7 +3,7 @@ title: Proxy
id: proxy id: proxy
date: 2019-09-10 date: 2019-09-10
short_description: > short_description: >
An application acting as an intermediary beween clients and servers An application acting as an intermediary between clients and servers
aka: aka:
tags: tags:
content/en/docs/reference/using-api/api-concepts.md
+4 -4
View File
@@ -394,7 +394,7 @@ manager to the manager making the change. When trying to apply an object, fields
that have a different value and are owned by another manager will result in a that have a different value and are owned by another manager will result in a
[conflict](#conflicts). This is done in order to signal that the operation might undo another [conflict](#conflicts). This is done in order to signal that the operation might undo another
collaborator's changes. Conflicts can be forced, in which case the value will be collaborator's changes. Conflicts can be forced, in which case the value will be
overriden, and the ownership will be transfered. overridden, and the ownership will be transferred.
It is meant both as a replacement for the original `kubectl apply` and as a It is meant both as a replacement for the original `kubectl apply` and as a
simpler mechanism to write controllers. simpler mechanism to write controllers.
@@ -682,7 +682,7 @@ For get and list, the semantics of resource version are:
The meaning of the get and list semantics are: The meaning of the get and list semantics are:
- **Most Recent:** Return data at the most recent resource version. The returned data must be consistent (i.e. served from etcd via a quorum read). - **Most Recent:** Return data at the most recent resource version. The returned data must be consistent (i.e. served from etcd via a quorum read).
- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic. - **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availability configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic.
- **Not older than:** Return data at least as new as the provided resource version. The newest available resource version is preferred, but any data not older than this resource version may be served. - **Not older than:** Return data at least as new as the provided resource version. The newest available resource version is preferred, but any data not older than this resource version may be served.
- **Exact:** Return data at the exact resource version provided. - **Exact:** Return data at the exact resource version provided.
@@ -696,8 +696,8 @@ For watch, the semantics of resource version are:
The meaning of the watch semantics are: The meaning of the watch semantics are:
- **Get State and Start at Most Recent:** Start a watch at the most recent resource version, which must be consistent (i.e. served from etcd via a quorum read). To establish initial state, the watch begins with synthetic “Added” events of all resources instances that exist at the starting resource version. All following watch events are for all changes that occured after the resource version the watch started at. - **Get State and Start at Most Recent:** Start a watch at the most recent resource version, which must be consistent (i.e. served from etcd via a quorum read). To establish initial state, the watch begins with synthetic “Added” events of all resources instances that exist at the starting resource version. All following watch events are for all changes that occurred after the resource version the watch started at.
- **Get State and Start at Any:** Warning: Watches initialize this way may return arbitrarily stale data! Please review this semantic before using it, and favor the other semantics where possible. Start a watch at any resource version, the most recent resource version available is preferred, but not required; any starting resource version is allowed. It is possible for the watch to start at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not start a watch with this semantic. To establish initial state, the watch begins with synthetic “Added” events for all resources instances that exist at the starting resource version. All following watch events are for all changes that occured after the resource version the watch started at. - **Get State and Start at Any:** Warning: Watches initialize this way may return arbitrarily stale data! Please review this semantic before using it, and favor the other semantics where possible. Start a watch at any resource version, the most recent resource version available is preferred, but not required; any starting resource version is allowed. It is possible for the watch to start at a much older resource version that the client has previously observed, particularly in high availability configurations, due to partitions or stale caches. Clients that cannot tolerate this should not start a watch with this semantic. To establish initial state, the watch begins with synthetic “Added” events for all resources instances that exist at the starting resource version. All following watch events are for all changes that occurred after the resource version the watch started at.
- **Start at Exact:** Start a watch at an exact resource version. The watch events are for all changes after the provided resource version. Unlike "Get State and Start at Most Recent" and "Get State and Start at Any", the watch is not started with synthetic "Added" events for the provided resource version. The client is assumed to already have the initial state at the starting resource version since the client provided the resource version. - **Start at Exact:** Start a watch at an exact resource version. The watch events are for all changes after the provided resource version. Unlike "Get State and Start at Most Recent" and "Get State and Start at Any", the watch is not started with synthetic "Added" events for the provided resource version. The client is assumed to already have the initial state at the starting resource version since the client provided the resource version.
### "410 Gone" responses ### "410 Gone" responses
content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+1 -1
View File
@@ -541,7 +541,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
1. What is a `pause` container? 1. What is a `pause` container?
In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accomodate worker containers crashing or restarting without losing any of the networking configuration. In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration.
The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat). The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat).
content/en/docs/setup/release/notes.md
+1 -1
View File
@@ -137,7 +137,7 @@ The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migra
- Add `scheduler_goroutines` metric to track number of kube-scheduler binding and prioritizing goroutines ([#83535](https://github.com/kubernetes/kubernetes/pull/83535), [@wgliang](https://github.com/wgliang)) - Add `scheduler_goroutines` metric to track number of kube-scheduler binding and prioritizing goroutines ([#83535](https://github.com/kubernetes/kubernetes/pull/83535), [@wgliang](https://github.com/wgliang))
- Adding initial EndpointSlice metrics. ([#83257](https://github.com/kubernetes/kubernetes/pull/83257), [@robscott](https://github.com/robscott)) - Adding initial EndpointSlice metrics. ([#83257](https://github.com/kubernetes/kubernetes/pull/83257), [@robscott](https://github.com/robscott))
- Adds a metric `apiserver_request_error_total` to kube-apiserver. This metric tallies the number of `request_errors` encountered by verb, group, version, resource, subresource, scope, component, and code. ([#83427](https://github.com/kubernetes/kubernetes/pull/83427), [@logicalhan](https://github.com/logicalhan)) - Adds a metric `apiserver_request_error_total` to kube-apiserver. This metric tallies the number of `request_errors` encountered by verb, group, version, resource, subresource, scope, component, and code. ([#83427](https://github.com/kubernetes/kubernetes/pull/83427), [@logicalhan](https://github.com/logicalhan))
- A new `kubelet_preemptions` metric is reported from Kubelets to track the number of preemptions occuring over time, and which resource is triggering those preemptions. ([#84120](https://github.com/kubernetes/kubernetes/pull/84120), [@smarterclayton](https://github.com/smarterclayton)) - A new `kubelet_preemptions` metric is reported from Kubelets to track the number of preemptions occurring over time, and which resource is triggering those preemptions. ([#84120](https://github.com/kubernetes/kubernetes/pull/84120), [@smarterclayton](https://github.com/smarterclayton))
- Kube-apiserver: Added metrics `authentication_latency_seconds` that can be used to understand the latency of authentication. ([#82409](https://github.com/kubernetes/kubernetes/pull/82409), [@RainbowMango](https://github.com/RainbowMango)) - Kube-apiserver: Added metrics `authentication_latency_seconds` that can be used to understand the latency of authentication. ([#82409](https://github.com/kubernetes/kubernetes/pull/82409), [@RainbowMango](https://github.com/RainbowMango))
- Add `plugin_execution_duration_seconds` metric for scheduler framework plugins. ([#84522](https://github.com/kubernetes/kubernetes/pull/84522), [@liu-cong](https://github.com/liu-cong)) - Add `plugin_execution_duration_seconds` metric for scheduler framework plugins. ([#84522](https://github.com/kubernetes/kubernetes/pull/84522), [@liu-cong](https://github.com/liu-cong))
- Add `permit_wait_duration_seconds` metric to the scheduler. ([#84011](https://github.com/kubernetes/kubernetes/pull/84011), [@liu-cong](https://github.com/liu-cong)) - Add `permit_wait_duration_seconds` metric to the scheduler. ([#84011](https://github.com/kubernetes/kubernetes/pull/84011), [@liu-cong](https://github.com/liu-cong))
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+1 -1
View File
@@ -879,7 +879,7 @@ With the OpenAPI v2 Publishing feature enabled, CustomResourceDefinition [OpenAP
The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and
show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions). show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions).
The following modifications are applied during the conversion to keep backwards compatiblity with The following modifications are applied during the conversion to keep backwards compatibility with
kubectl in previous 1.13 version. These modifications prevent kubectl from being over-strict and rejecting kubectl in previous 1.13 version. These modifications prevent kubectl from being over-strict and rejecting
valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD, valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD,
and therefore won't affect [validation](#validation) in the API server. and therefore won't affect [validation](#validation) in the API server.
content/en/docs/tasks/administer-cluster/access-cluster-api.md
+1 -1
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: # Select name of cluster you want to interact with from above output:
export CLUSTER_NAME="some_server_name" 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}") APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
# Gets the token value # Gets the token value
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 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 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 `--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 `--reserved-cpus` takes precedence over the CPU reservation specified by
`--kube-reserved` and `--system-reserved`. CPUs reserved by these options are taken, in `--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 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. 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. - 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 Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified. 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" >}} {{< feature-state for_k8s_version="v1.17" state="stable" >}}
- **Kubelet Flag**: `--reserved-cpus=0-3` - **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` 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. 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`, 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 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 This option is specifically designed for Telco/NFV use cases where uncontrolled
interrupts/timers may impact the workload performance. you can use this option 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 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 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. defined by this option, other mechanism outside Kubernetes should be used.
For example: in Centos, you can do this using the tuned toolset. For example: in Centos, you can do this using the tuned toolset.
content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+1 -1
View File
@@ -11,7 +11,7 @@ This page shows you how to configure a Pod to use a
for storage. for storage.
Here is a summary of the process: Here is a summary of the process:
1. You, as cluster adminstrator, create a PersistentVolume backed by physical 1. You, as cluster administrator, create a PersistentVolume backed by physical
storage. You do not associate the volume with any Pod. storage. You do not associate the volume with any Pod.
1. You, now taking the role of a developer / cluster user, create a 1. You, now taking the role of a developer / cluster user, create a