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 和学习曲线等方面,这是很重要的区别。

Istio 尾行记

Istio 一直没有什么像样的更新,Conduit 也迟迟不出来怼,眼看 2017 就要过去,安装试用也不新鲜了,补一篇 Istio 的笔记,算做个收尾了。

Istio 最大的亮点之一,就是使用 Pilot 将集群控制语言翻译成为 Envoy 配置,利用 Sidecar 的方式对服务通信进行控制,下面就是对这一过程的跟踪尝试。

kubectl apply -f install/kubernetes/istio.yaml

cat istio.yaml| grep ^kind

会看到,这里生成了相当多的内容,除去 Deployment、Service 和 ConfigMap 老几样之外,还有当前集群必须的 RBAC 几要素:Service Account、ClusterRole 以及 ClusterRoleBinding。然后就是 Kubernetes 世界里强力扩展的标志:各种 CRD(CustomResourceDefinition) 了。

Istio 尾行记

Istio 一直没有什么像样的更新,Conduit 也迟迟不出来怼,眼看 2017 就要过去,安装试用也不新鲜了,补一篇 Istio 的笔记,算做个收尾了。

Istio 最大的亮点之一,就是使用 Pilot 将集群控制语言翻译成为 Envoy 配置,利用 Sidecar 的方式对服务通信进行控制,下面就是对这一过程的跟踪尝试。

kubectl apply -f install/kubernetes/istio.yaml

cat istio.yaml| grep ^kind

会看到,这里生成了相当多的内容,除去 Deployment、Service 和 ConfigMap 老几样之外,还有当前集群必须的 RBAC 几要素:Service Account、ClusterRole 以及 ClusterRoleBinding。然后就是 Kubernetes 世界里强力扩展的标志:各种 CRD(CustomResourceDefinition) 了。

Node 重伤之后

Tags: 

很多人都知道 Kubernetes 能自动维护失效 Pod、防止服务中断、剔除故障节点 BLABLA 的一堆高大上功能。但节点故障之后,会对运行在故障节点上的容器、以及依赖容器的服务造成什么影响,是应该了解的,这样才能有针对性的进行监控设置、部署安排、故障处理等工作。

水平有限,这里不谈原理,只说说症状和一些相关的调整。

测试环境

  • Kubernetes 1.7.10,三节点,其中 Master 节点被 Taint.
    • 10.211.55.11(Master)
    • 10.211.55.12
    • 10.211.55.13
  • CentOS 7
  • Docker 1.12.3

实验设计

Docker、Kubelet 以及 Kube-Proxy 是 Node 的标准组件,我们准备一个 2 Replicas 的 Deployment 作为测试目标,使用 NodePort 方式暴露 HTTP 端口。具体代码见附录。

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 中积累沉淀的真实经验。

页面