kubernetes

在 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。

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

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

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

Kubernetes 的高级调度

Kubernetes 的调度器能够满足绝大多数要求,例如保证 Pod 只在资源足够的节点上运行,会尝试把同一个集合的 Pod 分散在不同的节点上,还会尝试平衡不同节点的资源使用率等。

不过有时候你希望控制 Pod 的调度。例如你希望确认某个 Pod 只运行在有特定硬件的节点上;或者想要让频繁互相通信的服务能就近部署;又或者你希望用独立的节点给部分用户提供服务。而且最终,用户总是比 Kubernetes 更了解自己的应用。

所以 Kubernetes 1.6 提供了四个高级调度功能:

  • 节点亲和/互斥
  • Taint(污染、变质) 和 Tolerations(容忍、耐受)
  • Pod 的亲和/互斥
  • 以及自定义调度

上述功能在 Kubernetes 1.6 中还属于 Beta 阶段。

节点亲和/互斥

节点的亲和和互斥是一种设置调度器选择节点的规则。这个规则是 nodeSelector(1.0 开始就有的功能)的衍生物。这一规则使用类似给 Node 添加自定义标签,在 Pod 中定义选择器的方式。规则在调度器中可以有必要和推荐两种级别。

Kubernetes 1.6 伸缩性升级:5000 Node 和 15 万个 Pod

上个夏天,我们分享了 Kubernetes 的伸缩性更新,经过一番努力,我们自豪的宣布 Kubernetes 1.6 能够处理 5000 个节点的集群和 15 万个 Pod 了;另外即使在这种负载规模下,端到端的 Pod 启动速度依然优于 2000 节点规模的 1.3 版本的 Kubernetes 集群,API 调用的延迟依然满足 1 秒的 SLO。

本文中我们会讨论到

  • 性能测试的指标和结果
  • 提高性能的改进
  • 未来在伸缩性方面的发展计划

XX 节点的集群意味着什么?

现在 Kubernetes 1.6 已经发布,那么当我们说到支持多少个节点的集群的时候,我们到底在说什么?前文说过,我们有两个性能相关的服务水平目标(SLO)

Kubernetes (1.6) 中的存储类及其动态供给

有状态容器的工作过程中,存储是一个关键问题,Kubernetes 对存储的管理提供了有力的支持。Kubernetes 独有的动态卷供给特性,实现了存储卷的按需创建。在这一特性面世之前,集群管理员首先要给云供应商或者存储供应商致电,来申请新的存储卷,然后创建持久卷(PersistentVolue),使其在 Kubernetes 中可见。而动态卷供给功能则实现了这两个步骤的自动化,让管理员无需再进行存储卷预分配。存储资源会依照 StorageClass 定义的方式进行供给。StorageClass 是对底层存储资源的抽象,包含了存储相关的参数,例如磁盘类型(标准类型和 SSD)。

StorageClass 的多种供给者(Previsioner),为 Kubernetes 提供了针对特定物理存储或云存储的访问能力。目前提供了多种开箱即用的存储支持,另外还有一些在 Kubernetes 孵化器中提供的其他存储支持。

在 Kubernetes 1.6 中,动态卷供给提升为稳定版(1.4 开始进入 Beta 版)。这在 Kubernetes 的存储自动化过程中是很重要的一步,让管理员能够控制资源的供给方式,让用户能够更专注于自己的应用。在上面提到的益处之外,在升级到 Kubernetes 1.6 之前,还需要了解一下这里涉及到的针对用户方面的变更。

Helm 简介

概念

  • Chart:一个 Helm 包,其中包含了运行一个应用所需要的工具、资源定义等,还可能包含 Kubernetes 集群中的服务定义,类似 Homebrew 中的 formula,APT 的 dpkg 或者 Yum 的 RPM 文件,
  • Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上,一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart,如果想在服务器上运行两个数据库,就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release,会有自己的 Release 名称。
  • Repository:用于存放和共享 Chart 的仓库。

简单说来,Helm 整个系统的主要任务就是,在仓库中查找需要的 Chart,然后把 Chart 以 Release 的形式安装到 Kubernetes 之中

简单的 Kubernetes Pod 日志查看工具 Kubetail

Tags: 

​传统来说,Kubernetes 环境下的日志都是靠 FluentD + ElasticSearch + Kibana 的组合实现的,这一组合的功能和强大,所以成为一个事实标准来使用,但是在一些比较简陋的测试集群中,或者不具备浏览器条件的自动化/控制台环境下,归并多个 Pod 的日志进行集中的查看和处理还是很有用的。

Kubetail 是一个 Bash 脚本,功能类似kubectl -f logs pod-name,但是不同的是,他同时对多个 Pod 工作,并把日志合并到一个流中。

项目网址:github

安装

只是个脚本,可以直接下载安装。

Mac 用户:

brew tap johanhaleby/kubetail && brew install kubetail

使用

kubetail [-h] [-c] [-n] [-t] [-l] [-s] pod-name-prefix

页面