Merge pull request #1 from kubernetes/master

Update from upstream

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,5 @@
-> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> For 1.9 Features: set Milestone to `1.9` and Base Branch to `release-1.9`
-> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> NOTE: Please check the “Allow edits from maintainers” box (see image below) to
-> [allow reviewers to fix problems](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) on your patch and speed up the review process.
+> NOTE: After opening the PR, please *un-check and re-check* the ["Allow edits from maintainers"](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.> 
 >
 > Please delete this note before submitting the pull request.
->
-> NOTE: After opening the PR, please *un-check and re-check* the "Allow edits from maintainers" box. This is a temporary workaround to address a known issue with GitHub.
 
 ![Allow edits from maintainers checkbox](https://help.github.com/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png)

_config.yml

@@ -18,16 +18,21 @@ defaults:
     scope:
       path: ""
     values:
-      fullversion: "v1.8.0"
-      version: "v1.8"
+      fullversion: "v1.9.0"
+      version: "v1.9"
       githubbranch: "master"
       docsbranch: "master"
       versions:
-        - fullversion: "v1.8.0"
+        - fullversion: "v1.9.0"
+          version: "v1.9"
+          githubbranch: "v1.9.0"
+          docsbranch: "release-1.9"
+          url: https://kubernetes.io/docs/home/
+        - fullversion: "v1.8.4"
           version: "v1.8"
-          githubbranch: "v1.8.0"
+          githubbranch: "v1.8.4"
           docsbranch: "release-1.8"
-          url: https://kubernetes.io/docs/home/
+          url: https://v1-8.docs.kubernetes.io/docs/home/
         - fullversion: "v1.7.6"
           version: "v1.7"
           githubbranch: "v1.7.6"
@@ -43,11 +48,6 @@ defaults:
           githubbranch: "v1.5.7"
           docsbranch: "release-1.5"
           url: https://v1-5.docs.kubernetes.io/docs/
-        - fullversion: "v1.4.12"
-          version: "v1.4"
-          githubbranch: "v1.4.12"
-          docsbranch: "release-1.4"
-          url: https://v1-4.docs.kubernetes.io/docs/
       deprecated: false
       currentUrl: https://kubernetes.io/docs/home/
       nextUrl: http://kubernetes-io-vnext-staging.netlify.com/

_data/concepts.yml

@@ -24,6 +24,7 @@ toc:
 
 - title: Extending Kubernetes
   section:
+  - docs/concepts/overview/extending.md
   - title: Extending the Kubernetes API
     section:
     - docs/concepts/api-extension/apiserver-aggregation.md

_data/glossary/annotation.yaml

@@ -0,0 +1,9 @@
+id: annotation
+name: Annotation
+full-link: docs/concepts/overview/working-with-objects/annotations
+tags:
+- fundamental
+short-description: >
+  A key-value pair that is used to attach arbitrary non-identifying metadata to objects.
+long-description: >
+  The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels. Clients such as tools and libraries can retrieve this metadata.

_data/glossary/configmap.yaml

@@ -0,0 +1,13 @@
+id: configmap
+name: ConfigMap
+full-link: /docs/tasks/configure-pod-container/configmap/
+related:
+- pod
+- secret
+tags:
+- core-object
+short-description: >
+  An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or config files in a {% glossary_tooltip text="volume" term_id="volume" %}.
+long-description: >
+  Allows you to decouple environment-specific configuration from your {% glossary_tooltip text="container images" term_id="container" %}, so that your applications are easily portable.
+  When storing confidential data use a [Secret](https://kubernetes.io/docs/concepts/configuration/secret/).

_data/glossary/daemonset.yaml

@@ -0,0 +1,10 @@
+id: daemonset
+name: DaemonSet
+full-link: /docs/concepts/workloads/controllers/daemonset
+tags:
+- fundamental
+- workload
+short-description: >
+  Ensures a copy of a {% glossary_tooltip term_id="pod" %} is running across a set of nodes in a {% glossary_tooltip term_id="cluster" %}.
+long-description: >
+  Used to deploy system daemons such as log collectors and monitoring agents that typically must run on every {% glossary_tooltip term_id="node" %}.

_data/glossary/horizontal-pod-autoscaler.yaml

@@ -0,0 +1,15 @@
+id: horizontal-pod-autoscaler
+name: Horizontal Pod Autoscaler
+full-link: /docs/tasks/run-application/horizontal-pod-autoscale/
+aka:
+- HPA
+related:
+- pod
+tags:
+- operation
+short-description: >
+  An API resource that automatically scales the number of pod replicas based on targeted CPU
+  utilization or custom metric targets.
+long-description: >
+  HPA is typically used with replication controllers, deployments or replica sets and cannot be
+  applied to objects that cannot be scaled, for example DaemonSets.  

_data/glossary/image.yaml

@@ -0,0 +1,9 @@
+id: image
+name: Image
+tags:
+- fundamental
+short-description: >
+  Stored instance of a container that holds a set of software needed to run an application.
+long-description: >
+  A way of packaging software that allows it to be stored in a container registry, pulled to a local system, and run as an application. Meta data is included in the image that can indicate what executable to run, who built it, and other information.
+

_data/glossary/job.yaml

@@ -0,0 +1,9 @@
+id: job
+name: Job
+full-link: /docs/concepts/workloads/controllers/jobs-run-to-completion
+tags:
+- core-object
+short-description: >
+  A finite or batch task that runs to completion.
+long-description: >
+  Creates one or more {% glossary_tooltip term_id="pod" %} objects and ensures that a specified number of them successfully terminate. As Pods successfully complete, the Job tracks the successful completions.

_data/glossary/kubelet.yaml

@@ -0,0 +1,10 @@
+id: kubelet
+name: Kubelet
+full-link: docs/reference/generated/kubelet
+tags:
+- fundamental
+- core-object
+short-description: >
+  An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
+long-description: >
+  The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.

_data/glossary/labels.yaml

@@ -0,0 +1,9 @@
+id: labels
+name: Labels
+full-link: /docs/concepts/overview/working-with-objects/labels
+tags:
+- fundamental
+short-description: >
+  Used to tag objects with identifying attributes that are meaningful and relevant to users.
+long-description: >
+  Labels are key/value pairs that are attached to objects, such as pods. They can be used to organize and to select subsets of objects.

_data/glossary/namespace.yaml

@@ -0,0 +1,9 @@
+id: namespace
+name: Namespace
+full-link: /docs/concepts/overview/working-with-objects/namespaces
+tags:
+- fundamental
+short-description: >
+  An abstraction used by Kubernetes to support virtual clusters on the same physical {% glossary_tooltip term_id="cluster" %}.
+long-description: >
+  Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.

_data/glossary/network-policy.yaml

@@ -0,0 +1,13 @@
+id: network-policy
+name: Network Policy
+full-link: /docs/concepts/services-networking/network-policies/
+aka:
+  - NetworkPolicy
+tags:
+- networking
+- architecture
+- extension
+short-description: >
+  A specification of how groups of Pods are allowed to communicate with each other and with other network endpoints.
+long-description: >
+  Network Policies help you declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate, and more specifically which port numbers to enforce each policy on. `NetworkPolicy` resources use labels to select Pods and define rules which specify what traffic is allowed to the selected Pods. Network Policies are implemented by a supported network plugin provided by a network provider. Be aware that creating a network resource without a controller to implement it will have no effect.

_data/glossary/node.yaml

@@ -0,0 +1,13 @@
+id: node
+name: Node
+full-link: /docs/concepts/architecture/nodes/
+aka:
+- Minion
+related:
+- deployment
+tags:
+- fundamental
+short-description: >
+  A node is a worker machine in Kubernetes.
+long-description: >
+  A worker machine may be a VM or physical machine, depending on the cluster. It has the {% glossary_tooltip text="Services" term_id="service" %} necessary to run {% glossary_tooltip text="Pods" term_id="pod" %} and is managed by the master components. The {% glossary_tooltip text="Services" term_id="service" %} on a node include Docker, kubelet and kube-proxy.

_data/glossary/platform-developer.yaml

@@ -2,9 +2,10 @@ id: platform-developer
 name: Platform Developer
 aka:
   - Kubernetes Developer
+  - Extension Developer
 tags:
   - user-type
 short-description: >
   A person who customizes the Kubernetes platform to fit the needs of their project.
 long-description: >
-  A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application.
+  A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application.  Some Platform Developers are also {% glossary_tooltip text="contributors" term_id="contributor" %} and develop extensions which are contributed to the Kubernetes community.  Others develop closed-source commercial or site-specific extensions.

_data/glossary/pod-security-policy.yaml

@@ -0,0 +1,19 @@
+id: pod-security-policy
+name: Pod Security Policy
+full-link: /docs/concepts/policy/pod-security-policy/
+related:
+- pod
+- container
+- sidecar
+- deployment
+- statefulset
+- security
+tags:
+- core-object
+- fundamental
+short-description: >
+  Enables fine-grained authorization of {% glossary_tooltip term_id="pod" %} creation and updates.
+long-description: >
+  A cluster-level resource that controls security sensitive aspects of the Pod specification.
+  The `PodSecurityPolicy` objects define a set of conditions that a Pod must run with in order to be accepted into the system, as well as defaults for the related fields.
+  Pod Security Policy control is implemented as an optional admission controller.

_data/glossary/replica-set.yml

@@ -0,0 +1,13 @@
+id: replica-set
+name: ReplicaSet
+full-link: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
+related:
+- replication-controller
+tags:
+- core-object
+- architecture
+short-description: >
+  ReplicaSet is the next-generation Replication Controller.
+long-description: >
+  ReplicaSet, like ReplicationController, ensures that a specified number of pods replicas are running at one time.
+  ReplicaSet supports the new set-based selector requirements as described in the labels user guide, whereas a Replication Controller only supports equality-based selector requirements.

_data/glossary/replication-controller.yaml

@@ -0,0 +1,9 @@
+id: replication-controller
+name: Replication Controller
+tags:
+- fundamental
+short-description: >
+  Kubernetes service that ensures a specific number of instances of a pod are always running.
+long-description: >
+  Will automatically add or remove running instances of a pod, based on a set value for that pod. Allows the pod to return to the defined number of instances if pods are deleted or if too many are started by mistake.
+

_data/glossary/resource-quota.yaml

@@ -0,0 +1,11 @@
+id: resource-quota
+name: Resource Quotas
+full-link: /docs/concepts/policy/resource-quotas/
+tags:
+- fundamental
+- operation
+- architecture
+short-description: >
+  Provides constraints that limit aggregate resource consumption per {% glossary_tooltip term_id="namespace" %}.
+long-description: >
+  Limits the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project.

_data/glossary/secret.yml

@@ -0,0 +1,15 @@
+id: secret
+name: Secret
+full-link: /docs/concepts/configuration/secret/
+related:
+- pods
+- volume
+tags:
+- core-object
+- security
+short-description: >
+  Stores sensitive information, such as passwords, OAuth tokens, and ssh keys.
+long-description: >
+  Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest. 
+  A {% glossary_tooltip text="Pod" term_id="pod" %} references the secret as a file in a volume mount or by the kubelet pulling images for a pod.
+  Secrets are great for confidential data and [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configmap/) for non-confidential data.

_data/glossary/security-context.yaml

@@ -0,0 +1,9 @@
+id: security-context
+name: Security Context
+full-link: /docs/tasks/configure-pod-container/security-context/
+tags:
+- security
+short-description: >
+  The securityContext field defines privilege and access control settings for a Pod or Container, including the runtime UID and GID.
+long-description: >
+  The securityContext field in a {% glossary_tooltip term_id="pod" %} (applying to all containers) or container is used to set the user (runAsUser) and group (fsGroup), capabilities, privilege settings, and security policies (SELinux/AppArmor/Seccomp) that container processes use.

_data/glossary/service-account.yaml

@@ -0,0 +1,10 @@
+id: service-account
+name: Service Account
+full-link: /docs/tasks/configure-pod-container/configure-service-account/
+tags:
+- fundamental
+- core-object
+short-description: >
+  Provides an identity for processes that run in a Pod {% glossary_tooltip text="Pods" term_id="pod" %}.
+long-description: >
+  When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace {% glossary_tooltip text="Namespace" term_id="namespace" %}.

_data/glossary/service-catalog.yaml

@@ -5,4 +5,4 @@ tags:
 short-description: >
   An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
 long-description: >
-  Service Catalog provides a way to list, provision, and bind with external {% glossary_tooltip text="Managed Services" term_id="managed-service" %} from {% glossary_tooltip text="Service Brokers" term_id="service-broker" %} without needing detailed knowledge about how those services are created or managed.
+  It provides a way to list, provision, and bind with external {% glossary_tooltip text="Managed Services" term_id="managed-service" %} from {% glossary_tooltip text="Service Brokers" term_id="service-broker" %} without needing detailed knowledge about how those services are created or managed.

_data/glossary/volume.yaml

@@ -0,0 +1,17 @@
+id: volume
+name: Volume
+full-link: /docs/concepts/storage/volumes/
+related:
+- pod
+- container
+- secret
+tags:
+- core-object
+- fundamental
+short-description: >
+ A directory containing data, accessible to the containers in a {% glossary_tooltip text="pod" term_id="pod" %}.
+long-description: >
+ A Kubernetes volume lives as long as the {% glossary_tooltip text="pod" term_id="pod" %} that encloses it.
+ Consequently, a volume outlives any {% glossary_tooltip text="containers" term_id="container" %} that run within the
+ {% glossary_tooltip text="pod" term_id="pod" %}, and data is preserved across
+ {% glossary_tooltip text="container" term_id="container" %} restarts.