Errbot 入门(3)

Tags: 

Errbot 入门(3)

通过 Errbot 控制 Kubernetes

前面两篇分别讲了 Errbot 的简单启动和 Slack 的集成。这一篇做个结尾,用 Errbot 来查询 Kubernetes 的状态。

之前使用的 Docker 镜像中,已经集成了 Kubernetes 的 Python 客户端,所以这里只要在 Python 中引用,就可以操作了。

这里实现两个功能,第一个是列出 kubeconfig 文件中的 context,第二个是列出集群 Node 的健康状况。

准备工作

首先在 Errbot 的加载卷目录中新建目录kubeconfig,并在其中放置一个可用的 kubeconfig 文件。例如:

/usr/local/var/volumes/errbot/kubeconfig/config

Errbot 入门(2)

Tags: 

上一篇中,大致理解了一点 Errbot 的基础指令,这里尝试把 Errbot 接入到聊天室之中。

Slack 接入

  • 首先去 Slack 网站 注册一个机器人。
  • 注册完成后,会得到一个 Token。

回到 Errbot 的配置文件,下面是一个样例。这里我们设置机器人接收 "@dustise" 这一 ID 的管理,BOT_IDENTITY 写入我们刚刚创建的 Bot 账号的 Token:

核心负载 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 请求的完整报文。

Errbot 入门(1)

简介

ChatBot,也就是聊天机器人,是近期偷偷热起来的东西之一,个人觉得原因很简单——太多系统需要运维了。

使用 Grafana 可以将各种监控、日志的东西进行跟踪,在同一个 Dashboard 进行展示,但是缺点也比较明显:

  1. Dashboard 需要定制,不够灵活,难于满足突发的个性化需要。
  2. 信息是单向流动的,无法进行远程干预。
  3. 插件开发需要兼顾前后端,前端漂亮的界面对运维来说,并非必要。

聊天机器人简单说来是一个需要很多二次开发的控制台,这个控制台的不同之处在于,可以和多种聊天室之类的东西进行集成,另外部分产品提供了认证、授权等功能;另外还有不少开源插件,用来同其他系统进行集成。称为机器人,应该说是一个历史遗留,跟 AI 大概有半毛钱的关系吧。

目前最流行的同类产品大概是 Github 的 Hubot,不过个人爱好问题,还是选择了 Python 的 Errbot。官方网站 http://errbot.io/ ,大致功能:

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) 了。

页面