diff --git a/.vuepress/config-sidebar.js b/.vuepress/config-sidebar.js index 41170ef5..3ace6e2e 100644 --- a/.vuepress/config-sidebar.js +++ b/.vuepress/config-sidebar.js @@ -36,7 +36,8 @@ module.exports = { 'install-docker-desktop', ['install-k8s', '安装Kubernetes单Master节点'], 'install-kubernetes', - 'install-node-port-range' + 'install-node-port-range', + 'k8s-restart', ] }, { @@ -231,6 +232,7 @@ module.exports = { 'k8s-intermediate/service/connecting', 'k8s-intermediate/service/ingress', 'k8s-intermediate/service/cni', + 'k8s-intermediate/service/np' ] }, { diff --git a/.vuepress/public/install-script/v1.16.2/init_master.sh b/.vuepress/public/install-script/v1.16.2/init_master.sh index a4b7f8bd..39ebe0b8 100644 --- a/.vuepress/public/install-script/v1.16.2/init_master.sh +++ b/.vuepress/public/install-script/v1.16.2/init_master.sh @@ -5,6 +5,14 @@ # 脚本出错时终止执行 set -e +if [ ${#POD_SUBNET} -eq 0 ] || [ ${#APISERVER_NAME} -eq 0 ]; then + echo -e "\033[31;1m请确保您已经设置了环境变量 POD_SUBNET 和 APISERVER_NAME \033[0m" + echo 当前POD_SUBNET=$POD_SUBNET + echo 当前APISERVER_NAME=$APISERVER_NAME + exit 1 +fi + + # 查看完整配置选项 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2 rm -f ./kubeadm-config.yaml cat < ./kubeadm-config.yaml diff --git a/.vuepress/theme/components/Page.vue b/.vuepress/theme/components/Page.vue index e88c0ea2..4f4abd56 100644 --- a/.vuepress/theme/components/Page.vue +++ b/.vuepress/theme/components/Page.vue @@ -50,6 +50,13 @@ + diff --git a/.vuepress/theme/components/Sidebar.vue b/.vuepress/theme/components/Sidebar.vue index bec508e4..a5a862e6 100644 --- a/.vuepress/theme/components/Sidebar.vue +++ b/.vuepress/theme/components/Sidebar.vue @@ -14,7 +14,7 @@
使用
-
+
培训
diff --git a/install/install-dashboard.md b/install/install-dashboard.md index e9caba83..a714a63a 100644 --- a/install/install-dashboard.md +++ b/install/install-dashboard.md @@ -54,6 +54,19 @@ meta: kubectl apply -f https://kuboard.cn/install-script/kuboard.yaml ``` +查看 Kuboard 运行状态： + +``` sh +kubectl get pods -l k8s.eip.work/name=kuboard -n kube-system +``` + +输出结果如下所示： +``` +NAME READY STATUS RESTARTS AGE +kuboard-54c9c4f6cb-6lf88 1/1 Running 0 45s +``` +> 如果您一直不能看到 kuboard 处于 Running 状态，可参考 [诊断应用程序](/learning/k8s-advanced/ts/application.html)，查找原因。如不能解决，请到本文页尾加群，联系群主解决。 + diff --git a/install/k8s-restart.md b/install/k8s-restart.md new file mode 100644 index 00000000..ed1e4c6f --- /dev/null +++ b/install/k8s-restart.md @@ -0,0 +1,36 @@ +--- +vssueId: 15 +# layout: StepLayout +description: Kubernete安装文档_Kubernetes集群的设计目标是setup-and-run-forever_然而许多学习者使用自己笔记本上的虚拟机安装K8S集群用于学习_这就必然会出现反复重启集群所在虚拟机的情况_本文针对重启后会出现一些的一些令人困惑的问题做了解释 +meta: + - name: keywords + content: Kubernetes重启,K8S重启,K8S教程 +--- + +# 重启Kubernetes集群 + + + +Kubernetes集群的设计目标是setup-and-run-forever，然而许多学习者使用自己笔记本上的虚拟机安装K8S集群用于学习，这就必然会出现反复重启集群所在虚拟机的情况。本文针对重启后会出现一些的一些令人困惑的问题做了解释。 + + + +## Worker节点不能启动 + +Master 节点的 IP 地址变化，导致 worker 节点不能启动。请重装集群，并确保所有节点都有固定内网 IP 地址。 + +## 许多Pod一直Crash或不能正常访问 + +``` sh +kubectl get pods --all-namespaces +``` + +重启后会发现许多 Pod 不在 Running 状态，此时，请使用如下命令删除这些状态不正常的 Pod。通常，您的 Pod 如果是使用 Deployment、StatefulSet 等控制器创建的，kubernetes 将创建新的 Pod 作为替代，重新启动的 Pod 通常能够正常工作。 + +``` sh +kubectl delete pod -n +``` + +## 其他问题 + +请参考本文结尾的方式联系 kuboard 群主，协助您解决重启 kubernetes 集群后的问题 diff --git a/learning/README.md b/learning/README.md index 1721f944..f17a430d 100644 --- a/learning/README.md +++ b/learning/README.md @@ -12,17 +12,17 @@ meta: # Kubernetes 教程
-
+
-
+
-
+
diff --git a/learning/k8s-basics/deploy-app.md b/learning/k8s-basics/deploy-app.md index ac83a209..35aff06c 100644 --- a/learning/k8s-basics/deploy-app.md +++ b/learning/k8s-basics/deploy-app.md @@ -34,7 +34,7 @@ meta: 在 k8s 上进行部署前，首先需要了解一个基本概念 **Deployment** -**Deployment** 译名为 **部署**。在k8s中，通过发布 Deployment，可以创建应用程序 (docker image) 的实例 (docker container)，这个实例会被包含在称为 **Pod** 的概念中，**Pod** 是 k8s 中最小单元的可管理单元。 +**Deployment** 译名为 **部署**。在k8s中，通过发布 Deployment，可以创建应用程序 (docker image) 的实例 (docker container)，这个实例会被包含在称为 **Pod** 的概念中，**Pod** 是 k8s 中最小可管理单元。 在 k8s 集群中发布 Deployment 后，Deployment 将指示 k8s 如何创建和更新应用程序的实例，master 节点将应用程序实例调度到集群中的具体的节点上。 diff --git a/learning/k8s-basics/k8s-core-concepts.md b/learning/k8s-basics/k8s-core-concepts.md index dcdab525..663b80aa 100644 --- a/learning/k8s-basics/k8s-core-concepts.md +++ b/learning/k8s-basics/k8s-core-concepts.md @@ -91,7 +91,7 @@ Replication Controller确保任意时间都有指定数量的Pod“副本”在 *如果Pods是短暂的，那么重启时IP地址可能会改变，怎么才能从前端容器正确可靠地指向后台容器呢？* [Service](https://kubernetes.io/docs/concepts/services-networking/service/) **抽象** -现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（）。 的Service会完成如下两件重要的事情： +现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，label选择器为(tier=backend, app=myapp) 的Service会完成如下两件重要的事情： - 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。 - 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。 diff --git a/learning/k8s-basics/kubernetes-basics.md b/learning/k8s-basics/kubernetes-basics.md index b03cb64e..47ef8783 100644 --- a/learning/k8s-basics/kubernetes-basics.md +++ b/learning/k8s-basics/kubernetes-basics.md @@ -48,7 +48,7 @@ meta: **Master 负责管理集群** 负责协调集群中的所有活动，例如调度应用程序，维护应用程序的状态，扩展和更新应用程序。 -**Worker节点(即图中的Node)是VM(虚拟机)或物理计算机，充当k8s集群中的工作计算机。** 每个Worker节点都有一个Kubelet，它管理一个Worker节点并与负责与Master节点通信。该Worker节点还应具有用于处理容器操作的工具，例如Docker。 +**Worker节点(即图中的Node)是VM(虚拟机)或物理计算机，充当k8s集群中的工作计算机。** 每个Worker节点都有一个Kubelet，它管理该Worker节点并负责与Master节点通信。该Worker节点还应具有用于处理容器操作的工具，例如Docker。 diff --git a/learning/k8s-bg/architecture/controller.md b/learning/k8s-bg/architecture/controller.md index de43aa1d..bc790622 100644 --- a/learning/k8s-bg/architecture/controller.md +++ b/learning/k8s-bg/architecture/controller.md @@ -16,7 +16,7 @@ meta: * 在恒温器上设定好目标温度，就是在告诉该 **控制循环** 你想要的 ***目标状态***。 * 房间里的实际温度，是 ***当前状态*** -* 恒温器通过打卡或关闭加热装置，不断地使 ***当前状态*** 接近于 ***目标状态*** +* 恒温器通过打开或关闭加热装置，不断地使 ***当前状态*** 接近于 ***目标状态*** 在 Kubernetes 中，**控制器** 就是上面所说的 **控制循环**，它不断监控着集群的状态，并对集群做出对应的变更调整。每一个控制器都不断地尝试着将 ***当前状态*** 调整到 ***目标状态***。 diff --git a/learning/k8s-bg/architecture/nodes.md b/learning/k8s-bg/architecture/nodes.md index 9138580e..4ed3a469 100644 --- a/learning/k8s-bg/architecture/nodes.md +++ b/learning/k8s-bg/architecture/nodes.md @@ -134,7 +134,7 @@ Events: | Node Condition | 描述 | | ----------------- | ------------------------------------------------------------ | | OutOfDisk | 如果节点上的空白磁盘空间不够，不能够再添加新的节点时，该字段为 `True`，其他情况为 `False` | -| Ready | 如果节点时健康的且已经就绪可以接受新的 Pod。则节点Ready字段为 `True`。`False`表明了该节点不健康，不能够接受新的 Pod。 | +| Ready | 如果节点是健康的且已经就绪可以接受新的 Pod。则节点Ready字段为 `True`。`False`表明了该节点不健康，不能够接受新的 Pod。 | | MemoryPressure | 如果节点内存紧张，则该字段为 `True`，否则为`False` | | PIDPressure | 如果节点上进程过多，则该字段为 `True`，否则为 `False` | | DiskPressure | 如果节点磁盘空间紧张，则该字段为 `True`，否则为 `False` | diff --git a/learning/k8s-bg/component.md b/learning/k8s-bg/component.md index 0e3d0ac0..33b45307 100644 --- a/learning/k8s-bg/component.md +++ b/learning/k8s-bg/component.md @@ -94,7 +94,7 @@ kube-proxy 在节点上维护网络规则。这些网络规则使得您可以在 ### 容器引擎 -容器引擎负责运行容器。Kubernetes支持多宗容器引擎：[Docker](http://www.docker.com/)、[containerd](https://containerd.io/)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现了 [Kubernetes容器引擎接口](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的容器引擎 +容器引擎负责运行容器。Kubernetes支持多种容器引擎：[Docker](http://www.docker.com/)、[containerd](https://containerd.io/)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现了 [Kubernetes容器引擎接口](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的容器引擎 ## Addons diff --git a/learning/k8s-intermediate/container/lifecycle.md b/learning/k8s-intermediate/container/lifecycle.md index 8c46f4bc..2312a94d 100644 --- a/learning/k8s-intermediate/container/lifecycle.md +++ b/learning/k8s-intermediate/container/lifecycle.md @@ -43,7 +43,7 @@ Kubernetes中为容器提供了两个 hook（钩子函数）： 容器只要实现并注册 hook handler 便可以使用钩子函数。Kubernetes 中，容器可以实现两种类型的 hook handler： * Exec - 在容器的名称空进和 cgroups 中执行一个指定的命令，例如 `pre-stop.sh`。该命令所消耗的 CPU、内存等资源，将计入容器可以使用的资源限制。 -* HTTP - 想容器的指定端口发送一个 HTTP 请求 +* HTTP - 向容器的指定端口发送一个 HTTP 请求 ### Hook handler的执行 diff --git a/learning/k8s-intermediate/container/runtime.md b/learning/k8s-intermediate/container/runtime.md index 8debb6de..2c7eceaa 100644 --- a/learning/k8s-intermediate/container/runtime.md +++ b/learning/k8s-intermediate/container/runtime.md @@ -21,9 +21,9 @@ meta: ## 设计目标 -可以通过 RuntimeClass，使不同的 Pod 使用不同的容器引擎，以在性能和安全之间取得平衡。例如，如果某些工作负载需要非常高的信息安全保证，您可能将其 Pod 运行在那种使用硬件虚拟化的容器引擎上；同时，将其他的 Pod 运行在另外一种容器引擎上，以获得更高的性能。 +可以通过 RuntimeClass，使不同的 Pod 使用不同的容器引擎，以在性能和安全之间取得平衡。例如，如果某些工作负载需要非常高的信息安全保证，您可能想要将其 Pod 运行在那种使用硬件虚拟化的容器引擎上；同时，将其他的 Pod 运行在另外一种容器引擎上，以获得更高的性能。 -也可以通过 RuntimeClass 配置，使不同的 Pod 使用相同的容器引擎，但是不同的容器引擎设定。 +也可以通过 RuntimeClass 配置，使不同的 Pod 使用相同的容器引擎和不同的容器引擎配置参数。 ### 配置步骤 diff --git a/learning/k8s-intermediate/service/service.md b/learning/k8s-intermediate/service/service.md index bad4383f..7d09e4cd 100644 --- a/learning/k8s-intermediate/service/service.md +++ b/learning/k8s-intermediate/service/service.md @@ -46,7 +46,7 @@ Kubernetes 通过引入 Service 的概念，将前端与后端解耦。 图中，Service 先连线到 Controller，Controller 在连线到容器组，这种表示方式只是概念上的，期望用户在使用 Kubernetes 的时候总是通过 Controller 创建 Pod，然后再通过 Service 暴露为网络服务，通过 Ingress 对集群外提供互联网访问。 -事实上，Service 与 Controller 并没有直接联系，Service 通过 label selector 选择符合条件的 Pod，并将选中的 Pod 作为网络服务的提供者。从这个意义上来讲，您可以有很多中方式去定义 Service 的 label selector，然而，最佳的实践是，在 Service 中使用与 Controller 中相同的 label selector。如上图所示。 +事实上，Service 与 Controller 并没有直接联系，Service 通过 label selector 选择符合条件的 Pod，并将选中的 Pod 作为网络服务的提供者。从这个意义上来讲，您可以有很多种方式去定义 Service 的 label selector，然而，最佳的实践是，在 Service 中使用与 Controller 中相同的 label selector。如上图所示。 ::: tip 使用 Kubernetes 的最佳实践： diff --git a/overview/k8s-core-concepts.md b/overview/k8s-core-concepts.md index cb7af38b..789f79f4 100644 --- a/overview/k8s-core-concepts.md +++ b/overview/k8s-core-concepts.md @@ -85,7 +85,7 @@ Replication Controller确保任意时间都有指定数量的Pod“副本”在 *如果Pods是短暂的，那么重启时IP地址可能会改变，怎么才能从前端容器正确可靠地指向后台容器呢？* [Service](https://kubernetes.io/docs/concepts/services-networking/service/) **抽象** -现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（）。 的Service会完成如下两件重要的事情： +现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，label选择器为(tier=backend, app=myapp) 的Service会完成如下两件重要的事情： - 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。 - 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。