* 'master' of https://github.com/kubernetes/kubernetes.github.io: (87 commits)
  fix envFrom in configmap
  Add link to example for CRDs (#5641)
  Fixed links to architecture.md and principles.md
  Polish AppArmor tutorial
  Remove dangling files related to apparmor
  fix the typo of serviceaccount (#5533)
  Correct setup link (#5634)
  relink the  persistent volume of petset (#5582)
  Updates to case study landing page (#5629)
  translate doc resource-quotas into chinese
  minor encoding fix for CN page
  fix typo
  concepts-overview-components+abac-fix
  concepts-overview-components-fix
  Update links to avoid redirects. (#5627)
  Update links to avoid redirects. (#5625)
  Fix 404s. (#5624)
  Fix 404s. (#5623)
  Edits cpu-constraint-namespace.md
  Fix index redirects (#5502)
  ...

# Conflicts:
#	_redirects
#	docs/concepts/storage/volumes.md
#	docs/concepts/workloads/controllers/daemonset.md
#	docs/concepts/workloads/controllers/petset.md
#	docs/concepts/workloads/controllers/statefulset.md
#	docs/tasks/run-application/run-single-instance-stateful-application.md
#	docs/tutorials/stateful-application/zookeeper.md
This commit is contained in:
Andrew Chen
2017-09-26 17:29:30 -07:00
126 changed files with 3823 additions and 1089 deletions
@@ -136,7 +136,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.
The Python client can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py).
#### Other languages
@@ -308,7 +308,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](/docs/user-guide/services/#ips-and-vips):
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
- runs on each node
- proxies UDP and TCP
- does not understand HTTP
@@ -29,7 +29,7 @@ frontend and backend are connected using a Kubernetes Service object.
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
require a supported environment. If your environment does not
support this, you can use a Service of type
[NodePort](/docs/user-guide/services/#type-nodeport) instead.
[NodePort](/docs/concepts/services-networking/service/#type-nodeport) instead.
{% endcapture %}
@@ -25,7 +25,7 @@ cluster nodes _provided your cluster runs in a supported environment and is conf
## Configuration file
To create an external load balancer, add the following line to your
[service configuration file](/docs/user-guide/services/operations/#service-configuration-file):
[service configuration file](/docs/concepts/services-networking/service/#type-loadbalancer):
```json
"type": "LoadBalancer"
@@ -68,7 +68,7 @@ resource (in the case of the example above, a replication controller named
`example`).
For more information, including optional flags, refer to the
[`kubectl expose` reference](/docs/user-guide/kubectl/v1.6/#expose).
[`kubectl expose` reference](/docs/user-guide/kubectl/{{page.version}}/#expose).
## Finding your IP address
@@ -101,7 +101,7 @@ load-balanced access to an application running in a cluster.
## Using a service configuration file
As an alternative to using `kubectl expose`, you can use a
[service configuration file](/docs/user-guide/services/operations)
[service configuration file](/docs/concepts/services-networking/service/)
to create a Service.
@@ -117,7 +117,7 @@ provides load balancing for an application that has two running instances.
## Using a service configuration file
As an alternative to using `kubectl expose`, you can use a
[service configuration file](/docs/user-guide/services/operations)
[service configuration file](/docs/concepts/services-networking/service/)
to create a Service.
{% endcapture %}
@@ -20,7 +20,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
The Dashboard UI is not deployed by default. To deploy it, run the following command:
```
kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
```
## Accessing the Dashboard UI
@@ -64,7 +64,7 @@ To access the deploy wizard from the Welcome page, click the respective button.
The deploy wizard expects that you provide the following information:
- **App name** (mandatory): Name for your application. A [label](/docs/user-guide/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
@@ -84,7 +84,7 @@ If needed, you can expand the **Advanced options** section where you can specify
- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details.
- **Labels**: Default [labels](/docs/user-guide/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
Example:
@@ -147,7 +147,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.
The Python client can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py):
```python
@@ -15,7 +15,7 @@ This page shows how to use Calico for NetworkPolicy.
{% capture steps %}
## Deploying a cluster using Calico
You can deploy a cluster using Calico for network policy in the default [GCE deployment](/docs/getting-started-guides/gce) using the following set of commands:
You can deploy a cluster using Calico for network policy in the default [GCE deployment](/docs/getting-started-guides/gce/) using the following set of commands:
```shell
export NETWORK_POLICY_PROVIDER=calico
@@ -22,7 +22,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi
an existing StorageClass that is marked as default. This default StorageClass
is then used to dynamically provision storage for PersistentVolumeClaims
that do not require any specific storage class. See
[PersistentVolumeClaim documentation](/docs/user-guide/persistent-volumes/#class-1)
[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1)
for details.
The pre-installed default StorageClass may not fit well with your expected workload;
@@ -68,7 +68,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
{% capture whatsnext %}
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Learn more about [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims).
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
### Reference
@@ -184,7 +184,7 @@ etcd supports restoring from snapshots that are taken from an etcd process of th
Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir). `datadir` is located at `$DATA_DIR/member/snap/db`. For more information and examples on restoring a cluster from a snapshot file, see [etcd disaster recovery documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster).
If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD__ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD__ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.
If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD_ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD_ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.
If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.
@@ -195,7 +195,7 @@ resources:
Because your Container did not specify its own CPU request and limit, it was given the
[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/)
from the LimitRange.
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace)
At this point, your Container might be running or it might not be running. Recall that a prerequisite
for this task is that your Nodes have at least 1 CPU. If each of your Nodes has only
1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request
@@ -219,12 +219,12 @@ Pods that were created previously.
As a cluster administrator, you might want to impose restrictions on the CPU resources that Pods can use.
For example:
* Each Node in a cluster has 2 cpu. You do not want to accept any Pod that requests
more than 2 cpu, because no Node in the cluster can support the request.
* Each Node in a cluster has 2 CPU. You do not want to accept any Pod that requests
more than 2 CPU, because no Node in the cluster can support the request.
* A cluster is shared by your production and development departments.
You want to allow production workloads to consume up to 3 cpu, but you want development workloads to be limited
to 1 cpu. You create separate namespaces for production and development, and you apply CPU constraints to
You want to allow production workloads to consume up to 3 CPU, but you want development workloads to be limited
to 1 CPU. You create separate namespaces for production and development, and you apply CPU constraints to
each namespace.
## Clean up
@@ -15,7 +15,7 @@ You'll need to have a Kubernetes cluster in place, with network policy support.
* [Cilium](/docs/tasks/administer-cluster/cilium-network-policy/)
* [Kube-router](/docs/tasks/administer-cluster/kube-router-network-policy/)
* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
* [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/weave-network-policy/)
**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
{% endcapture %}
@@ -49,7 +49,7 @@ container, and if users use the [node
allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
are made local to the end user pod part of the cgroup hierarchy as well as the
root node. This
[script](/docs/concepts/cluster-administration/out-of-resource/memory-available.sh)
[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
reproduces the same set of steps that the `kubelet` performs to calculate
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -66,7 +66,7 @@ being terminated and recreated on other nodes. The out of the box roles represen
between flexibility and the common use cases, but more limited roles should be carefully reviewed
to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
Consult the [authorization reference section](/docs/admin/authorization) for more information.
Consult the [authorization reference section](/docs/admin/authorization/) for more information.
## Controlling the capabilities of a workload or user at runtime
@@ -82,7 +82,7 @@ resources granted to a namespace. This is most often used to limit the amount of
or persistent disk a namespace can allocate, but can also control how many pods, services, or
volumes exist in each namespace.
[Limit ranges](/docs/admin/limitrange) restrict the maximum or minimum size of some of the
[Limit ranges](/docs/tasks/administer-cluster/memory-default-namespace/) restrict the maximum or minimum size of some of the
resources above, to prevent users from requesting unreasonably high or low values for commonly
reserved resources like memory, or to provide default limits when none are specified.
@@ -219,7 +219,7 @@ could use all of the CPU resources available on the Node where it is running.
* The Container is running in a namespace that has a default CPU limit, and the
Container is automatically assigned the default limit. Cluster administrators can use a
[LimitRange](https://kubernetes.io/docs/api-reference/v1.6/)
[LimitRange](https://kubernetes.io/docs/api-reference/v1.7/#limitrange-v1-core/)
to specify a default value for the CPU limit.
## Motivation for CPU requests and limits
@@ -313,7 +313,7 @@ could use all of the memory available on the Node where it is running.
* The Container is running in a namespace that has a default memory limit, and the
Container is automatically assigned the default limit. Cluster administrators can use a
[LimitRange](https://kubernetes.io/docs/api-reference/v1.6/)
[LimitRange](https://kubernetes.io/docs/api-reference/v1.7/#limitrange-v1-core)
to specify a default value for the memory limit.
## Motivation for memory requests and limits
@@ -75,7 +75,7 @@ a `disktype=ssd` label.
{% capture whatsnext %}
Learn more about
[labels and selectors](/docs/user-guide/labels/).
[labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
{% endcapture %}
{% include templates/task.md %}
@@ -23,7 +23,7 @@ This page shows you how to configure an application using a ConfigMap. ConfigMap
## Use kubectl to create a ConfigMap
Use the `kubectl create configmap` command to create configmaps from [directories](#creating-configmaps-from-directories), [files](#creating-configmaps-from-files), or [literal values](#creating-configmaps-from-literal-values):
Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
```shell
kubectl create configmap <map-name> <data-source>
@@ -124,7 +124,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
SPECIAL_TYPE: charm
```
1. Use `env-from` to define all of the ConfigMap's data as Pod environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
1. Use `envFrom` to define all of the ConfigMap's data as Pod environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
```yaml
apiVersion: v1
@@ -185,7 +185,7 @@ very charm
## Add ConfigMap data to a Volume
As explained in [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configmap.html), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
As explained in [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configmap/), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
The examples in this section refer to a ConfigMap named special-config, shown below.
@@ -81,7 +81,7 @@ The output shows that nginx is serving the web page that was written by the init
{% capture whatsnext %}
* Learn more about
[communicating between Containers running in the same Pod](/docs/tasks/configure-pod-container/communicate-containers-same-pod/).
[communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/).
* Learn more about [Init Containers](/docs/concepts/workloads/pods/init-containers/).
* Learn more about [Volumes](/docs/concepts/storage/volumes/).
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
@@ -9,7 +9,7 @@ title: Configure Service Accounts for Pods
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](/docs/admin/service-accounts-admin).*
[Cluster Admin Guide to Service Accounts](/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
@@ -146,18 +146,19 @@ Any tokens for non-existent service accounts will be cleaned up by the token con
```shell
$ kubectl describe secrets/build-robot-secret
Name: build-robot-secret
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name=build-robot,kubernetes.io/service-account.uid=870ef2a5-35cf-11e5-8d06-005056b45392
Name: build-robot-secret
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name=build-robot
kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
Type: kubernetes.io/service-account-token
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1220 bytes
token: ...
namespace: 7 bytes
ca.crt: 1338 bytes
namespace: 7 bytes
token: ...
```
**Note:** The content of `token` is elided here.
@@ -379,7 +379,7 @@ Learn about additional debugging tools, including:
* [Logging](/docs/user-guide/logging/overview)
* [Monitoring](/docs/user-guide/monitoring)
* [Getting into containers via `exec`](/docs/user-guide/getting-into-containers)
* [Connecting to containers via proxies](/docs/user-guide/connecting-to-applications-proxy)
* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
* [Connecting to containers via port forwarding](/docs/user-guide/connecting-to-applications-port-forward)
@@ -125,9 +125,9 @@ underlying Kubernetes services (once these have been allocated - this
may take a few seconds). For inter-cluster and inter-cloud-provider
networking between service shards to work correctly, your services
need to have an externally visible IP address. [Service Type:
Loadbalancer](/docs/user-guide/services/#type-loadbalancer)
Loadbalancer](/docs/concepts/services-networking/service/#type-loadbalancer)
is typically used for this, although other options
(e.g. [External IP's](/docs/user-guide/services/#external-ips)) exist.
(e.g. [External IP's](/docs/concepts/services-networking/service/#external-ips)) exist.
Note also that we have not yet provisioned any backend Pods to receive
the network traffic directed to these addresses (i.e. 'Service
@@ -261,11 +261,11 @@ kubefed init fellowship \
`kubefed init` exposes the federation API server as a Kubernetes
[service](/docs/concepts/services-networking/service/) on the host cluster. By default,
this service is exposed as a
[load balanced service](/docs/user-guide/services/#type-loadbalancer).
[load balanced service](/docs/concepts/services-networking/service/#type-loadbalancer).
Most on-premises and bare-metal environments, and some cloud
environments lack support for load balanced services. `kubefed init`
allows exposing the federation API server as a
[`NodePort` service](/docs/user-guide/services/#type-nodeport) on
[`NodePort` service](/docs/concepts/services-networking/service/#type-nodeport) on
such environments. This can be accomplished by passing
the `--api-server-service-type=NodePort` flag. You can also specify
the preferred address to advertise the federation API server by
@@ -289,17 +289,17 @@ Federation control plane stores its state in
[`etcd`](https://coreos.com/etcd/docs/latest/) data must be stored in
a persistent storage volume to ensure correct operation across
federation control plane restarts. On host clusters that support
[dynamic provisioning of storage volumes](/docs/user-guide/persistent-volumes/#dynamic),
[dynamic provisioning of storage volumes](/docs/concepts/storage/persistent-volumes/#dynamic),
`kubefed init` dynamically provisions a
[`PersistentVolume`](/docs/user-guide/persistent-volumes/#persistent-volumes)
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes)
and binds it to a
[`PersistentVolumeClaim`](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
to store [`etcd`](https://coreos.com/etcd/docs/latest/) data. If your
host cluster doesn't support dynamic provisioning, you can also
statically provision a
[`PersistentVolume`](/docs/user-guide/persistent-volumes/#persistent-volumes).
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes).
`kubefed init` creates a
[`PersistentVolumeClaim`](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
that has the following configuration:
```yaml
@@ -321,12 +321,12 @@ spec:
```
To statically provision a
[`PersistentVolume`](/docs/user-guide/persistent-volumes/#persistent-volumes),
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes),
you must ensure that the
[`PersistentVolume`](/docs/user-guide/persistent-volumes/#persistent-volumes)
[`PersistentVolume`](/docs/concepts/storage/persistent-volumes/#persistent-volumes)
that you create has the matching storage class, access mode and
at least as much capacity as the requested
[`PersistentVolumeClaim`](/docs/user-guide/persistent-volumes/#persistentvolumeclaims).
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
Alternatively, you can disable persistent storage completely
by passing `--etcd-persistent-storage=false` to `kubefed init`.
@@ -342,7 +342,7 @@ kubefed init fellowship \
```
`kubefed init` still doesn't support attaching an existing
[`PersistentVolumeClaim`](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)
[`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
to the federation control plane that it bootstraps. We are planning to
support this in a future version of `kubefed`.
@@ -373,7 +373,7 @@ For more information see
Once you've deployed a federation control plane, you'll need to make
that control plane aware of the clusters it should manage. You can add
a cluster to your federation by using the [`kubefed join`](/docs/admin/kubefed_join)
a cluster to your federation by using the [`kubefed join`](/docs/admin/kubefed_join/)
command.
To use `kubefed join`, you'll need to provide the name of the cluster
@@ -468,7 +468,7 @@ as described in the
## Removing a cluster from a federation
To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/admin/kubefed_unjoin)
To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/admin/kubefed_unjoin/)
command with the cluster name and the federation's
`--host-cluster-context`:
@@ -161,7 +161,7 @@ The output shows the values of selected environment variables:
{% capture whatsnext %}
* [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/)
* [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core)
* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core)
* [EnvVar](/docs/resources-reference/{{page.version}}/#envvar-v1-core)
+33 -32
View File
@@ -123,7 +123,7 @@ metadata:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/allow-database: "resource version"
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
@@ -229,7 +229,7 @@ metadata:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/allow-database: "resource version"
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
@@ -325,34 +325,35 @@ spec:
**Pod spec after admission controller:**
```yaml
apiVersion: v1
kind: Pod
metadata:
labels:
app: guestbook
tier: frontend
annotations:
podpreset.admission.kubernetes.io/allow-database: "resource version"
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /cache
name: cache-volume
env:
- name: GET_HOSTS_FROM
value: dns
- name: DB_PORT
value: "6379"
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}
metadata:
labels:
app: guestbook
tier: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /cache
name: cache-volume
env:
- name: GET_HOSTS_FROM
value: dns
- name: DB_PORT
value: "6379"
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}
```
### Multiple PodPreset Example
@@ -432,8 +433,8 @@ metadata:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/allow-database: "resource version"
podpreset.admission.kubernetes.io/proxy: "resource version"
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
podpreset.admission.kubernetes.io/podpreset-proxy: "resource version"
spec:
containers:
- name: website
@@ -538,7 +539,7 @@ $ kubectl describe ...
....
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
Tue, 07 Feb 2017 16:56:12 -0700 Tue, 07 Feb 2017 16:56:12 -0700 1 {podpreset.admission.kubernetes.io/allow-database } conflict Conflict on pod preset. Duplicate mountPath /cache.
Tue, 07 Feb 2017 16:56:12 -0700 Tue, 07 Feb 2017 16:56:12 -0700 1 {podpreset.admission.kubernetes.io/podpreset-allow-database } conflict Conflict on pod preset. Duplicate mountPath /cache.
```
## Deleting a Pod Preset
@@ -109,7 +109,7 @@ Processing item cherry
In the first example, each instance of the template had one parameter, and that parameter was also
used as a label. However label keys are limited in [what characters they can
contain](/docs/user-guide/labels/#syntax-and-character-set).
contain](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
This slightly more complex example uses the jinja2 template language to generate our objects.
We will use a one-line python script to convert the template to a file.
@@ -159,7 +159,7 @@ causes:
The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
node. This is possible when the node is
[running out of resources](/docs/concepts/cluster-administration/out-of-resource/).
[running out of resources](/docs/tasks/administer-cluster/out-of-resource/).
When this happens, find the nodes that don't have the DaemonSet pods scheduled on
by comparing the output of `kubectl get nodes` and the output of:
@@ -18,13 +18,13 @@ This document walks you through an example of enabling Horizontal Pod Autoscalin
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[Heapster](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster
as Horizontal Pod Autoscaler uses it to collect metrics
(if you followed [getting started on GCE guide](/docs/getting-started-guides/gce),
(if you followed [getting started on GCE guide](/docs/getting-started-guides/gce/),
heapster monitoring will be turned-on by default).
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
must be able to communicate with the API server providing the custom metrics API.
See the [Horizontal Pod Autoscaling user guide](/docs/user-guide/horizontal-pod-autoscaling/#support-for-custom-metrics) for more details.
See the [Horizontal Pod Autoscaling user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
## Step One: Run & expose php-apache server
@@ -148,7 +148,7 @@ properties to perform orderly startup of MySQL replication.
### Generating configuration
Before starting any of the containers in the Pod spec, the Pod first runs any
[Init Containers](/docs/user-guide/production-pods/#handling-initialization)
[Init Containers](/docs/concepts/workloads/pods/init-containers/)
in the order defined.
The first Init Container, named `init-mysql`, generates special MySQL config
@@ -168,7 +168,7 @@ Because the example topology consists of a single MySQL master and any number of
slaves, the script simply assigns ordinal `0` to be the master, and everyone
else to be slaves.
Combined with the StatefulSet controller's
[deployment order guarantee](/docs/concepts/abstractions/controllers/statefulsets/#deployment-and-scaling-guarantee),
[deployment order guarantee](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/),
this ensures the MySQL master is Ready before creating slaves, so they can begin
replicating.
@@ -292,7 +292,7 @@ running while you force a Pod out of the Ready state.
### Break the Readiness Probe
The [readiness probe](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks)
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
to make sure the server is up and able to execute queries.
@@ -410,7 +410,7 @@ With MySQL replication, you can scale your read query capacity by adding slaves.
With StatefulSet, you can do this with a single command:
```shell
kubectl scale --replicas=5 statefulset mysql
kubectl scale statefulset mysql --replicas=5
```
Watch the new Pods come up by running:
@@ -443,7 +443,7 @@ pod "mysql-client" deleted
Scaling back down is also seamless:
```shell
kubectl scale --replicas=3 statefulset mysql
kubectl scale statefulset mysql --replicas=3
```
Note, however, that while scaling up creates new PersistentVolumeClaims
@@ -149,7 +149,7 @@ specific to stateful apps:
* Don't scale the app. This setup is for single-instance apps
only. The underlying PersistentVolume can only be mounted to one
Pod. For clustered stateful apps, see the
[StatefulSet documentation](/docs/concepts/workloads/controllers/statefulset.md).
[StatefulSet documentation](/docs/concepts/workloads/controllers/statefulset/).
* Use `strategy:` `type: Recreate` in the Deployment configuration
YAML file. This instructs Kubernetes to _not_ use rolling
updates. Rolling updates will not work, as you cannot have more than