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

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 对象就可以在无需附加操作的情况下,对应用进行伸缩和故障恢复了。

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

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

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

haproxy-k8s-cdn

问题

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

页面