-{% for card in page.cards %}{% if card.title %}
-
-
{{card.title}}
-
{% if card.image %}{% endif %}{{card.description}}
-
-{% endif %}{% endfor %}
-
-
-{% else %}
-
-### ERROR: You must define "cards" front-matter YAML
-{: style="color:red" }
-
-This template requires that you insert YAML at the top of your document
-that defines the "cards" you'd like to display on the page. The cards will
-render in clickable boxes.
-
-To get rid of this message and take advantage of this template, define `cards`:
-
-```yaml
----
-cards:
-- progression: no
-- card:
- title: Mean Stack
- image: /docs/meanstack/image_0.png
- description: Lorem ipsum dolor it verberum.
-- card:
- title: Guestbook + Redis
- image: /images/docs/redis.svg
- description: Lorem ipsum dolor it verberum.
-- card:
- title: Cloud Native Cassandra
- image: /images/docs/cassandra.svg
- description: Lorem ipsum dolor it verberum.
-- card:
- title: WordPress + MySQL
- image: /images/docs/wordpress.svg
- description: Lorem ipsum dolor it verberum.
----
-```
-
-**Note:** If `progression` is set to `yes` then a "Start Here!" icon will be
-placed on the first card and arrows suggesting linear reading will be overlayed
-between the other cards, telling the reader that they should explore the content
-in a certain order.
-
-{% endif %}
diff --git a/_includes/user-guide-migration-notice.md b/_includes/user-guide-migration-notice.md
index 4579619b17..366a05907c 100644
--- a/_includes/user-guide-migration-notice.md
+++ b/_includes/user-guide-migration-notice.md
@@ -4,7 +4,7 @@
The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.
diff --git a/cn/docs/concepts/overview/what-is-kubernetes.md b/cn/docs/concepts/overview/what-is-kubernetes.md
index 167a06697c..39f331bf5a 100644
--- a/cn/docs/concepts/overview/what-is-kubernetes.md
+++ b/cn/docs/concepts/overview/what-is-kubernetes.md
@@ -93,7 +93,7 @@ Kubernetes 提供了很多的功能，总会有新的场景受益于新特性。
此外，[Kubernetes 控制面 (Controll Plane)](/docs/admin/cluster-components) 是构建在相同的 [APIs](/docs/api/) 上面，开发人员和用户都可以用。用户可以编写自己的控制器， [调度器](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/scheduler.md)等等，如果这么做，根据新加的[自定义 API](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/extending-api.md) ，可以扩展当前的通用 [CLI 命令行工具](/docs/user-guide/kubectl-overview/)。
-这种 [设计](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
+这种 [设计](https://git.k8s.io/community/contributors/design-proposals/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
#### Kubernetes 不是什么:
diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md
index ba74a9a16e..39edec0533 100644
--- a/docs/admin/admission-controllers.md
+++ b/docs/admin/admission-controllers.md
@@ -205,7 +205,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota`
objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
-See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
+See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins. This is
so that quota is not prematurely incremented only for the request to be rejected later in admission control.
@@ -218,7 +218,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
-See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
+See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
### InitialResources (experimental)
@@ -227,7 +227,7 @@ then the plug-in auto-populates a compute resource request based on historical u
If there is not enough data to make a decision the Request is left unchanged.
When the plug-in sets a compute resource request, it annotates the pod with information on what compute resources it auto-populated.
-See the [InitialResouces proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/initial-resources.md) for more details.
+See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/initial-resources.md) for more details.
### NamespaceLifecycle
diff --git a/docs/admin/authorization/webhook.md b/docs/admin/authorization/webhook.md
index b89182fb6f..1ceaa7a23b 100644
--- a/docs/admin/authorization/webhook.md
+++ b/docs/admin/authorization/webhook.md
@@ -141,7 +141,7 @@ Access to other non-resource paths can be disallowed without restricting access
to the REST api.
For further documentation refer to the authorization.v1beta1 API objects and
-[webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
+[webhook.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
{% endcapture %}
diff --git a/docs/admin/bootstrap-tokens.md b/docs/admin/bootstrap-tokens.md
index 5140e68c1b..09ceaa18a1 100644
--- a/docs/admin/bootstrap-tokens.md
+++ b/docs/admin/bootstrap-tokens.md
@@ -58,7 +58,7 @@ Authorization: Bearer 07401b.f395accd246ae52d
Each valid token is backed by a secret in the `kube-system` namespace. You can
find the full design doc
-[here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bootstrap-discovery.md).
+[here](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md).
Here is what the secret looks like. Note that `base64(string)` indicates the
value should be base64 encoded. The undecoded version is provided here for
diff --git a/docs/admin/federation/index.md b/docs/admin/federation/index.md
index 4407267af6..e33d177a1a 100644
--- a/docs/admin/federation/index.md
+++ b/docs/admin/federation/index.md
@@ -385,4 +385,4 @@ if required.
## For more information
- * [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md) details use cases that motivated this work.
+ * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md) details use cases that motivated this work.
diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md
index 7a295ab91d..7fdec4a44f 100644
--- a/docs/admin/kubeadm.md
+++ b/docs/admin/kubeadm.md
@@ -23,7 +23,9 @@ following steps:
1. kubeadm generates a self-signed CA to provision identities for each component
(including nodes) in the cluster. It also generates client certificates to
- be used by various components.
+ be used by various components. If the user has provided their own CA by
+ dropping it in the cert directory (configured via `--cert-dir`, by default
+ `/etc/kubernetes/pki`), this step is skipped.
1. Outputting a kubeconfig file for the kubelet to use to connect to the API
server, as well as an additional kubeconfig file for administration.
@@ -154,6 +156,16 @@ names `..svc.cluster.local`. You can use the
update the `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` file
accordingly else DNS will not function correctly.
+**Note**: This flag has an effect (it's needed for the kube-dns Deployment
+manifest and the API Server's serving certificate) but not as you might expect,
+since you will have to modify the arguments to the kubelets in the cluster for
+it to work fully. Specifying DNS parameters using this flag only is not enough.
+Rewriting the kubelet's CLI arguments is out of scope for kubeadm as it should
+be agnostic to how you run the kubelet. However, making all kubelets in the
+cluster pick up information dynamically via the API _is_ in scope and is a
+[planned feature](https://github.com/kubernetes/kubeadm/issues/28) for upcoming
+releases.
+
- `--skip-preflight-checks`
By default, kubeadm runs a series of preflight checks to validate the system
@@ -436,7 +448,7 @@ Remember to change `proxy_ip` and add a kube master node IP address to
## Use Kubeadm with other CRI runtimes
-Since [Kubernetes 1.6 release](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#node-components-1), Kubernetes container runtimes have been transferred to using CRI by default. Currently, the build-in container runtime is Docker which is enabled by build-in `dockershim` in `kubelet`.
+Since [Kubernetes 1.6 release](https://git.k8s.io/kubernetes/CHANGELOG.md#node-components-1), Kubernetes container runtimes have been transferred to using CRI by default. Currently, the build-in container runtime is Docker which is enabled by build-in `dockershim` in `kubelet`.
Using other CRI based runtimes with kubeadm is very simple, and currently supported runtimes are:
@@ -459,11 +471,28 @@ EOF
Now `kubelet` is ready to use the specified CRI runtime, and you can continue with `kubeadm init` and `kubeadm join` workflow to deploy Kubernetes cluster.
+## Using custom certificates
+
+By default kubeadm will generate all the certificates needed for a cluster to run.
+You can override this behaviour by providing your own certificates.
+
+To do so, you must place them in whatever directory is specified by the
+`--cert-dir` flag or `CertificatesDir` configuration file key. By default this
+is `/etc/kubernetes/pki`.
+
+If a given certificate and private key pair both exist, kubeadm will skip the
+generation step and those files will be validated and used for the prescribed
+use-case.
+
+This means you can, for example, prepopulate `/etc/kubernetes/pki/ca.crt`
+and `/etc/kubernetes/pki/ca.key` with an existing CA, which then will be used
+for signing the rest of the certs.
+
## Releases and release notes
If you already have kubeadm installed and want to upgrade, run `apt-get update
&& apt-get upgrade` or `yum update` to get the latest version of kubeadm.
Refer to the
-[CHANGELOG.md](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md)
+[CHANGELOG.md](https://git.k8s.io/kubeadm/CHANGELOG.md)
for more information.
diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md
index 9da312344d..486ceab71b 100644
--- a/docs/admin/kubelet.md
+++ b/docs/admin/kubelet.md
@@ -66,7 +66,7 @@ kubelet
--enable-custom-metrics Support for gathering custom metrics.
--enable-debugging-handlers Enables server endpoints for log collection and local running of containers and commands (default true)
--enable-server Enable the Kubelet's server (default true)
- --enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptible options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md for more details. [default='pods'] (default [pods])
+ --enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptible options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. [default='pods'] (default [pods])
--event-burst int32 Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10)
--event-qps int32 If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
--eviction-hard string A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default "memory.available<100Mi")
@@ -76,7 +76,7 @@ kubelet
--eviction-soft string A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction.
--eviction-soft-grace-period string A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction.
--exit-on-lock-contention Whether kubelet should exit upon lock-file contention.
- --experimental-allocatable-ignore-eviction When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md for more details. [default=false]
+ --experimental-allocatable-ignore-eviction When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. [default=false]
--experimental-allowed-unsafe-sysctls stringSlice Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk.
--experimental-bootstrap-kubeconfig string Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir.
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount
diff --git a/docs/admin/multiple-zones.md b/docs/admin/multiple-zones.md
index adad4316d3..7c2f522789 100644
--- a/docs/admin/multiple-zones.md
+++ b/docs/admin/multiple-zones.md
@@ -11,7 +11,7 @@ title: Running in Multiple Zones
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-nickname ["Ubernetes"](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)).
+nickname ["Ubernetes"](https://git.k8s.io/community/contributors/design-proposals/federation.md)).
Full Cluster Federation allows combining separate
Kubernetes clusters running in different regions or cloud providers
(or on-premise data centers). However, many
diff --git a/docs/admin/node-conformance.md b/docs/admin/node-conformance.md
index 6e245bdab7..79c3e50946 100644
--- a/docs/admin/node-conformance.md
+++ b/docs/admin/node-conformance.md
@@ -84,7 +84,7 @@ sudo docker run -it --rm --privileged --net=host \
gcr.io/google_containers/node-test:0.2
```
-Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md).
+Node conformance test is a containerized version of [node e2e test](https://git.k8s.io/community/contributors/devel/e2e-node-tests.md).
By default, it runs all conformance tests.
Theoretically, you can run any node e2e test if you configure the container and
diff --git a/docs/api-reference/v1.6/index.html b/docs/api-reference/v1.6/index.html
index 1ce8eb957c..340a13712b 100644
--- a/docs/api-reference/v1.6/index.html
+++ b/docs/api-reference/v1.6/index.html
@@ -7918,7 +7918,7 @@ Appears In Pod
diff --git a/docs/concepts/architecture/nodes.md b/docs/concepts/architecture/nodes.md
index 4b2da71843..5e86455b9f 100644
--- a/docs/concepts/architecture/nodes.md
+++ b/docs/concepts/architecture/nodes.md
@@ -19,7 +19,7 @@ A `node` is a worker machine in Kubernetes, previously known as a `minion`. A no
may be a VM or physical machine, depending on the cluster. Each node has
the services necessary to run [pods](/docs/user-guide/pods) and is managed by the master
components. The services on a node include Docker, kubelet and kube-proxy. See
-[The Kubernetes Node](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/architecture.md#the-kubernetes-node) section in the
+[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture.md#the-kubernetes-node) section in the
architecture design doc for more details.
## Node Status
diff --git a/docs/concepts/cluster-administration/addons.md b/docs/concepts/cluster-administration/addons.md
index 0aaaf7c82d..b8c492679c 100644
--- a/docs/concepts/cluster-administration/addons.md
+++ b/docs/concepts/cluster-administration/addons.md
@@ -31,6 +31,6 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
## Legacy Add-ons
-There are several other add-ons documented in the deprecated [cluster/addons](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons) directory.
+There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory.
Well-maintained ones should be linked to here. PRs welcome!
diff --git a/docs/concepts/cluster-administration/federation.md b/docs/concepts/cluster-administration/federation.md
index a60099c65f..5a698c7fb7 100644
--- a/docs/concepts/cluster-administration/federation.md
+++ b/docs/concepts/cluster-administration/federation.md
@@ -44,7 +44,7 @@ why you might want multiple clusters are:
See [Multi cluster guide](/docs/admin/multi-cluster) for details.
* Scalability: There are scalability limits to a single kubernetes cluster (this
should not be the case for most users. For more details:
- [Kubernetes Scaling and Performance Goals](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)).
+ [Kubernetes Scaling and Performance Goals](https://git.k8s.io/community/sig-scalability/goals.md)).
* [Hybrid cloud](###hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or
on-premises data centers.
diff --git a/docs/concepts/cluster-administration/logging.md b/docs/concepts/cluster-administration/logging.md
index 283a2c3812..7a0733d48c 100644
--- a/docs/concepts/cluster-administration/logging.md
+++ b/docs/concepts/cluster-administration/logging.md
@@ -101,7 +101,7 @@ systemd is not present, they write to `.log` files in the `/var/log` directory.
System components inside containers always write to the `/var/log` directory,
bypassing the default logging mechanism. They use the [glog][glog]
logging library. You can find the conventions for logging severity for those
-components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
+components in the [development docs on logging](https://git.k8s.io/community/contributors/devel/logging.md).
Similarly to the container logs, system component logs in the `/var/log`
directory should be rotated. In Kubernetes clusters brought up by
diff --git a/docs/concepts/cluster-administration/network-plugins.md b/docs/concepts/cluster-administration/network-plugins.md
index 0f6a8b2426..d36a6c7f42 100644
--- a/docs/concepts/cluster-administration/network-plugins.md
+++ b/docs/concepts/cluster-administration/network-plugins.md
@@ -38,7 +38,7 @@ The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command
If there are multiple CNI configuration files in the directory, the first one in lexicographic order of file name is used.
-In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/cni/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
+In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
Limitation: Due to [#31307](https://github.com/kubernetes/kubernetes/issues/31307), `HostPort` won't work with CNI networking plugin at the moment. That means all `hostPort` attribute in pod would be simply ignored.
diff --git a/docs/concepts/cluster-administration/networking.md b/docs/concepts/cluster-administration/networking.md
index ff7af7942b..c65f3ca158 100644
--- a/docs/concepts/cluster-administration/networking.md
+++ b/docs/concepts/cluster-administration/networking.md
@@ -225,7 +225,7 @@ to run, and in both cases, the network provides one IP address per pod - as is s
### CNI-Genie from Huawei
-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultanously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultanously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://git.k8s.io/kubernetes.github.io/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
@@ -233,4 +233,4 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu
The early design of the networking model and its rationale, and some future
plans are described in more detail in the [networking design
-document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/networking.md).
+document](https://git.k8s.io/community/contributors/design-proposals/networking.md).
diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md
index 495bd4665a..eb86ba0260 100644
--- a/docs/concepts/configuration/assign-pod-node.md
+++ b/docs/concepts/configuration/assign-pod-node.md
@@ -43,7 +43,7 @@ Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the o
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
-Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
+Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://git.k8s.io/community/contributors/design-proposals/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label.
@@ -143,7 +143,7 @@ If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` types
If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`, then the pod can be scheduled onto a node **only if all** `matchExpressions` can be satisfied.
For more information on node affinity, see the design doc
-[here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/nodeaffinity.md).
+[here](https://git.k8s.io/community/contributors/design-proposals/nodeaffinity.md).
### Inter-pod affinity and anti-affinity (beta feature)
@@ -184,7 +184,7 @@ value V that is running a pod that has a label with key "security" and value "S1
rule says that the pod prefers to not schedule onto a node if that node is already running a pod with label
having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
it would mean that the pod cannot schedule onto a node if that node is in the same zone as a pod with
-label having key "security" and value "S2".) See the [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/podaffinity.md).
+label having key "security" and value "S2".) See the [design doc](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
@@ -208,7 +208,7 @@ All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExe
must be satisfied for the pod to schedule onto a node.
For more information on inter-pod affinity/anti-affinity, see the design doc
-[here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/podaffinity.md).
+[here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
## Taints and tolerations (beta feature)
@@ -432,7 +432,7 @@ These automatically-added tolerations ensure that
the default pod behavior of remaining bound for 5 minutes after one of these
problems is detected is maintained.
The two default tolerations are added by the [DefaultTolerationSeconds
-admission controller](https://github.com/kubernetes/kubernetes/tree/master/plugin/pkg/admission/defaulttolerationseconds).
+admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
[DaemonSet](https://kubernetes.io/docs/admin/daemons/) pods are created with
`NoExecute` tolerations for `node.alpha.kubernetes.io/unreachable` and `node.alpha.kubernetes.io/notReady`
diff --git a/docs/concepts/configuration/manage-compute-resources-container.md b/docs/concepts/configuration/manage-compute-resources-container.md
index c5615b634c..2858dbd726 100644
--- a/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/docs/concepts/configuration/manage-compute-resources-container.md
@@ -13,7 +13,7 @@ requests specified, the scheduler can make better decisions about which nodes to
place Pods on. And when Containers have their limits specified, contention for
resources on a node can be handled in a specified manner. For more details about
the difference between requests and limits, see
-[Resource QoS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md).
+[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md).
{% endcapture %}
@@ -243,7 +243,7 @@ The amount of resources available to Pods is less than the node capacity, becaus
system daemons use a portion of the available resources. The `allocatable` field
[NodeStatus](/docs/resources-reference/v1.6/#nodestatus-v1-core)
gives the amount of resources that are available to Pods. For more information, see
-[Node Allocatable Resources](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md).
+[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md).
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
to limit the total amount of resources that can be consumed. If used in conjunction
diff --git a/docs/concepts/configuration/secret.md b/docs/concepts/configuration/secret.md
index 062eb6d21f..8cc6e34e14 100644
--- a/docs/concepts/configuration/secret.md
+++ b/docs/concepts/configuration/secret.md
@@ -10,7 +10,7 @@ redirect_from:
Objects of type `secret` are intended to hold sensitive information, such as
passwords, OAuth tokens, and ssh keys. Putting this information in a `secret`
is safer and more flexible than putting it verbatim in a `pod` definition or in
-a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/secrets.md) for more information.
+a docker image. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/secrets.md) for more information.
* TOC
{:toc}
@@ -121,7 +121,7 @@ data:
```
The data field is a map. Its keys must match
-[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/design/identifiers.md), except that leading dots are also
+[`DNS_SUBDOMAIN`](https://git.k8s.io/community/contributors/design-proposals/identifiers.md), except that leading dots are also
allowed. The values are arbitrary data, encoded using base64.
Create the secret using [`kubectl create`](/docs/user-guide/kubectl/v1.6/#create):
diff --git a/docs/concepts/example-concept-template.md b/docs/concepts/example-concept-template.md
index c36fea402e..6fbd85751c 100644
--- a/docs/concepts/example-concept-template.md
+++ b/docs/concepts/example-concept-template.md
@@ -1,14 +1,19 @@
---
title: Example Concept Template
+assignees:
+- chenopis
---
{% capture overview %}
+
**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
This page explains ...
+
{% endcapture %}
{% capture body %}
+
## Understanding ...
Kubernetes provides ...
@@ -16,13 +21,16 @@ Kubernetes provides ...
## Using ...
To use ...
+
{% endcapture %}
{% capture whatsnext %}
+
**[Optional Section]**
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
+
{% endcapture %}
{% include templates/concept.md %}
\ No newline at end of file
diff --git a/docs/concepts/overview/kubernetes-api.md b/docs/concepts/overview/kubernetes-api.md
index 9faf22ab82..2f3e0a009d 100644
--- a/docs/concepts/overview/kubernetes-api.md
+++ b/docs/concepts/overview/kubernetes-api.md
@@ -7,7 +7,7 @@ redirect_from:
- "/docs/api.html"
---
-Overall API conventions are described in the [API conventions doc](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md).
+Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/api-conventions.md).
API endpoints, resource types and samples are described in [API Reference](/docs/reference).
@@ -23,13 +23,13 @@ Kubernetes itself is decomposed into multiple components, which interact through
In our experience, any system that is successful needs to grow and change as new use cases emerge or existing ones change. Therefore, we expect the Kubernetes API to continuously change and grow. However, we intend to not break compatibility with existing clients, for an extended period of time. In general, new API resources and new resource fields can be expected to be added frequently. Elimination of resources or fields will require following a deprecation process. The precise deprecation policy for eliminating features is TBD, but once we reach our 1.0 milestone, there will be a specific policy.
-What constitutes a compatible change and how to change the API are detailed by the [API change document](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api_changes.md).
+What constitutes a compatible change and how to change the API are detailed by the [API change document](https://git.k8s.io/community/contributors/devel/api_changes.md).
## OpenAPI and Swagger definitions
Complete API details are documented using [Swagger v1.2](http://swagger.io/) and [OpenAPI](https://www.openapis.org/). The Kubernetes apiserver (aka "master") exposes an API that can be used to retrieve the Swagger v1.2 Kubernetes API spec located at `/swaggerapi`. You can also enable a UI to browse the API documentation at `/swagger-ui` by passing the `--enable-swagger-ui=true` flag to apiserver.
-Starting with kubernetes 1.4, OpenAPI spec is also available at [`/swagger.json`](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json). While we are transitioning from Swagger v1.2 to OpenAPI (aka Swagger v2.0), some of the tools such as kubectl and swagger-ui are still using v1.2 spec. OpenAPI spec is in Beta as of Kubernetes 1.5.
+Starting with kubernetes 1.4, OpenAPI spec is also available at [`/swagger.json`](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json). While we are transitioning from Swagger v1.2 to OpenAPI (aka Swagger v2.0), some of the tools such as kubectl and swagger-ui are still using v1.2 spec. OpenAPI spec is in Beta as of Kubernetes 1.5.
Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
@@ -42,12 +42,12 @@ multiple API versions, each at a different API path, such as `/api/v1` or
We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-lifed and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
Note that API versioning and Software versioning are only indirectly related. The [API and release
-versioning proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/versioning.md) describes the relationship between API versioning and
+versioning proposal](https://git.k8s.io/community/contributors/design-proposals/versioning.md) describes the relationship between API versioning and
software versioning.
Different API versions imply different levels of stability and support. The criteria for each level are described
-in more detail in the [API Changes documentation](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api_changes.md#alpha-beta-and-stable-versions). They are summarized here:
+in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions). They are summarized here:
- Alpha level:
- The version names contain `alpha` (e.g. `v1alpha1`).
@@ -71,7 +71,7 @@ in more detail in the [API Changes documentation](https://github.com/kubernetes/
## API groups
-To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-group.md).
+To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-group.md).
The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
Currently there are several API groups in use:
@@ -83,10 +83,10 @@ Currently there are several API groups in use:
There are two supported paths to extending the API.
-1. [Third Party Resources](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/extending-api.md)
+1. [Third Party Resources](https://git.k8s.io/community/contributors/design-proposals/extending-api.md)
are for users with very basic CRUD needs.
1. Coming soon: users needing the full set of Kubernetes API semantics can implement their own apiserver
- and use the [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/aggregated-api-servers.md)
+ and use the [aggregator](https://git.k8s.io/community/contributors/design-proposals/aggregated-api-servers.md)
to make it seamless for clients.
diff --git a/docs/concepts/overview/what-is-kubernetes.md b/docs/concepts/overview/what-is-kubernetes.md
index 6285d9bffe..06fe6f6517 100644
--- a/docs/concepts/overview/what-is-kubernetes.md
+++ b/docs/concepts/overview/what-is-kubernetes.md
@@ -93,7 +93,7 @@ Even though Kubernetes provides a lot of functionality, there are always new sce
[Labels](/docs/concepts/overview/working-with-objects/labels/) empower users to organize their resources however they please. [Annotations](/docs/concepts/overview/working-with-objects/annotations/) enable users to decorate resources with custom information to facilitate their workflows and provide an easy way for management tools to checkpoint state.
-Additionally, the [Kubernetes control plane](/docs/concepts/overview/components/) is built upon the same [APIs](/docs/reference/api-overview/) that are available to developers and users. Users can write their own controllers, such as [schedulers](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/scheduler.md), with [their own APIs](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/extending-api.md) that can be targeted by a general-purpose [command-line tool](/docs/user-guide/kubectl-overview/).
+Additionally, the [Kubernetes control plane](/docs/concepts/overview/components/) is built upon the same [APIs](/docs/reference/api-overview/) that are available to developers and users. Users can write their own controllers, such as [schedulers](https://git.k8s.io/community/contributors/devel/scheduler.md), with [their own APIs](https://git.k8s.io/community/contributors/design-proposals/extending-api.md) that can be targeted by a general-purpose [command-line tool](/docs/user-guide/kubectl-overview/).
This [design](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/principles.md) has enabled a number of other systems to build atop Kubernetes.
diff --git a/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 489e0c4fa4..96629678dd 100644
--- a/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -21,7 +21,7 @@ This page explains how Kubernetes objects are represented in the Kubernetes API,
A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's **desired state**.
-To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you; you can also use the Kubernetes API directly in your own programs. Kubernetes currently provides a `golang` [client library](https://github.com/kubernetes/client-go) for this purpose, and other language libraries (such as [Python](https://github.com/kubernetes-incubator/client-python)) are being developed.
+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you; you can also use the Kubernetes API directly in your own programs. Kubernetes currently provides a `golang` [client library](https://github.com/kubernetes/client-go) for this purpose, and other language libraries (such as [Python](https://github.com/kubernetes-incubator/client-python)) are being developed.
### Object Spec and Status
@@ -30,7 +30,7 @@ Every Kubernetes object includes two nested object fields that govern the object
For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance.
-For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md).
+For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md).
### Describing a Kubernetes Object
diff --git a/docs/concepts/overview/working-with-objects/names.md b/docs/concepts/overview/working-with-objects/names.md
index fd02680f0e..a213435795 100644
--- a/docs/concepts/overview/working-with-objects/names.md
+++ b/docs/concepts/overview/working-with-objects/names.md
@@ -14,7 +14,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user
## Names
-Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name. Names are used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions. See the [identifiers design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md) for the precise syntax rules for names.
+Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name. Names are used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions. See the [identifiers design doc](https://git.k8s.io/community/contributors/design-proposals/identifiers.md) for the precise syntax rules for names.
## UIDs
diff --git a/docs/concepts/policy/pod-security-policy.md b/docs/concepts/policy/pod-security-policy.md
index c9b22cce03..49e4dbf0bf 100644
--- a/docs/concepts/policy/pod-security-policy.md
+++ b/docs/concepts/policy/pod-security-policy.md
@@ -11,7 +11,7 @@ Objects of type `PodSecurityPolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container.
-See [PodSecurityPolicy proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/security-context-constraints.md) for more information.
+See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) for more information.
* TOC
{:toc}
@@ -203,4 +203,4 @@ following
In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. Access to different PodSecurityPolicy objects can be controlled via authorization. To limit access to PodSecurityPolicy objects for pods created via a Deployment, ReplicaSet, etc, the [Controller Manager](/docs/admin/kube-controller-manager/) must be run against the secured API port, and must not have superuser permissions.
-PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. For more details, see the [PodSecurityPolicy RBAC example](https://github.com/kubernetes/kubernetes/blob/master/examples/podsecuritypolicy/rbac/README.md) of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly.
+PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. For more details, see the [PodSecurityPolicy RBAC example](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md) of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly.
diff --git a/docs/concepts/policy/resource-quotas.md b/docs/concepts/policy/resource-quotas.md
index 0367e0b93b..cc2daa5c5e 100644
--- a/docs/concepts/policy/resource-quotas.md
+++ b/docs/concepts/policy/resource-quotas.md
@@ -240,4 +240,4 @@ See a [detailed example for how to use resource quota](/docs/tasks/configure-pod
## Read More
-See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) for more information.
+See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) for more information.
diff --git a/docs/concepts/services-networking/dns-pod-service.md b/docs/concepts/services-networking/dns-pod-service.md
index adc5167b81..11243f930c 100644
--- a/docs/concepts/services-networking/dns-pod-service.md
+++ b/docs/concepts/services-networking/dns-pod-service.md
@@ -325,7 +325,7 @@ kube-dns 10.180.3.17:53,10.180.3.17:53 1h
If you do not see the endpoints, see endpoints section in the [debugging services documentation](/docs/tasks/debug-application-cluster/debug-service/).
-For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/kubernetes/tree/master/examples/cluster-dns) in the Kubernetes GitHub repository.
+For additional Kubernetes DNS examples, see the [cluster-dns examples](https://git.k8s.io/kubernetes/examples/cluster-dns) in the Kubernetes GitHub repository.
## Kubernetes Federation (Multiple Zone support)
diff --git a/docs/concepts/services-networking/ingress.md b/docs/concepts/services-networking/ingress.md
index facf20155b..0d12584e26 100644
--- a/docs/concepts/services-networking/ingress.md
+++ b/docs/concepts/services-networking/ingress.md
@@ -47,9 +47,9 @@ It can be configured to give services externally-reachable urls, load balance tr
Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
-GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/ingress/tree/master/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc).
+GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress/controllers/nginx#running-multiple-ingress-controllers) and [here](https://git.k8s.io/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc).
-Make sure you review the [beta limitations](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/ingress/tree/master/controllers) as a pod.
+Make sure you review the [beta limitations](https://git.k8s.io/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://git.k8s.io/ingress/controllers) as a pod.
## The Ingress Resource
@@ -74,7 +74,7 @@ spec:
__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](/docs/user-guide/deploying-applications), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
-__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
+__Lines 5-7__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
__Lines 8-9__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
@@ -84,11 +84,11 @@ __Global Parameters__: For the sake of simplicity the example Ingress has no glo
## Ingress controllers
-In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. You need to choose the ingress controller implementation that is the best fit for your cluster, or implement one. Examples and instructions can be found [here](https://github.com/kubernetes/ingress/tree/master/controllers).
+In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. You need to choose the ingress controller implementation that is the best fit for your cluster, or implement one. Examples and instructions can be found [here](https://git.k8s.io/ingress/controllers).
## Before you begin
-The following document describes a set of cross platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. The docs for the GCE and nginx controllers are [here](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md) and [here](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md) respectively. **Make sure you review controller specific docs so you understand the caveats of each one**.
+The following document describes a set of cross platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. The docs for the GCE and nginx controllers are [here](https://git.k8s.io/ingress/controllers/gce/README.md) and [here](https://git.k8s.io/ingress/controllers/nginx/README.md) respectively. **Make sure you review controller specific docs so you understand the caveats of each one**.
## Types of Ingress
@@ -217,13 +217,13 @@ spec:
servicePort: 80
```
-Note that there is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on [nginx](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md#https), [GCE](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md#tls), or any other platform specific Ingress controller to understand how TLS works in your environment.
+Note that there is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on [nginx](https://git.k8s.io/ingress/controllers/nginx/README.md#https), [GCE](https://git.k8s.io/ingress/controllers/gce/README.md#tls), or any other platform specific Ingress controller to understand how TLS works in your environment.
### Loadbalancing
-An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource.
+An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource.
-It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md), [GCE](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md#health-checks)).
+It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://git.k8s.io/ingress/controllers/nginx/README.md), [GCE](https://git.k8s.io/ingress/controllers/gce/README.md#health-checks)).
## Updating an Ingress
@@ -293,5 +293,5 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Use [Service.Type=LoadBalancer](/docs/user-guide/services/#type-loadbalancer)
* Use [Service.Type=NodePort](/docs/user-guide/services/#type-nodeport)
-* Use a [Port Proxy](https://github.com/kubernetes/contrib/tree/master/for-demos/proxy-to-service)
-* Deploy the [Service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). This allows you to share a single IP among multiple Services and achieve more advanced loadbalancing through Service Annotations.
+* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
+* Deploy the [Service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). This allows you to share a single IP among multiple Services and achieve more advanced loadbalancing through Service Annotations.
diff --git a/docs/concepts/services-networking/network-policies.md b/docs/concepts/services-networking/network-policies.md
index 0e2038489a..77c9c326a1 100644
--- a/docs/concepts/services-networking/network-policies.md
+++ b/docs/concepts/services-networking/network-policies.md
@@ -85,7 +85,7 @@ spec:
__Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy` needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](/docs/user-guide/simple-yaml), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
-__spec__: `NetworkPolicy` [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
+__spec__: `NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
__podSelector__: Each `NetworkPolicy` includes a `podSelector` which selects the grouping of pods to which the policy applies. Since `NetworkPolicy` currently only supports definining `ingress` rules, this `podSelector` essentially defines the "destination pods" for the policy. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace.
diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md
index e7996a7bd0..1740d03127 100644
--- a/docs/concepts/storage/persistent-volumes.md
+++ b/docs/concepts/storage/persistent-volumes.md
@@ -151,7 +151,7 @@ Each PV contains a spec and status, which is the specification and status of the
### Capacity
-Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resources.md) to understand the units expected by `capacity`.
+Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/resources.md) to understand the units expected by `capacity`.
Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc.
@@ -304,7 +304,7 @@ Claims use the same conventions as volumes when requesting storage with specific
### Resources
-Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resources.md) applies to both volumes and claims.
+Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/community/contributors/design-proposals/resources.md) applies to both volumes and claims.
### Selector
@@ -435,7 +435,7 @@ for provisioning PVs. This field must be specified.
You are not restricted to specifying the "internal" provisioners
listed here (whose names are prefixed with "kubernetes.io" and shipped
alongside Kubernetes). You can also run and specify external provisioners,
-which are independent programs that follow a [specification](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-provisioning.md)
+which are independent programs that follow a [specification](https://git.k8s.io/community/contributors/design-proposals/volume-provisioning.md)
defined by Kubernetes. Authors of external provisioners have full discretion
over where their code lives, how the provisioner is shipped, how it needs to be
run, what volume plugin it uses (including Flex), etc. The repository [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage)
@@ -447,6 +447,14 @@ can be used. Some external provisioners are listed under the repository [kuberne
There are also cases when 3rd party storage vendors provide their own external
provisioner.
+### Reclaim Policy
+Persistent Volumes that are dynamically created by a storage class will have a reclaim
+policy of `delete`. If that is not desired, the only current option is to edit the
+PV after it is created.
+
+Persistent Volumes that are created manually and managed via a storage class will have
+whatever reclaim policy they were assigned at creation.
+
### Parameters
Storage classes have parameters that describe volumes belonging to the storage
class. Different parameters may be accepted depending on the `provisioner`. For
@@ -519,7 +527,7 @@ parameters:
```
$ kubectl create secret generic heketi-secret --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' --namespace=default
```
- Example of a secret can be found in [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/kubernetes/blob/master/examples/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
+ Example of a secret can be found in [glusterfs-provisioning-secret.yaml](https://git.k8s.io/kubernetes/examples/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster which will be used by Heketi when provisioning the volume. It can also be a list of clusterids, for ex:
"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397". This is an optional parameter.
* `gidMin`, `gidMax` : The minimum and maximum value of GID range for the storage class. A unique value (GID) in this range ( gidMin-gidMax ) will be used for dynamically provisioned volumes. These are optional values. If not specified, the volume will be provisioned with a value between 2000-2147483647 which are defaults for gidMin and gidMax respectively.
@@ -614,7 +622,7 @@ parameters:
vSphere Infrastructure(VI) administrator can specify storage requirements for applications in terms of storage capabilities while creating a storage class inside Kubernetes. Please note that while creating a StorageClass, administrator should specify storage capability names used in the table above as these names might differ from the ones used by VSAN. For example - Number of disk stripes per object is referred to as stripeWidth in VSAN documentation however vSphere Cloud Provider uses a friendly name diskStripes.
-You can see [vSphere example](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/vsphere) for more details.
+You can see [vSphere example](https://git.k8s.io/kubernetes/examples/volumes/vsphere) for more details.
#### Ceph RBD
diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md
index bc6b52c5cf..c3259f2179 100644
--- a/docs/concepts/storage/volumes.md
+++ b/docs/concepts/storage/volumes.md
@@ -616,7 +616,7 @@ spec:
volumePath: "[DatastoreName] volumes/myDisk"
fsType: ext4
```
-More examples can be found [here](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/vsphere).
+More examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes/vsphere).
### Quobyte
diff --git a/docs/concepts/workloads/controllers/cron-jobs.md b/docs/concepts/workloads/controllers/cron-jobs.md
index e823dfb09a..f50179e638 100644
--- a/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/docs/concepts/workloads/controllers/cron-jobs.md
@@ -42,8 +42,6 @@ with batch/v2alpha1 API turned on by passing `--runtime-config=batch/v2alpha1=tr
the API server (see [Turn on or off an API version for your cluster](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
for more).
-Beginning with 1.6 series Cron Jobs are enabled by default, but note that you can not use Cron Jobs on a hosted Kubernetes provider that has disabled alpha resources.
-
## Creating a Cron Job
Here is an example Cron Job. Every minute, it runs a simple job to print current time and then say
@@ -154,7 +152,7 @@ information about working with config files, see [deploying applications](/docs/
[configuring containers](/docs/user-guide/configuring-containers), and
[using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
-A cron job also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
+A cron job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
**Note:** All modifications to a cron job, especially its `.spec`, will be applied only to the next run.
diff --git a/docs/concepts/workloads/controllers/daemonset.md b/docs/concepts/workloads/controllers/daemonset.md
index da894a3ae8..00bd7951a6 100644
--- a/docs/concepts/workloads/controllers/daemonset.md
+++ b/docs/concepts/workloads/controllers/daemonset.md
@@ -35,7 +35,7 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and
general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
[configuring containers](/docs/user-guide/configuring-containers/), and [working with resources](/docs/concepts/tools/kubectl/object-management-overview/) documents.
-A DaemonSet also needs a [`.spec`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) section.
+A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) section.
### Pod Template
diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md
index db77c6b29a..1d07eba5cd 100644
--- a/docs/concepts/workloads/controllers/deployment.md
+++ b/docs/concepts/workloads/controllers/deployment.md
@@ -100,12 +100,22 @@ nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app
The created ReplicaSet will ensure that there are three nginx Pods at all times.
-**Note:** You must specify appropriate selector and pod template labels of a Deployment (in this case,
-`app = nginx`), i.e. don't overlap with other controllers (including Deployments, ReplicaSets,
-ReplicationControllers, etc.) Kubernetes won't stop you from doing that, and if you end up with multiple
-controllers that have overlapping selectors, those controllers will fight with each other and won't behave
+**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
+`app = nginx`), i.e. don't overlap with other controllers (including other Deployments, ReplicaSets,
+StatefulSets, etc.). Kubernetes won't stop you from doing that, and if you end up with multiple
+controllers that have overlapping selectors, those controllers may fight with each other and won't behave
correctly.
+### Pod-template-hash label
+
+**Note:** This label is not meant to be mutated by users!
+
+Note the pod-template-hash label in the example output in the pod labels above. pod-template-hash is added by the
+Deployment controller in every ReplicaSet that a Deployment creates or adopts. Its purpose is so that children
+ReplicaSets of a Deployment will not overlap among them. It is computed by hashing the PodTemplate of the ReplicaSet
+and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels,
+and in any existing Pods that the ReplicaSet may have.
+
## Updating a Deployment
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`)
@@ -638,7 +648,7 @@ attributes to the Deployment's `status.conditions`:
* Status=False
* Reason=ProgressDeadlineExceeded
-See the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
+See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
@@ -765,7 +775,7 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a
For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
configuring containers, and [using kubectl to manage resources](/docs/tutorials/object-management-kubectl/object-management/) documents.
-A Deployment also needs a [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status).
+A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
### Pod Template
diff --git a/docs/concepts/workloads/controllers/garbage-collection.md b/docs/concepts/workloads/controllers/garbage-collection.md
index 08acfe8052..e5e1f32484 100644
--- a/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/docs/concepts/workloads/controllers/garbage-collection.md
@@ -167,9 +167,9 @@ kubectl delete replicaset my-repset --cascade=false
{% capture whatsnext %}
-[Design Doc 1](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/garbage-collection.md)
+[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/garbage-collection.md)
-[Design Doc 2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/synchronous-garbage-collection.md)
+[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/synchronous-garbage-collection.md)
{% endcapture %}
diff --git a/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/docs/concepts/workloads/controllers/jobs-run-to-completion.md
index 2bc26940f7..fab8192322 100644
--- a/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -86,7 +86,7 @@ As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `meta
general information about working with config files, see [here](/docs/user-guide/simple-yaml),
[here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
-A Job also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
+A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
### Pod Template
@@ -266,7 +266,7 @@ The pattern names are also links to examples and more detailed description.
| Single Job with Static Work Assignment | ✓ | | ✓ | |
When you specify completions with `.spec.completions`, each Pod created by the Job controller
-has an identical [`spec`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status). This means that
+has an identical [`spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status). This means that
all pods will have the same command line and the same
image, the same volumes, and (almost) the same environment variables. These patterns
are different ways to arrange for pods to work on different things.
diff --git a/docs/concepts/workloads/controllers/replicationcontroller.md b/docs/concepts/workloads/controllers/replicationcontroller.md
index 288eeeaffb..6df56ab58a 100644
--- a/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -90,7 +90,7 @@ As with all other Kubernetes config, a ReplicationController needs `apiVersion`,
general information about working with config files, see [here](/docs/user-guide/simple-yaml/),
[here](/docs/user-guide/configuring-containers/), and [here](/docs/concepts/tools/kubectl/object-management-overview/).
-A ReplicationController also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
+A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
### Pod Template
diff --git a/docs/concepts/workloads/pods/pod-lifecycle.md b/docs/concepts/workloads/pods/pod-lifecycle.md
index a9ce4a8a76..ea478e377d 100644
--- a/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -66,7 +66,7 @@ and Unknown.
A [Probe](/docs/resources-reference/v1.6/#probe-v1-core) is a diagnostic
performed periodically by the [kubelet](/docs/admin/kubelet/)
on a Container. To perform a diagnostic,
-the kublet calls a
+the kubelet calls a
[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
the Container. There are three types of handlers:
diff --git a/docs/getting-started-guides/alternatives.md b/docs/getting-started-guides/alternatives.md
index 26d48c9c76..1eca7819cc 100644
--- a/docs/getting-started-guides/alternatives.md
+++ b/docs/getting-started-guides/alternatives.md
@@ -6,5 +6,5 @@ title: Deprecated Alternatives
# *Stop. These guides are superseded by [Minikube](../minikube/). They are only listed here for completeness.*
-* [Using Vagrant](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/local-cluster/vagrant.md)
-* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/local-cluster/local.md)
\ No newline at end of file
+* [Using Vagrant](https://git.k8s.io/community/contributors/devel/local-cluster/vagrant.md)
+* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://git.k8s.io/community/contributors/devel/local-cluster/local.md)
\ No newline at end of file
diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md
index bd3c562cf6..4a1eada797 100644
--- a/docs/getting-started-guides/clc.md
+++ b/docs/getting-started-guides/clc.md
@@ -252,7 +252,7 @@ kubectl cluster-info
### Accessing the cluster programmatically
-It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice.
+It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice.
To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master api server via https:
diff --git a/docs/getting-started-guides/kubespray.md b/docs/getting-started-guides/kubespray.md
index 404176aa29..17c1e446bc 100644
--- a/docs/getting-started-guides/kubespray.md
+++ b/docs/getting-started-guides/kubespray.md
@@ -32,7 +32,7 @@ to [kubeadm](../kubeadm) and [kops](../kops).
* You must have cloud instances or baremetal nodes running for your future Kubernetes cluster.
A way to achieve that is to use the
- [kargo-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md).
+ [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md).
* Or provision baremetal hosts with a tool-of-your-choice or launch cloud instances,
then create an inventory file for Ansible with this [tool](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py).
@@ -65,7 +65,7 @@ to [kubeadm](../kubeadm) and [kops](../kops).
#### Checklist
* Apply deployment with
- [kargo-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
+ [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
or ``ansible-playbook``
[manual commands](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
@@ -95,6 +95,5 @@ Note, that it is highly unrecommended to delete production clusters with the res
## Feedback
-* Slack Channel: [#kargo](https://kubernetes.slack.com/messages/kargo/)
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
-
diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md
deleted file mode 100644
index b47ac1150a..0000000000
--- a/docs/getting-started-guides/meanstack.md
+++ /dev/null
@@ -1,447 +0,0 @@
----
-title: MEAN stack on Google Cloud Platform
----
-
-**By: Sandeep Dinesh** - _July 29, 2015_
-
-
-
-In [a recent post](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), I talked about running a MEAN stack with [Docker Containers.](http://docker.com/)
-
-Manually deploying Containers is all fine and dandy, but is rather fragile and clumsy. What happens if the app crashes? How can the app be updated? Rolled back?
-
-Thankfully, there is a system we can use to manage our containers in a cluster environment called Kubernetes. Even better, Google has a managed version of Kubernetes called [Google Container Engine](https://cloud.google.com/container-engine/) so you can get up and running in minutes.
-
-* TOC
-{:toc}
-
-## The Basics of Using Kubernetes
-
-Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes.
-
-* Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly.
-* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database.
-* Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones.
-* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services.
-
-
-## Step 1: Creating the Container
-
-In my previous post, I used off-the-shelf containers to keep things simple.
-
-I had a stock MongoDB container and a stock Node.js container. The Mongo container ran fine without any modification. However, I had to manually enter the Node container to pull and run the code. Obviously this isn't ideal in Kubernetes land, as you aren't supposed to log into your servers!
-
-Instead, you have to build a custom container that has the code already inside it and runs automatically.
-
-To do this, you need to use more Docker. Make sure you have the latest version installed for the rest of this tutorial.
-
-Getting the code:
-
-Before starting, let's get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial.
-
-```shell
-$ git clone https://github.com/ijason/NodeJS-Sample-App.git app
-$ mv app/EmployeeDB/* app/
-$ sed -i -- 's/localhost/mongo/g' ./app/app.js
-```
-
-This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it's easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy.
-
-Building the Docker image:
-
-First, you need a `Dockerfile`. This is basically the list of instructions Docker uses to build a container image.
-
-Here is the `Dockerfile` for the web server:
-
-```shell
-FROM node:4.4
-
-RUN mkdir -p /usr/src/app
-WORKDIR /usr/src/app
-COPY ./app/ ./
-RUN npm install
-
-CMD ["node", "app.js"]
-```
-
-A `Dockerfile` is pretty self-explanatory, and this one is dead simple.
-
-First, it uses the official Node.js LTS image as the base image.
-
-Then, it creates a folder to store the code, `cd`s into that directory, copies the code in, and installs the dependencies with npm.
-
-Finally, it specifies the command Docker should run when the container starts, which is to start the app.
-
-
-## Step 2: Building our Container
-
-Right now, the directory should look like this:
-
-```shell
-$ ls
-
-Dockerfile app
-```
-
-Let's build.
-
-```shell
-$ docker build -t myapp .
-```
-
-This will build a new Docker image for your app. This might take a few minutes as it is downloading and building everything.
-
-After that is done, test it out:
-
-```shell
-$ docker run myapp
-```
-
-At this point, you should have a server running on `http://localhost:3000` (or wherever Docker tells you). The website will error out as there is no database running, but we know it works!
-
-
-
-
-## Step 3: Pushing our Container
-
-Now you have a custom Docker image, you have to actually access it from the cloud.
-
-As we are going to be using the image with Google Container Engine, the best place to push the image is the [Google Container Registry](https://cloud.google.com/tools/container-registry/). The Container Registry is built on top of [Google Cloud Storage](https://cloud.google.com/storage/), so you get the advantage of scalable storage and very fast access from Container Engine.
-
-First, make sure you have the latest version of the [Google Cloud SDK installed](https://cloud.google.com/sdk/).
-
-[Windows users click here.](https://dl.google.com/dl/cloudsdk/release/GoogleCloudSDKInstaller.exe)
-
-For Linux/Mac:
-
-```shell
-$ curl https://sdk.cloud.google.com | bash
-```
-
-Then, make sure you log in and update.
-
-```shell
-$ gcloud auth login
-$ gcloud components update
-```
-
-You're ready to push your container live, but you'll need a destination. Create a Project in [the Google Cloud Platform Console](https://console.developers.google.com/), and leave it blank. Use the Project ID below, and push your project live.
-
-```shell
-$ docker tag myapp gcr.io//myapp
-$ gcloud docker push gcr.io//myapp
-```
-
-After some time, it will finish. You can check the console to see the container has been pushed up.
-
-
-
-
-## **Step 4: Creating the Cluster**
-
-So now you have the custom container, let's create a cluster to run it.
-
-Currently, a cluster can be as small as one machine to as big as 100 machines. You can pick any machine type you want, so you can have a cluster of a single `f1-micro` instance, 100 `n1-standard-32` instances (3,200 cores!), and anything in between.
-
-For this tutorial I'm going to use the following:
-
-* Create a cluster named `mean-cluster`
-* Give it a size of 2 nodes
-* Machine type will be `n1-standard-1`
-* Zone will be `us-central-1f` (Use a zone close to you)
-
-There are two ways to create this cluster. Take your pick.
-
-**Command Line:**
-
-```shell
-$ gcloud beta container \
- --project "" \
- clusters create "mean-cluster" \
- --zone "us-central1-f" \
- --machine-type "n1-standard-1" \
- --num-nodes "2" \
- --network "default"
-```
-
-**GUI:**
-
-
-
-After a few minutes, you should see this in the console.
-
-
-
-
-## **Step 5: Creating the Database Service**
-
-Three things need to be created:
-
-1. Persistent Disk to store the data (pods are ephemeral, so we shouldn't save data locally)
-2. Deployment running MongoDB
-3. Service mapping to that Deployment
-
-To create the disk, run this:
-
-```shell
-$ gcloud compute disks create \
- --project "" \
- --zone "us-central1-f" \
- --size 200GB \
- mongo-disk
-```
-
-Pick the same zone as your cluster and an appropriate disk size for your application.
-
-Now, we need to create a Deployment that will run the database. I'm using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically.
-
-### `db-deployment.yml`
-
-```yaml
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
- name: mongo-deployment
-spec:
- replicas: 1
- template:
- metadata:
- labels:
- name: mongo
- spec:
- containers:
- - image: mongo
- name: mongo
- ports:
- - name: mongo
- containerPort: 27017
- hostPort: 27017
- volumeMounts:
- - name: mongo-persistent-storage
- mountPath: /data/db
- volumes:
- - name: mongo-persistent-storage
- gcePersistentDisk:
- pdName: mongo-disk
- fsType: ext4
-
-```
-
-We call the deployment `mongo-deployment`, specify one replica, and open the appropriate ports. The image is `mongo`, which is the off the shelf MongoDB image.
-
-The `volumes` section creates the volume for Kubernetes to use. There is a Google Container Engine-specific `gcePersistentDisk` section that maps the disk we made into a Kubernetes volume, and we mount the volume into the `/data/db` directory (as described in the MongoDB Docker documentation)
-
-Now we have the Deployment, let's create the Service:
-
-### `db-service.yml`
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- name: mongo
- name: mongo
-spec:
- ports:
- - port: 27017
- targetPort: 27017
- selector:
- name: mongo
-```
-
-Again, pretty simple stuff. We "select" the mongo Deployment to be served, open up the ports, and call the service `mongo`.
-
-This is just like the "link" command line option we used with Docker in my previous post. Instead of connecting to `localhost`, we connect to `mongo`, and Kubernetes redirects traffic to the mongo service!
-
-At this point, the local directory looks like this:
-
-```shell
-$ ls
-
-Dockerfile
-app
-db-deployment.yml
-db-service.yml
-```
-
-## Step 6: Running the Database
-
-First, let's "log in" to the cluster
-
-```shell
-$ gcloud container clusters get-credentials mean-cluster
-```
-
-Now create the Deployment.
-
-```shell
-$ kubectl create -f db-deployment.yml
-```
-
-And the Service.
-
-```shell
-$ kubectl create -f db-service.yml
-```
-
-`kubectl` is the Kubernetes command line tool (automatically installed with the Google Cloud SDK). We are just creating the resources specified in the files.
-
-At this point, the database is spinning up! You can check progress with the following command:
-
-```shell
-$ kubectl get pods
-```
-
-Once you see the mongo pod in running status, we are good to go!
-
-```shell
-$ kubectl get pods
-
-NAME READY REASON RESTARTS AGE
-mongo-deployment-xxxx 1/1 Running 0 3m
-```
-
-
-## Step 7: Creating the Web Server
-
-Now the database is running, let's start the web server.
-
-We need two things:
-
-1. Deployment to spin up and down web server pods
-2. Service to expose our website to the interwebs
-
-Let's look at the Deployment configuration:
-
-### `web-deployment.yml`
-
-```yaml
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
- name: web-deployment
-spec:
- replicas: 2
- template:
- metadata:
- labels:
- name: web
- spec:
- containers:
- - image: gcr.io//myapp
- name: web
- ports:
- - name: http-server
- containerPort: 3000
-
-```
-
-Here, we create a deployment called `web-deployment`, and we tell it to create two replicas. Replicas of what you ask? You may notice the `template` section looks just like a Pod configuration, and that's because it is. We are creating a Pod with our custom Node.js container and exposing port 3000.
-
-
-Now for the Service
-
-### `web-service.yml`
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: web
- labels:
- name: web
-spec:
- type: LoadBalancer
- ports:
- - port: 80
- targetPort: 3000
- protocol: TCP
- selector:
- name: web
-```
-
-Notice two things here:
-
-1. The type is *LoadBalancer*. This is a cool feature that will make Google Cloud Platform create an external network load balancer automatically for this service!
-2. We map external port 80 to the internal port 3000, so we can serve HTTP traffic without messing with Firewalls.
-
-At this point, the local directory looks like this
-
-```shell
-$ ls
-
-Dockerfile
-app
-db-deployment.yml
-db-service.yml
-web-service.yml
-web-deployment.yml
-```
-
-
-## Step 8: Running the Web Server
-
-Create the Deployment.
-
-```shell
-$ kubectl create -f web-deployment.yml
-```
-
-And the Service.
-
-```shell
-$ kubectl create -f web-service.yml
-```
-
-And check the status.
-
-```shell
-$ kubectl get pods
-```
-
-Once you see the web pods in running status, we are good to go!
-
-```shell
-$ kubectl get pods
-
-NAME READY REASON RESTARTS AGE
-mongo-deployment-xxxx 1/1 Running 0 4m
-web-deployment-xxxx 1/1 Running 0 1m
-web-deployment-xxxx 1/1 Running 0 1m
-```
-
-
-## Step 9: Accessing the App
-
-At this point, everything is up and running. The architecture looks something like this:
-
-{: style="max-width:25%"}
-
-By default, port 80 should be open on the load balancer. In order to find the IP address of our app, run this command:
-
-```shell
-$ gcloud compute forwarding-rules list
-
-NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
-abcdef us-central1 104.197.XXX.XXX TCP us-xxxx
-```
-
-If you go to the IP address listed, you should see the app up and running!
-
-
-
-And the Database works!
-
-
-
-
-#### **Final Thoughts**
-
-By using Container Engine and Kubernetes, we have a very robust, container based MEAN stack running in production.
-
-[In another post](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474#.e93x7kuq5), I cover how to setup a MongoDB replica set. This is very important for running in production.
-
-Hopefully I can do some more posts about advanced Kubernetes topics such as changing the cluster size and number of Node.js web server replicas, using different environments (dev, staging, prod) on the same cluster, and doing rolling updates.
-
-Thanks to [Mark Mandel](https://medium.com/@markmandel), [Aja Hammerly](https://medium.com/@thagomizer), and [Jack Wilber](https://medium.com/@jack.g.wilber). [Some rights reserved](http://creativecommons.org/licenses/by/4.0/) by the author.
diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md
index cfe0442ecb..7bfe8bb6bf 100644
--- a/docs/getting-started-guides/mesos/index.md
+++ b/docs/getting-started-guides/mesos/index.md
@@ -30,7 +30,7 @@ Further information is available in the Kubernetes on Mesos [contrib directory][
- A running [Mesos cluster on Google Compute Engine][5]
- A [VPN connection][10] to the cluster
- A machine in the cluster which should become the Kubernetes *master node* with:
- - Go (see [here](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md) for required versions)
+ - Go (see [here](https://git.k8s.io/community/contributors/devel/development.md) for required versions)
- make (i.e. build-essential)
- Docker
@@ -332,6 +332,6 @@ Future work will add instructions to this guide to enable support for Kubernetes
[8]: https://github.com/mesosphere/kubernetes-mesos/issues
[9]: https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples
[10]: http://open.mesosphere.com/getting-started/cloud/google/mesosphere/#vpn-setup
-[11]: https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/README.md#kube-dns
-[12]: https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/kubedns-controller.yaml.in
+[11]: https://git.k8s.io/kubernetes/cluster/addons/dns/README.md#kube-dns
+[12]: https://git.k8s.io/kubernetes/cluster/addons/dns/kubedns-controller.yaml.in
[13]: https://github.com/kubernetes-incubator/kube-mesos-framework/blob/master/README.md
diff --git a/docs/getting-started-guides/minikube.md b/docs/getting-started-guides/minikube.md
index 8ef8b78cb0..5d514e4c75 100644
--- a/docs/getting-started-guides/minikube.md
+++ b/docs/getting-started-guides/minikube.md
@@ -34,8 +34,8 @@ the following drivers:
* virtualbox
* vmwarefusion
-* kvm ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#kvm-driver))
-* xhyve ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver))
+* kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver))
+* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver))
Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
@@ -88,7 +88,7 @@ This will use an alternative minikube ISO image containing both rkt, and Docker,
### Driver plugins
-See [DRIVERS](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md) for details on supported drivers and how to install
+See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install
plugins, if required.
### Reusing the Docker daemon
@@ -281,6 +281,12 @@ $ minikube start --docker-env HTTP_PROXY=http://$YOURPROXY:PORT \
--docker-env HTTPS_PROXY=https://$YOURPROXY:PORT
```
+If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent kubectl from directly reaching it.
+To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
+
+```shell
+$ export no_proxy=$no_proxy,$(minikube ip)
+```
## Known Issues
* Features that require a Cloud Provider will not work in Minikube. These include:
@@ -290,17 +296,17 @@ $ minikube start --docker-env HTTP_PROXY=http://$YOURPROXY:PORT \
## Design
-Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [localkube](https://github.com/kubernetes/minikube/tree/master/pkg/localkube) (originally written and donated to this project by [RedSpread](https://redspread.com/)) for running the cluster.
+Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [localkube](https://git.k8s.io/minikube/pkg/localkube) (originally written and donated to this project by [RedSpread](https://redspread.com/)) for running the cluster.
-For more information about minikube, see the [proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/local-cluster-ux.md).
+For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/local-cluster-ux.md).
## Additional Links:
-* **Goals and Non-Goals**: For the goals and non-goals of the minikube project, please see our [roadmap](https://github.com/kubernetes/minikube/blob/master/docs/contributors/roadmap.md).
-* **Development Guide**: See [CONTRIBUTING.md](https://github.com/kubernetes/minikube/blob/master/CONTRIBUTING.md) for an overview of how to send pull requests.
-* **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://github.com/kubernetes/minikube/blob/master/docs/contributors/build_guide.md)
-* **Adding a New Dependency**: For instructions on how to add a new depeindency to minikube see the [adding dependencies guide](https://github.com/kubernetes/minikube/blob/master/docs/contributors/adding_a_dependency.md)
-* **Adding a New Addon**: For instruction on how to add a new addon for minikube see the [adding an addon guide](https://github.com/kubernetes/minikube/blob/master/docs/contributors/adding_an_addon.md)
-* **Updating Kubernetes**: For instructions on how to update kubernetes see the [updating Kubernetes guide](https://github.com/kubernetes/minikube/blob/master/docs/contributors/updating_kubernetes.md)
+* **Goals and Non-Goals**: For the goals and non-goals of the minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
+* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
+* **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md)
+* **Adding a New Dependency**: For instructions on how to add a new depeindency to minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)
+* **Adding a New Addon**: For instruction on how to add a new addon for minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)
+* **Updating Kubernetes**: For instructions on how to update kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md)
## Community
diff --git a/docs/getting-started-guides/openstack-heat.md b/docs/getting-started-guides/openstack-heat.md
index 3f7e7cedc6..c6d01cc042 100644
--- a/docs/getting-started-guides/openstack-heat.md
+++ b/docs/getting-started-guides/openstack-heat.md
@@ -10,7 +10,7 @@ title: OpenStack Heat
## Getting started with OpenStack
-This guide will take you through the steps of deploying Kubernetes to Openstack using `kube-up.sh`. The primary mechanisms for this are [OpenStack Heat](https://wiki.openstack.org/wiki/Heat) and the [SaltStack](https://github.com/kubernetes/kubernetes/tree/master/cluster/saltbase) distributed with Kubernetes.
+This guide will take you through the steps of deploying Kubernetes to Openstack using `kube-up.sh`. The primary mechanisms for this are [OpenStack Heat](https://wiki.openstack.org/wiki/Heat) and the [SaltStack](https://git.k8s.io/kubernetes/cluster/saltbase) distributed with Kubernetes.
The default OS is CentOS 7, this has not been tested on other operating systems.
diff --git a/docs/getting-started-guides/rkt/notes.md b/docs/getting-started-guides/rkt/notes.md
index a31875302a..eb1f94d98b 100644
--- a/docs/getting-started-guides/rkt/notes.md
+++ b/docs/getting-started-guides/rkt/notes.md
@@ -67,7 +67,7 @@ Exponential restart back-off for a failing container is currently not supported.
## Experimental NVIDIA GPU support
-The `--experimental-nvidia-gpus` flag, and related [GPU features](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/gpu-support.md) are not supported.
+The `--experimental-nvidia-gpus` flag, and related [GPU features](https://git.k8s.io/community/contributors/design-proposals/gpu-support.md) are not supported.
## QoS Classes
diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md
index 3fdd726319..ffe52a3708 100644
--- a/docs/getting-started-guides/scratch.md
+++ b/docs/getting-started-guides/scratch.md
@@ -164,7 +164,7 @@ You will need binaries for:
A Kubernetes binary release includes all the Kubernetes binaries as well as the supported release of etcd.
You can use a Kubernetes binary release (recommended) or build your Kubernetes binaries following the instructions in the
-[Developer Documentation](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/). Only using a binary release is covered in this guide.
+[Developer Documentation](https://git.k8s.io/community/contributors/devel/). Only using a binary release is covered in this guide.
Download the [latest binary release](https://github.com/kubernetes/kubernetes/releases/latest) and unzip it.
Server binary tarballs are no longer included in the Kubernetes final tarball, so you will need to locate and run
diff --git a/docs/getting-started-guides/ubuntu/installation.md b/docs/getting-started-guides/ubuntu/installation.md
index 5c0b5423ac..76e0c11bb1 100644
--- a/docs/getting-started-guides/ubuntu/installation.md
+++ b/docs/getting-started-guides/ubuntu/installation.md
@@ -47,33 +47,33 @@ so we can find them.
Deployment of the cluster is [supported on a wide variety of public clouds](#cloud-compatibility), private OpenStack clouds, or raw bare metal clusters. Bare metal deployments are supported via [MAAS](http://maas.io/).
-After deciding which cloud to deploy to, follow the [cloud setup page](https://jujucharms.com/docs/devel/getting-started-general#2.-choose-a-cloud) to configure deploying to that cloud.
+After deciding which cloud to deploy to, follow the [cloud setup page](https://jujucharms.com/docs/devel/getting-started-general#2.-choose-a-cloud) to configure deploying to that cloud.
-Load your [cloud credentials](https://jujucharms.com/docs/2.0/credentials) for each
-cloud provider you would like to use.
+Load your [cloud credentials](https://jujucharms.com/docs/2.0/credentials) for each
+cloud provider you would like to use.
In this example
```
-juju add-credential aws
+juju add-credential aws
credential name: my_credentials
select auth-type [userpass, oauth, etc]: userpass
enter username: jorge
enter password: *******
```
-You can also just auto load credentials for popular clouds with the `juju autoload-credentials` command, which will auto import your credentials from the default files and environment variables for each cloud.
+You can also just auto load credentials for popular clouds with the `juju autoload-credentials` command, which will auto import your credentials from the default files and environment variables for each cloud.
Next we need to bootstrap a controller to manage the cluster. You need to define the cloud you want to bootstrap on, the region, and then any name for your controller node:
```
juju update-clouds # This command ensures all the latest regions are up to date on your client
-juju bootstrap aws/us-east-2
+juju bootstrap aws/us-east-2
```
-or, another example, this time on Azure:
+or, another example, this time on Azure:
```
-juju bootstrap azure/centralus
+juju bootstrap azure/centralus
```
You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.0/controllers) for more information.
@@ -84,13 +84,13 @@ Note that each controller can host multiple Kubernetes clusters in a given cloud
{% capture steps %}
## Launch a Kubernetes cluster
-The following command will deploy the initial 9-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to:
+The following command will deploy the initial 9-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to:
```
juju deploy canonical-kubernetes
```
-After this command executes the cloud will then launch instances and begin the deployment process.
+After this command executes the cloud will then launch instances and begin the deployment process.
## Monitor deployment
@@ -98,9 +98,9 @@ The `juju status` command provides information about each unit in the cluster. U
juju status
-Output:
+Output:
-```
+```
Model Controller Cloud/Region Version
default aws-us-east-2 aws/us-east-2 2.0.1
@@ -159,8 +159,8 @@ juju scp kubernetes-master/0:config ~/.kube/config
Fetch a binary for the architecture you have deployed. If your client is a
different architecture you will need to get the appropriate `kubectl` binary
-through other means. In this example we copy kubectl to `~/bin` for convenience,
-by default this should be in your $PATH.
+through other means. In this example we copy kubectl to `~/bin` for convenience,
+by default this should be in your $PATH.
```
mkdir -p ~/bin
@@ -171,7 +171,7 @@ Query the cluster:
kubectl cluster-info
-Output:
+Output:
```
Kubernetes master is running at https://52.15.104.227:443
@@ -206,7 +206,7 @@ Or multiple units at one time:
```shell
juju add-unit -n3 kubernetes-worker
```
-You can also ask for specific instance types or other machine-specific constraints. See the [constraints documentation](https://jujucharms.com/docs/stable/reference-constraints) for more information. Here are some examples, note that generic constraints such as `cores` and `mem` are more portable between clouds. In this case we'll ask for a specific instance type from AWS:
+You can also ask for specific instance types or other machine-specific constraints. See the [constraints documentation](https://jujucharms.com/docs/stable/reference-constraints) for more information. Here are some examples, note that generic constraints such as `cores` and `mem` are more portable between clouds. In this case we'll ask for a specific instance type from AWS:
```shell
juju set-constraints kubernetes-worker instance-type=c4.large
@@ -218,7 +218,7 @@ You can also scale the etcd charm for more fault tolerant key/value storage:
```shell
juju add-unit -n3 etcd
```
-It is strongly recommended to run an odd number of units for quorum.
+It is strongly recommended to run an odd number of units for quorum.
## Tear down cluster
@@ -240,8 +240,8 @@ The Ubuntu Kubernetes deployment uses open-source operations, or operations as c
The Kubernetes layer and bundles can be found in the `kubernetes`
project on github.com:
- - [Bundle location](https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/bundles)
- - [Kubernetes charm layer location](https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/layers/kubernetes)
+ - [Bundle location](https://git.k8s.io/kubernetes/cluster/juju/bundles)
+ - [Kubernetes charm layer location](https://git.k8s.io/kubernetes/cluster/juju/layers)
- [Canonical Kubernetes home](https://jujucharms.com/canonical-kubernetes/)
Feature requests, bug reports, pull requests or any feedback would be much appreciated.
@@ -264,4 +264,3 @@ Bare Metal (MAAS) | Juju | Ubuntu | flannel, calico | [doc
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
{% include templates/task.md %}
-
diff --git a/docs/getting-started-guides/ubuntu/validation.md b/docs/getting-started-guides/ubuntu/validation.md
index e881ab9fa6..445bd6e4f6 100644
--- a/docs/getting-started-guides/ubuntu/validation.md
+++ b/docs/getting-started-guides/ubuntu/validation.md
@@ -91,13 +91,13 @@ To see the different types of tests the Kubernetes end-to-end charm has access
to, we encourage you to see the upstream documentation on the different types
of tests, and to strongly understand what subsets of the tests you are running.
-[Kinds of tests](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md#kinds-of-tests)
+[Kinds of tests](https://git.k8s.io/community/contributors/devel/e2e-tests.md#kinds-of-tests)
### More information on end-to-end testing
Along with the above descriptions, end-to-end testing is a much larger subject
than this readme can encapsulate. There is far more information in the
-[end-to-end testing guide](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md).
+[end-to-end testing guide](https://git.k8s.io/community/contributors/devel/e2e-tests.md).
### Evaluating end-to-end results
diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md
index c82e286ed2..9ec2395aab 100644
--- a/docs/getting-started-guides/vsphere.md
+++ b/docs/getting-started-guides/vsphere.md
@@ -20,7 +20,7 @@ This page also describes how to configure and get started with the cloud provide
To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch.
-Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/README.md)
+Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md)
### vSphere Cloud Provider
@@ -38,7 +38,7 @@ guide](http://kubernetes.io/docs/user-guide/persistent-volumes/#vsphere) and the
guide](/docs/concepts/storage/volumes/#vspherevolume)
Examples can be found
-[here](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/vsphere)
+[here](https://git.k8s.io/kubernetes/examples/volumes/vsphere)
#### Configuring vSphere Cloud Provider
@@ -82,7 +82,7 @@ Virtual machine > Configuration > Add new disk
Resource > Assign virtual machine to resource pool
```
-* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=``` flag. Cloud config [template can be found at Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf)
+* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=``` flag. Cloud config [template can be found at Kubernetes-Anywhere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/vsphere.conf)
Sample Config:
@@ -119,7 +119,7 @@ Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster
#### Prerequisites
* You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license).
-* You must have Go (see [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org).
+* You must have Go (see [here](https://git.k8s.io/community/contributors/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org).
* You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`.
```shell
diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md
index dd775b81af..ad5c1b9329 100644
--- a/docs/getting-started-guides/windows/index.md
+++ b/docs/getting-started-guides/windows/index.md
@@ -54,7 +54,7 @@ Requirements
* Git
* Go 1.7.1+
* make (if using Linux or MacOS)
-* Important notes and other dependencies are listed [here](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md#building-kubernetes-on-a-local-osshell-environment)
+* Important notes and other dependencies are listed [here](https://git.k8s.io/community/contributors/devel/development.md#building-kubernetes-on-a-local-osshell-environment)
**kubelet**
diff --git a/docs/home/contribute/create-pull-request.md b/docs/home/contribute/create-pull-request.md
index 5512d30acb..bc408e9e54 100644
--- a/docs/home/contribute/create-pull-request.md
+++ b/docs/home/contribute/create-pull-request.md
@@ -17,7 +17,7 @@ repository. This page shows how to create a pull request.
1. Sign the
[Linux Foundation Contributor License Agreement](https://identity.linuxfoundation.org/projects/cncf){: target="_blank"}.
-Documentation will be published under the [CC BY SA 4.0](https://github.com/kubernetes/kubernetes.github.io/blob/master/LICENSE) license.
+Documentation will be published under the [CC BY SA 4.0](https://git.k8s.io/kubernetes.github.io/LICENSE) license.
{% endcapture %}
diff --git a/docs/home/contribute/page-templates.md b/docs/home/contribute/page-templates.md
index caf5b41d90..ec9369af30 100644
--- a/docs/home/contribute/page-templates.md
+++ b/docs/home/contribute/page-templates.md
@@ -16,7 +16,7 @@ title: Using Page Templates
diff --git a/docs/home/contribute/stage-documentation-changes.md b/docs/home/contribute/stage-documentation-changes.md
index c851581f9b..8fdfc43887 100644
--- a/docs/home/contribute/stage-documentation-changes.md
+++ b/docs/home/contribute/stage-documentation-changes.md
@@ -33,7 +33,7 @@ can see your changes.
You can use the k8sdocs Docker image to run a local staging server. If you're
interested, you can view the
-[Dockerfile](https://github.com/kubernetes/kubernetes.github.io/blob/master/staging-container/Dockerfile){: target="_blank"}
+[Dockerfile](https://git.k8s.io/kubernetes.github.io/staging-container/Dockerfile){: target="_blank"}
for this image.
1. Install Docker if you don't already have it.
diff --git a/docs/home/contribute/write-new-topic.md b/docs/home/contribute/write-new-topic.md
index 61b605f0c6..6dde02a322 100644
--- a/docs/home/contribute/write-new-topic.md
+++ b/docs/home/contribute/write-new-topic.md
@@ -22,17 +22,17 @@ is the best fit for your content:
Task
-
A task page shows how to do a single thing, typically by giving a short sequence of steps. Task pages have minimal explanation, but often provide links to conceptual topics that provide related background and knowledge.
+
A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes
Tutorial
-
A tutorial page shows how to accomplish a goal that is larger than a single task. Typically a tutorial page has several sections, each of which has a sequence of steps. For example, a tutorial might provide a walkthrough of a code sample that illustrates a certain feature of Kubernetes. Tutorials can include surface-level explanations, but should link to related concept topics for deep explanations.
+
A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied togeter, but should link to related concept topics for deep explanations of individual features.
Concept
-
A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials.
+
A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
diff --git a/docs/reference/api-overview.md b/docs/reference/api-overview.md
index 7e8c611f7a..4c2e904f96 100644
--- a/docs/reference/api-overview.md
+++ b/docs/reference/api-overview.md
@@ -30,10 +30,10 @@ multiple API versions, each at a different API path, such as `/api/v1` or
The version is set at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes; all descriptions below cover both formats.
Note that API versioning and software versioning are only indirectly related. The [API and release
-versioning proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/versioning.md) describes the relationship between API versioning and software versioning.
+versioning proposal](https://git.k8s.io/community/contributors/design-proposals/versioning.md) describes the relationship between API versioning and software versioning.
Different API versions imply different levels of stability and support. The criteria for each level are described
-in more detail in the [API Changes documentation](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api_changes.md#alpha-beta-and-stable-versions).
+in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions).
The criteria are summarized here:
@@ -57,7 +57,7 @@ The criteria are summarized here:
## API groups
-[*API groups*](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-group.md) make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
+[*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-group.md) make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
Currently, there are several API groups in use:
@@ -66,7 +66,7 @@ Currently, there are several API groups in use:
(for example, `apiVersion: batch/v1`). Full list of supported API groups can be seen in [Kubernetes API reference](/docs/reference/).
There is a supported path to extending the API:
-* [Third Party Resources](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/extending-api.md)
+* [Third Party Resources](https://git.k8s.io/community/contributors/design-proposals/extending-api.md)
are for users with very basic CRUD needs.
diff --git a/docs/reference/index.md b/docs/reference/index.md
index 4ef45372e3..2b49caf4cf 100644
--- a/docs/reference/index.md
+++ b/docs/reference/index.md
@@ -29,4 +29,4 @@ assignees:
## Design Docs
-An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md) and [Kubernetes Design Overview](https://github.com/kubernetes/kubernetes/tree/{{page.fullversion}}/docs/design).
+An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture.md) and [Kubernetes Design Overview](https://github.com/kubernetes/kubernetes/tree/{{page.fullversion}}/docs/design).
diff --git a/docs/reference/security.md b/docs/reference/security.md
index 5fe3b5b13c..ee09bfbb61 100644
--- a/docs/reference/security.md
+++ b/docs/reference/security.md
@@ -17,9 +17,9 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete
We’re extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
-To make a report, please email the private [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE.md).
+To make a report, please email the private [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE.md).
-You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.
+You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/community/contributors/devel/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.
### When Should I Report a Vulnerability?
@@ -35,7 +35,7 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur
## Security Vulnerability Response
-Each report is acknowledged and analyzed by Product Security Team members within 3 working days. This will set off the [Security Release Process](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst).
+Each report is acknowledged and analyzed by Product Security Team members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/community/contributors/devel/security-release-process.md#product-security-team-pst).
Any vulnerability information shared with Product Security Team stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
diff --git a/docs/resources-reference/v1.6/index.html b/docs/resources-reference/v1.6/index.html
index 103f61e8f6..0c9dc8932d 100644
--- a/docs/resources-reference/v1.6/index.html
+++ b/docs/resources-reference/v1.6/index.html
@@ -1217,7 +1217,7 @@ Appears In Pod
diff --git a/docs/samples.md b/docs/samples.md
deleted file mode 100644
index e22c7698cb..0000000000
--- a/docs/samples.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-assignees:
-- bgrant0607
-title: Samples
----
-
-We have a wide variety of samples to choose from.
-
-## Recently updated samples
-
-The Kubernetes team is highlighting these samples as being the most up-to-date. Active upkeep is being done or has recently been done
-on these samples to ensure they are high quality and work on Kubernetes {{page.version}}.
-
-
diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md
index 46727f182d..53ed24d2b5 100644
--- a/docs/setup/independent/create-cluster-kubeadm.md
+++ b/docs/setup/independent/create-cluster-kubeadm.md
@@ -415,7 +415,7 @@ control of your Kubernetes cluster.
kubeadm deb/rpm packages and binaries are built for amd64, arm64, armhfp,
ppc64el, and s390x following the [multi-platform
-proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/multi-platform.md).
+proposal](https://git.k8s.io/community/contributors/design-proposals/multi-platform.md).
Currently, only the pod networks flannel and Weave Net work on multiple architectures.
For Weave Net just use its [standard install](https://www.weave.works/docs/net/latest/kube-addon/).
diff --git a/docs/setup/independent/install-kubeadm.md b/docs/setup/independent/install-kubeadm.md
index d0c808e31e..5f7573aee9 100644
--- a/docs/setup/independent/install-kubeadm.md
+++ b/docs/setup/independent/install-kubeadm.md
@@ -13,6 +13,7 @@ This page shows how to use install kubeadm.
* One or more machines running Ubuntu 16.04+, CentOS 7 or HypriotOS v1.0.1+
* 1GB or more of RAM per machine (any less will leave little room for your apps)
* Full network connectivity between all machines in the cluster (public or private network is fine)
+* Unique MAC address and product_uuid for every node
{% endcapture %}
@@ -26,7 +27,7 @@ Versions 1.13 and 17.03+ have not yet been tested and verified by the Kubernetes
For installation instructions, see
[Install Docker](https://docs.docker.com/engine/installation/).
-## Installing kubectl
+## Installing kubectl
On each of your machines,
[install kubectl](/docs/tasks/tools/install-kubectl/).
@@ -45,7 +46,7 @@ You will install these packages on all of your machines:
**Note:** If you already have kubeadm installed, you should do a `apt-get update &&
apt-get upgrade` or `yum update` to get the latest version of kubeadm. See the
kubeadm release notes if you want to read about the different [kubeadm
-releases](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md)
+releases](https://git.k8s.io/kubeadm/CHANGELOG.md)
For each machine:
diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md
index dc92350f8f..7602ec2238 100644
--- a/docs/setup/pick-right-solution.md
+++ b/docs/setup/pick-right-solution.md
@@ -88,7 +88,7 @@ have special requirements, or just because you want to understand what is undern
cluster, try the [Getting Started from Scratch](/docs/getting-started-guides/scratch) guide.
If you are interested in supporting Kubernetes on a new platform, see
-[Writing a Getting Started Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-a-getting-started-guide.md).
+[Writing a Getting Started Guide](https://git.k8s.io/community/contributors/devel/writing-a-getting-started-guide.md).
## Universal
@@ -143,7 +143,7 @@ Below is a table of all of the solutions listed above.
IaaS Provider | Config. Mgmt. | OS | Networking | Docs | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ----------------------------
-any | any | multi-support | any CNI | [docs](https://kubernetes.io/docs/getting-started-guides/kubeadm/) | Project ([SIG-cluster-lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle))
+any | any | multi-support | any CNI | [docs](https://kubernetes.io/docs/getting-started-guides/kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | Commercial
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
diff --git a/docs/tabs-example.md b/docs/tabs-example.md
index 863a466964..f5a4e8bb37 100644
--- a/docs/tabs-example.md
+++ b/docs/tabs-example.md
@@ -43,7 +43,7 @@ kubectl apply -f "https://git.io/weave-kube"
## Example Liquid template code for tabs
-Below is the [Liquid](https://shopify.github.io/liquid/) template code for the tabs demo above to illustrate how to specify the contents of each tab. The [`/_includes/tabs.md`](https://github.com/kubernetes/kubernetes.github.io/tree/master/_includes/tabs.md) file included at the end then uses those elements to render the actual tab set.
+Below is the [Liquid](https://shopify.github.io/liquid/) template code for the tabs demo above to illustrate how to specify the contents of each tab. The [`/_includes/tabs.md`](https://git.k8s.io/kubernetes.github.io/_includes/tabs.md) file included at the end then uses those elements to render the actual tab set.
### The code
diff --git a/docs/tasks/access-application-cluster/access-cluster.md b/docs/tasks/access-application-cluster/access-cluster.md
index 495358524d..69a8cf9ed0 100644
--- a/docs/tasks/access-application-cluster/access-cluster.md
+++ b/docs/tasks/access-application-cluster/access-cluster.md
@@ -132,7 +132,7 @@ Kubernetes supports [Go](#go-client) and [Python](#python-client) client librari
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes/client-go/blob/master/examples/out-of-cluster-client-configuration/main.go).
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
@@ -145,7 +145,7 @@ as the kubectl CLI does to locate and authenticate to the apiserver. See this [e
#### Other languages
-There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
+There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
### Accessing the API from a Pod
@@ -177,7 +177,7 @@ From within a pod the recommended ways to connect to API are:
in any container of the pod can access it. See this [example of using kubectl proxy
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
- They handle locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go)
+ They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
diff --git a/docs/tasks/administer-cluster/access-cluster-api.md b/docs/tasks/administer-cluster/access-cluster-api.md
index aba78582f0..16f41c2631 100644
--- a/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/docs/tasks/administer-cluster/access-cluster-api.md
@@ -124,7 +124,7 @@ Kubernetes supports [Go](#go-client) and [Python](#python-client) client librari
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes/client-go/blob/master/examples/out-of-cluster/main.go):
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster/main.go):
```golang
import (
@@ -167,7 +167,7 @@ for i in ret.items:
#### Other languages
-There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
+There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
### Accessing the API from a Pod
@@ -199,7 +199,7 @@ From within a pod the recommended ways to connect to API are:
in any container of the pod can access it. See this [example of using kubectl proxy
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
- They handle locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go)
+ They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
diff --git a/docs/tasks/administer-cluster/cluster-management.md b/docs/tasks/administer-cluster/cluster-management.md
index f243a992da..da24a4a2b2 100644
--- a/docs/tasks/administer-cluster/cluster-management.md
+++ b/docs/tasks/administer-cluster/cluster-management.md
@@ -24,7 +24,7 @@ To install Kubernetes on a set of machines, consult one of the existing [Getting
## Upgrading a cluster
-The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
+The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
* [Upgrading to 1.6](/docs/admin/upgrade-1-6)
@@ -66,7 +66,7 @@ The node upgrade process is user-initiated and is described in the [GKE document
Different providers, and tools, will manage upgrades differently. It is recommended that you consult their main documentation regarding upgrades.
* [kops](https://github.com/kubernetes/kops)
-* [kargo](https://github.com/kubernetes-incubator/kargo)
+* [kubespray](https://github.com/kubernetes-incubator/kubespray)
* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
* ...
diff --git a/docs/tasks/administer-cluster/configure-pod-disruption-budget.md b/docs/tasks/administer-cluster/configure-pod-disruption-budget.md
index c2e72a0a1f..68c2d7c491 100644
--- a/docs/tasks/administer-cluster/configure-pod-disruption-budget.md
+++ b/docs/tasks/administer-cluster/configure-pod-disruption-budget.md
@@ -22,7 +22,7 @@ Various cluster management operations may voluntarily evict pods. "Voluntary"
means an eviction can be safely delayed for a reasonable period of time. The
principal examples today are draining a node for maintenance or upgrade
(`kubectl drain`), and cluster autoscaling down. In the future the
-[rescheduler](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/rescheduling.md)
+[rescheduler](https://git.k8s.io/community/contributors/design-proposals/rescheduling.md)
may also perform voluntary evictions. By contrast, something like evicting pods
because a node has become unreachable or reports `NotReady`, is not "voluntary."
diff --git a/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/docs/tasks/administer-cluster/configure-upgrade-etcd.md
index a72aae3f08..fed514d13a 100644
--- a/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -35,7 +35,7 @@ see _some doc_.
Performance and stability of the cluster is sensitive to network and disk IO. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled.
-* Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations).
+* Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations).
## Resource requirements
@@ -247,7 +247,7 @@ it is enough to start etcd in 2.2.z version, wait until it is healthy, stop it,
Versions 3.0+ of etcd do not support general rollback. That is,
after migrating from M.N to M.N+1, there is no way to go back to M.N.
-The etcd team has provided a [custom rollback tool](https://github.com/kubernetes/kubernetes/tree/master/cluster/images/etcd/rollback)
+The etcd team has provided a [custom rollback tool](https://git.k8s.io/kubernetes/cluster/images/etcd/rollback)
but the rollback tool has these limitations:
* This custom rollback tool is not part of the etcd repo and does not receive the same
@@ -403,5 +403,5 @@ test key. On your master VM (or somewhere with firewalls configured such that
you can talk to your cluster's etcd), try:
```shell
-curl -fs -X PUT "http://${host}:${port}/v2/keys/_test"
+curl -X PUT "http://${host}:${port}/v2/keys/_test"
```
diff --git a/docs/tasks/administer-cluster/cpu-memory-limit.md b/docs/tasks/administer-cluster/cpu-memory-limit.md
index 73a8a65f5e..d04c9b14b4 100644
--- a/docs/tasks/administer-cluster/cpu-memory-limit.md
+++ b/docs/tasks/administer-cluster/cpu-memory-limit.md
@@ -227,7 +227,7 @@ constrain the amount of resource a pod consumes on a node.
{% endcapture %}
{% capture whatsnext %}
-* See [LimitRange design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control_limit_range.md) for more information.
+* See [LimitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) for more information.
* See [Resources](/docs/concepts/configuration/manage-compute-resources-container/) for a detailed description of the Kubernetes resource model.
{% endcapture %}
diff --git a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 7ebcf89071..e73953783c 100644
--- a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -179,7 +179,7 @@ The output is:
### Option 3: Delete the kube-dns-autoscaler manifest file from the master node
This option works if kube-dns-autoscaler is under control of the
-[Addon Manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/README.md)'s
+[Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md)'s
control, and you have write access to the master node.
Sign in to the master node and delete the corresponding manifest file.
diff --git a/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
index e5a4a07dde..77415f3414 100644
--- a/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
+++ b/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
@@ -34,7 +34,7 @@ the rescheduler tries to free up space for the add-on by evicting some pods; the
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
-(see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)).
+(see [more details](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md)).
Each critical add-on has to tolerate it,
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
@@ -44,7 +44,7 @@ killed for this purpose.
## Config
-Rescheduler should be [enabled by default as a static pod](https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
+Rescheduler should be [enabled by default as a static pod](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
It doesn't have any user facing configuration (component config) or API and can be disabled:
* during cluster setup by setting `ENABLE_RESCHEDULER` flag to `false`
diff --git a/docs/tasks/administer-cluster/highly-available-master.md b/docs/tasks/administer-cluster/highly-available-master.md
index e061bef416..f630a64891 100644
--- a/docs/tasks/administer-cluster/highly-available-master.md
+++ b/docs/tasks/administer-cluster/highly-available-master.md
@@ -157,5 +157,5 @@ To make such deployment secure, communication between etcd instances is authoriz
## Additional reading
-[Automated HA master deployment - design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/ha_master.md)
+[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/ha_master.md)
diff --git a/docs/tasks/administer-cluster/namespaces.md b/docs/tasks/administer-cluster/namespaces.md
index 6d55989398..ad0da4e625 100644
--- a/docs/tasks/administer-cluster/namespaces.md
+++ b/docs/tasks/administer-cluster/namespaces.md
@@ -87,14 +87,14 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
A limit range defines min/max constraints on the amount of resources a single entity can consume in
a *Namespace*.
-See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md)
+See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md)
A namespace can be in one of two phases:
* `Active` the namespace is in use
* `Terminating` the namespace is being deleted, and can not be used for new objects
-See the [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#phases) for more details.
+See the [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases) for more details.
## Creating a new namespace
@@ -117,7 +117,7 @@ Note that the name of your namespace must be a DNS compatible label.
There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
-More information on `finalizers` can be found in the namespace [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#finalizers).
+More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers).
### Working in namespaces
@@ -148,5 +148,5 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
## Design
-Details of the design of namespaces in Kubernetes, including a [detailed example](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace)
-can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md)
+Details of the design of namespaces in Kubernetes, including a [detailed example](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace)
+can be found in the [namespaces design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md)
diff --git a/docs/tasks/administer-cluster/reserve-compute-resources.md b/docs/tasks/administer-cluster/reserve-compute-resources.md
index f66874f615..3c3b267a4e 100644
--- a/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -103,7 +103,7 @@ It is recommended that the kubernetes system daemons are placed under a top
level control group (`runtime.slice` on systemd machines for example). Each
system daemon should ideally run within its own child control group. Refer to
[this
-doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md#recommended-cgroups-setup)
+doc](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md#recommended-cgroups-setup)
for more details on recommended control group hierarchy.
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
diff --git a/docs/tasks/administer-cluster/running-cloud-controller.md b/docs/tasks/administer-cluster/running-cloud-controller.md
index 9ee04f0249..21b278b74c 100644
--- a/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -9,7 +9,7 @@ redirect_from:
Kubernetes version 1.6 contains a new binary called as `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops in Kubernetes. These cloud-specific control loops were originally in the kube-controller-manager. However, cloud providers move at a different pace and schedule compared to the Kubernetes project, and abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud provider vendors to evolve independently from the core Kubernetes code.
-The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go).
+The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
In future Kubernetes releases, cloud vendors should link code that satisfies the above interface to the `cloud-controller-manager` project and compile `cloud-controller-manager` for their own clouds. Cloud providers would also be responsible for maintaining and evolving their code.
* TOC
@@ -19,11 +19,11 @@ In future Kubernetes releases, cloud vendors should link code that satisfies the
To build cloud-controller-manager for your cloud, follow these steps:
-* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go).
+* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
* Link the cloudprovider to cloud-controller-manager
-The methods in [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
-[existing providers](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
+The methods in [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
+[existing providers](https://git.k8s.io/kubernetes/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
of the existing providers, you do not need to write a new provider; you can proceed directly with linking your cloud provider to the `cloud-controller-manager`.
Once your code is ready, you must import that code into `cloud-controller-manager`. See the [rancher cloud sample](https://github.com/rancher/rancher-cloud-controller-manager) for a reference example. The import step in the sample is the only step required to link your cloud provider to the `cloud-controller-manager`.
diff --git a/docs/tasks/administer-federation/ingress.md b/docs/tasks/administer-federation/ingress.md
index a9d17fb3c6..b994eccbd1 100644
--- a/docs/tasks/administer-federation/ingress.md
+++ b/docs/tasks/administer-federation/ingress.md
@@ -302,7 +302,7 @@ Check that:
{% capture whatsnext %}
* If you need assistance, use one of the [support channels](http://kubernetes.io/docs/troubleshooting/) to seek assistance.
* For details about use cases that motivated this work, see
- [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md).
+ [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md).
{% endcapture %}
{% include templates/task.md %}
diff --git a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md
index f6f7ae87c7..0f7dcf3185 100644
--- a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md
+++ b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md
@@ -88,7 +88,7 @@ than what you expect to use.
If you specify a request, a Pod is guaranteed to be able to use that much
of the resource. See
-[Resource QoS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md) for the difference between resource limits and requests.
+[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md) for the difference between resource limits and requests.
## If you don't specify limits or requests
diff --git a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
index 8c9f69617c..c305af902d 100644
--- a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+++ b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -198,7 +198,7 @@ PersistentVolume are not present on the Pod resource itself.
{% capture whatsnext %}
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
-* Read the [Persistent Storage design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/persistent-storage.md).
+* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/persistent-storage.md).
### Reference
diff --git a/docs/tasks/configure-pod-container/security-context.md b/docs/tasks/configure-pod-container/security-context.md
index 664bd56e8f..287d074c4f 100644
--- a/docs/tasks/configure-pod-container/security-context.md
+++ b/docs/tasks/configure-pod-container/security-context.md
@@ -329,7 +329,7 @@ applied to Volumes as follows:
* `fsGroup`: Volumes that support ownership management are modified to be owned
and writable by the GID specified in `fsGroup`. See the
-[Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-ownership-management.md)
+[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/volume-ownership-management.md)
for more details.
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
@@ -349,8 +349,8 @@ protection, you must ensure each Pod is assigned a unique MCS label.
* [PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core)
* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
-* [Security Contexts design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/security_context.md)
-* [Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-ownership-management.md)
+* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/security_context.md)
+* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/volume-ownership-management.md)
* [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
diff --git a/docs/tasks/debug-application-cluster/logging-stackdriver.md b/docs/tasks/debug-application-cluster/logging-stackdriver.md
index d8aaae2a79..b9b4b77426 100644
--- a/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -321,7 +321,7 @@ Fluentd is written in Ruby and allows to extend its capabilities using
[plugins](http://www.fluentd.org/plugins). If you want to use a plugin, which is not included
in the default Stackdriver Logging container image, you have to build a custom image. Imagine
you want to add Kafka sink for messages from a particular container for additional processing.
-You can re-use the default [container image sources](https://github.com/kubernetes/contrib/tree/master/fluentd/fluentd-gcp-image)
+You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
with minor changes:
* Change Makefile to point to your container repository, e.g. `PREFIX=gcr.io/`.
diff --git a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index 39c8ad72e2..f6424f8596 100644
--- a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -13,7 +13,7 @@ Understanding how an application behaves when deployed is crucial to scaling the
## Overview
-Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster, similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' [Kubelet](/docs/admin/kubelet/)s, the on-machine Kubernetes agent. The Kubelet itself fetches the data from [cAdvisor](https://github.com/google/cadvisor). Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. Currently supported backends include [InfluxDB](http://influxdb.com/) (with [Grafana](http://grafana.org/) for visualization), [Google Cloud Monitoring](https://cloud.google.com/monitoring/) and many others described in more details [here](https://github.com/kubernetes/heapster/blob/master/docs/sink-configuration.md). The overall architecture of the service can be seen below:
+Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster, similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' [Kubelet](/docs/admin/kubelet/)s, the on-machine Kubernetes agent. The Kubelet itself fetches the data from [cAdvisor](https://github.com/google/cadvisor). Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. Currently supported backends include [InfluxDB](http://influxdb.com/) (with [Grafana](http://grafana.org/) for visualization), [Google Cloud Monitoring](https://cloud.google.com/monitoring/) and many others described in more details [here](https://git.k8s.io/heapster/docs/sink-configuration.md). The overall architecture of the service can be seen below:
diff --git a/docs/tasks/example-task-template.md b/docs/tasks/example-task-template.md
index 253a819994..076aa08e20 100644
--- a/docs/tasks/example-task-template.md
+++ b/docs/tasks/example-task-template.md
@@ -1,37 +1,50 @@
---
title: Example Task Template
+assignees:
+- chenopis
---
{% capture overview %}
+
**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
This page shows how to ...
+
{% endcapture %}
{% capture prerequisites %}
+
+* {% include task-tutorial-prereqs.md %}
* Do this.
* Do this too.
+
{% endcapture %}
{% capture steps %}
+
## Doing ...
1. Do this.
1. Do this next. Possibly read this [related explanation](...).
+
{% endcapture %}
{% capture discussion %}
+
## Understanding ...
**[Optional Section]**
Here's an interesting thing to know about the steps you just did.
+
{% endcapture %}
{% capture whatsnext %}
+
**[Optional Section]**
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Task template](/docs/home/contribute/page-templates/#task_template) for how to use this template.
+
{% endcapture %}
{% include templates/task.md %}
\ No newline at end of file
diff --git a/docs/tasks/federation/federation-service-discovery.md b/docs/tasks/federation/federation-service-discovery.md
index e065e79e42..12ddc3ebe8 100644
--- a/docs/tasks/federation/federation-service-discovery.md
+++ b/docs/tasks/federation/federation-service-discovery.md
@@ -384,4 +384,4 @@ Check that:
## For more information
- * [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md) details use cases that motivated this work.
+ * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md) details use cases that motivated this work.
diff --git a/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
index fccc6dd666..cd2c39c656 100644
--- a/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+++ b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
@@ -53,7 +53,7 @@ tar -xzvf kubernetes-client-windows-amd64.tar.gz
`amd64`. If you are on a different architecture, please use a URL
appropriate for your architecture. You can find the list of available
binaries on the
-[release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-1).
+[release page](https://git.k8s.io/kubernetes/CHANGELOG.md#client-binaries-1).
Copy the extracted binaries to one of the directories in your `$PATH`
and set the executable permission on those binaries.
diff --git a/docs/tasks/inject-data-application/podpreset.md b/docs/tasks/inject-data-application/podpreset.md
index e6ee31a6a9..68affe2533 100644
--- a/docs/tasks/inject-data-application/podpreset.md
+++ b/docs/tasks/inject-data-application/podpreset.md
@@ -13,7 +13,7 @@ You can use a `podpreset` object to inject certain information into pods at crea
time. This information can include secrets, volumes, volume mounts, and environment
variables.
-See [PodPreset proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/pod-preset.md) for more information.
+See [PodPreset proposal](https://git.k8s.io/community/contributors/design-proposals/pod-preset.md) for more information.
* TOC
{:toc}
diff --git a/docs/tasks/job/fine-parallel-processing-work-queue/index.md b/docs/tasks/job/fine-parallel-processing-work-queue/index.md
index 6bfb8f919f..9e4c3200e9 100644
--- a/docs/tasks/job/fine-parallel-processing-work-queue/index.md
+++ b/docs/tasks/job/fine-parallel-processing-work-queue/index.md
@@ -34,7 +34,7 @@ Here is an overview of the steps in this example:
## Starting Redis
For this example, for simplicitly, we will start a single instance of Redis.
-See the [Redis Example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook) for an example
+See the [Redis Example](https://git.k8s.io/kubernetes/examples/guestbook) for an example
of deploying Redis scalably and redundantly.
Start a temporary Pod running Redis and a service so we can find it.
diff --git a/docs/tasks/run-application/delete-stateful-set.md b/docs/tasks/run-application/delete-stateful-set.md
index 6e6c803eb5..4b2b0cb34a 100644
--- a/docs/tasks/run-application/delete-stateful-set.md
+++ b/docs/tasks/run-application/delete-stateful-set.md
@@ -83,7 +83,7 @@ If you find that some pods in your StatefulSet are stuck in the 'Terminating' or
{% capture whatsnext %}
-Learn more about [force deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/).
+Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
{% endcapture %}
diff --git a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index f5bdf35886..6f3d274675 100644
--- a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -52,7 +52,7 @@ controlled by the php-apache deployment we created in the first step of these in
Roughly speaking, HPA will increase and decrease the number of replicas
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
-See [here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
+See [here](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
```shell
$ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
diff --git a/docs/tasks/run-application/horizontal-pod-autoscale.md b/docs/tasks/run-application/horizontal-pod-autoscale.md
index 49d51758f1..fcce446a72 100644
--- a/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -46,7 +46,7 @@ or the custom metrics API (for all other metrics).
Please note that if some of the pod's containers do not have the relevant resource request set,
CPU utilization for the pod will not be defined and the autoscaler will not take any action
- for that metric. See the [autoscaling algorithm design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for further
+ for that metric. See the [autoscaling algorithm design document](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm) for further
details about how the autoscaling algorithm works.
* For per-pod custom metrics, the controller functions similarly to per-pod resource metrics,
@@ -66,7 +66,7 @@ See [Support for custom metrics](#prerequisites) for more details on REST client
The autoscaler accesses corresponding replication controller, deployment or replica set by scale sub-resource.
Scale is an interface that allows you to dynamically set the number of replicas and examine each of their current states.
-More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#scale-subresource).
+More details on scale sub-resource can be found [here](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#scale-subresource).
## API Object
@@ -80,7 +80,7 @@ can be found in `autoscaling/v2alpha1`. The new fields introduced in `autoscalin
are preserved as annotations when working with `autoscaling/v1`.
More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
## Support for Horizontal Pod Autoscaler in kubectl
@@ -141,6 +141,6 @@ available at [the k8s.io/metrics repository](https://github.com/kubernetes/metri
## Further reading
-* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md).
+* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/horizontal-pod-autoscaler.md).
* kubectl autoscale command: [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale).
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
diff --git a/docs/tasks/run-application/mysql-deployment.yaml b/docs/tasks/run-application/mysql-deployment.yaml
index 8be6ae7b3d..19e102947f 100644
--- a/docs/tasks/run-application/mysql-deployment.yaml
+++ b/docs/tasks/run-application/mysql-deployment.yaml
@@ -16,6 +16,7 @@ metadata:
spec:
accessModes:
- ReadWriteOnce
+ storageClassName: ""
resources:
requests:
storage: 20Gi
diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md
index 37df460f13..1eb797bee2 100644
--- a/docs/tasks/run-application/rolling-update-replication-controller.md
+++ b/docs/tasks/run-application/rolling-update-replication-controller.md
@@ -21,7 +21,7 @@ which in turn uses a
For more information, see
[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
-To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
+To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
@@ -161,7 +161,7 @@ spec:
- containerPort: 80
```
-To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) to specify the new image:
+To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) to specify the new image:
```shell
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
diff --git a/docs/tasks/tools/install-kubectl.md b/docs/tasks/tools/install-kubectl.md
index 4c84c348fd..df655eb7a5 100644
--- a/docs/tasks/tools/install-kubectl.md
+++ b/docs/tasks/tools/install-kubectl.md
@@ -183,12 +183,10 @@ Follow the "caveats" section of brew's output to add the appropriate bash comple
If you've installed kubectl using the [Homebrew instructions](#install-with-homebrew-on-macos) then kubectl completion should start working immediately.
-If you have installed kubectl manually, then run: `source <(kubectl completion bash)`
-
-To add kubectl autocompletion to your profile (so it is automatically loaded in future shells):
+If you have installed kubectl manually, you need to add kubectl autocompletion to the bash-completion:
```shell
-echo "source <(kubectl completion bash)" >> ~/.bash_profile
+kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl
```
The Homebrew project is independent from kubernetes, so the bash-completion packages are not guaranteed to work.
diff --git a/docs/tasks/tools/install-minikube.md b/docs/tasks/tools/install-minikube.md
index 61dfc17139..3246073871 100644
--- a/docs/tasks/tools/install-minikube.md
+++ b/docs/tasks/tools/install-minikube.md
@@ -21,7 +21,7 @@ VT-x or AMD-v virtualization must be enabled in your computer's BIOS.
If you do not already have a hypervisor installed, install one now.
* For OS X, install
-[xhyve driver](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#xhyve-driver),
+[xhyve driver](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver),
[VirtualBox](https://www.virtualbox.org/wiki/Downloads), or
[VMware Fusion](https://www.vmware.com/products/fusion).
diff --git a/docs/tutorials/clusters/apparmor.md b/docs/tutorials/clusters/apparmor.md
index a6ec38868f..16967924b1 100644
--- a/docs/tutorials/clusters/apparmor.md
+++ b/docs/tutorials/clusters/apparmor.md
@@ -302,7 +302,7 @@ nodes. There are lots of ways to setup the profiles though, such as:
* Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to
ensure the correct profiles are loaded. An example implementation can be found
- [here](https://github.com/kubernetes/contrib/tree/master/apparmor/loader).
+ [here](https://git.k8s.io/contrib/apparmor/loader).
* At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or
image.
* By copying the profiles to each node and loading them through SSH, as demonstrated in the
diff --git a/docs/tutorials/example-tutorial-template.md b/docs/tutorials/example-tutorial-template.md
index 1c2d9eb714..d92d59310d 100644
--- a/docs/tutorials/example-tutorial-template.md
+++ b/docs/tutorials/example-tutorial-template.md
@@ -1,25 +1,35 @@
---
title: Example Tutorial Template
+assignees:
+- chenopis
---
{% capture overview %}
+
**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
This page shows how to ...
+
{% endcapture %}
{% capture prerequisites %}
+
+* {% include task-tutorial-prereqs.md %}
* Do this.
* Do this too.
+
{% endcapture %}
{% capture objectives %}
+
* Learn this.
* Build this.
* Run this.
+
{% endcapture %}
{% capture lessoncontent %}
+
## Building ...
1. Do this.
@@ -32,20 +42,25 @@ This page shows how to ...
## Understanding the code
Here's something interesting about the code you ran in the preceding steps.
+
{% endcapture %}
{% capture cleanup %}
+
**[Optional Section]**
* Delete this.
* Stop this.
+
{% endcapture %}
{% capture whatsnext %}
+
**[Optional Section]**
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Tutorial template](/docs/home/contribute/page-templates/#tutorial_template) for how to use this template.
+
{% endcapture %}
{% include templates/tutorial.md %}
\ No newline at end of file
diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md
index 6a750a37bf..378c06358a 100644
--- a/docs/tutorials/index.md
+++ b/docs/tutorials/index.md
@@ -1,5 +1,8 @@
---
title: Tutorials
+redirect_from:
+- "/docs/samples/"
+- "/docs/samples.html"
---
This section of the Kubernetes documentation contains tutorials.
@@ -17,6 +20,8 @@ each of which has a sequence of steps.
* [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/)
+* [Example: PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
+
* [Using a Service to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address-service/)
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
@@ -29,6 +34,10 @@ each of which has a sequence of steps.
* [Running a Replicated Stateful Application](/docs/tutorials/stateful-application/run-replicated-stateful-application/)
+* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
+
+* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
+
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
#### Connecting Applications
diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
index 7c6b0e304c..1a0657d087 100644
--- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
+++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
@@ -575,7 +575,7 @@ Add, delete, or update individual elements. This does not preserve ordering.
This merge strategy uses a special tag on each field called a `patchMergeKey`. The
`patchMergeKey` is defined for each field in the Kubernetes source code:
-[types.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2119)
+[types.go](https://git.k8s.io/kubernetes/pkg/api/v1/types.go#L2119)
When merging a list of maps, the field specified as the `patchMergeKey` for a given element
is used like a map key for that element.
@@ -649,7 +649,7 @@ by `name`.
As of Kubernetes 1.5, merging lists of primitive elements is not supported.
**Note:** Which of the above strategies is chosen for a given field is controlled by
-the `patchStrategy` tag in [types.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go#L2119)
+the `patchStrategy` tag in [types.go](https://git.k8s.io/kubernetes/pkg/api/v1/types.go#L2119)
If no `patchStrategy` is specified for a field of type list, then
the list is replaced.
diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
index 67ccfa1ee8..d4a0837e1c 100644
--- a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
+++ b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md
@@ -85,7 +85,7 @@ however they require a better understanding of the Kubernetes object schema.
- `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor.
- `patch`: Directly modify specific fields of a live object by using a patch string.
For more details on patch strings, see the patch section in
-[API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#patch-operations).
+[API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations).
## How to delete objects
diff --git a/docs/tutorials/stateful-application/cassandra.md b/docs/tutorials/stateful-application/cassandra.md
new file mode 100644
index 0000000000..3d3b9f7c6b
--- /dev/null
+++ b/docs/tutorials/stateful-application/cassandra.md
@@ -0,0 +1,859 @@
+---
+title: "Example: Deploying Cassandra with Stateful Sets"
+---
+
+## Table of Contents
+
+ - [Prerequisites](#prerequisites)
+ - [Cassandra Docker](#cassandra-docker)
+ - [Quickstart](#quickstart)
+ - [Step 1: Create a Cassandra Headless Service](#step-1-create-a-cassandra-headless-service)
+ - [Step 2: Use a StatefulSet to create Cassandra Ring](#step-2-use-a-statefulset-to-create-cassandra-ring)
+ - [Step 3: Validate and Modify The Cassandra StatefulSet](#step-3-validate-and-modify-the-cassandra-statefulset)
+ - [Step 4: Delete Cassandra StatefulSet](#step-4-delete-cassandra-statefulset)
+ - [Step 5: Use a Replication Controller to create Cassandra node pods](#step-5-use-a-replication-controller-to-create-cassandra-node-pods)
+ - [Step 6: Scale up the Cassandra cluster](#step-6-scale-up-the-cassandra-cluster)
+ - [Step 7: Delete the Replication Controller](#step-7-delete-the-replication-controller)
+ - [Step 8: Use a DaemonSet instead of a Replication Controller](#step-8-use-a-daemonset-instead-of-a-replication-controller)
+ - [Step 9: Resource Cleanup](#step-9-resource-cleanup)
+ - [Seed Provider Source](#seed-provider-source)
+
+The following document describes the development of a _cloud native_
+[Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. When we say
+_cloud native_, we mean an application which understands that it is running
+within a cluster manager, and uses this cluster management infrastructure to
+help implement the application. In particular, in this instance, a custom
+Cassandra `SeedProvider` is used to enable Cassandra to dynamically discover
+new Cassandra nodes as they join the cluster.
+
+This example also uses some of the core components of Kubernetes:
+
+- [_Pods_](/docs/user-guide/pods)
+- [ _Services_](/docs/user-guide/services)
+- [_Replication Controllers_](/docs/user-guide/replication-controller)
+- [_Stateful Sets_](/docs/concepts/workloads/controllers/statefulset/)
+- [_Daemon Sets_](/docs/admin/daemons)
+
+## Prerequisites
+
+This example assumes that you have a Kubernetes version >=1.2 cluster installed and running,
+and that you have installed the [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
+command line tool somewhere in your path. Please see the
+[getting started guides](https://kubernetes.io/docs/getting-started-guides/)
+for installation instructions for your platform.
+
+This example also has a few code and configuration files needed. To avoid
+typing these out, you can `git clone` the Kubernetes repository to your local
+computer.
+
+## Cassandra Docker
+
+The pods use the [```gcr.io/google-samples/cassandra:v12```](image/Dockerfile)
+image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
+The docker is based on `debian:jessie` and includes OpenJDK 8. This image
+includes a standard Cassandra installation from the Apache Debian repo. Through the use of environment variables you are able to change values that are inserted into the `cassandra.yaml`.
+
+| ENV VAR | DEFAULT VALUE |
+| ------------- |:-------------: |
+| CASSANDRA_CLUSTER_NAME | 'Test Cluster' |
+| CASSANDRA_NUM_TOKENS | 32 |
+| CASSANDRA_RPC_ADDRESS | 0.0.0.0 |
+
+## Quickstart
+
+If you want to jump straight to the commands we will run,
+here are the steps:
+
+```sh
+#
+# StatefulSet
+#
+
+# clone the example repository
+git clone https://github.com/kubernetes/examples
+cd examples
+
+# create a service to track all cassandra statefulset nodes
+kubectl create -f cassandra/cassandra-service.yaml
+
+# create a statefulset
+kubectl create -f cassandra/cassandra-statefulset.yaml
+
+# validate the Cassandra cluster. Substitute the name of one of your pods.
+kubectl exec -ti cassandra-0 -- nodetool status
+
+# cleanup
+grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}') \
+ && kubectl delete statefulset,po -l app=cassandra \
+ && echo "Sleeping $grace" \
+ && sleep $grace \
+ && kubectl delete pvc -l app=cassandra
+
+#
+# Resource Controller Example
+#
+
+# create a replication controller to replicate cassandra nodes
+kubectl create -f cassandra/cassandra-controller.yaml
+
+# validate the Cassandra cluster. Substitute the name of one of your pods.
+kubectl exec -ti cassandra-xxxxx -- nodetool status
+
+# scale up the Cassandra cluster
+kubectl scale rc cassandra --replicas=4
+
+# delete the replication controller
+kubectl delete rc cassandra
+
+#
+# Create a DaemonSet to place a cassandra node on each kubernetes node
+#
+
+kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false
+
+# resource cleanup
+kubectl delete service -l app=cassandra
+kubectl delete daemonset cassandra
+```
+
+## Step 1: Create a Cassandra Headless Service
+
+A Kubernetes _[Service](/docs/user-guide/services)_ describes a set of
+[_Pods_](/docs/user-guide/pods) that perform the same task. In
+Kubernetes, the atomic unit of an application is a Pod: one or more containers
+that _must_ be scheduled onto the same host.
+
+The Service is used for DNS lookups between Cassandra Pods, and Cassandra clients
+within the Kubernetes Cluster.
+
+Here is the service description:
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ labels:
+ app: cassandra
+ name: cassandra
+spec:
+ clusterIP: None
+ ports:
+ - port: 9042
+ selector:
+ app: cassandra
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-service.yaml)
+
+
+Create the service for the StatefulSet:
+
+
+```console
+$ kubectl create -f cassandra/cassandra-service.yaml
+```
+
+The following command shows if the service has been created.
+
+```console
+$ kubectl get svc cassandra
+```
+
+The response should be like:
+
+```console
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+cassandra None 9042/TCP 45s
+```
+
+If an error is returned the service create failed.
+
+## Step 2: Use a StatefulSet to create Cassandra Ring
+
+StatefulSets (previously PetSets) are a feature that was upgraded to a Beta component in
+Kubernetes 1.5. Deploying stateful distributed applications, like Cassandra, within a clustered
+environment can be challenging. We implemented StatefulSet to greatly simplify this
+process. Multiple StatefulSet features are used within this example, but is out of
+scope of this documentation. [Please refer to the Stateful Set documentation.](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
+
+The StatefulSet manifest that is included below, creates a Cassandra ring that consists
+of three pods.
+
+This example includes using a GCE Storage Class, please update appropriately depending
+on the cloud you are working with.
+
+
+
+```yaml
+apiVersion: "apps/v1beta1"
+kind: StatefulSet
+metadata:
+ name: cassandra
+spec:
+ serviceName: cassandra
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ containers:
+ - name: cassandra
+ image: gcr.io/google-samples/cassandra:v12
+ imagePullPolicy: Always
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ resources:
+ limits:
+ cpu: "500m"
+ memory: 1Gi
+ requests:
+ cpu: "500m"
+ memory: 1Gi
+ securityContext:
+ capabilities:
+ add:
+ - IPC_LOCK
+ lifecycle:
+ preStop:
+ exec:
+ command: ["/bin/sh", "-c", "PID=$(pidof java) && kill $PID && while ps -p $PID > /dev/null; do sleep 1; done"]
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEEDS
+ value: "cassandra-0.cassandra.default.svc.cluster.local"
+ - name: CASSANDRA_CLUSTER_NAME
+ value: "K8Demo"
+ - name: CASSANDRA_DC
+ value: "DC1-K8Demo"
+ - name: CASSANDRA_RACK
+ value: "Rack1-K8Demo"
+ - name: CASSANDRA_AUTO_BOOTSTRAP
+ value: "false"
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ readinessProbe:
+ exec:
+ command:
+ - /bin/bash
+ - -c
+ - /ready-probe.sh
+ initialDelaySeconds: 15
+ timeoutSeconds: 5
+ # These volume mounts are persistent. They are like inline claims,
+ # but not exactly because the names need to match exactly one of
+ # the stateful pod volumes.
+ volumeMounts:
+ - name: cassandra-data
+ mountPath: /cassandra_data
+ # These are converted to volume claims by the controller
+ # and mounted at the paths mentioned above.
+ # do not use these in production until ssd GCEPersistentDisk or other ssd pd
+ volumeClaimTemplates:
+ - metadata:
+ name: cassandra-data
+ annotations:
+ volume.beta.kubernetes.io/storage-class: fast
+ spec:
+ accessModes: [ "ReadWriteOnce" ]
+ resources:
+ requests:
+ storage: 1Gi
+---
+kind: StorageClass
+apiVersion: storage.k8s.io/v1beta1
+metadata:
+ name: fast
+provisioner: kubernetes.io/gce-pd
+parameters:
+ type: pd-ssd
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-statefulset.yaml)
+
+
+Create the Cassandra StatefulSet as follows:
+
+```console
+$ kubectl create -f cassandra/cassandra-statefulset.yaml
+```
+
+## Step 3: Validate and Modify The Cassandra StatefulSet
+
+Deploying this StatefulSet shows off two of the new features that StatefulSets provides.
+
+1. The pod names are known
+2. The pods deploy in incremental order
+
+First validate that the StatefulSet has deployed, by running `kubectl` command below.
+
+```console
+$ kubectl get statefulset cassandra
+```
+
+The command should respond like:
+
+```console
+NAME DESIRED CURRENT AGE
+cassandra 3 3 13s
+```
+
+Next watch the Cassandra pods deploy, one after another. The StatefulSet resource
+deploys pods in a number fashion: 1, 2, 3, etc. If you execute the following
+command before the pods deploy you are able to see the ordered creation.
+
+```console
+$ kubectl get pods -l="app=cassandra"
+NAME READY STATUS RESTARTS AGE
+cassandra-0 1/1 Running 0 1m
+cassandra-1 0/1 ContainerCreating 0 8s
+```
+
+The above example shows two of the three pods in the Cassandra StatefulSet deployed.
+Once all of the pods are deployed the same command will respond with the full
+StatefulSet.
+
+```console
+$ kubectl get pods -l="app=cassandra"
+NAME READY STATUS RESTARTS AGE
+cassandra-0 1/1 Running 0 10m
+cassandra-1 1/1 Running 0 9m
+cassandra-2 1/1 Running 0 8m
+```
+
+Running the Cassandra utility `nodetool` will display the status of the ring.
+
+```console
+$ kubectl exec cassandra-0 -- nodetool status
+Datacenter: DC1-K8Demo
+======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.4.2.4 65.26 KiB 32 63.7% a9d27f81-6783-461d-8583-87de2589133e Rack1-K8Demo
+UN 10.4.0.4 102.04 KiB 32 66.7% 5559a58c-8b03-47ad-bc32-c621708dc2e4 Rack1-K8Demo
+UN 10.4.1.4 83.06 KiB 32 69.6% 9dce943c-581d-4c0e-9543-f519969cc805 Rack1-K8Demo
+```
+
+You can also run `cqlsh` to describe the keyspaces in the cluster.
+
+```console
+$ kubectl exec cassandra-0 -- cqlsh -e 'desc keyspaces'
+
+system_traces system_schema system_auth system system_distributed
+```
+
+In order to increase or decrease the size of the Cassandra StatefulSet, you must use
+`kubectl edit`. You can find more information about the edit command in the [documentation](/docs/user-guide/kubectl/kubectl_edit).
+
+Use the following command to edit the StatefulSet.
+
+```console
+$ kubectl edit statefulset cassandra
+```
+
+This will create an editor in your terminal. The line you are looking to change is
+`replicas`. The example does on contain the entire contents of the terminal window, and
+the last line of the example below is the replicas line that you want to change.
+
+```console
+# Please edit the object below. Lines beginning with a '#' will be ignored,
+# and an empty file will abort the edit. If an error occurs while saving this file will be
+# reopened with the relevant failures.
+#
+apiVersion: apps/v1beta1
+kind: StatefulSet
+metadata:
+ creationTimestamp: 2016-08-13T18:40:58Z
+ generation: 1
+ labels:
+ app: cassandra
+ name: cassandra
+ namespace: default
+ resourceVersion: "323"
+ selfLink: /apis/apps/v1beta1/namespaces/default/statefulsets/cassandra
+ uid: 7a219483-6185-11e6-a910-42010a8a0fc0
+spec:
+ replicas: 3
+```
+
+Modify the manifest to the following, and save the manifest.
+
+```console
+spec:
+ replicas: 4
+```
+
+The StatefulSet will now contain four pods.
+
+```console
+$ kubectl get statefulset cassandra
+```
+
+The command should respond like:
+
+```console
+NAME DESIRED CURRENT AGE
+cassandra 4 4 36m
+```
+
+For the Kubernetes 1.5 release, the beta StatefulSet resource does not have `kubectl scale`
+functionality, like a Deployment, ReplicaSet, Replication Controller, or Job.
+
+## Step 4: Delete Cassandra StatefulSet
+
+Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related StatefulSet resources. Deleting the Persistent Volume Claims may result in a deletion of the associated volumes, depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+
+Use the following commands to delete the StatefulSet.
+
+```console
+$ grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}') \
+ && kubectl delete statefulset -l app=cassandra \
+ && echo "Sleeping $grace" \
+ && sleep $grace \
+ && kubectl delete pvc -l app=cassandra
+```
+
+## Step 5: Use a Replication Controller to create Cassandra node pods
+
+A Kubernetes
+_[Replication Controller](/docs/user-guide/replication-controller)_
+is responsible for replicating sets of identical pods. Like a
+Service, it has a selector query which identifies the members of its set.
+Unlike a Service, it also has a desired number of replicas, and it will create
+or delete Pods to ensure that the number of Pods matches up with its
+desired state.
+
+The Replication Controller, in conjunction with the Service we just defined,
+will let us easily build a replicated, scalable Cassandra cluster.
+
+Let's create a replication controller with two initial replicas.
+
+
+
+```yaml
+apiVersion: v1
+kind: ReplicationController
+metadata:
+ name: cassandra
+ # The labels will be applied automatically
+ # from the labels in the pod template, if not set
+ # labels:
+ # app: cassandra
+spec:
+ replicas: 2
+ # The selector will be applied automatically
+ # from the labels in the pod template, if not set.
+ # selector:
+ # app: cassandra
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ containers:
+ - command:
+ - /run.sh
+ resources:
+ limits:
+ cpu: 0.5
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEED_PROVIDER
+ value: "io.k8s.cassandra.KubernetesSeedProvider"
+ - name: POD_NAMESPACE
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.namespace
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ image: gcr.io/google-samples/cassandra:v12
+ name: cassandra
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ volumeMounts:
+ - mountPath: /cassandra_data
+ name: data
+ volumes:
+ - name: data
+ emptyDir: {}
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-controller.yaml)
+
+
+There are a few things to note in this description.
+
+The `selector` attribute contains the controller's selector query. It can be
+explicitly specified, or applied automatically from the labels in the pod
+template if not set, as is done here.
+
+The pod template's label, `app:cassandra`, matches the Service selector
+from Step 1. This is how pods created by this replication controller are picked up
+by the Service."
+
+The `replicas` attribute specifies the desired number of replicas, in this
+case 2 initially. We'll scale up to more shortly.
+
+Create the Replication Controller:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-controller.yaml
+
+```
+
+You can list the new controller:
+
+```console
+
+$ kubectl get rc -o wide
+NAME DESIRED CURRENT AGE CONTAINER(S) IMAGE(S) SELECTOR
+cassandra 2 2 11s cassandra gcr.io/google-samples/cassandra:v12 app=cassandra
+
+```
+
+Now if you list the pods in your cluster, and filter to the label
+`app=cassandra`, you should see two Cassandra pods. (The `wide` argument lets
+you see which Kubernetes nodes the pods were scheduled onto.)
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-21qyy 1/1 Running 0 1m kubernetes-minion-b286
+cassandra-q6sz7 1/1 Running 0 1m kubernetes-minion-9ye5
+
+```
+
+Because these pods have the label `app=cassandra`, they map to the service we
+defined in Step 1.
+
+You can check that the Pods are visible to the Service using the following service endpoints query:
+
+```console
+
+$ kubectl get endpoints cassandra -o yaml
+apiVersion: v1
+kind: Endpoints
+metadata:
+ creationTimestamp: 2015-06-21T22:34:12Z
+ labels:
+ app: cassandra
+ name: cassandra
+ namespace: default
+ resourceVersion: "944373"
+ selfLink: /api/v1/namespaces/default/endpoints/cassandra
+ uid: a3d6c25f-1865-11e5-a34e-42010af01bcc
+subsets:
+- addresses:
+ - ip: 10.244.3.15
+ targetRef:
+ kind: Pod
+ name: cassandra
+ namespace: default
+ resourceVersion: "944372"
+ uid: 9ef9895d-1865-11e5-a34e-42010af01bcc
+ ports:
+ - port: 9042
+ protocol: TCP
+
+```
+
+To show that the `SeedProvider` logic is working as intended, you can use the
+`nodetool` command to examine the status of the Cassandra cluster. To do this,
+use the `kubectl exec` command, which lets you run `nodetool` in one of your
+Cassandra pods. Again, substitute `cassandra-xxxxx` with the actual name of one
+of your pods.
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1
+UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1
+
+```
+
+## Step 6: Scale up the Cassandra cluster
+
+Now let's scale our Cassandra cluster to 4 pods. We do this by telling the
+Replication Controller that we now want 4 replicas.
+
+```sh
+
+$ kubectl scale rc cassandra --replicas=4
+
+```
+
+You can see the new pods listed:
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-21qyy 1/1 Running 0 6m kubernetes-minion-b286
+cassandra-81m2l 1/1 Running 0 47s kubernetes-minion-b286
+cassandra-8qoyp 1/1 Running 0 47s kubernetes-minion-9ye5
+cassandra-q6sz7 1/1 Running 0 6m kubernetes-minion-9ye5
+
+```
+
+In a few moments, you can examine the Cassandra cluster status again, and see
+that the new pods have been detected by the custom `SeedProvider`:
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.6 51.67 KB 256 48.9% d07b23a5-56a1-4b0b-952d-68ab95869163 rack1
+UN 10.244.1.5 84.71 KB 256 50.7% e060df1f-faa2-470c-923d-ca049b0f3f38 rack1
+UN 10.244.1.6 84.71 KB 256 47.0% 83ca1580-4f3c-4ec5-9b38-75036b7a297f rack1
+UN 10.244.0.5 68.2 KB 256 53.4% 72ca27e2-c72c-402a-9313-1e4b61c2f839 rack1
+
+```
+
+## Step 7: Delete the Replication Controller
+
+Before you start Step 5, __delete the replication controller__ you created above:
+
+```sh
+
+$ kubectl delete rc cassandra
+
+```
+
+## Step 8: Use a DaemonSet instead of a Replication Controller
+
+In Kubernetes, a [_Daemon Set_](/docs/admin/daemons) can distribute pods
+onto Kubernetes nodes, one-to-one. Like a _ReplicationController_, it has a
+selector query which identifies the members of its set. Unlike a
+_ReplicationController_, it has a node selector to limit which nodes are
+scheduled with the templated pods, and replicates not based on a set target
+number of pods, but rather assigns a single pod to each targeted node.
+
+An example use case: when deploying to the cloud, the expectation is that
+instances are ephemeral and might die at any time. Cassandra is built to
+replicate data across the cluster to facilitate data redundancy, so that in the
+case that an instance dies, the data stored on the instance does not, and the
+cluster can react by re-replicating the data to other running nodes.
+
+`DaemonSet` is designed to place a single pod on each node in the Kubernetes
+cluster. That will give us data redundancy. Let's create a
+DaemonSet to start our storage cluster:
+
+
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: DaemonSet
+metadata:
+ labels:
+ name: cassandra
+ name: cassandra
+spec:
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ # Filter to specific nodes:
+ # nodeSelector:
+ # app: cassandra
+ containers:
+ - command:
+ - /run.sh
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEED_PROVIDER
+ value: "io.k8s.cassandra.KubernetesSeedProvider"
+ - name: POD_NAMESPACE
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.namespace
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ image: gcr.io/google-samples/cassandra:v12
+ name: cassandra
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ # If you need it it is going away in C* 4.0
+ #- containerPort: 9160
+ # name: thrift
+ resources:
+ requests:
+ cpu: 0.5
+ volumeMounts:
+ - mountPath: /cassandra_data
+ name: data
+ volumes:
+ - name: data
+ emptyDir: {}
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-daemonset.yaml)
+
+
+Most of this DaemonSet definition is identical to the ReplicationController
+definition above; it simply gives the daemon set a recipe to use when it creates
+new Cassandra pods, and targets all Cassandra nodes in the cluster.
+
+Differentiating aspects are the `nodeSelector` attribute, which allows the
+DaemonSet to target a specific subset of nodes (you can label nodes just like
+other resources), and the lack of a `replicas` attribute due to the 1-to-1 node-
+pod relationship.
+
+Create this DaemonSet:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-daemonset.yaml
+
+```
+
+You may need to disable config file validation, like so:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false
+
+```
+
+You can see the DaemonSet running:
+
+```console
+
+$ kubectl get daemonset
+NAME DESIRED CURRENT NODE-SELECTOR
+cassandra 3 3
+
+```
+
+Now, if you list the pods in your cluster, and filter to the label
+`app=cassandra`, you should see one (and only one) new cassandra pod for each
+node in your network.
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-ico4r 1/1 Running 0 4s kubernetes-minion-rpo1
+cassandra-kitfh 1/1 Running 0 1s kubernetes-minion-9ye5
+cassandra-tzw89 1/1 Running 0 2s kubernetes-minion-b286
+
+```
+
+To prove that this all worked as intended, you can again use the `nodetool`
+command to examine the status of the cluster. To do this, use the `kubectl
+exec` command to run `nodetool` in one of your newly-launched cassandra pods.
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1
+UN 10.244.4.2 32.45 KB 256 100.0% 0b1be71a-6ffb-4895-ac3e-b9791299c141 rack1
+UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1
+
+```
+
+**Note**: This example had you delete the cassandra Replication Controller before
+you created the DaemonSet. This is because – to keep this example simple – the
+RC and the DaemonSet are using the same `app=cassandra` label (so that their pods map to the
+service we created, and so that the SeedProvider can identify them).
+
+If we didn't delete the RC first, the two resources would conflict with
+respect to how many pods they wanted to have running. If we wanted, we could support running
+both together by using additional labels and selectors.
+
+## Step 9: Resource Cleanup
+
+When you are ready to take down your resources, do the following:
+
+```console
+
+$ kubectl delete service -l app=cassandra
+$ kubectl delete daemonset cassandra
+
+```
+
+### Custom Seed Provider
+
+A custom [`SeedProvider`](https://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/locator/SeedProvider.java)
+is included for running Cassandra on top of Kubernetes. Only when you deploy Cassandra
+via a replication control or a daemonset, you will need to use the custom seed provider.
+In Cassandra, a `SeedProvider` bootstraps the gossip protocol that Cassandra uses to find other
+Cassandra nodes. Seed addresses are hosts deemed as contact points. Cassandra
+instances use the seed list to find each other and learn the topology of the
+ring. The [`KubernetesSeedProvider`](java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)
+discovers Cassandra seeds IP addresses via the Kubernetes API, those Cassandra
+instances are defined within the Cassandra Service.
+
+Refer to the custom seed provider [README](https://git.k8s.io/examples/cassandra/java/README.md) for further
+`KubernetesSeedProvider` configurations. For this example you should not need
+to customize the Seed Provider configurations.
+
+See the [image](image/) directory of this example for specifics on
+how the container docker image was built and what it contains.
+
+You may also note that we are setting some Cassandra parameters (`MAX_HEAP_SIZE`
+and `HEAP_NEWSIZE`), and adding information about the
+[namespace](/docs/user-guide/namespaces).
+We also tell Kubernetes that the container exposes
+both the `CQL` and `Thrift` API ports. Finally, we tell the cluster
+manager that we need 0.1 cpu (0.1 core).
+
+
+
+[]()
+
diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
new file mode 100644
index 0000000000..d8d4da9f46
--- /dev/null
+++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -0,0 +1,369 @@
+---
+title: "Example: WordPress and MySQL with Persistent Volumes"
+assignees:
+- ahmetb
+- jeffmendoza
+---
+
+This example describes how to run a persistent installation of
+[WordPress](https://wordpress.org/) and
+[MySQL](https://www.mysql.com/) on Kubernetes. We'll use the
+[mysql](https://registry.hub.docker.com/_/mysql/) and
+[wordpress](https://registry.hub.docker.com/_/wordpress/) official
+[Docker](https://www.docker.com/) images for this installation. (The
+WordPress image includes an Apache server).
+
+Demonstrated Kubernetes Concepts:
+
+* [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) to
+ define persistent disks (disk lifecycle not tied to the Pods).
+* [Services](https://kubernetes.io/docs/concepts/services-networking/service/) to enable Pods to
+ locate one another.
+* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer)
+ to expose Services externally.
+* [Deployments](http://kubernetes.io/docs/user-guide/deployments/) to ensure Pods
+ stay up and running.
+* [Secrets](http://kubernetes.io/docs/user-guide/secrets/) to store sensitive
+ passwords.
+
+## Quickstart
+
+Put your desired MySQL password in a file called `password.txt` with
+no trailing newline. The first `tr` command will remove the newline if
+your editor added one.
+
+**Note:** if your cluster enforces **_selinux_** and you will be using [Host Path](#host-path) for storage, then please follow this [extra step](#selinux).
+
+```shell
+tr --delete '\n' .strippedpassword.txt && mv .strippedpassword.txt password.txt
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/local-volumes.yaml
+kubectl create secret generic mysql-pass --from-file=password.txt
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/mysql-deployment.yaml
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/wordpress-deployment.yaml
+```
+
+## Table of Contents
+
+
+
+- [Persistent Installation of MySQL and WordPress on Kubernetes](#persistent-installation-of-mysql-and-wordpress-on-kubernetes)
+ - [Quickstart](#quickstart)
+ - [Table of Contents](#table-of-contents)
+ - [Cluster Requirements](#cluster-requirements)
+ - [Decide where you will store your data](#decide-where-you-will-store-your-data)
+ - [Host Path](#host-path)
+ - [SELinux](#selinux)
+ - [GCE Persistent Disk](#gce-persistent-disk)
+ - [Create the MySQL Password Secret](#create-the-mysql-password-secret)
+ - [Deploy MySQL](#deploy-mysql)
+ - [Deploy WordPress](#deploy-wordpress)
+ - [Visit your new WordPress blog](#visit-your-new-wordpress-blog)
+ - [Take down and restart your blog](#take-down-and-restart-your-blog)
+ - [Next Steps](#next-steps)
+
+
+
+## Cluster Requirements
+
+Kubernetes runs in a variety of environments and is inherently
+modular. Not all clusters are the same. These are the requirements for
+this example.
+
+* Kubernetes version 1.2 is required due to using newer features, such
+ at PV Claims and Deployments. Run `kubectl version` to see your
+ cluster version.
+* [Cluster DNS](https://github.com/kubernetes/dns) will be used for service discovery.
+* An [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer)
+ will be used to access WordPress.
+* [Persistent Volume Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+ are used. You must create Persistent Volumes in your cluster to be
+ claimed. This example demonstrates how to create two types of
+ volumes, but any volume is sufficient.
+
+Consult a
+[Getting Started Guide](http://kubernetes.io/docs/getting-started-guides/)
+to set up a cluster and the
+[kubectl](http://kubernetes.io/docs/user-guide/prereqs/) command-line client.
+
+## Decide where you will store your data
+
+MySQL and WordPress will each use a
+[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+to store their data. We will use a Persistent Volume Claim to claim an
+available persistent volume. This example covers HostPath and
+GCEPersistentDisk volumes. Choose one of the two, or see
+[Types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes)
+for more options.
+
+### Host Path
+
+Host paths are volumes mapped to directories on the host. **These
+should be used for testing or single-node clusters only**. The data
+will not be moved between nodes if the pod is recreated on a new
+node. If the pod is deleted and recreated on a new node, data will be
+lost.
+
+##### SELinux
+
+On systems supporting selinux it is preferred to leave it enabled/enforcing.
+However, docker containers mount the host path with the "_svirt_sandbox_file_t_"
+label type, which is incompatible with the default label type for /tmp ("_tmp_t_"),
+resulting in a permissions error when the mysql container attempts to `chown`
+_/var/lib/mysql_.
+Therefore, on selinx systems using host path, you should pre-create the host path
+directory (/tmp/data/) and change it's selinux label type to "_svirt_sandbox_file_t_",
+as follows:
+
+```shell
+## on every node:
+mkdir -p /tmp/data
+chmod a+rwt /tmp/data # match /tmp permissions
+chcon -Rt svirt_sandbox_file_t /tmp/data
+```
+
+Continuing with host path, create the persistent volume objects in Kubernetes using
+[local-volumes.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/local-volumes.yaml):
+
+```shell
+export KUBE_REPO=https://raw.githubusercontent.com/kubernetes/examples/master
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/local-volumes.yaml
+```
+
+
+### GCE Persistent Disk
+
+This storage option is applicable if you are running on
+[Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/).
+
+Create two persistent disks. You will need to create the disks in the
+same [GCE zone](https://cloud.google.com/compute/docs/zones) as the
+Kubernetes cluster. The default setup script will create the cluster
+in the `us-central1-b` zone, as seen in the
+[config-default.sh](https://git.k8s.io/kubernetes/cluster/gce/config-default.sh) file. Replace
+`` below with the appropriate zone. The names `wordpress-1` and
+`wordpress-2` must match the `pdName` fields we have specified in
+[gce-volumes.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/gce-volumes.yaml).
+
+```shell
+gcloud compute disks create --size=20GB --zone= wordpress-1
+gcloud compute disks create --size=20GB --zone= wordpress-2
+```
+
+Create the persistent volume objects in Kubernetes for those disks:
+
+```shell
+export KUBE_REPO=https://raw.githubusercontent.com/kubernetes/examples/master
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/gce-volumes.yaml
+```
+
+## Create the MySQL Password Secret
+
+Use a [Secret](http://kubernetes.io/docs/user-guide/secrets/) object
+to store the MySQL password. First create a file (in the same directory
+as the wordpress sample files) called
+`password.txt` and save your password in it. Make sure to not have a
+trailing newline at the end of the password. The first `tr` command
+will remove the newline if your editor added one. Then, create the
+Secret object.
+
+```shell
+tr --delete '\n' .strippedpassword.txt && mv .strippedpassword.txt password.txt
+kubectl create secret generic mysql-pass --from-file=password.txt
+```
+
+This secret is referenced by the MySQL and WordPress pod configuration
+so that those pods will have access to it. The MySQL pod will set the
+database password, and the WordPress pod will use the password to
+access the database.
+
+## Deploy MySQL
+
+Now that the persistent disks and secrets are defined, the Kubernetes
+pods can be launched. Start MySQL using
+[mysql-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/mysql-deployment.yaml).
+
+```shell
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/mysql-deployment.yaml
+```
+
+Take a look at [mysql-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/mysql-deployment.yaml), and
+note that we've defined a volume mount for `/var/lib/mysql`, and then
+created a Persistent Volume Claim that looks for a 20G volume. This
+claim is satisfied by any volume that meets the requirements, in our
+case one of the volumes we created above.
+
+Also look at the `env` section and see that we specified the password
+by referencing the secret `mysql-pass` that we created above. Secrets
+can have multiple key:value pairs. Ours has only one key
+`password.txt` which was the name of the file we used to create the
+secret. The [MySQL image](https://hub.docker.com/_/mysql/) sets the
+database password using the `MYSQL_ROOT_PASSWORD` environment
+variable.
+
+It may take a short period before the new pod reaches the `Running`
+state. List all pods to see the status of this new pod.
+
+```shell
+kubectl get pods
+```
+
+```
+NAME READY STATUS RESTARTS AGE
+wordpress-mysql-cqcf4-9q8lo 1/1 Running 0 1m
+```
+
+Kubernetes logs the stderr and stdout for each pod. Take a look at the
+logs for a pod by using `kubectl log`. Copy the pod name from the
+`get pods` command, and then:
+
+```shell
+kubectl logs
+```
+
+```
+...
+2016-02-19 16:58:05 1 [Note] InnoDB: 128 rollback segment(s) are active.
+2016-02-19 16:58:05 1 [Note] InnoDB: Waiting for purge to start
+2016-02-19 16:58:05 1 [Note] InnoDB: 5.6.29 started; log sequence number 1626007
+2016-02-19 16:58:05 1 [Note] Server hostname (bind-address): '*'; port: 3306
+2016-02-19 16:58:05 1 [Note] IPv6 is available.
+2016-02-19 16:58:05 1 [Note] - '::' resolves to '::';
+2016-02-19 16:58:05 1 [Note] Server socket created on IP: '::'.
+2016-02-19 16:58:05 1 [Warning] 'proxies_priv' entry '@ root@wordpress-mysql-cqcf4-9q8lo' ignored in --skip-name-resolve mode.
+2016-02-19 16:58:05 1 [Note] Event Scheduler: Loaded 0 events
+2016-02-19 16:58:05 1 [Note] mysqld: ready for connections.
+Version: '5.6.29' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)
+```
+
+Also in [mysql-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/mysql-deployment.yaml) we created a
+service to allow other pods to reach this mysql instance. The name is
+`wordpress-mysql` which resolves to the pod IP.
+
+Up to this point one Deployment, one Pod, one PVC, one Service, one Endpoint,
+two PVs, and one Secret have been created, shown below:
+
+```shell
+kubectl get deployment,pod,svc,endpoints,pvc -l app=wordpress -o wide && \
+ kubectl get secret mysql-pass && \
+ kubectl get pv
+```
+
+```shell
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+deploy/wordpress-mysql 1 1 1 1 3m
+NAME READY STATUS RESTARTS AGE IP NODE
+po/wordpress-mysql-3040864217-40soc 1/1 Running 0 3m 172.17.0.2 127.0.0.1
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
+svc/wordpress-mysql None 3306/TCP 3m app=wordpress,tier=mysql
+NAME ENDPOINTS AGE
+ep/wordpress-mysql 172.17.0.2:3306 3m
+NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
+pvc/mysql-pv-claim Bound local-pv-2 20Gi RWO 3m
+NAME TYPE DATA AGE
+mysql-pass Opaque 1 3m
+NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
+local-pv-1 20Gi RWO Available 3m
+local-pv-2 20Gi RWO Bound default/mysql-pv-claim 3m
+```
+
+## Deploy WordPress
+
+Next deploy WordPress using
+[wordpress-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/wordpress-deployment.yaml):
+
+```shell
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/wordpress-deployment.yaml
+```
+
+Here we are using many of the same features, such as a volume claim
+for persistent storage and a secret for the password.
+
+The [WordPress image](https://hub.docker.com/_/wordpress/) accepts the
+database hostname through the environment variable
+`WORDPRESS_DB_HOST`. We set the env value to the name of the MySQL
+service we created: `wordpress-mysql`.
+
+The WordPress service has the setting `type: LoadBalancer`. This will
+set up the wordpress service behind an external IP.
+
+Find the external IP for your WordPress service. **It may take a minute
+to have an external IP assigned to the service, depending on your
+cluster environment.**
+
+```shell
+kubectl get services wordpress
+```
+
+```
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+wordpress 10.0.0.5 1.2.3.4 80/TCP 19h
+```
+
+## Visit your new WordPress blog
+
+Now, we can visit the running WordPress app. Use the external IP of
+the service that you obtained above.
+
+```
+http://
+```
+
+You should see the familiar WordPress init page.
+
+
+
+> Warning: Do not leave your WordPress installation on this page. If
+> it is found by another user, they can set up a website on your
+> instance and use it to serve potentially malicious content. You
+> should either continue with the installation past the point at which
+> you create your username and password, delete your instance, or set
+> up a firewall to restrict access.
+
+## Take down and restart your blog
+
+Set up your WordPress blog and play around with it a bit. Then, take
+down its pods and bring them back up again. Because you used
+persistent disks, your blog state will be preserved.
+
+All of the resources are labeled with `app=wordpress`, so you can
+easily bring them down using a label selector:
+
+```shell
+kubectl delete deployment,service -l app=wordpress
+kubectl delete secret mysql-pass
+```
+
+Later, re-creating the resources with the original commands will pick
+up the original disks with all your data intact. Because we did not
+delete the PV Claims, no other pods in the cluster could claim them
+after we deleted our pods. Keeping the PV Claims also ensured
+recreating the Pods did not cause the PD to switch Pods.
+
+If you are ready to release your persistent volumes and the data on them, run:
+
+```shell
+kubectl delete pvc -l app=wordpress
+```
+
+And then delete the volume objects themselves:
+
+```shell
+kubectl delete pv local-pv-1 local-pv-2
+```
+
+or
+
+```shell
+kubectl delete pv wordpress-pv-1 wordpress-pv-2
+```
+
+## Next Steps
+
+* [Introspection and Debugging](http://kubernetes.io/docs/user-guide/introspection-and-debugging/)
+* [Jobs](http://kubernetes.io/docs/user-guide/jobs/) may be useful to run SQL queries.
+* [Exec](http://kubernetes.io/docs/user-guide/getting-into-containers/)
+* [Port Forwarding](http://kubernetes.io/docs/user-guide/connecting-to-applications-port-forward/)
+
+
+[]()
+
diff --git a/docs/tutorials/stateless-application/guestbook.md b/docs/tutorials/stateless-application/guestbook.md
new file mode 100644
index 0000000000..a91e79029a
--- /dev/null
+++ b/docs/tutorials/stateless-application/guestbook.md
@@ -0,0 +1,707 @@
+---
+title: "Example: PHP Guestbook application with Redis"
+assignees:
+- ahmetb
+- jeffmendoza
+---
+
+
+This example shows how to build a simple, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/).
+
+**Table of Contents**
+
+
+ - [Guestbook Example](#guestbook-example)
+ - [Prerequisites](#prerequisites)
+ - [Quick Start](#quick-start)
+ - [Step One: Start up the redis master](#step-one-start-up-the-redis-master)
+ - [Define a Deployment](#define-a-deployment)
+ - [Define a Service](#define-a-service)
+ - [Create a Service](#create-a-service)
+ - [Finding a Service](#finding-a-service)
+ - [Environment variables](#environment-variables)
+ - [DNS service](#dns-service)
+ - [Create a Deployment](#create-a-deployment)
+ - [Optional Interlude](#optional-interlude)
+ - [Step Two: Start up the redis slave](#step-two-start-up-the-redis-slave)
+ - [Step Three: Start up the guestbook frontend](#step-three-start-up-the-guestbook-frontend)
+ - [Using 'type: LoadBalancer' for the frontend service (cloud-provider-specific)](#using-type-loadbalancer-for-the-frontend-service-cloud-provider-specific)
+ - [Step Four: Cleanup](#step-four-cleanup)
+ - [Troubleshooting](#troubleshooting)
+ - [Appendix: Accessing the guestbook site externally](#appendix-accessing-the-guestbook-site-externally)
+ - [Google Compute Engine External Load Balancer Specifics](#google-compute-engine-external-load-balancer-specifics)
+
+
+
+The example consists of:
+
+- A web frontend
+- A [redis](http://redis.io/) master (for storage), and a replicated set of redis 'slaves'.
+
+The web frontend interacts with the redis master via javascript redis API calls.
+
+**Note**: If you are running this example on a [Google Container Engine](https://cloud.google.com/container-engine/) installation, see [this Google Container Engine guestbook walkthrough](https://cloud.google.com/container-engine/docs/tutorials/guestbook) instead. The basic concepts are the same, but the walkthrough is tailored to a Container Engine setup.
+
+### Prerequisites
+
+This example requires a running Kubernetes cluster. First, check that kubectl is properly configured by getting the cluster state:
+
+```console
+$ kubectl cluster-info
+```
+
+If you see a url response, you are ready to go. If not, read the [Getting Started guides](http://kubernetes.io/docs/getting-started-guides/) for how to get started, and follow the [prerequisites](http://kubernetes.io/docs/user-guide/prereqs/) to install and configure `kubectl`. As noted above, if you have a Google Container Engine cluster set up, read [this example](https://cloud.google.com/container-engine/docs/tutorials/guestbook) instead.
+
+All the files referenced in this example can be downloaded [from GitHub](https://git.k8s.io/examples/guestbook).
+
+### Quick Start
+
+This section shows the simplest way to get the example work. If you want to know the details, you should skip this and read [the rest of the example](#step-one-start-up-the-redis-master).
+
+Start the guestbook with one command:
+
+```console
+$ kubectl create -f guestbook/all-in-one/guestbook-all-in-one.yaml
+service "redis-master" created
+deployment "redis-master" created
+service "redis-slave" created
+deployment "redis-slave" created
+service "frontend" created
+deployment "frontend" created
+```
+
+Alternatively, you can start the guestbook by running:
+
+```console
+$ kubectl create -f guestbook/
+```
+
+Then, list all your Services:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.0.117 80/TCP 20s
+redis-master 10.0.0.170 6379/TCP 20s
+redis-slave 10.0.0.201 6379/TCP 20s
+```
+
+Now you can access the guestbook on each node with frontend Service's `:`, e.g. `10.0.0.117:80` in this guide. `` is a cluster-internal IP. If you want to access the guestbook from outside of the cluster, add `type: NodePort` to the frontend Service `spec` field. Then you can access the guestbook with `:NodePort` from outside of the cluster. On cloud providers which support external load balancers, adding `type: LoadBalancer` to the frontend Service `spec` field will provision a load balancer for your Service. There are several ways for you to access the guestbook. You may learn from [Accessing services running on the cluster](https://kubernetes.io/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
+
+Clean up the guestbook:
+
+```console
+$ kubectl delete -f guestbook/all-in-one/guestbook-all-in-one.yaml
+```
+
+or
+
+```console
+$ kubectl delete -f guestbook/
+```
+
+
+### Step One: Start up the redis master
+
+Before continuing to the gory details, we also recommend you to read Kubernetes [concepts and user guide](http://kubernetes.io/docs/user-guide/).
+**Note**: The redis master in this example is *not* highly available. Making it highly available would be an interesting, but intricate exercise — redis doesn't actually support multi-master Deployments at this point in time, so high availability would be a somewhat tricky thing to implement, and might involve periodic serialization to disk, and so on.
+
+#### Define a Deployment
+
+To start the redis master, use the file [redis-master-deployment.yaml](https://git.k8s.io/examples/guestbook/redis-master-deployment.yaml), which describes a single [pod](http://kubernetes.io/docs/user-guide/pods/) running a redis key-value server in a container.
+
+Although we have a single instance of our redis master, we are using a [Deployment](http://kubernetes.io/docs/user-guide/deployments/) to enforce that exactly one pod keeps running. E.g., if the node were to go down, the Deployment will ensure that the redis master gets restarted on a healthy node. (In our simplified example, this could result in data loss.)
+
+The file [redis-master-deployment.yaml](redis-master-deployment.yaml) defines the redis master Deployment:
+
+
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: redis-master
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: redis
+ # role: master
+ # tier: backend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 1
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # role: master
+ # tier: backend
+ template:
+ metadata:
+ labels:
+ app: redis
+ role: master
+ tier: backend
+ spec:
+ containers:
+ - name: master
+ image: gcr.io/google_containers/redis:e2e
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ ports:
+ - containerPort: 6379
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml)
+
+
+#### Define a Service
+
+A Kubernetes [Service](http://kubernetes.io/docs/user-guide/services/) is a named load balancer that proxies traffic to one or more containers. This is done using the [labels](http://kubernetes.io/docs/user-guide/labels/) metadata that we defined in the `redis-master` pod above. As mentioned, we have only one redis master, but we nevertheless want to create a Service for it. Why? Because it gives us a deterministic way to route to the single master using an elastic IP.
+
+Services find the pods to load balance based on the pods' labels.
+The selector field of the Service description determines which pods will receive the traffic sent to the Service, and the `port` and `targetPort` information defines what port the Service proxy will run at.
+
+The file [redis-master-service.yaml](https://git.k8s.io/examples/guestbook/redis-master-deployment.yaml) defines the redis master Service:
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: redis-master
+ labels:
+ app: redis
+ role: master
+ tier: backend
+spec:
+ ports:
+ # the port that this service should serve on
+ - port: 6379
+ targetPort: 6379
+ selector:
+ app: redis
+ role: master
+ tier: backend
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-service.yaml)
+
+
+#### Create a Service
+
+According to the [config best practices](http://kubernetes.io/docs/user-guide/config-best-practices/), create a Service before corresponding Deployments so that the scheduler can spread the pods comprising the Service. So we first create the Service by running:
+
+```console
+$ kubectl create -f guestbook/redis-master-service.yaml
+service "redis-master" created
+```
+
+Then check the list of services, which should include the redis-master:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+redis-master 10.0.76.248 6379/TCP 1s
+```
+
+This will cause all pods to see the redis master apparently running on `:`. A Service can map an incoming port to any `targetPort` in the backend pod. Once created, the Service proxy on each node is configured to set up a proxy on the specified port (in this case port `6379`).
+
+`targetPort` will default to `port` if it is omitted in the configuration. `targetPort` is the port the container accepts traffic on, and `port` is the abstracted Service port, which can be any port other pods use to access the Service. For simplicity's sake, we omit it in the following configurations.
+
+The traffic flow from slaves to masters can be described in two steps:
+
+ - A *redis slave* will connect to `port` on the *redis master Service*
+ - Traffic will be forwarded from the Service `port` (on the Service node) to the `targetPort` on the pod that the Service listens to.
+
+For more details, please see [Connecting applications](http://kubernetes.io/docs/user-guide/connecting-applications/).
+
+#### Finding a Service
+
+Kubernetes supports two primary modes of finding a Service — environment variables and DNS.
+
+
+##### Environment variables
+
+The services in a Kubernetes cluster are discoverable inside other containers via [environment variables](https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables).
+
+##### DNS service
+
+An alternative is to use the [cluster's DNS service](https://kubernetes.io/docs/concepts/services-networking/service/#dns), if it has been enabled for the cluster. This lets all pods do name resolution of services automatically, based on the Service name.
+
+This example has been configured to use the DNS service by default.
+
+If your cluster does not have the DNS service enabled, then you can use environment variables by setting the
+`GET_HOSTS_FROM` env value in both
+[redis-slave-deployment.yaml](https://git.k8s.io/examples/guestbook/redis-slave-deployment.yaml) and [frontend-deployment.yaml](https://git.k8s.io/examples/guestbook/frontend-deployment.yaml)
+from `dns` to `env` before you start up the app.
+(However, this is unlikely to be necessary. You can check for the DNS service in the list of the cluster's services by
+running `kubectl --namespace=kube-system get rc -l k8s-app=kube-dns`.)
+Note that switching to env causes creation-order dependencies, since Services need to be created before their clients that require env vars.
+
+#### Create a Deployment
+
+Second, create the redis master pod in your Kubernetes cluster by running:
+
+```console
+$ kubectl create -f guestbook/redis-master-deployment.yaml
+deployment "redis-master" created
+```
+
+You can see the Deployment for your cluster by running:
+
+```console
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+redis-master 1 1 1 1 27s
+```
+
+Then, you can list the pods in the cluster, to verify that the master is running:
+
+```console
+$ kubectl get pods
+```
+
+You'll see all pods in the cluster, including the redis master pod, and the status of each pod.
+The name of the redis master will look similar to that in the following list:
+
+```console
+NAME READY STATUS RESTARTS AGE
+redis-master-2353460263-1ecey 1/1 Running 0 1m
+...
+```
+
+(Note that an initial `docker pull` to grab a container image may take a few minutes, depending on network conditions. A pod will be reported as `Pending` while its image is being downloaded.)
+
+`kubectl get pods` will show only the pods in the default [namespace](http://kubernetes.io/docs/user-guide/namespaces/). To see pods in all namespaces, run:
+
+```
+kubectl get pods --all-namespaces
+```
+
+For more details, please see [Configuring containers](http://kubernetes.io/docs/user-guide/configuring-containers/) and [Deploying applications](http://kubernetes.io/docs/user-guide/deploying-applications/).
+
+#### Optional Interlude
+
+You can get information about a pod, including the machine that it is running on, via `kubectl describe pods/`. E.g., for the redis master, you should see something like the following (your pod name will be different):
+
+```console
+$ kubectl describe pods redis-master-2353460263-1ecey
+Name: redis-master-2353460263-1ecey
+Node: kubernetes-node-m0k7/10.240.0.5
+...
+Labels: app=redis,pod-template-hash=2353460263,role=master,tier=backend
+Status: Running
+IP: 10.244.2.3
+Controllers: ReplicaSet/redis-master-2353460263
+Containers:
+ master:
+ Container ID: docker://76cf8115485966131587958ea3cbe363e2e1dcce129e2e624883f393ce256f6c
+ Image: gcr.io/google_containers/redis:e2e
+ Image ID: docker://e5f6c5a2b5646828f51e8e0d30a2987df7e8183ab2c3ed0ca19eaa03cc5db08c
+ Port: 6379/TCP
+...
+```
+
+The `Node` is the name and IP of the machine, e.g. `kubernetes-node-m0k7` in the example above. You can find more details about this node with `kubectl describe nodes kubernetes-node-m0k7`.
+
+If you want to view the container logs for a given pod, you can run:
+
+```console
+$ kubectl logs
+```
+
+These logs will usually give you enough information to troubleshoot.
+
+However, if you should want to SSH to the listed host machine, you can inspect various logs there directly as well. For example, with Google Compute Engine, using `gcloud`, you can SSH like this:
+
+```console
+me@workstation$ gcloud compute ssh
+```
+
+Then, you can look at the Docker containers on the remote machine. You should see something like this (the specifics of the IDs will be different):
+
+```console
+me@kubernetes-node-krxw:~$ sudo docker ps
+CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
+...
+0ffef9649265 redis:latest "/entrypoint.sh redi" About a minute ago Up About a minute k8s_master.869d22f3_redis-master-dz33o_default_1449a58a-5ead-11e5-a104-688f84ef8ef6_d74cb2b5
+```
+
+If you want to see the logs for a given container, you can run:
+
+```console
+$ docker logs
+```
+
+### Step Two: Start up the redis slave
+
+Now that the redis master is running, we can start up its 'read slaves'.
+
+We'll define these as replicated pods as well, though this time — unlike for the redis master — we'll define the number of replicas to be 2.
+In Kubernetes, a Deployment is responsible for managing multiple instances of a replicated pod. The Deployment will automatically launch new pods if the number of replicas falls below the specified number.
+(This particular replicated pod is a great one to test this with -- you can try killing the Docker processes for your pods directly, then watch them come back online on a new node shortly thereafter.)
+
+Just like the master, we want to have a Service to proxy connections to the redis slaves. In this case, in addition to discovery, the slave Service will provide transparent load balancing to web app clients.
+
+This time we put the Service and Deployment into one [file](http://kubernetes.io/docs/user-guide/managing-deployments/#organizing-resource-configurations). Grouping related objects together in a single file is often better than having separate files.
+The specification for the slaves is in [all-in-one/redis-slave.yaml](https://git.k8s.io/examples/guestbook/all-in-one/redis-slave.yaml):
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: redis-slave
+ labels:
+ app: redis
+ role: slave
+ tier: backend
+spec:
+ ports:
+ # the port that this service should serve on
+ - port: 6379
+ selector:
+ app: redis
+ role: slave
+ tier: backend
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: redis-slave
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: redis
+ # role: slave
+ # tier: backend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 2
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # role: slave
+ # tier: backend
+ template:
+ metadata:
+ labels:
+ app: redis
+ role: slave
+ tier: backend
+ spec:
+ containers:
+ - name: slave
+ image: gcr.io/google_samples/gb-redisslave:v1
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ env:
+ - name: GET_HOSTS_FROM
+ value: dns
+ # If your cluster config does not include a dns service, then to
+ # instead access an environment variable to find the master
+ # service's host, comment out the 'value: dns' line above, and
+ # uncomment the line below.
+ # value: env
+ ports:
+ - containerPort: 6379
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/redis-slave.yaml)
+
+
+This time the selector for the Service is `app=redis,role=slave,tier=backend`, because that identifies the pods running redis slaves. It is generally helpful to set labels on your Service itself as we've done here to make it easy to locate them with the `kubectl get services -l "app=redis,role=slave,tier=backend"` command. For more information on the usage of labels, see [using-labels-effectively](http://kubernetes.io/docs/user-guide/managing-deployments/#using-labels-effectively).
+
+Now that you have created the specification, create the Service in your cluster by running:
+
+```console
+$ kubectl create -f guestbook/all-in-one/redis-slave.yaml
+service "redis-slave" created
+deployment "redis-slave" created
+
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+redis-master 10.0.76.248 6379/TCP 20m
+redis-slave 10.0.112.188 6379/TCP 16s
+
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+redis-master 1 1 1 1 22m
+redis-slave 2 2 2 2 2m
+```
+
+Once the Deployment is up, you can list the pods in the cluster, to verify that the master and slaves are running. You should see a list that includes something like the following:
+
+```console
+$ kubectl get pods
+NAME READY STATUS RESTARTS AGE
+redis-master-2353460263-1ecey 1/1 Running 0 35m
+redis-slave-1691881626-dlf5f 1/1 Running 0 15m
+redis-slave-1691881626-sfn8t 1/1 Running 0 15m
+```
+
+You should see a single redis master pod and two redis slave pods. As mentioned above, you can get more information about any pod with: `kubectl describe pods/`. And also can view the resources on [kube-ui](http://kubernetes.io/docs/user-guide/ui/).
+
+### Step Three: Start up the guestbook frontend
+
+A frontend pod is a simple PHP server that is configured to talk to either the slave or master services, depending on whether the client request is a read or a write. It exposes a simple AJAX interface, and serves an Angular-based UX.
+Again we'll create a set of replicated frontend pods instantiated by a Deployment — this time, with three replicas.
+
+As with the other pods, we now want to create a Service to group the frontend pods.
+The Deployment and Service are described in the file [all-in-one/frontend.yaml](https://git.k8s.io/examples/guestbook/all-in-one/frontend.yaml):
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: frontend
+ labels:
+ app: guestbook
+ tier: frontend
+spec:
+ # if your cluster supports it, uncomment the following to automatically create
+ # an external load-balanced IP for the frontend service.
+ # type: LoadBalancer
+ ports:
+ # the port that this service should serve on
+ - port: 80
+ selector:
+ app: guestbook
+ tier: frontend
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: frontend
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: guestbook
+ # tier: frontend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 3
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # tier: frontend
+ template:
+ metadata:
+ labels:
+ app: guestbook
+ tier: frontend
+ spec:
+ containers:
+ - name: php-redis
+ image: gcr.io/google-samples/gb-frontend:v4
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ env:
+ - name: GET_HOSTS_FROM
+ value: dns
+ # If your cluster config does not include a dns service, then to
+ # instead access environment variables to find service host
+ # info, comment out the 'value: dns' line above, and uncomment the
+ # line below.
+ # value: env
+ ports:
+ - containerPort: 80
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/frontend.yaml)
+
+
+#### Using 'type: LoadBalancer' for the frontend service (cloud-provider-specific)
+
+For supported cloud providers, such as Google Compute Engine or Google Container Engine, you can specify to use an external load balancer
+in the service `spec`, to expose the service onto an external load balancer IP.
+To do this, uncomment the `type: LoadBalancer` line in the [all-in-one/frontend.yaml](https://git.k8s.io/examples/guestbook/all-in-one/frontend.yaml) file before you start the service.
+
+[See the appendix below](#appendix-accessing-the-guestbook-site-externally) on accessing the guestbook site externally for more details.
+
+Create the service and Deployment like this:
+
+```console
+$ kubectl create -f guestbook/all-in-one/frontend.yaml
+service "frontend" created
+deployment "frontend" created
+```
+
+Then, list all your services again:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.63.63 80/TCP 1m
+redis-master 10.0.76.248 6379/TCP 39m
+redis-slave 10.0.112.188 6379/TCP 19m
+```
+
+Also list all your Deployments:
+
+```console
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+frontend 3 3 3 3 2m
+redis-master 1 1 1 1 39m
+redis-slave 2 2 2 2 20m
+```
+
+Once it's up, i.e. when desired replicas match current replicas (again, it may take up to thirty seconds to create the pods), you can list the pods with specified labels in the cluster, to verify that the master, slaves and frontends are all running. You should see a list containing pods with label 'tier' like the following:
+
+```console
+$ kubectl get pods -L tier
+NAME READY STATUS RESTARTS AGE TIER
+frontend-1211764471-4e1j2 1/1 Running 0 4m frontend
+frontend-1211764471-gkbkv 1/1 Running 0 4m frontend
+frontend-1211764471-rk1cf 1/1 Running 0 4m frontend
+redis-master-2353460263-1ecey 1/1 Running 0 42m backend
+redis-slave-1691881626-dlf5f 1/1 Running 0 22m backend
+redis-slave-1691881626-sfn8t 1/1 Running 0 22m backend
+```
+
+You should see a single redis master pod, two redis slaves, and three frontend pods.
+
+The code for the PHP server that the frontends are running is in `examples/guestbook/php-redis/guestbook.php`. It looks like this:
+
+```php
+ 'tcp',
+ 'host' => $host,
+ 'port' => 6379,
+ ]);
+
+ $client->set($_GET['key'], $_GET['value']);
+ print('{"message": "Updated"}');
+ } else {
+ $host = 'redis-slave';
+ if (getenv('GET_HOSTS_FROM') == 'env') {
+ $host = getenv('REDIS_SLAVE_SERVICE_HOST');
+ }
+ $client = new Predis\Client([
+ 'scheme' => 'tcp',
+ 'host' => $host,
+ 'port' => 6379,
+ ]);
+
+ $value = $client->get($_GET['key']);
+ print('{"data": "' . $value . '"}');
+ }
+} else {
+ phpinfo();
+} ?>
+```
+
+Note the use of the `redis-master` and `redis-slave` host names -- we're finding those Services via the Kubernetes cluster's DNS service, as discussed above. All the frontend replicas will write to the load-balancing redis-slaves service, which can be highly replicated as well.
+
+### Step Four: Cleanup
+
+If you are in a live Kubernetes cluster, you can just kill the pods by deleting the Deployments and Services. Using labels to select the resources to delete is an easy way to do this in one command.
+
+```console
+$ kubectl delete deployments,services -l "app in (redis, guestbook)"
+```
+
+To completely tear down a Kubernetes cluster, if you ran this from source, you can use:
+
+```console
+$ /cluster/kube-down.sh
+```
+
+### Troubleshooting
+
+If you are having trouble bringing up your guestbook app, double check that your external IP is properly defined for your frontend Service, and that the firewall for your cluster nodes is open to port 80.
+
+Then, see the [troubleshooting documentation](http://kubernetes.io/docs/troubleshooting/) for a further list of common issues and how you can diagnose them.
+
+
+
+### Appendix: Accessing the guestbook site externally
+
+You'll want to set up your guestbook Service so that it can be accessed from outside of the internal Kubernetes network. Above, we introduced one way to do that, by setting `type: LoadBalancer` to Service `spec`.
+
+More generally, Kubernetes supports two ways of exposing a Service onto an external IP address: `NodePort`s and `LoadBalancer`s , as described [here](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types).
+
+If the `LoadBalancer` specification is used, it can take a short period for an external IP to show up in `kubectl get services` output, but you should then see it listed as well, e.g. like this:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.63.63 23.236.59.54 80/TCP 1m
+redis-master 10.0.76.248 6379/TCP 39m
+redis-slave 10.0.112.188 6379/TCP 19m
+```
+
+Once you've exposed the service to an external IP, visit the IP to see your guestbook in action, i.e. `http://:`.
+
+You should see a web page that looks something like this (without the messages). Try adding some entries to it!
+
+
+
+If you are more advanced in the ops arena, you can also manually get the service IP from looking at the output of `kubectl get pods,services`, and modify your firewall using standard tools and services (firewalld, iptables, selinux) which you are already familiar with.
+
+#### Google Compute Engine External Load Balancer Specifics
+
+In Google Compute Engine, Kubernetes automatically creates forwarding rules for services with `LoadBalancer`.
+
+You can list the forwarding rules like this (the forwarding rule also indicates the external IP):
+
+```console
+$ gcloud compute forwarding-rules list
+NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
+frontend us-central1 130.211.188.51 TCP us-central1/targetPools/frontend
+```
+
+In Google Compute Engine, you also may need to open the firewall for port 80 using the [console][cloud-console] or the `gcloud` tool. The following command will allow traffic from any source to instances tagged `kubernetes-node` (replace with your tags as appropriate):
+
+```console
+$ gcloud compute firewall-rules create --allow=tcp:80 --target-tags=kubernetes-node kubernetes-node-80
+```
+
+For GCE Kubernetes startup details, see the [Getting started on Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/)
+
+For Google Compute Engine details about limiting traffic to specific sources, see the [Google Compute Engine firewall documentation][gce-firewall-docs].
+
+[cloud-console]: https://console.developer.google.com
+[gce-firewall-docs]: https://cloud.google.com/compute/docs/networking#firewalls
+
+
+[]()
+
diff --git a/docs/user-guide/update-demo/index.md.orig b/docs/user-guide/update-demo/index.md.orig
index 14bf74ee1f..6739324029 100644
--- a/docs/user-guide/update-demo/index.md.orig
+++ b/docs/user-guide/update-demo/index.md.orig
@@ -4,7 +4,7 @@ assignees:
title: Rolling Update Demo
---
-This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) for more information.
+This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) for more information.
The files for this example are viewable in [our docs repo
here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/update-demo).
diff --git a/docs/user-guide/walkthrough/index.md b/docs/user-guide/walkthrough/index.md
index 2c10d96c1a..4c2e7f97dd 100644
--- a/docs/user-guide/walkthrough/index.md
+++ b/docs/user-guide/walkthrough/index.md
@@ -40,7 +40,7 @@ The simplest pod definition describes the deployment of a single container. For
A pod definition is a declaration of a _desired state_. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state. For example, when you create a Pod, you declare that you want the containers in it to be running. If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.
-See the [design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/README.md) for more details.
+See the [design document](https://git.k8s.io/community/contributors/design-proposals/README.md) for more details.
#### Pod Management
diff --git a/editdocs.md b/editdocs.md
index 8af1cf4b39..91578e6576 100644
--- a/editdocs.md
+++ b/editdocs.md
@@ -14,7 +14,7 @@ $( document ).ready(function() {
$("#continueEditButton").text("Edit " + forwarding);
$("#continueEditButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/edit/master/" + forwarding)
$("#viewOnGithubButton").text("View " + forwarding + " on GitHub");
- $("#viewOnGithubButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/tree/master/" + forwarding)
+ $("#viewOnGithubButton").attr("href", "https://git.k8s.io/kubernetes.github.io/" + forwarding)
} else {
$("#generalInstructions").show();
$("#continueEdit").hide();
diff --git a/images/docs/meanstack/MEANstack_architecture.svg b/images/docs/meanstack/MEANstack_architecture.svg
deleted file mode 100644
index 25171b2c47..0000000000
--- a/images/docs/meanstack/MEANstack_architecture.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
diff --git a/images/docs/meanstack/image_0.png b/images/docs/meanstack/image_0.png
deleted file mode 100644
index 92f7fa45ce..0000000000
Binary files a/images/docs/meanstack/image_0.png and /dev/null differ
diff --git a/images/docs/meanstack/image_1.png b/images/docs/meanstack/image_1.png
deleted file mode 100644
index 974ec0b0ae..0000000000
Binary files a/images/docs/meanstack/image_1.png and /dev/null differ
diff --git a/images/docs/meanstack/image_2.png b/images/docs/meanstack/image_2.png
deleted file mode 100644
index f856a537af..0000000000
Binary files a/images/docs/meanstack/image_2.png and /dev/null differ
diff --git a/images/docs/meanstack/image_3.png b/images/docs/meanstack/image_3.png
deleted file mode 100644
index 32d874d406..0000000000
Binary files a/images/docs/meanstack/image_3.png and /dev/null differ
diff --git a/images/docs/meanstack/image_4.png b/images/docs/meanstack/image_4.png
deleted file mode 100644
index a8f2d4e346..0000000000
Binary files a/images/docs/meanstack/image_4.png and /dev/null differ
diff --git a/images/docs/meanstack/image_5.png b/images/docs/meanstack/image_5.png
deleted file mode 100644
index 54e284b0f3..0000000000
Binary files a/images/docs/meanstack/image_5.png and /dev/null differ
diff --git a/images/docs/meanstack/image_6.png b/images/docs/meanstack/image_6.png
deleted file mode 100644
index 1af2b517d7..0000000000
Binary files a/images/docs/meanstack/image_6.png and /dev/null differ
diff --git a/images/docs/meanstack/image_7.png b/images/docs/meanstack/image_7.png
deleted file mode 100644
index 7774803073..0000000000
Binary files a/images/docs/meanstack/image_7.png and /dev/null differ
diff --git a/js/redirects.js b/js/redirects.js
index a6cb150c5f..d9a090c2d0 100644
--- a/js/redirects.js
+++ b/js/redirects.js
@@ -80,7 +80,16 @@ $( document ).ready(function() {
{
"from": "/docs/concepts/services-networking/networkpolicies/",
"to": "/docs/concepts/services-networking/network-policies/"
- }];
+ },
+ {
+ "from": "/docs/getting-started-guides/meanstack/",
+ "to": "https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d"
+ },
+ {
+ "from": "/docs/samples/",
+ "to": "/docs/tutorials/"
+ }
+ ];
forwardingRules.forEach(function(rule) {
if (forwardingURL.indexOf(rule.from) > -1) {
diff --git a/js/script.js b/js/script.js
index d6ff1dacf8..21e8012399 100755
--- a/js/script.js
+++ b/js/script.js
@@ -25,7 +25,7 @@ function copyCode(elem){
}
target.value = document.getElementById(elem).innerText;
// select the content
- target.setSelectionRange(0, target.value.length);
+ target.select();
// copy the selection
var succeed;
@@ -35,7 +35,7 @@ function copyCode(elem){
sweetAlert("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard.");
succeed = false;
}
- if (succeed) sweetAlert("Copied to clipboard:",target.value);
+ if (succeed) sweetAlert("Copied to clipboard: ",elem);
return succeed;
} else {
sweetAlert("Oops!",elem + " not found when trying to copy code");
@@ -520,4 +520,4 @@ $(function() {
if (!$('#home').length > 0 ) {
$('#hero').addClass('no-sub');
}
-});
\ No newline at end of file
+});
+
+If you are more advanced in the ops arena, you can also manually get the service IP from looking at the output of `kubectl get pods,services`, and modify your firewall using standard tools and services (firewalld, iptables, selinux) which you are already familiar with.
+
+#### Google Compute Engine External Load Balancer Specifics
+
+In Google Compute Engine, Kubernetes automatically creates forwarding rules for services with `LoadBalancer`.
+
+You can list the forwarding rules like this (the forwarding rule also indicates the external IP):
+
+```console
+$ gcloud compute forwarding-rules list
+NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
+frontend us-central1 130.211.188.51 TCP us-central1/targetPools/frontend
+```
+
+In Google Compute Engine, you also may need to open the firewall for port 80 using the [console][cloud-console] or the `gcloud` tool. The following command will allow traffic from any source to instances tagged `kubernetes-node` (replace with your tags as appropriate):
+
+```console
+$ gcloud compute firewall-rules create --allow=tcp:80 --target-tags=kubernetes-node kubernetes-node-80
+```
+
+For GCE Kubernetes startup details, see the [Getting started on Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/)
+
+For Google Compute Engine details about limiting traffic to specific sources, see the [Google Compute Engine firewall documentation][gce-firewall-docs].
+
+[cloud-console]: https://console.developer.google.com
+[gce-firewall-docs]: https://cloud.google.com/compute/docs/networking#firewalls
+
+
+[]()
+
diff --git a/docs/user-guide/update-demo/index.md.orig b/docs/user-guide/update-demo/index.md.orig
index 14bf74ee1f..6739324029 100644
--- a/docs/user-guide/update-demo/index.md.orig
+++ b/docs/user-guide/update-demo/index.md.orig
@@ -4,7 +4,7 @@ assignees:
title: Rolling Update Demo
---
-This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) for more information.
+This example demonstrates the usage of Kubernetes to perform a [rolling update](/docs/user-guide/kubectl/kubectl_rolling-update/) on a running group of [pods](/docs/user-guide/pods/). See [here](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/simple-rolling-update.md) for more information.
The files for this example are viewable in [our docs repo
here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/update-demo).
diff --git a/docs/user-guide/walkthrough/index.md b/docs/user-guide/walkthrough/index.md
index 2c10d96c1a..4c2e7f97dd 100644
--- a/docs/user-guide/walkthrough/index.md
+++ b/docs/user-guide/walkthrough/index.md
@@ -40,7 +40,7 @@ The simplest pod definition describes the deployment of a single container. For
A pod definition is a declaration of a _desired state_. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state. For example, when you create a Pod, you declare that you want the containers in it to be running. If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.
-See the [design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/README.md) for more details.
+See the [design document](https://git.k8s.io/community/contributors/design-proposals/README.md) for more details.
#### Pod Management
diff --git a/editdocs.md b/editdocs.md
index 8af1cf4b39..91578e6576 100644
--- a/editdocs.md
+++ b/editdocs.md
@@ -14,7 +14,7 @@ $( document ).ready(function() {
$("#continueEditButton").text("Edit " + forwarding);
$("#continueEditButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/edit/master/" + forwarding)
$("#viewOnGithubButton").text("View " + forwarding + " on GitHub");
- $("#viewOnGithubButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/tree/master/" + forwarding)
+ $("#viewOnGithubButton").attr("href", "https://git.k8s.io/kubernetes.github.io/" + forwarding)
} else {
$("#generalInstructions").show();
$("#continueEdit").hide();
diff --git a/images/docs/meanstack/MEANstack_architecture.svg b/images/docs/meanstack/MEANstack_architecture.svg
deleted file mode 100644
index 25171b2c47..0000000000
--- a/images/docs/meanstack/MEANstack_architecture.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
diff --git a/images/docs/meanstack/image_0.png b/images/docs/meanstack/image_0.png
deleted file mode 100644
index 92f7fa45ce..0000000000
Binary files a/images/docs/meanstack/image_0.png and /dev/null differ
diff --git a/images/docs/meanstack/image_1.png b/images/docs/meanstack/image_1.png
deleted file mode 100644
index 974ec0b0ae..0000000000
Binary files a/images/docs/meanstack/image_1.png and /dev/null differ
diff --git a/images/docs/meanstack/image_2.png b/images/docs/meanstack/image_2.png
deleted file mode 100644
index f856a537af..0000000000
Binary files a/images/docs/meanstack/image_2.png and /dev/null differ
diff --git a/images/docs/meanstack/image_3.png b/images/docs/meanstack/image_3.png
deleted file mode 100644
index 32d874d406..0000000000
Binary files a/images/docs/meanstack/image_3.png and /dev/null differ
diff --git a/images/docs/meanstack/image_4.png b/images/docs/meanstack/image_4.png
deleted file mode 100644
index a8f2d4e346..0000000000
Binary files a/images/docs/meanstack/image_4.png and /dev/null differ
diff --git a/images/docs/meanstack/image_5.png b/images/docs/meanstack/image_5.png
deleted file mode 100644
index 54e284b0f3..0000000000
Binary files a/images/docs/meanstack/image_5.png and /dev/null differ
diff --git a/images/docs/meanstack/image_6.png b/images/docs/meanstack/image_6.png
deleted file mode 100644
index 1af2b517d7..0000000000
Binary files a/images/docs/meanstack/image_6.png and /dev/null differ
diff --git a/images/docs/meanstack/image_7.png b/images/docs/meanstack/image_7.png
deleted file mode 100644
index 7774803073..0000000000
Binary files a/images/docs/meanstack/image_7.png and /dev/null differ
diff --git a/js/redirects.js b/js/redirects.js
index a6cb150c5f..d9a090c2d0 100644
--- a/js/redirects.js
+++ b/js/redirects.js
@@ -80,7 +80,16 @@ $( document ).ready(function() {
{
"from": "/docs/concepts/services-networking/networkpolicies/",
"to": "/docs/concepts/services-networking/network-policies/"
- }];
+ },
+ {
+ "from": "/docs/getting-started-guides/meanstack/",
+ "to": "https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d"
+ },
+ {
+ "from": "/docs/samples/",
+ "to": "/docs/tutorials/"
+ }
+ ];
forwardingRules.forEach(function(rule) {
if (forwardingURL.indexOf(rule.from) > -1) {
diff --git a/js/script.js b/js/script.js
index d6ff1dacf8..21e8012399 100755
--- a/js/script.js
+++ b/js/script.js
@@ -25,7 +25,7 @@ function copyCode(elem){
}
target.value = document.getElementById(elem).innerText;
// select the content
- target.setSelectionRange(0, target.value.length);
+ target.select();
// copy the selection
var succeed;
@@ -35,7 +35,7 @@ function copyCode(elem){
sweetAlert("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard.");
succeed = false;
}
- if (succeed) sweetAlert("Copied to clipboard:",target.value);
+ if (succeed) sweetAlert("Copied to clipboard: ",elem);
return succeed;
} else {
sweetAlert("Oops!",elem + " not found when trying to copy code");
@@ -520,4 +520,4 @@ $(function() {
if (!$('#home').length > 0 ) {
$('#hero').addClass('no-sub');
}
-});
\ No newline at end of file
+});