From a5db67cf04f4d6a611422ec12722120ef24ca853 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Tue, 3 Oct 2017 21:49:37 -0700 Subject: [PATCH] Update links to avoid redirects. (#5754) --- .../cluster-administration/cluster-administration-overview.md | 2 +- docs/concepts/overview/working-with-objects/labels.md | 2 +- docs/concepts/overview/working-with-objects/names.md | 2 +- docs/getting-started-guides/scratch.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/concepts/cluster-administration/cluster-administration-overview.md b/docs/concepts/cluster-administration/cluster-administration-overview.md index 97c07725e3..ec41426044 100644 --- a/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -21,7 +21,7 @@ Before choosing a guide, here are some considerations: - **If you are designing for high-availability**, learn about configuring [clusters in multiple zones](/docs/admin/multi-cluster/). - Will you be using **a hosted Kubernetes cluster**, such as [Google Container Engine (GKE)](https://cloud.google.com/container-engine/), or **hosting your own cluster**? - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. - - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/admin/networking/) fits best. One option for custom networking is [*OpenVSwitch GRE/VxLAN networking*](/docs/admin/ovs-networking/), which uses OpenVSwitch to set up networking between pods across Kubernetes nodes. + - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. One option for custom networking is [*OpenVSwitch GRE/VxLAN networking*](/docs/admin/ovs-networking/), which uses OpenVSwitch to set up networking between pods across Kubernetes nodes. - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the latter, choose a actively-developed distro. Some distros only use binary releases, but diff --git a/docs/concepts/overview/working-with-objects/labels.md b/docs/concepts/overview/working-with-objects/labels.md index a64512cd2d..747a3bf561 100644 --- a/docs/concepts/overview/working-with-objects/labels.md +++ b/docs/concepts/overview/working-with-objects/labels.md @@ -16,7 +16,7 @@ Each object can have a set of key/value labels defined. Each Key must be unique } ``` -We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/docs/user-guide/annotations). +We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). * TOC {:toc} diff --git a/docs/concepts/overview/working-with-objects/names.md b/docs/concepts/overview/working-with-objects/names.md index 21a400a4e0..b64ad38f99 100644 --- a/docs/concepts/overview/working-with-objects/names.md +++ b/docs/concepts/overview/working-with-objects/names.md @@ -7,7 +7,7 @@ title: Names All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID. -For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/user-guide/annotations). +For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/). ## Names diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index 78ba39ef80..a5cad5c5c4 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -58,7 +58,7 @@ on how flags are set on various components. ### Network #### Network Connectivity -Kubernetes has a distinctive [networking model](/docs/admin/networking/). +Kubernetes has a distinctive [networking model](/docs/concepts/cluster-administration/networking/). Kubernetes allocates an IP address to each pod. When creating a cluster, you need to allocate a block of IPs for Kubernetes to use as Pod IPs. The simplest @@ -430,7 +430,7 @@ Each node needs to be allocated its own CIDR range for pod networking. Call this `NODE_X_POD_CIDR`. A bridge called `cbr0` needs to be created on each node. The bridge is explained -further in the [networking documentation](/docs/admin/networking/). The bridge itself +further in the [networking documentation](/docs/concepts/cluster-administration/networking/). The bridge itself needs an address from `$NODE_X_POD_CIDR` - by convention the first IP. Call this `NODE_X_BRIDGE_ADDR`. For example, if `NODE_X_POD_CIDR` is `10.0.0.0/16`, then `NODE_X_BRIDGE_ADDR` is `10.0.0.1/16`. NOTE: this retains the `/16` suffix