kubernetes

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

安装

具体安装步骤如下:

在 kubectl 中使用 Service Account Token

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

这里用 default Service Account 为例

假设

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

准备配置文件

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

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 版本,每次更新都会有不同。

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。

页面