Replace special quote characters with normal ones.

This commit is contained in:
TAKAHASHI Shuuji
2020-08-05 03:17:57 +09:00
parent 6b784ad586
commit c6a96128c4
42 changed files with 104 additions and 104 deletions
@@ -150,7 +150,7 @@ so that you can change the configuration more easily.
## Interact with the frontend Service
Once youve created a Service of type LoadBalancer, you can use this
Once you've created a Service of type LoadBalancer, you can use this
command to find the external IP:
```shell
@@ -191,7 +191,7 @@ affect the HTTP liveness probe.
A third type of liveness probe uses a TCP socket. With this configuration, the
kubelet will attempt to open a socket to your container on the specified port.
If it can establish a connection, the container is considered healthy, if it
cant it is considered a failure.
can't it is considered a failure.
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
@@ -284,7 +284,7 @@ Sometimes, applications are temporarily unable to serve traffic.
For example, an application might need to load large data or configuration
files during startup, or depend on external services after startup.
In such cases, you don't want to kill the application,
but you dont want to send it requests either. Kubernetes provides
but you don't want to send it requests either. Kubernetes provides
readiness probes to detect and mitigate these situations. A pod with containers
reporting that they are not ready does not receive traffic through Kubernetes
Services.
@@ -348,7 +348,7 @@ set "Host" in httpHeaders instead.
in the range 1 to 65535.
For an HTTP probe, the kubelet sends an HTTP request to the specified path and
port to perform the check. The kubelet sends the probe to the pods IP address,
port to perform the check. The kubelet sends the probe to the pod's IP address,
unless the address is overridden by the optional `host` field in `httpGet`. If
`scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
certificate verification. In most scenarios, you do not want to set the `host` field.
@@ -260,8 +260,8 @@ metadata:
```
When a Pod consumes a PersistentVolume that has a GID annotation, the annotated GID
is applied to all containers in the Pod in the same way that GIDs specified in the
Pods security context are. Every GID, whether it originates from a PersistentVolume
annotation or the Pods specification, is applied to the first process run in
Pod's security context are. Every GID, whether it originates from a PersistentVolume
annotation or the Pod's specification, is applied to the first process run in
each container.
{{< note >}}
@@ -365,7 +365,7 @@ on Linux, Chocolatey on Windows, and Homebrew on macOS. Any package
manager will be suitable if it can place new executables placed somewhere
in the user's `PATH`.
As a plugin author, if you pick this option then you also have the burden
of updating your kubectl plugins distribution package across multiple
of updating your kubectl plugin's distribution package across multiple
platforms for each release.
### Source code {#distributing-source-code}
@@ -223,7 +223,7 @@ This functionality is available in Kubernetes v1.6 and later.
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
```
* Use envFrom to define all of the Secrets data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
* Use envFrom to define all of the Secret's data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
@@ -200,30 +200,30 @@ The following information is available to containers through environment
variables and `downwardAPI` volumes:
* Information available via `fieldRef`:
* `metadata.name` - the pods name
* `metadata.namespace` - the pods namespace
* `metadata.uid` - the pods UID, available since v1.8.0-alpha.2
* `metadata.labels['<KEY>']` - the value of the pods label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
* `metadata.annotations['<KEY>']` - the value of the pods annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
* `metadata.name` - the pod's name
* `metadata.namespace` - the pod's namespace
* `metadata.uid` - the pod's UID, available since v1.8.0-alpha.2
* `metadata.labels['<KEY>']` - the value of the pod's label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
* `metadata.annotations['<KEY>']` - the value of the pod's annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
* Information available via `resourceFieldRef`:
* A Containers CPU limit
* A Containers CPU request
* A Containers memory limit
* A Containers memory request
* A Containers ephemeral-storage limit, available since v1.8.0-beta.0
* A Containers ephemeral-storage request, available since v1.8.0-beta.0
* A Container's CPU limit
* A Container's CPU request
* A Container's memory limit
* A Container's memory request
* A Container's ephemeral-storage limit, available since v1.8.0-beta.0
* A Container's ephemeral-storage request, available since v1.8.0-beta.0
In addition, the following information is available through
`downwardAPI` volume `fieldRef`:
* `metadata.labels` - all of the pods labels, formatted as `label-key="escaped-label-value"` with one label per line
* `metadata.annotations` - all of the pods annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
* `metadata.labels` - all of the pod's labels, formatted as `label-key="escaped-label-value"` with one label per line
* `metadata.annotations` - all of the pod's annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
The following information is available through environment variables:
* `status.podIP` - the pods IP address
* `spec.serviceAccountName` - the pods service account name, available since v1.4.0-alpha.3
* `spec.nodeName` - the nodes name, available since v1.4.0-alpha.3
* `status.podIP` - the pod's IP address
* `spec.serviceAccountName` - the pod's service account name, available since v1.4.0-alpha.3
* `spec.nodeName` - the node's name, available since v1.4.0-alpha.3
* `status.hostIP` - the node's IP, available since v1.7.0-alpha.1
{{< note >}}
@@ -90,7 +90,7 @@ Before using `--driver=none`, consult [this documentation](https://minikube.sigs
Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
{{< caution >}}
The `podman` driver requires running the containers as root because regular user accounts dont have full access to all operating system features that their containers might need to run.
The `podman` driver requires running the containers as root because regular user accounts don't have full access to all operating system features that their containers might need to run.
{{< /caution >}}
### Install Minikube using a package