Merge pull request #22981 from shuuji3/en/replace-special-quote-with-normal-ones

Replace special quote characters with normal ones

content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md

@@ -150,7 +150,7 @@ so that you can change the configuration more easily.
 
 ## Interact with the frontend Service
 
-Once you’ve 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

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -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
-can’t 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 don’t 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 pod’s 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.

content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

@@ -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
-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
+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 >}}

content/en/docs/tasks/extend-kubectl/kubectl-plugins.md

@@ -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 plugin’s distribution package across multiple
+of updating your kubectl plugin's distribution package across multiple
 platforms for each release.
 
 ### Source code {#distributing-source-code}

content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md

@@ -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 Secret’s 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" >}}
 

content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md

@@ -200,30 +200,30 @@ The following information is available to containers through environment
 variables and `downwardAPI` volumes:
 
 * Information available via `fieldRef`:
-  * `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+
+  * `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 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
+  * 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 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
+* `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 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.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 >}}

content/en/docs/tasks/tools/install-minikube.md

@@ -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 don’t 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