Paths -> Absolute
This commit is contained in:
@@ -22,7 +22,7 @@ Check the location and credentials that kubectl knows about with this command:
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
Many of the [examples](https://github.com/kubernetes/kubernetes/tree/master/examples/) provide an introduction to using
|
||||
Many of the [examples](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](kubectl/kubectl).
|
||||
|
||||
### Directly accessing the REST API
|
||||
@@ -125,7 +125,7 @@ From within a pod the recommended ways to connect to API are:
|
||||
process within a container. This proxies the
|
||||
Kubernetes API to the localhost interface of the pod, so that other processes
|
||||
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/master/examples/kubectl-container/).
|
||||
in a pod](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/kubectl-container/).
|
||||
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
|
||||
This handles locating and authenticating to the apiserver.
|
||||
|
||||
|
||||
@@ -188,4 +188,4 @@ check:
|
||||
|
||||
If none of the above solves your problem, follow the instructions in [Debugging Service document](debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
|
||||
|
||||
You may also visit [troubleshooting document](../troubleshooting) for more information.
|
||||
You may also visit [troubleshooting document](/{{page.version}}/docs/troubleshooting/) for more information.
|
||||
@@ -9,7 +9,7 @@ container needs. When containers have their resource requests specified, the sc
|
||||
able to 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, please refer to
|
||||
[Resource QoS](../proposals/resource-qos).
|
||||
[Resource QoS](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/resource-qos.md).
|
||||
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit. CPU is specified
|
||||
in units of cores. Memory is specified in units of bytes.
|
||||
|
||||
@@ -198,7 +198,7 @@ Till now we have only accessed the nginx server from within the cluster. Before
|
||||
* An nginx server configured to use the certificates
|
||||
* A [secret](secrets) that makes the certificates accessible to pods
|
||||
|
||||
You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/master/examples/https-nginx/), in short:
|
||||
You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/https-nginx/), in short:
|
||||
|
||||
```shell
|
||||
$ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json
|
||||
@@ -262,7 +262,7 @@ spec:
|
||||
Noteworthy points about the nginx-app manifest:
|
||||
|
||||
- It contains both rc and service specification in the same file
|
||||
- The [nginx server](https://github.com/kubernetes/kubernetes/tree/master/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports.
|
||||
- The [nginx server](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports.
|
||||
- Each container has access to the keys through a volume mounted at /etc/nginx/ssl. This is setup *before* the nginx server is started.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -494,10 +494,10 @@ misbehaving. And yet your `Service` is not working. You should probably let
|
||||
us know, so we can help investigate!
|
||||
|
||||
Contact us on
|
||||
[Slack](../troubleshooting/#slack) or
|
||||
[Slack](/{{page.version}}/docs/troubleshooting/)#slack) or
|
||||
[email](https://groups.google.com/forum/#!forum/google-containers) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
## More information
|
||||
|
||||
Visit [troubleshooting document](../troubleshooting) for more information.
|
||||
Visit [troubleshooting document](/{{page.version}}/docs/troubleshooting/) for more information.
|
||||
@@ -19,14 +19,14 @@ A typical use case is:
|
||||
|
||||
## Enabling Deployments on kubernetes cluster
|
||||
|
||||
Deployments is part of the [`extensions` API Group](../api/#api-groups) and is not enabled by default.
|
||||
Deployments is part of the [`extensions` API Group](/{{page.version}}/docs/api/)#api-groups) and is not enabled by default.
|
||||
Set `--runtime-config=extensions/v1beta1/deployments=true` on API server to
|
||||
enable it.
|
||||
This can be achieved by exporting `ENABLE_DEPLOYMENTS=true` before running
|
||||
`kube-up.sh` script on GCE.
|
||||
|
||||
Note that Deployment objects effectively have [API version
|
||||
`v1alpha1`](../api/#api-versioning).
|
||||
`v1alpha1`](/{{page.version}}/docs/api/)#api-versioning).
|
||||
Alpha objects may change or even be discontinued in future software releases.
|
||||
However, due to to a known issue, they will appear as API version `v1beta1` if
|
||||
enabled.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Downward API example"
|
||||
---
|
||||
Following this example, you will create a pod with a container that consumes the pod's name and
|
||||
namespace using the [downward API](../downward-api).
|
||||
namespace using the [downward API](/{{page.version}}/docs/user-guide/downward-api/).
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Supported metadata fields:
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and the `kubectl`
|
||||
command line tool somewhere in your path. Please see the [gettingstarted](..//{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
command line tool somewhere in your path. Please see the [gettingstarted](/{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
### Step One: Create the pod
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ This document describes the current state of Horizontal Pod Autoscaler in Kubern
|
||||
|
||||
Horizontal pod autoscaling allows the number of pods in a replication controller or deployment
|
||||
to scale automatically based on observed CPU utilization.
|
||||
It is a [beta](../api/#api-versioning) feature in Kubernetes 1.1.
|
||||
It is a [beta](/{{page.version}}/docs/api/)#api-versioning) feature in Kubernetes 1.1.
|
||||
|
||||
The autoscaler is implemented as a Kubernetes API resource and a controller.
|
||||
The resource describes behavior of the controller.
|
||||
@@ -40,7 +40,7 @@ More details on scale sub-resource can be found [here](https://github.com/kubern
|
||||
|
||||
## API Object
|
||||
|
||||
Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](../api/#api-versioning)).
|
||||
Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](/{{page.version}}/docs/api/)#api-versioning)).
|
||||
More details about the API object can be found at
|
||||
[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
|
||||
|
||||
@@ -102,7 +102,7 @@ $ kubectl create -f docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.ya
|
||||
horizontalpodautoscaler "php-apache" created
|
||||
```
|
||||
|
||||
Alternatively, we can create the autoscaler using [kubectl autoscale](../kubectl/kubectl_autoscale).
|
||||
Alternatively, we can create the autoscaler using [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_autoscale.md).
|
||||
The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](hpa-php-apache.yaml) file:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -198,9 +198,9 @@ value is `Always`.)
|
||||
|
||||
## Caveats
|
||||
|
||||
Job objects are in the [`extensions` API Group](../api/#api-groups).
|
||||
Job objects are in the [`extensions` API Group](/{{page.version}}/docs/api/)#api-groups).
|
||||
|
||||
Job objects have [API version `v1beta1`](../api/#api-versioning). Beta objects may
|
||||
Job objects have [API version `v1beta1`](/{{page.version}}/docs/api/)#api-versioning). Beta objects may
|
||||
undergo changes to their schema and/or semantics in future software releases, but
|
||||
similar functionality will be supported.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Overview"
|
||||
---
|
||||
This example shows two types of pod [health checks](../production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
This example shows two types of pod [health checks](/{{page.version}}/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
|
||||
The [exec-liveness.yaml](exec-liveness.yaml) demonstrates the container execution check.
|
||||
|
||||
@@ -39,7 +39,7 @@ livenessProbe:
|
||||
|
||||
The Kubelet sends an HTTP request to the specified path and port to perform the health check. If you take a look at image/server.go, you will see the server starts to respond with an error code 500 after 10 seconds, so the check fails. The Kubelet sends the probe to the container's ip address by default which could be specified with `host` as part of httpGet probe. If the container listens on `127.0.0.1`, `host` should be specified as `127.0.0.1`. In general, if the container listens on its ip address or on all interfaces (0.0.0.0), there is no need to specify the `host` as part of the httpGet probe.
|
||||
|
||||
This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks.
|
||||
This [guide](/{{page.version}}/docs/user-guide/k8s201/#health-checking) has more information on health checks.
|
||||
|
||||
## Get your hands dirty
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ describes a pod that just emits a log message once every 4 seconds. The pod spec
|
||||
[synthetic_10lps.yaml](synthetic_10lps.yaml)
|
||||
describes a pod that just emits 10 log lines per second.
|
||||
|
||||
See [logging document](../logging) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
|
||||
See [logging document](/{{page.version}}/docs/user-guide/logging/) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
|
||||
started instructions
|
||||
at [Cluster Level Logging to Google Cloud Logging](/{{page.version}}/docs/getting-started-guides/logging).
|
||||
To observe the ingested log lines when using Elasticsearch and Kibana please see the getting
|
||||
|
||||
@@ -10,7 +10,7 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god
|
||||
## Examining the logs of running containers
|
||||
|
||||
The logs of a running container may be fetched using the command `kubectl logs`. For example, given
|
||||
this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/master/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
|
||||
this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
|
||||
output every second. (You can find different pod specifications [here](logging-demo/).)
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE ../../examples/blog-logging/counter-pod.yaml -->
|
||||
@@ -28,7 +28,7 @@ spec:
|
||||
'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']
|
||||
```
|
||||
|
||||
[Download example](https://github.com/kubernetes/kubernetes/tree/master/examples/blog-logging/counter-pod.yaml)
|
||||
[Download example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/blog-logging/counter-pod.yaml)
|
||||
<!-- END MUNGE: EXAMPLE ../../examples/blog-logging/counter-pod.yaml -->
|
||||
|
||||
we can run the pod:
|
||||
|
||||
@@ -113,7 +113,7 @@ my-nginx-svc app=nginx app=nginx 10.0.152.174 80/TCP
|
||||
|
||||
The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.
|
||||
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
|
||||
@@ -53,7 +53,7 @@ Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wi
|
||||
|
||||
## Try it out!
|
||||
|
||||
Now that you've learned a bit about Heapster, feel free to try it out on your own clusters! The [Heapster repository](https://github.com/kubernetes/heapster) is available on GitHub. It contains detailed instructions to setup Heapster and its storage backends. Heapster runs by default on most Kubernetes clusters, so you may already have it! Feedback is always welcome. Please let us know if you run into any issues via the troubleshooting [channels](../troubleshooting).
|
||||
Now that you've learned a bit about Heapster, feel free to try it out on your own clusters! The [Heapster repository](https://github.com/kubernetes/heapster) is available on GitHub. It contains detailed instructions to setup Heapster and its storage backends. Heapster runs by default on most Kubernetes clusters, so you may already have it! Feedback is always welcome. Please let us know if you run into any issues via the troubleshooting [channels](/{{page.version}}/docs/troubleshooting/).
|
||||
|
||||
***
|
||||
*Authors: Vishnu Kannan and Victor Marmol, Google Software Engineers.*
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Node selection example"
|
||||
---
|
||||
This example shows how to assign a [pod](../pods) to a specific [node](/{{page.version}}/docs/admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
|
||||
This example shows how to assign a [pod](/{{page.version}}/docs/user-guide/pods/) to a specific [node](/{{page.version}}/docs/admin/node/) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "How To Use Persistent Volumes"
|
||||
---
|
||||
The purpose of this guide is to help you become familiar with [Kubernetes Persistent Volumes](../persistent-volumes). By the end of the guide, we'll have
|
||||
The purpose of this guide is to help you become familiar with [Kubernetes Persistent Volumes](/{{page.version}}/docs/user-guide/persistent-volumes/). By the end of the guide, we'll have
|
||||
nginx serving content from your persistent volume.
|
||||
|
||||
This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.
|
||||
@@ -88,6 +88,6 @@ $ curl 10.0.0.241:3000
|
||||
I love Kubernetes storage!
|
||||
```
|
||||
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](/{{page.version}}/docs/troubleshooting/)#slack) and ask!
|
||||
|
||||
Enjoy!
|
||||
@@ -10,7 +10,7 @@ You've seen [how to configure and deploy pods and containers](configuring-contai
|
||||
|
||||
The container file system only lives as long as the container does, so when a container crashes and restarts, changes to the filesystem will be lost and the container will restart from a clean slate. To access more-persistent storage, outside the container file system, you need a [*volume*](volumes). This is especially important to stateful applications, such as key-value stores and databases.
|
||||
|
||||
For example, [Redis](http://redis.io/) is a key-value cache and store, which we use in the [guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) and other examples. We can add a volume to it to store persistent data as follows:
|
||||
For example, [Redis](http://redis.io/) is a key-value cache and store, which we use in the [guestbook](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/) and other examples. We can add a volume to it to store persistent data as follows:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -234,7 +234,7 @@ spec:
|
||||
memory: 64Mi
|
||||
```
|
||||
|
||||
The container will die due to OOM (out of memory) if it exceeds its specified limit, so specifying a value a little higher than expected generally improves reliability. By specifying request, pod is guaranteed to be able to use that much of resource when needed. See [Resource QoS](../proposals/resource-qos) for the difference between resource limits and requests.
|
||||
The container will die due to OOM (out of memory) if it exceeds its specified limit, so specifying a value a little higher than expected generally improves reliability. By specifying request, pod is guaranteed to be able to use that much of resource when needed. See [Resource QoS](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/proposals/resource-qos.md) for the difference between resource limits and requests.
|
||||
|
||||
If you're not sure how much resources to request, you can first launch the application without specifying resources, and use [resource usage monitoring](monitoring) to determine appropriate values.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Secrets example"
|
||||
---
|
||||
Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/secrets.md) for more information.
|
||||
Following this example, you will create a [secret](/{{page.version}}/docs/user-guide/secrets/) and a [pod](/{{page.version}}/docs/user-guide/pods/) that consumes that secret in a [volume](/{{page.version}}/docs/user-guide/volumes/). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/secrets.md) for more information.
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ limitations under the License.
|
||||
|
||||
-->
|
||||
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](../managing-deployments/#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/release-1.1/docs/design/simple-rolling-update.md) for more information.
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_rolling-update.md) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](/{{page.version}}/docs/user-guide/managing-deployments/#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/release-1.1/docs/design/simple-rolling-update.md) for more information.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
@@ -46,7 +46,7 @@ Now visit the the [demo website](http://localhost:8001/static). You won't see a
|
||||
|
||||
### Step Two: Run the replication controller
|
||||
|
||||
Now we will turn up two replicas of an [image](../images). They all serve on internal port 80.
|
||||
Now we will turn up two replicas of an [image](/{{page.version}}/docs/user-guide/images/). They all serve on internal port 80.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/update-demo/nautilus-rc.yaml
|
||||
|
||||
@@ -235,7 +235,7 @@ writers simultaneously.
|
||||
__Important: You must have your own NFS server running with the share exported
|
||||
before you can use it__
|
||||
|
||||
See the [NFS example](https://github.com/kubernetes/kubernetes/tree/master/examples/nfs/) for more details.
|
||||
See the [NFS example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/nfs/) for more details.
|
||||
|
||||
### iscsi
|
||||
|
||||
@@ -254,7 +254,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately,
|
||||
iSCSI volumes can only be mounted by a single consumer in read-write mode - no
|
||||
simultaneous readers allowed.
|
||||
|
||||
See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/master/examples/iscsi/) for more details.
|
||||
See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/iscsi/) for more details.
|
||||
|
||||
### flocker
|
||||
|
||||
@@ -269,7 +269,7 @@ can be "handed off" between pods as required.
|
||||
|
||||
__Important: You must have your own Flocker installation running before you can use it__
|
||||
|
||||
See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/master/examples/flocker/) for more details.
|
||||
See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/flocker/) for more details.
|
||||
|
||||
### glusterfs
|
||||
|
||||
@@ -284,7 +284,7 @@ simultaneously.
|
||||
__Important: You must have your own GlusterFS installation running before you
|
||||
can use it__
|
||||
|
||||
See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/master/examples/glusterfs/) for more details.
|
||||
See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/glusterfs/) for more details.
|
||||
|
||||
### rbd
|
||||
|
||||
@@ -304,7 +304,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately,
|
||||
RBD volumes can only be mounted by a single consumer in read-write mode - no
|
||||
simultaneous writers allowed.
|
||||
|
||||
See the [RBD example](https://github.com/kubernetes/kubernetes/tree/master/examples/rbd/) for more details.
|
||||
See the [RBD example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/rbd/) for more details.
|
||||
|
||||
### gitRepo
|
||||
|
||||
|
||||
@@ -11,17 +11,17 @@ In order for the kubectl usage examples to work, make sure you have an examples
|
||||
|
||||
## Kubectl CLI
|
||||
|
||||
The easiest way to interact with Kubernetes is via the [kubectl](../kubectl/kubectl) command-line interface.
|
||||
The easiest way to interact with Kubernetes is via the [kubectl](/{{page.version}}/docs/user-guide/kubectl-overview/) command-line interface.
|
||||
|
||||
For more info about kubectl, including its usage, commands, and parameters, see the [kubectl CLI reference](../kubectl/kubectl).
|
||||
For more info about kubectl, including its usage, commands, and parameters, see the [kubectl CLI reference](/{{page.version}}/docs/user-guide/kubectl-overview/).
|
||||
|
||||
If you haven't installed and configured kubectl, finish the [prerequisites](../prereqs) before continuing.
|
||||
If you haven't installed and configured kubectl, finish the [prerequisites](/{{page.version}}/docs/user-guide/prereqs/) before continuing.
|
||||
|
||||
## Pods
|
||||
|
||||
In Kubernetes, a group of one or more containers is called a _pod_. Containers in a pod are deployed together, and are started, stopped, and replicated as a group.
|
||||
|
||||
See [pods](/{{page.version}}/docs/user-guide/pods) for more details.
|
||||
See [pods](/{{page.version}}/docs/user-guide/pods/) for more details.
|
||||
|
||||
|
||||
#### Pod Definition
|
||||
@@ -60,7 +60,7 @@ List all pods:
|
||||
$ kubectl get pods
|
||||
```
|
||||
|
||||
On most providers, the pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox pod and exec commands on it remotely. See the [command execution documentation](../kubectl/kubectl_exec) for details.
|
||||
On most providers, the pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox pod and exec commands on it remotely. See the [command execution documentation](/{{page.version}}/docs/user-guide/getting-into-containers/) for details.
|
||||
|
||||
Provided the pod IP is accessible, you should be able to access its http endpoint with curl on port 80:
|
||||
|
||||
@@ -179,4 +179,4 @@ Finally, we have also introduced an environment variable to the `git-monitor` co
|
||||
## What's Next?
|
||||
|
||||
Continue on to [Kubernetes 201](k8s201) or
|
||||
for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/)
|
||||
for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/)
|
||||
@@ -56,7 +56,7 @@ List all pods with the label `app=nginx`:
|
||||
$ kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
For more information, see [Labels](../labels).
|
||||
For more information, see [Labels](/{{page.version}}/docs/user-guide/labels).
|
||||
They are a core concept used by two additional Kubernetes building blocks: Replication Controllers and Services.
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ Delete the replication controller by name:
|
||||
$ kubectl delete rc nginx-controller
|
||||
```
|
||||
|
||||
For more information, see [Replication Controllers](../replication-controller).
|
||||
For more information, see [Replication Controllers](/{{page.version}}/docs/user-guide/replication-controller).
|
||||
|
||||
|
||||
## Services
|
||||
@@ -167,7 +167,7 @@ List all services:
|
||||
$ kubectl get services
|
||||
```
|
||||
|
||||
On most providers, the service IPs are not externally accessible. The easiest way to test that the service is working is to create a busybox pod and exec commands on it remotely. See the [command execution documentation](../kubectl/kubectl_exec) for details.
|
||||
On most providers, the service IPs are not externally accessible. The easiest way to test that the service is working is to create a busybox pod and exec commands on it remotely. See the [command execution documentation](/{{page.version}}/docs/user-guide/kubectl-overview/) for details.
|
||||
|
||||
Provided the service IP is accessible, you should be able to access its http endpoint with curl on port 80:
|
||||
|
||||
@@ -185,7 +185,7 @@ $ kubectl delete service nginx-service
|
||||
|
||||
When created, each service is assigned a unique IP address. This address is tied to the lifespan of the Service, and will not change while the Service is alive. Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some pod that is a member of the set identified by the label selector in the Service.
|
||||
|
||||
For more information, see [Services](../services).
|
||||
For more information, see [Services](/{{page.version}}/docs/user-guide/services/).
|
||||
|
||||
|
||||
## Health Checking
|
||||
@@ -231,8 +231,8 @@ Kubelet to ensure that your application is operating correctly for a definition
|
||||
|
||||
Currently, there are three types of application health checks that you can choose from:
|
||||
|
||||
* HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered success, failure otherwise. See health check examples [here](../liveness/).
|
||||
* Container Exec - The Kubelet will execute a command inside your container. If it exits with status 0 it will be considered a success. See health check examples [here](../liveness/).
|
||||
* HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered success, failure otherwise. See health check examples [here](/{{page.version}}/docs/user-guide/liveness/).
|
||||
* Container Exec - The Kubelet will execute a command inside your container. If it exits with status 0 it will be considered a success. See health check examples [here](/{{page.version}}/docs/user-guide/liveness/).
|
||||
* TCP Socket - The Kubelet will attempt to open a socket to your container. If it can establish a connection, the container is considered healthy, if it can't it is considered a failure.
|
||||
|
||||
In all cases, if the Kubelet discovers a failure the container is restarted.
|
||||
@@ -269,9 +269,9 @@ spec:
|
||||
[Download example](pod-with-http-healthcheck.yaml)
|
||||
<!-- END MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->
|
||||
|
||||
For more information about health checking, see [Container Probes](../pod-states/#container-probes).
|
||||
For more information about health checking, see [Container Probes](/{{page.version}}/docs/user-guide/pod-states/#container-probes).
|
||||
|
||||
|
||||
## What's Next?
|
||||
|
||||
For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/).
|
||||
For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/).
|
||||
@@ -6,7 +6,7 @@ and who want to learn more about using kubectl to manage resources such
|
||||
as pods and services. Users who want to access the REST API directly,
|
||||
and developers who want to extend the Kubernetes API should
|
||||
refer to the [api conventions](/{{page.version}}/docs/devel/api-conventions) and
|
||||
the [api document](../api).*
|
||||
the [api document](/{{page.version}}/docs/api/).*
|
||||
|
||||
## Resources are Automatically Modified
|
||||
|
||||
|
||||
Reference in New Issue
Block a user