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 个参数是跟这些东西有关的(下面是节选):

Kubernetes 中的几种存储

参考:https://kubernetes.io/docs/concepts/storage/volumes/

一个运行中的容器,缺省情况下,对文件系统的写入,都是发生在其分层文件系统的可写层的,一旦容器运行结束,所有写入都会被丢弃。因此需要对持久化支持。

Kubernetes 中通过 Volume 的方式提供对存储的支持。下面对一些常见的存储概念进行一点简要的说明。

EmptyDir

顾名思义,EmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,可能读者会奇怪,那还要他做什么?EmptyDir的用处是,可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件。

缺省情况下,EmptyDir 是使用主机磁盘进行存储的,也可以设置emptyDir.medium 字段的值为Memory,来提高运行速度,但是这种设置,对该卷的占用会消耗容器的内存份额。

容器趋势:Bitami 用户调查 2017(1)

Bitnami 每年都会做一个面向其客户的调查。今年我们针对全职开发者,收集了大量关于编排、自动化、应用开发、应用环境、容器以及其他特别数据。接下来的几周,我们计划分享一些业界趋势信息的图文。

近几年来,容器是我们着重跟踪的关键技术。在本年的调查中,这一技术的关注度和生产使用度迅速攀升。关注度增长的第一证据是,对比 2016 到 2017 年的,声称正在使用容器的开发者,增速提高到了两倍多。调查中反映出的另外一大特征就是大量的生产环境应用,从 2016 年的 27% 提高到了 2017 年的 65%。有用户说他们只在开发和测试中使用容器,不准备应用到生产环境,这一报告看来,趋势并非如此。

这说明,不仅仅是 2016 年中容器的早期用户开始成熟,而且用户基数也正在增长,正在从测试开发走向生产。

图 1. 2016 年和 2017 年的应用环境对比(仅用于开发/测试 vs 生产)

containerdata1

istio 三日谈之二 路由规则

路由控制是 istio 的最常用功能了,经过前面的准备,我们已经基本可以进行这些内容的尝试了。

注意下面的路由规则都忽略了对来源的过滤,会显得比较呆板或者说没用,但是在加入过滤条件之后,就完全不可同日而语了。具体的过滤规则的写法可以参考官方文档或者 istio 中的 bookinfo 实例。

创建 frontend-v2

为了展示路由分配的能力,我们首先创建一个名为frontend-v2Deployment,这个deploy跟之前的 v1 共享同一个 PVC,也就是共享同一套页面。利用环境变量来控制输出。

istio 三日谈之一,环境准备

笔者尝试在一个准生产环境下,利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇,将一些主要的坑和环境准备工作。

内容较多,因此无法写成手把手教程,希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个:

  • istio/mixer:0.1.6
  • pilot:0.1.6
  • proxy_debug:0.1.6
  • istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题,官方在源码中提供了很方便的工具,用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件:

页面