Link replacements for a,b,c
This commit is contained in:
John Mulhausen
@@ -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/#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](/{{page.version}}/docs/user-guide/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
|
||||
|
||||
@@ -9,7 +9,7 @@ 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 <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` 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/#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](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy) or [kubectl port-forward](/{{page.version}}/docs/user-guide/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.
|
||||
|
||||
@@ -6,13 +6,13 @@ title: "Kubernetes User Guide: Managing Applications: Configuring and launching
|
||||
|
||||
## Configuration in Kubernetes
|
||||
|
||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](quick-start), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](/{{page.version}}/docs/user-guide/quick-start), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||
|
||||
In the declarative style, all configuration is stored in YAML or JSON configuration files using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently 'v1'?), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation.
|
||||
|
||||
## Launching a container using a configuration file
|
||||
|
||||
Kubernetes executes containers in [*Pods*](pods). A pod containing a simple Hello World container can be specified in YAML as follows:
|
||||
Kubernetes executes containers in [*Pods*](/{{page.version}}/docs/user-guide/pods). A pod containing a simple Hello World container can be specified in YAML as follows:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -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/#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`](/{{page.version}}/docs/user-guide/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"]
|
||||
@@ -161,4 +161,4 @@ On the other hand, containers and their logs are eventually deleted automaticall
|
||||
|
||||
## What's next?
|
||||
|
||||
[Learn about deploying continuously running applications.](deploying-applications)
|
||||
[Learn about deploying continuously running applications.](/{{page.version}}/docs/user-guide/deploying-applications)
|
||||
|
||||
@@ -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/#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](/{{page.version}}/docs/user-guide/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
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Connecting to applications: kubectl proxy and apiserver proxy"
|
||||
---
|
||||
You have seen the [basics](accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui)) running on the Kubernetes cluster from your workstation.
|
||||
You have seen the [basics](/{{page.version}}/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui)) running on the Kubernetes cluster from your workstation.
|
||||
|
||||
|
||||
## Getting the apiserver proxy URL of kube-ui
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Kubernetes User Guide: Managing Applications: Deploying continuously running applications"
|
||||
---
|
||||
You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.
|
||||
You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](/{{page.version}}/docs/user-guide/configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -111,4 +111,4 @@ You could also specify the `selector` explicitly, such as if you wanted to speci
|
||||
|
||||
## What's next?
|
||||
|
||||
[Learn about exposing applications to users and clients, and connecting tiers of your application together.](connecting-applications)
|
||||
[Learn about exposing applications to users and clients, and connecting tiers of your application together.](/{{page.version}}/docs/user-guide/connecting-applications)
|
||||
@@ -250,7 +250,7 @@ before changing course.
|
||||
|
||||
As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and
|
||||
`metadata` fields. For general information about working with config files,
|
||||
see [here](deploying-applications), [here](configuring-containers), and [here](working-with-resources).
|
||||
see [here](deploying-applications), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
A Deployment also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).
|
||||
|
||||
|
||||
@@ -86,7 +86,7 @@ Using a similar syntax it's possible to expose pod information to containers usi
|
||||
Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI`
|
||||
volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed.
|
||||
|
||||
Downward API volume permits to store more complex data like [`metadata.labels`](labels) and [`metadata.annotations`](annotations). Currently key/value pair set fields are saved using `key="value"` format:
|
||||
Downward API volume permits to store more complex data like [`metadata.labels`](labels) and [`metadata.annotations`](/{{page.version}}/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format:
|
||||
|
||||
```conf
|
||||
key1="value1"
|
||||
|
||||
@@ -23,7 +23,7 @@ for your platform.
|
||||
## Optional: Build your own containers
|
||||
|
||||
The code for the containers is under
|
||||
[containers/](containers/)
|
||||
[containers/](/{{page.version}}/docs/user-guide/environment-guide/containers/)
|
||||
|
||||
## Get everything running
|
||||
|
||||
@@ -72,7 +72,7 @@ First the frontend pod's information is printed. The pod name and
|
||||
[namespace](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/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
|
||||
definition](/{{page.version}}/docs/user-guide/environment-guide/show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
service, named `backend-srv`. Finally, the frontend pod queries the
|
||||
backend service and prints the information returned. Again the backend
|
||||
|
||||
@@ -3,7 +3,7 @@ title: "Identifiers"
|
||||
---
|
||||
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
|
||||
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](labels) and [annotations](annotations).
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](labels) and [annotations](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
## Names
|
||||
|
||||
|
||||
@@ -6,34 +6,34 @@ title: "Kubernetes User Guide: Managing Applications"
|
||||
|
||||
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).
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](/{{page.version}}/docs/user-guide/prereqs).
|
||||
|
||||
## Quick walkthrough
|
||||
|
||||
1. [Kubernetes 101](walkthrough/)
|
||||
1. [Kubernetes 201](walkthrough/k8s201)
|
||||
1. [Kubernetes 101](/{{page.version}}/docs/user-guide/walkthrough/)
|
||||
1. [Kubernetes 201](/{{page.version}}/docs/user-guide/walkthrough/k8s201)
|
||||
|
||||
## Thorough walkthrough
|
||||
|
||||
If you don't have much familiarity with Kubernetes, we recommend you read the following sections in order:
|
||||
|
||||
1. [Quick start: launch and expose an application](quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](configuring-containers)
|
||||
1. [Deploying continuously running applications](deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](connecting-applications)
|
||||
1. [Working with containers in production](production-pods)
|
||||
1. [Managing deployments](managing-deployments)
|
||||
1. [Application introspection and debugging](introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](ui)
|
||||
1. [Logging](logging)
|
||||
1. [Monitoring](monitoring)
|
||||
1. [Getting into containers via `exec`](getting-into-containers)
|
||||
1. [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
1. [Quick start: launch and expose an application](/{{page.version}}/docs/user-guide/quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](/{{page.version}}/docs/user-guide/configuring-containers)
|
||||
1. [Deploying continuously running applications](/{{page.version}}/docs/user-guide/deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](/{{page.version}}/docs/user-guide/connecting-applications)
|
||||
1. [Working with containers in production](/{{page.version}}/docs/user-guide/production-pods)
|
||||
1. [Managing deployments](/{{page.version}}/docs/user-guide/managing-deployments)
|
||||
1. [Application introspection and debugging](/{{page.version}}/docs/user-guide/introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](/{{page.version}}/docs/user-guide/ui)
|
||||
1. [Logging](/{{page.version}}/docs/user-guide/logging)
|
||||
1. [Monitoring](/{{page.version}}/docs/user-guide/monitoring)
|
||||
1. [Getting into containers via `exec`](/{{page.version}}/docs/user-guide/getting-into-containers)
|
||||
1. [Connecting to containers via proxies](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward)
|
||||
|
||||
## Concept guide
|
||||
|
||||
[**Overview**](overview)
|
||||
[**Overview**](/{{page.version}}/docs/user-guide/overview)
|
||||
: A brief overview of Kubernetes concepts.
|
||||
|
||||
[**Cluster**](/{{page.version}}/docs/admin/)
|
||||
@@ -42,52 +42,49 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
|
||||
[**Node**](/{{page.version}}/docs/admin/node)
|
||||
: A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
|
||||
|
||||
[**Pod**](pods)
|
||||
[**Pod**](/{{page.version}}/docs/user-guide/pods)
|
||||
: A pod is a co-located group of containers and volumes.
|
||||
|
||||
[**Label**](labels)
|
||||
[**Label**](/{{page.version}}/docs/user-guide/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/#label-selectors)
|
||||
[**Selector**](/{{page.version}}/docs/user-guide/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)
|
||||
[**Replication Controller**](/{{page.version}}/docs/user-guide/replication-controller)
|
||||
: A replication controller ensures that a specified number of pod replicas are running at any one time. It both allows for easy scaling of replicated systems and handles re-creation of a pod when the machine it is on reboots or otherwise fails.
|
||||
|
||||
[**Service**](services)
|
||||
[**Service**](/{{page.version}}/docs/user-guide/services)
|
||||
: A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name.
|
||||
|
||||
[**Volume**](volumes)
|
||||
[**Volume**](/{{page.version}}/docs/user-guide/volumes)
|
||||
: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device.
|
||||
|
||||
[**Secret**](secrets)
|
||||
[**Secret**](/{{page.version}}/docs/user-guide/secrets)
|
||||
: A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request.
|
||||
|
||||
[**Name**](identifiers)
|
||||
[**Name**](/{{page.version}}/docs/user-guide/identifiers)
|
||||
: A user- or client-provided name for a resource.
|
||||
|
||||
[**Namespace**](namespaces)
|
||||
[**Namespace**](/{{page.version}}/docs/user-guide/namespaces)
|
||||
: A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.
|
||||
|
||||
[**Annotation**](annotations)
|
||||
[**Annotation**](/{{page.version}}/docs/user-guide/annotations)
|
||||
: A key/value pair that can hold larger (compared to a label), and possibly not human-readable, data, intended to store non-identifying auxiliary data, especially data manipulated by tools and system extensions. Efficient filtering by annotation values is not supported.
|
||||
|
||||
## Further reading
|
||||
|
||||
* API resources
|
||||
* [Working with resources](working-with-resources)
|
||||
* [Working with resources](/{{page.version}}/docs/user-guide/working-with-resources)
|
||||
|
||||
* Pods and containers
|
||||
* [Pod lifecycle and restart policies](pod-states)
|
||||
* [Lifecycle hooks](container-environment)
|
||||
* [Compute resources, such as cpu and memory](compute-resources)
|
||||
* [Specifying commands and requesting capabilities](containers)
|
||||
* [Downward API: accessing system configuration from a pod](downward-api)
|
||||
* [Images and registries](images)
|
||||
* [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/)
|
||||
|
||||
|
||||
|
||||
* [Pod lifecycle and restart policies](/{{page.version}}/docs/user-guide/pod-states)
|
||||
* [Lifecycle hooks](/{{page.version}}/docs/user-guide/container-environment)
|
||||
* [Compute resources, such as cpu and memory](/{{page.version}}/docs/user-guide/compute-resources)
|
||||
* [Specifying commands and requesting capabilities](/{{page.version}}/docs/user-guide/containers)
|
||||
* [Downward API: accessing system configuration from a pod](/{{page.version}}/docs/user-guide/downward-api)
|
||||
* [Images and registries](/{{page.version}}/docs/user-guide/images)
|
||||
* [Migrating from docker-cli to kubectl](/{{page.version}}/docs/user-guide/docker-cli-to-kubectl)
|
||||
* [Tips and tricks when working with config](/{{page.version}}/docs/user-guide/config-best-practices)
|
||||
* [Assign pods to selected nodes](/{{page.version}}/docs/user-guide/node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](/{{page.version}}/docs/user-guide/update-demo/)
|
||||
@@ -67,7 +67,7 @@ rules:
|
||||
|
||||
*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
|
||||
|
||||
__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 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](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
__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.
|
||||
|
||||
|
||||
@@ -311,6 +311,6 @@ Learn about additional debugging tools, including:
|
||||
* [Logging](logging)
|
||||
* [Monitoring](monitoring)
|
||||
* [Getting into containers via `exec`](getting-into-containers)
|
||||
* [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
* [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
* [Connecting to containers via proxies](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy)
|
||||
* [Connecting to containers via port forwarding](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward)
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ $ kubectl logs pi-aiw0a
|
||||
|
||||
As with all other Kubernetes config, a Job 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).
|
||||
[here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
A Job also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ When performing an operation on multiple resources, you can specify each resourc
|
||||
* To specify multiple resource types individually: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
|
||||
Example: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
|
||||
[Use YAML rather than JSON](config-best-practices) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
[Use YAML rather than JSON](/{{page.version}}/docs/user-guide/config-best-practices) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
Example: `$ kubectl get pod -f ./pod.yaml`
|
||||
* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Each object can have a set of key/value labels defined. Each Key must be unique
|
||||
}
|
||||
```
|
||||
|
||||
We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](annotations).
|
||||
We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
@@ -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/#configuration-in-kubernetes) and [labels](deploying-applications/#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](/{{page.version}}/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](deploying-applications/#labels).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -365,7 +365,7 @@ You can also run the [update demo](update-demo/) to see a visual representation
|
||||
|
||||
## In-place updates of resources
|
||||
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. For instance, you might want to add an [annotation](annotations) with a description of your object. That's easiest to do with `kubectl patch`:
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. For instance, you might want to add an [annotation](/{{page.version}}/docs/user-guide/annotations) with a description of your object. That's easiest to do with `kubectl patch`:
|
||||
|
||||
```shell
|
||||
$ kubectl patch rc my-nginx-v4 -p '{"metadata": {"annotations": {"description": "my frontend running nginx"}}}'
|
||||
@@ -406,4 +406,4 @@ replicationcontrollers/my-nginx-v4
|
||||
## What's next?
|
||||
|
||||
- [Learn about how to use `kubectl` for application introspection and debugging.](introspection-and-debugging)
|
||||
- [Tips and tricks when working with config](config-best-practices
|
||||
- [Tips and tricks when working with config](/{{page.version}}/docs/user-guide/config-best-practices
|
||||
|
||||
@@ -13,7 +13,7 @@ In Kubernetes, all containers run inside [pods](pods). A pod can host a single c
|
||||
|
||||
Users can create and manage pods themselves, but Kubernetes drastically simplifies system management by allowing users to delegate two common pod-related activities: deploying multiple pod replicas based on the same pod configuration, and creating replacement pods when a pod or its machine fails. The Kubernetes API object that manages these behaviors is called a [replication controller](replication-controller). It defines a pod in terms of a template, that the system then instantiates as some number of pods (specified by the user). The replicated set of pods might constitute an entire application, a micro-service, or one layer in a multi-tier application. Once the pods are created, the system continually monitors their health and that of the machines they are running on; if a pod fails due to a software problem or machine failure, the replication controller automatically creates a new pod on a healthy machine, to maintain the set of pods at the desired replication level. Multiple pods from the same or different applications can share the same machine. Note that a replication controller is needed even in the case of a single non-replicated pod if the user wants it to be re-created when it or its machine fails.
|
||||
|
||||
Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](annotations).
|
||||
Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
Kubernetes supports a unique [networking model](/{{page.version}}/docs/admin/networking). Kubernetes encourages a flat address space and does not dynamically allocate ports, instead allowing users to select whichever ports are convenient for them. To achieve this, it allocates an IP address for each pod.
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ An example flow:
|
||||
2. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
|
||||
3. Pod shows up as "Terminating" when listed in client commands
|
||||
4. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the pod shutdown process.
|
||||
1. If the pod has defined a [preStop hook](container-environment/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
|
||||
1. If the pod has defined a [preStop hook](/{{page.version}}/docs/user-guide/container-environment/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
|
||||
2. The processes in the Pod are sent the TERM signal.
|
||||
5. (simultaneous with 3), Pod is removed from endpoints list for service, and are no longer considered part of the set of running pods for replication controllers. Pods that shutdown slowly can continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
|
||||
6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Kubernetes User Guide: Managing Applications: Working with pods and containers in production"
|
||||
---
|
||||
You've seen [how to configure and deploy pods and containers](configuring-containers), using some of the most common configuration parameters. This section dives into additional features that are especially useful for running applications in production.
|
||||
You've seen [how to configure and deploy pods and containers](/{{page.version}}/docs/user-guide/configuring-containers), using some of the most common configuration parameters. This section dives into additional features that are especially useful for running applications in production.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -200,7 +200,7 @@ More examples can be found in our [blog article](http://blog.kubernetes.io/2015/
|
||||
|
||||
## Resource management
|
||||
|
||||
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.
|
||||
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](/{{page.version}}/docs/user-guide/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](/{{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:
|
||||
|
||||
@@ -270,7 +270,7 @@ spec:
|
||||
timeoutSeconds: 1
|
||||
```
|
||||
|
||||
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).
|
||||
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](/{{page.version}}/docs/user-guide/connecting-applications).
|
||||
|
||||
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).
|
||||
|
||||
@@ -279,7 +279,7 @@ For more details (e.g., how to specify command-based probes), see the [example i
|
||||
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/#container-hooks), which will execute prior to sending SIGTERM.
|
||||
* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](/{{page.version}}/docs/user-guide/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:
|
||||
|
||||
|
||||
@@ -63,4 +63,4 @@ services/my-nginx
|
||||
|
||||
## What's next?
|
||||
|
||||
[Learn about how to configure common container parameters, such as commands and environment variables.](configuring-containers)
|
||||
[Learn about how to configure common container parameters, such as commands and environment variables.](/{{page.version}}/docs/user-guide/configuring-containers)
|
||||
@@ -27,7 +27,7 @@ pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been
|
||||
[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/#accessing-the-api-from-a-pod).
|
||||
[Accessing the Cluster](/{{page.version}}/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
|
||||
|
||||
## Using Multiple Service Accounts.
|
||||
|
||||
|
||||
@@ -373,6 +373,6 @@ medium of the filesystem holding the kubelet root dir (typically
|
||||
pods.
|
||||
|
||||
In the future, we expect that `emptyDir` and `hostPath` volumes will be able to
|
||||
request a certain amount of space using a [resource](compute-resources)
|
||||
request a certain amount of space using a [resource](/{{page.version}}/docs/user-guide/compute-resources)
|
||||
specification, and to select the type of media to use, for clusters that have
|
||||
several media types.
|
||||
Reference in New Issue
Block a user