istio 0.5.0 新特性:流量镜像

在类似 Dark launch 的测试、发布过程中,流量复制是个非常有用的功能,istio 0.5.0 的更新,带来了一个新的路由相关特性:流量镜像。

这一场景中,我们会将正常的流量进行复制,将复制出来的流量分发给待上线的应用(V2),使用实际流量对新版本应用进行测试;而现有客户端则仅会感知到单一版本(V1)的存在。

下面做个小实验来进行验证。

条件

基于 Kubernetes 运行的 Istio 0.5.0 版本部署。

部署

源码见后。

nginx:stabel-alpine镜像,生成v1v2两个版本的 Deployment,以及一个target服务:

ChatBot:在 Slack 中使用监控和告警

前面文章中我们使用 Errbot 通过 Kubernetes API 在 Slack 中进行 Kubernetes 查询。这种方式很局限。毕竟拉更多组件下水,写更多代码才是大势所趋LOL。本文以 Istio 中的响应时间监控为例,看看 Errbot 和 Prometheus 的互动。

前提

  • Istio
  • Prometheus
  • 公网部署
  • 接入 Slack 的 Errbot
  • Errbot 开放 3141 端口,能够被 Alertmanager 使用。

注意:

在 Azure 上运行 Istio 的注意事项

Tags: 
  • ACS Engine: v0.12.4
  • Istio: v0.5.0
  • Kubernetes: v1.8.7

在 Istio 注入之后,生成的 Init 容器中会有 RunAs 的 SecurityContext,而 ACS Engine 的缺省 admission 包含了SecurityContextDeny,会拒绝这一选项,造成 Istio Workload 无法运行,

解决方法很简单,只要在定义文件中修改 api server 配置:

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:

Errbot 入门(1)

简介

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

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

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

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

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

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 集群

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

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

部署目标

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

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

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

ha-kubernetes

页面