fix single # headers (#1825)

* fix single # headers
kgateway-dev · Dec 5, 2019 · f2530c3 · f2530c3
1 parent 38fd4a7
commit f2530c3
Show file tree

Hide file tree

Showing 6 changed files with 13 additions and 13 deletions.
diff --git a/docs/content/getting_started/_index.md b/docs/content/getting_started/_index.md
@@ -3,7 +3,7 @@ title: Getting Started with Gloo
 weight: 15
 ---
 
-# Gloo Says Go
+## Gloo Says Go
 
 We know you want to jump right in and start hacking away with Gloo. That's awesome! If you want to try out Gloo in a hosted setting, please check out our [Katacoda](https://katacoda.com/solo-io) courses that will guide you through a number of scenarios using Gloo, all in a sandboxed environment.
 

diff --git a/docs/content/gloo_routing/tls/client_tls_service_annotations.md b/docs/content/gloo_routing/tls/client_tls_service_annotations.md
@@ -5,15 +5,15 @@ weight: 75
 description: Set up Gloo to route to TLS-encrypted services by using annotations on the Kubernetes Service object.
 ---
 
-# Motivation
+## Motivation
 
 Gloo can auto-discover SSL configuration for [upstream TLS connections]({{< versioned_link_path fromRoot="/gloo_routing/tls/client_tls">}}) using annotations on the Kubernetes Service.
 
 This can be used as a convenient alternative to the {{% protobuf display="Upstream" name="gloo.solo.io.Upstream" %}} to configure Upstream or Client SSL.
 
 This document explains the options for configuring SSL using service annotations. For a step-by-step guide illustrating Upstream SSL in Gloo, see [the Upstream SSL Guide]({{< versioned_link_path fromRoot="/gloo_routing/tls/client_tls">}})
 
-# Configuring Upstream SSL Using Kubernetes Secrets
+## Configuring Upstream SSL Using Kubernetes Secrets
 
 To use a Kubernetes TLS secret for Upstream TLS, set the annotations of your service like so:
 
@@ -41,7 +41,7 @@ spec:
 Note: The secret must live in the same namespace as the service.
 {{% /notice %}}
 
-# Configuring Upstream SSL Using Files Mounted to the Proxy
+## Configuring Upstream SSL Using Files Mounted to the Proxy
 
 To certs mounted to the proxy pod (named `gateway-proxy-v2` by default) for Upstream TLS, set the annotations of your service like so:
 
@@ -72,7 +72,7 @@ Note: The certificates must be mounted to the proxy pod (named `gateway-proxy-v2
 {{% /notice %}}
 
 
-# Configuring Upstream SSL for a Specific Port on a Service
+## Configuring Upstream SSL for a Specific Port on a Service
 
 A service may have more than one port, where only a specific port is serving SSL.
 

diff --git a/docs/content/gloo_routing/validation/_index.md b/docs/content/gloo_routing/validation/_index.md
@@ -5,15 +5,15 @@ weight: 11
 description: (Kubernetes Only) Gloo can be configured to validate configuration before it is applied to the cluster. With validation enabled, any attempt to apply invalid configuration to the cluster will be rejected.
 ---
 
-# Motivation
+## Motivation
 
 When configuring an API gateway or edge proxy, invalid configuration can quickly lead to bugs, service outages, and 
 security vulnerabilities. 
 
 This document explains features in Gloo designed to prevent invalid configuration from propagating to the 
 data plane (the Gateway Proxies).
 
-# How Gloo Validates Configuration
+## How Gloo Validates Configuration
 
 Validation in Gloo is comprised of a two step process:
 
@@ -35,7 +35,7 @@ The proxy that *Gateways* and their *Virtual Services* will be applied to can be
 
 {{% /notice %}}
 
-# Warnings and Errors
+## Warnings and Errors
 
 Gloo processes an admitted config resource, it can report one of three status types on the resource:
 
@@ -45,7 +45,7 @@ Gloo processes an admitted config resource, it can report one of three status ty
 
 When a resource is in *Rejected* or *Warning* state, its configuration is not propagated to the proxy.
 
-# Using the Validating Webhook
+## Using the Validating Webhook
 
 Admission Validation provides a safeguard to ensure Gloo does not halt processing of configuration. If a resource 
 would be written or modified in such a way to cause Gloo to report an error, it is instead rejected by the Kubernetes 
@@ -71,7 +71,7 @@ To enable "strict" admission control (rejection of resources with invalid config
 When strict admission control is enabled, any resource that would produce a `Rejected` status will be rejected on admission.
 Resources that would produce a `Warning` status are still admitted.
 
-# Enabling Strict Validation Webhook 
+## Enabling Strict Validation Webhook 
 
 
 By default, the Validation Webhook only logs the validation result, but always admits resources with valid YAML (even if the 

diff --git a/docs/content/installation/gateway/_index.md b/docs/content/installation/gateway/_index.md
@@ -4,7 +4,7 @@ description: Guides for installing the Gloo Gateway.
 weight: 2
 ---
 
-# Install the Gloo Gateway
+## Install the Gloo Gateway
 
 <dic markdown=1>
 <table>

diff --git a/docs/content/observability/tracing.md b/docs/content/observability/tracing.md
@@ -4,7 +4,7 @@ weight: 4
 description: Configure Gloo for tracing
 ---
 
-# Tracing
+## Tracing
 
 Gloo makes it easy to implement tracing on your system through [Envoy's tracing capabilities](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing.html).
 

diff --git a/docs/content/upgrading/0.18.1.md b/docs/content/upgrading/0.18.1.md
@@ -6,7 +6,7 @@ description: Migrating from Gateway v1 to v2 CRD.
 
  {{% notice note %}} Please use open source gloo 0.18.1+, or gloo enterprise 0.18.0+. {{% /notice %}}
 
-# Upgrading to 0.18 on Kubernetes
+## Upgrading to 0.18 on Kubernetes
 In Open Source Gloo 0.18.1, we updated the Gateway API to support managing Envoy TCP (L4) routing configuration in addition to existing HTTP/S (L7). This required making a non-backwards compatible change to the Gateway CRD in Gloo. 
 
 Due to limited support for CRD versioning in older versions of Kubernetes (we cannot assume our customers run Kubernetes 1.13+), we implemented this change with a new Gateway v2 CRD. Open Source Gloo 0.18.1+ will no longer install the old Gateway CRD or controller.