Kubernetes 开发了一个 Elasticsearch 附加组件来实现集群的日志管理。这是一个 Elasticsearch、Fluentd 和 Kibana 的组合。Elasticsearch 是一个搜索引擎，负责存储日志并提供查询接口；Fluentd 负责从 Kubernetes 搜集日志并发送给 Elasticsearch；Kibana 提供了一个 Web GUI，用户可以浏览和搜索存储在

CloudMan 在实践时使用的是 Prometheus Operator 版本 v0.14.0。由于项目开发迭代速度很快，部署方法可能会更新，必要时请参考官方文档。 下载最新源码 git clone cd prometheus-operator 为方便管理，创建一个单独的 Namespace monitoring，Prometheus Operator 相关的组件都会部署到这个 Namespace。

本节讨论 Prometheus Operator 的架构。 因为 Prometheus Operator 是基于 Prometheus 的，我们需要先了解一下 Prometheus。 Prometheus 架构 Prometheus 是一个非常优秀的监控工具。准确的说，应该是监控方案。Prometheus 提供了数据搜集、存储、处理、可视化和告警一套完整的解决方案。Prometheus 的架构如下图所示：

前面我们介绍了 Kubernetes 的两种监控方案 Weave Scope 和 Heapster，它们主要的监控对象是 Node 和 Pod。这些数据对 Kubernetes 运维人员是必须的，但还不够。我们通常还希望监控集群本身的运行状态，比如 Kubernetes 的 API Server、Scheduler、Controller Manager 等管理组件是否正常工作，负荷是否过大等？

Heapster 是 Kubernetes 原生的集群监控方案。Heapster 以 Pod 的形式运行，它会自动发现集群节点、从节点上的 Kubelet 获取监控数据。Kubelet 则是从节点上的 cAdvisor 收集数据。 Heapster 将数据按照 Pod 进行分组，将它们存储到预先配置的 backend 并进行可视化展示。Heapster 当前支持的 backend 有 InfluxDB（通过

创建 Kubernetes 集群并部署容器化应用只是第一步。一旦集群运行起来，我们需要确保一起正常，所有必要组件就位并各司其职，有足够的资源满足应用的需求。Kubernetes 是一个复杂系统，运维团队需要有一套工具帮助他们获知集群的实时状态，并为故障排查提供及时和准确的数据支持。 本章重点讨论 Kubernetes 常用的监控方案，下一章会讨论日志管理。 Weave Scope Weave Scope

上一节我们完成了 Kubernetes Dashboard 的安装，本节就来实践一下。 Dashboard 界面结构 Dashboard 的界面很简洁，分为三个大的区域。 顶部操作区 在这里用户可以搜索集群中的资源、创建资源或退出。 左边导航菜单 通过导航菜单可以查看和管理集群中的各种资源。菜单项按照资源的层级分为两类： Cluster 级别的资源 Namespace 级别的资源 默认显示的是 default

前面章节 Kubernetes 所有的操作我们都是通过命令行工具 kubectl 完成的。为了提供更丰富的用户体验，Kubernetes 还开发了一个基于 Web 的 Dashboard，用户可以用 Kubernetes Dashboard 部署容器化的应用、监控应用的状态、执行故障排查任务以及管理 Kubernetes 各种资源。 在 Kubernetes Dashboard

为了演示 Network Policy，我们先部署一个 httpd 应用，其配置文件 httpd.yaml 为： httpd 有三个副本，通过 NodePort 类型的 Service 对外提供服务。部署应用： 当前没有定义任何 Network Policy，验证应用可以被访问： 启动一个 busybox Pod，可以访问 Service，也可以 Ping 到副本 Pod。 集群节点可以访问 Service，

Network Policy 是 Kubernetes 的一种资源。Network Policy 通过 Label 选择 Pod，并指定其他 Pod 或外界如何与这些 Pod 通信。 默认情况下，所有 Pod 是非隔离的，即任何来源的网络流量都能够访问 Pod，没有任何限制。当为 Pod 定义了 Network Policy，只有 Policy 允许的流量才能访问 Pod。 不过，不是所有的 Kubernetes

网络模型有了，如何实现呢？ 为了保证网络方案的标准化、扩展性和灵活性，Kubernetes 采用了 Container Networking Interface（CNI）规范。 CNI 是由 CoreOS 提出的容器网络规范，它使用了插件（Plugin）模型创建容器的网络栈。 CNI 的优点是支持多种容器 runtime，不仅仅是 Docker。CNI

本节我们讨论 Kubernetes 网络这个重要主题。 Kubernetes 作为编排引擎管理着分布在不同节点上的容器和 Pod。Pod、Service、外部组件之间需要一种可靠的方式找到彼此并进行通信，Kubernetes 网络则负责提供这个保障。本章包括如下内容： Kubernetes 网络模型 各种网络方案 Network Policy Kubernetes 网络模型 Kubernetes

安装 chart 当我们觉得准备就绪，就可以安装 chart，Helm 支持四种安装方法： 安装仓库中的 chart，例如：helm install stable/nginx 通过 tar 包安装，例如：helm install ./nginx-1.2.3.tgz 通过 chart 本地目录安装，例如：helm install ./nginx 通过 URL 安装，例如：helm install

Kubernetes 给我们提供了大量官方 chart，不过要部署微服务应用，还是需要开发自己的 chart，下面就来实践这个主题。 创建 chart 执行 helm create mychart 的命令创建 chart mychart： Helm 会帮我们创建目录 mychart，并生成了各类 chart 文件。这样我们就可以在此基础上开发自己的 chart 了。 新建的 chart 默认包含一个

学习了 chart 结构和模板的知识后，现在重新实践一次 MySQL chart，相信会有更多收获。 chart 安装前的准备 作为准备工作，安装之前需要先清楚 chart 的使用方法。这些信息通常记录在 values.yaml 和 README.md 中。除了下载源文件查看，执行 helm inspect values 可能是更方便的方法。 输出的实际上是 values.yaml 的内容。阅读注释就可以知道

Helm 通过模板创建 Kubernetes 能够理解的 YAML 格式的资源配置文件，我们将通过例子来学习如何使用模板。 以 templates/secrets.yaml 为例： 从结构看，文件的内容非常像 Secret 配置，只是大部分属性值变成了{{ xxx }}。这些 {{ xxx }} 实际上是模板的语法。Helm 采用了 Go 语言的模板来编写 chart。Go

chart 是 Helm 的应用打包格式。chart 由一系列文件组成，这些文件描述了 Kubernetes 部署应用时所需要的资源，比如 Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap 等。 单个的 chart 可以非常简单，只用于部署一个服务，比如 Memcached；chart 也可以很复杂，部署整个应用，比如包含 HTTP

Helm 安装成功后，可执行 helm search 查看当前可安装的 chart。 这个列表很长，这里只截取了一部分。大家不禁会问，这些 chart 都是从哪里来的？ 前面说过，Helm 可以像 apt 和 yum 管理软件包一样管理 chart。apt 和 yum 的软件包存放在仓库中，同样的，Helm 也有仓库。 Helm 安装时已经默认配置好了两个仓库：stable 和 local。stable

本节我们将安装和部署 Helm 客户端和 Tiller 服务器。 Helm 客户端 通常，我们将 Helm 客户端安装在能够执行 kubectl 命令的节点上，只需要下面一条命令： curl | bash 执行 helm version 验证。 目前只能查看到客户端的版本，服务器还没有安装。 helm 有很多子命令和参数，为了提高使用命令行的效率，通常建议安装 helm 的 bash 命令补全脚本，方法如下：

在实践之前，我们先来看看 Helm 的架构。 Helm 有两个重要的概念：chart 和 release。 chart 是创建一个应用的信息集合，包括各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。可以将 chart 想象成 apt、yum 中的软件安装包。 release 是 chart 的运行实例，代表了一个正在运行的应用。当