Etcd 维护

Etcd 集群少不了日常维护来保持其可用性。这些运维操作一般都是自动化且期间 Etcd 不会停止对外服务，或者严重影响 Etcd 集群的性能。

所有的运维管理都在操作 Etcd 的存储空间。存储空间的配额用于控制 Etcd 数据空间的大小，如果 Etcd 节点磁盘空间不足了，配额会触发告警，然后 Etcd 系统将进入操作受限的维护模式。为了避免存储空间消耗完导致写不进去，应该定期清理 key 的历史版本。在清理 Etcd 节点存储碎片之后，存储空间会重新进行调整。最后，定期对 Etcd 节点状态做快照备份，以便在错误的运维操作引起数据丢失或数据不一致时进行数据恢复。

nginx 日志打印响应时间 request_time 和 upstream_response_time

设置log_format，添加request_time，$upstream_response_time，位置随意

1
2
3
4
5

log_format  main  '"$request_time" "$upstream_response_time" $remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

下线一般有两种情况,一般是故障或者是迁移。故障节点下线只需要直接摘除下来就可以，因为会从新调度到新的节点。而正常节点迁移则需要先排干节点，即将所有pod在此节点上迁移出去其他节点。

介绍

golang 中的 sync 包实现了两种锁：

1. Mutex：互斥锁
2. RWMutex：读写锁，RWMutex 基于 Mutex 实现

Install Linux Kernel 4.4.5 LTS in CentOS 7

I tested this tutorial on CentOS 7 64 bit edition. Although, these steps should work on RHEL 7.

Note: Since this kernel is just released, the latest kernel haven’t pushed into the ELRepo yet. It stills shows the 4.4.4 version. I think the latest kernel will be pushed to the repository in few hours.

To install the latest kernel, add ELRepo repository.

Add ELRepo GPG key:

1 什么是Context

最近在公司分析gRPC源码，proto文件生成的代码，接口函数第一个参数统一是ctx context.Context接口，公司不少同事都不了解这样设计的出发点是什么，其实我也不了解其背后的原理。今天趁着妮妲台风妹子正面登陆深圳，全市停工、停课、停业，在家休息找了一些资料研究把玩一把。

找到网卡对应的方式，在主机上执行如下命令

1
2
3
4
5
6
7

docker exec -it <container-name> bash -c 'cat /sys/class/net/eth0/iflink'
# 假设返回 12
grep -l 12 /sys/class/net/veth*/ifindex
# 此时会有如下类似返回
/sys/class/net/veth11d4238/ifindex
# veth11d4238 即主机上的另一半

文字识别

python的pytesseract为文字识别提供了很好的支持。整个实现只需要一行关键代码即可。

前提安装

1
2

yum install -y tesseract-langpack-chi_sim tesseract-langpack-chi_tra tesseract
pip install pytesseract

代码示例

1
2
3
4

from PIL import Imageimport
import pytesseract
text=pytesseract.image_to_string(Image.open(file_path), lang='chi_sim')
print(text)

识别语言： 中文简体(chi_sim), 繁体(chi_tra)

集群做了什么？产生了什么影响？在容器引擎的日常运维中，经常遇到客户反馈线上问题，例如: cloud-controller-manager 服务无法启动，集群初始化卡状态，kubectl top no 命令返回错误，master节点某些pod被kill掉等；值班同学遇到这些问题时，通常会进入集群各个 ...

介绍

Kubernetes Cluster Federation 又名 KubeFed 或 Federtation v2，是 Kubernetes SIG Multi-Cluster 团队新提出的集群联邦架构。新架构在 Federation v1 基础之上，简化扩展 Federated API过程，并加强跨集群服务发现与编排的功能。

KubeFed 是Kubernetes官方多集群联邦解决方案。它允许用户使用在“Host cluster”中定义的一组简单的APIs，在多个Kubernetes集群中联合统一调度工作负载。

KubeFed 与v1版本使用一套独立的Federation APIs不同，它创建和扩展了一套自定义资源。

在 KubeFed 设计之初，有两个最重要的核心理念是其希望实现的，分别为 Modularization（模块化）和 Customizable（定制化）。这两个理念是希望 KubeFed 能够跟随着 Kubernetes 生态发展，并与之保持相容性和扩展性。

与 v1 版本相比，KubeFed 最大的改变是将 API Server 移除，并通过 CRD 机制来完成 Federated Resources 的扩充，KubeFed Controller 负责管理这些 CRD，并实现同步 Resources 、跨集群编排等功能。