Changes for move to Netlify (#4464)

* disable jekyll-redirect-from gem * add _redirects file * disable 404 redirect script * add 301 redirect to test * retain _redirects file * Convert redirect_from's to _redirect file. (#4409) * Remove redirect_from's. (#4424) * Add 301's to _redirects. (#4427) * add whitespace before 301 * move redirects in /js/redirects/js to _redirects * add disabled option for cn redirect * convert include to array in _config.yml * enable redirects.js script for legacy support
2017-07-28 08:23:11 -07:00
parent 130b72927c
commit 2e257d9707
158 changed files with 624 additions and 1011 deletions
@@ -4,11 +4,6 @@ assignees:
 - sttts
 - ericchiang
 title: Auditing
-redirect_from:
- "/docs/admin/audit/"
- "/docs/admin/audit.html"
- "/docs/concepts/cluster-administration/audit/"
- "/docs/concepts/cluster-administration/audit.html"
 ---

 * TOC
@@ -3,9 +3,6 @@ assignees:
 - janetkuo
 - thockin
 title: Application Introspection and Debugging
-redirect_from:
- "/docs/user-guide/introspection-and-debugging/"
- "/docs/user-guide/introspection-and-debugging.html"
 ---

 Once your application is running, you'll inevitably need to debug problems with it.
@@ -90,7 +87,7 @@ Containers:
    Environment Variables:
 Conditions:
  Type		Status
-  Ready 	True 
+  Ready 	True
 Volumes:
  default-token-4bcbi:
    Type:	Secret (a volume populated by a Secret)
@@ -140,7 +137,7 @@ $ kubectl describe pod nginx-deployment-1370807587-fz9sd
  Node:		/
  Labels:		app=nginx,pod-template-hash=1370807587
  Status:		Pending
-  IP:		
+  IP:
  Controllers:	ReplicaSet/nginx-deployment-1370807587
  Containers:
    nginx:
@@ -278,7 +275,7 @@ Labels:			kubernetes.io/hostname=kubernetes-node-861h
 CreationTimestamp:	Fri, 10 Jul 2015 14:32:29 -0700
 Conditions:
  Type		Status		LastHeartbeatTime			LastTransitionTime			Reason					Message
-  Ready 	Unknown 	Fri, 10 Jul 2015 14:34:32 -0700 	Fri, 10 Jul 2015 14:35:15 -0700 	Kubelet stopped posting node status. 	
+  Ready 	Unknown 	Fri, 10 Jul 2015 14:34:32 -0700 	Fri, 10 Jul 2015 14:35:15 -0700 	Kubelet stopped posting node status.
 Addresses:	10.240.115.55,104.197.0.26
 Capacity:
 cpu:		1
@@ -3,9 +3,6 @@ assignees:
 - mikedanese
 - thockin
 title: Troubleshoot Applications
-redirect_from:
- "/docs/user-guide/application-troubleshooting/"
- "/docs/user-guide/application-troubleshooting.html"
 ---

 This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
@@ -2,9 +2,6 @@
 assignees:
 - davidopp
 title: Troubleshoot Clusters
-redirect_from:
- "/docs/admin/cluster-troubleshooting/"
- "/docs/admin/cluster-troubleshooting.html"
 ---

 This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
@@ -8,9 +8,6 @@ assignees:
 - kow3ns
 - smarterclayton
 title: Debug Init Containers
-redirect_from:
- "/docs/tasks/troubleshoot/debug-init-containers/"
- "/docs/tasks/troubleshoot/debug-init-containers.html"
 ---

 {% capture overview %}
@@ -28,7 +25,7 @@ Init Containers. The example command lines below refer to the Pod as

 * You should be familiar with the basics of
  [Init Containers](/docs/concepts/abstractions/init-containers/).
-* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).   
+* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).

 {% endcapture %}

@@ -2,9 +2,6 @@
 assignees:
 - bprashanth
 title: Debug Pods and Replication Controllers
-redirect_from:
- "/docs/user-guide/debugging-pods-and-replication-controllers/"
- "/docs/user-guide/debugging-pods-and-replication-controllers.html"
 ---

 * TOC
@@ -4,9 +4,6 @@ assignees:
 - janetkuo
 - thockin
 title: Debug Services
-redirect_from:
- "/docs/user-guide/debugging-services/"
- "/docs/user-guide/debugging-services.html"
 ---

 An issue that comes up rather frequently for new installations of Kubernetes is
@@ -86,7 +83,7 @@ $ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
 deployment "hostnames" created
 ```

-`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. 
+`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
 Note that this is the same as if you had started the `Deployment` with
 the following YAML:

@@ -8,9 +8,6 @@ assignees:
 - kow3ns
 - smarterclayton
 title: Debug a StatefulSet
-redirect_from:
- "/docs/tasks/manage-stateful-set/debugging-a-statefulset/"
- "/docs/tasks/manage-stateful-set/debugging-a-statefulset.html"
 ---

 {% capture overview %}
@@ -22,7 +19,7 @@ This task shows you how to debug a StatefulSet.
 {% capture prerequisites %}


-* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. 
+* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
 * You should have a StatefulSet running that you want to investigate.

 {% endcapture %}
@@ -31,13 +28,13 @@ This task shows you how to debug a StatefulSet.

 ## Debugging a StatefulSet

-In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them, you can use the following: 
+In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them, you can use the following:

 ```shell
 kubectl get pods -l app=myapp
 ```

-If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time, refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the [Debugging Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods) guide. 
+If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time, refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the [Debugging Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods) guide.

 StatefulSets provide a debug mechanism to pause all controller operations on Pods using an annotation. Setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` on any StatefulSet Pod will *pause* all operations of the StatefulSet. When paused, the StatefulSet will not perform any scaling operations. Once the debug hook is set, you can execute commands within the containers of StatefulSet pods without interference from scaling operations. You can set the annotation to `"false"` by executing the following:

@@ -45,11 +42,11 @@ StatefulSets provide a debug mechanism to pause all controller operations on Pod
 kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite
 ```

-When the annotation is set to `"false"`, the StatefulSet will not respond to its Pods becoming unhealthy or unavailable. It will not create replacement Pods till the annotation is removed or set to `"true"` on each StatefulSet Pod. 
+When the annotation is set to `"false"`, the StatefulSet will not respond to its Pods becoming unhealthy or unavailable. It will not create replacement Pods till the annotation is removed or set to `"true"` on each StatefulSet Pod.

 ### Step-wise Initialization

-You can also use the same annotation to debug race conditions during bootstrapping of the StatefulSet by setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` in the `.spec.template.metadata.annotations` field of the StatefulSet prior to creating it. 
+You can also use the same annotation to debug race conditions during bootstrapping of the StatefulSet by setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` in the `.spec.template.metadata.annotations` field of the StatefulSet prior to creating it.

 ```yaml
 apiVersion: apps/v1beta1
@@ -67,12 +64,12 @@ spec:
        pod.alpha.kubernetes.io/initialized: "false"
 ...
 ...
-... 
+...

 ```

 After setting the annotation, if you create the StatefulSet, you can wait for each Pod to come up and verify that it has initialized correctly. The StatefulSet will not create any subsequent Pods till the debug annotation is set to `"true"` (or removed) on each Pod that has already been created. You can set the annotation to `"true"` by executing the following:
- 
+
 ```shell
 kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="true" --overwrite
 ```
@@ -3,11 +3,6 @@ assignees:
 - caesarxuchao
 - mikedanese
 title: Get a Shell to a Running Container
-redirect_from:
- "/docs/user-guide/getting-into-containers/"
- "/docs/user-guide/getting-into-containers.html"
- "/docs/tasks/kubectl/get-shell-running-container/"
- "/docs/tasks/kubectl/get-shell-running-container.html"
 ---

 {% capture overview %}
@@ -3,9 +3,6 @@ assignees:
 - crassirostris
 - piosz
 title: Logging Using Elasticsearch and Kibana
-redirect_from:
- "/docs/user-guide/logging/elasticsearch/"
- "/docs/user-guide/logging/elasticsearch.html"
 ---

 On the Google Compute Engine (GCE) platform, the default logging support targets
@@ -3,9 +3,6 @@ assignees:
 - crassirostris
 - piosz
 title: Logging Using Stackdriver
-redirect_from:
- "/docs/user-guide/logging/stackdriver/"
- "/docs/user-guide/logging/stackdriver.html"
 ---

 Before reading this page, it's highly recommended to familiarize yourself
@@ -3,9 +3,6 @@ assignees:
 - Random-Liu
 - dchen1107
 title: Monitor Node Health
-redirect_from:
- "/docs/admin/node-problem/"
- "/docs/admin/node-problem.html"
 ---

 * TOC
@@ -2,11 +2,6 @@
 assignees:
 - mikedanese
 title: Tools for Monitoring Compute, Storage, and Network Resources
-redirect_from:
- "/docs/user-guide/monitoring/"
- "/docs/user-guide/monitoring.html"
- "/docs/concepts/cluster-administration/resource-usage-monitoring/"
- "/docs/concepts/cluster-administration/resource-usage-monitoring.html"
 ---

 Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes.
@@ -3,8 +3,6 @@ assignees:
 - brendandburns
 - davidopp
 title: Troubleshooting
-redirect_from:
- "/docs/troubleshooting/"
 ---

 Sometimes things go wrong. This guide is aimed at making them right. It has