Kubernetes 中的几种存储

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

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

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

EmptyDir

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

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

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 的元素列表确缺少这一块内容。

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 服务器角色,只为了满足测试需要的话,就不需要太复杂的配置了。

安装

具体安装步骤如下:

Monitor as Code 的一点尝试

Tags: 

这篇的真实名字应该是:Grafana 也是有 API 的

在项目的 CI/CD 实践过程中,XX as code 是一个很重要的方法,利用代码的方式,对软件的构建、发布、测试等环节进行表达,一方面极大的提高了自动化程度;另一方面,将这些代码纳入版本管理范围,使其同软件代码同步更新和迭代,更好的体现了系统的整体性,提高了系统的可维护性。

前面的文章中我也多次提到了监控的内容,业务和系统的运行状况可视化是系统运行的重要支撑。甚至监控本身就应该是软件的一部分。得益于各种开源软件的支持,我们可以做一番 Monitor as Code 的尝试。

监控过程本身一般由数据的产生和展示两个部分组成,对于系统数据,例如 Kubernetes 或者主机数据,我们可以使用 Zabbix、Heapster 或者 cAdvisor 以及 Prometheus 进行获取;而业务的数据则需要借助业务应用自身的代码或者数据库来转换为指标数据,注入到 InfluxDB 等时间序列数据库中。本文中暂不介绍数据生成部分的内容。

最终我们继续选择 Grafana 进行数据的展示。这是这一篇里面唯一有用的内容了。

在 kubectl 中使用 Service Account Token

在运行基于 K8S 的 CI/CD 过程中,经常有需求在容器中对 Kubernetes 的资源进行操作,其中隐藏的安全问题,目前推荐的最佳实践也就是使用 Service Account 了。而调试账号能力的最好方法,必须是 kubectl 了。下面就讲讲如何利用 kubectl 引用 Servie Account 凭据进行 K8S 操作的方法。

这里用 default Service Account 为例

假设

目前已经能对目标集群进行操作,文中需要的权限主要就是读取命名空间中的 Secret 和 Service Account。

准备配置文件

新建一个 Yaml 文件,命名请随意,例如 kubectl.yaml。内容:

页面