Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
kubernetes-learning
提交
e5b43388
K
kubernetes-learning
项目概览
OpenDocCN
/
kubernetes-learning
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
K
kubernetes-learning
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode，体验更适合开发者的 AI 搜索 >>
提交
e5b43388
编写于
4月 24, 2019
作者:
阳明的博客
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
替换微博图床
上级
0d727b34
变更
9
展开全部
隐藏空白更改
内联
并排
Showing
9 changed file
with
644 addition
and
39 deletion
+644
-39
SUMMARY.md
SUMMARY.md
+1
-0
docs/59.自定义Prometheus Operator 监控项.md
docs/59.自定义Prometheus Operator 监控项.md
+10
-10
docs/60.Prometheus Operator高级配置.md
docs/60.Prometheus Operator高级配置.md
+2
-2
docs/62.搭建 EFK 日志系统.md
docs/62.搭建 EFK 日志系统.md
+6
-6
docs/63.Harbor.md
docs/63.Harbor.md
+6
-6
docs/64.Gitlab.md
docs/64.Gitlab.md
+5
-5
docs/65.Gitlab CI.md
docs/65.Gitlab CI.md
+10
-10
docs/66.devops.md
docs/66.devops.md
+603
-0
gitlab-ci-k8s-demo
gitlab-ci-k8s-demo
+1
-0
未找到文件。
SUMMARY.md
浏览文件 @
e5b43388
...
...
@@ -99,4 +99,5 @@
*
[
Harbor
](
docs/63.Harbor.md
)
*
[
Gitlab
](
docs/64.Gitlab.md
)
*
[
Gitlab CI
](
docs/65.Gitlab
CI.md)
*
[
Devops
](
docs/66/devops.md
)
docs/59.自定义Prometheus Operator 监控项.md
浏览文件 @
e5b43388
...
...
@@ -140,7 +140,7 @@ spec:
上面我们在 monitoring 命名空间下面创建了名为 etcd-k8s 的 ServiceMonitor 对象，基本属性和前面章节中的一致，匹配 kube-system 这个命名空间下面的具有 k8s-app=etcd 这个 label 标签的 Service，jobLabel 表示用于检索 job 任务名称的标签，和前面不太一样的地方是 endpoints 属性的写法，配置上访问 etcd 的相关证书，endpoints 属性下面可以配置很多抓取的参数，比如 relabel、proxyUrl，tlsConfig 表示用于配置抓取监控数据端点的 tls 认证，由于证书 serverName 和 etcd 中签发的可能不匹配，所以加上了 insecureSkipVerify=true
> 关于 ServiceMonitor 属性的更多用法可以查看文档：[https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md) 了解更多
...
...
@@ -195,7 +195,7 @@ $ kubectl create -f prometheus-etcdService.yaml
创建完成后，隔一会儿去 Prometheus 的 Dashboard 中查看 targets，便会有 etcd 的监控项了：
可以看到还是有一个明显的错误，和我们上节课监控 kube-scheduler 的错误比较类似于，因为我们这里的 etcd 的是监听在 127.0.0.1 这个 IP 上面的，所以访问会拒绝：
```
shell
...
...
@@ -209,17 +209,17 @@ $ kubectl create -f prometheus-etcdService.yaml
重启 etcd，生效后，查看 etcd 这个监控任务就正常了：
数据采集到后，可以在 grafana 中导入编号为
`3070`
的 dashboard，获取到 etcd 的监控图表。
### 配置 PrometheusRule
现在我们知道怎么自定义一个 ServiceMonitor 对象了，但是如果需要自定义一个报警规则的话呢？比如现在我们去查看 Prometheus Dashboard 的 Alert 页面下面就已经有一些报警规则了，还有一些是已经触发规则的了：
但是这些报警信息是哪里来的呢？他们应该用怎样的方式通知我们呢？我们知道之前我们使用自定义的方式可以在 Prometheus 的配置文件之中指定 AlertManager 实例和 报警的 rules 文件，现在我们通过 Operator 部署的呢？我们可以在 Prometheus Dashboard 的 Config 页面下面查看关于 AlertManager 的配置：
```
yaml
...
...
@@ -355,7 +355,7 @@ monitoring-etcd-rules.yaml monitoring-prometheus-k8s-rules.yaml
可以看到我们创建的 rule 文件已经被注入到了对应的 rulefiles 文件夹下面了，证明我们上面的设想是正确的。然后再去 Prometheus Dashboard 的 Alert 页面下面就可以查看到上面我们新建的报警规则了：
### 配置报警
...
...
@@ -363,7 +363,7 @@ monitoring-etcd-rules.yaml monitoring-prometheus-k8s-rules.yaml
首先我们将 alertmanager-main 这个 Service 改为 NodePort 类型的 Service，修改完成后我们可以在页面上的 status 路径下面查看 AlertManager 的配置信息:
这些配置信息实际上是来自于我们之前在
`prometheus-operator/contrib/kube-prometheus/manifests`
目录下面创建的 alertmanager-secret.yaml 文件：
...
...
@@ -440,15 +440,15 @@ secret "alertmanager-main" created
我们添加了两个接收器，默认的通过邮箱进行发送，对于 CoreDNSDown 这个报警我们通过 webhook 来进行发送，这个 webhook 就是我们前面课程中定义的一个钉钉接收的 Server，上面的步骤创建完成后，很快我们就会收到一条钉钉消息：
同样邮箱中也会收到报警信息：
我们再次查看 AlertManager 页面的 status 页面的配置信息可以看到已经变成上面我们的配置信息了：
AlertManager 配置也可以使用模板(.tmpl文件)，这些模板可以与 alertmanager.yaml 配置文件一起添加到 Secret 对象中，比如：
...
...
docs/60.Prometheus Operator高级配置.md
浏览文件 @
e5b43388
...
...
@@ -108,7 +108,7 @@ prometheus.monitoring.coreos.com "k8s" configured
隔一小会儿，可以前往 Prometheus 的 Dashboard 中查看配置是否生效：
在 Prometheus Dashboard 的配置页面下面我们可以看到已经有了对应的的配置信息了，但是我们切换到 targets 页面下面却并没有发现对应的监控任务，查看 Prometheus 的 Pod 日志：
```
shell
...
...
@@ -172,7 +172,7 @@ rules:
更新上面的 ClusterRole 这个资源对象，然后重建下 Prometheus 的所有 Pod，正常就可以看到 targets 页面下面有 kubernetes-service-endpoints 这个监控任务了：
我们这里自动监控了两个 Service，第一个就是我们之前创建的 Redis 的服务，我们在 Redis Service 中有两个特殊的 annotations：
```
yaml
...
...
docs/62.搭建 EFK 日志系统.md
浏览文件 @
e5b43388
...
...
@@ -439,7 +439,7 @@ kibana NodePort 10.105.208.253 <none> 5601:31816/TCP 2
如果 Pod 已经是 Running 状态了，证明应用已经部署成功了，然后可以通过 NodePort 来访问 Kibana 这个服务，在浏览器中打开
`http://<任意节点IP>:31816`
即可，如果看到如下欢迎界面证明 Kibana 已经成功部署到了 Kubernetes集群之中。
## 部署 Fluentd
...
...
@@ -452,7 +452,7 @@ Fluentd 通过一组给定的数据源抓取日志数据，处理后（转换成
*
结构化并且标记这些数据
*
然后根据匹配的标签将数据发送到多个目标服务去
### 配置
...
...
@@ -826,15 +826,15 @@ kibana-7558d4dc4d-5mqdz 1/1 Running 0 1d
Fluentd 启动成功后，我们可以前往 Kibana 的 Dashboard 页面中，点击左侧的
`Discover`
，可以看到如下配置页面：
在这里可以配置我们需要的 Elasticsearch 索引，前面 Fluentd 配置文件中我们采集的日志使用的是 logstash 格式，这里只需要在文本框中输入
`logstash-*`
即可匹配到 Elasticsearch 集群中的所有日志数据，然后点击下一步，进入以下页面：
在该页面中配置使用哪个字段按时间过滤日志数据，在下拉列表中，选择
`@timestamp`
字段，然后点击
`Create index pattern`
，创建完成后，点击左侧导航菜单中的
`Discover`
，然后就可以看到一些直方图和最近采集到的日志数据了：
### 测试
...
...
@@ -861,7 +861,7 @@ $ kubectl create -f counter.yaml
Pod 创建并运行后，回到 Kibana Dashboard 页面，在上面的
`Discover`
页面搜索栏中输入
`kubernetes.pod_name:counter`
，就可以过滤 Pod 名为 counter 的日志数据：
我们也可以通过其他元数据来过滤日志数据，比如
您可以单击任何日志条目以查看其他元数据，如容器名称，Kubernetes 节点，命名空间等。
...
...
docs/63.Harbor.md
浏览文件 @
e5b43388
# 63. Harbor
[
](/post/harbor-code-analysis/)
[
](/post/harbor-code-analysis/)
[
Harbor
](
https://github.com/goharbor/harbor
)
是一个
`CNCF`
基金会托管的开源的可信的云原生
`docker registry`
项目，可以用于存储、签名、扫描镜像内容，Harbor 通过添加一些常用的功能如安全性、身份权限管理等来扩展 docker registry 项目，此外还支持在 registry 之间复制镜像，还提供更加高级的安全功能，如用户管理、访问控制和活动审计等，在新版本中还添加了
`Helm`
仓库托管的支持。
...
...
@@ -19,7 +19,7 @@
至此，整个登录过程完成，整个过程可以用下面的流程图来说明：
要完成上面的登录认证过程有两个关键点需要注意：怎样让 registry 服务知道服务认证地址？我们自己提供的认证服务生成的 token 为什么 registry 就能够识别？
...
...
@@ -616,16 +616,16 @@ harbor-harbor-ingress registry.qikqiak.com,notary.qikqiak.com 80,
### Harbor Portal
添加完成后，在浏览器中输入
`registry.qikqiak.com`
就可以打开熟悉的 Harbor 的 Portal 界面了，当然我们配置的 Ingress 中会强制跳转到 https，所以如果你的浏览器有什么安全限制的话，需要信任我们这里 Ingress 对应的证书，证书文件可以通过查看 Secret 资源对象获取：
然后输入用户名：admin，密码：Harbor12345（当然我们也可以通过 Helm 安装的时候自己覆盖 harborAdminPassword）即可登录进入 Portal 首页：
我们可以看到有很多功能，默认情况下会有一个名叫
`library`
的项目，改项目默认是公开访问权限的，进入项目可以看到里面还有 Helm Chart 包的管理，可以手动在这里上传，也可以对改项目里面的镜像进行一些配置，比如是否开启自动扫描镜像功能：
### docker cli
...
...
@@ -690,7 +690,7 @@ latest: digest: sha256:4415a904b1aca178c2450fd54928ab362825e863c0ad5452fd020e92f
推送完成后，我们同样可以在 Portal 页面上看到这个镜像的信息：
镜像 push 成功，同样可以测试下 pull：
...
...
docs/64.Gitlab.md
浏览文件 @
e5b43388
...
...
@@ -287,17 +287,17 @@ redis-8446f57bdf-4v62p 1/1 Running 0 17
可以看到都已经部署成功了，然后我们可以通过 Ingress 中定义的域名
`git.qikqiak.com`
(需要做 DNS 解析或者在本地 /etc/hosts 中添加映射)来访问 Portal：
使用用户名 root，和部署的时候指定的超级用户密码
`GITLAB_ROOT_PASSWORD=admin321`
即可登录进入到首页：
Gitlab 运行后，我们可以注册为新用户并创建一个项目，还可以做很多的其他系统设置，比如设置语言、设置应用风格样式等等。
点击
`Create a project`
创建一个新的项目，和之前 Github 使用上没有多大的差别：
创建完成后，我们可以添加本地用户的一个
`SSH-KEY`
，这样我们就可以通过 SSH 来拉取或者推送代码了。SSH 公钥通常包含在
`~/.ssh/id_rsa.pub`
文件中，并以
`ssh-rsa`
开头。如果没有的话可以使用
`ssh-keygen`
命令来生成，
`id_rsa.pub`
里面的内容就是我们需要的 SSH 公钥，然后添加到 Gitlab 中。
...
...
@@ -326,7 +326,7 @@ spec:
注意上面 ssh 对应的 nodePort 端口设置为 30022，这样就不会随机生成了，重新更新下 Deployment 和 Service，更新完成后，现在我们在项目上面 Clone 的时候使用 ssh 就会带上端口号了：
现在就可以使用
`Clone with SSH`
的地址了，由于上面我们配置了 SSH 公钥，所以就可以直接访问上面的仓库了：
```
shell
...
...
@@ -354,7 +354,7 @@ To ssh://git@git.qikqiak.com:30022/root/gitlab-demo.git
然后刷新浏览器，就可以看到刚刚创建的 Git 仓库中多了一个 README.md 的文件：
到这里就表明我们的 Gitlab 就成功部署到了 Kubernetes 集群当中了。
...
...
docs/65.Gitlab CI.md
浏览文件 @
e5b43388
...
...
@@ -81,7 +81,7 @@ To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
前面的章节中我们已经成功安装了 Gitlab，在浏览器中打开
`git.qikqiak.com`
页面，然后登录后进入到管理页面
`http://git.qikqiak.com/admin`
，然后点击导航栏中的
`Runner`
，可以看到该页面中有两个总要的参数，一个是 URL，另外一个就是 Register Token，下面的步骤中需要用到这两个参数值。
> 注意：不要随便泄露 Token
...
...
@@ -311,7 +311,7 @@ gitlab-ci-runner-1 1/1 Running 0 3m
可以看到已经成功运行了两个（具体取决于
`StatefulSet`
清单中的副本数) Runner 实例，然后切换到 Gitlab Admin 页面下面的 Runner 页面：
当然我们也可以根据需要更改 Runner 的一些配置，比如添加 tag 标签等。
...
...
@@ -331,7 +331,7 @@ $ git push -u origin master
```
当我们把仓库推送到 Gitlab 以后，应该可以看到 Gitlab CI 开始执行构建任务了:
此时 Runner Pod 所在的 namespace 下面也会出现两个新的 Pod：
```
shell
...
...
@@ -347,7 +347,7 @@ runner-9rixsyft-project-2-concurrent-1t74t9 0/2 ContainerCreating 0
这两个新的 Pod 就是用来执行具体的 Job 任务的，这里同时出现两个证明第一步是并行执行的两个任务，从上面的 Pipeline 中也可以看到是 test 和 test2 这两个 Job。我们可以看到在执行 image_build 任务的时候出现了错误：
我们可以点击查看这个 Job 失败详细信息：
```
shell
...
...
@@ -361,7 +361,7 @@ ERROR: Job failed: command terminated with exit code 1
定位到项目 -> 设置 -> CI/CD，展开
`Environment variables`
栏目，配置镜像仓库相关的参数值：
配置上后，我们在上面失败的 Job 任务上点击“重试”，在重试过后依然可以看到会出现下面的错误信息：
...
...
@@ -473,7 +473,7 @@ xxxxxxtoken值xxxx
填写上面对应的值添加集群：
...
...
@@ -779,21 +779,21 @@ $ git push origin master
现在回到 Gitlab 中可以看到我们的项目触发了一个新的 Pipeline 的构建：
可以查看最后一个阶段（stage）是否正确，如果通过了，证明我们已经成功将应用程序部署到 Kubernetes 集群中了，一个成功的`review`阶段如下所示：
整个 Pipeline 构建成功后，我们可以在项目的环境菜单下面看到多了一个环境：
如果我们点击`终止`，就会调用`.gitlab-ci.yml`中定义的钩子`on_stop: stop_review`，点击`View deployment`就可以看到这次我们的部署结果（前提是DNS解析已经完成）：
这就是关于 Gitlab CI 结合 Kubernetes 进行 CI/CD 的过程，具体详细的构建任务还需要结合我们自己的应用实际情况而定。下节课给大家介绍使用 Jenkins + Gitlab + Harbor + Helm + Kubernetes 来实现一个完整的 CI/CD 流水线作业。
docs/66.devops.md
0 → 100644
浏览文件 @
e5b43388
此差异已折叠。
点击以展开。
gitlab-ci-k8s-demo
@
62ec25b6
Subproject commit 62ec25b629f8a7c174c40916c38293694bcf6e5d
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑！
取消
想要评论请
注册
或
登录
