diff --git a/OWNERS b/OWNERS index f1cef0b5bb..ec534bfbfb 100644 --- a/OWNERS +++ b/OWNERS @@ -1,6 +1,3 @@ -approvers: -- smarterclayton -- janetkuo -- pwittrock -- kelseyhightower -- jaredbhatti +reviewers: +- chenopis +- zacharysarah diff --git a/_data/tutorials.yml b/_data/tutorials.yml index 3989024606..479135958e 100644 --- a/_data/tutorials.yml +++ b/_data/tutorials.yml @@ -29,8 +29,11 @@ toc: section: - docs/tutorials/kubernetes-basics/update-intro.html - docs/tutorials/kubernetes-basics/update-interactive.html -- title: Online Training Course +- title: Online Training Courses + section: Scalable Microservices with Kubernetes (Udacity) path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615 + section: Introduction to Kubernetes (edX) + path: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x# - docs/tutorials/stateless-application/hello-minikube.md - title: Configuration section: @@ -61,4 +64,3 @@ toc: - title: Services section: - docs/tutorials/services/source-ip.md - diff --git a/docs/concepts/architecture/master-node-communication.md b/docs/concepts/architecture/master-node-communication.md index a650cc9a3a..c94a4e8aed 100644 --- a/docs/concepts/architecture/master-node-communication.md +++ b/docs/concepts/architecture/master-node-communication.md @@ -77,7 +77,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificates bundle to use to verify the kubelet's serving certificate. -If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels) +If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an untrusted or public network. diff --git a/docs/concepts/overview/working-with-objects/namespaces.md b/docs/concepts/overview/working-with-objects/namespaces.md index a16ae8e1cd..0f66878964 100644 --- a/docs/concepts/overview/working-with-objects/namespaces.md +++ b/docs/concepts/overview/working-with-objects/namespaces.md @@ -82,7 +82,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN). ## Not All Objects are in a Namespace Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are -in some namespace. However namespace resources are not themselves in a namespace. +in some namespaces. However namespace resources are not themselves in a namespace. And low-level resources, such as [nodes](/docs/admin/node) and persistentVolumes, are not in any namespace. Events are an exception: they may or may not have a namespace, depending on the object the event is about. diff --git a/docs/concepts/services-networking/connect-applications-service.md b/docs/concepts/services-networking/connect-applications-service.md index c9ba693510..bca732ac0b 100644 --- a/docs/concepts/services-networking/connect-applications-service.md +++ b/docs/concepts/services-networking/connect-applications-service.md @@ -101,7 +101,7 @@ Kubernetes supports 2 primary modes of finding a Service - environment variables ### Environment Variables -When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different): +When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different): ```shell $ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE diff --git a/docs/concepts/workloads/controllers/daemonset.md b/docs/concepts/workloads/controllers/daemonset.md index 57b67447ae..ce48aa5213 100644 --- a/docs/concepts/workloads/controllers/daemonset.md +++ b/docs/concepts/workloads/controllers/daemonset.md @@ -93,7 +93,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`](/docs/admin/node/#manual-node-administration) field of a node is not respected + - The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected by the DaemonSet controller. - DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster bootstrap. diff --git a/docs/concepts/workloads/controllers/statefulset.md b/docs/concepts/workloads/controllers/statefulset.md index d45c44412a..7f017a0bef 100644 --- a/docs/concepts/workloads/controllers/statefulset.md +++ b/docs/concepts/workloads/controllers/statefulset.md @@ -94,10 +94,9 @@ spec: volumeClaimTemplates: - metadata: name: www - annotations: - volume.beta.kubernetes.io/storage-class: anything spec: accessModes: [ "ReadWriteOnce" ] + storageClassName: my-storage-class resources: requests: storage: 1Gi @@ -143,7 +142,8 @@ Note that Cluster Domain will be set to `cluster.local` unless Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume -with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled +with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass +is specified, then the default StorageClass will be used. When a Pod is (re)scheduled onto a node, its `volumeMounts` mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. diff --git a/docs/concepts/workloads/pods/init-containers.md b/docs/concepts/workloads/pods/init-containers.md index aa2d4a634a..4eb2fe796e 100644 --- a/docs/concepts/workloads/pods/init-containers.md +++ b/docs/concepts/workloads/pods/init-containers.md @@ -83,7 +83,7 @@ Here are some ideas for how to use Init Containers: * Wait for some time before starting the app Container with a command like `sleep 60`. * Clone a git repository into a volume. * Place values into a configuration file and run a template tool to dynamically - generate a configuration file for the the main app Container. For example, + generate a configuration file for the main app Container. For example, place the POD_IP value in a configuration and generate the main app configuration file using Jinja. diff --git a/docs/getting-started-guides/kubespray.md b/docs/getting-started-guides/kubespray.md index 6bf2fd66e9..eee97f6a2a 100644 --- a/docs/getting-started-guides/kubespray.md +++ b/docs/getting-started-guides/kubespray.md @@ -4,94 +4,102 @@ title: Installing Kubernetes On-premises/Cloud Providers with Kubespray ## Overview -This quickstart helps to install a Kubernetes cluster hosted -on GCE, Azure, OpenStack, AWS or Baremetal with -[`Kubespray`](https://github.com/kubernetes-incubator/kubespray) tool. +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, -[inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md) -generation CLI tools and domain knowledge for generic OS/Kubernetes -clusters configuration management tasks. It provides: +Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: -* [High available cluster](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md) -* [Composable](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md) - (Choice of the network plugin, for instance) -* Support most popular Linux - [distributions](https://github.com/kubernetes-incubator/kubespray#supported-linux-distributions) -* Continuous integration tests +* a highly available cluster +* composable attributes +* support for most popular Linux distributions +* continuous integration tests -To choose a tool which fits your use case the best, you may want to read this -[comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) -to [kubeadm](../kubeadm) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](../kubeadm) and [kops](../kops). ## Creating a cluster -### (1/4) Ensure the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements) are met +### (1/5) Meet the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements) -#### Checklist +Provision servers with the following requirements: -* You must have cloud instances or baremetal nodes running for your future Kubernetes cluster. - A way to achieve that is to use the - [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md). -* Or provision baremetal hosts with a tool-of-your-choice or launch cloud instances, - then create an inventory file for Ansible with this [tool](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py). +* `Ansible v2.3` (or newer) +* `Jinja 2.9` (or newer) +* `python-netaddr` installed on the machine that running Ansible commands +* Target servers must have access to the Internet in order to pull docker images +* Target servers are configured to allow IPv4 forwarding +* Target servers have SSH connectivity ( tcp/22 ) directly to your nodes or through a bastion host/ssh jump box +* Target servers have a privileged user +* Your SSH key must be copied to all the servers that are part of your inventory +* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate +* If using a cloud provider, you must have the appropriate credentials available and exported as environment variables -### (2/4) Compose the deployment +Kubespray provides the following utilities to help provision your environment: -#### Checklist +* [Terraform](https://www.terraform.io/) scripts for the following cloud providers: + * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws) + * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws) +* [kubespray-cli](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md) -* Customize your deployment by usual Ansible meanings, which is - [generating inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory) - and overriding default data [variables](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md). - Or just stick with default values (Kubespray will choose Calico networking plugin for you - then). This includes steps like deciding on the: - * DNS [configuration options](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md) - * [Networking plugin](https://github.com/kubernetes-incubator/kubespray#network-plugins) to use - * [Versions](https://github.com/kubernetes-incubator/kubespray#versions-of-supported-components) - of components. - * Additional node groups like [bastion hosts](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md#bastion-host) or - [Calico BGP route reflectors](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/calico.md#optional--bgp-peering-with-border-routers). -* Plan custom deployment steps, if any, or use the default composition layer in the - [cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml). - Taking the best from Ansible world, Kubespray allows users to execute arbitrary steps via the - ``ansible-playbook`` with given inventory, playbooks, data overrides and tags, limits, batches - of nodes to deploy and so on. -* For large deployments (100+ nodes), you may want to - [tweak things](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) - for best results. +**Note:** kubespray-cli is no longer actively maintained. +{. :note} -### (3/4) Run the deployment +### (2/5) Compose an inventory file -#### Checklist +After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". -* Apply deployment with - [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md) - or ``ansible-playbook`` - [manual commands](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). +### (3/5) Plan your cluster deployment -### (4/4) (Optional) verify inter-pods connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md) +Kubespray provides the ability to customize many aspects of the deployment: -#### Checklist +* CNI (networking) plugins +* DNS configuration +* Choice of control plane: native/binary or containerized with docker or rkt) +* Component versions +* Calico route reflectors +* Component runtime options +* Certificate generation methods -* Ensure the netchecker-agent's pods can resolve DNS requests and ping each over within the default namespace. - Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. +Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. -## Explore contributed add-ons +### (4/5) Deploy a Cluster -See the [list of contributed playbooks](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib) -to explore other deployment options. +Next, deploy your cluster with one of two methods: + +* [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). +* [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md) + +**Note:** kubespray-cli is no longer actively maintained. +{. :note} + +Both methods run the default [cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml). + +Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results. + +### (5/5) Verify the deployment + +Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators. + +## Cluster operations + +Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_. + +### Scale your cluster + +You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#Adding-nodes)". + +### Upgrade your cluster + +You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". ## What's next -Kubespray has quite a few [marks on the radar](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). +Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). ## Cleanup -To delete your scratch cluster, you can apply the -[reset role](https://github.com/kubernetes-incubator/kubespray/blob/master/roles/reset/tasks/main.yml) -with the manual ``ansible-playbook`` command. +You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml). -Note, that it is highly unrecommended to delete production clusters with the reset playbook! +**Caution:** When running the reset playbook, be sure not to accidentally target your production cluster! +{. :caution} ## Feedback diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md index bb189a922a..a01d2efad8 100644 --- a/docs/getting-started-guides/mesos/index.md +++ b/docs/getting-started-guides/mesos/index.md @@ -228,13 +228,16 @@ Note that we have passed these two values already as parameter to the apiserver A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/kubedns-controller.yaml.in][12] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: -- replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1` -- replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.` +{% assign dns_replicas = "{{ pillar['dns_replicas'] }}" %} +{% assign dns_domain = "{{ pillar['dns_domain'] }}" %} +- replace `{{ dns_replicas }}` with `1` +- replace `{{ dns_domain }}` with `cluster.local.` - add `--kube_master_url=${KUBERNETES_MASTER}` parameter to the kube2sky container command. In addition the service template at [cluster/addons/dns/kubedns-controller.yaml.in][12] needs the following replacement: -- `{% raw %}{{ pillar['dns_server'] }}{% endraw %}` with `10.10.10.10`. +{% assign dns_server = "{{ pillar['dns_server'] }}" %} +- `{{ dns_server }}` with `10.10.10.10`. To do this automatically: diff --git a/docs/getting-started-guides/ubuntu/upgrades.md b/docs/getting-started-guides/ubuntu/upgrades.md index 52bb1bdd80..d065993f28 100644 --- a/docs/getting-started-guides/ubuntu/upgrades.md +++ b/docs/getting-started-guides/ubuntu/upgrades.md @@ -40,7 +40,7 @@ The Kubernetes Charms use snap channels to drive payloads. The channels are defi | beta | Latest alpha or beta of Kubernetes for that minor release | | edge | Nightly builds of that minor release of Kubernetes | -If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availablility of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms. +If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availability of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms. ## Master Upgrades diff --git a/docs/home/contribute/review-issues.md b/docs/home/contribute/review-issues.md index d6cc0bdb01..815edff9c9 100644 --- a/docs/home/contribute/review-issues.md +++ b/docs/home/contribute/review-issues.md @@ -55,7 +55,7 @@ The following labels and definitions should be used to prioritize issues. If you ## Handling special issue types ### Duplicate issues -If a single problem has one or more issues open for it, the problem should be consolodated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem. +If a single problem has one or more issues open for it, the problem should be consolidated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem. ### Dead link issues Depending on where the dead link is reported, different actions are required to resolve the issue. Dead links in the API and Kubectl docs are automation issues and should be assigned a P1 until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned a P3. diff --git a/docs/home/contribute/style-guide.md b/docs/home/contribute/style-guide.md index 8b214458d4..594b5eb5b5 100644 --- a/docs/home/contribute/style-guide.md +++ b/docs/home/contribute/style-guide.md @@ -231,7 +231,7 @@ I didn't read the stlye guide. ### Ordered Lists -Callouts will interupt numbered lists unless you indent three spaces before the notice and the tag. +Callouts will interrupt numbered lists unless you indent three spaces before the notice and the tag. For example: diff --git a/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md b/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md index c7e09287bd..f66eb69396 100644 --- a/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md +++ b/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md @@ -127,7 +127,7 @@ $ kubectl get crontab -o json "uid": "6f65e7a3-8601-11e6-a23e-42010af0000c" } } - ] + ], "kind": "List", "metadata": {}, "resourceVersion": "", diff --git a/docs/tasks/administer-cluster/encrypt-data.md b/docs/tasks/administer-cluster/encrypt-data.md index dc0889295a..9a6e596e9b 100644 --- a/docs/tasks/administer-cluster/encrypt-data.md +++ b/docs/tasks/administer-cluster/encrypt-data.md @@ -148,7 +148,7 @@ program to retrieve the contents of your secret. Since secrets are encrypted on write, performing an update on a secret will encrypt that content. ``` -kubectl get secrets -o json | kubectl replace -f - +kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` The command above reads all secrets and then updates them to apply server side encryption. diff --git a/docs/tasks/administer-cluster/weave-network-policy.md b/docs/tasks/administer-cluster/weave-network-policy.md index cc4111c208..85537e93f3 100644 --- a/docs/tasks/administer-cluster/weave-network-policy.md +++ b/docs/tasks/administer-cluster/weave-network-policy.md @@ -26,9 +26,89 @@ The Weave Net Addon for Kubernetes comes with a [Network Policy Controller](http {% endcapture %} +{% capture example %} + +## Namespace isolation example + +1. Create a namespace with `DefaultDeny`. + +```yaml +kind: Namespace +apiVersion: v1 +metadata: + name: myns + annotations: + net.beta.kubernetes.io/network-policy: | + { + "ingress": { + "isolation": "DefaultDeny" + } + } +``` + +2. Create 2 pods inside this namespace. + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: pod1 + namespace: myns + labels: + inns: "yes" +spec: + containers: + - name: pod1 + image: nginx +--- +kind: Pod +apiVersion: v1 +metadata: + name: pod2 + namespace: myns + labels: + inns: "yes" +spec: + containers: + - name: pod2 + image: nginx +``` + +3. Get the IP addresses of the pods. + +```shell +kubectl get po -n myns -o wide +``` +**Note:** If your cURL requests to pods are forbidden, try making cURL requests to other pods from within a pod. +{: .note} + +4. Create a Kubernetes NetworkPolicy that allows pods within the same namespace to connect with each other. + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: aaa + namespace: myns +spec: + podSelector: + matchExpressions: + - {key: inns, operator: In, values: ["yes"]} + ingress: + - from: + - podSelector: + matchExpressions: + - {key: inns, operator: In, values: ["yes"]} +``` +**Caution:** After applying the network policy, pods outside the namespace you specify may be unable to connect with pods inside the namespace. +{. :caution} + +{% endcapture %} + + {% capture whatsnext %} -Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. +Once you have installed the Weave Net addon, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. {% endcapture %} diff --git a/docs/tasks/configure-pod-container/configmap.md b/docs/tasks/configure-pod-container/configmap.md index 8f84bbdb08..508f32e2e3 100644 --- a/docs/tasks/configure-pod-container/configmap.md +++ b/docs/tasks/configure-pod-container/configmap.md @@ -223,7 +223,7 @@ metadata: ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap. -Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the a Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. +Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index 4dc47cc5a6..088090f415 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -136,7 +136,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure. You can see the source code for the server in -[server.go](http://k8s.io/docs/user-guide/liveness/image/server.go). +[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go). For the first 10 seconds that the Container is alive, the `/healthz` handler returns a status of 200. After that, the handler returns a status of 500. diff --git a/docs/tasks/configure-pod-container/configure-pod-configmap.md b/docs/tasks/configure-pod-container/configure-pod-configmap.md index e4c523d33f..9abe97e560 100644 --- a/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -234,7 +234,7 @@ special.level special.type ``` -### Add ConfigMap data to a specific path in the Volume: +### Add ConfigMap data to a specific path in the Volume Use the `path` field to specify the desired file path for specific ConfigMap items. In this case, the `special.level` item will be mounted in the `config-volume` volume at `/etc/config/keys`. diff --git a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 02c11adff2..159426e29e 100644 --- a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -50,7 +50,7 @@ Here is a video showing how to setup and run a Google Cloud Monitoring backed He [![how to setup and run a Google Cloud Monitoring backed Heapster](http://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](http://www.youtube.com/watch?v=xSMNR2fcoLs) -Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wide resource usage. +Here is a snapshot of the Google Cloud Monitoring dashboard showing cluster-wide resource usage. ![Google Cloud Monitoring dashboard](/images/docs/gcm.png) diff --git a/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/docs/tasks/federation/set-up-cluster-federation-kubefed.md index 4df407f4a0..cf74b87eef 100644 --- a/docs/tasks/federation/set-up-cluster-federation-kubefed.md +++ b/docs/tasks/federation/set-up-cluster-federation-kubefed.md @@ -67,9 +67,9 @@ kubefed is available as a [snap](https://snapcraft.io/) application. 1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with: - sudo snap install kubefed --classic + sudo snap install kubefed --classic -2. Run `kubefed version` to verify that the verison you've installed is sufficiently up-to-date. +2. Run `kubefed version` to verify that the version you've installed is sufficiently up-to-date. ## Choosing a host cluster. @@ -422,7 +422,7 @@ in the federation don't follow In such cases, you can specify a cluster name that conforms to the [RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules and specify the cluster context using the `--cluster-context` flag. -For example, if context of the cluster your are joining is +For example, if context of the cluster you are joining is `gondor_needs-no_king`, then you can join the cluster by running: ```shell diff --git a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index ac47ca09d4..b44baa485f 100644 --- a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -60,8 +60,8 @@ We may check the current status of autoscaler by running: ```shell $ kubectl get hpa -NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE -php-apache Deployment/php-apache/scale 50% 0% 1 10 18s +NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s ``` @@ -85,8 +85,8 @@ Within a minute or so, we should see the higher CPU load by executing: ```shell $ kubectl get hpa -NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE -php-apache Deployment/php-apache/scale 50% 305% 1 10 3m +NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m ``` @@ -114,8 +114,8 @@ Then we will verify the result state (after a minute or so): ```shell $ kubectl get hpa -NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE -php-apache Deployment/php-apache/scale 50% 0% 1 10 11m +NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m $ kubectl get deployment php-apache NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE diff --git a/docs/tools/kompose/user-guide.md b/docs/tools/kompose/user-guide.md index 3135dcdd0b..1a54860bba 100644 --- a/docs/tools/kompose/user-guide.md +++ b/docs/tools/kompose/user-guide.md @@ -30,7 +30,7 @@ file "redis-deployment.yaml" created ## Installation -We have multiple ways to install Kompose. Our prefered method is downloading the binary from the latest GitHub release. +We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release. ### GitHub release diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index 9f48c6b9ea..e0a9b24d95 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -9,7 +9,9 @@ each of which has a sequence of steps. * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features. -* [Online Training Course](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) + +* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md index fa226b11b1..315e2a471b 100644 --- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md +++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md @@ -484,7 +484,7 @@ TODO(1.6): For 1.6, add the following bullet point to 1. ### How different types of fields are merged How a particular field in a configuration file is merged with -with the live configuration depends on the +the live configuration depends on the type of the field. There are several types of fields: - *primitive*: A field of type string, integer, or boolean.