环境搭建

多节点搭建步骤：

https://docs.openstack.org/devstack/rocky/guides/multinode-lab.html

要配置 kvm，否则使用默认的 qemu 跑 vm 性能会很差：

https://docs.openstack.org/devstack/rocky/guides/devstack-with-nested-kvm.html

步骤

1. drain 掉节点上所有的 pod

1

kubectl drain <node-name> --ignore-daemonsets --delete-local-data --force

2. 停止 kubelet

1

systemctl stop kubelet

3. 停止所有容器

1
2

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

4. 停止 docker daemon

1

systemctl stop docker

背景

当前测试环境 K8s 集群 3 台 master 机器配置相对较高，之前为了充分利用资源将 workload 与 control plane + etcd 混部，这样大大降低了集群的稳定性，而 IaaS 层没有用虚拟化技术，不支持原地升级规格，因此我们决定通过迁移的方式来实现：

1. 让 K8s master 组件独享 3 台机器，与 workload 分开部署
2. 用 3 台性能较差的机器代替，避免资源浪费

旧的 master 节点为：oldmaster-1 oldmaster-2 oldmaster-3
新的 master 节点为：master-1 master-2 master-3

前置条件

检查客户端配置

1. 检查所有 kubelet server 配置为 LB 地址

如果不是则改为 LB 地址

1

ansible all -m shell -a 'sed -i "s#server: https://.*#server: https://10.200.20.241:443#" /etc/kubernetes/kubelet.conf'

2. 检查 kube-proxy server 配置为 LB 地址

1

kubectl -n kube-system get configmap kube-proxy -o yaml | sed 's#server: https://.*#server: https://10.200.20.241:443#' | kubectl apply -f -

3. 检查所有 controller-manager 和 scheduler server 配置为本机 apiserver 6443 地址

4. 确保所有业务方 kubeconfig 都使用 LB 地址

现象

1. 收到告警提示 PLEG 延时升高（240s）

笔者对 HTC 手机有着深厚的感情，从 HTC G2 到 HTC M8，经历了 HTC 的鼎盛和衰落。本文记录了一些常用的刷机方法和 hack 命令，以作备忘。

官方 Unlock/ReLock 方法

Unlock

获取解锁 token

1

fastboot oem get_identifier_token

准备工作

安装 etcdctl

方法1

1

apt install etcd-client=3.2.17+dfsg-1

健康检查和就绪检查

健康检查（Liveness Probe）

如果设置了 livenessProbe，k8s (kubelet) 会每隔 n 秒执行预先配置的行为来检查容器是否健康

当健康检查失败时，k8s 会认为容器已经挂掉，会根据 restartPolicy 来对容器进行重启或其他操作。

每次检查有 3 种结果，Success、Failure、Unknown

如果不配置，默认的检查状态为 Success

本文主要介绍了 Deployment 和 StatefulSet 的升级机制和扩缩容机制，以及一些常用的配置项。并分别介绍了以这两种方式部署 Pod 时的对服务进行升级（包括滚动发布、蓝绿发布、灰度／金丝雀发布）的最佳实践。

Deployment

升级机制

Rollout

Deployment 的 rollout 在 .spec.template 被修改时触发（比如镜像地址更新、Pod label 更新等等），其他修改（.spec.replicas 更新）不会触发。

更新时，k8s 通过计算 pod-template-hash，创建新的 ReplicaSet，由新的 rs 启动新的 Pod，不断替换旧 rs 的 Pod。

本文转自 从头编写一款时间序列数据库 （翻译：Colstuwjx），请支持原作者。

我从事监控方面的工作。尤其是专注在 Prometheus，一款内置了自己定制的时间序列数据库的监控系统，以及它和 Kubernetes 的集成工作。

从很多方面来说，Kubernetes 表现出了一切 Prometheus 专门设计的东西。它使得持续部署，自动扩缩，以及高度动态环境的其他功能更易于实现。它的查询语言和操作模型，还有许多其他概念方面的决策使得 Prometheus 尤其适合这样的环境。然而，如果被监控的工作负载变得更加显著动态的话，这也会给监控系统本身带来新的压力。基于这一点的考虑，与其再次回顾 Prometheus 已经很好解决的问题，还不如专注于在这样一个高度动态或短生命周期服务的环境里提高它的性能。

Prometheus 的存储层在历史上有着惊人的性能表现，一个单台服务器每秒可以摄取多达 100 万个采样，数百万个时间序列，同时仅占用令人惊叹的少量磁盘空间。尽管当前的存储已经给我们提供了不错的服务，笔者构思了一个新设计的存储子系统用来纠正现有解决方案的一些短板，并且可以用来配备支撑下一代的集群规模。

背景

有时我们需要将自定义的域名或 IP 加入到 apiserver 的证书中，以通过 kubectl 或 kubelet 等客户端的验证，这个时候就需要对 apiserver 证书中包含的 IP 和 DNS 信息做些修改。

概念

首先介绍几个概念：

• KEY: 私钥
• CSR: Certificate Signing Request 证书签名请求（公钥）
• CRT: Certificate 证书
• x.509: 一种证书格式
• PEM: X.509 证书文件具体的存储格式（有时候用 pem 代替 crt 后缀）