Conduit v0.2.0 发布

Tags: 

里程碑版本,这次发布中新增了对 HTTP/1.x 和 TCP 支持,这样就可以为绝大多数运行在 Kubernetes 上的应用提供支持了。

核心负载 API 升级为 GA

Tags: 

DaemonSet、Deployment、ReplicaSet 以及 StatefulSet 升级为 GA。

很高兴核心 Workload API 在 Kubernetes 1.9 中升级为 GA。本文来自 Kenneth Owens,讲述了核心负载对象如何从诞生走入 GA,回顾 1.9 中的变化,并对未来进行展望。

起初

Pods(注 1)将容器紧密结合在一起,共享资源、网络、存储以及生命周期。Pod 很有用,但是更进一步,用户希望无缝的、可重复的以及自动的创建同一个 Pod 的多个副本,所以我们有了 ReplicationController(注 2)

可扩展 Admission 进入 Beta 阶段

Tags: 

Kubernetes API Server 中有一个功能,能让用户(对工作负载)进行决策,这一功能在 1.9 中已经走入成熟期。

Admission 是 Kubernetes 中最强大的工具之一,可以通过限制创建对象的方式来增强 Kubernetes 集群的安全性,这部分一直是编译在代码之中的。在 1.9 中,我们将 Admission 的 Webhook 升级成 Beta,让用户可以在 API Server 之外对 Admission 施加影响。

Admission 是什么?

Admission(注1),是在认证之后,资源持久化之前 的一个处理 API Server 请求的步骤。Admission 能获取到和认证过程一致的信息(用户、URL 等),以及绝大多数 API 请求的完整报文。

Kubernetes 1.9:Windows Server 容器支持进入 Beta 阶段

Tags: 

Kubernetes v1.9 已经发布,“到处可用,人人可用”的目标又前进一步。我们对 Windows 服务器的支持在 Windows 和 Kubernetes 两方面都有很大进步,现已提升到 Beta 阶段。SIG-Windows 从 2016 年 3 月开始工作,目的是为 Windows 应用和负载打开 Kubernetes 大门,这一目标极大的扩展了 Kubernetes 的应用场景,同时也降低了企业用户应用 Kubernetes 的门槛。

各种规模的企业都有大笔在 .NET 和 Windows 应用的投资。Gartner 声称(注1) 80% 的企业应用在 Windows 上运行。根据 StackOverflow 的分析,40% 的个人开发者在使用 .NET 开发(包括 .NET Core)。

Conduit AMA 活动回放

本月初我们面向 Kubernetes 发布了 Conduit —— 新一代超轻量级 Service Mesh。在享受对 Conduit 的热烈欢迎的同时,我们还在 KubeCon + CloudNativeCon 上同大家有了近距离接触。为了和未能参加奥斯汀会议的用户进行沟通,我们于 12.11 日在 Slack 上举办了一场由 Buoyant 共同创始人 William Morgan 和 Oliver Gould 主持的AMA 活动。

我们还给错过这一活动的用户准备了一份谈话记录。为了方便阅读,这里在保持内容完整性的前提下对谈话稿进行了一些编辑。

Conduit 和 Istio 有什么不同?

William:基本上说来,Conduit 和 Istio 具有相同的目标(Linkerd 也是):面向微服务应用,通过管理通讯层,为其加入超时、重试、断路器、TLS、策略等在 Linkerd 中备受欢迎的功能,提高应用的可靠性、弹性和安全性。但是其切入角度不同:Conduit 希望为这一目标提供一个尽可能小的方案。这个小字的范围,除了包含 CPU、内存、延迟影响之外,还包含了 API 和学习曲线等方面,这是很重要的区别。

Kubernetes 1.9: Apps 负载升级 GA,生态系统扩张

Tags: 

1.9 是今年第四个,也是最后一个 Kubernetes 版本。

今天的发布持续对 Kubernetes 的功能范围、健壮性进行了改进,这也和社区的大量杰出贡献分不开的。作为今年的第四个版本,我们回顾了一下今年的关键变更。值得一提的是,Apps 负载升级到了稳定版。这一举措打消了部分用户对于运行关键负载的疑虑。另外一个里程碑就是 Windows 支持进入了 Beta 阶段,让很多 Windows 专属的应用能够运行在 Kubernetes 之上,很大程度上扩展了 Kubernetes 生态系统的版图,让 Kubernetes 能够更好的服务企业用户。

负载 API 升级

激动的宣布—— apis/v1 组负载 API 进入 GA(General Availability) 阶段,缺省启用。Apps 负载 API 包含 DaemonSet、Deployment、ReplicaSet 以及 StatefulSet 包含了用于长时间运行的有状态和无状态的 Kubernetes 工作负载。注意 Batch 负载 API (Job 和 CronJob) 不在此列,他们会有独立的升级路线。

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

页面