fix mungedoc links

This commit is contained in:
Mike Danese
2015-07-13 10:32:55 -07:00
parent 430eabe5e6
commit 0e8d521eed
15 changed files with 20 additions and 24 deletions

View File

@@ -42,7 +42,7 @@ Note that replication controllers may themselves have labels and would generally
Pods may be removed from a replication controller's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
Similarly, deleting a replication controller does not affect the pods it created. Its `replicas` field must first be set to 0 in order to delete the pods controlled. (Note that the client tool, kubectl, provides a single operation, [stop](kubectl_stop.md) to delete both the replication controller and the pods it controls. However, there is no such operation in the API at the moment)
Similarly, deleting a replication controller does not affect the pods it created. Its `replicas` field must first be set to 0 in order to delete the pods controlled. (Note that the client tool, kubectl, provides a single operation, [stop](user-guide/kubectl/kubectl_stop.md) to delete both the replication controller and the pods it controls. However, there is no such operation in the API at the moment)
## Responsibilities of the replication controller
@@ -73,7 +73,7 @@ Ideally, the rolling update controller would take application readiness into acc
The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
Rolling update is implemented in the client tool
[kubectl](kubectl_rolling-update.md)
[kubectl](user-guide/kubectl/kubectl_rolling-update.md)
### Multiple release tracks