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>
This commit is contained in:
Xiang Dai
Kubernetes Prow Robot
parent
746a659723
commit
f21f4b2257
|
|
@ -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,7 +56,7 @@ 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
|
||||
|
|
@ -64,51 +64,51 @@ Below are general categories of non-Kubernetes project content along with guidel
|
|||
- 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
|
||||
|
|
|
|||
|
|
@ -531,8 +531,8 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
|
|||
This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones.
|
||||
If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)
|
||||
|
||||
1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
|
||||
|
||||
1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
|
||||
|
||||
If you are behind a proxy, the following PowerShell environment variables must be defined:
|
||||
```PowerShell
|
||||
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
|
||||
|
|
@ -540,9 +540,9 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
|
|||
```
|
||||
|
||||
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).
|
||||
|
||||
### Further investigation
|
||||
|
|
|
|||
|
|
@ -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))
|
||||
- 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))
|
||||
- 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))
|
||||
- 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))
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ spec:
|
|||
kind: CronTab
|
||||
# shortNames allow shorter string to match your resource on the CLI
|
||||
shortNames:
|
||||
- ct
|
||||
- ct
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
|
||||
|
|
@ -256,10 +256,10 @@ A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/access-ku
|
|||
* a node with `x-kubernetes-preserve-unknown-fields: true`
|
||||
2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2).
|
||||
3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below).
|
||||
4. if `metadata` is specified, then only restrictions on `metadata.name` and `metadata.generateName` are allowed.
|
||||
4. if `metadata` is specified, then only restrictions on `metadata.name` and `metadata.generateName` are allowed.
|
||||
|
||||
|
||||
Non-Structural Example 1:
|
||||
Non-Structural Example 1:
|
||||
```yaml
|
||||
allOf:
|
||||
- properties:
|
||||
|
|
@ -296,7 +296,7 @@ allOf:
|
|||
properties:
|
||||
foo:
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
Non-Structural Example 3:
|
||||
```yaml
|
||||
|
|
@ -326,10 +326,10 @@ is not a structural schema because of the following violations:
|
|||
|
||||
* the type at the root is missing (rule 1).
|
||||
* the type of `foo` is missing (rule 1).
|
||||
* `bar` inside of `anyOf` is not specified outside (rule 2).
|
||||
* `bar` inside of `anyOf` is not specified outside (rule 2).
|
||||
* `bar`'s `type` is within `anyOf` (rule 3).
|
||||
* the description is set within `anyOf` (rule 3).
|
||||
* `metadata.finalizer` might not be restricted (rule 4).
|
||||
* `metadata.finalizer` might not be restricted (rule 4).
|
||||
|
||||
In contrast, the following, corresponding schema is structural:
|
||||
```yaml
|
||||
|
|
@ -371,14 +371,14 @@ CustomResourceDefinitions traditionally store any (possibly validated) JSON as i
|
|||
{{< tabs name="CustomResourceDefinition_pruning" >}}
|
||||
{{% tab name="apiextensions.k8s.io/v1" %}}
|
||||
|
||||
For CustomResourceDefinitions created in `apiextensions.k8s.io/v1`, [structural OpenAPI v3 validation schemas](#specifying-a-structural-schema) are required and pruning is enabled and cannot be disabled (note that CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`).
|
||||
For CustomResourceDefinitions created in `apiextensions.k8s.io/v1`, [structural OpenAPI v3 validation schemas](#specifying-a-structural-schema) are required and pruning is enabled and cannot be disabled (note that CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`).
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
|
||||
|
||||
For CustomResourceDefinitions created in `apiextensions.k8s.io/v1beta1`, if a [structural OpenAPI v3 validation schema](#specifying-a-structural-schema) is defined (either in the global `spec.validation.openAPIV3Schema` in `apiextensions.k8s.io/v1beta1` or for each version) in a CustomResourceDefinition, pruning can be enabled by setting `spec.preserveUnknownFields` to `false`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
If pruning is enabled, unspecified fields in CustomResources on creation and on update are dropped.
|
||||
|
|
@ -501,8 +501,8 @@ type: object
|
|||
properties:
|
||||
foo:
|
||||
x-kubernetes-int-or-string: true
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Also those nodes are partially excluded from rule 3 in the sense that the following two patterns are allowed (exactly those, without variations in order to additional fields):
|
||||
|
||||
```yaml
|
||||
|
|
@ -511,7 +511,7 @@ anyOf:
|
|||
- type: integer
|
||||
- type: string
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
and
|
||||
|
||||
|
|
@ -523,7 +523,7 @@ allOf:
|
|||
- type: string
|
||||
- ... # zero or more
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
With one of those specification, both an integer and a string validate.
|
||||
|
||||
|
|
@ -615,10 +615,10 @@ Additionally, the following restrictions are applied to the schema:
|
|||
- `definitions`,
|
||||
- `dependencies`,
|
||||
- `deprecated`,
|
||||
- `discriminator`,
|
||||
- `discriminator`,
|
||||
- `id`,
|
||||
- `patternProperties`,
|
||||
- `readOnly`,
|
||||
- `readOnly`,
|
||||
- `writeOnly`,
|
||||
- `xml`,
|
||||
- `$ref`.
|
||||
|
|
@ -667,7 +667,7 @@ spec:
|
|||
replicas:
|
||||
type: integer
|
||||
minimum: 1
|
||||
maximum: 10
|
||||
maximum: 10
|
||||
scope: Namespaced
|
||||
names:
|
||||
plural: crontabs
|
||||
|
|
@ -818,14 +818,14 @@ spec:
|
|||
type: integer
|
||||
minimum: 1
|
||||
maximum: 10
|
||||
default: 1
|
||||
default: 1
|
||||
scope: Namespaced
|
||||
names:
|
||||
plural: crontabs
|
||||
singular: crontab
|
||||
kind: CronTab
|
||||
shortNames:
|
||||
- ct
|
||||
- ct
|
||||
```
|
||||
|
||||
With this both `cronSpec` and `replicas` are defaulted:
|
||||
|
|
@ -853,7 +853,7 @@ spec:
|
|||
```
|
||||
|
||||
Note that defaulting happens on the object
|
||||
|
||||
|
||||
* in the request to the API server using the request version defaults,
|
||||
* when reading from etcd using the storage version defaults,
|
||||
* after mutating admission plugins with non-empty patches using the admission webhook object version defaults.
|
||||
|
|
@ -875,11 +875,11 @@ OpenAPI v2 Publishing is available as beta since 1.15, and as alpha since 1.14.
|
|||
|
||||
With the OpenAPI v2 Publishing feature enabled, CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#preserving-unknown-fields) (opt-in in v1beta1, enabled by default in v1) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server.
|
||||
|
||||
[kubectl](/docs/reference/kubectl/overview) consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
|
||||
[kubectl](/docs/reference/kubectl/overview) consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
|
||||
|
||||
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).
|
||||
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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This page shows you how to configure a Pod to use a
|
|||
for storage.
|
||||
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.
|
||||
|
||||
1. You, now taking the role of a developer / cluster user, create a
|
||||
|
|
|
|||
Loading…
Reference in New Issue