本文已归档在kubernetes-handbook 中的第 3 章【用户指南】中，一切更新以 kubernetes-handbook 中为准。

为了详细说明，我特意写了两个示例程序放在 GitHub 中，模拟应用开发流程：

• k8s-app-monitor-test ：生成模拟的监控数据，发送 http 请求，获取 json 返回值
• K8s-app-monitor-agent ：获取监控数据并绘图，访问浏览器获取图表

API 文档见k8s-app-monitor-test 中的api.html文件，该文档在 API blueprint 中定义，使用aglio 生成，打开后如图所示：

关于服务发现

K8s-app-monitor-agent服务需要访问k8s-app-monitor-test服务，这就涉及到服务发现的问题，我们在代码中直接写死了要访问的服务的内网 DNS 地址（kubedns 中的地址，即k8s-app-monitor-test.default.svc.cluster.local）。

我们知道 Kubernetes 在启动 Pod 的时候为容器注入环境变量，这些环境变量在所有的 namespace 中共享（环境变量是不断追加的，新启动的 Pod 中将拥有老的 Pod 中所有的环境变量，而老的 Pod 中的环境变量不变）。但是既然使用这些环境变量就已经可以访问到对应的 service，那么获取应用的地址信息，究竟是使用变量呢？还是直接使用 DNS 解析来发现？

答案是使用 DNS，详细说明见Kubernetes 中的服务发现与 Docker 容器间的环境变量传递源码探究 。

打包镜像

因为我使用 wercker 自动构建，构建完成后自动打包成 docker 镜像并上传到 docker hub 中（需要提前在 docker hub 中创建 repo），如何使用 wercker 做持续构建与发布，并集成 docker hub 插件请参考使用 Wercker 进行持续构建与发布 。

查看详细构建流程

生成了如下两个 docker 镜像：

• jimmysong/k8s-app-monitor-test:latest
• jimmysong/k8s-app-monitor-agent:latest

启动服务

所有的 kubernetes 应用启动所用的 yaml 配置文件都保存在那两个 GitHub 仓库的manifest.yaml文件中。

分别在两个 GitHub 目录下执行kubectl create -f manifest.yaml即可启动服务。

外部访问

服务启动后需要更新 ingress 配置，在ingress.yaml 文件中增加以下几行：

  - host: k8s-app-monitor-agent.jimmysong.io
    http:
      paths:
      - path: /
        backend:
          serviceName: k8s-app-monitor-agent
          servicePort: 8080

保存后，然后执行kubectl replace -f ingress.yaml即可刷新 ingress。

修改本机的/etc/hosts文件，在其中加入以下一行：

172.20.0.119 k8s-app-monitor-agent.jimmysong.io

当然你也可以加入到 DNS 中，为了简单起见我使用 hosts。

详见边缘节点配置 。

在浏览器中访问 http://k8s-app-monitor-agent.jimmysong.io

刷新页面将获得新的图表。

参考

• 使用 Wercker 进行持续构建与发布
• 示例的项目代码服务器端
• 示例项目代码前端
• kubernetes-handbok
• 边缘节点配置