feat: add the pre and next page.

Author: guangzhengli

docs/configmap.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Namespace'
+  link: '/docs/namespaces'
+next:
+  text: 'Secret'
+  link: '/docs/secert'
+---
+
 # ConfigMap
 
 上面的教程提到，我们在不同环境 `dev` `test` `uat` `prod` 中区分资源，可以让其资源独立互相不受影响，但是随之而来也会带来一些问题，例如不同环境的数据库的地址往往是不一样的，那么如果在代码中写同一个数据库的地址，就会出现问题。

docs/container.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Pre'
+  link: '/docs/pre'
+next:
+  text: 'Pod'
+  link: '/docs/pod'
+---
+
 # Container
 
 我们的旅程从一段代码开始。新建一个 `main.go` 文件，复制下面的代码到文件中。

docs/dashboard.md

@@ -1,3 +1,10 @@
+---
+prev:
+  text: 'Helm'
+  link: '/docs/helm'
+next: false
+---
+
 # Dashboard
 
 ## kubernetes dashboard

docs/deployment.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Pod'
+  link: '/docs/pod'
+next:
+  text: 'Service'
+  link: '/docs/service'
+---
+
 # Deployment
 
 在生产环境中，我们基本上不会直接管理 pod，我们需要 `kubernetes` 来帮助我们来完成一些自动化操作，例如自动扩容或者自动升级版本。可以想象在生产环境中，我们手动部署了 10 个 `hellok8s:v1` 的 pod，这个时候我们需要升级成 `hellok8s:v2` 版本，我们难道需要一个一个的将 `hellok8s:v1` 的 pod 手动升级吗？

docs/helm.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Job'
+  link: '/docs/job'
+next:
+  text: 'Dashboard'
+  link: '/docs/dashboard'
+---
+
 # Helm
 
 经过前面的教程，想必你已经对 kubernetes 的使用有了一定的理解。但是不知道你是否想过这样一个问题，就是我们前面教程中提到的所有资源，包括用 `pod`, `deployment`, `service`, `ingress`, `configmap`,`secret` 所有资源来部署一套完整的 `hellok8s` 服务的话，难道需要一个一个的 `kubectl apply -f` 来创建吗？如果换一个 namespace，或者说换一套 kubernetes 集群部署的话，又要重复性的操作创建的过程吗？

docs/ingress.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Service'
+  link: '/docs/service'
+next:
+  text: 'Namespace'
+  link: '/docs/namespace'
+---
+
 # Ingress
 
 [Ingress](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#ingress-v1beta1-networking-k8s-io) 公开从集群外部到集群内[服务](https://kubernetes.io/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、 SSL/TLS，以及基于名称的虚拟托管。你必须拥有一个 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。 [Ingress 控制器](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，例如 `minikube` 默认使用的是 [nginx-ingress](https://minikube.sigs.k8s.io/docs/tutorials/nginx_tcp_udp_ingress/)，目前  `minikube` 也支持 [Kong-Ingress](https://minikube.sigs.k8s.io/docs/handbook/addons/kong-ingress/)。

docs/job.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Secret'
+  link: '/docs/secret'
+next:
+  text: 'Helm'
+  link: '/docs/helm'
+---
+
 # Job
 
 在实际的开发过程中，还有一类任务是之前的资源不能满足的，即一次性任务。例如常见的计算任务，只需要拿到相关数据计算后得出结果即可，无需一直运行。而处理这一类任务的资源就是 Job。

docs/namespace.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Ingress'
+  link: '/docs/ingress'
+next:
+  text: 'ConfigMap'
+  link: '/docs/configmap'
+---
+
 # Namespace
 
 在实际的开发当中，有时候我们需要不同的环境来做开发和测试，例如 `dev` 环境给开发使用，`test` 环境给 QA 使用，那么 k8s 能不能在不同环境 `dev` `test` `uat` `prod` 中区分资源，让不同环境的资源独立互相不影响呢，答案是肯定的，k8s 提供了名为 Namespace 的资源来帮助隔离资源。

docs/pod.md

@@ -1,3 +1,12 @@
+---
+prev:
+  text: 'Container'
+  link: '/docs/container'
+next:
+  text: 'Deployment'
+  link: '/docs/deployment'
+---
+
 # Pod
 
 如果在生产环境中运行的都是独立的单体服务，那么 Container (容器) 也就够用了，但是在实际的生产环境中，维护着大规模的集群和各种不同的服务，服务之间往往存在着各种各样的关系。而这些关系的处理，才是手动管理最困难的地方。

docs/pre.md

@@ -1,3 +1,10 @@
+---
+prev: false
+next:
+  text: 'Container'
+  link: '/docs/container'
+---
+
 # 准备工作
 
 在开始本教程之前，需要配置好本地环境，以下是需要安装的依赖和包。