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

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 和容器技术是非常热爱的,这一系列的技术让开发人员编写的应用能够到处运行,却无需担心基础设施的差异。但事实上,这一技术体系还是有很多依赖的,这些依赖很大程度上磨灭了用户的热情。

搭建高可用 Kubernetes 集群

领导说,只要机器够多,故障是个很平常的事情。

Kubernetes 能很好的管理容器和节点,所以正常的节点故障或者个别应用的故障是不会影响集群运作的。一旦 apiserver 或者所依赖的 etcd 出现问题,情况就不再乐观了。幸好这两个核心服务都提供了高可用相关能力。同时 controller-manager 以及 scheduler 也都具备通过选举产生 leadership 的机制,这就提供了高可用的基础。下面讲讲 Master 组件的高可用部署方式。

部署目标

  • 每个 apiserver 都使用不同的负载均衡端点访问整个 etcd 集群。

  • 每个 controller-manager 和 scheduler 使用各自的 apiserver 进行工作。

  • 客户端通过负载均衡机访问 apiserver。

ha-kubernetes

在 Kubernetes 上使用 Jmeter 运行压力测试

Kubernetes 的资源和任务调度能力,能给自动化测试提供相当大力的支持,这里以 Jmeter 为例,讲讲如何在 Kubernetes 中使用 Jmeter 进行简单的性能测试。

开始之前

  • 录制任务:本文所用镜像为 Jmeter 3.x 版本,建议提前录制一个简单的测试任务进行下面的操作。

  • 支持 Jobs 的 Kubernetes 集群,以及缺省的 StorageClass 支持,能够实现 PVC 的动态供应。

  • 互联网连接。

试验内容

  1. 搭建一个 Web DAV 服务,用于提供给 Jmeter 输入输出场所,也便于日后 CI/CD 工具的案例输入或结果输出。
  2. 运行单实例的 Jmeter 测试任务。
  3. 运行集群形式的 Jmeter 测试任务。

预备存储

这一步骤并非强制,完全可以通过 scp 或者 mount 等其他方式来实现

试译:Mixer 的适配器模型

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

为什么是适配器模型?

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

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

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

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

使用 Let's Encrypt 轻松加固 Traefik Ingress Controller

Traefik 是一个现代 HTTP 反向代理和负载均衡服务器,支持众多后端(Docker、Swarm、Kubernetes、Marathon 等等)下的动态配置。

Ingress 是 Kubernetes 对外暴露服务的一种方式,可以通过域名、路径等方式,将外部请求转发给集群的内部服务。

Let's Encrypt 是一个于数字证书认证机构,通过自动化方式免费提供 SSL/TLS 证书。

好了凑够一百字了应该,现在开始说正经事。

上面三个东西合起来的话,这篇文章的目的就很清楚了,找个免费的法子把 Kubernetes 的服务升级成高大上的 https。

准备工作

  • Ingress 首先需要一个域名来工作。

  • 使用htdigest -c user.dat traefik guest命令,创建一个名为 guest 的用户,并存储在 user.dat 中,用于后面的密码验证。

  • 为 Traefik 准备一个 PVC,用于存储 ACME 生成的认证文件,这里我们命名为 traefik。

页面