Kubernetes 的证书认证

今天让我们聊聊 Kubernetes 的公私钥和证书认证。

本文内容会提及如何根据需要对 CA、公私钥进行组织并对集群进行设置。

Kubernetes 的组件中有很多不同的地方可以放置证书之类的东西。在进行集群安装的时候,我感觉有一百多亿个不同的命令参数是用来设置证书、密钥的,真不明白是怎么弄到一起工作的。

当然了,没有一百亿那么多的参数,不过的确很多的。比如 API Server 的参数吧,有大概 16 个参数是跟这些东西有关的(下面是节选):

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

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

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

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

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

containerdata1

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(容器运行时) 的增强。

关于 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 在他的文章中阐述了这一观点。

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)

编写易移植的 PVC

如果你在编写配置模板或者是一个可能在很多不同集群下运行的配置,要在其中包含持久存储,我们提供一些建议:

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

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

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

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

页面