No design/ docs, no linking to README files
This commit is contained in:
John Mulhausen
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user