一、部署环境说明

1、 节点操作系统：CentOS Linux 7.3.1611；

2、 主机及角色（主机名基于 hosts 文件或 dns 服务解析）：

IP 地址

主机名

节点角色

172.16.0.69

master, etcd1, registry

master, etcd, private registry, chrony server

172.16.0.67

node1.magedu.com

node1

172.16.0.68

node2.magedu.com

node2

如果基于 hosts 文件解析主机名，各节点 hosts 文件内容如下：

172.16.0.67 node1.magedu.com node1172.16.0.68 node2.magedu.com node2172.16.0.69 master.magedu.com master etcd1 registry

3、 各节点通过 chrony 服务器完成时间同步；

4、各节点关闭 firewalld.service 或 iptables.service，并确保其不会自动启动；

二、部署 etcd

2.1 服务注册（Service Registration）和服务发现（Service Discovery）

服务发现是大多数分布式系统或面向服务的架构中的核心组件之一，它的出现是用于解决此类环境中普遍面临的一个问题——客户端如何获知运行于多个节点之上的服务的 IP 地址和端口？

解决此类问题的方案有两个。一是静态配置，直接将服务的相关信息写入配置文件。然而，服务数量较大时其配置复杂度会指数级上升，更何况对于一个支持自动缩扩容的系统来说，其服务地址并非固定不变，此时就需要第二种解决方案：动态服务注册和发现。

服务注册：服务进程将其信息写入"中心注册表（central registry）"，这些信息通常包括 IP 地址、端口、认证标识、协议、版本号及其它环境信息；服务发现：客户端程序的相关进程查询中心注册表服务器，以获知目标服务的相关信息；

通常情况下，多数服务发现解决方案还能够或者必须提供额外功能，例如服务健康状态监控、负载均衡、访问集成（整合多个语言客户端）、运行时依赖关系及可用性提升等。

此类问题的解决方案有两类：一类是通用目的的实现，它们基于强一致性协议提供一致性数据存储，例如 Zookeeper、etcd、Doozer 和 Consul 等，它们不但可用于服务注册和服务发现，也常被用于服务协作中的其它多种功能，例如 leader election，以及 centralized locking 等。

另一类是专用实现，它们仅用于服务注册和服务发现，例如 Airbnb 的 SmartStack、Netflix的 Eureka、Bitly 的 NSQ lookupd、Serf，以及 SkyDNS 等。

2.2 etcd 概述

etcd is an open-source distributed key value store that provides shared configuration and service discovery for Container Linux clusters. etcd runs on each machine in a cluster and gracefully handles leader election during network partitions and the loss of the current leader.

Application containers running on your cluster can read and write data into etcd.Common examples are storing database connection details, cache settings, featureflags, and more.

Etcd is a highly-available, key-value store for shared configuration and service discovery.Etcd was inspired by Zookeeper and Doozer. It's written in Go, uses Raft for consensusand has a HTTP+JSON based API.

Etcd is typically run with three, five or seven members in the ensemble.Clients use a language specific binding or implement one using an HTTP client.

Service registration relies on using a key TTL along with heartbeating from the service to ensure the key remains available. If a services fails to update the key's TTL, Etcd will expire it. If a service becomes unavailable, clients will need to handle the connection failure and try another service instance.

Service discovery involves listing the keys under a directory and then waiting for changes on the directory. Since the API is HTTP based, the client application keeps a long-polling connection open with the Etcd cluster.

Since Etcd uses Raft, it should be a strongly-consistent system. Raft requires a leader to be elected and all client requests are handled by the leader. However, Etcd also seems to support reads from non-leaders using this undocumented consistent parameter which would improve availabilty in the read case. Writes would still need to be handled by the leader during a partition and could fail.

2.3 Kubernetes 场景中的 etcd 部署方式

开发或测试环境

2.4 部署 etcd

部署单节点 etcd

etcd 程序包位于 CentOS 7 的 Extras 仓库中，配置得当后，执行如下命令即可完成安装。

master ~]# yum install etcd

etcd 服务需要提供 kubernetes 集群的所有节点，因此需要监听于可用于外部通信的地址。编辑/etc/etcd/etcd.conf 配置文件，修改如下选项的值中的"localhost"为合适的值即可，例如此示例中的 master，即对应的 IP 地址 172.16.0.69。

# [member]

ETCD_NAME=etcd1

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

#ETCD_LISTEN_PEER_URLS=";

ETCD_LISTEN_CLIENT_URLS=

#[cluster]

#ETCD_INITIAL_ADVERTISE_PEER_URLS=";

ETCD_INITIAL_CLUSTER="etcd1=;

#ETCD_INITIAL_CLUSTER_STATE="new"

#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"

ETCD_ADVERTISE_CLIENT_URLS=";

上述的各选项的意义如下：

ETCD_NAME：当前节点的名称；ETCD_LISTEN_CLIENT_URLS：当前节点用于与 etcd 客户端通信的 URL 列表，彼此间以逗号分隔； ECTD_ADVERTISE_CLIENT_URLS：当前节点向外通告的其用于与客户通信的 URL 列表； ETCD_INITIAL_CLUSTER：用于 etcd 启动时初始化的集群配置；构建一个多节点的 etcd集群时，需要让集群成员间通信的端口监听于对外通信的 IP 地址上，默认为 localhost；以下两个选项可用于此配置；ETCD_LISTEN_PEER_URLS：list of URLs to listen on for peer traffic.ETCD_INITIAL_ADVERTISE_PEER_URLS：list of this member's peer URLs to advertise to the rest of the cluster.

而后启动 etcd 服务即可。

master ~]# systemctl start etcd.service

查看 etcd 集群成员列表：

master ~]# etcdctl -C member list

64d0398ed3861f26: name=etcd1 peerURLs=

clientURLs= isLeader=true

查看集群健康状态：

master ~]# etcdctl -C cluster-health

member 64d0398ed3861f26 is healthy: got healthy result from

etcdctl 的各子命令及其功能：

backup：backup an etcd directory

cluster-health：check the health of the etcd cluster

mk：make a new key with a given value

mkdir：make a new directory

rm：remove a key or a directory

rmdir：removes the key if it is an empty directory or a key-value pair

get：retrieve the value of a key

ls：retrieve a directory

set：set the value of a key

setdir：create a new directory or update an existing directory TTL

update：update an existing key with a given value

updatedir：update an existing directory

watch：watch a key for changes

exec-watch：watch a key for changes and exec an executable

member：member add, remove and list subcommands

user：user add, grant and revoke subcommands

role：role add, grant and revoke subcommands

auth：overall auth controls

help, h：Shows a list of commands or help for one command

部署 etcd 集群

etcd 集群的启动方式支持三种机制：

Static（静态）：集群成员固定，初始化前直接指定成员主机 URL 即可；etcd Discovery（etcd 发现）：集群成员地址不固定，此时可利用已经存在 etcd 集群来发现并创建一个新的集群，发现方式是 etcd 标识； DNS Discovery（DNS 发现）：集群成员地址不固定，此时可利用已经存在 etcd 集群来发现并创建一个新的集群，发现方式是 DNS SRV records；

具体的配置过程，请参考官方文档。

三、部署 kubernetes master 节点

3.1 master 节点功能概述

Kubernetes master 包含三个核心组件：API Server、Scheduler 和 Controller Manager，它们分别对应于一个要启动的服务，kube-apiserver、kube-scheduler 和 kube-controller-manager。

API Server：The Kubernetes API server validates and configures data for the apiobjects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster's sharedstate through which all other components interact.Scheduler ： The Kubernetes scheduler is a policy-rich, topology-aware,workload-specific function that significantly impacts availability, performance, and capacity. The scheduler needs to take into account individual and collective resource requirements, quality of service requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, deadlines, and so on. Workload-specific requirements will be exposed through the API as necessary.Controller Manager：The Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.

3.2 部署 master 节点

kubernetes 由 CentOS 7.3.1611 的 Extras 仓库提供，配置完成后使用如下命令即可完成安装。

master ~]# yum install kubernetes-master

kubernetes master 的配置文件位于/etc/kubernetes 目录下，主要修改的有两个：apiserver 和config。

配置 apiserver，将各选项设定为符合环境的值：

# 配置 kube-apiserver 监听的本机地址，配置多节点集群时，应该使用对外通信的地址

KUBE_API_ADDRESS="--insecure-bind-address=0.0.0.0"

# 配置 kube-apiserver 监听的商品，默认为 8080

KUBE_API_PORT="--port=8080"

# Port minions listen on

# KUBELET_PORT="--kubelet-port=10250"

# 配置 kubernetes 集群要使用的 etcd 集群的成员列表

KUBE_ETCD_SERVERS="--etcd-servers=;

# 集群内各 service 可使用的地址范围

KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"

# 默认的管理控制策略

KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitR anger,SecurityContextDeny,ServiceAccount,ResourceQuota"

# 自定义的其它配置选项

KUBE_API_ARGS=""

配置公共配置文件 config，定义 master 访问接口

# 配置错误日志记录方式

KUBE_LOGTOSTDERR="--logtostderr=true"

# 指定日志级别，0 表示 debug

KUBE_LOG_LEVEL="--v=0"

# 设定本集群中是否允许运行特权 docker 容器

KUBE_ALLOW_PRIV="--allow-privileged=false"

# 配置 controller-manager, scheduler 和 proxy 访问 master 服务的接口；

KUBE_MASTER="--master=;

3.3 启动 master 节点

此示例中，kube-apiserver、kube-scheduler 和 kube-controller-manager 均运行于 master 节点，因此直接启动它们即可。

master ~]# systemctl start kube-apiserver.service kube-scheduler.service

kube-controller-manager.service

四、部署 Kubernetes 集群的各 Node

Kubernetes 集群的各节点用于运行容器，因此部署 kubernetes 的相关组件之前需要事先提供容器相关的环境（Container runtime），例如 docker。以下操作需要在各 Node 主机分别进行。

4.1 部署并启动 Docker

docker 位于 CentOS 7.3.1611 的 Extras 仓库中，配置好之后以如下命令即可安装。

~]# yum install docker

配置好 docker 的需自定义的选项后即可启动服务，例如私有仓库等。

~]# systemctl start docker.service

4.2 部署并启动 Kubelet 和 Kubernetes Network Proxy

Kubernetes 集群的各 node 分别包含两个重要组件：Kubelet 和 Kubernetes Network Proxy，它们分别对应于一个服务 kubelet 和 kube-proxy。

kubelet：The kubelet is the primary "node agent" that runs on each node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.kube-proxy：The Kubernetes network proxy runs on each node. This reflects services as defined in the Kubernetes API on each node and can do simple TCP,UDP stream forwarding or round robin TCP,UDP forwarding across a set of backends. Service cluster ips and ports are currently found through Docker-links-compatible environment variables specifying ports opened by the service proxy. There is an optional addon that provides cluster DNS for thesecluster IPs. The user must create a service with the apiserver API to configure the proxy.

kubernetes-nodes 位于 CentOS 7.3.1611 的 Extras 仓库中，配置好之后以如下命令即可安装。

~]# yum install kubernetes-node

kubernetes node的配置文件位于/etc/kubernetes目录下，主要修改的有两个：kubelet和 config。

配置 kubelet

# kubelet 服务监听的 IP 地址 (set to 0.0.0.0 or "" for all interfaces)

KUBELET_ADDRESS="--address=0.0.0.0"

# kubelet 监听的端口

# KUBELET_PORT="--port=10250"

# 当前节点的主机名，留空表示使用本机的真实主机名

KUBELET_HOSTNAME="--hostname-override=node1"

# api-server 的访问接口

KUBELET_API_SERVER="--api-servers=;

# pod infrastructure container

KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel

7/pod-infrastructure:latest"

# 按需定义的其它选项

KUBELET_ARGS=""

配置公共配置文件 config，定义 master 访问接口

# 配置错误日志记录方式

KUBE_LOGTOSTDERR="--logtostderr=true"

# 指定日志级别，0 表示 debug

KUBE_LOG_LEVEL="--v=0"

# 设定本集群中是否允许运行特权 docker 容器

KUBE_ALLOW_PRIV="--allow-privileged=false"

# 配置 controller-manager, scheduler 和 proxy 访问 master 服务的接口；

KUBE_MASTER="--master=;

4.3 启动 node 的各服务

此示例中，kubelet 和 kube-proxy 要同时运行于 Node 节点，因此直接启动它们即可。

master ~]# systemctl start kubelet.proxy kube-proxy.service

五、集群测试

5.1 kubectl 概述

Kubernetes 的 API Server 是集群服务的访问入口，kubectl 通过 API 与集群交互完成各种管理工具，因此，kubectl 需要在管理集群之前知悉集群的访问入口，并拥有访问凭证（如果集群配置了验正和授权机制）。这些信息可以命令行选项给出，也可以通过配置文件 kubeconfigfile 设定。

Client access to a running Kubernetes cluster can be shared by copying the kubectl client config bundle (kubeconfig). This config bundle lives in $HOME/.kube/config.

In order to easily switch between multiple clusters, a kubeconfig file was defined. This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.

例如，要了解指定集群中的节点信息，可使用如下命令进行。

~]$ kubectl -s get nodes

NAME STATUS AGE

node1 Ready 36m

node2 Ready 34m

查看集群运行状态，可使用如下命令进行。

~]$ kubectl -s cluster-info

Kubernetes master is running at

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

5.2 kubectl 命令概览

kubectl 命令在线手册获取地址为 。

5.3 测试于 Kubernetes 中运行容器

kubectl run 命令能够创建并运行一个指定的可复制的镜像，它会自动创建一个 deployment或者 job 来管理创建的容器。例如，创建一个交互登录的基于 busybox 镜像的容器 bbox。

~]$ kubectl -s run -i -t bbox --image=busybox

/ #

查看集群中的"部署（deployment）资源：

~]$ kubectl -s get deployments

NAME

DESIRED

CURRENT

UP-TO-DATE

AVAILABLE

AGE

bbox

1

1

1

1

1m

查看集群中启动的 Pod：

~]$ kubectl -s get pods

NAME

READY

STATUS

RESTARTS

AGE

bbox-4272330656-t6pzw

1/1

Running

0

2m

也可以以 yaml 格式查看启动的 Pod 的详细格式的信息：

~]$ kubectl -s get -o yaml pods

„„„„

hostIP: 172.16.0.67

phase: Running

podIP: 172.17.0.2

startTime: 2017-07-31T10:32:44Z

„„„„

kubectl delete 命令可用于删除集群中的资源，例如此前使用 kubectl run 命令自动创建的

deployment 类型的资源 bbox，可使用如下命令：

~]$ kubectl -s delete deployment bbox

deployment "bbox" deleted

六、Kubernetes 的网络功能

6.1 Docker 网络模型存在的问题

With Docker, each container is assigned an IP address that can be used to communicate with other containers on the same host. For communicating over a network, containers are tied to the IP addresses of the host machines and must rely on port-mapping to reach the desired container. This makes it difficult for applications running inside containers to advertise their external IP and port as that information is not available to them.

6.2 Kubernetes 网络模型

Kubernetes 需要其原子组件 Pod 彼此间可直接通信，无论它们位于集群中的哪台主机之上。因此，每个 Pod 必须拥有一个可路由的 IP 地址，相互间无须 NAT 或端口映射即可进行数据交换。这有别于 Docker 的网络模型，使用默认网络模型的两个 Docker 主机无满足此类需求。同时，同一个 Pod 内部的各容器间可直接通过 loopback 接口进行通信，例如同一 pod 内部的 tomcat 容器可直接经由 lo 接口访问 mariadb server 容器上的数据。这种模型中，Pod 类似于 IaaS 架构中的 VM，同一 VM 上运行的多个 application 极容易迁移至 Pod 的容器上，且各 Pod 之间的通信也类似于各 VM 之间的通信。

Kubernetes PAUSE container

Kubernetes 的每个 Pod 中均存在一个名为"PAUSE"的容器，它持有 Pod 的 IP 地址等网络属性，并将网络名称空间共享给当前 Pod 中的其它容器，这些容器是 Pod 的 joined网络类型的容器。

在 Pod 内部，每个容器以"映射容器（mapped container）"模型连接至 PAUSE 容器，通信过程中，目标地址为 Pod IP 地址的流量首先到达 PAUSE 容器，而后再由 PAUSE 容器转发至后端的一个或多个容器。此种模型中，PAUSE 容器也被称作"目标容器（target container）"，而其它容器被称为"源容器（source container）"。

概括来讲，Kubernetes 的网络模型中存在四种通信模式：

同一 Pod 内部的容器间通信：籍由同一网络名称空间中的 lo 接口进行；Pod 间的通信：同一 Kubernetes 集群中的所有 Pod 拥有同一 IP 网络中的地址，Pod彼此间可通过 IP 地址直接通信；Pod 与 Service 间的通信：Service 的核心是 VIP，它能够直接接受客户端的请求，并将请求代理至与此服务关联的各 Pod；其过程是到达 Service 的请求被发往各 Node主机的 kube-proxy 进程，并由其路由至相关的 Pod；来自集群外部的访问：集群中的节点拥有公网 IP（External IP）地址时，Kubernetes可将服务"暴露"至此些 IP 地址；到此些 IP 地址上的服务端口的访问流量会被路由至 Service 的端点，而后由 kube-proxy 转发至目标 Pod；External IP 非由 Kubernetes

管理，管理员需要完成此工作；

Kubernetes 网络解决方案

Kubernetes 虽然设计了网络模型，但它自己并不实现此功能，而是借助于第三方解决解决方案，例如 Flannel、Calico、Weave、OpenContrail、Cisco Contiv 和 OpenVSwitch等等。

Flannel

Flannel is a very simple overlay network that satisfies the Kubernetes requirements.Flannel is a virtual network solution maintained by the CoreOS project. It's a well-tested,production ready solution, so it has the lowest setup cost.

Project Calico

Calico is a new approach to virtual networking and network security for containers, VMs,and bare metal services, that provides a rich set of security enforcement capabilities running on top of a highly scalable and efficient virtual network fabric. Calico includespre-integration with Kubernetes and Mesos (as a CNI network plugin), Docker (as alibnetwork plugin) and OpenStack (as a Neutron plugin). Calico supports a broad range of deployment options including on premise or public cloud (AWS, GCE, etc) providing the same rich set of features across all.

Contiv

Contiv is a open source container networking and policy fabric for heterogeneous docker container deployments across virtual machines, bare-metal, and public or private clouds. As the industry's most powerful container networking fabric, Contiv, with its Layer2, Layer3, overlay & ACI modes, natively integrates with Cisco infrastructure and maps the application intent with the infrastructure capabilities using rich networking and security policies.

6.3 叠加网络 flannel 概述

Flannel 是由 CoreOS 项目维护的虚拟网络解决方案，它是能够满足 Kubernetes 网络模型需求的极简洁实现方式，但经由充分测试且可用于生产环境，部署代价极低。

运行时，Flannel 需要首先确定自己使用的网络地址，例如"10.1.0.0/16"，而后为集群中的每个 Docker 主机分配一个子网，例如"10.1.15.0/24"或"10.1.20.0/24"等，Docker 主机将此子网地址作为本机上运行的容器的可用地址池。

同一 Docker 主机上的 Pod 间通信通过 docker0 桥即可直接进行，而跨 Docker 主机的 Pod间通信时，Pod 的报文经由本机上的 flannel 桥隧道转发其目标网络所在的 Docker 主机的flannel 桥，并到达目标网络，而后由目标 Pod 接收。如下图所示。

Flannel 将虚拟 IP 和主机地址的映射关系存于 etcd 中，运行于各主机上的 flanneld 进程负责监控 etcd 中与当前主机相关的配置信息，并完成报文路由。

6.4 安装 flannel

flannel需要运行于集群的各节点，包括master主机和各Node主机。flannel程序包位于CentOS7.3.1611 的 Extras 仓库中，配置好之后在各主机以如下命令即可完成安装。

~]# yum install flannel

6.5 配置 flannel

flannel 需要基于 etcd 存储数据，配置其使用 etcd 服务的 URL 。配置文件为/etc/sysconfig/flanneld。配置详情如下所示。

# etcd 服务器 URL 列表

FLANNEL_ETCD_ENDPOINTS=";

# flannel 向 etcd 查询网络地址池相关的配置时使用的 key，其值需要手动创建

FLANNEL_ETCD_PREFIX="/atomic.io/network"

# 传递 flanneld 程序的其它选项

#FLANNEL_OPTIONS=""

6.6 在 etcd 配置 flanneld 使用的地址池

~]# etcdctl -C mk /atomic.io/network/config '{ "Network": "10.99.0.0/16" }'

{ "Network": "10.99.0.0/16" }

6.7 启动 flanneld，并重启各服务

在 master 主机启动 flanneld 服务。

~]# systemctl start flanneld.service

在各 Node 主机上启动 flanneld 服务，并重启 docker 服务即可完成配置。

~]# systemctl start flanneld.service

~]# systemctl restart docker.service

6.8 测试

启动多个 Pod，查看其启动的主机及获得的 IP 地址，并测试各 Pod 中的容器间的连通性即可。测试方法参考上文第 5 部分。

七、Kubernetes Dashboard

7.1 Kubernetes Dashboard 概述

Kubernetes Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage applications running in the cluster and troubleshoot them, as well as manage the cluster itself.

7.2 部署 Kubernetes Dashboard

Kubernetes Dashboard 的镜像位于 gcr.io（Google Containers Registry），此站点在 GFW 的转名单列表中,无法在国内直接访问，因此简单按照官方的文档进行部署。不过，好在有人将 gcr中的镜像同步到了 dockerhub 中，例如 docker.io/mritd/kubernetes-dashboard-amd64，部署时只需简单地将 Kubernetes Dashboard 提供的部署文件中的镜像改动一下即可。

Kubernetes 1.5 部署 dashboard

首先确保集群中没有运行中 dashboard 实例：

~]$ kubectl get pods --all-namespaces | grep dashboard

而后下载部署文件 ，并修改其内容如下所示：

接着使用此文件创建 Service 和 Pod 即可。

~]$ kubectl -s create -f ./ kube-dashboard-no-rbac

查看创建的服务：

~]# kubectl -s get services

NAME

CLUSTER-IP

EXTERNAL-IP

PORT(S)

AGE

kubernetes

10.254.0.1

<none>

443/TCP

4h

通过 master 主机的 URL（/ui）即可访问 Dashboard。例如，打开浏览器，键入如下地址。

Kubernetes 1.6 部署 dashboard

请参考 中给出的说明。

八、Kubernetes 监控系统

8.1 cAdvisor 概述

cAdvisor (Container Advisor) provides container users an understanding of the resource usageand performance characteristics of their running containers. It is a running daemon that collects,aggregates, processes, and exports information about running containers. Specifically, for each container it keeps resource isolation parameters, historical resource usage, histograms of complete historical resource usage and network statistics. This data is exported by container and machine-wide.

cAdvisor has native support for Docker containers and should support just about any other container type out of the box. We strive for support across the board so feel free to open an issue if that is not the case. cAdvisor's container abstraction is based on lmctfy's so containers are inherently nested hierarchically.

cAdvisor 是开源容器资源占用率及性能分析 agent，其设计目标即为容器监控，并原生支持Docker 容器。cAdvisor 会自动发现当前主机上的所有容器，并收集 CPU、内存、文件系统和网络资源占用率相关的数据，甚至可收集当前主机的所有监控数据。

实践中，cAdvisor 运行于 Kubernetes 集群中的各主机上，收集、聚合、处理及导出当前主机上各容器的相关监控数据。Kubernetes 新近的版本已经将 cAdvisor 功能集成到 kubelet 程序中。cAdvisor 内嵌了 Web UI，并通过 ;hostname>:<port>/输出，它默认监听于 tcp 协议的 4194 端口，因此可通过各节点的 ;Node-IP>:4194/直接访问。

不过，cAdvisor 的 Web UI 仅能显示当前节点上各容器的相关数据，如果需要集成多个主机上的 cAdvisor数据于一个系统中，可以使用HeapSter。，因此 cAdvisor常作为HeapSter的 agent使用。

8.2 HeapSter 概述

Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster,similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' Kubelets, the on-machine Kubernetes agent. The Kubelet itself fetches the data from cAdvisor. Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. The overall architecture of the service can be seen below:

实践中，可将数据存储于 InfluxDB，并通过 Grafana 进行展示。

InfluxDB is an open source database written in Go specifically to handle time series data with high availability and high performance requirements. It exposes an easy to use API to write and fetch time series data. Heapster is set up to use InfluxDB as the storage backend by default on most Kubernetes clusters.

Grafana is the data visualization component in our monitoring setup. It is available out of the box in a Kubernetes cluster. The default dashboard displays resource usage of the cluster and the pods inside of it. This dashboard can easily be customized and expanded.

InfluxDB and Grafana already run in pods exposing themselves as Kubernetes services, making it easy for Heapster to discover them. With all of this already in place, there is minimal setup required to get things up and running.

HeapSter 是容器集群监控和性能分析工具，其设计上原生支持 Kubernetes 和 CoreOS，也可很容易地扩展为支持其它集群的监控。Heapster 收集并解析诸多数据指标，例如资源利用率、生命周期事件等，并将其通过 REST 端点输出为 Cluster Metrics。Heapster 监听于 tcp 协议的10025 端口。

DNS 有两种配置方式，在 1.3 之前使用 etcd + kube2sky + skydns 的方式，在 1.3 之后可以

使用 kubedns + dnsmasq 的方式。

参考文献：