Skip to content
Permalink
Browse files

Fix en language misspell (#18201)

* fix misspell

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

* clean white noise

Signed-off-by: Xiang Dai <764524258@qq.com>
  • Loading branch information
daixiang0 authored and k8s-ci-robot committed Dec 20, 2019
1 parent 746a659 commit f21f4b2257a9e0f29a719bf6e12863eb80aaebb9
@@ -188,7 +188,7 @@ Support for the "PodResources service" requires `KubeletPodResources` [feature g

{{< feature-state for_k8s_version="v1.17" state="alpha" >}}

The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.


```gRPC
@@ -200,7 +200,7 @@ message NUMANode {
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.

@@ -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,
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
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
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.
@@ -21,33 +21,33 @@ docs, follow the instructions in the [Style guide](/docs/contribute/style/style-
{{% capture body %}}
## Contributing content

The Kubernetes documentation comprises the content of the
[kubernetes/website](https://github.com/kubernetes/website) source repository.
Located in the `kubernetes/website/content/<language_code>/docs` folder, the
majority of the Kubernetes documentation is specific to the [Kubernetes
project](https://github.com/kubernetes/kubernetes). The Kubernetes
documentation may also include content from projects in the
[kubernetes](https://github.com/kubernetes) and
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if
those projects do not have their own documentation. Linking to active kubernetes,
kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always
allowed, but linking to vendor-specific products is not. Check the CNCF project lists
([Graduated/Incubating](https://www.cncf.io/projects/),
[Sandbox](https://www.cncf.io/sandbox-projects/),
[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a
project's CNCF status.
The Kubernetes documentation comprises the content of the
[kubernetes/website](https://github.com/kubernetes/website) source repository.
Located in the `kubernetes/website/content/<language_code>/docs` folder, the
majority of the Kubernetes documentation is specific to the [Kubernetes
project](https://github.com/kubernetes/kubernetes). The Kubernetes
documentation may also include content from projects in the
[kubernetes](https://github.com/kubernetes) and
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if
those projects do not have their own documentation. Linking to active kubernetes,
kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always
allowed, but linking to vendor-specific products is not. Check the CNCF project lists
([Graduated/Incubating](https://www.cncf.io/projects/),
[Sandbox](https://www.cncf.io/sandbox-projects/),
[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a
project's CNCF status.

### Dual-sourced content

Kubernetes documentation does not include duplicate content sourced from multiple
locations (*dual-sourced* content). Dual-sourced content requires duplicated
effort from project maintainers and tends to become outdated more quickly.
Kubernetes documentation does not include duplicate content sourced from multiple
locations (*dual-sourced* content). Dual-sourced content requires duplicated
effort from project maintainers and tends to become outdated more quickly.
Before adding content, ask yourself this:

- Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations?
- If yes, then:
- Does the project have its own documentation?
- if yes, link to the project's documention from the Kubernetes documentation
- if yes, link to the project's documention from the Kubernetes documentation
- if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation
- If no, then:
- Stop!
@@ -56,59 +56,59 @@ Before adding content, ask yourself this:

### What is and isn't allowed

There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects.
There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects.
Below are general categories of non-Kubernetes project content along with guidelines of what is and is not allowed:

1. Instructional content involving non-Kubernetes projects during setup or operation of Kubernetes
- Allowed:
- Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations
- Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation
- Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content
- Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
- Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
- Not Allowed:
- Adding content that duplicates documentation in another repository
- Examples:
- Examples:
- Including minikube installation and configuration instructions; minikube has its own [documentation](https://minikube.sigs.k8s.io/docs/) that provides those instructions
- Including instructions for installing Docker, CRI-O, containerd, and other container runtimes on various operating systems
- 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 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 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

Adding this type of content to the Kubernetes documentation is not allowed.
Adding this type of content to the Kubernetes documentation is not allowed.
1. Content that describes a non-Kubernetes project
- Allowed:
- Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project
- Not Allowed:
- Allowed:
- Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project
- Not Allowed:
- Adding content describing a vendor-specific product
- Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
- Adding content that duplicates documentation from another project, regardless of source repository
- Example: adding [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) documentation to the Kubernetes documentation
1. Content that simply links to information about a non-Kubernetes project
- Allowed:
- Allowed:
- Linking to projects in the kubernetes and kubernetes-sigs GitHub organizations
- Example: linking to Kubernetes in Docker (KinD) [documentation](https://kind.sigs.k8s.io/docs/user/quick-start), which resides in the kubernetes-sigs GitHub organization
- Linking to active CNCF projects
- Example: linking to the Prometheus [documentation](https://prometheus.io/docs/introduction/overview/); Prometheus is an active CNCF project
- Not Allowed:
- Not Allowed:
- Linking to vendor-specific products
- Linking to archived CNCF projects
- Linking to inactive projects in the kubernetes and kubernetes-sigs GitHub organizations
- Linking to open source projects that are not CNCF projects or do not reside in the kubernetes or kubernetes-sigs GitHub organizations
1. Content about training courses
- Allowed:
- Allowed:
- Linking to vendor-neutral Kubernetes training courses offered by the [CNCF](https://www.cncf.io/), the [Linux Foundation](https://www.linuxfoundation.org/), and the [Linux Academy](https://linuxacademy.com/), which is a partner of the Linux Foundation
- Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
- Not Allowed:
- Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content
- Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
- Not Allowed:
- Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content
- Example: linking to Kubernetes tutorials or courses on Medium, KodeKloud, Udacity, Coursera, learnk8s, and similar websites
- Linking to vendor-specific tutorials regardless of the training provider
- Example: linking to Linux Academy courses such as [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)

If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
{{% /capture %}}

{{% capture whatsnext %}}
@@ -1134,7 +1134,7 @@ webhooks:
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.

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
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.
@@ -3,7 +3,7 @@ title: Proxy
id: proxy
date: 2019-09-10
short_description: >
An application acting as an intermediary beween clients and servers
An application acting as an intermediary between clients and servers
aka:
tags:
@@ -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
[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
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
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:

- **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.
- **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:

- **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 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 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 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.

### "410 Gone" responses

0 comments on commit f21f4b2

Please sign in to comment.
You can’t perform that action at this time.