update title levels

appendix/issues.md

@@ -1,4 +1,4 @@
-## Kubernetes 相关问题记录
+# Kubernetes 相关问题记录
 
 安装、使用kubernetes的过程中遇到的所有问题的记录。
 

cloud-native/cncf-ambassador.md

@@ -1,4 +1,4 @@
-## CNCF Ambassador
+# CNCF Ambassador
 
 CNCF Ambassador（CNCF 大使），人员名单详见 <https://www.cncf.io/people/ambassadors/>，笔者很荣幸作为第二位成为 CNCF Ambassador 的中国人。
 

cloud-native/cncf-project-governing.md

@@ -1,4 +1,4 @@
-## CNCF中的项目治理
+# CNCF中的项目治理
 
 CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。
 

cloud-native/cncf-sandbox-criteria.md

@@ -1,4 +1,4 @@
-## 开源项目加入CNCF Sandbox的要求
+# 开源项目加入CNCF Sandbox的要求
 
 [CNCF Project Proposal Process](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) 中指出开源项目要想加入 CNCF 必须满足以下条件：
 

concepts/configmap.md

@@ -1,4 +1,4 @@
-## ConfigMap
+# ConfigMap
 
 其实 ConfigMap 功能在 Kubernetes1.2 版本的时候就有了，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与 docker image 解耦，你总不能每修改一个配置就重做一个 image 吧？ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象。
 

guide/auth-with-kubeconfig-or-token.md

@@ -1,4 +1,4 @@
-## 使用 kubeconfig 或 token 进行用户身份认证
+# 使用 kubeconfig 或 token 进行用户身份认证
 
 在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。
 
@@ -7,7 +7,7 @@
 - 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件
 - 为集群的管理员（拥有所有命名空间的 amdin 权限）创建 token
 
-### 使用 kubeconfig
+## 使用 kubeconfig
 
 如何生成`kubeconfig`文件请参考[创建用户认证授权的kubeconfig文件](../guide/kubectl-user-authentication-authorization.md)。
 
@@ -19,11 +19,11 @@
 
 对于访问 dashboard 时候的使用 kubeconfig 文件如`brand.kubeconfig` 必须追到 `token` 字段，否则认证不会通过。而使用 kubectl 命令时的用的 kubeconfig 文件则不需要包含 `token` 字段。
 
-### 生成 token
+## 生成 token
 
 需要创建一个admin用户并授予admin角色绑定，使用下面的yaml文件创建admin用户并赋予他管理员权限，然后可以通过token访问kubernetes，该文件见[admin-role.yaml](https://github.com/rootsongjc/kubernetes-handbook/tree/master/manifests/dashboard-1.7.1/admin-role.yaml)。
 
-#### 生成kubernetes集群最高权限admin用户的token
+### 生成kubernetes集群最高权限admin用户的token
 
 ```yaml
 kind: ClusterRoleBinding
@@ -96,7 +96,7 @@ kubectl -n kube-system get secret admin-token-nwphb -o jsonpath={.data.token}|ba
 kubectl describe secret admin-token-nwphb 
 ```
 
-#### 为普通用户生成token
+### 为普通用户生成token
 
 为指定namespace分配该namespace的最高权限，这通常是在为某个用户（组织或者个人）划分了namespace之后，需要给该用户创建token登陆kubernetes dashboard或者调用kubernetes API的时候使用。
 
@@ -112,5 +112,5 @@ kubectl create rolebinding $ROLEBINDING_NAME --clusterrole=admin --serviceaccoun
 
 ## 参考
 
-- [JSONPath 手册](https://kubernetes.io/docs/user-guide/jsonpath/)
-- [Kubernetes 中的认证](https://kubernetes.io/docs/admin/authentication/)
+- [JSONPath 手册 - kubernetes.io](https://kubernetes.io/docs/user-guide/jsonpath/)
+- [Kubernetes 中的认证 - kubernetes.io](https://kubernetes.io/docs/admin/authentication/)

practice/distributed-load-test.md

@@ -1,4 +1,4 @@
-## 分布式负载测试
+# 分布式负载测试
 
 该教程描述如何在 [Kubernetes](https://kubernetes.io/) 中进行分布式负载均衡测试，包括一个 web 应用、docker 镜像和 Kubernetes controllers/services。关于分布式负载测试的更多资料请查看 [Distributed Load Testing Using Kubernetes](https://cloud.google.com/solutions/distributed-load-testing-using-kubernetes) 。
 

practice/rbac-support-in-kubernetes.md

@@ -1,4 +1,4 @@
-## Kubernetes中的RBAC 支持
+# Kubernetes中的RBAC 支持
 
 > 在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
 

usecases/before-using-istio.md

@@ -1,4 +1,4 @@
-## 使用 Istio 前需要考虑的问题
+# 使用 Istio 前需要考虑的问题
 
 在使用 Istio 之前，请先考虑下以下因素：
 

usecases/kubeedge.md

@@ -1,4 +1,4 @@
-## KubeEdge
+# KubeEdge
 
 以 Kubernetes 为基础的开源项目：[KubeEdge](https://kubeedge.io/zh/)。
 

usecases/service-mesh-adoption-and-evolution.md

@@ -1,4 +1,4 @@
-## 采纳和演进
+# 采纳和演进
 
 没有人会一下子采纳Service Mesh架构的所有组件，或者一次性将所有的应用都改造成Service Mesh的，都是渐渐式采纳，从非核心系统开始改造。采纳Service Mesh就两种路径：