Istio 的频率限制

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

简介

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

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

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

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

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

建立测试环境

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

Istio 0.2 发布:增强的 Service Mesh 以及多环境支持

在 2017 年 5 月 24 日,我们启动了 Istio —— 一个为微服务提供连接、监控和安全支持的平台。互联 网对我们投入了巨大的关注,开发、运维和合作伙伴的社区日益壮大,这一切让我们诚惶诚恐。0.1 版本 展示了 Kubernetes 环境下 Istio 的所有概念。

今天我们高兴的宣布 0.2 版,这一版本在稳定和性能方面有了增强,在 Kubernetes 中提供了全集群范围内 的部署和 Sidecar 的自动注入功能,为 TCP 提供了策略和认证支持,Service Mesh 的扩展能力进一步 覆盖到了虚拟机上。另外,Istio 现在可以在 Kubernetes 之外的环境运行,例如 Consul/Nomad 或者 Eureka。除了核心功能之外,Istio 还为第三方公司和个人提供了扩展开发的能力。

0.2 版本亮点

提高可用性

  • 多命名空间支持:响应 0.1 版本的用户呼声,Istio 可以在集群范围内的多个命名空间内运行。

  • TCP 服务的策略和安全支持:除了 HTTP 服务之外,我们为 TCP 服务加入了双向 TLS 认证以及 策略支持。这使得我们所提供的观测、策略以及安全能力能够覆盖到更多 Kubernetes 应用之中。

Kubernetes 1.8:安全、负载和功能演进

Tags: 

很高兴的在此宣布今年的第三个 Release,Kubernetes 1.8 发布了。Kubernetes 1.8 展示了很多激动 人心的新特性。除了功能改进之外,社区方面也在向着更成熟的方向发展, 我们强化了项目的过程管理, 确定了架构和管理办法 这些进步将进一步保障 Kubernetes 在未来的持续发展能力和广阔前景,

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 提供配置文件:

Kubernetes 应用故障的一些定位方法

常备工作

准备一个工具镜像

其中包含 nslookup, ping, curl, 甚至是 ab、siege 等常用工具以及一个顺手的 Shell。一言不合就可以用静态 Pod 的方式将其运行到 Kubernetes 之中进行内部诊断。

sysctl -a | grep forwarding

你猜这是干啥的?

服务状态查询

各个 Kubernetes 组件的状态检查。可以使用 Ansible 之类的工具进行快速查询。

Service 不通

这里我们首先假设 Pod 工作正常

目前我们的应用均采用的是 NodePort 模式对外提供服务:

Kubernetes 的审计日志和采集

基础操作

一个正常运行的 Kubernetes 集群,除了利用访问控制对集群操作的许可进行限制之外,对于操作过程的跟踪审计也是比不可少的,围绕不同的实体,例如用户、节点以及各种工作负载进行观测是很有必要的。Kubernetes 的 API Server 提供了审计日志支持,利用审计日志的方式对系统内的操作进行记录,这里我们可以沿用推荐的 Elastic Search + Fluentd 对审计日志进行采集存储,最终使用 Kibana 或者其他支持 ES 查询的工具对关键资源或用户进行访问跟踪。

首先要启用 API Server 的审计功能。Kubernetes 提供了四个基础参数来定义审计功能:

  • audit-log-path 启用审计日志,并将日志内容写入指定文件,“-” 代表 stdout。

  • audit-log-maxage 日志文件的最大保存天数,根据文件名中的日期进行确定。

  • audit-log-maxbackup 最多保存日志文件的数量。

Kubernetes 1.7 下的 Prometheus 监控

在 Kubernetes 的标准 Heapster + InfluxDB 的监控方案之外,还有一个监控工具就是 Prometheus 了,相比 InfluxDB 来说,Prometheus 有更集中的检测能力,更多的 Exporter(数据源)支持(不过好像还是打不过 Zabbix?),以及更新潮。。

另外不少新的软件方案缺省开始支持 Prometheus 的数据抓取,所以,早上早填坑。下面是日前在一个 Kubernetes 1.7.3 集群中部署 Prometheus 监控遇到的两个坑,分享一下:

cAdvisor

官方示例解释如下:

This is required for Kubernetes 1.7.3 and later, where cAdvisor metrics (those whose names begin with 'container_') have been removed from the Kubelet metrics endpoint. This job scrapes the cAdvisor endpoint to retrieve those metrics.

Kubernetes 的证书认证

今天让我们聊聊 Kubernetes 的公私钥和证书认证。

本文内容会提及如何根据需要对 CA、公私钥进行组织并对集群进行设置。

Kubernetes 的组件中有很多不同的地方可以放置证书之类的东西。在进行集群安装的时候,我感觉有一百多亿个不同的命令参数是用来设置证书、密钥的,真不明白是怎么弄到一起工作的。

当然了,没有一百亿那么多的参数,不过的确很多的。比如 API Server 的参数吧,有大概 16 个参数是跟这些东西有关的(下面是节选):

页面