Operator:固化到软件中的运维技能

Tags: 

SRE 是用开发软件的方式来进行应用运维的人。他们是工程师、开发者,通晓如何进行软件开发,尤其是特定应用域的开发。他们做出的东西,就是包含这一应用的运维领域技能的软件。

我们的团队正在 Kubernetes 社区进行一个概念的设计和实现,这一概念就是:在 Kubernetes 基础之上,可靠的创建、配置和管理复杂应用的方法。

我们把这种软件称为 Operator。一个 Operator 指的是一个面向特定应用的控制器,这一控制器对 Kubernetes API 进行了扩展,使用 Kubernetes 用户的行为方式,创建、配置和管理复杂的有状态应用的实例。他构建在基础的 Kubernetes 资源和控制器概念的基础上,但是包含了具体应用领域的运维知识,实现了日常任务的自动化。

无状态容易,有状态难

在 Kubernetes 的支持下,管理和伸缩 Web 应用、移动应用后端以及 API 服务都变得比较简单了。其原因是这些应用一般都是无状态的,所以 Deployment 这样的基础 Kubernetes API 对象就可以在无需附加操作的情况下,对应用进行伸缩和故障恢复了。

Mixer 的 SPOF 迷思

SPOF: Single Point of Failure

Istio 的意思:

  1. Mixer 很稳定

  2. 你们说的延迟不是我说的延迟

Mixer 出现在请求路径上,很自然的会引发一个疑问:他对系统可用性和延迟会产生什么样的影响?我们经常被提问的一句话就是:“这不是一个单点失败的案例么?”

本文中我们会深入挖掘和阐述 Mixer 的设计原则,这些设计原则让 Mixer 能够提高系统可用性,并降低平均请求延时。

Istio 的 Mixer 对系统可用性和延迟有两个主要的好处:

  • 提高 SLO:Mixer 把 Proxy 和服务从基础设施后端的故障中隔离出来,提供了高级、高效的 Mesh 可用性保障。Mesh 作为一个整体来说,在同基础设施后端的交互中,有了 Mixer 的帮助,会有更低的故障率。

SoundCloud 如何使用 HAProxy 和 Kubernetes 处理用户流量

SoundCloud 如何使用 HAProxy 和 Kubernetes 处理面向用户的流量

两年前 SoundCloud 开始了将我们的自研部署平台 Bazooka 迁移到 Kubernetes 的尝试。Kubernetes 将容器化应用的部署、伸缩和管理都进行了自动化。

haproxy-k8s-cdn

问题

用户流量的路由,是这类动态平台需要面对的一个重大挑战:把来自用户的 API 和网站访问路由到运行在 Kubernetes 的 Pod 上。

Conduit 登场

今天我们要介绍 Conduit,面向 Kubernetes 的新的开源 Service Mesh。

Conduit 是从头开始的,目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面,用 Go 开发了简单强大的控制平面,总体设计围绕着性能、安全性和可用性进行。更重要的是,Conduit 将会完全吸收过去 18 个月中,我们在 Linkerd 的生产级 Service Mesh 中积累沉淀的真实经验。

Kube-Node:让 Kubernetes 自行管理节点

本文是一个系列中的一篇,来自于 CNCF 成员,为奥斯汀 12.6-12.8 的 KubeCon/CloudNativeCon 而做。

Michelle Noorali 在今年三月份的欧洲 KubeCon 上的 KeyNote中说到:Kubernetes 对开发人员来说还是太难了。原则上来说,开发人员对 Kubernetes 和容器技术是非常热爱的,这一系列的技术让开发人员编写的应用能够到处运行,却无需担心基础设施的差异。但事实上,这一技术体系还是有很多依赖的,这些依赖很大程度上磨灭了用户的热情。

试译:Mixer 的适配器模型

Istio 0.2 引入了新的 Mixer 适配器模型,从而具有了更大的灵活性去接入各种基础设施后端。本文尝试讲述这一模型及其工作机制。

为什么是适配器模型?

各种基础设施都提供了用于支持服务构建的功能,例如访问控制、遥测、配额、计费等等。传统服务会直接和这些后端系统打交道,和后端紧密耦合,并集成其中的个性化语义以及用法。

Mixer 服务构成了基础设施和 Istio 之间的抽象层。Istio 组件和运行于 Service Mesh 中的服务,借助 Mixer 的能力就能在不直接访问后端接口的情况下和这些后端进行交互。

Mixer 除了作为应用和基础设施之间的隔离层之外,操作者还可以借助 Mixer 的中介模型,注入或者操作应用和后端之间的策略,例如哪些数据需要报告给哪些后端、哪些后端提供认证等。

每种后端都有各自不同的接口和操作方式,因此 Mixer 需要有代码来支持这种差异,我们称这些内容为适配器

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

页面