manual fixes

docs/accessing-the-cluster.md

@@ -10,7 +10,7 @@ kubernetes CLI, `kubectl`.
 
 To access a cluster, you need to know the location of the cluster and have credentials
 to access it.  Typically, this is automatically set-up when you work through
-though a [Getting started guide](../docs/getting-started-guide/README.md),
+though a [Getting started guide](../docs/getting-started-guides/README.md),
 or someone else setup the cluster and provided you with credentials and a location.
 
 Check the location and credentials that kubectl knows about with this command:

docs/compute_resources.md

@@ -110,7 +110,7 @@ However, it will not be killed for excessive CPU usage.
 
 The resource usage of a pod is reported as part of the Pod status.
 
-If [optional monitoring](../cluster/addons/monitoring/README.md) is configured for your cluster,
+If [optional monitoring](../cluster/addons/cluster-monitoring/README.md) is configured for your cluster,
 then pod resource usage can be retrieved from the monitoring system.
 
 ## Troubleshooting

docs/design/resources.md

@@ -1,5 +1,5 @@
 **Note: this is a design doc, which describes features that have not been completely implemented.
-User documentation of the current state is [here](../resources.md).  The tracking issue for
+User documentation of the current state is [here](../compute_resources.md).  The tracking issue for
 implementation of this model is
 [#168](https://github.com/GoogleCloudPlatform/kubernetes/issues/168).  Currently, only memory and
 cpu limits on containers (not pods) are supported.  "memory" is in bytes and "cpu" is in

docs/devel/writing-a-getting-started-guide.md

@@ -29,7 +29,7 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
    search for uses of flags by guides.
  - We may ask that you host binary assets or large amounts of code in our `contrib` directory or on your
    own repo.
- - Setup a cluster and run the [conformance test](../../docs/devel/conformance-test.md) against it, and report the
+ - Setup a cluster and run the [conformance test](../../docs/devel/development.md#conformance-testing) against it, and report the
    results in your PR.
  - Add or update a row in [The Matrix](../../docs/getting-started-guides/README.md).
  - State the binary version of kubernetes that you tested clearly in your Guide doc and in The Matrix.

docs/getting-started-guides/coreos.md

@@ -2,7 +2,6 @@
 
 There are multiple guides on running Kubernetes with [CoreOS](http://coreos.com):
 
-* [Single Node Cluster](coreos/coreos_single_node_cluster.md)
 * [Multi-node Cluster](coreos/coreos_multinode_cluster.md)
 * [Setup Multi-node Cluster on Google Compute Engine in an easy way](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md)
 * [Multi-node cluster using cloud-config and Weave on Vagrant](https://github.com/errordeveloper/weave-demos/blob/master/poseidon/README.md)

docs/getting-started-guides/scratch.md

@@ -758,7 +758,7 @@ At this point you should be able to run through one of the basic examples, such
 
 ### Running the Conformance Test
 
-You may want to try to run the [Conformance test](../hack/conformance.sh).  Any failures may give a hint as to areas that need more attention.
+You may want to try to run the [Conformance test](../../hack/conformance-test.sh).  Any failures may give a hint as to areas that need more attention.
 
 ### Networking
 

docs/high-availability.md

@@ -46,11 +46,11 @@ choices. For example, on systemd-based systems (e.g. RHEL, CentOS), you can run
 If you are extending from a standard Kubernetes installation, the ```kubelet``` binary should already be present on your system.  You can run
 ```which kubelet``` to determine if the binary is in fact installed.  If it is not installed,
 you should install the [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), the
-[high-availability/init-kubelet](high-availability/init-kubelet) and [high-availability/default-kubelet](high-availability/default-kubelet)
+[high-availability/init-kubelet](TODO:high-availability/init-kubelet) and [high-availability/default-kubelet](TODO:high-availability/default-kubelet)
 scripts.
 
-If you are using monit, you should also install the monit daemon (```apt-get install monit```) and the [high-availability/monit-kubelet](high-availability/monit-kubelet) and
-[high-availability/monit-docker](high-availability/monit-docker) configs.
+If you are using monit, you should also install the monit daemon (```apt-get install monit```) and the [high-availability/monit-kubelet](TODO:high-availability/monit-kubelet) and
+[high-availability/monit-docker](TODO:high-availability/monit-docker) configs.
 
 On systemd systems you ```systemctl enable kubelet``` and ```systemctl enable docker```.
 

docs/secrets.md

@@ -52,7 +52,7 @@ allowed.  The values are arbitrary data, encoded using base64. The values of
 username and password in the example above, before base64 encoding,
 are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end.
 
-Create the secret using [`kubectl create`](kubectl-create.md).
+Create the secret using [`kubectl create`](kubectl_create.md).
 
 Once the secret is created, you can:
   - create pods that automatically use it via a [Service Account](service_accounts.md).