Reimplement edits (#4249)
* Reimplement PR #3920 * Reimplement PR #3976 * Reimplement PR #4055 and #4128 * Reimplement PR #4146 * Reimplemented PR #4163
This commit is contained in:
@@ -69,7 +69,7 @@ This is a living document. If you think of something that is not on this list bu
|
||||
|
||||
Note that the [Deployment](/docs/concepts/workloads/controllers/deployment/) object obviates the need to manage replication controller 'version names'. A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. (Deployment objects are currently part of the [`extensions` API Group](/docs/concepts/overview/kubernetes-api/#api-groups).)
|
||||
|
||||
- You can manipulate labels for debugging. Because Kubernetes replication controllers and services match to pods using labels, this allows you to remove a pod from being considereby a controller, or served traffic by a service, by removing the relevant selectolabels. If you remove the labels of an existing pod, its controller will create a new pod to takits place. This is a useful way to debug a previously "live" pod in a quarantine environmentSee the [`kubectl label`](/docs/concepts/overview/working-with-objects/labels/) command.
|
||||
- You can manipulate labels for debugging. Because Kubernetes replication controllers and services match to pods using labels, this allows you to remove a pod from being considered by a controller, or served traffic by a service, by removing the relevant selector labels. If you remove the labels of an existing pod, its controller will create a new pod to take its place. This is a useful way to debug a previously "live" pod in a quarantine environment. See the [`kubectl label`](/docs/concepts/overview/working-with-objects/labels/) command.
|
||||
|
||||
## Container Images
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ redirect_from:
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows you how to configure an application using a ConfigMap.
|
||||
This page shows you how to configure an application using a ConfigMap. ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -120,7 +120,7 @@ would produce the following ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl describe configmaps game-config-2
|
||||
Name: game-config
|
||||
Name: game-config-2
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
@@ -138,7 +138,7 @@ kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kub
|
||||
|
||||
```shell
|
||||
kubectl describe configmaps game-config-2
|
||||
Name: game-config
|
||||
Name: game-config-2
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
@@ -54,9 +54,9 @@ the Pod:
|
||||
|
||||
kubectl exec -it test-projected-volume -- /bin/sh
|
||||
|
||||
1. In your shell, verify that the `projected-volumes` directory contains your projected sources:
|
||||
1. In your shell, verify that the `projected-volume` directory contains your projected sources:
|
||||
|
||||
/ # ls projected-volumes/
|
||||
/ # ls /projected-volume/
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
@@ -22,8 +22,8 @@ This document makes use of the following terms:
|
||||
* [NAT](https://en.wikipedia.org/wiki/Network_address_translation): network address translation
|
||||
* [Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): replacing the source IP on a packet, usually with a node's IP
|
||||
* [Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): replacing the destination IP on a packet, usually with a pod IP
|
||||
* [VIP](/docs/user-guide/services/#ips-and-vips): a virtual IP, such as the one assigned to every Kubernetes Service
|
||||
* [Kube-proxy](/docs/user-guide/services/#virtual-ips-and-service-proxies): a network daemon that orchestrates Service VIP management on every node
|
||||
* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): a virtual IP, such as the one assigned to every Kubernetes Service
|
||||
* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): a network daemon that orchestrates Service VIP management on every node
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Reference in New Issue
Block a user