Kubernetes 中的几种存储

参考:https://kubernetes.io/docs/concepts/storage/volumes/

一个运行中的容器,缺省情况下,对文件系统的写入,都是发生在其分层文件系统的可写层的,一旦容器运行结束,所有写入都会被丢弃。因此需要对持久化支持。

Kubernetes 中通过 Volume 的方式提供对存储的支持。下面对一些常见的存储概念进行一点简要的说明。

EmptyDir

顾名思义,EmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,可能读者会奇怪,那还要他做什么?EmptyDir的用处是,可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件。

缺省情况下,EmptyDir 是使用主机磁盘进行存储的,也可以设置emptyDir.medium 字段的值为Memory,来提高运行速度,但是这种设置,对该卷的占用会消耗容器的内存份额。

容器趋势:Bitami 用户调查 2017(1)

Bitnami 每年都会做一个面向其客户的调查。今年我们针对全职开发者,收集了大量关于编排、自动化、应用开发、应用环境、容器以及其他特别数据。接下来的几周,我们计划分享一些业界趋势信息的图文。

近几年来,容器是我们着重跟踪的关键技术。在本年的调查中,这一技术的关注度和生产使用度迅速攀升。关注度增长的第一证据是,对比 2016 到 2017 年的,声称正在使用容器的开发者,增速提高到了两倍多。调查中反映出的另外一大特征就是大量的生产环境应用,从 2016 年的 27% 提高到了 2017 年的 65%。有用户说他们只在开发和测试中使用容器,不准备应用到生产环境,这一报告看来,趋势并非如此。

这说明,不仅仅是 2016 年中容器的早期用户开始成熟,而且用户基数也正在增长,正在从测试开发走向生产。

图 1. 2016 年和 2017 年的应用环境对比(仅用于开发/测试 vs 生产)

containerdata1

istio 三日谈之二 路由规则

路由控制是 istio 的最常用功能了,经过前面的准备,我们已经基本可以进行这些内容的尝试了。

注意下面的路由规则都忽略了对来源的过滤,会显得比较呆板或者说没用,但是在加入过滤条件之后,就完全不可同日而语了。具体的过滤规则的写法可以参考官方文档或者 istio 中的 bookinfo 实例。

创建 frontend-v2

为了展示路由分配的能力,我们首先创建一个名为frontend-v2Deployment,这个deploy跟之前的 v1 共享同一个 PVC,也就是共享同一套页面。利用环境变量来控制输出。

istio 三日谈之一,环境准备

笔者尝试在一个准生产环境下,利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇,将一些主要的坑和环境准备工作。

内容较多,因此无法写成手把手教程,希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个:

  • istio/mixer:0.1.6
  • pilot:0.1.6
  • proxy_debug:0.1.6
  • istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题,官方在源码中提供了很方便的工具,用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件:

Istio,Kubernetes 的微服务支持

参考资料: https://developer.ibm.com/dwblog/2017/istio/ http://blog.kubernetes.io/2017/05/managing-microservices-with-istio-service-mesh.html https://istio.io/docs/

简介

Istio 是一个由 IBM、Google 以及 Lyft 联合推出的开源软件,以无痛方式为运行在 Kubernetes 上的微服务提供流量管理,访问策略管理以及监控等功能。这一软件目前仅在 Kubernetes 上运行,今后可能会扩展到其他平台。本文会结合官方例子,完成安装和基础的监控内容。

架构和组件

总体架构如图所示。

arch

Kubeadm offline installer 升级到 1.7.0 版本

仓库地址

本来做这玩意的初衷就是,Kubeadm 和 Kubernetes 是一家人,升级比较方便跟得住。未曾想第一次大版本升级,就遇到了个不大不小的坑,导致安装无法完成。这个 Issue 会在 1.7.1 修补,下面介绍一下曲线救国的安装方式。

这一问题的似乎是 kubeadm 的更新破坏了 TLS 自动授权过程造成的,具体症状是:主节点的kubeadm init完成之后,在其他节点上使用kubeadm join --token=xxxx host_ip:host_port命令加入集群时,集群会反复输出错误信息,大意是kube-public命名空间中名为cluster-info的 ConfigMap 中没有对应 token 的签署记录。

使用 kubectl 查看该 ConfigMap,和 1.6.6 的集群作对照(是的,安装的够快,想要什么版本都容易),发现 1.7.0 里面这个 ConfigMap 的元素列表确缺少这一块内容。

Kubernetes 1.7:安全加固,有状态应用更新以及扩展性

Tags: 

今天我们发布了 Kubernetes 1.7,这是一个里程碑。目前 Kubernetes 在世界范围内得以大量使用,响应企业的呼声,这一版本在存储、安全以及扩展性方面大为增强。

简单说来,新版本的安全加固措施包含对 secret 的加密、Pod 间的网络策略,用于限制 Kubelet 访问的节点鉴权以及客户端/服务器的 TLS 证书翻转。

针对在 Kubernetes 上运行数据库的用户来说,新版本的一个主要特性就是加入了对 StatefulSet 和 DaemonSet 的自动更新功能。同时还加入了对本地存储以及能够加速 StatefulSet 伸缩过程的爆发模式。

另外对于高级用户来说,这一版本的 API 聚合 (API aggregation) 功能让用户提供的 API 能够和 Kubernetes API 同时工作。还有可扩展的 admission 控制器、插件式的 cloud provider 以及 CRI(容器运行时) 的增强。

kubeadm 踩坑记

Kubeadm 是个让我爱恨交加的东西,一方面,我不认为一个生产集群应该使用这样一个第三方工具进行在线安装,尤其是在目前这种网络环境之下;而另外一方面,Kubeadm 这一工具是随 Kubernetes 同步更新的,其中包含了大量的集群配置方面的最佳实践,是追新的最佳参考,所以这个讨厌的东西的运行是必须需要得到保障的。kubeadm 的执行过程沉默到令人发指,因此下面分享几个使用过程中遇到的一些问题和解决的思路和方法,希望对同行们有所帮助。

下面的例子是基于 kubeadm 1.6.6 + Centos 7 的执行过程记录的。

实测:Kubernetes 1.6 中的混合 DNS

在之前的文章中提到过,Kubernetes 1.6 新增的混合 DNS 功能。这一功能不大,但是在企业私有云环境下有着非常重要的衔接作用,能够有效的将 Kubernetes 内的应用和集群外甚至互联网上的的 Consual 或者类似系统管理的服务连接起来,形成更好的协同效果。

上篇文章主要侧重点是概念和一些 YAML 例子,本文则会从操作出发,用一个例子从头到尾的逐步操作这一功能的具体操作。

DNS Server

我们使用一个 Ubuntu Server 运行 dnsmasq 来担任 Kubernetes 集群外的 DNS 服务器角色,只为了满足测试需要的话,就不需要太复杂的配置了。

安装

具体安装步骤如下:

页面