No design/ docs, no linking to README files
This commit is contained in:
John Mulhausen
+16
-16
@@ -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/
|
||||
@@ -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
|
||||
|
||||
@@ -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/
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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).
|
||||
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).
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
+14
-14
@@ -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.
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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)
|
||||
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)
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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).
|
||||
document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/networking.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).
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.*
|
||||
|
||||
@@ -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
|
||||
|
||||
+12
-12
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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/)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 <none> 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)!
|
||||
You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/)!
|
||||
@@ -63,7 +63,7 @@ Guide to running a single master, multi-worker cluster controlled by an OS X men
|
||||
|
||||
<hr/>
|
||||
|
||||
[**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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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/)!
|
||||
|
||||
@@ -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 `<kubernetes>/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 <none> 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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -22,7 +22,7 @@ Here is the same information in a picture which shows how the pods might be plac
|
||||
|
||||
|
||||
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):
|
||||
|
||||
|
||||
@@ -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/)
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -240,7 +240,7 @@ my-nginx 10.0.0.1 <none> 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!
|
||||
|
||||
|
||||
+6
-6
@@ -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).
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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/)
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
@@ -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 <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.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.
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
@@ -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}}"
|
||||
|
||||
@@ -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`.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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,
|
||||
|
||||
|
||||
@@ -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/).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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).
|
||||
@@ -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)
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -73,7 +73,7 @@ $ kubectl config set-context $(CONTEXT) --namespace=<insert-namespace-name-here>
|
||||
|
||||
## 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 `<service-name>.<namespace-name>.svc.cluster.local`, which means
|
||||
that if a container just uses `<service-name>` it will resolve to the service which
|
||||
is local to a namespace. This is useful for using the same configuration across
|
||||
|
||||
@@ -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 <node-n
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](/{{page.version}}/docs/design/identifiers)), meaning that they are not allowed to contain any upper-case letters.
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/identifiers)), meaning that they are not allowed to contain any upper-case letters.
|
||||
|
||||
You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.
|
||||
|
||||
|
||||
@@ -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 <node-n
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](/{{page.version}}/docs/design/identifiers)), meaning that they are not allowed to contain any upper-case letters.
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
|
||||
|
||||
You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.
|
||||
|
||||
|
||||
@@ -15,9 +15,9 @@ Users can create and manage pods themselves, but Kubernetes drastically simplifi
|
||||
|
||||
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).
|
||||
|
||||
Kubernetes supports a unique [networking model](../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.
|
||||
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.
|
||||
|
||||
Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](services) abstraction, which provides a stable IP address and [DNS name](../admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.
|
||||
Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](services) abstraction, which provides a stable IP address and [DNS name](/{{page.version}}/docs/admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.
|
||||
|
||||
Every resource in Kubernetes, such as a pod, is identified by a URI and has a UID. Important components of the URI are the kind of object (e.g. pod), the object's name, and the object's [namespace](namespaces). For a certain object kind, every name is unique within its namespace. In contexts where an object name is provided without a namespace, it is assumed to be in the default namespace. UID is unique across time and space.
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ apiVersion: v1
|
||||
|
||||
### Capacity
|
||||
|
||||
Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](../design/resources) to understand the units expected by `capacity`.
|
||||
Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md) to understand the units expected by `capacity`.
|
||||
|
||||
Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc.
|
||||
|
||||
@@ -146,7 +146,7 @@ Claims use the same conventions as volumes when requesting storage with specific
|
||||
|
||||
### Resources
|
||||
|
||||
Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](../design/resources) applies to both volumes and claims.
|
||||
Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://github.com/kubernetes/kubernetes/tree/master/docs/design/resources.md) applies to both volumes and claims.
|
||||
|
||||
## Claims As Volumes
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ nginx serving content from your persistent volume.
|
||||
|
||||
This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.
|
||||
|
||||
See [Persistent Storage design document](../../design/persistent-storage) for more information.
|
||||
See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage) for more information.
|
||||
|
||||
## Provisioning
|
||||
|
||||
@@ -90,7 +90,7 @@ $ curl 10.0.0.241:3000
|
||||
I love Kubernetes storage!
|
||||
|
||||
```
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting.html#slack) and ask!
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!
|
||||
|
||||
Enjoy!
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ nginx serving content from your persistent volume.
|
||||
|
||||
This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.
|
||||
|
||||
See [Persistent Storage design document](../../design/persistent-storage) for more information.
|
||||
See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage.md) for more information.
|
||||
|
||||
## Provisioning
|
||||
|
||||
@@ -88,6 +88,6 @@ $ curl 10.0.0.241:3000
|
||||
I love Kubernetes storage!
|
||||
```
|
||||
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting.html#slack) and ask!
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!
|
||||
|
||||
Enjoy!
|
||||
@@ -7,7 +7,7 @@ This document covers the lifecycle of a pod. It is not an exhaustive document,
|
||||
|
||||
## Pod Phase
|
||||
|
||||
As consistent with the overall [API convention](../devel/api-conventions.html#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
|
||||
As consistent with the overall [API convention](/{{page.version}}/docs/devel/api-conventions/#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
|
||||
|
||||
The number and meanings of `PodPhase` values are tightly guarded. Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`.
|
||||
|
||||
@@ -46,17 +46,17 @@ More detailed information about the current (and previous) container statuses ca
|
||||
|
||||
## RestartPolicy
|
||||
|
||||
The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](pods.html#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired.
|
||||
The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired.
|
||||
|
||||
Three types of controllers are currently available:
|
||||
|
||||
- Use a [`Job`](jobs) for pods which are expected to terminate (e.g. batch computations).
|
||||
- Use a [`ReplicationController`](replication-controller) for pods which are not expected to
|
||||
terminate, and where (e.g. web servers).
|
||||
- Use a [`DaemonSet`](../admin/daemons): Use for pods which need to run 1 per machine because they provide a
|
||||
- Use a [`DaemonSet`](/{{page.version}}/docs/admin/daemons): Use for pods which need to run 1 per machine because they provide a
|
||||
machine-specific system service.
|
||||
If you are unsure whether to use ReplicationController or Daemon, then see [Daemon Set versus
|
||||
Replication Controller](../admin/daemons.html#daemon-set-versus-replication-controller).
|
||||
Replication Controller](/{{page.version}}/docs/admin/daemons/#daemon-set-versus-replication-controller).
|
||||
|
||||
`ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`.
|
||||
`Job` is *only* appropriate for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
|
||||
|
||||
@@ -29,7 +29,7 @@ Like individual application containers, pods are considered to be relatively eph
|
||||
|
||||
Pods facilitate data sharing and communication among their constituents.
|
||||
|
||||
The applications in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the application containers within the pod. [More details on networking](../admin/networking).
|
||||
The applications in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the application containers within the pod. [More details on networking](/{{page.version}}/docs/admin/networking).
|
||||
|
||||
In addition to defining the application containers that run in the pod, the pod specifies a set of shared storage volumes. Volumes enable data to survive container restarts and to be shared among the applications within the 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.html#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](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.
|
||||
@@ -118,7 +118,7 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(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).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 <registry.domain>`.
|
||||
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:
|
||||
|
||||
|
||||
@@ -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).
|
||||
object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
|
||||
@@ -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/)
|
||||
|
||||
|
||||
|
||||
@@ -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/)
|
||||
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
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.
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user