CSS fixes

_config.yml

@@ -3,8 +3,7 @@ markdown: kramdown
 kramdown:
   input: GFM
   html_to_native: true
-  hard_wrap: false
-  enable_coderay: true
+  syntax_highlighter: rouge
 baseurl: /
 incremental: true
 

v1.1/docs/admin/cluster-large.md

@@ -6,8 +6,6 @@ title: "Using Large Clusters"
 
 At v1.0, Kubernetes supports clusters up to 100 nodes with 30 pods per node and 1-2 containers per pod.
 
-
-
 {% include pagetoc.html %}
 
 ## Setup
@@ -22,7 +20,8 @@ When setting up a large Kubernetes cluster, the following issues must be conside
 
 ### Quota Issues
 
-To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider:
+To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider:
+
 * Increase the quota for things like CPU, IPs, etc.
   * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for:
     * CPUs
@@ -41,21 +40,22 @@ To prevent memory leaks or other resource issues in [cluster addons](https://rel
 
 For example:
 
-{% highlight yaml %}
+{% highlight yaml %}
 containers:
   - image: gcr.io/google_containers/heapster:v0.15.0
     name: heapster
     resources:
       limits:
         cpu: 100m
-        memory: 200Mi
+        memory: 200Mi
 {% endhighlight %}
 
 These limits, however, are based on data collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
 
-To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
-* Scale memory and CPU limits for each of the following addons, if used, along with the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
-  * Heapster ([GCM/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/google/heapster-controller.yaml), [InfluxDB backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/influxdb/heapster-controller.yaml), [InfluxDB/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/googleinfluxdb/heapster-controller-combined.yaml), [standalone](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/standalone/heapster-controller.yaml))
+To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
+
+- Scale memory and CPU limits for each of the following addons, if used, along with the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
+  - Heapster ([GCM/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/google/heapster-controller.yaml), [InfluxDB backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/influxdb/heapster-controller.yaml), [InfluxDB/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/googleinfluxdb/heapster-controller-combined.yaml), [standalone](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/standalone/heapster-controller.yaml))
   * [InfluxDB and Grafana](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
   * [skydns, kube2sky, and dns etcd](http://releases.k8s.io/release-1.1/cluster/addons/dns/skydns-rc.yaml.in)
   * [Kibana](http://releases.k8s.io/release-1.1/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)