whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update links to avoid redirects. (#5754)

Browse Source
This commit is contained in:
Steve Perry
2017-10-03 21:49:37 -07:00
committed by GitHub
parent a7475665fa
commit a5db67cf04
4 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/cluster-administration/cluster-administration-overview.md
+1 -1
View File
@@ -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/). - **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 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. - 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)**? - 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 - 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 latter, choose a actively-developed distro. Some distros only use binary releases, but
docs/concepts/overview/working-with-objects/labels.md
+1 -1
View File
@@ -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
{:toc} {:toc}
docs/concepts/overview/working-with-objects/names.md
+1 -1
View File
@@ -7,7 +7,7 @@ title: Names
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID. 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 ## Names
docs/getting-started-guides/scratch.md
+2 -2
View File
@@ -58,7 +58,7 @@ on how flags are set on various components.
### Network ### Network
#### Network Connectivity #### 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 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 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`. Call this `NODE_X_POD_CIDR`.
A bridge called `cbr0` needs to be created on each node. The bridge is explained 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 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`, 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 then `NODE_X_BRIDGE_ADDR` is `10.0.0.1/16`. NOTE: this retains the `/16` suffix