Merge remote-tracking branch 'origin' into release-1.12

content/en/blog/_posts/2018-09-06-2018-steering-committee-election-cycle-kicks-off.md

@@ -0,0 +1,36 @@
+---
+layout: blog
+title:  '2018 Steering Committee Election Cycle Kicks Off'
+date:   2018-09-06
+---
+
+**Author**: Paris Pittman (Google), Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF)
+
+Having a clear, definable governance model is crucial for the health of open source projects. For one of the highest velocity projects in the open source world, governance is critical especially for one as large and active as Kubernetes, which is one of the most high-velocity projects in the open source world. A clear structure helps users trust that the project will be nurtured and progress forward. Initially, this structure was laid by the former 7 member bootstrap committee composed of founders and senior contributors with a goal to create the foundational governance building blocks.  
+
+The [initial charter](https://git.k8s.io/steering/charter.md) and establishment of an election process to seat a full Steering Committee was a part of those first building blocks. Last year, the bootstrap committee [kicked off](https://groups.google.com/d/msg/kubernetes-dev/piPuoqFkJwA/mCjwLH81BgAJ) the first Kubernetes Steering Committee election which brought forth 6 new members from the community as voted on by contributors. These new members plus the bootstrap committee formed the [Steering Committee that we know today](https://github.com/kubernetes/steering). This yearly election cycle will continue to ensure that new representatives get cycled through to add different voices and thoughts on the Kubernetes project strategy.
+
+The committee has worked hard on topics that will streamline the project and how we operate. SIG (Special Interest Group) governance was an overarching recurring theme this year: Kubernetes community is not a monolithic organization, but a huge, distributed community, where [Special Interest Groups (SIGs) and Working Groups (WGs)](https://github.com/kubernetes/community/blob/master/sig-list.md) are the atomic community units, that are making Kubernetes so successful from the ground.
+
+### Contributors - this is where you come in.
+
+There are three seats up for election this year. The [voters guide](https://git.k8s.io/community/events/elections/2018) will get you up to speed on the specifics of this years election including candidate bios as they are updated in real time. The [elections process doc](https://github.com/kubernetes/steering/blob/master/elections.md) will steer you towards eligibility, operations, and the fine print.
+
+1) Nominate yourself, someone else, and/or put your support to others.
+
+Want to help chart our course? Interested in governance and community topics? Add your name! _The nomination process is optional_.
+
+2) Vote.
+
+On September 19th, eligible voters will receive an email poll invite conducted by [CIVS](https://civs.cs.cornell.edu). The newly elected will be announced at the [weekly community meeting](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) on Thursday, October 4th at 5pm UTC.
+
+To those who are running:
+
+<img src="/images/blog/2018-09-06-2018-steering-committee-election-cycle-kicks-off/sc-elections.png" width="400">
+
+### Helpful resources
+
+* [Steering Committee](https://github.com/kubernetes/steering) - who sits on the committee and terms, their projects and meetings info  
+* [Steering Committee Charter](https://git.k8s.io/steering/charter.md) - this is a great read if you’re interested in running (or assessing for the best candidates!)
+* [Election Process](https://git.k8s.io/steering/elections.md)
+* [Voters Guide!](https://git.k8s.io/community/events/elections/2018) - Updated on a rolling basis. This guide will always have the latest information throughout the election cycle. The complete schedule of events and candidate bios will be housed here.

content/en/case-studies/adform/index.html

@@ -5,9 +5,9 @@ case_study_styles: true
 cid: caseStudies
 css: /css/style_case_studies.css
 logo: adform_featured_logo.png
-draft: true
+draft: false
 featured: true
-weight: 1
+weight: 47
 quote: >
   Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
 ---

content/en/case-studies/homeoffice/index.html

@@ -1,4 +1,4 @@
 ---
-title: UK Home Office
+title: Home Office UK
 content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU
 ---

content/en/case-studies/ing/index.html

@@ -3,7 +3,7 @@ title: ING Case Study
 linkTitle: ING
 case_study_styles: true
 cid: caseStudies
-weight: 20
+weight: 50
 featured: true
 css: /css/style_case_studies.css
 quote: >

content/en/case-studies/pearson/index.html

@@ -4,7 +4,7 @@ linkTitle: Pearson
 case_study_styles: true
 cid: caseStudies
 css: /css/style_case_studies.css
-featured: true
+featured: false
 quote: >
   We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
 ---

content/en/case-studies/pinterest/index.html

@@ -4,7 +4,7 @@ linkTitle: Pinterest
 case_study_styles: true
 cid: caseStudies
 css: /css/style_case_studies.css
-featured: true
+featured: false
 weight: 30
 quote: >
   We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do.

content/en/case-studies/slingtv/index.html

@@ -5,7 +5,7 @@ case_study_styles: true
 cid: caseStudies
 css: /css/style_case_studies.css
 featured: true
-weight: 10
+weight: 49
 quote: >
   I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.
 ---

content/en/case-studies/ygrene/index.html

@@ -7,7 +7,7 @@ cid: caseStudies
 css: /css/style_case_studies.css
 logo: ygrene_featured_logo.png
 featured: true
-weight: 2
+weight: 48
 quote: >
   We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
 ---

content/en/docs/concepts/cluster-administration/cloud-providers.md

@@ -320,3 +320,18 @@ Note that the Kubernetes Node name must match the Photon VM name (or if `overrid
 ### Node Name
 
 The VSphere cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
+
+## IBM Cloud Kubernetes Service 
+
+### Compute nodes
+By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://console.bluemix.net/docs/containers/cs_clusters_planning.html#plan_clusters).
+
+The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance. 
+
+### Networking
+The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://console.bluemix.net/docs/containers/cs_network_cluster.html#planning).
+
+To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Planning to expose your apps with external networking](https://console.bluemix.net/docs/containers/cs_network_planning.html#planning).
+
+### Storage
+The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://console.bluemix.net/docs/containers/cs_storage_planning.html#storage_planning).

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -161,7 +161,7 @@ cluster when they should use this PriorityClass.
 ### Example PriorityClass
 
 ```yaml
-apiVersion: scheduling.k8s.io/v1alpha1
+apiVersion: scheduling.k8s.io/v1beta1
 kind: PriorityClass
 metadata:
   name: high-priority

content/en/docs/concepts/containers/images.md

@@ -47,6 +47,7 @@ Credentials can be provided in several ways:
     - use IAM roles and policies to control access to ECR repositories
     - automatically refreshes ECR login credentials
   - Using Azure Container Registry (ACR)
+  - Using IBM Cloud Container Registry
   - Configuring Nodes to Authenticate to a Private Registry
     - all pods can read any configured private registries
     - requires node configuration by cluster administrator
@@ -55,6 +56,7 @@ Credentials can be provided in several ways:
     - requires root access to all nodes to setup
   - Specifying ImagePullSecrets on a Pod
     - only pods which provide own keys can access the private registry
+
 Each option is described in more detail below.
 
 
@@ -127,6 +129,12 @@ Once you have created your container registry, you will use the following creden
 Once you have those variables filled in you can
 [configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
 
+### Using IBM Cloud Container Registry
+IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your Docker images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can create a token to grant access to registry namespaces.
+
+To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://console.bluemix.net/docs/services/Registry/index.html#index).
+
+You can use the IBM Cloud Container Registry to deploy containers from [IBM Cloud public images](https://console.bluemix.net/docs/services/RegistryImages/index.html#ibm_images) and your private images into the `default` namespace of your IBM Cloud Kubernetes Service cluster. To deploy a container into other namespaces, or to use an image from a different IBM Cloud Container Registry region or IBM Cloud account, create a Kubernetes `imagePullSecret`. For more information, see [Building containers from images](https://console.bluemix.net/docs/containers/cs_images.html#images).
 
 ### Configuring Nodes to Authenticate to a Private Registry
 
@@ -347,5 +355,3 @@ common use cases and suggested solutions.
    - The tenant adds that secret to imagePullSecrets of each namespace.
 
 {{% /capture %}}
-
-

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -148,7 +148,7 @@ For examples of device plugin implementations, see:
 * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
 * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
 * The [SRIOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
-* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU and FPGA devices
+* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU, FPGA and QuickAssist devices
 
 {{% /capture %}}
 

content/en/docs/concepts/storage/storage-limits.md

@@ -65,11 +65,12 @@ volumes for the node. For example:
 
 * On
 <a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
-up to 128 volumes could be attached to a node, depending on the node type. 
+up to 128 volumes can be attached to a node, [depending on the node
+type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
 
-* For Amazon EBS disks on M5/C5 instance types, Kubernetes would permit only 25
+* For Amazon EBS disks on M5/C5 instance types, Kubernetes allows only 25
 volumes to be attached to a node. For other instance types on
 <a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
-Kubernetes would permit 39 volumes to be attached.
+Kubernetes allows 39 volumes to be attached to a node.
 
 {{% /capture %}}

content/en/docs/concepts/workloads/controllers/daemonset.md

@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
 - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
 - running a logs collection daemon on every node, such as `fluentd` or `logstash`.
 - running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
-  https://github.com/prometheus/node_exporter), `collectd`, Datadog agent, New Relic agent, or Ganglia `gmond`.
+  https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, or Ganglia `gmond`.
 
 In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
 A more complex setup might use multiple DaemonSets for a single type of daemon, but with

content/en/docs/reference/access-authn-authz/authentication.md

@@ -548,7 +548,8 @@ extra:
 
 In order to prevent header spoofing, the authenticating proxy is required to present a valid client
 certificate to the API server for validation against the specified CA before the request headers are
-checked.
+checked. WARNING: do **not** reuse a CA that is used in a different context unless you understand
+the risks and the mechanisms to protect the CA's usage.
 
 * `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
 * `--requestheader-allowed-names` Optional.  List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.

content/en/docs/reference/access-authn-authz/rbac.md

@@ -452,6 +452,16 @@ Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authoriz
 
 ### Discovery Roles
 
+Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible. To disable anonymous unauthenticated access add `--anonymous-auth=false` to the API server configuration.
+
+To view the configuration of these roles via `kubectl` run:
+
+```
+kubectl get clusterroles system:discovery -o yaml
+```
+
+NOTE: editing the role is not recommended as changes will be overwritten on API server restart via auto-reconciliation (see above).
+
 <table>
 <colgroup><col width="25%"><col width="25%"><col></colgroup>
 <tr>

content/en/docs/reference/command-line-tools-reference/kube-apiserver.md

@@ -759,7 +759,7 @@ kube-apiserver [flags]
       <td colspan="2">--requestheader-client-ca-file string</td>
     </tr>
     <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: do **not** reuse a CA that is used in a different context (for example with --client-ca-file) unless you understand the risks and the mechanisms to protect the CA's usage. Generally it is recommended to not depend on authorization being already done for incoming requests.</td>
     </tr>
 
     <tr>

content/en/docs/setup/pick-right-solution.md

@@ -216,6 +216,7 @@ any                  | RKE          | multi-support    | flannel or canal
 any                  | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
 Alibaba Cloud Container Service For Kubernetes | ROS        | CentOS | flannel/Terway       | [docs](https://www.aliyun.com/product/containerservice)                    |  Commercial
 Agile Stacks       | Terraform   | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
+IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial 
 
 
 {{< note >}}

content/en/docs/setup/salt.md

@@ -1,120 +0,0 @@
----
-reviewers:
-- davidopp
-title: Configuring Kubernetes with Salt
-weight: 70
-content_template: templates/concept
----
-
-{{% capture overview %}}
-
-The Kubernetes cluster can be configured using Salt.
-
-The Salt scripts are shared across multiple hosting providers and depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
-
-{{% /capture %}}
-
-{{% capture body %}}
-
-## Salt cluster setup
-
-The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others).
-
-The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster.
-
-Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others).
-
-```shell
-cat /etc/salt/minion.d/master.conf
-```
-
-```none
-master: kubernetes-master
-```
-
-The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes.
-
-If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master.  It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
-
-## Standalone Salt Configuration on GCE and others
-
-On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state.
-
-All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes.
-
-## Salt security
-
-*(Not applicable on default GCE and OpenStack-Heat setup.)*
-
-Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions.  It is not recommended to use this security configuration in production environments without deeper study.  (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
-
-```shell
-cat /etc/salt/master.d/auto-accept.conf
-```
-
-```shell
-open_mode: True
-auto_accept: True
-```
-
-## Salt minion configuration
-
-Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.
-
-An example file is presented below using the Vagrant based environment.
-
-```shell
-cat /etc/salt/minion.d/grains.conf
-```
-
-```yaml
-grains:
-  etcd_servers: $MASTER_IP
-  cloud: vagrant
-  roles:
-    - kubernetes-master
-```
-
-Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files.
-
-The following enumerates the set of defined key/value pairs that are supported today.  If you add new ones, please make sure to update this list.
-
-Key | Value
------------------------------------|----------------------------------------------------------------
-`api_servers` | (Optional) The IP address / host name where a kubelet can get read-only access to kube-apiserver
-`cbr-cidr` | (Optional) The minion IP address range used for the docker container bridge.
-`cloud` | (Optional) Which IaaS platform is used to host Kubernetes, *gce*, *azure*, *aws*, *vagrant*
-`etcd_servers` | (Optional) Comma-delimited list of IP addresses the kube-apiserver and kubelet use to reach etcd.  Uses the IP of the first machine in the kubernetes_master role, or 127.0.0.1 on GCE.
-`hostnamef` | (Optional) The full host name of the machine, i.e. uname -n
-`node_ip` | (Optional) The IP address to use to address this node
-`hostname_override` | (Optional) Mapped to the kubelet hostname-override
-`network_mode` | (Optional) Networking model to use among nodes: *openvswitch*
-`networkInterfaceName` | (Optional) Networking interface to use to bind addresses, default value *eth0*
-`publicAddressOverride` | (Optional) The IP address the kube-apiserver should use to bind against for external read-only access
-`roles` | (Required) 1. `kubernetes-master` means this machine is the master in the Kubernetes cluster.  2. `kubernetes-pool` means this machine is a kubernetes-node.  Depending on the role, the Salt scripts will provision different resources on the machine.
-
-These keys may be leveraged by the Salt sls files to branch behavior.
-
-In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.).  As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following.
-
-```liquid
-
-{% if grains['os_family'] == 'RedHat' %}
-// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc.
-{% else %}
-// something specific to Debian environment (apt-get, initd)
-{% endif %}
-
-```
-
-## Best Practices
-
-When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments.  This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
-
-## Future enhancements (Networking)
-
-Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.)
-
-We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers.
-
-{{% /capture %}}

content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md

@@ -38,6 +38,8 @@ Enable the aggregation layer via the following kube-apiserver flags. They may ha
     --proxy-client-cert-file=<path to aggregator proxy cert>
     --proxy-client-key-file=<path to aggregator proxy key>
 
+WARNING: do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.
+
 If you are not running kube-proxy on a host running the API server, then you must make sure that the system is enabled with the following apiserver flag:
 
     --enable-aggregator-routing=true

content/en/docs/tasks/administer-cluster/change-default-storage-class.md

@@ -46,9 +46,9 @@ for details about addon manager and how to disable individual addons.
     The output is similar to this:
 
     ```bash
-    NAME                 TYPE
+    NAME                 PROVISIONER               AGE
-    standard (default)   kubernetes.io/gce-pd
+    standard (default)   kubernetes.io/gce-pd      1d
-    gold                 kubernetes.io/gce-pd
+    gold                 kubernetes.io/gce-pd      1d
     ```
 
     The default StorageClass is marked by `(default)`.
@@ -77,8 +77,7 @@ for details about addon manager and how to disable individual addons.
       ```
 
       Please note that at most one StorageClass can be marked as default. If two
-      or more of them are marked as default, Kubernetes ignores the annotation,
+      or more of them are marked as default, a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot be created.
-      i.e. it behaves as if there is no default StorageClass.
 
 1. Verify that your chosen StorageClass is default:
 
@@ -89,9 +88,9 @@ for details about addon manager and how to disable individual addons.
       The output is similar to this:
 
       ```bash
-      NAME             TYPE
+      NAME             PROVISIONER               AGE
-      standard         kubernetes.io/gce-pd
+      standard         kubernetes.io/gce-pd      1d
-      gold (default)   kubernetes.io/gce-pd
+      gold (default)   kubernetes.io/gce-pd      1d
       ```
 
 {{% /capture %}}

content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md

@@ -36,10 +36,10 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
 
     The output is similar to this:
 
-        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
+        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
-        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   10s
+        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
-        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   6s
+        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
-        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3                   3s
+        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s
 
    This list also includes the name of the claims that are bound to each volume
    for easier identification of dynamically provisioned volumes.
@@ -56,10 +56,10 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
 
     The output is similar to this:
 
-        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
+        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
-        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   40s
+        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     40s
-        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   36s
+        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     36s
-        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3                   33s
+        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     33s
 
     In the preceding output, you can see that the volume bound to claim
     `default/claim3` has reclaim policy `Retain`. It will not be automatically

content/en/docs/tasks/administer-cluster/kubelet-config-file.md

@@ -30,7 +30,7 @@ it simplifies node deployment and configuration management.
 
 The subset of the Kubelet's configuration that can be configured via a file
 is defined by the `KubeletConfiguration` struct
-[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
+[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
 
 The configuration file must be a JSON or YAML representation of the parameters
 in this struct. Make sure the Kubelet has read permissions on the file.

content/en/docs/tasks/administer-cluster/reserve-compute-resources.md

@@ -119,7 +119,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 
 ### System Reserved
 
-- **Kubelet Flag**: `--system-reserved=[cpu=100mi][,][memory=100Mi][,][ephemeral-storage=1Gi]`
+- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi]`
 - **Kubelet Flag**: `--system-reserved-cgroup=`
 
 

content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md

@@ -122,7 +122,7 @@ Recall that by setting `-cpu "2"`, you configured the Container to attempt to us
 {{< note >}}
 **Note:** Another possible explanation for the CPU throttling is that the Node might not have
 enough CPU resources available. Recall that the prerequisites for this exercise require each of
-your Nodes ot have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
+your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
 cannot use more than 1 CPU regardless of the CPU limit specified for the Container.
 {{< /note >}}
 

content/en/docs/tasks/configure-pod-container/assign-memory-resource.md

@@ -190,10 +190,13 @@ kubectl get pod memory-demo-2 --namespace=mem-example
 The output shows that the Container is killed, restarted, killed again, restarted again, and so on:
 
 ```
-stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
+kubectl get pod memory-demo-2 --namespace=mem-example
 NAME            READY     STATUS      RESTARTS   AGE
 memory-demo-2   0/1       OOMKilled   1          37s
-stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
+```
+```
+
+kubectl get pod memory-demo-2 --namespace=mem-example
 NAME            READY     STATUS    RESTARTS   AGE
 memory-demo-2   1/1       Running   2          40s
 ```

content/en/includes/partner-script.js

@@ -831,7 +831,7 @@
 			name: 'IBM',
 			logo: 'ibm',
 			link: 'https://www.ibm.com/cloud/container-service',
-			blurb: 'IBM - IBM Cloud Container Service'
+			blurb: 'IBM - IBM Cloud Kubernetes Service'
 				},
 		{
 			type: 2,

data/setup.yml

@@ -38,7 +38,7 @@ toc:
     path: https://cloud.google.com/kubernetes-engine/docs/before-you-begin/
   - title: Running Kubernetes on Azure Container Service
     path: https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough
-  - title: Running Kubernetes on IBM Cloud Container Service
+  - title: Running Kubernetes on IBM Cloud Kubernetes Service
     path: https://console.bluemix.net/docs/containers/container_index.html
 
 - title: Turn-key Cloud Solutions

resources/OWNERS

@@ -0,0 +1,8 @@
+# Allow CSS/SASS updates from blog and case studies owners 
+options:
+  no_parent_owners: false
+reviewers:
+  - alexcontini
+approvers:
+  - alexcontini
+  

resources/_gen/assets/sass/cn/sass/styles.sass_a6e533854c4de092afe9278041939937.json

@@ -0,0 +1 @@
+{"Target":"css/styles.css","MediaType":"text/css","Data":{}}

static/google2a9463bd6a902e34.html

@@ -0,0 +1 @@
+google-site-verification: google2a9463bd6a902e34.html