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。内容:

关于 Job title 中的 "DevOps" 的讨论

Tags: 

你可能看到了很多招聘 “DevOps 工程师”、“DevOps 经理” 或者 “DevOps 忍者”(胡说的)什么的,或者我最喜欢说的——“DevOps”。

另一方面,有些开发或者运维的家伙也会把 "DevOps 工程师" 这个时髦词汇加到自己的 LinkedIn 资料里面去。事实上,讨论中的很人承认干了这事(其实只要说的是你的确能做的事情就好),DevOps 之于雇主,可媲美蜂蜜之于狗熊了。

Spike Morelli 支持在 Job Title 中加入 DevOps 这个修饰,他的观点可以在博客中找到。如果对找工作有好处,何乐而不为呢?当然还是要注意这一份工作的具体需求。

Why having "DevOps in a Job Title Makes Sense

https://dzone.com/articles/why-having-devops-job-title?mz=38541-devops

而反对方,很多 DevOps 哲学的实践者会说,DevOps 是一个关于文化和自动化的词语,而非工作描述。Matthias Marschall 在他的文章中阐述了这一观点。

kubeadm 安装 Kubernetes 1.6.2

因为一些莫可名状的原因,国内网络使用 Kubeadm 颇有难度,这里大概说一下过程中的一些坑。

主体流程遵循官网指南:https://kubernetes.io/docs/getting-started-guides/kubeadm/

1/4 准备工作

这里用包管理的方式安装 kubeadm、Docker 等组件。需要注意一点点的是,如果用的非 Root 用户,要注意 sudo 的时候的环境代理设置问题。或者干脆在 apt/yum 的配置文件中写入代理服务器。

另外这里安装 Docker 之后,注意给 Docker 配置代理。或者可以直接想法子搞到下面列表中的镜像,并导入 Docker 之中:

镜像准备

下面提到的镜像基于目前的 1.6.2 版本,每次更新都会有不同。

GlusterFS + Heketi 入门(非容器)

GlusterFS 是个开源的分布式文件系统,而 Heketi 在其上提供了 REST 形式的 API,二者协同为 Kubernetes 提供了存储卷的自动供给能力。

一般对这个系统的介绍,都是基于 Docker 的容器内完成的,个人爱好原因,还不太习惯把这个事情放到集群里面,所以介绍一下用 Yum 方式的安装过程。

我们使用三台服务器作为存储集群,操作系统为 CentOS 7。另外假设每台 Gluster FS 服务器挂在有名为 /dev/sdc 的裸设备,安装过程需要有互联网连接。

  • Heketi 服务器:10.211.55.31
  • Gluster 服务器:
    • 10.211.55.31
    • 10.211.55.32
    • 10.211.55.33

Heketi 的安装和初始设置

这个很简单,CentOS 的 EPEL Repository 中就提供了他的安装包。

实用 Jenkins Docker 镜像

Jenkins 跟 GKE 的 Load Balancer 不兼容怎么办?当然是选择原谅他啊。

最近在玩 Google 的 Container Engine,发现 Jenkins 的安装过程的安全防护跟 GKE 的负载均衡器有点不和谐。要在启动初始化过程之前,完成对 CSRF 特性的调整。弄着弄着就收不住了,所以就有了对我那个 “要你命3000” Jenkins 镜像的一次大升级。

Kubernetes 中的 RBAC 支持

RBAC vs ABAC

目前 Kubernetes 中有一系列的鉴权机制。

https://kubernetes.io/docs/admin/authorization/

鉴权的作用是,决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外,还会对一些运行在集群内部并对集群进行操作的软件产生作用,例如使用了 Kubernetes 插件的 Jenkins,或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。

ABAC(Attribute Based Access Control)本来是不错的概念,但是在 Kubernetes 中的实现比较难于管理和理解(怪我咯),而且需要对 Master 所在节点的 SSH 和文件系统权限,而且要使得对授权的变更成功生效,还需要重新启动 API Server。

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

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

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

页面