Kubernetes 集群资源的那些事

大多数时候,我们在跟 K8S 玩耍的时候,主要目的就是:“把 XXX 打个镜像,在集群上跑起来 ——— 诶快看,真的跑起来了嘿!”。

Kubernetes 和 Docker 的缺省配置,就能够帮我们省却很多麻烦。不过大家都很清楚,资源问题是无法回避的,我们在传统 IT 环境下遇到的各种资源相关问题,在容器集群环境下一样要得到解决,多租户动态分配环境下,这些问题会更加复杂。

本文仅是一个索引,不准备也没能力做过多的深入,只是将一些需要注意的内容罗列出来做一些大致介绍。

有些内容称作资源可能并不是很恰当,暂时存在资源这个筐里吧。

磁盘

Volume

一般我们会用存储卷的方式来给 Pod 提供存储资源。

起初的存储卷,在用量的控制方面,只能借存储的实际提供者的能力来进行。例如可以限制 GlusterFS 中 Volume 的大小。

从头开始:Redmine 和 Gitlab 的集成和联动

本文的操作将达成如下目的:

  1. 在 Redmine 中查看 GitLab 仓库中的变更。
  2. Redmine 中更新 Gitlab 仓库。
  3. 利用 Git Commit Log 改变 Redmine 中的 Issue 状态。

工作环境

该过程在 Kubernetes 环境中完成。

Redmine:sameersbn/redmine:3.3.1 Gitlab:官方镜像

Redmine 设置

系统仓库设置

以管理员身份登入 Redmine,进入 Administration -> Repositoriessettings?tab=repositories)。

为 Gitlab 和 Jenkins 添加 InfluxDB 支持

概述

量化和监控对现在的开发运维工作的重要性是毋庸置疑的。在大肆鼓吹 DevOps 的今天,一体化的数据采集和可视化展示就尤为重要了。

为了能在同一视图下对 Jenkins 和 Gitlab 的操作进行监控,本来写了一些数据采集的脚本,后发现这两个系统都有实现向 InfluxDB 发送指标数据的能力,虽说结构和数据的细致程度可能不及定制脚本,但懒人方案始终是更快的解决办法。

非常对不起各位的是,下面的内容主要是堆代码了。

环境准备

Docker

为方便部署,这里采用 Docker 作为执行环境,过程中需要下载一些镜像,所以这里可能要配置代理或者其他途径来获得镜像文件并导入。

这里假设宿主机 IP 为 10.211.55.5

网络

因为几个组件之间互相需要访问,因此我们首先用如下命令创建一个虚拟网络:

docker network create devops

VMWare Harbor 在 Kubernetes 上的部署

VMWare 家的 Harbor 是我目前能免费得到的最好的私库管理工具了,除了解决了基础的镜像存储、权限控制这些基础能力之外,还具备 对 DevOps 非常有帮助的镜像同步功能

原本这一产品只提供了基于 Docker Composer 的部署方法,后由社区为其新增了 Kubernetes 的部署支持。本文大部分基于官方文档而来。

部署过程大概分这样几个步骤:

  1. 环境准备
  2. 配置
  3. 运行

环境准备

  • 首先是需要有一个正常运行的 Kubernetes 环境,需要提供对持久卷和 Config Map 的支持,没记错的话应该是 1.2。

  • 下文需要执行的脚本需要 Python 2.6 的支持。

镜像获取和上传

https://github.com/vmware/harbor/releases可以找到离线版本的二进制文件包。

利用 Gitlab 为 Sonarqube 提供单点登录服务

Gitlab 很贴心的提供了一个 Oauth 2 功能,可以作为 CI/CD 工具链的认证中心来使用。

Sonarqube 的官方插件只有一个 Github 的支持插件,因此这一功能需要借助第三方插件来完成。

项目地址

https://gitlab.talanlabs.com/gabriel-allaigre/sonar-auth-gitlab-plugin

下载地址

http://nexus.talanlabs.com/content/groups/public_release/com/synaptix/sonar-auth-gitlab-plugin/1.0.0/sonar-auth-gitlab-plugin-1.0.0.jar

Linkerd + Namerd,实现 Kubernetes 集群的灰度发布

主要内容源于 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ,砍掉了 Jenkins 等附加部分,更换了更加易于理解的示例应用,以保证主干突出。

Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程,然而其滚动过程并不容易控制,对于灰度发布的需要来说,仍稍显不足,这里介绍一种利用 Linkerd 方案进行流量切换的思路。

官网介绍:linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。

本文从实际操作入手,上线两个版本的简单应用,利用这一组合完成流量的切换和测试过程。

Grafana 和 Elasticsearch

容器化和微服务,让世界花枝招展,又支离破碎。一个典型的运行在容器云之上的微服务架构的应用,通常是由多种服务和基础设施的支撑而来的。这对运维工作提出一个很大的挑战 —— 一个应用后端的众多系统,究竟是怎样的工作状况?

事实上,所有构成这一应用的微服务以及支撑这一应用的所有基础设施,都会有各自的日志、指标数据,以及构建在上游的监控、日志系统。各处分散的数据和系统,会给支持团队造成极大的负担,也最终成为开发运维工作的拦路虎。

之前的经验中,可以把自家应用的各种业务、技术指标通过 Zabbix 或者 influxDB 进行存储,经由 Grafana 的插件系统进行整合展示,目前流行的容器云支撑系统 Kubernetes,也能够通过 influxDB 在 Grafana 上展示 Heapster 搜集到的数据。指标的事情解决了,下面自然就是日志了。

Grafana 也提供了针对 Elasticsearch 的数据源插件。下面用 Kubernetes 中正在运行的日志收集实例来展示 Grafana 对 ES 的支持。

Kubernetes 支持 OpenAPI

Open API 让 API 提供者可以定义自己的操作和模型,并让开发者可以自动化的生成喜欢语言的客户端,用以和 API 服务器通信。Kubernetes 已经支持 Swagger 1.2(OpenAPI 规范的前身)有一段时间了,但是这一标准不够完整和有效,凭借这一支持,非常难生成工具或客户端。

在 Kubernetes 1.4,我们对目前的模型和操作进行了升级,引入了 Open API 规范(在没被捐献给 Open API 之前被称作 Swagger 2.0)支持的 Alpha 版本。从 Kubernetes 1.5 开始,OpenAPI 规范的支持已经完备,能够直接从 Kubernetes 源码生成规范,对于模型和方法的任何变更,都会保障文档和规范的完全同步。

Kubernetes 的 Windows Server 支持

响应群众呼声,Kubernetes 1.5 包含了对 Windows Servern 的支持。80% 的企业应用运行于 Linux + Java 或 .Net + Windows 平台上。Kubernetes 正在 Preview 阶段的这一功能,是贴近企业需求的一次努力。

Kubernetes Windows Server 2016 以及 Windows 容器支持包含了下列功能的预览版本:

容器化的多平台应用

使用操作系统原生语言,例如 Go 和 .NET 核心开发的应用,在以前是不可能再 Linux 和 Windows 之间进行编排的。现在 Kubernetes 有了 windows Server 2016 支持,这些应用就能够同时部署在 Windows 和 Linux 之下了,开发者可以自行选择操作系统运行时。这一功能,消费者已经等了 20 年了。

StatefulSet: Kubernetes 中对有状态应用的运行和伸缩

我们认为,对于大量的有状态容器化负载,我们已经具备了一定的支持能力。我们并不是宣称这一功能已经完全完成,但是我们相信他已经处于一个可用状态,并且我们会在推动其正式发布的过程中保持其兼容性。

页面