kubernetes

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。

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

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 源码生成规范,对于模型和方法的任何变更,都会保障文档和规范的完全同步。

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

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

Kubernetes 中的容器运行时接口

文中多次出现了个单词 shim,胡翻成代理了,虽然垫片还是比鲁棒啥的好听。。

归根结底,Kubernetes Node 的最底层就是启动和停止容器的组件了,这一部分我们称之为容器运行时( Container Runtim ),这其中最知名的也就是 Docker 了,这一领域正在快速成长,他并不孤独。为了让 Kubernetes 更具扩展性,我们投入了不少精力,在 Kubernetes 中加入了容器运行时插件 API,我们称之为 “CRI”。

Kompose: Docker-compose 到 Kubernetes 的迁移工具

Docker 给了开发者以巨大的帮助。让每个人都能够从 Docker Registry 启动一个打包好的 Docker 应用。为了对付多容器应用, Docker 开发了 Docker-compose (也就是 Compose)。Compose 借助 yaml 格式的描述文件来定义一个多容器应用,然后就可以用一个简单的 docker-compose up 来启动这一应用中的多个容器。然而,Compose 只能够在本地或者 Docker Swarm 集群中运行。 那如果我们需要在 Swarm 之外运行怎么办?比如 Kubernetes?

Kubernetes 中的 StorageClass 和动态卷供给

存储是容器运行环境的重要一环,Kubernetes 提供了一些用于存储管理的基础能力。动态卷供给是一个 Kubernetes 独有的功能,这一功能允许按需创建存储卷。在没有这种能力之前,集群管理员需要打电话给他们的云或者存储提供者来创建新的存储卷,成功以后再创建 PersistentVolume 对象,才能够在 Kubernetes 中使用。动态卷供给能力让管理员不必进行预先创建存储卷,而是随用户需求进行创建。这一特性在 1.2 版本中处于 α 阶段,在 版本 1.4 中提升为 β。这一版本提高了动态卷的弹性和可用性。

页面