Skip to content

Commit cb3dec9

Browse files
committed
Merge branch 'master' of github.com:cnych/kubernetes-learning
2 parents e5b4338 + 48adfbf commit cb3dec9

File tree

3 files changed

+5
-5
lines changed

3 files changed

+5
-5
lines changed

docs/34.PVC.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -260,7 +260,7 @@ index.html nginxpvc-test
260260
$ ls /data/k8s/nginxpvc-test/
261261
```
262262

263-
我们可以预想到现在我们访问上面的服务,是不是又会得到**403**的结果啊,因为**nginxpvc-test**目录下面还没有任何文件呢,我们把根目录下面的 index.html 文件一到到 nginxpvc-test 目录下面去是不是又可以访问了:
263+
我们可以预想到现在我们访问上面的服务,是不是又会得到**403**的结果啊,因为**nginxpvc-test**目录下面还没有任何文件呢,我们把根目录下面的 index.html 文件移动到 nginxpvc-test 目录下面去是不是又可以访问了:
264264
```shell
265265
$ mv /data/k8s/index.html /data/k8s/nginxpvc-test/
266266
```

docs/54.监控Kubernetes集群节点.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
* 编排级的 metrics:比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标
99

1010
## 监控方案
11-
Kubernetes 集群的监控方案目前主要有以下集中方案
11+
Kubernetes 集群的监控方案目前主要有以下几种方案
1212

1313
* Heapster:Heapster 是一个集群范围的监控和数据聚合工具,以 Pod 的形式运行在集群中。
1414
![heapster](./images/kubernetes_monitoring_heapster.png)
@@ -26,7 +26,7 @@ Kubernetes 集群的监控方案目前主要有以下集中方案:
2626
* metrics-server 主要关注的是[资源度量 API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md) 的实现,比如 CPU、文件描述符、内存、请求延时等指标。
2727

2828
## 监控集群节点
29-
现在我们就来开始我们集群的监控工作,首先来监控我们集群的节点,要监控节点其实我们已经有很多非常成熟的方案了,比如 Nagios、zabbix,甚至我们自己来收集数据也可以,我们这里通过 Prometheus 来采集节点的监控指标数据,可以通过[node_exporter](https://github.com/prometheus/node_exporter)来获取,顾名思义,node_exporter 抓哟就是用于采集服务器节点的各种运行指标的,目前 node_exporter 支持几乎所有常见的监控点,比如 conntrack,cpu,diskstats,filesystem,loadavg,meminfo,netstat等,详细的监控点列表可以参考其[Github repo](https://github.com/prometheus/node_exporter)
29+
现在我们就来开始我们集群的监控工作,首先来监控我们集群的节点,要监控节点其实我们已经有很多非常成熟的方案了,比如 Nagios、zabbix,甚至我们自己来收集数据也可以,我们这里通过 Prometheus 来采集节点的监控指标数据,可以通过[node_exporter](https://github.com/prometheus/node_exporter)来获取,顾名思义,node_exporter 就是抓取用于采集服务器节点的各种运行指标,目前 node_exporter 支持几乎所有常见的监控点,比如 conntrack,cpu,diskstats,filesystem,loadavg,meminfo,netstat等,详细的监控点列表可以参考其[Github repo](https://github.com/prometheus/node_exporter)
3030

3131
我们可以通过 DaemonSet 控制器来部署该服务,这样每一个节点都会自动运行一个这样的 Pod,如果我们从集群中删除或者添加节点后,也会进行自动扩展。
3232

@@ -97,7 +97,7 @@ spec:
9797

9898
另外我们还将主机的`/dev`、`/proc`、`/sys`这些目录挂载到容器中,这些因为我们采集的很多节点数据都是通过这些文件夹下面的文件来获取到的,比如我们在使用`top`命令可以查看当前`cpu`使用情况,数据就来源于文件`/proc/stat`,使用`free`命令可以查看当前内存使用情况,其数据来源是来自`/proc/meminfo`文件。
9999

100-
另外由于我们集群使用的是 kubeadm 搭建的,所以如果希望 master 节点也一起被监控,则需要添加响应的容忍,对于污点和容忍还不是很熟悉的同学可以在前面的章节中回顾下。
100+
另外由于我们集群使用的是 kubeadm 搭建的,所以如果希望 master 节点也一起被监控,则需要添加相应的容忍,对于污点和容忍还不是很熟悉的同学可以在前面的章节中回顾下。
101101

102102
然后直接创建上面的资源对象即可:
103103
```shell

docs/56.Grafana的安装使用.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ $ docker run -d --name=grafana -p 3000:3000 grafana/grafana
2020
* Runs as the grafana user by default (instead of root)
2121
* All default volumes removed
2222

23-
特别需要注意第3条,userid 和 groupid 都有所变化,所以我们在运行的容器的时候需要注意这个变化。现在我们将这个容器转化成 Kubernetes 中的 Pod:(grafana.yaml)
23+
特别需要注意第3条,userid 和 groupid 都有所变化,所以我们在运行的容器的时候需要注意这个变化。现在我们将这个容器转化成 Kubernetes 中的 Pod:(grafana-deploy.yaml)
2424
```yaml
2525
apiVersion: extensions/v1beta1
2626
kind: Deployment

0 commit comments

Comments
 (0)