Istio 0.2 发布:增强的 Service Mesh 以及多环境支持

在 2017 年 5 月 24 日,我们启动了 Istio —— 一个为微服务提供连接、监控和安全支持的平台。互联 网对我们投入了巨大的关注,开发、运维和合作伙伴的社区日益壮大,这一切让我们诚惶诚恐。0.1 版本 展示了 Kubernetes 环境下 Istio 的所有概念。

今天我们高兴的宣布 0.2 版,这一版本在稳定和性能方面有了增强,在 Kubernetes 中提供了全集群范围内 的部署和 Sidecar 的自动注入功能,为 TCP 提供了策略和认证支持,Service Mesh 的扩展能力进一步 覆盖到了虚拟机上。另外,Istio 现在可以在 Kubernetes 之外的环境运行,例如 Consul/Nomad 或者 Eureka。除了核心功能之外,Istio 还为第三方公司和个人提供了扩展开发的能力。

0.2 版本亮点

提高可用性

  • 多命名空间支持:响应 0.1 版本的用户呼声,Istio 可以在集群范围内的多个命名空间内运行。

  • TCP 服务的策略和安全支持:除了 HTTP 服务之外,我们为 TCP 服务加入了双向 TLS 认证以及 策略支持。这使得我们所提供的观测、策略以及安全能力能够覆盖到更多 Kubernetes 应用之中。

Kubernetes 1.8:安全、负载和功能演进

Tags: 

很高兴的在此宣布今年的第三个 Release,Kubernetes 1.8 发布了。Kubernetes 1.8 展示了很多激动 人心的新特性。除了功能改进之外,社区方面也在向着更成熟的方向发展, 我们强化了项目的过程管理, 确定了架构和管理办法 这些进步将进一步保障 Kubernetes 在未来的持续发展能力和广阔前景,

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)

页面