搭建高可用 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 等其他方式来实现

使用 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。

K8S 上 Elastic Search 集群的通信加密、认证和清理

Kubernetes 的 Release 文件包中,一直包含了使用 Elastic Search 方案进行日志处理的简单例子, 这个例子非常简陋外加版本较旧,处于“能用”的状态而已。

而近期的版本中这一情况发生了变化,原来的elasticsearch中新增了一个子目录: production_clusterREADME.md中的介绍是:

A more robust example that follows Elasticsearch best-practices of separating nodes concern is also available.

这个听起来就厉害了,关键字:robuts,best-practice。

顺藤摸瓜找到了作者的 github 地址:https://github.com/pires/

这一集群的特点是:

CI/CD 工具链的分分合合

作案动机

一种对 ci/cd 工具的轻量化和解耦的尝试?

Jenkins 的传统集群方式,是使用不同环境的服务器构成不同能力的 Jenkins 节点,由主节点根据任务 环节的需要,调度不同能力的子节点来完成构建或部署任务。

进入容器云时代,情况发生了变化,我们可以使用不同能力的 Jenkins 镜像,使用 Kubernetes 插件来 完成这种任务的拆分和调度,为此,我构建了一个包含所有我们平时用到的工具的 Jenkins 镜像,简化了 节点的扩展和选择过程。

然而随着学习和应用的深入,我意识到这种做法有几个问题:

  • DevOps 中隐含着发挥个人能力的愿景,工具链的所谓大而全,只不过是在画一个比较大的圈,使用这样的 一套 Jenkins,还是要被其中所包含的仅有的工具中进行选择,对身陷其中的技术人员绝不能说是友好,也 绝不是鼓励各展所长的态度。

  • 现有的功能测试、接口测试、压力测试等工具,越来越专业化,往往会有各自的工作集群调度甚至是托管方案, 例如 selenium grid、JMeter 集群等。

非缺省域名下 Istio 的使用

Kubernetes 缺省的域名为 cluster.local,好死不死的,istio 的缺省安装也沿用了这一设定, 并且文档中并没有明确指出这一假设。Istio 中使用了大量的 FQDN 进行服务的甄别,域名不一致这样 的问题可以说是后患无穷。经过 101 号 issue 的讨论,得知 proxy 和 pilot 组件提供了域名的设置功能, 大致用法如下:

Pilot

kubectl edit deploy istio-pilot -n istio-system 或者编辑官方的 istio.yaml,查找 docker.io/istio/pilot:0.2.9 的容器,并在 args 一节中加入如下的两行:

Istio 的频率限制

本来这个应该是作为第三天“零散功能点”介绍的,结果目标规则部分遇到一个 bug 一直没得到修正,就拖 着了——然后后来发现自己这个想法挺无知的——零散的功能点非常多,非常大,而且文档非常弱,很难搞,只好 逐个介绍了。

简介

调用频率限制这个功能其实也是比较常见的东西了。这里就不多做介绍了。下面简单粗暴的介绍一下测试要完 成的目标。

测试中我们将使用两个服务,服务叫 workload,客户端叫 sleep,workload 服务正常返回群众喜闻乐见 的 “Hello World”,而 sleep 仅用来做 Shell 方便测试。

测试过程将为 workload 建立规则:

  • 对于任意访问,十秒钟之内仅能访问两次;
  • 对于来自 sleep 的访问,十秒钟之内仅能访问一次

下面所有内容都在 default 命名空间进行

建立测试环境

编辑 workload.yaml 以及 sleep.yaml 之后, 我们使用如下命令运行(这两部分源码,只有些乌七八糟的标签和命名有点问题,其他很普通。 见最后页)

istio 的自动注入

Tags: 

istio 的自动注入

从小白角度上来讲,istio 的吸引力不在于那些花里胡哨或者说精彩纷呈的功能,而是

  • 第一:背景深厚
  • 第二:可以流水线操作的一键注入功能

而目前的 0.2 预发布版又提供了自动注入功能,进一步提高了易用性。

开始之前

istio 的 0.2.4 版本。

根据官方文档,自动注入功能需要 Kubernetes 1.7.4 以上,并且需要启用两个 Alpha 功能,可以把 如下参数加入 kube-apiserver 的启动文件之中:

--runtime-config=admissionregistration.k8s.io/v1alpha1=true
--runtime-config=batch/v2alpha1=true

开启自动注入功能

kubectl apply -f install/kubernetes/istio-initializer.yaml

等待运行结果。注意其中的镜像地址可以按需求进行编辑。

iTerm2 缺省配置可能泄漏隐私

Tags: 

原文地址 https://gitlab.com/gnachman/iterm2/issues/6050

缩水版

iTerm 的Perform DNS lookups to check if URLs are valid选项,让 iTerm 用户在选择文字时会把选择内容 明文 发送给 DNS 服务器进行查询,iTerm 设置中,可以在 advanced页中进行查找和关闭。

Kubernetes + Blackbox 实现对 Web 和 DNS 的简单监控

其实都在这里了: https://github.com/prometheus/blackbox_exporter/blob/master/CONFIGURATION.md

Prometheus 带有很多有针对性的 Exporter,能够对 MySQL、Apache 或者 ElasticSearch 等服务 器进行监控,另外还有 Blackbox Exporter 用于对 http dns tcp 等零散目标进行简单监控。

DNS 的监控

首先需要运行一个 Blackbox 的 Deployment,并利用 Configmap 来为 Blackbox 提供配置文件:

页面