diff --git a/_data/v1_1/guides.yml b/_data/v1_1/guides.yml index b2f1fd891c..c3ff2d6b04 100644 --- a/_data/v1_1/guides.yml +++ b/_data/v1_1/guides.yml @@ -9,14 +9,14 @@ toc: - title: TODO - 5-minute Quickstart path: /v1.1/docs/hellonode/ - title: Kubernetes 101 - path: /v1.1/docs/user-guide/walkthrough/README/ + path: /v1.1/docs/user-guide/walkthrough/ - title: Kubernetes 201 path: /v1.1/docs/user-guide/walkthrough/k8s201/ - title: Running Kubernetes section: - title: Picking the Right Solution - path: /v1.1/docs/getting-started-guides/README/ + path: /v1.1/docs/getting-started-guides/ - title: Running Kubernetes on Your Local Machine section: - title: Running Kubernetes Locally via Docker @@ -34,7 +34,7 @@ toc: - title: Running Kubernetes on AWS EC2 path: /v1.1/docs/getting-started-guides/aws/ - title: Running Kubernetes on Azure - path: /v1.1/docs/getting-started-guides/coreos/azure/README/ + path: /v1.1/docs/getting-started-guides/coreos/azure/ - title: Running Kubernetes on Custom Solutions section: - title: Getting Started From Scratch @@ -93,7 +93,7 @@ toc: - title: Accessing Clusters path: /v1.1/docs/user-guide/accessing-the-cluster/ - title: Sharing a Cluster - path: /v1.1/docs/admin/namespaces/README/ + path: /v1.1/docs/admin/namespaces/ - title: Changing Cluster Size path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/ - title: Creating a Custom Cluster from Scratch @@ -109,20 +109,20 @@ toc: - title: Using Nodes path: /v1.1/docs/admin/node/ - title: Assigning Pods to Nodes - path: /v1.1/docs/user-guide/node-selection/README/ + path: /v1.1/docs/user-guide/node-selection/ - title: Using Configuration Files path: /v1.1/docs/user-guide/simple-yaml/ - title: Configuring Containers path: /v1.1/docs/user-guide/configuring-containers/ - title: Using Environment Variables - path: /v1.1/docs/user-guide/environment-guide/README/ + path: /v1.1/docs/user-guide/environment-guide/ - title: Managing Compute Resources path: /v1.1/docs/user-guide/compute-resources/ - title: Applying Resource Quotas and Limits - path: /v1.1/docs/admin/resourcequota/README/ + path: /v1.1/docs/admin/resourcequota/ - title: Setting Pod CPU and Memory Limits - path: /v1.1/docs/admin/limitrange/README/ + path: /v1.1/docs/admin/limitrange/ - title: Managing Deployments path: /v1.1/docs/user-guide/managing-deployments/ @@ -138,28 +138,28 @@ toc: - title: Creating Servers with External IPs path: /v1.1/examples/simple-nginx/ - title: Setting Up and Configuring DNS - path: /v1.1/examples/cluster-dns/README/ + path: /v1.1/examples/cluster-dns/ - title: Using DNS Pods and Services path: /v1.1/docs/admin/dns/ - title: Working with Containers path: /v1.1/docs/user-guide/production-pods/ - title: Creating Pods with the Downward API - path: /v1.1/docs/user-guide/downward-api/README/ + path: /v1.1/docs/user-guide/downward-api/ - title: Using Secrets - path: /v1.1/docs/user-guide/secrets/README/ + path: /v1.1/docs/user-guide/secrets/ - title: Using Persistent Volumes - path: /v1.1/docs/user-guide/persistent-volumes/README/ + path: /v1.1/docs/user-guide/persistent-volumes/ - title: Updating Live Pods - path: /v1.1/docs/user-guide/update-demo/README/ + path: /v1.1/docs/user-guide/update-demo/ - title: Testing and Monitoring section: - title: Simulating Large Test Loads - path: /v1.1/examples/k8petstore/README/ + path: /v1.1/examples/k8petstore/ - title: Checking Pod Health - path: /v1.1/docs/user-guide/liveness/README/ + path: /v1.1/docs/user-guide/liveness/ - title: Using Explorer to Examine the Runtime Environment - path: /v1.1/examples/explorer/README/ + path: /v1.1/examples/explorer/ - title: Resource Usage Monitoring path: /v1.1/docs/user-guide/monitoring/ \ No newline at end of file diff --git a/_data/v1_1/overrides.yml b/_data/v1_1/overrides.yml index 1f04c5ed92..833f441ce2 100644 --- a/_data/v1_1/overrides.yml +++ b/_data/v1_1/overrides.yml @@ -1,5 +1,4 @@ overrides: -- path: v1.1/docs/design - path: v1.1/docs/man - path: v1.1/docs/proposals - path: v1.1/docs/api-reference diff --git a/_data/v1_1/reference.yml b/_data/v1_1/reference.yml index 86df6f5585..c79e42f6cc 100644 --- a/_data/v1_1/reference.yml +++ b/_data/v1_1/reference.yml @@ -96,14 +96,14 @@ toc: - title: Kubernetes Design Docs section: - title: Kubernetes Architecture - path: /v1.1/docs/design/architecture/ + path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/architecture.md - title: Kubernetes Design Overview - path: /v1.1/docs/design/README/ + path: https://github.com/kubernetes/kubernetes/blob/master/docs/design/ - title: Security in Kubernetes - path: /v1.1/docs/design/security/ + path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/security.md - title: Kubernetes Identity and Access Management - path: /v1.1/docs/design/access/ + path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/access.md - title: Security Contexts - path: /v1.1/docs/design/security_context/ + path: https://github.com/kubernetes/kubernetes/tree/master/docs/design/security_context.md - title: Kubernetes OpenVSwitch GRE/VxLAN networking path: /v1.1/docs/admin/ovs-networking/ \ No newline at end of file diff --git a/v1.1/docs/admin/accessing-the-api.md b/v1.1/docs/admin/accessing-the-api.md index eb7b3524c7..bd2f67bcc5 100644 --- a/v1.1/docs/admin/accessing-the-api.md +++ b/v1.1/docs/admin/accessing-the-api.md @@ -7,7 +7,7 @@ cluster administrators who want to customize their cluster or understand the details. Most questions about accessing the cluster are covered -in [Accessing the cluster](../user-guide/accessing-the-cluster). +in [Accessing the cluster](/{{page.version}}/docs/user-guide/accessing-the-cluster). ## Ports and IPs Served On @@ -30,7 +30,7 @@ By default the Kubernetes APIserver serves HTTP on 2 ports: - uses token-file or client-certificate based [authentication](authentication). - uses policy-based [authorization](authorization). 3. Removed: ReadOnly Port - - For security reasons, this had to be removed. Use the [service account](../user-guide/service-accounts) feature instead. + - For security reasons, this had to be removed. Use the [service account](/{{page.version}}/docs/user-guide/service-accounts) feature instead. ## Proxies and Firewall rules @@ -54,7 +54,7 @@ variety of uses cases: running on the `kubernetes-master` machine. The proxy can use cert-based authentication or token-based authentication. 2. Processes running in Containers on Kubernetes that need to read from - the apiserver. Currently, these can use a [service account](../user-guide/service-accounts). + the apiserver. Currently, these can use a [service account](/{{page.version}}/docs/user-guide/service-accounts). 3. Scheduler and Controller-manager processes, which need to do read-write API operations. Currently, these have to run on the same host as the apiserver and use the Localhost Port. In the future, these will be diff --git a/v1.1/docs/admin/admission-controllers.md b/v1.1/docs/admin/admission-controllers.md index 327d4f4ae3..89db4bb1d1 100644 --- a/v1.1/docs/admin/admission-controllers.md +++ b/v1.1/docs/admin/admission-controllers.md @@ -62,12 +62,12 @@ enabling this plug-in. ### ServiceAccount -This plug-in implements automation for [serviceAccounts](../user-guide/service-accounts). +This plug-in implements automation for [serviceAccounts](/{{page.version}}/docs/user-guide/service-accounts). We strongly recommend using this plug-in if you intend to make use of Kubernetes `ServiceAccount` objects. ### SecurityContextDeny -This plug-in will deny any pod with a [SecurityContext](../user-guide/security-context) that defines options that were not available on the `Container`. +This plug-in will deny any pod with a [SecurityContext](/{{page.version}}/docs/user-guide/security-context) that defines options that were not available on the `Container`. ### ResourceQuota @@ -75,7 +75,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](../design/admission_control_resource_quota) and the [example of Resource Quota](resourcequota/) for more details. +See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](resourcequota/) 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. @@ -88,7 +88,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](../design/admission_control_limit_range) and the [example of Limit Range](limitrange/) for more details. +See the [limitRange design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details. ### InitialResources (experimental) diff --git a/v1.1/docs/admin/authentication.md b/v1.1/docs/admin/authentication.md index bf64b491a6..20fc4d9918 100644 --- a/v1.1/docs/admin/authentication.md +++ b/v1.1/docs/admin/authentication.md @@ -22,7 +22,7 @@ header with a value of `Bearer SOMETOKEN`. **OpenID Connect ID Token** is enabled by passing the following options to the apiserver: - `--oidc-issuer-url` (required) tells the apiserver where to connect to the OpenID provider. Only HTTPS scheme will be accepted. - `--oidc-client-id` (required) is used by apiserver to verify the audience of the token. -A valid [ID token](http://openid.net/specs/openid-connect-core-1_0.html#IDToken) MUST have this +A valid [ID token](http://openid.net/specs/openid-connect-core-1_0/#IDToken) MUST have this client-id in its `aud` claims. - `--oidc-ca-file` (optional) is used by apiserver to establish and verify the secure connection to the OpenID provider. diff --git a/v1.1/docs/admin/cluster-large.md b/v1.1/docs/admin/cluster-large.md index c110c9b560..206b59456e 100644 --- a/v1.1/docs/admin/cluster-large.md +++ b/v1.1/docs/admin/cluster-large.md @@ -66,4 +66,4 @@ To avoid running into cluster addon resource issues, when creating a cluster wit * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/fluentd-es/fluentd-es.yaml) * [FluentD with GCP Plugin](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml) -For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](../user-guide/compute-resources.html#troubleshooting). \ No newline at end of file +For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/{{page.version}}/docs/user-guide/compute-resources/#troubleshooting). \ No newline at end of file diff --git a/v1.1/docs/admin/cluster-management.md b/v1.1/docs/admin/cluster-management.md index 597d1255e5..b4b7a69664 100644 --- a/v1.1/docs/admin/cluster-management.md +++ b/v1.1/docs/admin/cluster-management.md @@ -8,7 +8,7 @@ running cluster. ## Creating and configuring a Cluster -To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/{{page.version}}/docs/getting-started-guides/README) depending on your environment. +To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/{{page.version}}/docs/getting-started-guides/) depending on your environment. ## Upgrading a cluster @@ -63,7 +63,7 @@ recommend testing the upgrade on an experimental cluster before performing the u ## Resizing a cluster -If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](node.html#self-registration-of-nodes). +If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](node/#self-registration-of-nodes). If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI: ```shell diff --git a/v1.1/docs/admin/cluster-troubleshooting.md b/v1.1/docs/admin/cluster-troubleshooting.md index 94a63184e9..6e1ec7cee4 100644 --- a/v1.1/docs/admin/cluster-troubleshooting.md +++ b/v1.1/docs/admin/cluster-troubleshooting.md @@ -3,7 +3,7 @@ title: "Cluster Troubleshooting" --- This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the problem you are experiencing. See -the [application troubleshooting guide](../user-guide/application-troubleshooting) for tips on application debugging. +the [application troubleshooting guide](/{{page.version}}/docs/user-guide/application-troubleshooting) for tips on application debugging. You may also visit [troubleshooting document](../troubleshooting) for more information. ## Listing your cluster diff --git a/v1.1/docs/admin/daemons.md b/v1.1/docs/admin/daemons.md index b2a1adcfe7..a333c15716 100644 --- a/v1.1/docs/admin/daemons.md +++ b/v1.1/docs/admin/daemons.md @@ -26,30 +26,30 @@ but with different flags and/or different memory and cpu requests for different ### Required Fields As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For -general information about working with config files, see [here](../user-guide/simple-yaml), -[here](../user-guide/configuring-containers), and [here](../user-guide/working-with-resources). +general information about working with config files, see [here](/{{page.version}}/docs/user-guide/simple-yaml), +[here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](/{{page.version}}/docs/user-guide/working-with-resources). -A DaemonSet also needs a [`.spec`](../devel/api-conventions.html#spec-and-status) section. +A DaemonSet also needs a [`.spec`](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) section. ### Pod Template The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](../user-guide/replication-controller.html#pod-template). -It has exactly the same schema as a [pod](../user-guide/pods), except +The `.spec.template` is a [pod template](/{{page.version}}/docs/user-guide/replication-controller/#pod-template). +It has exactly the same schema as a [pod](/{{page.version}}/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a pod, a pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). -A pod template in a DaemonSet must have a [`RestartPolicy`](../user-guide/pod-states) +A pod template in a DaemonSet must have a [`RestartPolicy`](/{{page.version}}/docs/user-guide/pod-states) equal to `Always`, or be unspecified, which defaults to `Always`. ### Pod Selector The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of -a [ReplicationController](../user-guide/replication-controller) or -[Job](../user-guide/jobs). +a [ReplicationController](/{{page.version}}/docs/user-guide/replication-controller) or +[Job](/{{page.version}}/docs/user-guide/jobs). If the `.spec.selector` is specified, it must equal the `.spec.template.metadata.labels`. If not specified, the are default to be equal. Config with these unequal will be rejected by the API. @@ -64,7 +64,7 @@ a node for testing. If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create pods on nodes which match that [node -selector](../user-guide/node-selection/README). +selector](/{{page.version}}/docs/user-guide/node-selection/). If you do not specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create pods on all nodes. @@ -75,7 +75,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified when the pod is created, so it is ignored by the scheduler). Therefore: - - the [`unschedulable`](node.html#manual-node-administration) field of a node is not respected + - the [`unschedulable`](node/#manual-node-administration) field of a node is not respected by the daemon set controller. - daemon set controller can make pods even when the scheduler has not been started, which can help cluster bootstrap. @@ -88,7 +88,7 @@ Some possible patterns for communicating with pods in a DaemonSet are: as a stats database. They do not have clients. - **NodeIP and Known Port**: Pods in the Daemon Set use a `hostPort`, so that the pods are reachable via the node IPs. Clients knows the the list of nodes ips somehow, and know the port by convention. -- **DNS**: Create a [headless service](../user-guide/services.html#headless-services) with the same pod selector, +- **DNS**: Create a [headless service](/{{page.version}}/docs/user-guide/services/#headless-services) with the same pod selector, and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from DNS. - **Service**: Create a service with the same pod selector, and use the service to reach a @@ -147,7 +147,7 @@ in cluster bootstrapping cases. Also, static pods may be deprecated in the futu ### Replication Controller -Daemon Set are similar to [Replication Controllers](../user-guide/replication-controller) in that +Daemon Set are similar to [Replication Controllers](/{{page.version}}/docs/user-guide/replication-controller) in that they both create pods, and those pods have processes which are not expected to terminate (e.g. web servers, storage servers). @@ -158,12 +158,12 @@ all or certain hosts, and when it needs to start before other pods. ## Caveats -DaemonSet objects are in the [`extensions` API Group](../api.html#api-groups). +DaemonSet objects are in the [`extensions` API Group](../api/#api-groups). DaemonSet is not enabled by default. Enable it by setting `--runtime-config=extensions/v1beta1/daemonsets=true` on the api server. This can be achieved by exporting ENABLE_DAEMONSETS=true before running kube-up.sh script on GCE. -DaemonSet objects effectively have [API version `v1alpha1`](../api.html#api-versioning). +DaemonSet objects effectively have [API version `v1alpha1`](../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. \ No newline at end of file diff --git a/v1.1/docs/admin/etcd.md b/v1.1/docs/admin/etcd.md index 21fb9b4237..f0f1eccc43 100644 --- a/v1.1/docs/admin/etcd.md +++ b/v1.1/docs/admin/etcd.md @@ -13,11 +13,11 @@ internet at large), because access to etcd is equivalent to root in your cluster. Data Reliability: for reasonable safety, either etcd needs to be run as a -[cluster](high-availability.html#clustering-etcd) (multiple machines each running +[cluster](high-availability/#clustering-etcd) (multiple machines each running etcd) or etcd's data directory should be located on durable storage (e.g., GCE's persistent disk). In either case, if high availability is required--as it might be in a production cluster--the data directory ought to be [backed up -periodically](https://coreos.com/etcd/docs/2.0.12/admin_guide.html#disaster-recovery), +periodically](https://coreos.com/etcd/docs/2.0.12/admin_guide/#disaster-recovery), to reduce downtime in case of corruption. ## Default configuration diff --git a/v1.1/docs/admin/index.md b/v1.1/docs/admin/index.md index 04c84c581b..58af4fe8e0 100644 --- a/v1.1/docs/admin/index.md +++ b/v1.1/docs/admin/index.md @@ -2,7 +2,7 @@ title: "Kubernetes Cluster Admin Guide" --- The cluster admin guide is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with concepts in the [User Guide](../user-guide/README). +It assumes some familiarity with concepts in the [User Guide](/{{page.version}}/docs/user-guide/). ## Admin Guide Table of Contents @@ -32,6 +32,6 @@ It assumes some familiarity with concepts in the [User Guide](../user-guide/READ 1. [Multiple Clusters](multi-cluster) 1. [High Availability Clusters](high-availability) 1. [Large Clusters](cluster-large) - 1. [Getting started from scratch](../getting-started-guides/scratch) + 1. [Getting started from scratch](/{{page.version}}/docs/getting-started-guides/scratch) 1. [Kubernetes's use of salt](salt) 1. [Troubleshooting](cluster-troubleshooting) \ No newline at end of file diff --git a/v1.1/docs/admin/introduction.md b/v1.1/docs/admin/introduction.md index e5382b8e8f..f03e601904 100644 --- a/v1.1/docs/admin/introduction.md +++ b/v1.1/docs/admin/introduction.md @@ -2,7 +2,7 @@ title: "Kubernetes Cluster Admin Guide" --- The cluster admin guide is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with concepts in the [User Guide](../user-guide/README). +It assumes some familiarity with concepts in the [User Guide](/{{page.version}}/docs/user-guide/). * TOC {:toc} @@ -10,7 +10,7 @@ It assumes some familiarity with concepts in the [User Guide](../user-guide/READ ## Planning a cluster There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this -[matrix](../getting-started-guides/README). We call each of the combinations in this matrix a *distro*. +[matrix](/{{page.version}}/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*. Before choosing a particular guide, here are some things to consider: @@ -34,7 +34,7 @@ Before choosing a particular guide, here are some things to consider: ## Setting up a cluster -Pick one of the Getting Started Guides from the [matrix](../getting-started-guides/README) and follow it. +Pick one of the Getting Started Guides from the [matrix](/{{page.version}}/docs/getting-started-guides/) and follow it. If none of the Getting Started Guides fits, you may want to pull ideas from several of the guides. One option for custom networking is *OpenVSwitch GRE/VxLAN networking* ([ovs-networking.md](ovs-networking)), which @@ -57,7 +57,7 @@ project](salt). * **DNS Integration with SkyDNS** ([dns.md](dns)): Resolving a DNS name directly to a Kubernetes service. -* **Logging** with [Kibana](../user-guide/logging) +* **Logging** with [Kibana](/{{page.version}}/docs/user-guide/logging) ## Multi-tenant support @@ -65,7 +65,7 @@ project](salt). ## Security -* **Kubernetes Container Environment** ([docs/user-guide/container-environment.md](../user-guide/container-environment)): +* **Kubernetes Container Environment** ([docs/user-guide/container-environment.md](/{{page.version}}/docs/user-guide/container-environment)): Describes the environment for Kubelet managed containers on a Kubernetes node. diff --git a/v1.1/docs/admin/limitrange/index.md b/v1.1/docs/admin/limitrange/index.md index dccaee4d24..142d6edad4 100644 --- a/v1.1/docs/admin/limitrange/index.md +++ b/v1.1/docs/admin/limitrange/index.md @@ -26,7 +26,7 @@ This example demonstrates how limits can be applied to a Kubernetes namespace to min/max resource limits per pod. In addition, this example demonstrates how you can apply default resource limits to pods in the absence of an end-user specified value. -See [LimitRange design doc](../../design/admission_control_limit_range) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/{{page.version}}/docs/user-guide/compute-resources) +See [LimitRange design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/{{page.version}}/docs/user-guide/compute-resources) ## Step 0: Prerequisites diff --git a/v1.1/docs/admin/namespaces.md b/v1.1/docs/admin/namespaces.md index ea596a823d..2cd3e62cd9 100644 --- a/v1.1/docs/admin/namespaces.md +++ b/v1.1/docs/admin/namespaces.md @@ -1,8 +1,6 @@ --- title: "Namespaces" --- -## Abstract - A Namespace is a mechanism to partition resources created by users into a logically named group. @@ -86,13 +84,13 @@ 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](../design/admission_control_limit_range) +See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/tree/master/docs/design/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](../design/namespaces.html#phases) for more details. +See the [design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/namespaces.md#phases) for more details. ### Creating a new namespace @@ -107,7 +105,7 @@ metadata: Note that the name of your namespace must be a DNS compatible label. -More information on the `finalizers` field can be found in the namespace [design doc](../design/namespaces.html#finalizers). +More information on the `finalizers` field can be found in the namespace [design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/namespaces.md#finalizers). Then run: @@ -117,8 +115,8 @@ $ kubectl create -f ./my-namespace.yaml ### Working in namespaces -See [Setting the namespace for a request](/{{page.version}}/docs/user-guide/namespaces.html#setting-the-namespace-for-a-request) -and [Setting the namespace preference](/{{page.version}}/docs/user-guide/namespaces.html#setting-the-namespace-preference). +See [Setting the namespace for a request](/{{page.version}}/docs/user-guide/namespaces/#setting-the-namespace-for-a-request) +and [Setting the namespace preference](/{{page.version}}/docs/user-guide/namespaces/#setting-the-namespace-preference). ### Deleting a namespace @@ -143,5 +141,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](../design/namespaces.html#example-openshift-origin-managing-a-kubernetes-namespace) -can be found in the [namespaces design doc](../design/namespaces) \ No newline at end of file +Details of the design of namespaces in Kubernetes, including a [detailed example](https://github.com/kubernetes/kubernetes/tree/master/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace) +can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/namespaces.md) \ No newline at end of file diff --git a/v1.1/docs/admin/namespaces/index.md b/v1.1/docs/admin/namespaces/index.md index 9709f75e79..8a0fbe0a72 100644 --- a/v1.1/docs/admin/namespaces/index.md +++ b/v1.1/docs/admin/namespaces/index.md @@ -5,7 +5,7 @@ Kubernetes _[namespaces](/{{page.version}}/docs/admin/namespaces)_ help differen It does this by providing the following: -1. A scope for [Names](../../user-guide/identifiers). +1. A scope for [Names](/{{page.version}}/docs/user-guide/identifiers). 2. A mechanism to attach authorization and policy to a subsection of the cluster. Use of multiple namespaces is optional. @@ -16,8 +16,8 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu This example assumes the following: -1. You have an [existing Kubernetes cluster](../../getting-started-guides/). -2. You have a basic understanding of Kubernetes _[pods](../../user-guide/pods)_, _[services](../../user-guide/services)_, and _[replication controllers](../../user-guide/replication-controller)_. +1. You have an [existing Kubernetes cluster](/{{page.version}}/docs/getting-started-guides/). +2. You have a basic understanding of Kubernetes _[pods](/{{page.version}}/docs/user-guide/pods)_, _[services](/{{page.version}}/docs/user-guide/services)_, and _[replication controllers](/{{page.version}}/docs/user-guide/replication-controller)_. ### Step One: Understand the default namespace diff --git a/v1.1/docs/admin/networking.md b/v1.1/docs/admin/networking.md index 799bf90d0f..6b0777942f 100644 --- a/v1.1/docs/admin/networking.md +++ b/v1.1/docs/admin/networking.md @@ -1,17 +1,18 @@ --- title: "Networking in Kubernetes" --- -* TOC -{:toc} - Kubernetes approaches networking somewhat differently than Docker does by default. There are 4 distinct networking problems to solve: 1. Highly-coupled container-to-container communications: this is solved by - [pods](../user-guide/pods) and `localhost` communications. + [pods](/{{page.version}}/docs/user-guide/pods) and `localhost` communications. 2. Pod-to-Pod communications: this is the primary focus of this document. -3. Pod-to-Service communications: this is covered by [services](../user-guide/services). -4. External-to-Service communications: this is covered by [services](../user-guide/services). +3. Pod-to-Service communications: this is covered by [services](/{{page.version}}/docs/user-guide/services). +4. External-to-Service communications: this is covered by [services](/{{page.version}}/docs/user-guide/services). + +* TOC +{:toc} + ## Summary @@ -180,4 +181,4 @@ IPs. The early design of the networking model and its rationale, and some future plans are described in more detail in the [networking design -document](../design/networking). \ No newline at end of file +document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/networking.md). \ No newline at end of file diff --git a/v1.1/docs/admin/node.md b/v1.1/docs/admin/node.md index 1db25d195d..9770dc2e49 100644 --- a/v1.1/docs/admin/node.md +++ b/v1.1/docs/admin/node.md @@ -8,9 +8,9 @@ title: "Node" `Node` is a worker machine in Kubernetes, previously known as `Minion`. Node may be a VM or physical machine, depending on the cluster. Each node has -the services necessary to run [Pods](../user-guide/pods) and is managed by the master +the services necessary to run [Pods](/{{page.version}}/docs/user-guide/pods) and is managed by the master components. The services on a node include docker, kubelet and network proxy. See -[The Kubernetes Node](../design/architecture.html#the-kubernetes-node) section in the +[The Kubernetes Node](https://github.com/kubernetes/kubernetes/tree/master/docs/design/architecture.md#the-kubernetes-node) section in the architecture design doc for more details. ## Node Status @@ -82,7 +82,7 @@ The information is gathered by Kubelet from the node. ## Node Management -Unlike [Pods](../user-guide/pods) and [Services](../user-guide/services), a Node is not inherently +Unlike [Pods](/{{page.version}}/docs/user-guide/pods) and [Services](/{{page.version}}/docs/user-guide/services), a Node is not inherently created by Kubernetes: it is either taken from cloud providers like Google Compute Engine, or from your pool of physical or virtual machines. What this means is that when Kubernetes creates a node, it is really just creating an object that represents the node in its internal state. @@ -209,4 +209,4 @@ on each kubelet where you want to reserve resources. Node is a top-level resource in the kubernetes REST API. More details about the API object can be found at: [Node API -object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_node). +object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_node). diff --git a/v1.1/docs/admin/resource-quota.md b/v1.1/docs/admin/resource-quota.md index 298bb6f923..c97057422a 100755 --- a/v1.1/docs/admin/resource-quota.md +++ b/v1.1/docs/admin/resource-quota.md @@ -18,7 +18,7 @@ work like this: their resource requests defaulted to match their defined limits. The user is only charged for the resources they request in the Resource Quota versus their limits because the request is the minimum amount of resource guaranteed by the cluster during scheduling. For more information on over commit, - see [compute-resources](../user-guide/compute-resources). + see [compute-resources](/{{page.version}}/docs/user-guide/compute-resources). - If creating a pod would cause the namespace to exceed any of the limits specified in the the Resource Quota for that namespace, then the request will fail with HTTP status code `403 FORBIDDEN`. @@ -52,7 +52,7 @@ Resource Quota is enforced in a particular namespace when there is a ## Compute Resource Quota -The total sum of [compute resources](../user-guide/compute-resources) requested by pods +The total sum of [compute resources](/{{page.version}}/docs/user-guide/compute-resources) requested by pods in a namespace can be limited. The following compute resource types are supported: | ResourceName | Description | @@ -73,9 +73,9 @@ are supported: | pods | Total number of pods | | services | Total number of services | | replicationcontrollers | Total number of replication controllers | -| resourcequotas | Total number of [resource quotas](admission-controllers.html#resourcequota) | +| resourcequotas | Total number of [resource quotas](admission-controllers/#resourcequota) | | secrets | Total number of secrets | -| persistentvolumeclaims | Total number of [persistent volume claims](../user-guide/persistent-volumes.html#persistentvolumeclaims) | +| persistentvolumeclaims | Total number of [persistent volume claims](/{{page.version}}/docs/user-guide/persistent-volumes/#persistentvolumeclaims) | For example, `pods` quota counts and enforces a maximum on the number of `pods` created in a single namespace. @@ -151,4 +151,4 @@ See a [detailed example for how to use resource quota](resourcequota/). ## Read More -See [ResourceQuota design doc](../design/admission_control_resource_quota) for more information. +See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control_resource_quota.md) for more information. diff --git a/v1.1/docs/admin/resourcequota/index.md b/v1.1/docs/admin/resourcequota/index.md index 90b1fc161e..e05827fdcc 100644 --- a/v1.1/docs/admin/resourcequota/index.md +++ b/v1.1/docs/admin/resourcequota/index.md @@ -1,9 +1,9 @@ --- title: "Resource Quota" --- -This example demonstrates how [resource quota](../../admin/admission-controllers.html#resourcequota) and -[limitsranger](../../admin/admission-controllers.html#limitranger) can be applied to a Kubernetes namespace. -See [ResourceQuota design doc](../../design/admission_control_resource_quota) for more information. +This example demonstrates how [resource quota](/{{page.version}}/docs/admin/admission-controllers/#resourcequota) and +[limitsranger](/{{page.version}}/docs/admin/admission-controllers/#limitranger) can be applied to a Kubernetes namespace. +See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control_resource_quota.md) for more information. This example assumes you have a functional Kubernetes setup. diff --git a/v1.1/docs/admin/service-accounts-admin.md b/v1.1/docs/admin/service-accounts-admin.md index bcea431335..c6fefe2236 100644 --- a/v1.1/docs/admin/service-accounts-admin.md +++ b/v1.1/docs/admin/service-accounts-admin.md @@ -2,7 +2,7 @@ title: "Cluster Admin Guide to Service Accounts" --- *This is a Cluster Administrator guide to service accounts. It assumes knowledge of -the [User Guide to Service Accounts](../user-guide/service-accounts).* +the [User Guide to Service Accounts](/{{page.version}}/docs/user-guide/service-accounts).* *Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts.* diff --git a/v1.1/docs/admin/static-pods.md b/v1.1/docs/admin/static-pods.md index 3de90dcf0c..c2d6ab5d9b 100644 --- a/v1.1/docs/admin/static-pods.md +++ b/v1.1/docs/admin/static-pods.md @@ -85,7 +85,7 @@ static-web-my-minion1 172.17.0.3 my-minion1/192.1 Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering. -Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](../user-guide/kubectl/kubectl) command), kubelet simply won't remove it. +Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/{{page.version}}/docs/user-guide/kubectl/kubectl) command), kubelet simply won't remove it. ```shell [joe@my-master ~] $ kubectl delete pod static-web-my-minion1 diff --git a/v1.1/docs/api.md b/v1.1/docs/api.md index 32d68964be..0c1a5d9c4d 100644 --- a/v1.1/docs/api.md +++ b/v1.1/docs/api.md @@ -1,15 +1,15 @@ --- title: "The Kubernetes API" --- -Primary system and API concepts are documented in the [User guide](user-guide/README). +Primary system and API concepts are documented in the [User guide](/{{page.version}}/docs/user-guide/). -Overall API conventions are described in the [API conventions doc](devel/api-conventions). +Overall API conventions are described in the [API conventions doc](/{{page.version}}/docs/devel/api-conventions). Complete API details are documented via [Swagger](http://swagger.io/). The Kubernetes apiserver (aka "master") exports an API that can be used to retrieve the [Swagger spec](https://github.com/swagger-api/swagger-spec/tree/master/schemas/v1.2) for the Kubernetes API, by default at `/swaggerapi`, and a UI you can use to browse the API documentation at `/swagger-ui`. We also periodically update a [statically generated UI](http://kubernetes.io/third_party/swagger-ui/). -Remote access to the API is discussed in the [access doc](admin/accessing-the-api). +Remote access to the API is discussed in the [access doc](/{{page.version}}/docs/admin/accessing-the-api). -The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [Kubectl](user-guide/kubectl/kubectl) command-line tool can be used to create, update, delete, and get API objects. +The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [Kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) command-line tool can be used to create, update, delete, and get API objects. Kubernetes also stores its serialized state (currently in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) in terms of the API resources. @@ -19,7 +19,7 @@ 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](devel/api_changes). +What constitutes a compatible change and how to change the API are detailed by the [API change document](/{{page.version}}/docs/devel/api_changes). ## API versioning @@ -30,12 +30,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. Note that API versioning and Software versioning are only indirectly related. The [API and release -versioning proposal](design/versioning) describes the relationship between API versioning and +versioning proposal](https://github.com/kubernetes/kubernetes/tree/master/docs/design/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](devel/api_changes.html#alpha-beta-and-stable-versions). They are summarized here: +in more detail in the [API Changes documentation](/{{page.version}}/docs/devel/api_changes/#alpha-beta-and-stable-versions). They are summarized here: - Alpha level: - The version names contain `alpha` (e.g. `v1alpha1`). @@ -73,7 +73,7 @@ Currently there are two API groups in use: In the future we expect that there will be more API groups, all at REST path `/apis/$API_GROUP` and using `apiVersion: $API_GROUP/$VERSION`. We expect that there will be a way for (third parties to -create their own API groups](design/extending-api.md), and to avoid naming collisions. +create their own API groups](https://github.com/kubernetes/kubernetes/tree/master/docs/design/extending-api.md), and to avoid naming collisions. ## Enabling resources in the extensions group @@ -88,17 +88,17 @@ As of June 4, 2015, the Kubernetes v1 API has been enabled by default. The v1bet ### v1 conversion tips (from v1beta3) -We're working to convert all documentation and examples to v1. A simple [API conversion tool](admin/cluster-management.html#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec. +We're working to convert all documentation and examples to v1. A simple [API conversion tool](/{{page.version}}/docs/admin/cluster-management/#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec. Changes to services are the most significant difference between v1beta3 and v1. * The `service.spec.portalIP` property is renamed to `service.spec.clusterIP`. * The `service.spec.createExternalLoadBalancer` property is removed. Specify `service.spec.type: "LoadBalancer"` to create an external load balancer instead. -* The `service.spec.publicIPs` property is deprecated and now called `service.spec.deprecatedPublicIPs`. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify `service.spec.type: "NodePort"` instead. Read [External Services](user-guide/services.html#external-services) for more info. If this is not sufficient for your use case, please file an issue or contact @thockin. +* The `service.spec.publicIPs` property is deprecated and now called `service.spec.deprecatedPublicIPs`. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify `service.spec.type: "NodePort"` instead. Read [External Services](/{{page.version}}/docs/user-guide/services/#external-services) for more info. If this is not sufficient for your use case, please file an issue or contact @thockin. Some other difference between v1beta3 and v1: -* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](user-guide/security-context). +* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](/{{page.version}}/docs/user-guide/security-context). * The `pod.spec.host` property is renamed to `pod.spec.nodeName`. * The `endpoints.subsets[*].addresses.IP` property is renamed to `endpoints.subsets[*].addresses.ip`. * The `pod.status.containerStatuses[*].state.termination` and `pod.status.containerStatuses[*].lastState.termination` properties are renamed to `pod.status.containerStatuses[*].state.terminated` and `pod.status.containerStatuses[*].lastState.terminated` respectively. @@ -119,7 +119,7 @@ Some important differences between v1beta1/2 and v1beta3: * The `labels` query parameter has been renamed to `labelSelector`. * The `fields` query parameter has been renamed to `fieldSelector`. * The container `entrypoint` has been renamed to `command`, and `command` has been renamed to `args`. -* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](user-guide/compute-resources.html#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores). +* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](/{{page.version}}/docs/user-guide/compute-resources/#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores). * Restart policy is represented simply as a string (e.g., `"Always"`) rather than as a nested map (`always{}`). * Pull policies changed from `PullAlways`, `PullNever`, and `PullIfNotPresent` to `Always`, `Never`, and `IfNotPresent`. * The volume `source` is inlined into `volume` rather than nested. diff --git a/v1.1/docs/devel/api-conventions.md b/v1.1/docs/devel/api-conventions.md index 0cc4df9a66..5d6aad4aaf 100644 --- a/v1.1/docs/devel/api-conventions.md +++ b/v1.1/docs/devel/api-conventions.md @@ -5,12 +5,11 @@ Updated: 9/20/2015 *This document is oriented at users who want a deeper understanding of the Kubernetes API structure, and developers wanting to extend the Kubernetes API. An introduction to -using resources with kubectl can be found in [Working with resources](../user-guide/working-with-resources).* +using resources with kubectl can be found in [Working with resources](/{{page.version}}/docs/user-guide/working-with-resources).* * TOC {:toc} - The conventions of the [Kubernetes API](../api) (and related APIs in the ecosystem) are intended to ease client development and ensure that configuration mechanisms can be implemented that work across a diverse set of use cases consistently. The general style of the Kubernetes API is RESTful - clients create, update, delete, or retrieve a description of an object via the standard HTTP verbs (POST, PUT, DELETE, and GET) - and those APIs preferentially accept and return JSON. Kubernetes also exposes additional endpoints for non-standard verbs and allows alternative content types. All of the JSON accepted and returned by the server has a schema, identified by the "kind" and "apiVersion" fields. Where relevant HTTP header fields exist, they should mirror the content of JSON fields, but the information should not be represented only in the HTTP header. @@ -45,7 +44,7 @@ Kinds are grouped into three categories: Most objects defined in the system should have an endpoint that returns the full set of resources, as well as zero or more endpoints that return subsets of the full list. Some objects may be singletons (the current user, the system defaults) and may not have lists. - In addition, all lists that return objects with labels should support label filtering (see [docs/user-guide/labels.md](../user-guide/labels), and most lists should support filtering by fields. + In addition, all lists that return objects with labels should support label filtering (see [docs/user-guide/labels.md](/{{page.version}}/docs/user-guide/labels), and most lists should support filtering by fields. Examples: PodLists, ServiceLists, NodeLists @@ -63,7 +62,7 @@ Kinds are grouped into three categories: * `/status`: Used to write just the status portion of a resource. For example, the `/pods` endpoint only allows updates to `metadata` and `spec`, since those reflect end-user intent. An automated process should be able to modify status for users to see by sending an updated Pod kind to the server to the "/pods/<name>/status" endpoint - the alternate endpoint allows different rules to be applied to the update, and access to be appropriately restricted. * `/scale`: Used to read and write the count of a resource in a manner that is independent of the specific resource schema. - Two additional subresources, `proxy` and `portforward`, provide access to cluster resources as described in [docs/user-guide/accessing-the-cluster.md](../user-guide/accessing-the-cluster). + Two additional subresources, `proxy` and `portforward`, provide access to cluster resources as described in [docs/user-guide/accessing-the-cluster.md](/{{page.version}}/docs/user-guide/accessing-the-cluster). The standard REST verbs (defined below) MUST return singular JSON objects. Some API endpoints may deviate from the strict REST pattern and return resources that are not singular JSON objects, such as streams of JSON objects or unstructured text log data. @@ -84,9 +83,9 @@ These fields are required for proper decoding of the object. They may be populat Every object kind MUST have the following metadata in a nested object field called "metadata": -* namespace: a namespace is a DNS compatible subdomain that objects are subdivided into. The default namespace is 'default'. See [docs/user-guide/namespaces.md](../user-guide/namespaces) for more. -* name: a string that uniquely identifies this object within the current namespace (see [docs/user-guide/identifiers.md](../user-guide/identifiers)). This value is used in the path when retrieving an individual object. -* uid: a unique in time and space value (typically an RFC 4122 generated identifier, see [docs/user-guide/identifiers.md](../user-guide/identifiers)) used to distinguish between objects with the same name that have been deleted and recreated +* namespace: a namespace is a DNS compatible subdomain that objects are subdivided into. The default namespace is 'default'. See [docs/user-guide/namespaces.md](/{{page.version}}/docs/user-guide/namespaces) for more. +* name: a string that uniquely identifies this object within the current namespace (see [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers)). This value is used in the path when retrieving an individual object. +* uid: a unique in time and space value (typically an RFC 4122 generated identifier, see [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers)) used to distinguish between objects with the same name that have been deleted and recreated Every object SHOULD have the following metadata in a nested object field called "metadata": @@ -94,8 +93,8 @@ Every object SHOULD have the following metadata in a nested object field called * generation: a sequence number representing a specific generation of the desired state. Set by the system and monotonically increasing, per-resource. May be compared, such as for RAW and WAW consistency. * creationTimestamp: a string representing an RFC 3339 date of the date and time an object was created * deletionTimestamp: a string representing an RFC 3339 date of the date and time after which this resource will be deleted. This field is set by the server when a graceful deletion is requested by the user, and is not directly settable by a client. The resource will be deleted (no longer visible from resource lists, and not reachable by name) after the time in this field. Once set, this value may not be unset or be set further into the future, although it may be shortened or the resource may be deleted prior to this time. -* labels: a map of string keys and values that can be used to organize and categorize objects (see [docs/user-guide/labels.md](../user-guide/labels)) -* annotations: a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object (see [docs/user-guide/annotations.md](../user-guide/annotations)) +* labels: a map of string keys and values that can be used to organize and categorize objects (see [docs/user-guide/labels.md](/{{page.version}}/docs/user-guide/labels)) +* annotations: a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object (see [docs/user-guide/annotations.md](/{{page.version}}/docs/user-guide/annotations)) Labels are intended for organizational purposes by end users (select the pods that match this label query). Annotations enable third-party automation and tooling to decorate objects with additional metadata for their own use. @@ -140,19 +139,19 @@ In general, condition values may change back and forth, but some condition trans A typical oscillating condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. A possible monotonic condition could be `Succeeded`. A `False` status for `Succeeded` would imply failure. An object that was still active would not have a `Succeeded` condition, or its status would be `Unknown`. -Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](../design/principles.html#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion. +Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/tree/master/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion. In condition types, and everywhere else they appear in the API, **`Reason`** is intended to be a one-word, CamelCase representation of the category of cause of the current status, and **`Message`** is intended to be a human-readable phrase or sentence, which may contain specific details of the individual occurrence. `Reason` is intended to be used in concise output, such as one-line `kubectl get` output, and in summarizing occurrences of causes, whereas `Message` is intended to be presented to users in detailed status explanations, such as `kubectl describe` output. Historical information status (e.g., last transition time, failure counts) is only provided with reasonable effort, and is not guaranteed to not be lost. -Status information that may be large (especially proportional in size to collections of other resources, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](../design/resources.html#usage-data), should be put into separate objects, with possibly a reference from the original object. This helps to ensure that GETs and watch remain reasonably efficient for the majority of clients, which may not need that data. +Status information that may be large (especially proportional in size to collections of other resources, such as lists of references to other objects -- see below) and/or rapidly changing, such as [resource usage](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md#usage-data), should be put into separate objects, with possibly a reference from the original object. This helps to ensure that GETs and watch remain reasonably efficient for the majority of clients, which may not need that data. Some resources report the `observedGeneration`, which is the `generation` most recently observed by the component responsible for acting upon changes to the desired state of the resource. This can be used, for instance, to ensure that the reported status reflects the most recent desired status. #### References to related objects -References to loosely coupled sets of objects, such as [pods](../user-guide/pods) overseen by a [replication controller](../user-guide/replication-controller), are usually best referred to using a [label selector](../user-guide/labels). In order to ensure that GETs of individual objects remain bounded in time and space, these sets may be queried via separate API queries, but will not be expanded in the referring object's status. +References to loosely coupled sets of objects, such as [pods](/{{page.version}}/docs/user-guide/pods) overseen by a [replication controller](/{{page.version}}/docs/user-guide/replication-controller), are usually best referred to using a [label selector](/{{page.version}}/docs/user-guide/labels). In order to ensure that GETs of individual objects remain bounded in time and space, these sets may be queried via separate API queries, but will not be expanded in the referring object's status. References to specific objects, especially specific resource versions and/or specific fields of those objects, are specified using the `ObjectReference` type (or other types representing strict subsets of it). Unlike partial URLs, the ObjectReference type facilitates flexible defaulting of fields from the referring object or other contextual information. @@ -299,7 +298,7 @@ labels: ## Idempotency -All compatible Kubernetes APIs MUST support "name idempotency" and respond with an HTTP status code 409 when a request is made to POST an object that has the same name as an existing object in the system. See [docs/user-guide/identifiers.md](../user-guide/identifiers) for details. +All compatible Kubernetes APIs MUST support "name idempotency" and respond with an HTTP status code 409 when a request is made to POST an object that has the same name as an existing object in the system. See [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers) for details. Names generated by the system may be requested using `metadata.generateName`. GenerateName indicates that the name should be made unique by the server prior to persisting it. A non-empty value for the field indicates the name will be made unique (and the name returned to the client will be different than the name passed). The value of this field will be combined with a unique suffix on the server if the Name field has not been provided. The provided value must be valid within the rules for Name, and may be truncated by the length of the suffix required to make the value unique on the server. If this field is specified, and Name is not present, the server will NOT return a 409 if the generated name exists - instead, it will either return 201 Created or 504 with Reason `ServerTimeout` indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header). @@ -638,7 +637,7 @@ However, we should support conveniences for common cases by default. For example If the user wants to apply additional labels to the pods that it doesn't select upon, such as to facilitate adoption of pods or in the expectation that some label values will change, they can set the selector to a subset of the pod labels. Similarly, the RC's labels could be initialized to a subset of the pod template's labels, or could include additional/different labels. -For disciplined users managing resources within their own namespaces, it's not that hard to consistently apply schemas that ensure uniqueness. One just needs to ensure that at least one value of some label key in common differs compared to all other comparable resources. We could/should provide a verification tool to check that. However, development of conventions similar to the examples in [Labels](../user-guide/labels) make uniqueness straightforward. Furthermore, relatively narrowly used namespaces (e.g., per environment, per application) can be used to reduce the set of resources that could potentially cause overlap. +For disciplined users managing resources within their own namespaces, it's not that hard to consistently apply schemas that ensure uniqueness. One just needs to ensure that at least one value of some label key in common differs compared to all other comparable resources. We could/should provide a verification tool to check that. However, development of conventions similar to the examples in [Labels](/{{page.version}}/docs/user-guide/labels) make uniqueness straightforward. Furthermore, relatively narrowly used namespaces (e.g., per environment, per application) can be used to reduce the set of resources that could potentially cause overlap. In cases where users could be running misc. examples with inconsistent schemas, or where tooling or components need to programmatically generate new objects to be selected, there needs to be a straightforward way to generate unique label sets. A simple way to ensure uniqueness of the set is to ensure uniqueness of a single label value, such as by using a resource name, uid, resource hash, or generation number. diff --git a/v1.1/docs/devel/api_changes.md b/v1.1/docs/devel/api_changes.md index e94eb152f9..f2f3ba9472 100644 --- a/v1.1/docs/devel/api_changes.md +++ b/v1.1/docs/devel/api_changes.md @@ -182,7 +182,7 @@ pass (e.g., `heightInInches` from `height`, and vice versa), which runs just pri to conversion. That works fine when the user creates a resource from a hand-written configuration -- clients can write either field and read either field, but what about creation or update from the output of GET, or update via PATCH (see -[In-place updates](../user-guide/managing-deployments.html#in-place-updates-of-resources))? +[In-place updates](/{{page.version}}/docs/user-guide/managing-deployments/#in-place-updates-of-resources))? In this case, the two fields will conflict, because only one field would be updated in the case of an old client that was only aware of the old field (e.g., `height`). @@ -251,7 +251,7 @@ Breaking compatibility of a beta or stable API version, such as v1, is unaccepta Compatibility for experimental or alpha APIs is not strictly required, but breaking compatibility should not be done lightly, as it disrupts all users of the feature. Experimental APIs may be removed. Alpha and beta API versions may be deprecated -and eventually removed wholesale, as described in the [versioning document](../design/versioning). +and eventually removed wholesale, as described in the [versioning document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/versioning.md). Document incompatible changes across API versions under the [conversion tips](../api). If your change is going to be backward incompatible or might be a breaking change for API diff --git a/v1.1/docs/devel/coding-conventions.md b/v1.1/docs/devel/coding-conventions.md index 4f83ba6c2b..a93f8782af 100644 --- a/v1.1/docs/devel/coding-conventions.md +++ b/v1.1/docs/devel/coding-conventions.md @@ -8,7 +8,7 @@ Code conventions - https://google-styleguide.googlecode.com/svn/trunk/shell.xml - Ensure that build, release, test, and cluster-management scripts run on OS X - Go - - Ensure your code passes the [presubmit checks](development.html#hooks) + - Ensure your code passes the [presubmit checks](development/#hooks) - [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) - [Effective Go](https://golang.org/doc/effective_go) - Comment your code. @@ -47,7 +47,7 @@ Directory and file conventions - Package directories should generally avoid using separators as much as possible (when packages are multiple words, they usually should be in nested subdirectories). - Document directories and filenames should use dashes rather than underscores - Contrived examples that illustrate system features belong in /docs/user-guide or /docs/admin, depending on whether it is a feature primarily intended for users that deploy applications or cluster administrators, respectively. Actual application examples belong in /examples. - - Examples should also illustrate [best practices for using the system](../user-guide/config-best-practices) + - Examples should also illustrate [best practices for using the system](/{{page.version}}/docs/user-guide/config-best-practices) - Third-party code - Third-party Go code is managed using Godeps - Other third-party code belongs in /third_party diff --git a/v1.1/docs/devel/developer-guides/vagrant.md b/v1.1/docs/devel/developer-guides/vagrant.md index 87656ecb9a..fbdf2338ba 100644 --- a/v1.1/docs/devel/developer-guides/vagrant.md +++ b/v1.1/docs/devel/developer-guides/vagrant.md @@ -251,7 +251,7 @@ my-nginx nginx run=my-nginx 3 ``` We did not start any services, hence there are none listed. But we see three replicas displayed properly. -Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/README) application to learn how to create a service. +Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) application to learn how to create a service. You can already play with scaling the replicas with: ```shell diff --git a/v1.1/docs/devel/development.md b/v1.1/docs/devel/development.md index 6587e1d1ab..9cfec6a6a3 100644 --- a/v1.1/docs/devel/development.md +++ b/v1.1/docs/devel/development.md @@ -24,7 +24,7 @@ Below, we outline one of the more common git workflows that core developers use. ### Clone your fork -The commands below require that you have $GOPATH set ([$GOPATH docs](https://golang.org/doc/code.html#GOPATH)). We highly recommend you put Kubernetes' code into your GOPATH. Note: the commands below will not work if there is more than one directory in your `$GOPATH`. +The commands below require that you have $GOPATH set ([$GOPATH docs](https://golang.org/doc/code/#GOPATH)). We highly recommend you put Kubernetes' code into your GOPATH. Note: the commands below will not work if there is more than one directory in your `$GOPATH`. ```shell mkdir -p $GOPATH/src/k8s.io diff --git a/v1.1/docs/devel/index.md b/v1.1/docs/devel/index.md index 564ce00a81..60d7215123 100644 --- a/v1.1/docs/devel/index.md +++ b/v1.1/docs/devel/index.md @@ -3,8 +3,8 @@ title: "Kubernetes Developer Guide" --- The developer guide is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project. -It assumes some familiarity with concepts in the [User Guide](../user-guide/README) and the [Cluster Admin -Guide](../admin/README). +It assumes some familiarity with concepts in the [User Guide](/{{page.version}}/docs/user-guide/) and the [Cluster Admin +Guide](/{{page.version}}/docs/admin/). ## The process of developing and contributing code to the Kubernetes project @@ -45,7 +45,7 @@ Guide](../admin/README). * API objects are explained at [http://kubernetes.io/third_party/swagger-ui/](http://kubernetes.io/third_party/swagger-ui/). -* **Annotations** ([docs/user-guide/annotations.md](../user-guide/annotations)): are for attaching arbitrary non-identifying metadata to objects. +* **Annotations** ([docs/user-guide/annotations.md](/{{page.version}}/docs/user-guide/annotations)): are for attaching arbitrary non-identifying metadata to objects. Programs that automate Kubernetes objects may use annotations to store small amounts of their state. * **API Conventions** ([api-conventions.md](api-conventions)): @@ -57,14 +57,14 @@ Guide](../admin/README). ## Writing plugins -* **Authentication Plugins** ([docs/admin/authentication.md](../admin/authentication)): +* **Authentication Plugins** ([docs/admin/authentication.md](/{{page.version}}/docs/admin/authentication)): The current and planned states of authentication tokens. -* **Authorization Plugins** ([docs/admin/authorization.md](../admin/authorization)): +* **Authorization Plugins** ([docs/admin/authorization.md](/{{page.version}}/docs/admin/authorization)): Authorization applies to all HTTP requests on the main apiserver port. This doc explains the available authorization implementations. -* **Admission Control Plugins** ([admission_control](../design/admission_control)) +* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/kubernetes/tree/master/docs/design/admission_control.md)) ## Building releases diff --git a/v1.1/docs/devel/scheduler_algorithm.md b/v1.1/docs/devel/scheduler_algorithm.md index 47d51144ea..f016911891 100755 --- a/v1.1/docs/devel/scheduler_algorithm.md +++ b/v1.1/docs/devel/scheduler_algorithm.md @@ -11,7 +11,7 @@ The purpose of filtering the nodes is to filter out the nodes that do not meet c - `PodFitsResources`: Check if the free resource (CPU and Memory) meets the requirement of the Pod. The free resource is measured by the capacity minus the sum of requests of all Pods on the node. To learn more about the resource QoS in Kubernetes, please check [QoS proposal](../proposals/resource-qos). - `PodFitsHostPorts`: Check if any HostPort required by the Pod is already occupied on the node. - `PodFitsHost`: Filter out all nodes except the one specified in the PodSpec's NodeName field. -- `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](../user-guide/node-selection/) is an example of how to use `nodeSelector` field). +- `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](/{{page.version}}/docs/user-guide/node-selection/) is an example of how to use `nodeSelector` field). - `CheckNodeLabelPresence`: Check if all the specified labels exist on a node or not, regardless of the value. The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). diff --git a/v1.1/docs/devel/writing-a-getting-started-guide.md b/v1.1/docs/devel/writing-a-getting-started-guide.md index 2cdf97f7d1..a50cc5861c 100644 --- a/v1.1/docs/devel/writing-a-getting-started-guide.md +++ b/v1.1/docs/devel/writing-a-getting-started-guide.md @@ -12,7 +12,7 @@ A guide refers to scripts, Configuration Management files, and/or binary assets the combination of all these things needed to run on a particular type of infrastructure a **distro**. -[The Matrix](/{{page.version}}/docs/getting-started-guides/README) lists the distros. If there is already a guide +[The Matrix](/{{page.version}}/docs/getting-started-guides/) lists the distros. If there is already a guide which is similar to the one you have planned, consider improving that one. @@ -35,9 +35,9 @@ These guidelines say *what* to do. See the Rationale section for *why*. search for uses of flags by guides. - We may ask that you host binary assets or large amounts of code in our `contrib` directory or on your own repo. - - Add or update a row in [The Matrix](/{{page.version}}/docs/getting-started-guides/README). + - Add or update a row in [The Matrix](/{{page.version}}/docs/getting-started-guides/). - State the binary version of Kubernetes that you tested clearly in your Guide doc. - - Setup a cluster and run the [conformance test](development.html#conformance-testing) against it, and report the + - Setup a cluster and run the [conformance test](development/#conformance-testing) against it, and report the results in your PR. - Versioned distros should typically not modify or add code in `cluster/`. That is just scripts for developer distros. @@ -46,7 +46,7 @@ These guidelines say *what* to do. See the Rationale section for *why*. If you have a cluster partially working, but doing all the above steps seems like too much work, we still want to hear from you. We suggest you write a blog post or a Gist, and we will link to it on our wiki page. -Just file an issue or chat us on [Slack](../troubleshooting.html#slack) and one of the committers will link to it from the wiki. +Just file an issue or chat us on [Slack](../troubleshooting/#slack) and one of the committers will link to it from the wiki. ## Development Distro Guidelines diff --git a/v1.1/docs/getting-started-guides/README.md b/v1.1/docs/getting-started-guides/README.md index 1b80126748..62af299cc6 100644 --- a/v1.1/docs/getting-started-guides/README.md +++ b/v1.1/docs/getting-started-guides/README.md @@ -50,7 +50,7 @@ few commands, and have active community support. - [GCE](gce) - [AWS](aws) -- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) +- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/) ### Custom Solutions @@ -116,7 +116,7 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['��][3] | Commercial Vagrant | Saltstack | Fedora | flannel | [docs](vagrant) | ['��][2] | Project GCE | Saltstack | Debian | GCE | [docs](gce) | ['��][1] | Project -Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin)) +Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin)) Docker Single Node | custom | N/A | local | [docs](docker) | | Project ([@brendandburns](https://github.com/brendandburns)) Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns)) Bare-metal | Ansible | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project diff --git a/v1.1/docs/getting-started-guides/azure.md b/v1.1/docs/getting-started-guides/azure.md index 4cb456517f..dd82d979b9 100644 --- a/v1.1/docs/getting-started-guides/azure.md +++ b/v1.1/docs/getting-started-guides/azure.md @@ -4,7 +4,7 @@ title: "Getting started on Microsoft Azure" ## Getting started on Microsoft Azure -Checkout the [coreos azure getting started guide](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) +Checkout the [coreos azure getting started guide](/{{page.version}}/docs/getting-started-guides/coreos/azure/) diff --git a/v1.1/docs/getting-started-guides/centos/centos_manual_config.md b/v1.1/docs/getting-started-guides/centos/centos_manual_config.md index 6799b4e1a6..f93c46d5b0 100644 --- a/v1.1/docs/getting-started-guides/centos/centos_manual_config.md +++ b/v1.1/docs/getting-started-guides/centos/centos_manual_config.md @@ -12,7 +12,7 @@ You need two machines with CentOS installed on them. This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc... -This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](../../admin/networking) done outside of kubernetes. Although the additional Kubernetes configuration requirements should be obvious. +This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](/{{page.version}}/docs/admin/networking) done outside of kubernetes. Although the additional Kubernetes configuration requirements should be obvious. The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_. The remaining host, centos-minion will be the node and run kubelet, proxy, cadvisor and docker. @@ -168,4 +168,4 @@ centos-minion Ready **The cluster should be running! Launch a test pod.** -You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/README)! \ No newline at end of file +You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/)! \ No newline at end of file diff --git a/v1.1/docs/getting-started-guides/coreos.md b/v1.1/docs/getting-started-guides/coreos.md index f2d92a946f..6aabfdcf7a 100644 --- a/v1.1/docs/getting-started-guides/coreos.md +++ b/v1.1/docs/getting-started-guides/coreos.md @@ -63,7 +63,7 @@ Guide to running a single master, multi-worker cluster controlled by an OS X men
-[**Resizable multi-node cluster on Azure with Weave**](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) +[**Resizable multi-node cluster on Azure with Weave**](/{{page.version}}/docs/getting-started-guides/coreos/azure/) Guide to running an HA etcd cluster with a single master on Azure. Uses the Azure node.js CLI to resize the cluster. diff --git a/v1.1/docs/getting-started-guides/dcos.md b/v1.1/docs/getting-started-guides/dcos.md index 7860ef7b51..bf735c6043 100644 --- a/v1.1/docs/getting-started-guides/dcos.md +++ b/v1.1/docs/getting-started-guides/dcos.md @@ -28,7 +28,7 @@ Explore the following resources for more information about Kubernetes, Kubernete - [DCOS Documentation](https://docs.mesosphere.com/) - [Managing DCOS Services](https://docs.mesosphere.com/services/kubernetes/) -- [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/master/examples/README) +- [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/master/examples/) - [Kubernetes on Mesos Documentation](https://releases.k8s.io/release-1.1/contrib/mesos/README.md) - [Kubernetes on Mesos Release Notes](https://github.com/mesosphere/kubernetes-mesos/releases) - [Kubernetes on DCOS Package Source](https://github.com/mesosphere/kubernetes-mesos) @@ -105,7 +105,7 @@ $ dcos kubectl get pods --namespace=kube-system Names and ages may vary. -Now that Kubernetes is installed on DCOS, you may wish to explore the [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/master/examples/) or the [Kubernetes User Guide](../user-guide/README). +Now that Kubernetes is installed on DCOS, you may wish to explore the [Kubernetes Examples](https://github.com/kubernetes/kubernetes/tree/master/examples/) or the [Kubernetes User Guide](/{{page.version}}/docs/user-guide/). ## Uninstall diff --git a/v1.1/docs/getting-started-guides/docker-multinode/master.md b/v1.1/docs/getting-started-guides/docker-multinode/master.md index b94c202b27..51201c8066 100644 --- a/v1.1/docs/getting-started-guides/docker-multinode/master.md +++ b/v1.1/docs/getting-started-guides/docker-multinode/master.md @@ -171,7 +171,7 @@ NAME LABELS STATUS ``` If the status of the node is `NotReady` or `Unknown` please check that all of the containers you created are successfully running. -If all else fails, ask questions on [Slack](../../troubleshooting.html#slack). +If all else fails, ask questions on [Slack](../../troubleshooting/#slack). ### Next steps diff --git a/v1.1/docs/getting-started-guides/docker-multinode/testing.md b/v1.1/docs/getting-started-guides/docker-multinode/testing.md index 54386bc7a7..ccdb660202 100644 --- a/v1.1/docs/getting-started-guides/docker-multinode/testing.md +++ b/v1.1/docs/getting-started-guides/docker-multinode/testing.md @@ -15,7 +15,7 @@ NAME LABELS STATUS 127.0.0.1 kubernetes.io/hostname=127.0.0.1 Ready ``` -If the status of any node is `Unknown` or `NotReady` your cluster is broken, double check that all containers are running properly, and if all else fails, contact us on [Slack](../../troubleshooting.html#slack). +If the status of any node is `Unknown` or `NotReady` your cluster is broken, double check that all containers are running properly, and if all else fails, contact us on [Slack](../../troubleshooting/#slack). ### Run an application diff --git a/v1.1/docs/getting-started-guides/docker.md b/v1.1/docs/getting-started-guides/docker.md index fdc5ee6435..497981940d 100644 --- a/v1.1/docs/getting-started-guides/docker.md +++ b/v1.1/docs/getting-started-guides/docker.md @@ -65,7 +65,7 @@ docker run \ /hyperkube kubelet --containerized --hostname-override="127.0.0.1" --address="0.0.0.0" --api-servers=http://localhost:8080 --config=/etc/kubernetes/manifests ``` -This actually runs the kubelet, which in turn runs a [pod](../user-guide/pods) that contains the other master components. +This actually runs the kubelet, which in turn runs a [pod](/{{page.version}}/docs/user-guide/pods) that contains the other master components. ### Step Three: Run the service proxy diff --git a/v1.1/docs/getting-started-guides/fedora/fedora_manual_config.md b/v1.1/docs/getting-started-guides/fedora/fedora_manual_config.md index e87c1a38c3..0e8c60f4f9 100644 --- a/v1.1/docs/getting-started-guides/fedora/fedora_manual_config.md +++ b/v1.1/docs/getting-started-guides/fedora/fedora_manual_config.md @@ -12,7 +12,7 @@ title: "Getting started on Fedora" This is a getting started guide for [Fedora](http://fedoraproject.org). It is a manual configuration so you understand all the underlying packages / services / ports, etc... -This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](../../admin/networking) +This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/{{page.version}}/docs/admin/networking) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious. The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These @@ -212,4 +212,4 @@ kubectl delete -f ./node.json **The cluster should be running! Launch a test pod.** -You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/README)! +You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/)! diff --git a/v1.1/docs/getting-started-guides/gce.md b/v1.1/docs/getting-started-guides/gce.md index 32e69d087f..c687579c80 100644 --- a/v1.1/docs/getting-started-guides/gce.md +++ b/v1.1/docs/getting-started-guides/gce.md @@ -53,8 +53,8 @@ cluster/kube-up.sh If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster. -If you run into trouble, please see the section on [troubleshooting](gce.html#troubleshooting), post to the -[google-containers group](https://groups.google.com/forum/#!forum/google-containers), or come ask questions on [Slack](../troubleshooting.html#slack). +If you run into trouble, please see the section on [troubleshooting](gce/#troubleshooting), post to the +[google-containers group](https://groups.google.com/forum/#!forum/google-containers), or come ask questions on [Slack](../troubleshooting/#slack). The next few steps will show you: @@ -68,7 +68,7 @@ The next few steps will show you: The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation. The next step is to make sure the `kubectl` tool is in your path. -The [kubectl](../user-guide/kubectl/kubectl) tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. +The [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. Add the appropriate binary folder to your `PATH` to access kubectl: @@ -113,7 +113,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru $ kubectl get --all-namespaces services ``` -should show a set of [services](../user-guide/services) that look something like this: +should show a set of [services](/{{page.version}}/docs/user-guide/services) that look something like this: ```shell NAMESPACE NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE @@ -123,7 +123,7 @@ kube-system kube-ui 10.0.0.3 80/TCP ... ``` -Similarly, you can take a look at the set of [pods](../user-guide/pods) that were created during cluster startup. +Similarly, you can take a look at the set of [pods](/{{page.version}}/docs/user-guide/pods) that were created during cluster startup. You can do this via the ```shell diff --git a/v1.1/docs/getting-started-guides/index.md b/v1.1/docs/getting-started-guides/index.md index 6969c932e7..ddcd34ab0f 100644 --- a/v1.1/docs/getting-started-guides/index.md +++ b/v1.1/docs/getting-started-guides/index.md @@ -51,7 +51,7 @@ few commands, and have active community support. - [GCE](gce) - [AWS](aws) -- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) +- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/) ### Custom Solutions @@ -117,7 +117,7 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['œ“][3] | Commercial Vagrant | Saltstack | Fedora | flannel | [docs](vagrant) | ['œ“][2] | Project GCE | Saltstack | Debian | GCE | [docs](gce) | ['œ“][1] | Project -Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/README) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin)) +Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin)) Docker Single Node | custom | N/A | local | [docs](docker) | | Project ([@brendandburns](https://github.com/brendandburns)) Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns)) Bare-metal | Ansible | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project diff --git a/v1.1/docs/getting-started-guides/locally.md b/v1.1/docs/getting-started-guides/locally.md index 383c0ce7f6..d321b4ae7a 100644 --- a/v1.1/docs/getting-started-guides/locally.md +++ b/v1.1/docs/getting-started-guides/locally.md @@ -69,8 +69,8 @@ cluster/kubectl.sh get replicationcontrollers ### Running a user defined pod -Note the difference between a [container](../user-guide/containers) -and a [pod](../user-guide/pods). Since you only asked for the former, Kubernetes will create a wrapper pod for you. +Note the difference between a [container](/{{page.version}}/docs/user-guide/containers) +and a [pod](/{{page.version}}/docs/user-guide/pods). Since you only asked for the former, Kubernetes will create a wrapper pod for you. However you cannot view the nginx start page on localhost. To verify that nginx is running you need to run `curl` within the docker container (try `docker exec`). You can control the specifications of a pod via a user defined manifest, and reach nginx through your browser on the port specified therein: diff --git a/v1.1/docs/getting-started-guides/logging.md b/v1.1/docs/getting-started-guides/logging.md index db2dcca03f..8a905e683f 100644 --- a/v1.1/docs/getting-started-guides/logging.md +++ b/v1.1/docs/getting-started-guides/logging.md @@ -22,7 +22,7 @@ Here is the same information in a picture which shows how the pods might be plac ![Cluster](https://github.com/kubernetes/kubernetes/tree/master/examples/blog-logging/diagrams/cloud-logging.png) This diagram shows four nodes created on a Google Compute Engine cluster with the name of each VM node on a purple background. The internal and public IPs of each node are shown on gray boxes and the pods running in each node are shown in green boxes. Each pod box shows the name of the pod and the namespace it runs in, the IP address of the pod and the images which are run as part of the pod's execution. Here we see that every node is running a fluentd-cloud-logging pod which is collecting the log output of the containers running on the same node and sending them to Google Cloud Logging. A pod which provides the -[cluster DNS service](../admin/dns) runs on one of the nodes and a pod which provides monitoring support runs on another node. +[cluster DNS service](/{{page.version}}/docs/admin/dns) runs on one of the nodes and a pod which provides monitoring support runs on another node. To help explain how cluster level logging works let's start off with a synthetic log generator pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/master/examples/blog-logging/counter-pod.yaml): diff --git a/v1.1/docs/getting-started-guides/mesos-docker.md b/v1.1/docs/getting-started-guides/mesos-docker.md index bbaea4b3d0..eb9ab1c2e5 100644 --- a/v1.1/docs/getting-started-guides/mesos-docker.md +++ b/v1.1/docs/getting-started-guides/mesos-docker.md @@ -182,7 +182,7 @@ host machine (mac). 1. Explore examples To learn more about Pods, Volumes, Labels, Services, and Replication Controllers, start with the - [Kubernetes Walkthrough](../user-guide/walkthrough/). + [Kubernetes Walkthrough](/{{page.version}}/docs/user-guide/walkthrough/). To skip to a more advanced example, see the [Guestbook Example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) diff --git a/v1.1/docs/getting-started-guides/scratch.md b/v1.1/docs/getting-started-guides/scratch.md index d4d4f76ef5..45eb055434 100644 --- a/v1.1/docs/getting-started-guides/scratch.md +++ b/v1.1/docs/getting-started-guides/scratch.md @@ -140,7 +140,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](/{{page.version}}/docs/devel/README). Only using a binary release is covered in this guide. +[Developer Documentation](/{{page.version}}/docs/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. Then locate `./kubernetes/server/kubernetes-server-linux-amd64.tar.gz` and unzip *that*. @@ -806,7 +806,7 @@ Otherwise, you will need to manually create node objects. ### Inspect pods and services -Try to run through the "Inspect your cluster" section in one of the other Getting Started Guides, such as [GCE](/{{page.version}}/docs/getting-started-guides/gce.html#inspect-your-cluster). +Try to run through the "Inspect your cluster" section in one of the other Getting Started Guides, such as [GCE](/{{page.version}}/docs/getting-started-guides/gce/#inspect-your-cluster). You should see some services. You should also see "mirror pods" for the apiserver, scheduler and controller-manager, plus any add-ons you started. ### Try Examples diff --git a/v1.1/docs/getting-started-guides/ubuntu-calico.md b/v1.1/docs/getting-started-guides/ubuntu-calico.md index a5107d6f95..ef3e15a8c3 100644 --- a/v1.1/docs/getting-started-guides/ubuntu-calico.md +++ b/v1.1/docs/getting-started-guides/ubuntu-calico.md @@ -252,7 +252,7 @@ With this sample configuration, because the containers have private `192.168.0.0 ### NAT on the nodes -The simplest method for enabling connectivity from containers to the internet is to use an iptables masquerade rule. This is the standard mechanism [recommended](/{{page.version}}/docs/admin/networking.html#google-compute-engine-gce) in the Kubernetes GCE environment. +The simplest method for enabling connectivity from containers to the internet is to use an iptables masquerade rule. This is the standard mechanism [recommended](/{{page.version}}/docs/admin/networking/#google-compute-engine-gce) in the Kubernetes GCE environment. We need to NAT traffic that has a destination outside of the cluster. Internal traffic includes the master/nodes, and the container IP pools. A suitable masquerade chain would follow the pattern below, replacing the following variables: diff --git a/v1.1/docs/getting-started-guides/vagrant.md b/v1.1/docs/getting-started-guides/vagrant.md index 540b5625aa..e3c7d6967b 100644 --- a/v1.1/docs/getting-started-guides/vagrant.md +++ b/v1.1/docs/getting-started-guides/vagrant.md @@ -240,7 +240,7 @@ my-nginx 10.0.0.1 80/TCP run=my-nginx ``` We did not start any services, hence there are none listed. But we see three replicas displayed properly. -Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/README) application to learn how to create a service. +Check the [guestbook](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) application to learn how to create a service. You can already play with scaling the replicas with: ```shell @@ -293,7 +293,7 @@ If this is your first time creating the cluster, the kubelet on each node schedu #### I want to make changes to Kubernetes code! -To set up a vagrant cluster for hacking, follow the [vagrant developer guide](../devel/developer-guides/vagrant). +To set up a vagrant cluster for hacking, follow the [vagrant developer guide](/{{page.version}}/docs/devel/developer-guides/vagrant). #### I have brought Vagrant up but the nodes cannot validate! diff --git a/v1.1/docs/index.md b/v1.1/docs/index.md index d4df3427d0..4d64c4642f 100644 --- a/v1.1/docs/index.md +++ b/v1.1/docs/index.md @@ -1,29 +1,29 @@ --- title: "Kubernetes Documentation: releases.k8s.io/release-1.1" --- -* The [User's guide](user-guide/README) is for anyone who wants to run programs and +* The [User's guide](/{{page.version}}/docs/user-guide/) is for anyone who wants to run programs and services on an existing Kubernetes cluster. -* The [Cluster Admin's guide](admin/README) is for anyone setting up +* The [Cluster Admin's guide](/{{page.version}}/docs/admin/) is for anyone setting up a Kubernetes cluster or administering it. -* The [Developer guide](devel/README) is for anyone wanting to write +* The [Developer guide](/{{page.version}}/docs/devel/) is for anyone wanting to write programs that access the Kubernetes API, write plugins or extensions, or modify the core code of Kubernetes. -* The [Kubectl Command Line Interface](user-guide/kubectl/kubectl) is a detailed reference on +* The [Kubectl Command Line Interface](/{{page.version}}/docs/user-guide/kubectl/kubectl) is a detailed reference on the `kubectl` CLI. * The [API object documentation](http://kubernetes.io/third_party/swagger-ui/) is a detailed description of all fields found in core API objects. -* An overview of the [Design of Kubernetes](design/) +* An overview of the [Design of Kubernetes](https://github.com/kubernetes/kubernetes/tree/master/docs/design/) * There are example files and walkthroughs in the [examples](https://github.com/kubernetes/kubernetes/tree/master/examples) folder. * If something went wrong, see the [troubleshooting](troubleshooting) document for how to debug. -You should also check the [known issues](user-guide/known-issues) for the release you're using. +You should also check the [known issues](/{{page.version}}/docs/user-guide/known-issues) for the release you're using. * To report a security issue, see [Reporting a Security Issue](reporting-security-issues). diff --git a/v1.1/docs/troubleshooting.md b/v1.1/docs/troubleshooting.md index 0deb46f041..2bfa665ad0 100644 --- a/v1.1/docs/troubleshooting.md +++ b/v1.1/docs/troubleshooting.md @@ -3,10 +3,10 @@ title: "Troubleshooting" --- Sometimes things go wrong. This guide is aimed at making them right. It has two sections: - * [Troubleshooting your application](user-guide/application-troubleshooting) - Useful for users who are deploying code into Kubernetes and wondering why it is not working. - * [Troubleshooting your cluster](admin/cluster-troubleshooting) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy. + * [Troubleshooting your application](/{{page.version}}/docs/user-guide/application-troubleshooting) - Useful for users who are deploying code into Kubernetes and wondering why it is not working. + * [Troubleshooting your cluster](/{{page.version}}/docs/admin/cluster-troubleshooting) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy. -You should also check the [known issues](user-guide/known-issues) for the release you're using. +You should also check the [known issues](/{{page.version}}/docs/user-guide/known-issues) for the release you're using. # Getting help @@ -14,7 +14,7 @@ If your problem isn't answered by any of the guides above, there are variety of ## Questions -If you aren't familiar with it, many of your questions may be answered by the [user guide](user-guide/README). +If you aren't familiar with it, many of your questions may be answered by the [user guide](/{{page.version}}/docs/user-guide/). We also have a number of FAQ pages: diff --git a/v1.1/docs/user-guide/README.md b/v1.1/docs/user-guide/README.md index b69fedf9a1..00d667330b 100644 --- a/v1.1/docs/user-guide/README.md +++ b/v1.1/docs/user-guide/README.md @@ -4,13 +4,13 @@ title: "Kubernetes User Guide: Managing Applications" * TOC {:toc} -The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/README). The [Developer Guide](/{{page.version}}/docs/devel/README) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project. +The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project. Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs). ## Quick walkthrough -1. [Kubernetes 101](walkthrough/README) +1. [Kubernetes 101](walkthrough/) 1. [Kubernetes 201](walkthrough/k8s201) ## Thorough walkthrough @@ -36,10 +36,10 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo [**Overview**](overview) : A brief overview of Kubernetes concepts. -[**Cluster**](../admin/README) +[**Cluster**](/{{page.version}}/docs/admin/) : A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications. -[**Node**](../admin/node) +[**Node**](/{{page.version}}/docs/admin/node) : A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled. [**Pod**](pods) @@ -48,7 +48,7 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo [**Label**](labels) : A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources. -[**Selector**](labels.html#label-selectors) +[**Selector**](labels/#label-selectors) : A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service. [**Replication Controller**](replication-controller) @@ -87,7 +87,4 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo * [Migrating from docker-cli to kubectl](docker-cli-to-kubectl) * [Tips and tricks when working with config](config-best-practices) * [Assign pods to selected nodes](node-selection/) - * [Perform a rolling update on a running group of pods](update-demo/) - - - + * [Perform a rolling update on a running group of pods](update-demo/) \ No newline at end of file diff --git a/v1.1/docs/user-guide/accessing-the-cluster.md b/v1.1/docs/user-guide/accessing-the-cluster.md index 9c49d4fa89..4e5df3988d 100644 --- a/v1.1/docs/user-guide/accessing-the-cluster.md +++ b/v1.1/docs/user-guide/accessing-the-cluster.md @@ -13,7 +13,7 @@ Kubernetes CLI, `kubectl`. To access a cluster, you need to know the location of the cluster and have credentials to access it. Typically, this is automatically set-up when you work through -though a [Getting started guide](../getting-started-guides/README), +though a [Getting started guide](/{{page.version}}/docs/getting-started-guides/), or someone else setup the cluster and provided you with credentials and a location. Check the location and credentials that kubectl knows about with this command: @@ -90,13 +90,13 @@ certificate. On some clusters, the apiserver does not require authentication; it may serve on localhost, or be protected by a firewall. There is not a standard -for this. [Configuring Access to the API](../admin/accessing-the-api) +for this. [Configuring Access to the API](/{{page.version}}/docs/admin/accessing-the-api) describes how a cluster admin can configure this. Such approaches may conflict with future high-availability support. ### Programmatic access to the API -There are [client libraries](../devel/client-libraries) for accessing the API +There are [client libraries](/{{page.version}}/docs/devel/client-libraries) for accessing the API from several languages. The Kubernetes project-supported [Go](http://releases.k8s.io/release-1.1/pkg/client/) client library can use the same [kubeconfig file](kubeconfig-file) @@ -136,7 +136,7 @@ In each case, the credentials of the pod are used to communicate securely with t The previous section was about connecting the Kubernetes API server. This section is about connecting to other services running on Kubernetes cluster. In Kubernetes, the -[nodes](../admin/node), [pods](pods) and [services](services) all have +[nodes](/{{page.version}}/docs/admin/node), [pods](pods) and [services](services) all have their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be routable, so they will not be reachable from a machine outside the cluster, such as your desktop machine. @@ -251,7 +251,7 @@ There are several different proxies you may encounter when using Kubernetes: - proxy to target may use HTTP or HTTPS as chosen by proxy using available information - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service - 1. The [kube proxy](services.html#ips-and-vips): + 1. The [kube proxy](services/#ips-and-vips): - runs on each node - proxies UDP and TCP - does not understand HTTP diff --git a/v1.1/docs/user-guide/application-troubleshooting.md b/v1.1/docs/user-guide/application-troubleshooting.md index f347bb10e9..743b2c26af 100644 --- a/v1.1/docs/user-guide/application-troubleshooting.md +++ b/v1.1/docs/user-guide/application-troubleshooting.md @@ -3,7 +3,7 @@ title: "Application Troubleshooting" --- This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly. This is *not* a guide for people who want to debug their cluster. For that you should check out -[this guide](../admin/cluster-troubleshooting) +[this guide](/{{page.version}}/docs/admin/cluster-troubleshooting) * TOC {:toc} @@ -41,7 +41,7 @@ there are insufficient resources of one type or another that prevent scheduling. your pod. Reasons include: * **You don't have enough resources**: You may have exhausted the supply of CPU or Memory in your cluster, in this case -you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources.html#my-pods-are-pending-with-event-message-failedscheduling) for more information. +you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information. * **You are using `hostPort`**: When you bind a Pod to a `hostPort` there are a limited number of places that pod can be scheduled. In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod. If you do require diff --git a/v1.1/docs/user-guide/compute-resources.md b/v1.1/docs/user-guide/compute-resources.md index 36ed90e58f..ecee8d9401 100644 --- a/v1.1/docs/user-guide/compute-resources.md +++ b/v1.1/docs/user-guide/compute-resources.md @@ -171,7 +171,7 @@ Here you can see from the `Allocated resources` section that that a pod which as Looking at the `Pods` section, you can see which pods are taking up space on the node. -The [resource quota](../admin/resource-quota) feature can be configured +The [resource quota](/{{page.version}}/docs/admin/resource-quota) feature can be configured to limit the total amount of resources that can be consumed. If used in conjunction with namespaces, it can prevent one team from hogging all the resources. @@ -234,11 +234,11 @@ We can see that this container was terminated because `reason:OOM Killed`, where The current system only allows resource quantities to be specified on a container. It is planned to improve accounting for resources which are shared by all containers in a pod, -such as [EmptyDir volumes](volumes.html#emptydir). +such as [EmptyDir volumes](volumes/#emptydir). The current system only supports container requests and limits for CPU and Memory. It is planned to add new resource types, including a node disk space -resource, and a framework for adding custom [resource types](../design/resources.html#resource-types). +resource, and a framework for adding custom [resource types](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md#resource-types). Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168). diff --git a/v1.1/docs/user-guide/config-best-practices.md b/v1.1/docs/user-guide/config-best-practices.md index 30ddeade8e..c56a34b37d 100644 --- a/v1.1/docs/user-guide/config-best-practices.md +++ b/v1.1/docs/user-guide/config-best-practices.md @@ -9,13 +9,13 @@ This document is meant to highlight and consolidate in one place configuration b 1. Group related objects together in a single file. This is often better than separate files. 1. Use `kubectl create -f ` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `` and passes them to create. 1. Create a service before corresponding replication controllers so that the scheduler can spread the pods comprising the service. You can also create the replication controller without specifying replicas, create the service, then scale up the replication controller, which may work better in an example using progressive disclosure and may have benefits in real scenarios also, such as ensuring one replica works before creating lots of them) -1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](services.html#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](connecting-to-applications-proxy) or [kubectl port-forward](connecting-to-applications-port-forward). +1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](services/#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](connecting-to-applications-proxy) or [kubectl port-forward](connecting-to-applications-port-forward). 1. Don't use `hostNetwork` for the same reasons as `hostPort`. 1. Don't specify default values unnecessarily, to simplify and minimize configs. For example, omit the selector and labels in ReplicationController if you want them to be the same as the labels in its podTemplate, since those fields are populated from the podTemplate labels by default. 1. Instead of attaching one label to a set of pods to represent a service (e.g., `service: myservice`) and another to represent the replication controller managing the pods (e.g., `controller: mycontroller`), attach labels that identify semantic attributes of your application or deployment and select the appropriate subsets in your service and replication controller, such as `{ app: myapp, tier: frontend, deployment: v3 }`. A service can be made to span multiple deployments, such as across rolling updates, by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully. -1. Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](labels.html#label-selectors) and [using labels effectively](managing-deployments.html#using-labels-effectively). +1. Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](labels/#label-selectors) and [using labels effectively](managing-deployments/#using-labels-effectively). 1. Use kubectl run and expose to quickly create and expose single container replication controllers. See the [quick start guide](quick-start) for an example. -1. Use headless services for easy service discovery when you don't need kube-proxy load balancing. See [headless services](services.html#headless-services). +1. Use headless services for easy service discovery when you don't need kube-proxy load balancing. See [headless services](services/#headless-services). 1. Use kubectl delete rather than stop. Delete has a superset of the functionality of stop and stop is deprecated. 1. If there is a viable alternative to naked pods (i.e. pods not bound to a controller), go with the alternative. Controllers are almost always preferable to creating pods (except for some `restartPolicy: Never` scenarios). A minimal Job is coming. See [#1624](http://issue.k8s.io/1624). Naked pods will not be rescheduled in the event of node failure. 1. Put a version number or hash as a suffix to the name and in a label on a replication controller to facilitate rolling update, as we do for [--image](kubectl/kubectl_rolling-update). This is necessary because rolling-update actually creates a new controller as opposed to modifying the existing controller. This does not play well with version agnostic controller names. diff --git a/v1.1/docs/user-guide/configuring-containers.md b/v1.1/docs/user-guide/configuring-containers.md index 55201f37b9..8175c3cf4c 100644 --- a/v1.1/docs/user-guide/configuring-containers.md +++ b/v1.1/docs/user-guide/configuring-containers.md @@ -31,7 +31,7 @@ The value of `metadata.name`, `hello-world`, will be the name of the pod resourc `restartPolicy: Never` indicates that we just want to run the container once and then terminate the pod. -The [`command`](containers.html#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows: +The [`command`](containers/#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows: ```yaml command: ["/bin/echo"] @@ -65,7 +65,7 @@ pods/hello-world `kubectl create --validate` currently warns about problems it detects, but creates the resource anyway, unless a required field is absent or a field value is invalid. Unknown API fields are ignored, so be careful. This pod was created, but with no `command`, which is an optional field, since the image may specify an `Entrypoint`. View the [Pod API -object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_pod) +object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_pod) to see the list of valid fields. ## Environment variables and variable expansion @@ -89,7 +89,7 @@ spec: # specification of the pod's contents args: ["/bin/echo \"${MESSAGE}\""] ``` -However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](/{{page.version}}/docs/design/expansion): +However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/master/docs/design/expansion): ```yaml command: ["/bin/echo"] diff --git a/v1.1/docs/user-guide/connecting-applications.md b/v1.1/docs/user-guide/connecting-applications.md index 93e51b3f75..602b872377 100644 --- a/v1.1/docs/user-guide/connecting-applications.md +++ b/v1.1/docs/user-guide/connecting-applications.md @@ -57,7 +57,7 @@ $ kubectl get pods -l app=nginx -o json | grep podIP You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model. -You can read more about [how we achieve this](../admin/networking.html#how-to-achieve-this) if you're curious. +You can read more about [how we achieve this](/{{page.version}}/docs/admin/networking/#how-to-achieve-this) if you're curious. ## Creating a Service @@ -83,7 +83,7 @@ spec: app: nginx ``` -This specification will create a Service which targets TCP port 80 on any Pod with the `app=nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_service) to see the list of supported fields in service definition. +This specification will create a Service which targets TCP port 80 on any Pod with the `app=nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_service) to see the list of supported fields in service definition. Check your Service: ```shell @@ -113,7 +113,7 @@ NAME ENDPOINTS nginxsvc 10.245.0.14:80,10.245.0.15:80 ``` -You should now be able to curl the nginx Service on `10.0.116.146:80` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire, if you're curious about how this works you can read more about the [service proxy](services.html#virtual-ips-and-service-proxies). +You should now be able to curl the nginx Service on `10.0.116.146:80` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire, if you're curious about how this works you can read more about the [service proxy](services/#virtual-ips-and-service-proxies). ## Accessing the Service @@ -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/README), in short: +You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/master/examples/https-nginx/), in short: ```shell $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json diff --git a/v1.1/docs/user-guide/connecting-to-applications-port-forward.md b/v1.1/docs/user-guide/connecting-to-applications-port-forward.md index f5196e9ba6..5b5dc0438e 100644 --- a/v1.1/docs/user-guide/connecting-to-applications-port-forward.md +++ b/v1.1/docs/user-guide/connecting-to-applications-port-forward.md @@ -1,7 +1,7 @@ --- title: "Connecting to applications: kubectl port-forward" --- -kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward). Compared to [kubectl proxy](accessing-the-cluster.html#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging. +kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward). Compared to [kubectl proxy](accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging. ## Creating a Redis master diff --git a/v1.1/docs/user-guide/connecting-to-applications-proxy.md b/v1.1/docs/user-guide/connecting-to-applications-proxy.md index fe6c6be945..8ae0f8e27f 100644 --- a/v1.1/docs/user-guide/connecting-to-applications-proxy.md +++ b/v1.1/docs/user-guide/connecting-to-applications-proxy.md @@ -13,7 +13,7 @@ $ kubectl cluster-info | grep "KubeUI" KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui ``` -if this command does not find the URL, try the steps [here](ui.html#accessing-the-ui). +if this command does not find the URL, try the steps [here](ui/#accessing-the-ui). ## Connecting to the kube-ui service from your local workstation diff --git a/v1.1/docs/user-guide/container-environment.md b/v1.1/docs/user-guide/container-environment.md index e14ded1c50..faeda32955 100644 --- a/v1.1/docs/user-guide/container-environment.md +++ b/v1.1/docs/user-guide/container-environment.md @@ -52,7 +52,7 @@ This hook is sent immediately after a container is created.  It notifies the co *PreStop* -This hook is called immediately before a container is terminated. No parameters are passed to the handler. This event handler is blocking, and must complete before the call to delete the container is sent to the Docker daemon. The SIGTERM notification sent by Docker is also still sent. A more complete description of termination behavior can be found in [Termination of Pods](pods.html#termination-of-pods). +This hook is called immediately before a container is terminated. No parameters are passed to the handler. This event handler is blocking, and must complete before the call to delete the container is sent to the Docker daemon. The SIGTERM notification sent by Docker is also still sent. A more complete description of termination behavior can be found in [Termination of Pods](pods/#termination-of-pods). ### Hook Handler Execution diff --git a/v1.1/docs/user-guide/debugging-services.md b/v1.1/docs/user-guide/debugging-services.md index f1f3719aae..b3d7e5a455 100644 --- a/v1.1/docs/user-guide/debugging-services.md +++ b/v1.1/docs/user-guide/debugging-services.md @@ -494,7 +494,7 @@ misbehaving. And yet your `Service` is not working. You should probably let us know, so we can help investigate! Contact us on -[Slack](../troubleshooting.html#slack) or +[Slack](../troubleshooting/#slack) or [email](https://groups.google.com/forum/#!forum/google-containers) or [GitHub](https://github.com/kubernetes/kubernetes). diff --git a/v1.1/docs/user-guide/deploying-applications.md b/v1.1/docs/user-guide/deploying-applications.md index aff4093747..db49b8f9bd 100644 --- a/v1.1/docs/user-guide/deploying-applications.md +++ b/v1.1/docs/user-guide/deploying-applications.md @@ -35,7 +35,7 @@ spec: Some differences compared to specifying just a pod are that the `kind` is `ReplicationController`, the number of `replicas` desired is specified, and the pod specification is under the `template` field. The names of the pods don't need to be specified explicitly because they are generated from the name of the replication controller. View the [replication controller API -object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_replicationcontroller) +object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_replicationcontroller) to view the list of supported fields. This replication controller can be created using `create`, just as with pods: @@ -100,7 +100,7 @@ CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS APP my-nginx nginx nginx app=nginx 2 nginx ``` -More importantly, the pod template's labels are used to create a [`selector`](labels.html#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](kubectl/kubectl_get): +More importantly, the pod template's labels are used to create a [`selector`](labels/#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](kubectl/kubectl_get): ```shell $ kubectl get rc my-nginx -o template --template="{{.spec.selector}}" diff --git a/v1.1/docs/user-guide/deployments.md b/v1.1/docs/user-guide/deployments.md index a7abb95950..e953d89e86 100644 --- a/v1.1/docs/user-guide/deployments.md +++ b/v1.1/docs/user-guide/deployments.md @@ -19,14 +19,14 @@ A typical use case is: ## Enabling Deployments on kubernetes cluster -Deployments is part of the [`extensions` API Group](../api.html#api-groups) and is not enabled by default. +Deployments is part of the [`extensions` API Group](../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.html#api-versioning). +`v1alpha1`](../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. @@ -252,13 +252,13 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a `metadata` fields. For general information about working with config files, see [here](deploying-applications), [here](configuring-containers), and [here](working-with-resources). -A Deployment also needs a [`.spec` section](../devel/api-conventions.html#spec-and-status). +A Deployment also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status). ### Pod Template The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](replication-controller.html#pod-template). It has exactly +The `.spec.template` is a [pod template](replication-controller/#pod-template). It has exactly the same schema as a [pod](pods), except it is nested and does not have an `apiVersion` or `kind`. diff --git a/v1.1/docs/user-guide/docker-cli-to-kubectl.md b/v1.1/docs/user-guide/docker-cli-to-kubectl.md index 29354e6f15..6a8a1ed6fe 100644 --- a/v1.1/docs/user-guide/docker-cli-to-kubectl.md +++ b/v1.1/docs/user-guide/docker-cli-to-kubectl.md @@ -197,7 +197,7 @@ Notice that we don't delete the pod directly. With kubectl we want to delete the #### docker login -There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](images.html#using-a-private-registry). +There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](images/#using-a-private-registry). #### docker version diff --git a/v1.1/docs/user-guide/downward-api/volume/README.md b/v1.1/docs/user-guide/downward-api/volume/README.md index f0bc53f675..d2586b0a99 100644 --- a/v1.1/docs/user-guide/downward-api/volume/README.md +++ b/v1.1/docs/user-guide/downward-api/volume/README.md @@ -2,7 +2,7 @@ title: "Downward API volume plugin" --- Following this example, you will create a pod with a downward API volume. -A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](..//{{page.version}}/docs/devel/api-conventions.html#metadata). +A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](..//{{page.version}}/docs/devel/api-conventions/#metadata). Supported metadata fields: diff --git a/v1.1/docs/user-guide/environment-guide/README.md b/v1.1/docs/user-guide/environment-guide/README.md index e8b86c1f0c..02b386cb6c 100644 --- a/v1.1/docs/user-guide/environment-guide/README.md +++ b/v1.1/docs/user-guide/environment-guide/README.md @@ -64,10 +64,10 @@ Response from backend Backend Container Backend Pod Name: backend-rc-6qiya Backend Namespace: default - ``` + First the frontend pod's information is printed. The pod name and -[namespace](/{{page.version}}/docs/design/namespaces) are retrieved from the +[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces) are retrieved from the [Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of an environment variable set in the [pod definition](show-rc.yaml). Then, the dynamic Kubernetes environment diff --git a/v1.1/docs/user-guide/environment-guide/index.md b/v1.1/docs/user-guide/environment-guide/index.md index 61ebd6b254..37334fa233 100644 --- a/v1.1/docs/user-guide/environment-guide/index.md +++ b/v1.1/docs/user-guide/environment-guide/index.md @@ -69,7 +69,7 @@ Backend Namespace: default ``` First the frontend pod's information is printed. The pod name and -[namespace](/{{page.version}}/docs/design/namespaces) are retrieved from the +[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces.md) are retrieved from the [Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of an environment variable set in the [pod definition](show-rc.yaml). Then, the dynamic Kubernetes environment diff --git a/v1.1/docs/user-guide/getting-into-containers.md b/v1.1/docs/user-guide/getting-into-containers.md index 26b2117a16..04acc7c3b7 100644 --- a/v1.1/docs/user-guide/getting-into-containers.md +++ b/v1.1/docs/user-guide/getting-into-containers.md @@ -5,7 +5,7 @@ Developers can use `kubectl exec` to run commands in a container. This guide dem ## Using kubectl exec to check the environment variables of a container -Kubernetes exposes [services](services.html#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. +Kubernetes exposes [services](services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. We first create a pod and a service, diff --git a/v1.1/docs/user-guide/horizontal-pod-autoscaler.md b/v1.1/docs/user-guide/horizontal-pod-autoscaler.md index c3a2bc0b66..6087c80cc7 100644 --- a/v1.1/docs/user-guide/horizontal-pod-autoscaler.md +++ b/v1.1/docs/user-guide/horizontal-pod-autoscaler.md @@ -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.html#api-versioning) feature in Kubernetes 1.1. +It is a [beta](../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. @@ -28,21 +28,21 @@ Then, it compares the arithmetic mean of the pods' CPU utilization with the targ CPU utilization is the recent CPU usage of a pod divided by the sum of CPU requested by the pod's containers. Please note that if some of the pod's containers do not have CPU request set, CPU utilization for the pod will not be defined and the autoscaler will not take any action. -Further details of the autoscaling algorithm are given [here](../design/horizontal-pod-autoscaler.html#autoscaling-algorithm). +Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm). Autoscaler uses heapster to collect CPU utilization. Therefore, it is required to deploy heapster monitoring in your cluster for autoscaling to work. Autoscaler accesses corresponding replication controller or deployment by scale sub-resource. Scale is an interface which allows to dynamically set the number of replicas and to learn the current state of them. -More details on scale sub-resource can be found [here](../design/horizontal-pod-autoscaler.html#scale-subresource). +More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#scale-subresource). ## API Object -Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](../api.html#api-versioning)). +Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](../api/#api-versioning)). More details about the API object can be found at -[HorizontalPodAutoscaler Object](../design/horizontal-pod-autoscaler.html#horizontalpodautoscaler-object). +[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). ## Support for horizontal pod autoscaler in kubectl @@ -73,9 +73,9 @@ the horizontal pod autoscaler will not be bound to the new replication controlle ## Further reading -* Design documentation: [Horizontal Pod Autoscaling](../design/horizontal-pod-autoscaler). +* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md). * Manual of autoscale command in kubectl: [kubectl autoscale](kubectl/kubectl_autoscale). -* Usage example of [Horizontal Pod Autoscaler](horizontal-pod-autoscaling/README). +* Usage example of [Horizontal Pod Autoscaler](horizontal-pod-autoscaling/). diff --git a/v1.1/docs/user-guide/horizontal-pod-autoscaling/README.md b/v1.1/docs/user-guide/horizontal-pod-autoscaling/README.md index 902e3fdcc9..80f878e501 100644 --- a/v1.1/docs/user-guide/horizontal-pod-autoscaling/README.md +++ b/v1.1/docs/user-guide/horizontal-pod-autoscaling/README.md @@ -1,7 +1,7 @@ --- title: "Horizontal Pod Autoscaler" --- -Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api.html#api-versioning) feature in Kubernetes 1.1. +Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1. It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage. In the future also other metrics will be supported. @@ -93,7 +93,7 @@ controlled by the php-apache replication controller we created in the first step Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas (via the replication controller) so as to maintain an average CPU utilization across all Pods of 50% (since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores). -See [here](/{{page.version}}/docs/design/horizontal-pod-autoscaler.html#autoscaling-algorithm) for more details on the algorithm. +See [here](https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler/#autoscaling-algorithm) for more details on the algorithm. We will create the autoscaler by executing the following command: diff --git a/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md b/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md index 4fa88dec36..f4513975ba 100644 --- a/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md +++ b/v1.1/docs/user-guide/horizontal-pod-autoscaling/index.md @@ -1,7 +1,7 @@ --- title: "Horizontal Pod Autoscaler" --- -Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api.html#api-versioning) feature in Kubernetes 1.1. +Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1. It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage. In the future also other metrics will be supported. @@ -93,7 +93,7 @@ controlled by the php-apache replication controller we created in the first step Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas (via the replication controller) so as to maintain an average CPU utilization across all Pods of 50% (since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores). -See [here](/{{page.version}}/docs/design/horizontal-pod-autoscaler.html#autoscaling-algorithm) for more details on the algorithm. +See [here](https://github.com/kubernetes/kubernetes/tree/master/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm. We will create the autoscaler by executing the following command: diff --git a/v1.1/docs/user-guide/identifiers.md b/v1.1/docs/user-guide/identifiers.md index 12c3d2ab76..9cc174a214 100644 --- a/v1.1/docs/user-guide/identifiers.md +++ b/v1.1/docs/user-guide/identifiers.md @@ -7,11 +7,8 @@ For non-unique user-provided attributes, Kubernetes provides [labels](labels) an ## 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 the 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](../design/identifiers) 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 the 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/tree/master/docs/design/identifiers.md) for the precise syntax rules for names. ## UIDs -UID are generated by Kubernetes. Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique). - - - +UID are generated by Kubernetes. Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique). \ No newline at end of file diff --git a/v1.1/docs/user-guide/index.md b/v1.1/docs/user-guide/index.md index b69fedf9a1..a1a7bda1fb 100644 --- a/v1.1/docs/user-guide/index.md +++ b/v1.1/docs/user-guide/index.md @@ -4,13 +4,13 @@ title: "Kubernetes User Guide: Managing Applications" * TOC {:toc} -The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/README). The [Developer Guide](/{{page.version}}/docs/devel/README) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project. +The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project. Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs). ## Quick walkthrough -1. [Kubernetes 101](walkthrough/README) +1. [Kubernetes 101](walkthrough/) 1. [Kubernetes 201](walkthrough/k8s201) ## Thorough walkthrough @@ -36,10 +36,10 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo [**Overview**](overview) : A brief overview of Kubernetes concepts. -[**Cluster**](../admin/README) +[**Cluster**](/{{page.version}}/docs/admin/) : A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications. -[**Node**](../admin/node) +[**Node**](/{{page.version}}/docs/admin/node) : A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled. [**Pod**](pods) @@ -48,7 +48,7 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo [**Label**](labels) : A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources. -[**Selector**](labels.html#label-selectors) +[**Selector**](labels/#label-selectors) : A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service. [**Replication Controller**](replication-controller) diff --git a/v1.1/docs/user-guide/ingress.md b/v1.1/docs/user-guide/ingress.md index 0eef149d20..e326345fcf 100644 --- a/v1.1/docs/user-guide/ingress.md +++ b/v1.1/docs/user-guide/ingress.md @@ -69,7 +69,7 @@ rules: __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](simple-yaml), [here](configuring-containers), and [here](working-with-resources). -__Lines 5-7__: Ingress [spec](../devel/api-conventions.html#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](/{{page.version}}/docs/devel/api-conventions/#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 (eg: foo.bar.com, defaults to * in this example), a list of paths (eg: /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. diff --git a/v1.1/docs/user-guide/jobs.md b/v1.1/docs/user-guide/jobs.md index 1c46455c3a..612f242070 100644 --- a/v1.1/docs/user-guide/jobs.md +++ b/v1.1/docs/user-guide/jobs.md @@ -96,13 +96,13 @@ As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `meta general information about working with config files, see [here](simple-yaml), [here](configuring-containers), and [here](working-with-resources). -A Job also needs a [`.spec` section](../devel/api-conventions.html#spec-and-status). +A Job also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status). ### Pod Template The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](replication-controller.html#pod-template). It has exactly +The `.spec.template` is a [pod template](replication-controller/#pod-template). It has exactly the same schema as a [pod](pods), except it is nested and does not have an `apiVersion` or `kind`. @@ -135,7 +135,7 @@ think that those pods were created by it. Kubernetes will not stop you from doi By default, a Job is complete when one Pod runs to successful completion. You can also specify that this needs to happen multiple times by specifying `.spec.completions` with a value greater than 1. When multiple completions are requested, each Pod created by the Job controller has an identical -[`spec`](../devel/api-conventions.html#spec-and-status). In particular, all pods will have +[`spec`](/{{page.version}}/docs/devel/api-conventions/#spec-and-status). In particular, all pods will have the same command line and the same image, the same volumes, and mostly the same environment variables. It is up to the user to arrange for the pods to do work on different things. For example, the pods might all access a shared work queue service to acquire work units. @@ -198,9 +198,9 @@ value is `Always`.) ## Caveats -Job objects are in the [`extensions` API Group](../api.html#api-groups). +Job objects are in the [`extensions` API Group](../api/#api-groups). -Job objects have [API version `v1beta1`](../api.html#api-versioning). Beta objects may +Job objects have [API version `v1beta1`](../api/#api-versioning). Beta objects may undergo changes to their schema and/or semantics in future software releases, but similar functionality will be supported. diff --git a/v1.1/docs/user-guide/liveness/README.md b/v1.1/docs/user-guide/liveness/README.md index 9f8f737958..d0d47e8ab4 100644 --- a/v1.1/docs/user-guide/liveness/README.md +++ b/v1.1/docs/user-guide/liveness/README.md @@ -2,7 +2,7 @@ title: "Checking Pod Health" --- -This example shows two types of pod [health checks](../production-pods.html#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks. +This example shows two types of pod [health checks](../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. @@ -37,7 +37,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.html#health-checking) has more information on health checks. +This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks. ## Get your hands dirty diff --git a/v1.1/docs/user-guide/liveness/index.md b/v1.1/docs/user-guide/liveness/index.md index e2d94ad1f0..53869a4857 100644 --- a/v1.1/docs/user-guide/liveness/index.md +++ b/v1.1/docs/user-guide/liveness/index.md @@ -1,7 +1,7 @@ --- title: "Overview" --- -This example shows two types of pod [health checks](../production-pods.html#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks. +This example shows two types of pod [health checks](../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.html#health-checking) has more information on health checks. +This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks. ## Get your hands dirty diff --git a/v1.1/docs/user-guide/logging.md b/v1.1/docs/user-guide/logging.md index e386144271..1eb7727493 100644 --- a/v1.1/docs/user-guide/logging.md +++ b/v1.1/docs/user-guide/logging.md @@ -5,7 +5,7 @@ This page is designed to help you use logs to troubleshoot issues with your Kube ## Logging by Kubernetes Components -Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library. Developer conventions for logging severity are described in [docs/devel/logging.md](../devel/logging). +Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library. Developer conventions for logging severity are described in [docs/devel/logging.md](/{{page.version}}/docs/devel/logging). ## Examining the logs of running containers @@ -74,13 +74,13 @@ $ kubectl logs kube-dns-v3-7r1l9 etcd ## Cluster level logging to Google Cloud Logging -The getting started guide [Cluster Level Logging to Google Cloud Logging](../getting-started-guides/logging) +The getting started guide [Cluster Level Logging to Google Cloud Logging](/{{page.version}}/docs/getting-started-guides/logging) explains how container logs are ingested into [Google Cloud Logging](https://cloud.google.com/logging/docs/) and shows how to query the ingested logs. ## Cluster level logging with Elasticsearch and Kibana -The getting started guide [Cluster Level Logging with Elasticsearch and Kibana](../getting-started-guides/logging-elasticsearch) +The getting started guide [Cluster Level Logging with Elasticsearch and Kibana](/{{page.version}}/docs/getting-started-guides/logging-elasticsearch) describes how to ingest cluster level logs into Elasticsearch and view them using Kibana. ## Ingesting Application Log Files diff --git a/v1.1/docs/user-guide/managing-deployments.md b/v1.1/docs/user-guide/managing-deployments.md index 45aef1e0ac..289c0055b7 100644 --- a/v1.1/docs/user-guide/managing-deployments.md +++ b/v1.1/docs/user-guide/managing-deployments.md @@ -1,7 +1,7 @@ --- title: "Kubernetes User Guide: Managing Applications: Managing deployments" --- -You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](configuring-containers.html#configuration-in-kubernetes) and [labels](deploying-applications.html#labels). +You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](configuring-containers/#configuration-in-kubernetes) and [labels](deploying-applications/#labels). * TOC {:toc} @@ -233,7 +233,7 @@ my-nginx-o0ef1 1/1 Running 0 1h At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios. -To update a service without an outage, `kubectl` supports what is called ['rolling update'?](kubectl/kubectl_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](../design/simple-rolling-update) and the [example of rolling update](update-demo/) for more information. +To update a service without an outage, `kubectl` supports what is called ['rolling update'?](kubectl/kubectl_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/kubernetes/tree/master/docs/design/simple-rolling-update.md) and the [example of rolling update](update-demo/) for more information. Let's say you were running version 1.7.9 of nginx: @@ -256,7 +256,7 @@ spec: - containerPort: 80 ``` -To update to version 1.9.1, you can use [`kubectl rolling-update --image`](/{{page.version}}/docs/design/simple-rolling-update): +To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update.md): ```shell $ kubectl rolling-update my-nginx --image=nginx:1.9.1 diff --git a/v1.1/docs/user-guide/namespaces.md b/v1.1/docs/user-guide/namespaces.md index bb9c13f4ed..baa750ed6e 100644 --- a/v1.1/docs/user-guide/namespaces.md +++ b/v1.1/docs/user-guide/namespaces.md @@ -73,7 +73,7 @@ $ kubectl config set-context $(CONTEXT) --namespace= ## Namespaces and DNS -When you create a [Service](services), it creates a corresponding [DNS entry](../admin/dns). +When you create a [Service](services), it creates a corresponding [DNS entry](/{{page.version}}/docs/admin/dns). This entry is of the form `..svc.cluster.local`, which means that if a container just uses `` it will resolve to the service which is local to a namespace. This is useful for using the same configuration across diff --git a/v1.1/docs/user-guide/node-selection/README.md b/v1.1/docs/user-guide/node-selection/README.md index 6703bb23ba..2aa4b5a80e 100644 --- a/v1.1/docs/user-guide/node-selection/README.md +++ b/v1.1/docs/user-guide/node-selection/README.md @@ -1,7 +1,7 @@ --- title: "Node selection example" --- -This example shows how to assign a [pod](../pods) to a specific [node](../../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](../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 @@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes (0xc20b222db0)true' Pod is a top-level resource in the kubernetes REST API. More details about the API object can be found at: [Pod API -object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_pod). +object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_pod). diff --git a/v1.1/docs/user-guide/production-pods.md b/v1.1/docs/user-guide/production-pods.md index 4ab7475110..f3ad97571a 100644 --- a/v1.1/docs/user-guide/production-pods.md +++ b/v1.1/docs/user-guide/production-pods.md @@ -104,11 +104,11 @@ spec: name: supersecret ``` -For more details, see the [secrets document](secrets), [example](secrets/) and [design doc](/{{page.version}}/docs/design/secrets). +For more details, see the [secrets document](secrets), [example](secrets/) and [design doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md). ## Authenticating with a private image registry -Secrets can also be used to pass [image registry credentials](images.html#using-a-private-registry). +Secrets can also be used to pass [image registry credentials](images/#using-a-private-registry). First, create a `.dockercfg` file, such as running `docker login `. Then put the resulting `.dockercfg` file into a [secret resource](secrets). For example: @@ -202,7 +202,7 @@ More examples can be found in our [blog article](http://blog.kubernetes.io/2015/ Kubernetes's scheduler will place applications only where they have adequate CPU and memory, but it can only do so if it knows how much [resources they require](compute-resources). The consequence of specifying too little CPU is that the containers could be starved of CPU if too many other containers were scheduled onto the same node. Similarly, containers could die unpredictably due to running out of memory if no memory were requested, which can be especially likely for large-memory applications. -If no resource requirements are specified, a nominal amount of resources is assumed. (This default is applied via a [LimitRange](../admin/limitrange/) for the default [Namespace](namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows: +If no resource requirements are specified, a nominal amount of resources is assumed. (This default is applied via a [LimitRange](/{{page.version}}/docs/admin/limitrange/) for the default [Namespace](namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows: ```yaml apiVersion: v1 @@ -240,7 +240,7 @@ If you're not sure how much resources to request, you can first launch the appli ## Liveness and readiness probes (aka health checks) -Many applications running for long periods of time eventually transition to broken states, and cannot recover except by restarting them. Kubernetes provides [*liveness probes*](pod-states.html#container-probes) to detect and remedy such situations. +Many applications running for long periods of time eventually transition to broken states, and cannot recover except by restarting them. Kubernetes provides [*liveness probes*](pod-states/#container-probes) to detect and remedy such situations. A common way to probe an application is using HTTP, which can be specified as follows: @@ -272,14 +272,14 @@ spec: Other times, applications are only temporarily unable to serve, and will recover on their own. Typically in such cases you'd prefer not to kill the application, but don't want to send it requests, either, since the application won't respond correctly or at all. A common such scenario is loading large data or configuration files during application startup. Kubernetes provides *readiness probes* to detect and mitigate such situations. Readiness probes are configured similarly to liveness probes, just using the `readinessProbe` field. A pod with containers reporting that they are not ready will not receive traffic through Kubernetes [services](connecting-applications). -For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](walkthrough/k8s201.html#health-checking), the [standalone example](liveness/), and the [documentation](pod-states.html#container-probes). +For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](walkthrough/k8s201/#health-checking), the [standalone example](liveness/), and the [documentation](pod-states/#container-probes). ## Lifecycle hooks and termination notice Of course, nodes and applications may fail at any time, but many applications benefit from clean shutdown, such as to complete in-flight requests, when the termination of the application is deliberate. To support such cases, Kubernetes supports two kinds of notifications: * Kubernetes will send SIGTERM to applications, which can be handled in order to effect graceful termination. SIGKILL is sent a configurable number of seconds later if the application does not terminate sooner (defaults to 30 seconds, controlled by `spec.terminationGracePeriodSeconds`). -* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](container-environment.html#container-hooks), which will execute prior to sending SIGTERM. +* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](container-environment/#container-hooks), which will execute prior to sending SIGTERM. The specification of a pre-stop hook is similar to that of probes, but without the timing-related parameters. For example: diff --git a/v1.1/docs/user-guide/replication-controller.md b/v1.1/docs/user-guide/replication-controller.md index ea1434a83b..d99f05e669 100644 --- a/v1.1/docs/user-guide/replication-controller.md +++ b/v1.1/docs/user-guide/replication-controller.md @@ -24,7 +24,7 @@ Pods created by a replication controller are intended to be fungible and semanti ### Labels -The population of pods that a replication controller is monitoring is defined with a [label selector](labels.html#label-selectors), which creates a loosely coupled relationship between the controller and the pods controlled, in contrast to pods, which are more tightly coupled to their definition. We deliberately chose not to represent the set of pods controlled using a fixed-length array of pod specifications, because our experience is that approach increases complexity of management operations, for both clients and the system. +The population of pods that a replication controller is monitoring is defined with a [label selector](labels/#label-selectors), which creates a loosely coupled relationship between the controller and the pods controlled, in contrast to pods, which are more tightly coupled to their definition. We deliberately chose not to represent the set of pods controlled using a fixed-length array of pod specifications, because our experience is that approach increases complexity of management operations, for both clients and the system. The replication controller should verify that the pods created from the specified template have labels that match its label selector. Though it isn't verified yet, you should also ensure that only one replication controller controls any given pod, by ensuring that the label selectors of replication controllers do not target overlapping sets. If you do end up with multiple controllers that have overlapping selectors, you will have to manage the deletion yourself with --cascade=false until there are no controllers with an overlapping superset of selectors. @@ -75,4 +75,4 @@ For instance, a service might target all pods with `tier in (frontend), environm Replication controller is a top-level resource in the kubernetes REST API. More details about the API object can be found at: [ReplicationController API -object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_replicationcontroller). \ No newline at end of file +object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_replicationcontroller). \ No newline at end of file diff --git a/v1.1/docs/user-guide/resourcequota/README.md b/v1.1/docs/user-guide/resourcequota/README.md index fac01bf5d5..dc92d2fd6f 100644 --- a/v1.1/docs/user-guide/resourcequota/README.md +++ b/v1.1/docs/user-guide/resourcequota/README.md @@ -1,6 +1,6 @@ --- title: "Resource Quota" --- -This page has been moved to [here](../../admin/resourcequota/README) +This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/) diff --git a/v1.1/docs/user-guide/resourcequota/index.md b/v1.1/docs/user-guide/resourcequota/index.md index fac01bf5d5..dc92d2fd6f 100644 --- a/v1.1/docs/user-guide/resourcequota/index.md +++ b/v1.1/docs/user-guide/resourcequota/index.md @@ -1,6 +1,6 @@ --- title: "Resource Quota" --- -This page has been moved to [here](../../admin/resourcequota/README) +This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/) diff --git a/v1.1/docs/user-guide/secrets.md b/v1.1/docs/user-guide/secrets.md index 4cfa8f38dc..2f49a473d9 100644 --- a/v1.1/docs/user-guide/secrets.md +++ b/v1.1/docs/user-guide/secrets.md @@ -4,7 +4,7 @@ title: "Secrets" 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](../design/secrets) for more information. +a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md) for more information. * TOC {:toc} @@ -51,7 +51,7 @@ data: ``` The data field is a map. Its keys must match -[`DNS_SUBDOMAIN`](../design/identifiers), except that leading dots are also +[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md), except that leading dots are also allowed. The values are arbitrary data, encoded using base64. The values of username and password in the example above, before base64 encoding, are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end. @@ -105,7 +105,7 @@ See another example of creating a secret and a pod that consumes that secret in ### Manually specifying an imagePullSecret -Use of imagePullSecrets is described in the [images documentation](images.html#specifying-imagepullsecrets-on-a-pod) +Use of imagePullSecrets is described in the [images documentation](images/#specifying-imagepullsecrets-on-a-pod) ### Arranging for imagePullSecrets to be Automatically Attached @@ -113,7 +113,7 @@ You can manually create an imagePullSecret, and reference it from a serviceAccount. Any pods created with that serviceAccount or that default to use that serviceAccount, will get have the imagePullSecret of the field set to that of the service account. -See [here](service-accounts.html#adding-imagepullsecrets-to-a-service-account) +See [here](service-accounts/#adding-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. @@ -189,7 +189,7 @@ the original pod must be deleted, and a new pod (perhaps with an identical workflow as deploying a new container image. The `kubectl rolling-update` command can be used ([man page](kubectl/kubectl_rolling-update)). -The [`resourceVersion`](../devel/api-conventions.html#concurrency-control-and-consistency) +The [`resourceVersion`](/{{page.version}}/docs/devel/api-conventions/#concurrency-control-and-consistency) of the secret is not specified when it is referenced. Therefore, if a secret is updated at about the same time as pods are starting, then it is not defined which version of the secret will be used for the pod. It diff --git a/v1.1/docs/user-guide/secrets/README.md b/v1.1/docs/user-guide/secrets/README.md index 9230cdd6bf..6e26b55b22 100644 --- a/v1.1/docs/user-guide/secrets/README.md +++ b/v1.1/docs/user-guide/secrets/README.md @@ -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](../../design/secrets) for more information. +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/tree/master/docs/design/secrets) for more information. ## Step Zero: Prerequisites diff --git a/v1.1/docs/user-guide/secrets/index.md b/v1.1/docs/user-guide/secrets/index.md index 42c72c7f50..ebf3d45726 100644 --- a/v1.1/docs/user-guide/secrets/index.md +++ b/v1.1/docs/user-guide/secrets/index.md @@ -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](../../design/secrets) for more information. +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/tree/master/docs/design/secrets.md) for more information. ## Step Zero: Prerequisites diff --git a/v1.1/docs/user-guide/security-context.md b/v1.1/docs/user-guide/security-context.md index 69c21dfd55..076c8cd7f5 100644 --- a/v1.1/docs/user-guide/security-context.md +++ b/v1.1/docs/user-guide/security-context.md @@ -1,4 +1,4 @@ --- title: "Security Contexts" --- -A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](../design/security_context) for more details. \ No newline at end of file +A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/tree/master/docs/design/security_context.md) for more details. \ No newline at end of file diff --git a/v1.1/docs/user-guide/service-accounts.md b/v1.1/docs/user-guide/service-accounts.md index 04b232fc6f..0ac820960c 100644 --- a/v1.1/docs/user-guide/service-accounts.md +++ b/v1.1/docs/user-guide/service-accounts.md @@ -4,7 +4,7 @@ title: "Service Accounts" A service account provides an identity for processes that run in a Pod. *This is a user introduction to Service Accounts. See also the -[Cluster Admin Guide to Service Accounts](../admin/service-accounts-admin).* +[Cluster Admin Guide to Service Accounts](/{{page.version}}/docs/admin/service-accounts-admin).* *Note: This document describes how service accounts behave in a cluster set up as recommended by the Kubernetes project. Your cluster administrator may have @@ -24,10 +24,10 @@ When you create a pod, you do not need to specify a service account. It is automatically assigned the `default` service account of the same namespace. If you get the raw json or yaml for a pod you have created (e.g. `kubectl get pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been -[automatically set](working-with-resources.html#resources-are-automatically-modified). +[automatically set](working-with-resources/#resources-are-automatically-modified). You can access the API using a proxy or with a client library, as described in -[Accessing the Cluster](accessing-the-cluster.html#accessing-the-api-from-a-pod). +[Accessing the Cluster](accessing-the-cluster/#accessing-the-api-from-a-pod). ## Using Multiple Service Accounts. @@ -130,7 +130,7 @@ token: ## Adding ImagePullSecrets to a service account -First, create an imagePullSecret, as described [here](images.html#specifying-imagepullsecrets-on-a-pod) +First, create an imagePullSecret, as described [here](images/#specifying-imagepullsecrets-on-a-pod) Next, verify it has been created. For example: ```shell diff --git a/v1.1/docs/user-guide/services.md b/v1.1/docs/user-guide/services.md index d49f30ad5b..cd626a2740 100644 --- a/v1.1/docs/user-guide/services.md +++ b/v1.1/docs/user-guide/services.md @@ -16,7 +16,7 @@ Enter `Services`. A Kubernetes `Service` is an abstraction which defines a logical set of `Pods` and a policy by which to access them - sometimes called a micro-service. The set of `Pods` targeted by a `Service` is (usually) determined by a [`Label -Selector`](labels.html#label-selectors) (see below for why you might want a +Selector`](labels/#label-selectors) (see below for why you might want a `Service` without a selector). As an example, consider an image-processing backend which is running with 3 diff --git a/v1.1/docs/user-guide/simple-nginx.md b/v1.1/docs/user-guide/simple-nginx.md index d6fab5fdf6..f00e54c77f 100644 --- a/v1.1/docs/user-guide/simple-nginx.md +++ b/v1.1/docs/user-guide/simple-nginx.md @@ -35,7 +35,7 @@ kubectl stop rc my-nginx ### Exposing your pods to the internet. -On some platforms (for example Google Compute Engine) the kubectl command can integrate with your cloud provider to add a [public IP address](services.html#external-services) for the pods, +On some platforms (for example Google Compute Engine) the kubectl command can integrate with your cloud provider to add a [public IP address](services/#external-services) for the pods, to do this run: ```shell diff --git a/v1.1/docs/user-guide/update-demo/README.md b/v1.1/docs/user-guide/update-demo/README.md index 0910b82128..a1af4653dd 100644 --- a/v1.1/docs/user-guide/update-demo/README.md +++ b/v1.1/docs/user-guide/update-demo/README.md @@ -21,7 +21,7 @@ limitations under the License. # Rolling update example -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.html#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](../../design/simple-rolling-update) for more information. +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/tree/master/docs/design/simple-rolling-update) for more information. ### Step Zero: Prerequisites diff --git a/v1.1/docs/user-guide/update-demo/index.md b/v1.1/docs/user-guide/update-demo/index.md index 83b569d5f7..7a4f10b686 100644 --- a/v1.1/docs/user-guide/update-demo/index.md +++ b/v1.1/docs/user-guide/update-demo/index.md @@ -21,7 +21,7 @@ limitations under the License. # Rolling update example -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.html#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](../../design/simple-rolling-update) for more information. +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/tree/master/docs/design/simple-rolling-update.md) for more information. ### Step Zero: Prerequisites diff --git a/v1.1/docs/user-guide/volumes.md b/v1.1/docs/user-guide/volumes.md index 29458f97bb..fbbe86b463 100644 --- a/v1.1/docs/user-guide/volumes.md +++ b/v1.1/docs/user-guide/volumes.md @@ -362,7 +362,7 @@ details. A `downwardAPI` volume is used to make downward API data available to applications. It mounts a directory and writes the requested data in plain text files. -See the [`downwardAPI` volume example](downward-api/volume/README) for more details. +See the [`downwardAPI` volume example](downward-api/volume/) for more details. ## Resources diff --git a/v1.1/docs/user-guide/walkthrough/README.md b/v1.1/docs/user-guide/walkthrough/README.md index b403d5466a..e81cc3f581 100644 --- a/v1.1/docs/user-guide/walkthrough/README.md +++ b/v1.1/docs/user-guide/walkthrough/README.md @@ -44,7 +44,7 @@ spec: ``` 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](../../design/README) for more details. +See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/) for more details. #### Pod Management @@ -171,4 +171,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/README) \ No newline at end of file +for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/) \ No newline at end of file diff --git a/v1.1/docs/user-guide/walkthrough/index.md b/v1.1/docs/user-guide/walkthrough/index.md index d0e497d412..2ba3f334fe 100644 --- a/v1.1/docs/user-guide/walkthrough/index.md +++ b/v1.1/docs/user-guide/walkthrough/index.md @@ -43,7 +43,7 @@ spec: 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](../../design/README) for more details. +See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/README.md) for more details. #### Pod Management diff --git a/v1.1/docs/user-guide/walkthrough/k8s201.md b/v1.1/docs/user-guide/walkthrough/k8s201.md index 79964fe5c8..eb1ba63033 100644 --- a/v1.1/docs/user-guide/walkthrough/k8s201.md +++ b/v1.1/docs/user-guide/walkthrough/k8s201.md @@ -269,7 +269,7 @@ spec: [Download example](pod-with-http-healthcheck.yaml) -For more information about health checking, see [Container Probes](../pod-states.html#container-probes). +For more information about health checking, see [Container Probes](../pod-states/#container-probes). ## What's Next? diff --git a/v1.1/docs/user-guide/working-with-resources.md b/v1.1/docs/user-guide/working-with-resources.md index 6c4e86003b..477caf1758 100644 --- a/v1.1/docs/user-guide/working-with-resources.md +++ b/v1.1/docs/user-guide/working-with-resources.md @@ -5,7 +5,7 @@ title: "Working with Resources" 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](../devel/api-conventions) and +refer to the [api conventions](/{{page.version}}/docs/devel/api-conventions) and the [api document](../api).* ## Resources are Automatically Modified @@ -41,9 +41,9 @@ If you `diff -u /tmp/original.yaml /tmp/current.yaml`, you can see the fields ad The system adds fields in several ways: - Some fields are added synchronously with creation of the resource and some are set asynchronously. - - For example: `metadata.uid` is set synchronously. (Read more about [metadata](../devel/api-conventions.html#metadata)). - - For example, `status.hostIP` is set only after the pod has been scheduled. This often happens fast, but you may notice pods which do not have this set yet. This is called Late Initialization. (Read mode about [status](../devel/api-conventions.html#spec-and-status) and [late initialization](../devel/api-conventions.html#late-initialization) ). - - Some fields are set to default values. Some defaults vary by cluster and some are fixed for the API at a certain version. (Read more about [defaulting](../devel/api-conventions.html#defaulting)). + - For example: `metadata.uid` is set synchronously. (Read more about [metadata](/{{page.version}}/docs/devel/api-conventions/#metadata)). + - For example, `status.hostIP` is set only after the pod has been scheduled. This often happens fast, but you may notice pods which do not have this set yet. This is called Late Initialization. (Read mode about [status](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) and [late initialization](/{{page.version}}/docs/devel/api-conventions/#late-initialization) ). + - Some fields are set to default values. Some defaults vary by cluster and some are fixed for the API at a certain version. (Read more about [defaulting](/{{page.version}}/docs/devel/api-conventions/#defaulting)). - For example, `spec.containers[0].imagePullPolicy` always defaults to `IfNotPresent` in api v1. - For example, `spec.containers[0].resources.limits.cpu` may be defaulted to `100m` on some clusters, to some other value on others, and not defaulted at all on others. diff --git a/v1.1/docs/whatisk8s.md b/v1.1/docs/whatisk8s.md index cff1f53e42..ec50e5b17d 100644 --- a/v1.1/docs/whatisk8s.md +++ b/v1.1/docs/whatisk8s.md @@ -57,27 +57,27 @@ It can also do much more than that. Kubernetes satisfies a number of common needs of applications running in production, such as: -* [co-locating helper processes](user-guide/pods), -* [mounting storage systems](user-guide/volumes), -* [distributing secrets](user-guide/secrets), -* [application health checking](user-guide/production-pods.html#liveness-and-readiness-probes-aka-health-checks), -* [replicating application instances](user-guide/replication-controller), -* [horizontal auto-scaling](user-guide/horizontal-pod-autoscaler), -* [load balancing](user-guide/services), -* [rolling updates](user-guide/update-demo/), and -* [resource monitoring](user-guide/monitoring). +* [co-locating helper processes](/{{page.version}}/docs/user-guide/pods), +* [mounting storage systems](/{{page.version}}/docs/user-guide/volumes), +* [distributing secrets](/{{page.version}}/docs/user-guide/secrets), +* [application health checking](/{{page.version}}/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks), +* [replicating application instances](/{{page.version}}/docs/user-guide/replication-controller), +* [horizontal auto-scaling](/{{page.version}}/docs/user-guide/horizontal-pod-autoscaler), +* [load balancing](/{{page.version}}/docs/user-guide/services), +* [rolling updates](/{{page.version}}/docs/user-guide/update-demo/), and +* [resource monitoring](/{{page.version}}/docs/user-guide/monitoring). -For more details, see the [user guide](user-guide/). +For more details, see the [user guide](/{{page.version}}/docs/user-guide/). #### Why and how is Kubernetes a platform? Even though Kubernetes provides a lot of functionality, there are always new scenarios that would benefit from new features. Ad hoc orchestration that is acceptable initially often requires robust automation at scale. Application-specific workflows can be streamlined to accelerate developer velocity. This is why Kubernetes was also designed to serve as a platform for building an ecosystem of components and tools to make it easier to deploy, scale, and manage applications. -[Labels](user-guide/labels) empower users to organize their resources however they please. [Annotations](user-guide/annotations) enable users to decorate resources with custom information to facilitate their workflows and provide an easy way for management tools to checkpoint state. +[Labels](/{{page.version}}/docs/user-guide/labels) empower users to organize their resources however they please. [Annotations](/{{page.version}}/docs/user-guide/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](admin/cluster-components) is built upon the same [APIs](api) that are available to developers and users. Users can write their own controllers, [schedulers](devel/scheduler), etc., if they choose, with [their own APIs](design/extending-api) that can be targeted by a general-purpose [command-line tool](user-guide/kubectl-overview). +Additionally, the [Kubernetes control plane](/{{page.version}}/docs/admin/cluster-components) is built upon the same [APIs](api) that are available to developers and users. Users can write their own controllers, [schedulers](/{{page.version}}/docs/devel/scheduler), etc., if they choose, with [their own APIs](https://github.com/kubernetes/kubernetes/tree/master/docs/design/extending-api.md) that can be targeted by a general-purpose [command-line tool](/{{page.version}}/docs/user-guide/kubectl-overview). -This [design](design/principles) has enabled a number of other systems to build atop Kubernetes. +This [design](https://github.com/kubernetes/kubernetes/tree/master/docs/design/principles.md) has enabled a number of other systems to build atop Kubernetes. #### Kubernetes is not: diff --git a/v1.1/gs-custom.md b/v1.1/gs-custom.md index 3db929785c..1a38afbee4 100644 --- a/v1.1/gs-custom.md +++ b/v1.1/gs-custom.md @@ -4,7 +4,7 @@ title: "Getting Started: Custom Solutions" Use these solutions to create Kubernetes clusters in your custom environment. -First time here? See [Picking the Right Solution](/{{page.version}}/docs/getting-started-guides/README) for more information. +First time here? See [Picking the Right Solution](/{{page.version}}/docs/getting-started-guides/) for more information. ## From scratch