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
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
746a659723
commit
f21f4b2257
+20
-20
@@ -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.
|
||||
|
||||
|
||||
+1
-1
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user