From b9fa59644f72d1c564bdf116c8a3e36413d23cb3 Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Mon, 25 Sep 2017 14:45:50 +0800 Subject: [PATCH] update some redirects and scale type --- docs/admin/federation/index.md | 2 +- .../run-replicated-stateful-application.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/admin/federation/index.md b/docs/admin/federation/index.md index ecdcca87d9..d4c524a926 100644 --- a/docs/admin/federation/index.md +++ b/docs/admin/federation/index.md @@ -134,7 +134,7 @@ existing Kubernetes cluster. It also starts a [`type: LoadBalancer`](/docs/concepts/services-networking/service/#type-loadbalancer) [`Service`](/docs/concepts/services-networking/service/) for the `federation-apiserver` and a -[`PVC`](/docs/concepts/storage/persistent-volumes/) backed +[`PVC`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims/) backed by a dynamically provisioned [`PV`](/docs/concepts/storage/persistent-volumes/) for `etcd`. All these components are created in the `federation` namespace. diff --git a/docs/tasks/run-application/run-replicated-stateful-application.md b/docs/tasks/run-application/run-replicated-stateful-application.md index 9613bb2437..b3e7dd45dc 100644 --- a/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/docs/tasks/run-application/run-replicated-stateful-application.md @@ -149,7 +149,7 @@ properties to perform orderly startup of MySQL replication. ### Generating configuration Before starting any of the containers in the Pod spec, the Pod first runs any -[Init Containers](/docs/user-guide/production-pods/#handling-initialization) +[Init Containers](/docs/concepts/workloads/pods/init-containers/) in the order defined. The first Init Container, named `init-mysql`, generates special MySQL config @@ -169,7 +169,7 @@ Because the example topology consists of a single MySQL master and any number of slaves, the script simply assigns ordinal `0` to be the master, and everyone else to be slaves. Combined with the StatefulSet controller's -[deployment order guarantee](/docs/concepts/abstractions/controllers/statefulsets/#deployment-and-scaling-guarantee), +[deployment order guarantee](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/), this ensures the MySQL master is Ready before creating slaves, so they can begin replicating. @@ -293,7 +293,7 @@ running while you force a Pod out of the Ready state. ### Break the Readiness Probe -The [readiness probe](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks) +The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes) for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'` to make sure the server is up and able to execute queries. @@ -411,7 +411,7 @@ With MySQL replication, you can scale your read query capacity by adding slaves. With StatefulSet, you can do this with a single command: ```shell -kubectl scale --replicas=5 statefulset mysql +kubectl scale statefulset mysql --replicas=5 ``` Watch the new Pods come up by running: @@ -444,7 +444,7 @@ pod "mysql-client" deleted Scaling back down is also seamless: ```shell -kubectl scale --replicas=3 statefulset mysql +kubectl scale statefulset mysql --replicas=3 ``` Note, however, that while scaling up creates new PersistentVolumeClaims