- Attend KubeCon in Austin, TX on December 6-8, 2017 + Attend KubeCon in Austin, TX on December 6-8, 2017
diff --git a/docs/admin/authorization/webhook.md b/docs/admin/authorization/webhook.md
index a0ba0f8e38..f451a0d569 100644
--- a/docs/admin/authorization/webhook.md
+++ b/docs/admin/authorization/webhook.md
@@ -31,8 +31,10 @@ A configuration example which uses HTTPS client auth:
clusters:
- name: name-of-remote-authz-service
cluster:
- certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
- server: https://authz.example.com/authorize # URL of remote service to query. Must use 'https'.
+ # CA for verifying the remote service.
+ certificate-authority: /path/to/ca.pem
+ # URL of remote service to query. Must use 'https'. May not include parameters.
+ server: https://authz.example.com/authorize
# users refers to the API Server's webhook configuration.
users:
diff --git a/docs/admin/daemon.yaml b/docs/admin/daemon.yaml
deleted file mode 100644
index c5cd14a592..0000000000
--- a/docs/admin/daemon.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: DaemonSet
-metadata:
- name: prometheus-node-exporter
-spec:
- template:
- metadata:
- name: prometheus-node-exporter
- labels:
- daemon: prom-node-exp
- spec:
- containers:
- - name: c
- image: prom/prometheus
- ports:
- - containerPort: 9090
- hostPort: 9090
- name: serverport
diff --git a/docs/admin/high-availability/kube-scheduler.yaml b/docs/admin/high-availability/kube-scheduler.yaml
index 9e997cbc47..40c863da48 100644
--- a/docs/admin/high-availability/kube-scheduler.yaml
+++ b/docs/admin/high-availability/kube-scheduler.yaml
@@ -21,9 +21,6 @@ spec:
volumeMounts:
- mountPath: /var/log/kube-scheduler.log
name: logfile
- - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
- name: default-token-s8ejd
- readOnly: true
volumes:
- hostPath:
path: /var/log/kube-scheduler.log
diff --git a/docs/admin/multiple-schedulers/pod1.yaml b/docs/admin/multiple-schedulers/pod1.yaml
index 733aa97d99..6cf8fec25a 100644
--- a/docs/admin/multiple-schedulers/pod1.yaml
+++ b/docs/admin/multiple-schedulers/pod1.yaml
@@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
- image: gcr.io/google_containers/pause:2.0
\ No newline at end of file
+ image: gcr.io/google_containers/pause:2.0
diff --git a/docs/concepts/abstractions/controllers/my-repset.yaml b/docs/concepts/abstractions/controllers/my-repset.yaml
deleted file mode 100644
index 54befd8f9d..0000000000
--- a/docs/concepts/abstractions/controllers/my-repset.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: ReplicaSet
-metadata:
- name: my-repset
-spec:
- replicas: 3
- selector:
- matchLabels:
- pod-is-for: garbage-collection-example
- template:
- metadata:
- labels:
- pod-is-for: garbage-collection-example
- spec:
- containers:
- - name: nginx
- image: nginx
diff --git a/docs/concepts/cluster-administration/cloud-providers.md b/docs/concepts/cluster-administration/cloud-providers.md
index 739476217c..7b31be5cd7 100644
--- a/docs/concepts/cluster-administration/cloud-providers.md
+++ b/docs/concepts/cluster-administration/cloud-providers.md
@@ -213,6 +213,28 @@ provider configuration:
bs-version=v2
```
+#### Metadata
+These configuration options for the OpenStack provider pertain to metadata and
+should appear in the `[Metadata]` section of the `cloud.conf` file:
+
+* `search-order` (Optional): This configuration key influences the way that the
+ provider retrieves metadata relating to the instance(s) in which it runs. The
+ default value of `configDrive,metadataService` results in the provider
+ retrieving metadata relating to the instance from the config drive first if
+ available and then the metadata service. Alternative values are:
+ * `configDrive` - Only retrieve instance metadata from the configuration
+ drive.
+ * `metadataService` - Only retrieve instance metadata from the metadata
+ service.
+ * `metadataService,configDrive` - Retrieve instance metadata from the metadata
+ service first if available, then the configuration drive.
+
+ Influencing this behavior may be desirable as the metadata on the
+ configuration drive may grow stale over time, whereas the metadata service
+ always provides the most up to date view. Not all OpenStack clouds provide
+ both configuration drive and metadata service though and only one or the other
+ may be available which is why the default is to check both.
+
#### Router
These configuration options for the OpenStack provider pertain to routing and
should appear in the `[Route]` section of the `cloud.conf` file:
diff --git a/docs/concepts/configuration/overview.md b/docs/concepts/configuration/overview.md
index f9151eca8c..098517d9a7 100644
--- a/docs/concepts/configuration/overview.md
+++ b/docs/concepts/configuration/overview.md
@@ -37,13 +37,7 @@ This is a living document. If you think of something that is not on this list bu
## Services
-- It's typically best to create a [service](/docs/concepts/services-networking/service/) before corresponding [replication controllers](/docs/concepts/workloads/controllers/replicationcontroller/). This lets the scheduler spread the pods that comprise the service.
-
- You can also use this process to ensure that at least one replica works before creating lots of them:
-
- 1. Create a replication controller without specifying replicas (this will set replicas=1);
- 2. Create a service;
- 3. Then scale up the replication controller.
+- It's typically best to create a [service](/docs/concepts/services-networking/service/) before the corresponding [replication controllers](/docs/concepts/workloads/controllers/replicationcontroller/). This lets the scheduler spread the pods that comprise the service.
- Don't use `hostPort` unless it is absolutely necessary (for example: for a node daemon). It specifies the port number to expose on the host. When you bind a Pod to a `hostPort`, there are a limited number of places to schedule a pod due to port conflicts— you can only schedule as many such Pods as there are nodes in your Kubernetes cluster.
diff --git a/docs/concepts/configuration/pod-priority-preemption.md b/docs/concepts/configuration/pod-priority-preemption.md
index ce30c79c67..9ee15dafbf 100644
--- a/docs/concepts/configuration/pod-priority-preemption.md
+++ b/docs/concepts/configuration/pod-priority-preemption.md
@@ -39,8 +39,7 @@ The following sections provide more information about these steps.
## Enabling priority and preemption
Pod priority and preemption is disabled by default in Kubernetes 1.8.
-To enable the feature, set this command-line flag for the API server
-and the scheduler:
+To enable the feature, set this command-line flag for the API server, scheduler and kubelet:
```
--feature-gates=PodPriority=true
diff --git a/docs/concepts/overview/working-with-objects/nginx-deployment.yaml b/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
index 8925d1b08d..4139bd1ac1 100644
--- a/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
+++ b/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
@@ -4,6 +4,9 @@ metadata:
name: nginx-deployment
spec:
replicas: 3
+ selector:
+ matchLabels:
+ app: nginx
template:
metadata:
labels:
diff --git a/docs/concepts/services-networking/service.md b/docs/concepts/services-networking/service.md
index 0adab1cfae..15ae7d2b9c 100644
--- a/docs/concepts/services-networking/service.md
+++ b/docs/concepts/services-networking/service.md
@@ -117,7 +117,7 @@ subsets:
- port: 9376
```
-NOTE: Endpoint IPs may not be loopback (127.0.0.0/8), link-local
+**NOTE:** Endpoint IPs may not be loopback (127.0.0.0/8), link-local
(169.254.0.0/16), or link-local multicast (224.0.0.0/24).
Accessing a `Service` without a selector works the same as if it had a selector.
@@ -151,13 +151,11 @@ its pods, add appropriate selectors or endpoints and change the service `type`.
Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
responsible for implementing a form of virtual IP for `Services` of type other
than `ExternalName`.
-In Kubernetes v1.0 the proxy was purely in userspace. In Kubernetes v1.1 an
-iptables proxy was added, but was not the default operating mode. Since
-Kubernetes v1.2, the iptables proxy is the default.
-
-As of Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct.
-In Kubernetes v1.1 the `Ingress` API was added (beta) to represent "layer 7"
-(HTTP) services.
+In Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct, the
+proxy was purely in userspace. In Kubernetes v1.1, the `Ingress` API was added
+(beta) to represent "layer 7"(HTTP) services, iptables proxy was added too,
+and become the default operating mode since Kubernetes v1.2. In Kubernetes v1.9-alpha,
+ipvs proxy was added.
### Proxy-mode: userspace
@@ -169,37 +167,20 @@ will be proxied to one of the `Service`'s backend `Pods` (as reported in
`SessionAffinity` of the `Service`. Lastly, it installs iptables rules which
capture traffic to the `Service`'s `clusterIP` (which is virtual) and `Port`
and redirects that traffic to the proxy port which proxies the backend `Pod`.
-
-The net result is that any traffic bound for the `Service`'s IP:Port is proxied
-to an appropriate backend without the clients knowing anything about Kubernetes
-or `Services` or `Pods`.
-
-By default, the choice of backend is round robin. Client-IP based session affinity
-can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
-default is `"None"`), and you can set the max session sticky time by setting the field
-`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` if you have already set
-`service.spec.sessionAffinity` to `"ClientIP"` (the default is "10800").
+By default, the choice of backend is round robin.
### Proxy-mode: iptables
In this mode, kube-proxy watches the Kubernetes master for the addition and
-removal of `Service` and `Endpoints` objects. For each `Service` it installs
+removal of `Service` and `Endpoints` objects. For each `Service`, it installs
iptables rules which capture traffic to the `Service`'s `clusterIP` (which is
virtual) and `Port` and redirects that traffic to one of the `Service`'s
-backend sets. For each `Endpoints` object it installs iptables rules which
-select a backend `Pod`.
+backend sets. For each `Endpoints` object, it installs iptables rules which
+select a backend `Pod`.By default, the choice of backend is random.
-By default, the choice of backend is random. Client-IP based session affinity
-can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
-default is `"None"`), and you can set the max session sticky time by setting the field
-`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` if you have already set
-`service.spec.sessionAffinity` to `"ClientIP"` (the default is "10800").
-
-As with the userspace proxy, the net result is that any traffic bound for the
-`Service`'s IP:Port is proxied to an appropriate backend without the clients
-knowing anything about Kubernetes or `Services` or `Pods`. This should be
+Obviously, iptables need not switch back between userspace and kernelspace, it should be
faster and more reliable than the userspace proxy. However, unlike the
userspace proxier, the iptables proxier cannot automatically retry another
`Pod` if the one it initially selects does not respond, so it depends on
@@ -231,12 +212,21 @@ options for load balancing algorithm, such as:
- nq: never queue
**Note:** ipvs mode assumed IPVS kernel modules are installed on the node
-before running kube-proxy. When kube-proxy starts, if proxy mode is ipvs,
+before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
kube-proxy would validate if IPVS modules are installed on the node, if
it's not installed kube-proxy will fall back to iptables proxy mode.
+In any of proxy model, any traffic bound for the Service’s IP:Port is
+proxied to an appropriate backend without the clients knowing anything
+about Kubernetes or Services or Pods. Client-IP based session affinity
+can be selected by setting service.spec.sessionAffinity to "ClientIP"
+(the default is "None"), and you can set the max session sticky time by
+setting the field service.spec.sessionAffinityConfig.clientIP.timeoutSeconds
+if you have already set service.spec.sessionAffinity to "ClientIP"
+(the default is “10800”).
+
## Multi-Port Services
Many `Services` need to expose more than one port. For this case, Kubernetes
@@ -727,6 +717,10 @@ work, and the client IP is not altered.
This same basic flow executes when traffic comes in through a node-port or
through a load-balancer, though in those cases the client IP does get altered.
+#### Ipvs
+
+Iptables operations slow down dramatically in large scale cluster e.g 10,000 Services. IPVS is designed for load balancing and based on in-kernel hash tables. So we can achieve performance consistency in large number of services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
+
## API Object
Service is a top-level resource in the Kubernetes REST API. More details about the
diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md
index 4dccc7bc75..aebe9c5cf6 100644
--- a/docs/concepts/storage/persistent-volumes.md
+++ b/docs/concepts/storage/persistent-volumes.md
@@ -54,7 +54,7 @@ dynamic provisioning for themselves.
To enable dynamic storage provisioning based on storage class, the cluster administrator
needs to enable the `DefaultStorageClass` [admission controller](/docs/admin/admission-controllers/#defaultstorageclass)
on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is
-among the comma-delimited, ordered list of values for the `--admission-control` flag of
+among the comma-delimited, ordered list of values for the `--admission-control` flag of
the API server component. For more information on API server command line flags,
please check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
@@ -417,8 +417,6 @@ spec:
`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
-``
-
## Writing Portable Configuration
If you're writing configuration templates or examples that run on a wide range of clusters
@@ -455,4 +453,3 @@ and need persistent storage, we recommend that you use the following pattern:
default.
At some point, the alpha annotation will cease to have meaning, but the unset
`storageClass` field on the PVC will have the desired effect.
-
diff --git a/docs/concepts/workloads/controllers/garbage-collection.md b/docs/concepts/workloads/controllers/garbage-collection.md
index b220a17cdd..2f83cc87ab 100644
--- a/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/docs/concepts/workloads/controllers/garbage-collection.md
@@ -40,7 +40,7 @@ If you create the ReplicaSet and then view the Pod metadata, you can see
OwnerReferences field:
```shell
-kubectl create -f https://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml
+kubectl create -f https://k8s.io/docs/concepts/controllers/my-repset.yaml
kubectl get pods --output=yaml
```
diff --git a/docs/home/contribute/style-guide.md b/docs/home/contribute/style-guide.md
index 4b5efb30bd..db330d32ab 100644
--- a/docs/home/contribute/style-guide.md
+++ b/docs/home/contribute/style-guide.md
@@ -18,6 +18,12 @@ docs, follow the instructions on
**Note:** Kubernetes documentation uses [GitHub Flavored Markdown](https://github.github.com/gfm/).
{: .note}
+
+## Language
+
+Kubernetes documentation uses US English.
+
+
## Documentation formatting standards
### Use camel case for API objects
diff --git a/docs/setup/independent/install-kubeadm.md b/docs/setup/independent/install-kubeadm.md
index 3a4c1536c2..b07895df7c 100644
--- a/docs/setup/independent/install-kubeadm.md
+++ b/docs/setup/independent/install-kubeadm.md
@@ -86,15 +86,21 @@ apt-get update
apt-get install -y docker.io
```
-or install Docker CE 17.03 from Docker's repositories for Ubuntu or Debian:
+or install Docker CE 17.09 from Docker's repositories for Ubuntu or Debian:
```bash
-apt-get update && apt-get install -y curl apt-transport-https
+apt-get update
+apt-get install -y \
+ apt-transport-https \
+ ca-certificates \
+ curl \
+ software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-cat </etc/apt/sources.list.d/docker.list
-deb https://download.docker.com/linux/$(lsb_release -si | tr '[:upper:]' '[:lower:]') $(lsb_release -cs) stable
-EOF
-apt-get update && apt-get install -y docker-ce=$(apt-cache madison docker-ce | grep 17.03 | head -1 | awk '{print $3}')
+add-apt-repository \
+ "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \
+ $(lsb_release -cs) \
+ stable"
+apt-get update && apt-get install -y docker-ce=$(apt-cache madison docker-ce | grep 17.09 | head -1 | awk '{print $3}')
```
{% endcapture %}
@@ -130,6 +136,9 @@ as Docker (e.g. `cgroupfs`).
{% include tabs.md %}
+Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
+for more information.
+
## Installing kubeadm, kubelet and kubectl
You will install these packages on all of your machines:
diff --git a/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
index bd9404a1b4..591bf441c9 100644
--- a/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
+++ b/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
@@ -38,7 +38,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
1. Create a Kubernetes service account in your namespace.
1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
1. Create a Kubernetes cluster role binding from the default service account in your namespace to the cluster role you just created.
-1. Create a Kubernetes apiservice. The CA cert above should be base 64 encoded, stripped of new lines and used as the spec.caBundle in the apiservce. This should not be namespaced.
+1. Create a Kubernetes apiservice. The CA cert above should be base 64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced.
1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
{% endcapture %}
diff --git a/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
index c84b56dad5..9a5d946da6 100644
--- a/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+++ b/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
@@ -17,7 +17,7 @@ can develop their features independantly from the core Kubernetes release cycles
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisifed.
-To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvier](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
+To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
## Developing
diff --git a/docs/tasks/administer-cluster/quota-api-object.md b/docs/tasks/administer-cluster/quota-api-object.md
index fd3fdd2236..978cc02037 100644
--- a/docs/tasks/administer-cluster/quota-api-object.md
+++ b/docs/tasks/administer-cluster/quota-api-object.md
@@ -67,7 +67,7 @@ status:
services.nodeports: "0"
```
-## Create a PersistentVolumeClaim:
+## Create a PersistentVolumeClaim
Here is the configuration file for a PersistentVolumeClaim object:
@@ -92,7 +92,7 @@ NAME STATUS
pvc-quota-demo Pending
```
-## Attempt to create a second PersistentVolumeClaim:
+## Attempt to create a second PersistentVolumeClaim
Here is the configuration file for a second PersistentVolumeClaim:
diff --git a/docs/tasks/configure-pod-container/configmap.md b/docs/tasks/configure-pod-container/configmap.md
index e77248b191..d31ea8f978 100644
--- a/docs/tasks/configure-pod-container/configmap.md
+++ b/docs/tasks/configure-pod-container/configmap.md
@@ -36,7 +36,9 @@ The data source corresponds to a key-value pair in the ConfigMap, where
* key = the file name or the key you provided on the command line, and
* value = the file contents or the literal value you provided on the command line.
-You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or [`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
+You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
+[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
+about a ConfigMap.
### Create ConfigMaps from directories
diff --git a/docs/tasks/debug-application-cluster/debug-application-introspection.md b/docs/tasks/debug-application-cluster/debug-application-introspection.md
index a149efba6f..917cc18d5a 100644
--- a/docs/tasks/debug-application-cluster/debug-application-introspection.md
+++ b/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -16,33 +16,12 @@ your pods. But there are a number of ways to get even more information about you
For this example we'll use a Deployment to create two pods, similar to the earlier example.
-```yaml
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
- name: nginx-deployment
-spec:
- replicas: 2
- template:
- metadata:
- labels:
- app: nginx
- spec:
- containers:
- - name: nginx
- image: nginx
- resources:
- limits:
- memory: "128Mi"
- cpu: "500m"
- ports:
- - containerPort: 80
-```
+{% include code.html language="yaml" file="nginx-dep.yaml" ghlink="/docs/tasks/debug-application-cluster/nginx-dep.yaml" %}
-Copy this to a file *./my-nginx-dep.yaml*
+Create deployment by running following command:
```shell
-$ kubectl create -f ./my-nginx-dep.yaml
+$ kubectl create -f https://k8s.io/docs/tasks/debug-application-cluster/nginx-dep.yaml
deployment "nginx-deployment" created
```
diff --git a/docs/concepts/abstractions/nginx-deployment.yaml b/docs/tasks/debug-application-cluster/nginx-dep.yaml
similarity index 57%
rename from docs/concepts/abstractions/nginx-deployment.yaml
rename to docs/tasks/debug-application-cluster/nginx-dep.yaml
index 2aabf5e7b1..9051645fbb 100644
--- a/docs/concepts/abstractions/nginx-deployment.yaml
+++ b/docs/tasks/debug-application-cluster/nginx-dep.yaml
@@ -1,9 +1,9 @@
-apiVersion: apps/v1beta1
+apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
- replicas: 3
+ replicas: 2
template:
metadata:
labels:
@@ -11,6 +11,10 @@ spec:
spec:
containers:
- name: nginx
- image: nginx:1.7.9
+ image: nginx
+ resources:
+ limits:
+ memory: "128Mi"
+ cpu: "500m"
ports:
- containerPort: 80
diff --git a/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
index a615cdbf25..a73e06f6fc 100644
--- a/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+++ b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
@@ -371,44 +371,35 @@ For more information see
## Adding a cluster to a federation
-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/)
-command. A new context will have been added to your kubeconfig named `fellowship`
-(after the name of your federation). To join clusters into the federation, you will
-need to change the context.
+After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage.
-```
-kubectl config use-context fellowship
-```
+To join clusters into the federation:
-To use `kubefed join`, you'll need to provide the name of the cluster
-you want to add to the federation, and the `--host-cluster-context`
-for the federation control plane's host cluster.
+1. Change the context:
-> Note: The name that you provide to the `join` command is used as the
-joining cluster's identity in federation. This name should adhere to
-the rules described in the
-[identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
-corresponding to your joining cluster conforms to these rules then you
-can use the same name in the join command. Otherwise, you will have to
-choose a different name for your cluster's identity. For more
-information, please see the
-[naming rules and customization](#naming-rules-and-customization)
-section below.
+ kubectl config use-context fellowship
-The following example command adds the cluster `gondor` to the
-federation running on host cluster `rivendell`:
+1. If you are using a managed cluster service, allow the service to access the cluster. To do this, create a `clusterrolebinding` for the account associated with your cluster service:
-```
-kubefed join gondor --host-cluster-context=rivendell
-```
+ kubectl create clusterrolebinding -cluster-admin-binding --clusterrole=cluster-admin --user=@example.org --context= Note: The name that you provide to the `join` command is used as the joining cluster's identity in federation. If this name adheres to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
+corresponding to your joining cluster conforms to these rules then you can use the same name in the join command. Otherwise, you will have to choose a different name for your cluster's identity.
-> Note: Kubernetes requires that you manually join clusters to a
-federation because the federation control plane manages only those
-clusters that it is responsible for managing. Adding a cluster tells
-the federation control plane that it is responsible for managing that
-cluster.
### Naming rules and customization
diff --git a/docs/tasks/inject-data-application/distribute-credentials-secure.md b/docs/tasks/inject-data-application/distribute-credentials-secure.md
index c85532fe86..b48f22ab97 100644
--- a/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -37,7 +37,7 @@ username and password:
1. Create the Secret
- kubectl create -f secret.yaml
+ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret.yaml
**Note:** If you want to skip the Base64 encoding step, you can create a Secret
by using the `kubectl create secret` command:
@@ -81,7 +81,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
- kubectl create -f secret-pod.yaml
+ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-pod.yaml
1. Verify that your Pod is running:
@@ -128,7 +128,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
- kubectl create -f secret-envars-pod.yaml
+ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-envars-pod.yaml
1. Verify that your Pod is running:
diff --git a/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml b/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
index 73d93312fa..0cf950c803 100644
--- a/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
+++ b/docs/tasks/inject-data-application/podpreset-allow-db-merged.yaml
@@ -10,7 +10,7 @@ metadata:
spec:
containers:
- name: website
- image: ecorp/website
+ image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
diff --git a/docs/tasks/inject-data-application/podpreset-allow-db.yaml b/docs/tasks/inject-data-application/podpreset-allow-db.yaml
index 96f6dbfe20..97203fdb9c 100644
--- a/docs/tasks/inject-data-application/podpreset-allow-db.yaml
+++ b/docs/tasks/inject-data-application/podpreset-allow-db.yaml
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
- namespace: myns
spec:
selector:
matchLabels:
diff --git a/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml b/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
index 9061b9f5e8..cf201b2f06 100644
--- a/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
+++ b/docs/tasks/inject-data-application/podpreset-conflict-pod.yaml
@@ -8,7 +8,7 @@ metadata:
spec:
containers:
- name: website
- image: ecorp/website
+ image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
diff --git a/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml b/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
index ab70b14d28..a2ad96c48a 100644
--- a/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
+++ b/docs/tasks/inject-data-application/podpreset-conflict-preset.yaml
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
- namespace: myns
spec:
selector:
matchLabels:
diff --git a/docs/tasks/inject-data-application/podpreset-merged.yaml b/docs/tasks/inject-data-application/podpreset-merged.yaml
index 0a5dfce0b5..97c022c86c 100644
--- a/docs/tasks/inject-data-application/podpreset-merged.yaml
+++ b/docs/tasks/inject-data-application/podpreset-merged.yaml
@@ -10,7 +10,7 @@ metadata:
spec:
containers:
- name: website
- image: ecorp/website
+ image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
diff --git a/docs/tasks/inject-data-application/podpreset-multi-merged.yaml b/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
index dd6a7197ef..7fcaae62e3 100644
--- a/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
+++ b/docs/tasks/inject-data-application/podpreset-multi-merged.yaml
@@ -11,7 +11,7 @@ metadata:
spec:
containers:
- name: website
- image: ecorp/website
+ image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
diff --git a/docs/tasks/inject-data-application/podpreset-pod.yaml b/docs/tasks/inject-data-application/podpreset-pod.yaml
index 82c590a924..b6b4e60d6e 100644
--- a/docs/tasks/inject-data-application/podpreset-pod.yaml
+++ b/docs/tasks/inject-data-application/podpreset-pod.yaml
@@ -8,7 +8,7 @@ metadata:
spec:
containers:
- name: website
- image: ecorp/website
+ image: nginx
ports:
- containerPort: 80
diff --git a/docs/tasks/inject-data-application/podpreset-preset.yaml b/docs/tasks/inject-data-application/podpreset-preset.yaml
index c5d34437f2..f300289c82 100644
--- a/docs/tasks/inject-data-application/podpreset-preset.yaml
+++ b/docs/tasks/inject-data-application/podpreset-preset.yaml
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
- namespace: myns
spec:
selector:
matchLabels:
diff --git a/docs/tasks/inject-data-application/podpreset-proxy.yaml b/docs/tasks/inject-data-application/podpreset-proxy.yaml
index 20dab81f36..d854475ac2 100644
--- a/docs/tasks/inject-data-application/podpreset-proxy.yaml
+++ b/docs/tasks/inject-data-application/podpreset-proxy.yaml
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: proxy
- namespace: myns
spec:
selector:
matchLabels:
diff --git a/docs/tasks/inject-data-application/podpreset.md b/docs/tasks/inject-data-application/podpreset.md
index d2571ab844..4368608690 100644
--- a/docs/tasks/inject-data-application/podpreset.md
+++ b/docs/tasks/inject-data-application/podpreset.md
@@ -20,18 +20,50 @@ You can get an overview of PodPresets at
This is a simple example to show how a Pod spec is modified by the Pod
Preset.
-**User submitted pod spec:**
+{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
+
+Create the PodPreset:
+
+```shell
+kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-preset.yaml
+```
+
+Examine the created PodPreset:
+
+```shell
+$ kubectl get podpreset
+NAME AGE
+allow-database 1m
+```
+
+The new PodPreset will act upon any pod that has label `role: frontend`.
{% include code.html language="yaml" file="podpreset-pod.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-pod.yaml" %}
-**Example Pod Preset:**
+Create a pod:
-{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
+```shell
+$ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-pod.yaml
+```
+
+List the running Pods:
+
+```shell
+$ kubectl get pods
+NAME READY STATUS RESTARTS AGE
+website 1/1 Running 0 4m
+```
**Pod spec after admission controller:**
{% include code.html language="yaml" file="podpreset-merged.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-merged.yaml" %}
+To see above output, run the following command:
+
+```shell
+$ kubectl get pod website -o yaml
+```
+
### Pod Spec with `ConfigMap` Example
This is an example to show how a Pod spec is modified by the Pod Preset
@@ -113,7 +145,7 @@ when there is a conflict.
**If we run `kubectl describe...` we can see the event:**
-```
+```shell
$ kubectl describe ...
....
Events:
diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md
index 5c07373bf3..7b7f1d0b4d 100644
--- a/docs/tutorials/stateful-application/zookeeper.md
+++ b/docs/tutorials/stateful-application/zookeeper.md
@@ -100,7 +100,7 @@ Open a command terminal, and use
manifest.
```shell
-kubectl apply -f https://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/docs/tutorials/stateful-application/zookeeper.yaml
```
This creates the `zk-hs` Headless Service, the `zk-cs` Service,
diff --git a/docs/user-guide/kubectl-overview.md b/docs/user-guide/kubectl-overview.md
index 923a99558e..5ae7485c5b 100644
--- a/docs/user-guide/kubectl-overview.md
+++ b/docs/user-guide/kubectl-overview.md
@@ -264,6 +264,17 @@ $ kubectl describe pods
$ kubectl describe pods --include-uninitialized=false
```
+**Note:** The `kubectl get` command is usually used for retrieving one or more
+resources of the same resource type. It features a rich set of flags that allows
+you to customize the output format using the `-o` or `--output` flag, for example.
+You can specify the `-w` or `--watch` flag to start watching updates to a particular
+object. The `kubectl describe` command is more focused on describing the many
+related aspects of a specified resource. It may invoke several API calls to the
+API server to build a view for the user. For example, the `kubectl describe node`
+command retrieves not only the information about the node, but also a summary of
+the pods running on it, the events generated for the node etc.
+{: .note}
+
`kubectl delete` - Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
```shell
diff --git a/docs/user-guide/walkthrough/index.md b/docs/user-guide/walkthrough/index.md
index c456638dac..20fd482271 100644
--- a/docs/user-guide/walkthrough/index.md
+++ b/docs/user-guide/walkthrough/index.md
@@ -97,8 +97,8 @@ volumes:
```yaml
volumeMounts:
- # name must match the volume name below
- - name: redis-persistent-storage
+ # name must match the volume name defined in volumes
+ - name: redis-persistent-storage
# mount path within the container
mountPath: /data/redis
```
diff --git a/images/KubeCon_NA_Community.jpg b/images/KubeCon_NA_Community.jpg
new file mode 100644
index 0000000000..ab046414be
Binary files /dev/null and b/images/KubeCon_NA_Community.jpg differ
diff --git a/images/square-logos/componentsoft.png b/images/square-logos/componentsoft.png
new file mode 100644
index 0000000000..cdd7b4d4dd
Binary files /dev/null and b/images/square-logos/componentsoft.png differ
diff --git a/images/square-logos/dataspine.png b/images/square-logos/dataspine.png
new file mode 100644
index 0000000000..95ab24a311
Binary files /dev/null and b/images/square-logos/dataspine.png differ
diff --git a/images/square-logos/isotoma.png b/images/square-logos/isotoma.png
new file mode 100644
index 0000000000..b1ac23d905
Binary files /dev/null and b/images/square-logos/isotoma.png differ
diff --git a/images/square-logos/objectcomputing.png b/images/square-logos/objectcomputing.png
new file mode 100644
index 0000000000..622e6b98a6
Binary files /dev/null and b/images/square-logos/objectcomputing.png differ
diff --git a/images/square-logos/redzara.png b/images/square-logos/redzara.png
new file mode 100644
index 0000000000..4aa3b9bbbe
Binary files /dev/null and b/images/square-logos/redzara.png differ
diff --git a/images/square-logos/servian.png b/images/square-logos/servian.png
new file mode 100644
index 0000000000..aeaaa58a21
Binary files /dev/null and b/images/square-logos/servian.png differ
diff --git a/images/square-logos/vexxhost.png b/images/square-logos/vexxhost.png
new file mode 100644
index 0000000000..c7060c021c
Binary files /dev/null and b/images/square-logos/vexxhost.png differ
diff --git a/index.html b/index.html
index a3f73aaac3..cf22d1e40c 100644
--- a/index.html
+++ b/index.html
@@ -64,7 +64,7 @@ cid: home
- Attend KubeCon in Austin, TX on December 6-8, 2017 + Attend KubeCon in Austin, TX on December 6-8, 2017
- Attend KubeCon in Austin, TX on December 6-8, 2017 + Attend KubeCon in Austin, TX on December 6-8, 2017