kubernetes

在 Kubernetes(1.6)中配置私有 DNS 区域以及上级域名服务

很多用户都有自己的域名区域,并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes管理的服务发现系统(例如 Consul)。我们在 Kubernetes 1.6 中推出了新功能,kube-dns 添加了可配置的私有 DNS 区域(通常称为存根域)以及外部的上级域名服务,本文将会讲解如何使用这一功能。

Kubernetes 目前在 Pod 定义中支持两个 DNS 策略:DefaultClusterFirstdnsPolicy缺省为ClusterFirst

Kubernetes 的高级调度

Kubernetes 的调度器能够满足绝大多数要求,例如保证 Pod 只在资源足够的节点上运行,会尝试把同一个集合的 Pod 分散在不同的节点上,还会尝试平衡不同节点的资源使用率等。

不过有时候你希望控制 Pod 的调度。例如你希望确认某个 Pod 只运行在有特定硬件的节点上;或者想要让频繁互相通信的服务能就近部署;又或者你希望用独立的节点给部分用户提供服务。而且最终,用户总是比 Kubernetes 更了解自己的应用。

所以 Kubernetes 1.6 提供了四个高级调度功能:

  • 节点亲和/互斥
  • Taint(污染、变质) 和 Tolerations(容忍、耐受)
  • Pod 的亲和/互斥
  • 以及自定义调度

上述功能在 Kubernetes 1.6 中还属于 Beta 阶段。

节点亲和/互斥

节点的亲和和互斥是一种设置调度器选择节点的规则。这个规则是 nodeSelector(1.0 开始就有的功能)的衍生物。这一规则使用类似给 Node 添加自定义标签,在 Pod 中定义选择器的方式。规则在调度器中可以有必要和推荐两种级别。

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)

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 之中

简单的 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

Kubernetes 集群资源的那些事

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

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

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

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

磁盘

Volume

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

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

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可以找到离线版本的二进制文件包。

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。

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

页面