correct capitalization across docs (#9327)
parent
94e3d092d1
commit
e0dd309c4e
|
@ -82,7 +82,7 @@ When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands
|
|||
the basic logging example, the kubelet on the node handles the request and
|
||||
reads directly from the log file, returning the contents in the response.
|
||||
|
||||
**Note:** currently, if some external system has performed the rotation,
|
||||
**Note:** Currently, if some external system has performed the rotation,
|
||||
only the contents of the latest log file will be available through
|
||||
`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
|
||||
the rotation and there are two files, one 10MB in size and one empty,
|
||||
|
|
|
@ -482,7 +482,7 @@ Create a secret containing some ssh keys:
|
|||
$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
**Security Note:** Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
|
||||
|
||||
Now we can create a pod which references the secret with the ssh key and
|
||||
|
|
|
@ -130,12 +130,12 @@ Once you have those variables filled in you can
|
|||
|
||||
### Configuring Nodes to Authenticate to a Private Repository
|
||||
|
||||
**Note:** if you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
|
||||
**Note:** if you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
|
||||
**Note:** If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
|
||||
manage and update the ECR login credentials. You cannot use this approach.
|
||||
|
||||
**Note:** this approach is suitable if you can control node configuration. It
|
||||
**Note:** This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
|
||||
|
@ -197,9 +197,9 @@ registry keys are added to the `.docker/config.json`.
|
|||
|
||||
### Pre-pulling Images
|
||||
|
||||
**Note:** if you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
|
||||
**Note:** this approach is suitable if you can control node configuration. It
|
||||
**Note:** This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
|
||||
|
|
|
@ -246,7 +246,7 @@ or different paths in each Container. When a Pod is removed from a node for
|
|||
any reason, the data in the `emptyDir` is deleted forever.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** a Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
|
||||
**Note:** A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
|
||||
{{< /note >}}
|
||||
|
||||
Some uses for an `emptyDir` are:
|
||||
|
|
|
@ -128,7 +128,7 @@ There are three main types of jobs:
|
|||
1. Parallel Jobs with a *fixed completion count*:
|
||||
- specify a non-zero positive value for `.spec.completions`.
|
||||
- the job is complete when there is one successful pod for each value in the range 1 to `.spec.completions`.
|
||||
- **not implemented yet:** each pod passed a different index in the range 1 to `.spec.completions`.
|
||||
- **not implemented yet:** Each pod passed a different index in the range 1 to `.spec.completions`.
|
||||
1. Parallel Jobs with a *work queue*:
|
||||
- do not specify `.spec.completions`, default to `.spec.parallelism`.
|
||||
- the pods must coordinate with themselves or an external service to determine what each should work on.
|
||||
|
|
|
@ -90,7 +90,7 @@ a deployed cluster. The following example will skip the `Flaky`, `Slow`, and
|
|||
juju run-action kubernetes-e2e/0 test skip='\[(Flaky|Slow|Feature:.*)\]'
|
||||
|
||||
{{< note >}}
|
||||
**Note:** the escaping of the regex due to how bash handles brackets.
|
||||
**Note:** The escaping of the regex due to how bash handles brackets.
|
||||
{{< /note >}}
|
||||
|
||||
To see the different types of tests the Kubernetes end-to-end charm has access
|
||||
|
|
|
@ -289,7 +289,7 @@ Because your cluster has both Linux and Windows nodes, you must explicitly set t
|
|||
}
|
||||
}
|
||||
```
|
||||
**Note:** this example assumes you are running on Windows Server 1709, so uses the image tag to support that. If you are on a different version, you will need to update the tag. For example, if on Windows Server 2016, update to use `"image": "microsoft/iis"` which will default to that OS version.
|
||||
**Note:** This example assumes you are running on Windows Server 1709, so uses the image tag to support that. If you are on a different version, you will need to update the tag. For example, if on Windows Server 2016, update to use `"image": "microsoft/iis"` which will default to that OS version.
|
||||
|
||||
### Secrets and ConfigMaps
|
||||
Secrets and ConfigMaps can be utilized in Windows Server Containers, but must be used as environment variables. See limitations section below for additional details.
|
||||
|
|
|
@ -452,7 +452,7 @@ flag to `kubeadm init`.
|
|||
{{< /caution >}}
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** see self-hosted caveats and limitations.
|
||||
**Warning:** See self-hosted caveats and limitations.
|
||||
{{< /warning >}}
|
||||
|
||||
#### Caveats
|
||||
|
|
|
@ -39,7 +39,7 @@ The version is set at the API level rather than at the resource or field level t
|
|||
The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** the API versioning and software versioning are indirectly related. The [API and release
|
||||
**Note:** The API versioning and software versioning are indirectly related. The [API and release
|
||||
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ This article describes a solution that exports Kubernetes events to
|
|||
Stackdriver Logging, where they can be processed and analyzed.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** it is not guaranteed that all events happening in a cluster will be
|
||||
**Note:** It is not guaranteed that all events happening in a cluster will be
|
||||
exported to Stackdriver. One possible scenario when events will not be
|
||||
exported is when event exporter is not running (e.g. during restart or
|
||||
upgrade). In most cases it's fine to use events for purposes like setting up
|
||||
|
|
|
@ -325,7 +325,7 @@ kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-
|
|||
```
|
||||
|
||||
Then in the value for the key `containers.input.conf` insert a new filter right after
|
||||
the `source` section. **Note:** order is important.
|
||||
the `source` section. **Note:** Order is important.
|
||||
|
||||
Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
|
||||
to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
|
||||
|
@ -347,4 +347,4 @@ with minor changes:
|
|||
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
|
||||
new image, you can use the plugin you installed in the fluentd configuration.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
|
|
|
@ -284,7 +284,7 @@ web-1
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** if you instead see 403 Forbidden responses for the above curl command,
|
||||
**Note:** If you instead see 403 Forbidden responses for the above curl command,
|
||||
you will need to fix the permissions of the directory mounted by the `volumeMounts`
|
||||
(due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)) with:
|
||||
|
||||
|
|
Loading…
Reference in New Issue