Kubernetes 1.6 伸缩性升级:5000 Node 和 15 万个 Pod

上个夏天,我们分享了 Kubernetes 的伸缩性更新,经过一番努力,我们自豪的宣布 Kubernetes 1.6 能够处理 5000 个节点的集群和 15 万个 Pod 了;另外即使在这种负载规模下,端到端的 Pod 启动速度依然优于 2000 节点规模的 1.3 版本的 Kubernetes 集群,API 调用的延迟依然满足 1 秒的 SLO。

本文中我们会讨论到

  • 性能测试的指标和结果
  • 提高性能的改进
  • 未来在伸缩性方面的发展计划

XX 节点的集群意味着什么?

现在 Kubernetes 1.6 已经发布,那么当我们说到支持多少个节点的集群的时候,我们到底在说什么?前文说过,我们有两个性能相关的服务水平目标(SLO)

编写易移植的 PVC

如果你在编写配置模板或者是一个可能在很多不同集群下运行的配置,要在其中包含持久存储,我们提供一些建议:

Kubernetes (1.6) 中的存储类及其动态供给

有状态容器的工作过程中,存储是一个关键问题,Kubernetes 对存储的管理提供了有力的支持。Kubernetes 独有的动态卷供给特性,实现了存储卷的按需创建。在这一特性面世之前,集群管理员首先要给云供应商或者存储供应商致电,来申请新的存储卷,然后创建持久卷(PersistentVolue),使其在 Kubernetes 中可见。而动态卷供给功能则实现了这两个步骤的自动化,让管理员无需再进行存储卷预分配。存储资源会依照 StorageClass 定义的方式进行供给。StorageClass 是对底层存储资源的抽象,包含了存储相关的参数,例如磁盘类型(标准类型和 SSD)。

StorageClass 的多种供给者(Previsioner),为 Kubernetes 提供了针对特定物理存储或云存储的访问能力。目前提供了多种开箱即用的存储支持,另外还有一些在 Kubernetes 孵化器中提供的其他存储支持。

在 Kubernetes 1.6 中,动态卷供给提升为稳定版(1.4 开始进入 Beta 版)。这在 Kubernetes 的存储自动化过程中是很重要的一步,让管理员能够控制资源的供给方式,让用户能够更专注于自己的应用。在上面提到的益处之外,在升级到 Kubernetes 1.6 之前,还需要了解一下这里涉及到的针对用户方面的变更。

Helm 简介

概念

  • Chart:一个 Helm 包,其中包含了运行一个应用所需要的工具、资源定义等,还可能包含 Kubernetes 集群中的服务定义,类似 Homebrew 中的 formula,APT 的 dpkg 或者 Yum 的 RPM 文件,
  • Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上,一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart,如果想在服务器上运行两个数据库,就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release,会有自己的 Release 名称。
  • Repository:用于存放和共享 Chart 的仓库。

简单说来,Helm 整个系统的主要任务就是,在仓库中查找需要的 Chart,然后把 Chart 以 Release 的形式安装到 Kubernetes 之中

OpenVAS 打包记

docker pull dustise/openvas

git clone https://github.com/fleeto/docker-openvas.git


上回书说到的 OpenVAS,其中的安装过程用的居然不是 Docker,其主要原因有:

  • 第一,安装使用都不熟悉,直接上手第三方比较容易跑偏,官网靠谱一点(现在我知道了,官网也有不靠谱的)。
  • 第二,因为上面的原因,Docker Hub 上的 mikesplain/openvas-docker 不得要领,尤其是客户端连接这部分。(后来知道他的强制更新高估了天朝的网络条件)。
  • 第三,我喜新厌旧,不想用老旧的 8 版本。
  • 第四,多语言支持,在上述 Docker Hub 版本上删节了。

但是作为一个容器云鼓吹者,不弄个顺手的封装的确是不合适的,所以花了些时间,重新来了一次,中间波折蛮多,不过也多了些容器封装方面的经验,就此记录下来。

OpenVAS 的简单安装和使用

OpenVAS 是一个开源的漏洞评估系统。

环境准备

  • 这里用 CentOS 7 Minimal 版本开始安装
  • 开始之前,首先关闭 Selinux 和 firewalld,以免造成一些不必要的干扰,安装完成后可以酌情开启。
  • 考虑到一些特殊的网络状况,可能需要设置代理服务器,注意后面的安装可能用到 RSYNC,所以设置代理的时候也要加上:RSYNC_PROXY=10.211.55.2:8016 诸如此类的语句。

最后是一些必要的工具准备:

yum install -y bzip2 wget net-tools 

安装

安装过程需要借助第三方源进行,简单的一个命令:

wget -q -O - http://www.atomicorp.com/installers/atomic | sh

注意代理服务器

利用 Telegraf 进行简单的系统监控

InfluxData 除了广为人知的 InfluxDB 之外,还有几个其他的产品,合称 TICK:

  • Telegraf:数据采集
  • InfluxDB:数据存储
  • Chronograf:数据展现
  • Kapacitor:数据分析、告警

在翻看 InfluxDB 的时候偶然发现了这个东西,虽然 Tick 四兄弟捆起来也不够看,不过 Telegraf 足够小巧,而且自动化的可能性更大,更符合目前的做事风格,所以就学习一下。

官宣: The plugin-driven server agent for collecting & reporting metrics.

所以 Telegraf 主要是一个框架,由数据输入、处理、输出三大类插件完成各种功能。Github 的 README.md 中列出了主要插件:https://github.com/influxdata/telegraf。总的来说还是比较丰富的,下面的操作将利用简单的输入插件结合 InfluxDB 输出插件完成一个初步的指标收集过程。

简单的 Kubernetes Pod 日志查看工具 Kubetail

Tags: 

​传统来说,Kubernetes 环境下的日志都是靠 FluentD + ElasticSearch + Kibana 的组合实现的,这一组合的功能和强大,所以成为一个事实标准来使用,但是在一些比较简陋的测试集群中,或者不具备浏览器条件的自动化/控制台环境下,归并多个 Pod 的日志进行集中的查看和处理还是很有用的。

Kubetail 是一个 Bash 脚本,功能类似kubectl -f logs pod-name,但是不同的是,他同时对多个 Pod 工作,并把日志合并到一个流中。

项目网址:github

安装

只是个脚本,可以直接下载安装。

Mac 用户:

brew tap johanhaleby/kubetail && brew install kubetail

使用

kubetail [-h] [-c] [-n] [-t] [-l] [-s] pod-name-prefix

InfluxDB 小窍门(2.16.2017)

Tags: 

从查询结果中排除空字段

Q: GROUP BY time() 是个很有用的东西,但是我发现我的查询中返回了大量的空字段值。我觉得不论时间范围内是否有数据,系统都会给 GROUP BY time() 中的每个时间间隔都返回个Timestamp。我的工作中面对的是一系列的不规则的时序数据,有没有什么办法让 GROUP BY time() 只在有真正的字段数据的时候才返回结果?

我的查询:

SELECT SUM("candied") FROM "hearts" \
WHERE time >= '2017-02-14T16:00:00Z' AND time <= '2017-02-14T22:00:00Z' \
GROUP BY time(1h)

结果:

借助 Calico,管窥 Kubernetes 网络策略

Kubernetes 提出了一系列 CXI 的标准容器接口,其中的 CNI 以插件方式支持多种网络。新增的 networkpolicy API 对象,提供了对网络策略的支持,本文以 Calico 为例,实际操作一个网络策略的创建和测试。

页面