Use git.k8s.io for links

2 files changed, 2 insertions, 2 deletions

diff --git a/sig-scalability/README.md b/sig-scalability/README.md
index b22b82fd..24b37f9c 100644
--- a/sig-scalability/README.md
+++ b/sig-scalability/README.md
@@ -10,7 +10,7 @@ To understand how this file is generated, see https://git.k8s.io/community/gener
 
 Responsible for answering scalability related questions such as:
 What size clusters do we think that we should support with Kubernetes in the short to medium term? How performant do we think that the control system should be at scale? What resource overhead should the Kubernetes control system reasonably consume?
-For more details about our objectives please review our [Scaling And Performance Goals](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)
+For more details about our objectives please review our [Scaling And Performance Goals](https://git.k8s.io/community/sig-scalability/goals.md)
 
 ## Meetings
 * [Thursdays at 16:00 UTC](https://zoom.us/j/989573207) (bi-weekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=16:00&tz=UTC).
diff --git a/sig-scalability/provider-configs.md b/sig-scalability/provider-configs.md
index c960ad22..afe183b0 100644
--- a/sig-scalability/provider-configs.md
+++ b/sig-scalability/provider-configs.md
@@ -120,7 +120,7 @@ proposed</td>
 
 * Leader election results are non-deterministic on on a typical cluster, and a config would be best served to be configured as worst-case. Not presently known whether there are performance impacts resulting from leader election resulting in either co-location or distribution of those components.
 
-* Improving the cluster performance loading to match production deployment scenarios is critical on-going work, especially clusterloader: [https://github.com/kubernetes/perf-tests/tree/master/clusterloader](https://github.com/kubernetes/perf-tests/tree/master/clusterloader)
+* Improving the cluster performance loading to match production deployment scenarios is critical on-going work, especially clusterloader: [https://git.k8s.io/perf-tests/clusterloader](https://git.k8s.io/perf-tests/clusterloader)
 
 * Multi-zone / multi-az deployments are often used to manage large clusters, but for testing/scalability efforts the target is intentionally a single Availability Zone. This keeps greater consistency between environments that do and don’t support AZ-based deployments. Failures during scalability testing are outside the SIG charter. Protecting against network partitioning and improving total cluster availability (one of the key benefits to a multi-AZ strategy) are currently out scope for the Scalability SIG efforts.