Merge pull request #7620 from lunarwhite/doc-fix

fix incorrect links in contributor guide

Author: k8s-ci-robot

contributors/devel/running-locally.md

@@ -25,7 +25,7 @@ Getting started locally
 
 ### Linux
 
-Not running Linux? Consider running [Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/), or on a cloud provider like [Google Compute Engine](https://kubernetes.io/docs/setup/production-environment/turnkey/gce/).
+Not running Linux? Consider running [Minikube](https://kubernetes.io/docs/tasks/tools/#minikube), or on a cloud provider like [Google Compute Engine](https://cloud.google.com/compute/).
 
 ### Container Runtime
 

contributors/devel/sig-testing/e2e-tests.md

@@ -608,7 +608,7 @@ In time, it is our intent to add or autogenerate a sample viper configuration th
 
 With introducing Pod Security admission in Kubernetes by default, it is desired to execute e2e tests within bounded pod security policy levels. The default pod security policy in e2e tests is [restricted](https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-levels). This is set in https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/framework.go. This ensures that e2e tests follow best practices for hardening pods by default.
 
-Two helper functions are available for returning a minimal [restricted pod security context](https://github.com/kubernetes/kubernetes/blob/d7e6eab87d0fd005b238e3ec9b088e37d41a15d3/test/e2e/framework/pod/utils.go#L119) and a [restricted container security context](https://github.com/kubernetes/kubernetes/blob/d7e6eab87d0fd005b238e3ec9b088e37d41a15d3/test/e2e/framework/pod/utils.go#L127). These can be used to initialize pod or container specs to ensure adherence for the most restricted pod security policy.
+Two helper functions are available for returning a minimal [restricted pod security context](https://github.com/kubernetes/kubernetes/blob/c876b30c2b30c0355045d7548c22b6cd42ab58da/test/e2e/framework/pod/utils.go#L156) and a [restricted container security context](https://github.com/kubernetes/kubernetes/blob/c876b30c2b30c0355045d7548c22b6cd42ab58da/test/e2e/framework/pod/utils.go#L172). These can be used to initialize pod or container specs to ensure adherence for the most restricted pod security policy.
 
 If pods need to elevate privileges to either `baseline` or `privileged` a new field - `NamespacePodSecurityEnforceLevel` - was introduced to the e2e framework to specify the necessary namespace enforcement level. Note that namespaces get created in the `BeforeEach()` phase of ginkgo tests.
 

contributors/devel/sig-testing/monitoring.md

@@ -255,7 +255,7 @@ SpyGlass.
 
 For `node-kubelet-master`, we see the following:
 
-![Spyglass Prow Job Results for node-kubelet-master`](./testgrid-images/spyglass-summary-node-kubelet-master.png "Spyglass Prow Job results viewer")
+![Spyglass Prow Job Results for node-kubelet-master`](./testgrid-images/spyglass-summary.png "Spyglass Prow Job results viewer")
 
 Here we see that 2 tests failed (both related to the node problem detector) and
 the `e2e.go: Node Tests` stage was marked as failed (because the node problem

contributors/guide/issue-triage.md

@@ -140,7 +140,7 @@ The api-machinery SIG has found that consistently meeting on a regular, fixed sc
 
 ### Triage Guide by cluster-lifecycle
 
-The cluster-lifecycle SIG has developed a [triaging page](/sig-cluster-lifecycle/grooming.md) detailing their process, including the [Milestones](#planning-milestones) stage. Here is a [March 2020 presentation](https://www.youtube.com/watch?v=Q07_PfkNjlw) delivered to the SIG chairs and leads group on their process.
+The cluster-lifecycle SIG has developed a [triaging page](/sig-cluster-lifecycle/grooming.md) detailing their process, including the [Milestones](/sig-cluster-lifecycle/grooming.md#planning-a-milestone) stage. Here is a [March 2020 presentation](https://www.youtube.com/watch?v=Q07_PfkNjlw) delivered to the SIG chairs and leads group on their process.
 
 ## Step One: Review Newly Created Open Issues