Merge pull request #1541 from cblecker/link-updates

Fix all the links

27 files changed, 93 insertions, 93 deletions

diff --git a/contributors/devel/README.md b/contributors/devel/README.md
index 9678912f..8650ad51 100644
--- a/contributors/devel/README.md
+++ b/contributors/devel/README.md
@@ -70,7 +70,7 @@ Guide](http://kubernetes.io/docs/admin/).
   Authorization applies to all HTTP requests on the main apiserver port.
   This doc explains the available authorization implementations.
 
-* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control.md))
+* **Admission Control Plugins** ([admission_control](/contributors/design-proposals/api-machinery/admission_control.md))
 
 
 ## Building releases
diff --git a/contributors/devel/api_changes.md b/contributors/devel/api_changes.md
index 293d2fe9..8104946c 100644
--- a/contributors/devel/api_changes.md
+++ b/contributors/devel/api_changes.md
@@ -495,7 +495,7 @@ The generators that create go code have a `--go-header-file` flag
 which should be a file that contains the header that should be
 included. This header is the copyright that should be present at the
 top of the generated file and should be checked with the
-[`repo-infra/verify/verify-boilerplane.sh`](https://github.com/kubernetes/repo-infra/blob/master/verify/verify-boilerplate.sh)
+[`repo-infra/verify/verify-boilerplane.sh`](https://git.k8s.io/repo-infra/verify/verify-boilerplate.sh)
 script at a later stage of the build.
 
 To invoke these generators, you can run `make update`, which runs a bunch of
@@ -829,7 +829,7 @@ The preferred approach adds an alpha field to the existing object, and ensures i
 
 1. Add a feature gate to the API server to control enablement of the new field (and associated function):
 
-    In [staging/src/k8s.io/apiserver/pkg/features/kube_features.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/features/kube_features.go):
+    In [staging/src/k8s.io/apiserver/pkg/features/kube_features.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/pkg/features/kube_features.go):
 
     ```go
     // owner: @you
diff --git a/contributors/devel/architectural-roadmap.md b/contributors/devel/architectural-roadmap.md
index 9d8a6f31..afe37b1a 100644
--- a/contributors/devel/architectural-roadmap.md
+++ b/contributors/devel/architectural-roadmap.md
@@ -252,7 +252,7 @@ Kubernetes cannot function without this basic API machinery and semantics, inclu
   factor out functionality from existing components in running
   clusters. At its core would be a pull-based declarative reconciler,
   as provided by the [current add-on
-  manager](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/addon-manager)
+  manager](https://git.k8s.io/kubernetes/cluster/addons/addon-manager)
   and as described in the [whitebox app management
   doc](https://docs.google.com/document/d/1S3l2F40LCwFKg6WG0srR6056IiZJBwDmDvzHWRffTWk/edit#heading=h.gh6cf96u8mlr). This
   would be easier once we have [apply support in the
@@ -528,7 +528,7 @@ routing APIs and functions include:
       (NIY)
 
     * Service DNS. DNS, using the [official Kubernetes
-      schema](https://github.com/kubernetes/dns/blob/master/docs/specification.md),
+      schema](https://git.k8s.io/dns/docs/specification.md),
       is required.
 
 The application layer may depend on:
@@ -601,7 +601,7 @@ Automation APIs and functions:
 * NIY: The vertical pod autoscaling API(s)
 
 * [Cluster autoscaling and/or node
-  provisioning](https://github.com/kubernetes/contrib/tree/master/cluster-autoscaler)
+  provisioning](https://git.k8s.io/contrib/cluster-autoscaler)
 
 * The PodDisruptionBudget API
 
@@ -649,7 +649,7 @@ The management layer may depend on:
 * Replacement and/or additional horizontal and vertical pod
   autoscalers
 
-* [Cluster autoscaler and/or node provisioner](https://github.com/kubernetes/contrib/tree/master/cluster-autoscaler)
+* [Cluster autoscaler and/or node provisioner](https://git.k8s.io/contrib/cluster-autoscaler)
 
 * Dynamic volume provisioners
 
@@ -880,7 +880,7 @@ LoadBalancer API is present.
 
 Extensions and their options should be registered via FooClass
 resources, similar to
-[StorageClass](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/storage/v1beta1/types.go#L31),
+[StorageClass](https://git.k8s.io/kubernetes/pkg/apis/storage/v1beta1/types.go#L31),
 but with parameter descriptions, types (e.g., integer vs string),
 constraints (e.g., range or regexp) for validation, and default
 values, with a reference to fooClassName from the extended API. These
diff --git a/contributors/devel/automation.md b/contributors/devel/automation.md
index 1d019f2b..e46ff9a5 100644
--- a/contributors/devel/automation.md
+++ b/contributors/devel/automation.md
@@ -14,9 +14,9 @@ In an effort to
    * maintain end-to-end test stability
    * load test github's label feature
 
-We have added an automated [submit-queue](https://github.com/kubernetes/test-infra/tree/master/mungegithub/submit-queue)
+We have added an automated [submit-queue](https://git.k8s.io/test-infra/mungegithub/submit-queue)
 to the
-[github "munger"](https://github.com/kubernetes/test-infra/tree/master/mungegithub)
+[github "munger"](https://git.k8s.io/test-infra/mungegithub)
 for kubernetes.
 
 The submit-queue does the following:
@@ -48,7 +48,7 @@ If these tests pass a second time, the PR will be merged when this PR finishes r
 
 ## Github Munger
 
-We run [github "mungers"](https://github.com/kubernetes/test-infra/tree/master/mungegithub).
+We run [github "mungers"](https://git.k8s.io/test-infra/mungegithub).
 
 This runs repeatedly over github pulls and issues and runs modular "mungers".
 The mungers include the "submit-queue" referenced above along
diff --git a/contributors/devel/bazel.md b/contributors/devel/bazel.md
index 21b57ff6..de80b4b2 100644
--- a/contributors/devel/bazel.md
+++ b/contributors/devel/bazel.md
@@ -3,7 +3,7 @@
 Building and testing Kubernetes with  Bazel is supported but not yet default.
 
 Go rules are managed by the [`gazelle`](https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle)
-tool, with some additional rules managed by the [`kazel`](https://github.com/kubernetes/repo-infra/tree/master/kazel) tool.
+tool, with some additional rules managed by the [`kazel`](https://git.k8s.io/repo-infra/kazel) tool.
 These tools are called via the `hack/update-bazel.sh` script.
 
 Instructions for installing Bazel
@@ -26,7 +26,7 @@ $ bazel test //pkg/kubectl/...
 
 ## Planter
 If you don't want to install Bazel, you can instead try using the unofficial
-[Planter](https://github.com/kubernetes/test-infra/tree/master/planter) tool,
+[Planter](https://git.k8s.io/test-infra/planter) tool,
 which runs Bazel inside a Docker container.
 
 For example, you can run
diff --git a/contributors/devel/cherry-picks.md b/contributors/devel/cherry-picks.md
index 4d9e65f0..232b2a0b 100644
--- a/contributors/devel/cherry-picks.md
+++ b/contributors/devel/cherry-picks.md
@@ -15,7 +15,7 @@ depending on the point in the release cycle.
    to set the same label to confirm that no release note is needed.
 1. `release-note` labeled PRs generate a release note using the PR title by
    default OR the release-note block in the PR template if filled in.
-  * See the [PR template](https://github.com/kubernetes/kubernetes/blob/master/.github/PULL_REQUEST_TEMPLATE.md) for more details.
+  * See the [PR template](https://git.k8s.io/kubernetes/.github/PULL_REQUEST_TEMPLATE.md) for more details.
   * PR titles and body comments are mutable and can be modified at any time
     prior to the release to reflect a release note friendly message.
 
diff --git a/contributors/devel/container-runtime-interface.md b/contributors/devel/container-runtime-interface.md
index 96f5f10d..29e96ed2 100644
--- a/contributors/devel/container-runtime-interface.md
+++ b/contributors/devel/container-runtime-interface.md
@@ -3,9 +3,9 @@
 ## What is CRI?
 
 CRI (_Container Runtime Interface_) consists of a
-[protobuf API](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/cri/v1alpha1/runtime/api.proto),
+[protobuf API](https://git.k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime/api.proto),
 specifications/requirements (to-be-added),
-and [libraries](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/server/streaming)
+and [libraries](https://git.k8s.io/kubernetes/pkg/kubelet/server/streaming)
 for container runtimes to integrate with kubelet on a node. CRI is currently in Alpha.
 
 In the future, we plan to add more developer tools such as the CRI validation
@@ -59,8 +59,8 @@ Below is a mixed list of CRI specifications/requirements, design docs and
 proposals. We are working on adding more documentation for the API.
 
   - [Original proposal](https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/proposals/container-runtime-interface-v1.md)
-  - [Networking](https://github.com/kubernetes/community/blob/master/contributors/devel/kubelet-cri-networking.md)
-  - [Container metrics](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-container-stats.md)
+  - [Networking](/contributors/devel/kubelet-cri-networking.md)
+  - [Container metrics](/contributors/devel/cri-container-stats.md)
   - [Exec/attach/port-forward streaming requests](https://docs.google.com/document/d/1OE_QoInPlVCK9rMAx9aybRmgFiVjHpJCHI9LrfdNM_s/edit?usp=sharing)
   - [Container stdout/stderr logs](https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/proposals/kubelet-cri-logging.md)
 
diff --git a/contributors/devel/contributor-cheatsheet.md b/contributors/devel/contributor-cheatsheet.md
index f8506d16..5ec5a3f3 100644
--- a/contributors/devel/contributor-cheatsheet.md
+++ b/contributors/devel/contributor-cheatsheet.md
@@ -13,14 +13,14 @@ A list of common resources when contributing to Kubernetes.
 - [Gubernator Dashboard - k8s.reviews](https://k8s-gubernator.appspot.com/pr)
 - [reviewable.kubernetes.io](https://reviewable.kubernetes.io/reviews#-)
 - [Submit Queue](https://submit-queue.k8s.io)
-- [Bot commands](https://github.com/kubernetes/test-infra/blob/master/commands.md)
+- [Bot commands](https://git.k8s.io/test-infra/commands.md)
 - [Release Buckets](http://gcsweb.k8s.io/gcs/kubernetes-release/)
 - Developer Guide
-  - [Cherry Picking Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md) - [Queue](http://cherrypick.k8s.io/#/queue)
+  - [Cherry Picking Guide](/contributors/devel/cherry-picks.md) - [Queue](http://cherrypick.k8s.io/#/queue)
 
 ## SIGs and Working Groups
 
-- [Master SIG list](https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list)
+- [Master SIG list](/sig-list.md#master-sig-list)
 
 ## Community
 
diff --git a/contributors/devel/controllers.md b/contributors/devel/controllers.md
index 0764f63a..50dada02 100644
--- a/contributors/devel/controllers.md
+++ b/contributors/devel/controllers.md
@@ -32,7 +32,7 @@ When you're writing controllers, there are few guidelines that will help make su
 
 1. Use `SharedInformers`.  `SharedInformers` provide hooks to receive notifications of adds, updates, and deletes for a particular resource.  They also provide convenience functions for accessing shared caches and determining when a cache is primed.
 
-   Use the factory methods down in https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/informers/factory.go to ensure that you are sharing the same instance of the cache as everyone else.
+   Use the factory methods down in https://git.k8s.io/kubernetes/staging/src/k8s.io/client-go/informers/factory.go to ensure that you are sharing the same instance of the cache as everyone else.
 
    This saves us connections against the API server, duplicate serialization costs server-side, duplicate deserialization costs controller-side, and duplicate caching costs controller-side.
 
@@ -62,7 +62,7 @@ When you're writing controllers, there are few guidelines that will help make su
 
     This lets clients know that the controller has processed a resource. Make sure that your controller is the main controller that is responsible for that resource, otherwise if you need to communicate observation via your own controller, you will need to create a different kind of ObservedGeneration in the Status of the resource.
 
-1. Consider using owner references for resources that result in the creation of other resources (eg. a ReplicaSet results in creating Pods). Thus you ensure that children resources are going to be garbage-collected once a resource managed by your controller is deleted. For more information on owner references, read more [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/controller-ref.md).
+1. Consider using owner references for resources that result in the creation of other resources (eg. a ReplicaSet results in creating Pods). Thus you ensure that children resources are going to be garbage-collected once a resource managed by your controller is deleted. For more information on owner references, read more [here](/contributors/design-proposals/api-machinery/controller-ref.md).
 
     Pay special attention in the way you are doing adoption. You shouldn't adopt children for a resource when either the parent or the children are marked for deletion. If you are using a cache for your resources, you will likely need to bypass it with a direct API read in case you observe that an owner reference has been updated for one of the children. Thus, you ensure your controller is not racing with the garbage collector.
 
diff --git a/contributors/devel/cri-container-stats.md b/contributors/devel/cri-container-stats.md
index a2352fb5..c1176f05 100644
--- a/contributors/devel/cri-container-stats.md
+++ b/contributors/devel/cri-container-stats.md
@@ -1,7 +1,7 @@
 # Container Runtime Interface: Container Metrics
 
 [Container runtime interface
-(CRI)](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)
+(CRI)](/contributors/devel/container-runtime-interface.md)
 provides an abstraction for container runtimes to integrate with Kubernetes.
 CRI expects the runtime to provide resource usage statistics for the
 containers.
@@ -12,7 +12,7 @@ Historically Kubelet relied on the [cAdvisor](https://github.com/google/cadvisor
 library, an open-source project hosted in a separate repository, to retrieve
 container metrics such as CPU and memory usage. These metrics are then aggregated
 and exposed through Kubelet's [Summary
-API](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/stats/v1alpha1/types.go)
+API](https://git.k8s.io/kubernetes/pkg/kubelet/apis/stats/v1alpha1/types.go)
 for the monitoring pipeline (and other components) to consume. Any container
 runtime (e.g., Docker and Rkt) integrated with Kubernetes needed to add a
 corresponding package in cAdvisor to support tracking container and image file
@@ -23,9 +23,9 @@ progression to augment CRI to serve container metrics to eliminate a separate
 integration point.
 
 *See the [core metrics design
-proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/core-metrics-pipeline.md)
+proposal](/contributors/design-proposals/instrumentation/core-metrics-pipeline.md)
 for more information on metrics exposed by Kubelet, and [monitoring
-architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)
+architecture](/contributors/design-proposals/instrumentation/monitoring_architecture.md)
 for the evolving monitoring pipeline in Kubernetes.*
 
 # Container Metrics
diff --git a/contributors/devel/development.md b/contributors/devel/development.md
index a3264c05..60ff877c 100644
--- a/contributors/devel/development.md
+++ b/contributors/devel/development.md
@@ -293,13 +293,13 @@ make test
 make test WHAT=./pkg/api/helper GOFLAGS=-v
 
 # Run integration tests, requires etcd
-# For more info, visit https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md#integration-tests
+# For more info, visit https://git.k8s.io/community/contributors/devel/testing.md#integration-tests
 make test-integration
 
 # Run e2e tests by building test binaries, turn up a test cluster, run all tests, and tear the cluster down
 # Equivalent to: go run hack/e2e.go -- -v --build --up --test --down
 # Note: running all e2e tests takes a LONG time! To run specific e2e tests, visit:
-# https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md#building-kubernetes-and-running-the-tests
+# https://git.k8s.io/community/contributors/devel/e2e-tests.md#building-kubernetes-and-running-the-tests
 make test-e2e
 ```
 
@@ -398,9 +398,9 @@ masse. This makes reviews easier.
 
 
 [OS X GNU tools]: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x
-[build/build-image/cross]: https://github.com/kubernetes/kubernetes/blob/master/build/build-image/cross
-[build/common.sh]: https://github.com/kubernetes/kubernetes/blob/master/build/common.sh
-[e2e-image]: https://github.com/kubernetes/test-infra/tree/master/jenkins/e2e-image
+[build/build-image/cross]: https://git.k8s.io/kubernetes/build/build-image/cross
+[build/common.sh]: https://git.k8s.io/kubernetes/build/common.sh
+[e2e-image]: https://git.k8s.io/test-infra/jenkins/e2e-image
 [etcd-latest]: https://coreos.com/etcd/docs/latest
 [etcd-install]: testing.md#install-etcd-dependency
 <!-- https://github.com/coreos/etcd/releases -->
@@ -409,5 +409,5 @@ masse. This makes reviews easier.
 [kubectl user guide]: https://kubernetes.io/docs/user-guide/kubectl
 [kubernetes.io]: https://kubernetes.io
 [mercurial]: http://mercurial.selenic.com/wiki/Download
-[test-image]: https://github.com/kubernetes/test-infra/tree/master/jenkins/test-image
+[test-image]: https://git.k8s.io/test-infra/jenkins/test-image
 [Build with Bazel]: bazel.md
diff --git a/contributors/devel/e2e-node-tests.md b/contributors/devel/e2e-node-tests.md
index 0dda84a3..4f3327cb 100644
--- a/contributors/devel/e2e-node-tests.md
+++ b/contributors/devel/e2e-node-tests.md
@@ -137,7 +137,7 @@ make test-e2e-node REMOTE=true IMAGE_PROJECT="<name-of-project-with-images>" IMA
 ```
 
 Setting up your own host image may require additional steps such as installing etcd or docker.  See
-[setup_host.sh](https://github.com/kubernetes/kubernetes/tree/master/test/e2e_node/environment/setup_host.sh) for common steps to setup hosts to run node tests.
+[setup_host.sh](https://git.k8s.io/kubernetes/test/e2e_node/environment/setup_host.sh) for common steps to setup hosts to run node tests.
 
 ## Create instances using a different instance name prefix
 
@@ -223,7 +223,7 @@ the bottom of the comments section.  To re-run just the node e2e tests from the
 `@k8s-bot node e2e test this issue: #<Flake-Issue-Number or IGNORE>` and **include a link to the test
 failure logs if caused by a flake.**
 
-The PR builder runs tests against the images listed in [jenkins-pull.properties](https://github.com/kubernetes/kubernetes/tree/master/test/e2e_node/jenkins/jenkins-pull.properties)
+The PR builder runs tests against the images listed in [jenkins-pull.properties](https://git.k8s.io/kubernetes/test/e2e_node/jenkins/jenkins-pull.properties)
 
-The post submit tests run against the images listed in [jenkins-ci.properties](https://github.com/kubernetes/kubernetes/tree/master/test/e2e_node/jenkins/jenkins-ci.properties)
+The post submit tests run against the images listed in [jenkins-ci.properties](https://git.k8s.io/kubernetes/test/e2e_node/jenkins/jenkins-ci.properties)
 
diff --git a/contributors/devel/e2e-tests.md b/contributors/devel/e2e-tests.md
index 1ee22022..cf4127d0 100644
--- a/contributors/devel/e2e-tests.md
+++ b/contributors/devel/e2e-tests.md
@@ -146,7 +146,7 @@ go run hack/e2e.go -- -v --down
 
 The logic in `e2e.go` moved out of the main kubernetes repo to test-infra.
 The remaining code in `hack/e2e.go` installs `kubetest` and sends it flags.
-It now lives in [kubernetes/test-infra/kubetest](https://github.com/kubernetes/test-infra/tree/master/kubetest).
+It now lives in [kubernetes/test-infra/kubetest](https://git.k8s.io/test-infra/kubetest).
 By default `hack/e2e.go` updates and installs `kubetest` once per day.
 Control the updater behavior with the `--get` and `--old` flags:
 The `--` flag separates updater and kubetest flags (kubetest flags on the right).
@@ -446,7 +446,7 @@ similarly enough to older versions.  The general strategy is to cover the follow
    same version (e.g. a cluster upgraded to v1.3 passes the same v1.3 tests as
    a newly-created v1.3 cluster).
 
-[hack/e2e-runner.sh](https://github.com/kubernetes/test-infra/blob/master/jenkins/e2e-image/e2e-runner.sh) is
+[hack/e2e-runner.sh](https://git.k8s.io/test-infra/jenkins/e2e-image/e2e-runner.sh) is
 the authoritative source on how to run version-skewed tests, but below is a
 quick-and-dirty tutorial.
 
@@ -569,7 +569,7 @@ breaking changes, it does *not* block the merge-queue, and thus should run in
 some separate test suites owned by the feature owner(s)
 (see [Continuous Integration](#continuous-integration) below).
 
-Every test should be owned by a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md),
+Every test should be owned by a [SIG](/sig-list.md),
 and have a corresponding `[sig-<name>]` label.
 
 ### Viper configuration and hierarchichal test parameters.
@@ -582,7 +582,7 @@ To use viper, rather than flags, to configure your tests:
 
 - Just add "e2e.json" to the current directory you are in, and define parameters in it... i.e. `"kubeconfig":"/tmp/x"`.
 
-Note that advanced testing parameters, and hierarchichally defined parameters, are only defined in viper, to see what they are, you can dive into [TestContextType](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/test_context.go).
+Note that advanced testing parameters, and hierarchichally defined parameters, are only defined in viper, to see what they are, you can dive into [TestContextType](https://git.k8s.io/kubernetes/test/e2e/framework/test_context.go).
 
 In time, it is our intent to add or autogenerate a sample viper configuration that includes all e2e parameters, to ship with kubernetes.
 
@@ -656,7 +656,7 @@ A quick overview of how we run e2e CI on Kubernetes.
 We run a battery of `e2e` tests against `HEAD` of the master branch on a
 continuous basis, and block merges via the [submit
 queue](http://submit-queue.k8s.io/) on a subset of those tests if they fail (the
-subset is defined in the [munger config](https://github.com/kubernetes/test-infra/tree/master/mungegithub/mungers/submit-queue.go)
+subset is defined in the [munger config](https://git.k8s.io/test-infra/mungegithub/mungers/submit-queue.go)
 via the `jenkins-jobs` flag; note we also block on	`kubernetes-build` and
 `kubernetes-test-go` jobs for build and unit and integration tests).
 
@@ -732,7 +732,7 @@ label, and will be incorporated into our core suites. If tests are not expected
 to pass by default, (e.g. they require a special environment such as added
 quota,) they should remain with the `[Feature:.+]` label, and the suites that
 run them should be incorporated into the
-[munger config](https://github.com/kubernetes/test-infra/tree/master/mungegithub/mungers/submit-queue.go)
+[munger config](https://git.k8s.io/test-infra/mungegithub/mungers/submit-queue.go)
 via the `jenkins-jobs` flag.
 
 Occasionally, we'll want to add tests to better exercise features that are
diff --git a/contributors/devel/flexvolume.md b/contributors/devel/flexvolume.md
index 5fc518a4..52d42ccf 100644
--- a/contributors/devel/flexvolume.md
+++ b/contributors/devel/flexvolume.md
@@ -14,10 +14,10 @@ The vendor and driver names must match flexVolume.driver in the volume spec, wit
 
 ## Dynamic Plugin Discovery
 Beginning in v1.8, Flexvolume supports the ability to detect drivers on the fly. Instead of requiring drivers to exist at system initialization time or having to restart kubelet or controller manager, drivers can be installed, upgraded/downgraded, and uninstalled while the system is running.
-For more information, please refer to the [design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md).
+For more information, please refer to the [design document](/contributors/design-proposals/storage/flexvolume-deployment.md).
 
 ## Automated Plugin Installation/Upgrade
-One possible way to install and upgrade your Flexvolume drivers is by using a DaemonSet. See [Recommended Driver Deployment Method](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md#recommended-driver-deployment-method) for details.
+One possible way to install and upgrade your Flexvolume drivers is by using a DaemonSet. See [Recommended Driver Deployment Method](/contributors/design-proposals/storage/flexvolume-deployment.md#recommended-driver-deployment-method) for details.
 
 ## Plugin details
 The plugin expects the following call-outs are implemented for the backend drivers. Some call-outs are optional. Call-outs are invoked from the Kubelet & the Controller manager nodes.
@@ -50,7 +50,7 @@ Detach the volume from the Kubelet node. Nodename param is only valid/relevant i
 ```
 
 #### Wait for attach:
-Wait for the volume to be attached on the remote node. On success, the path to the device is returned. Called from both Kubelet & Controller manager. The timeout should be 10m (based on https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/volumemanager/volume_manager.go#L88 )
+Wait for the volume to be attached on the remote node. On success, the path to the device is returned. Called from both Kubelet & Controller manager. The timeout should be 10m (based on https://git.k8s.io/kubernetes/pkg/kubelet/volumemanager/volume_manager.go#L88 )
 
 ```
 <driver executable> waitforattach <mount device> <json options>
@@ -132,7 +132,7 @@ Note: Secrets are passed only to "mount/unmount" call-outs.
 See [nginx.yaml] & [nginx-nfs.yaml] for a quick example on how to use Flexvolume in a pod.
 
 
-[lvm]: https://github.com/kubernetes/kubernetes/blob/master/examples/volumes/flexvolume/lvm
-[nfs]: https://github.com/kubernetes/kubernetes/blob/master/examples/volumes/flexvolume/nfs
-[nginx.yaml]: https://github.com/kubernetes/kubernetes/blob/master/examples/volumes/flexvolume/nginx.yaml
-[nginx-nfs.yaml]: https://github.com/kubernetes/kubernetes/blob/master/examples/volumes/flexvolume/nginx-nfs.yaml
+[lvm]: https://git.k8s.io/kubernetes/examples/volumes/flexvolume/lvm
+[nfs]: https://git.k8s.io/kubernetes/examples/volumes/flexvolume/nfs
+[nginx.yaml]: https://git.k8s.io/kubernetes/examples/volumes/flexvolume/nginx.yaml
+[nginx-nfs.yaml]: https://git.k8s.io/kubernetes/examples/volumes/flexvolume/nginx-nfs.yaml
diff --git a/contributors/devel/generating-clientset.md b/contributors/devel/generating-clientset.md
index 2ef0ddd5..7a47aeb8 100644
--- a/contributors/devel/generating-clientset.md
+++ b/contributors/devel/generating-clientset.md
@@ -33,7 +33,7 @@ In addition, the following optional tags influence the client generation:
 $ client-gen --input="api/v1,extensions/v1beta1" --clientset-name="my_release"
 ```
 
-**3.** ***Adding expansion methods***: client-gen only generates the common methods, such as CRUD. You can manually add additional methods through the expansion interface. For example, this [file](https://github.com/kubernetes/kubernetes/blob/master/pkg/client/clientset_generated/internalclientset/typed/core/internalversion/pod_expansion.go) adds additional methods to Pod's client. As a convention, we put the expansion interface and its methods in file ${TYPE}_expansion.go. In most cases, you don't want to remove existing expansion files. So to make life easier, instead of creating a new clientset from scratch, ***you can copy and rename an existing clientset (so that all the expansion files are copied)***, and then run client-gen.
+**3.** ***Adding expansion methods***: client-gen only generates the common methods, such as CRUD. You can manually add additional methods through the expansion interface. For example, this [file](https://git.k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/core/internalversion/pod_expansion.go) adds additional methods to Pod's client. As a convention, we put the expansion interface and its methods in file ${TYPE}_expansion.go. In most cases, you don't want to remove existing expansion files. So to make life easier, instead of creating a new clientset from scratch, ***you can copy and rename an existing clientset (so that all the expansion files are copied)***, and then run client-gen.
 
 ## Output of client-gen
 
@@ -43,7 +43,7 @@ $ client-gen --input="api/v1,extensions/v1beta1" --clientset-name="my_release"
 
 ## Released clientsets
 
-If you are contributing code to k8s.io/kubernetes, try to use the generated clientset [here](https://github.com/kubernetes/kubernetes/tree/master/pkg/client/clientset_generated/internalclientset).
+If you are contributing code to k8s.io/kubernetes, try to use the generated clientset [here](https://git.k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset).
 
 If you need a stable Go client to build your own project, please refer to the [client-go repository](https://github.com/kubernetes/client-go).
 
diff --git a/contributors/devel/gubernator.md b/contributors/devel/gubernator.md
index 9e3855ff..2a25ddd7 100644
--- a/contributors/devel/gubernator.md
+++ b/contributors/devel/gubernator.md
@@ -113,7 +113,7 @@ k8s-gubernator.appspot.com/build/yourusername-g8r-logs/logs/e2e-node/timestamp
 Gubernator provides a framework for debugging failures and introduces useful features.
 There is still a lot of room for more features and growth to make the debugging process more efficient.
 
-How to contribute (see https://github.com/kubernetes/test-infra/blob/master/gubernator/README.md)
+How to contribute (see https://git.k8s.io/test-infra/gubernator/README.md)
 
 * Extend GUBERNATOR flag to all local tests
 
diff --git a/contributors/devel/issues.md b/contributors/devel/issues.md
index 387bd987..575eddff 100644
--- a/contributors/devel/issues.md
+++ b/contributors/devel/issues.md
@@ -33,7 +33,7 @@ for other github repositories related to Kubernetes is TBD.
 Most people can leave comments and open issues. They don't have the ability to
 set labels, change milestones and close other peoples issues. For that we use
 a bot to manage labelling and triaging. The bot has a set of
-[commands and permissions](https://github.com/kubernetes/test-infra/blob/master/commands.md)
+[commands and permissions](https://git.k8s.io/test-infra/commands.md)
 and this document will cover the basic ones.
 
 ## Determine if it’s a support request
@@ -93,7 +93,7 @@ The Kubernetes Team
 ```
 
 ## Find the right SIG(s)
-Components are divided among [Special Interest Groups (SIGs)](https://github.com/kubernetes/community/blob/master/sig-list.md). Find a proper SIG for the ownership of the issue using the bot:
+Components are divided among [Special Interest Groups (SIGs)](/sig-list.md). Find a proper SIG for the ownership of the issue using the bot:
 
 * Typing `/sig network` in a comment should add the sig/network label, for
 example.
diff --git a/contributors/devel/kubectl-conventions.md b/contributors/devel/kubectl-conventions.md
index 127546c9..5b009657 100644
--- a/contributors/devel/kubectl-conventions.md
+++ b/contributors/devel/kubectl-conventions.md
@@ -372,7 +372,7 @@ and as noted in [command conventions](#command-conventions), ideally that logic
 should exist server-side so any client could take advantage of it. Notice that
 this is not a mandatory structure and not every command is implemented this way,
 but this is a nice convention so try to be compliant with it. As an example,
-have a look at how [kubectl logs](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/logs.go) is implemented.
+have a look at how [kubectl logs](https://git.k8s.io/kubernetes/pkg/kubectl/cmd/logs.go) is implemented.
 
 ## Exit code conventions
 
diff --git a/contributors/devel/node-performance-testing.md b/contributors/devel/node-performance-testing.md
index 4afa8d25..d43737a8 100644
--- a/contributors/devel/node-performance-testing.md
+++ b/contributors/devel/node-performance-testing.md
@@ -26,7 +26,7 @@ Heapster will hide the performance cost of serving those stats in the Kubelet.
 
 Disabling addons is simple. Just ssh into the Kubernetes master and move the
 addon from `/etc/kubernetes/addons/` to a backup location. More details
-[here](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/).
+[here](https://git.k8s.io/kubernetes/cluster/addons/).
 
 ### Which / how many pods?
 
@@ -57,7 +57,7 @@ sampling.
 ## E2E Performance Test
 
 There is an end-to-end test for collecting overall resource usage of node
-components: [kubelet_perf.go](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/node/kubelet_perf.go). To
+components: [kubelet_perf.go](https://git.k8s.io/kubernetes/test/e2e/node/kubelet_perf.go). To
 run the test, simply make sure you have an e2e cluster running (`go run
 hack/e2e.go -- -up`) and [set up](#cluster-set-up) correctly.
 
diff --git a/contributors/devel/on-call-federation-build-cop.md b/contributors/devel/on-call-federation-build-cop.md
index 69c2d973..708c854a 100644
--- a/contributors/devel/on-call-federation-build-cop.md
+++ b/contributors/devel/on-call-federation-build-cop.md
@@ -24,10 +24,10 @@ Federation CI e2e job names are as below:
 
 Search for the above job names in various configuration files as below:
 
-* Prow config: https://github.com/kubernetes/test-infra/blob/master/prow/config.yaml
-* Test job/bootstrap config: https://github.com/kubernetes/test-infra/blob/master/jobs/config.json
-* Test grid config: https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml
-* Job specific config: https://github.com/kubernetes/test-infra/tree/master/jobs/env
+* Prow config: https://git.k8s.io/test-infra/prow/config.yaml
+* Test job/bootstrap config: https://git.k8s.io/test-infra/jobs/config.json
+* Test grid config: https://git.k8s.io/test-infra/testgrid/config/config.yaml
+* Job specific config: https://git.k8s.io/test-infra/jobs/env
 
 ### Results
 
@@ -73,10 +73,10 @@ Federation pre-submit jobs have following names.
 
 Search for the above job names in various configuration files as below:
 
-* Prow config: https://github.com/kubernetes/test-infra/blob/master/prow/config.yaml
-* Test job/bootstrap config: https://github.com/kubernetes/test-infra/blob/master/jobs/config.json
-* Test grid config: https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml
-* Job specific config: https://github.com/kubernetes/test-infra/tree/master/jobs/env
+* Prow config: https://git.k8s.io/test-infra/prow/config.yaml
+* Test job/bootstrap config: https://git.k8s.io/test-infra/jobs/config.json
+* Test grid config: https://git.k8s.io/test-infra/testgrid/config/config.yaml
+* Job specific config: https://git.k8s.io/test-infra/jobs/env
 
 ### Results
 
@@ -91,7 +91,7 @@ We track the flakiness metrics of all the pre-submit jobs and
 individual tests that run against PRs in
 [kubernetes/federation](https://github.com/kubernetes/federation).
 
-* The metrics that we track are documented in https://github.com/kubernetes/test-infra/blob/master/metrics/README.md#metrics.
+* The metrics that we track are documented in https://git.k8s.io/test-infra/metrics/README.md#metrics.
 * Job-level metrics are available in http://storage.googleapis.com/k8s-metrics/job-flakes-latest.json.
 
 ### Playbook
diff --git a/contributors/devel/owners.md b/contributors/devel/owners.md
index aea8579e..489cf309 100644
--- a/contributors/devel/owners.md
+++ b/contributors/devel/owners.md
@@ -16,7 +16,7 @@ of OWNERS files
 ## OWNERS spec
 
 The [mungegithub gitrepos
-feature](https://github.com/kubernetes/test-infra/blob/master/mungegithub/features/repo-updates.go)
+feature](https://git.k8s.io/test-infra/mungegithub/features/repo-updates.go)
 is the main consumer of OWNERS files.  If this page is out of date, look there.
 
 Each directory that contains a unit of independent code or content may also contain an OWNERS file.
@@ -72,7 +72,7 @@ GitHub usernames and aliases listed in OWNERS files are case-insensitive.
 ## Code Review Process
 
 This is a simplified description of our [full PR testing and merge
-workflow](https://github.com/kubernetes/community/blob/master/contributors/devel/pull-requests.md#the-testing-and-merge-workflow)
+workflow](/contributors/devel/pull-requests.md#the-testing-and-merge-workflow)
 that conveniently forgets about the existence of tests, to focus solely on the roles driven by
 OWNERS files.
 
@@ -158,13 +158,13 @@ is the state of today.
 
 ## Implementation
 
-### [`mungegithub`](https://github.com/kubernetes/test-infra/tree/master/mungegithub)
+### [`mungegithub`](https://git.k8s.io/test-infra/mungegithub)
 
 Mungegithub polls GitHub, and "munges" things it finds, including issues and pull requests. It is
 stateful, in that restarting it means it loses track of which things it has munged at what time.
 
 - [feature:
-  gitrepos](https://github.com/kubernetes/test-infra/blob/master/mungegithub/features/repo-updates.go)
+  gitrepos](https://git.k8s.io/test-infra/mungegithub/features/repo-updates.go)
   - responsible for parsing OWNERS and OWNERS_ALIAS files
   - if its `use-reviewers` flag is set to false, **approvers** will also be **reviewers**
   - if its `enable-md-yaml` flag is set, `.md` files will also be parsed to see if they have
@@ -172,14 +172,14 @@ stateful, in that restarting it means it loses track of which things it has mung
 [kubernetes.github.io](https://github.com/kubernetes/kubernetes.github.io/))
   - used by other mungers to get the set of **reviewers** or **approvers** for a given path
 - [munger:
-  blunderbuss](https://github.com/kubernetes/test-infra/blob/master/mungegithub/mungers/blunderbuss.go)
+  blunderbuss](https://git.k8s.io/test-infra/mungegithub/mungers/blunderbuss.go)
   - responsible for determining **reviewers** and assigning to them
   - chooses from people in the deepest/closest OWNERS files to the code being changed
   - weights its choice based on the magnitude of lines changed for each file
   - randomly chooses to ensure the same people aren't chosen every time
   - if its `blunderbuss-number-assignees` flag is unset, it will default to 2 assignees
 - [munger:
-  approval-handler](https://github.com/kubernetes/test-infra/blob/master/mungegithub/mungers/approval-handler.go)
+  approval-handler](https://git.k8s.io/test-infra/mungegithub/mungers/approval-handler.go)
   - responsible for adding the  `approved` label once an **approver** for each of the required
     OWNERS files has `/approve`'d
   - responsible for commenting as required OWNERS files are satisfied
@@ -187,19 +187,19 @@ stateful, in that restarting it means it loses track of which things it has mung
   - [full description of the
     algorithm](https://github.com/kubernetes/test-infra/blob/6f5df70c29528db89d07106a8156411068518cbc/mungegithub/mungers/approval-handler.go#L99-L111)
 - [munger:
-  submit-queue](https://github.com/kubernetes/test-infra/blob/master/mungegithub/mungers/submit-queue.go)
+  submit-queue](https://git.k8s.io/test-infra/mungegithub/mungers/submit-queue.go)
   - responsible for merging PR's
   - responsible for updating a GitHub status check explaining why a PR can't be merged (eg: a
     missing `lgtm` or `approved` label)
 
-### [`prow`](https://github.com/kubernetes/test-infra/tree/master/prow)
+### [`prow`](https://git.k8s.io/test-infra/prow)
 
 Prow receives events from GitHub, and reacts to them. It is effectively stateless.
 
-- [plugin: lgtm](https://github.com/kubernetes/test-infra/tree/master/prow/plugins/lgtm)
+- [plugin: lgtm](https://git.k8s.io/test-infra/prow/plugins/lgtm)
   - responsible for adding the `lgtm` label when a **reviewer** comments `/lgtm` on a PR
   - the **PR author** may not `/lgtm` their own PR
-- [plugin: assign](https://github.com/kubernetes/test-infra/tree/master/prow/plugins/assign)
+- [plugin: assign](https://git.k8s.io/test-infra/prow/plugins/assign)
   - responsible for assigning GitHub users in response to `/assign` comments on a PR
   - responsible for unassigning GitHub users in response to `/unassign` comments on a PR
 
diff --git a/contributors/devel/pull-requests.md b/contributors/devel/pull-requests.md
index 40ec31c0..50e457a2 100644
--- a/contributors/devel/pull-requests.md
+++ b/contributors/devel/pull-requests.md
@@ -44,7 +44,7 @@ pass or fail of continuous integration.
 
 ## Sign the CLA
 
-You must sign the CLA before your first contribution. [Read more about the CLA.](https://github.com/kubernetes/community/blob/master/CLA.md)
+You must sign the CLA before your first contribution. [Read more about the CLA.](/CLA.md)
 
 If you haven't signed the Contributor License Agreement (CLA) before making a PR,
 the `@k8s-ci-robot` will leave a comment with instructions on how to sign the CLA.
@@ -92,7 +92,7 @@ For PRs that don't need to be mentioned at release time, just write "NONE" (case
 
 The `/release-note-none` comment command can still be used as an alternative to writing "NONE" in the release-note block if it is left empty.
 
-To see how to format your release notes, view the [PR template](https://github.com/kubernetes/kubernetes/blob/master/.github/PULL_REQUEST_TEMPLATE.md) for a brief example. PR titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
+To see how to format your release notes, view the [PR template](https://git.k8s.io/kubernetes/.github/PULL_REQUEST_TEMPLATE.md) for a brief example. PR titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
 
 Release notes apply to PRs on the master branch. For cherry-pick PRs, see the [cherry-pick instructions](cherry-picks.md). The only exception to these rules is when a PR is not a cherry-pick and is targeted directly to the non-master branch.  In this case, a `release-note-*` label is required for that non-master PR.
 
@@ -127,7 +127,7 @@ If you are a member, or a member comments `/ok-to-test`, the PR will be consider
 
 Once the tests pass, all failures are commented as flakes, or the reviewer adds the labels `lgtm` and `approved`, the PR enters the final merge queue. The merge queue is needed to make sure no incompatible changes have been introduced by other PRs since the tests were last run on your PR.
 
-Either the [on call contributor](on-call-rotations.md) will manage the merge queue manually, or the [GitHub "munger"](https://github.com/kubernetes/test-infra/tree/master/mungegithub) submit-queue plugin will manage the merge queue automatically.
+Either the [on call contributor](on-call-rotations.md) will manage the merge queue manually, or the [GitHub "munger"](https://git.k8s.io/test-infra/mungegithub) submit-queue plugin will manage the merge queue automatically.
 
 1. The PR enters the merge queue ([http://submit-queue.k8s.io](http://submit-queue.k8s.io))
 1. The merge queue triggers a test re-run with the comment `/test all [submit-queue is verifying that this PR is safe to merge]`
@@ -151,7 +151,7 @@ The GitHub robots will add and remove the `do-not-merge/hold` label as you use t
 
 ## Comment Commands Reference
 
-[The commands doc](https://github.com/kubernetes/test-infra/blob/master/commands.md) contains a reference for all comment commands.
+[The commands doc](https://git.k8s.io/test-infra/commands.md) contains a reference for all comment commands.
 
 ## Automation
 
@@ -220,8 +220,8 @@ Are you sure Feature-X is something the Kubernetes team wants or will accept? Is
 
 It's better to get confirmation beforehand. There are two ways to do this:
 
-- Make a proposal doc (in docs/proposals; for example [the QoS proposal](http://prs.k8s.io/11713)), or reach out to the affected special interest group (SIG). Here's a [list of SIGs](https://github.com/kubernetes/community/blob/master/sig-list.md)
-- Coordinate your effort with [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) ahead of time
+- Make a proposal doc (in docs/proposals; for example [the QoS proposal](http://prs.k8s.io/11713)), or reach out to the affected special interest group (SIG). Here's a [list of SIGs](/sig-list.md)
+- Coordinate your effort with [SIG Docs](/sig-docs) ahead of time
 - Make a sketch PR (e.g., just the API or Go interface). Write or code up just enough to express the idea and the design and why you made those choices
 
 Or, do all of the above.
diff --git a/contributors/devel/scalability-good-practices.md b/contributors/devel/scalability-good-practices.md
index 5769d248..2b941a75 100644
--- a/contributors/devel/scalability-good-practices.md
+++ b/contributors/devel/scalability-good-practices.md
@@ -108,7 +108,7 @@ This looks fine-ish if you don't know that LIST are very expensive calls. Object
 
 `Informer` is our library that provides a read interface of the store - it's a read-only cache that provides you a local copy of the store that will contain only object that you're interested in (matching given selector). From it you can GET, LIST, or do whatever read operations you want. `Informer` also allows you to register functions that will be called when an object is created, modified or deleted, which is what most people want.
  
-The magic behind `Informers` is that they are populated by the WATCH, so they don't stress API server too much. Code for Informer is [here](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/tools/cache/shared_informer.go).
+The magic behind `Informers` is that they are populated by the WATCH, so they don't stress API server too much. Code for Informer is [here](https://git.k8s.io/kubernetes/staging/src/k8s.io/client-go/tools/cache/shared_informer.go).
  
 In general: use `Informers` - if we were able to rewrite most vanilla controllers to them, you'll be able to do it as well. If you don't you may dramatically increase CPU requirements of the API server which will starve it and make it too slow to meet our SLOs.
 
diff --git a/contributors/devel/strategic-merge-patch.md b/contributors/devel/strategic-merge-patch.md
index 82a2fd48..c1d69c1a 100644
--- a/contributors/devel/strategic-merge-patch.md
+++ b/contributors/devel/strategic-merge-patch.md
@@ -216,7 +216,7 @@ item that has duplicates will delete all matching items.
 
 `setElementOrder` directive provides a way to specify the order of a list.
 The relative order specified in this directive will be retained.
-Please refer to [proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cli/preserve-order-in-strategic-merge-patch.md) for more information.
+Please refer to [proposal](/contributors/design-proposals/cli/preserve-order-in-strategic-merge-patch.md) for more information.
 
 ### Syntax
 
@@ -295,7 +295,7 @@ containers:
 
 `retainKeys` directive provides a mechanism for union types to clear mutual exclusive fields.
 When this directive is present in the patch, all the fields not in this directive will be cleared.
-Please refer to [proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/add-new-patchStrategy-to-clear-fields-not-present-in-patch.md) for more information.
+Please refer to [proposal](/contributors/design-proposals/api-machinery/add-new-patchStrategy-to-clear-fields-not-present-in-patch.md) for more information.
 
 ### Syntax
 
diff --git a/contributors/devel/testing.md b/contributors/devel/testing.md
index d3adf0ed..6a7c7be6 100644
--- a/contributors/devel/testing.md
+++ b/contributors/devel/testing.md
@@ -159,7 +159,7 @@ See `go help test` and `go help testflag` for additional info.
 is [table driven testing](https://github.com/golang/go/wiki/TableDrivenTests)
   - Example: [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go)
 * Each test should create its own master, httpserver and config.
-  - Example: [TestPodUpdateActiveDeadlineSeconds](https://github.com/kubernetes/kubernetes/blob/master/test/integration/pods/pods_test.go)
+  - Example: [TestPodUpdateActiveDeadlineSeconds](https://git.k8s.io/kubernetes/test/integration/pods/pods_test.go)
 * See [coding conventions](coding-conventions.md).
 
 ### Install etcd dependency
@@ -201,7 +201,7 @@ make test-integration  # Run all integration tests.
 ```
 
 This script runs the golang tests in package
-[`test/integration`](https://github.com/kubernetes/kubernetes/tree/master/test/integration).
+[`test/integration`](https://git.k8s.io/kubernetes/test/integration).
 
 ### Run a specific integration test
 
diff --git a/contributors/devel/vagrant.md b/contributors/devel/vagrant.md
index 1ecd8157..98d150ac 100644
--- a/contributors/devel/vagrant.md
+++ b/contributors/devel/vagrant.md
@@ -227,7 +227,7 @@ my-nginx   3         3         3            3           1m
 
 We did not start any Services, hence there are none listed. But we see three
 replicas displayed properly. Check the
-[guestbook](https://github.com/kubernetes/examples/tree/master/guestbook)
+[guestbook](https://git.k8s.io/examples/guestbook)
 application to learn how to create a Service. You can already play with scaling
 the replicas with:
 
diff --git a/contributors/devel/writing-good-e2e-tests.md b/contributors/devel/writing-good-e2e-tests.md
index dd782d50..0658aad2 100644
--- a/contributors/devel/writing-good-e2e-tests.md
+++ b/contributors/devel/writing-good-e2e-tests.md
@@ -146,7 +146,7 @@ right thing.
 
 Here are a few pointers:
 
-+ [E2e Framework](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/framework.go):
++ [E2e Framework](https://git.k8s.io/kubernetes/test/e2e/framework/framework.go):
    Familiarise yourself with this test framework and how to use it.
    Amongst others, it automatically creates uniquely named namespaces
    within which your tests can run to avoid name clashes, and reliably
@@ -160,7 +160,7 @@ Here are a few pointers:
    should always use this framework.  Trying other home-grown
    approaches to avoiding name clashes and resource leaks has proven
    to be a very bad idea.
-+ [E2e utils library](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/util.go):
++ [E2e utils library](https://git.k8s.io/kubernetes/test/e2e/framework/util.go):
    This handy library provides tons of reusable code for a host of
    commonly needed test functionality, including waiting for resources
    to enter specified states, safely and consistently retrying failed
@@ -178,9 +178,9 @@ Here are a few pointers:
 + **Follow the examples of stable, well-written tests:** Some of our
    existing end-to-end tests are better written and more reliable than
    others.  A few examples of well-written tests include:
-   [Replication Controllers](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/apps/rc.go),
-   [Services](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/network/service.go),
-   [Reboot](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/lifecycle/reboot.go).
+   [Replication Controllers](https://git.k8s.io/kubernetes/test/e2e/apps/rc.go),
+   [Services](https://git.k8s.io/kubernetes/test/e2e/network/service.go),
+   [Reboot](https://git.k8s.io/kubernetes/test/e2e/lifecycle/reboot.go).
 + [Ginkgo Test Framework](https://github.com/onsi/ginkgo): This is the
    test library and runner upon which our e2e tests are built.  Before
    you write or refactor a test, read the docs and make sure that you