Use relative links for k8s.io

2022-06-30 12:08:14 +08:00
parent 462d6cb583
commit 34721abcac
21 changed files with 30 additions and 29 deletions
@@ -127,7 +127,7 @@ the shared Volume is lost.
 ## {{% heading "whatsnext" %}}


-* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
+* Learn more about [patterns for composite containers](/blog/2015/06/the-distributed-system-toolkit-patterns/).

 * Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).

@@ -15,7 +15,7 @@ content_type: task

 ## Background

-As part of the [cloud provider extraction effort](https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), all cloud specific controllers must be moved out of the `kube-controller-manager`. All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`.
+As part of the [cloud provider extraction effort](/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), all cloud specific controllers must be moved out of the `kube-controller-manager`. All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`.

 Leader Migration provides a mechanism in which HA clusters can safely migrate "cloud specific" controllers between the `kube-controller-manager` and the `cloud-controller-manager` via a shared resource lock between the two components while upgrading the replicated control plane. For a single-node control plane, or if unavailability of controller managers can be tolerated during the upgrade, Leader Migration is not needed and this guide can be ignored.

@@ -11,7 +11,7 @@ weight: 20
 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
 {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version
 {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions
-when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
+when upgrading is unsupported. For more details, please visit [Version Skew Policy](/releases/version-skew-policy/).

 To see information about upgrading clusters created using older versions of kubeadm,
 please refer to following pages instead:
@@ -88,7 +88,7 @@ would provision a network resource like a Google Compute Engine persistent disk,
 an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also
 use [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)
 to set up
-[dynamic provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes).
+[dynamic provisioning](/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes).

 Here is the configuration file for the hostPath PersistentVolume:

@@ -206,7 +206,7 @@ Ready before starting Pod `N+1`.
 After the init containers complete successfully, the regular containers run.
 The MySQL Pods consist of a `mysql` container that runs the actual `mysqld`
 server, and an `xtrabackup` container that acts as a
-[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
+[sidecar](/blog/2015/06/the-distributed-system-toolkit-patterns).

 The `xtrabackup` sidecar looks at the cloned data files and determines if
 it's necessary to initialize MySQL replication on the replica.