Tabsp's Blog

仅使用 443 端口完美配置 Nginx SNI 分流 REALITY&XHTTP、Hysteria 2 及 WEB 网站

Tue, 17 Dec 2024 00:00:00 +0000

背景

上一篇文章介绍了手动安装并配置 Xray 的 REALITY 协议，但是支持 REALITY 协议的 iOS 的客户端太少，所以打算同时安装一个 Hysteria 2 作为补充。目前来看 Xray core 短期内不会支持 Hysteria 2，故考虑使用 nginx 同时反代 Xray 和 Hysteria 2。

正如标题所言，这次我们上点强度，为了达到完美的效果，我们只使用一个 443 端口，实现 nginx 反代 Xray（支持 REALITY&XHTTP）和 Hysteria 2，同时再反代一个 WEB 网站，网站支持 HTTP/2 和 HTTP/3。

流程如下：

┌─────────────┐ ┌────────────────┐ ┌───────────────────┐
│ WEB browser │ │ REALITY client │ │ Hysteria 2 client │
└──────┬──────┘ └───────┬────────┘ └─────────┬─────────┘
 │ │ │
 │ │ │
 │ │ │
 │ │ │
 │ ┌────────▼────────┐ │
 └──────────► example.com:443 ◄───────────────┘
 └────────┬────────┘
 │
 │
 ┌───▼───┐
 │ Nginx │
 └───┬───┘
 │
 ┌──────────────────┼────────────────────────┐
 │ │ │
 ┌─────▼──────┐ ┌──────▼───────┐ ┌──────────▼────────┐
 │ WEB server │ │ Xray server │ │ Hysteria 2 server │
 └────────────┘ └──────────────┘ └───────────────────┘

准备工作

一个域名，本文以 example.com 为例，注意自行替换下文所有配置文件中的域名为自己的域名
将 example.com 解析到自己主机，不要开启 CDN
和上一篇文章一样，本文所有操作均基于 root 用户
一些耐心

安装

安装 Nginx

编译安装最新版本 Nginx

手动配置 Xray（vless+reality+vision）代理服务器

Sat, 14 Dec 2024 00:00:00 +0000

依赖

curl
vim

本文所有操作均基于 root 用户。

安装

安装 Xray

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

配置

Xray 配置

使用 vim 修改 Xray 默认配置文件，默认路径在 /usr/local/etc/xray/config.json，默认内容为 {}。

vim /usr/local/etc/xray/config.json

参考配置：

{
 "log": {
 "loglevel": "warning"
 },
 "routing": {
 "domainStrategy": "IPIfNonMatch",
 "rules": [
 {
 "type": "field",
 "protocol": ["bittorrent"],
 "outboundTag": "block"
 },
 {
 "type": "field",
 "ip": ["geoip:private"],
 "outboundTag": "block"
 },
 {
 "type": "field",
 "ip": ["geoip:cn"],
 "outboundTag": "block"
 },
 {
 "type": "field",
 "domain": ["geosite:category-ads-all"],
 "outboundTag": "block"
 }
 ]
 },
 "inbounds": [
 {
 "tag": "xray-xtls-reality",
 "listen": "0.0.0.0",
 "port": 443,
 "protocol": "vless",
 "settings": {
 "clients": [
 {
 "id": "<replace-this>", // 可以使用 xray uuid 生成，注意保存
 "flow": "xtls-rprx-vision"
 }
 ],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "dest": "<replace-this>", // 自行设置合适的回落域名，必须带端口，比如：www.example.com:443
 "serverNames": [
 "<replace-this>" // 自行设置客户端可用的 server name 列表，例如：www.example.com
 ],
 "privateKey": "<replace-this>", // 可以使用 xray x25519 生成
 "shortIds": [""]
 }
 },
 "sniffing": {
 "enabled": true,
 "destOverride": ["http", "tls", "quic"]
 }
 }
 ],
 "outbounds": [
 {
 "protocol": "freedom",
 "tag": "direct"
 },
 {
 "protocol": "blackhole",
 "tag": "block"
 }
 ]
}

参考配置中的 <replace-this> 必须替换并修改为自己的配置，替换方法参考注释，其他例如 shortIds、流量过滤等可以自行决定是否配置。

Arch Linux 安装

Sat, 13 Mar 2021 00:00:00 +0000

下载镜像

在 Arch Linux - Downloads 页面任意找一个镜像站下载，国内推荐使用清华大学开源软件镜像站。

安装系统

系统刻录

推荐使用 balenaEtcher，虚拟机安装则直接选择下载后的镜像即可。

准备操作

确保已经连接到网络，直接连接有线网络或通过 iwctl 连接无线网络

# 同步系统时间
timedatectl set-ntp true

磁盘分区

使用上一步创建启动盘启动系统，启动后会进入一个命令提示符界面，接着开始对磁盘进行分区操作。

注意：此步骤分区基于 GPT 分区表

# 查看磁盘列表，确认要分区的磁盘编号
fdisk -l

# 确认编号后开始进行分区，我这里是磁盘编号为 sda（依据实际情况修改）
fdisk /dev/sda
# 接着按序号进行操作
1. p # 显示分区信息
2. g # 创建 GPT 分区表
3. p # 再次查看分区信息

4. n # 开始创建引导分区
5. <CR> # 回车，分区编号默认
6. <CR> # 回车，起始柱面默认
7. +512M # 启动分区分配 512M

8. n # 开始创建 swap 分区
9. 3 # 分区编号设置为 3
10. <CR> # 回车，起始柱面默认
11. +4G # 交换分区分配 4G（一般为内存大小的 2 倍）

12. n # 开始创建数据分区
13. <CR> # 回车，分区编号默认
14. <CR> # 回车，起始柱面默认
15. <CR> # 回车，剩余空间全部分配给数据分区

16. p # 查看分区信息
17. w # 保存分区信息

格式化分区

# 查看磁盘列表，确认要格式化的分区编号
fdisk -l

# 格式化引导分区，我这里编号为 sda1（依据实际情况修改）
mkfs.fat -F32 /dev/sda1
# 格式化数据分区
mkfs.ext4 /dev/sda2
# 设置并开启 swap 分区
mkswap /dev/sda3
swapon /dev/sda3

挂载分区

# 将数据分区挂载到 /mnt
mount /dev/sda2 /mnt
# 创建引导分区挂载点并挂载
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot

开始安装

# 安装必须的软件、Linux 内核及硬件驱动
pacstrap /mnt base linux linux-firmware

# 生成 fstab
genfstab -U /mnt >> /mnt/etc/fstab
# 检查生成后的 fstab 文件
cat /mnt/etc/fstab

# 进入到新安装的系统
arch-chroot /mnt
# 配置时区（依据实际情况修改）
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
# 同步系统时间
hwclock --systohc
# 检查时间
date
# 退回到安装引导系统
exit

# 配置编码
# 编辑文件打开这两行注释
vim /mnt/etc/locale.gen
en_US.UTF-8 UTF-8
zh_CN.UTF-8 UTF-8
# 新建文件新增一行
vim /mnt/etc/locale.conf
LANG=en_US.UTF-8

# 配置主机名（依据实际情况修改）
echo myhostname > /mnt/etc/hostname

# 重新进入到新安装的系统
arch-chroot /mnt
# 生成编码
locale-gen
# 设置 root 密码
passwd
# 安装引导
pacman -S grub efibootmgr intel-ucode os-prober
# 生成 grub 配置
mkdir /boot/grub
grub-mkconfig > /boot/grub/grub.cfg
# 确认电脑类型，我这里是 x86_64
uname -m
x86_64

# 根据上一步确认的电脑类型安装 grub
grub-install --target=x86_64-efi --efi-directory=/boot

# 安装必要及常用的软件
pacman -S vim vi zsh dhcpcd

# 退回到安装引导系统
exit
# 重启
reboot

安装后的配置

重启后拔掉启动 U 盘或删除 arch 镜像盘片（虚拟机安装）。使用 root 用户登录，密码为在上一节中自行设置的密码。

HTTPS 安全原理

Mon, 28 Sep 2020 00:00:00 +0000

为什么要加密？

如果所有的信息都在互联网上进行明文传输，那么就意味着所有信息都可以被“黑客”随意获取或篡改。

如何加密？

对称加密

设：加密函数为 encode，解密函数为 decode，秘钥为 key，要传输的数据为 data，加密后的数据为 x_data

可得：

encode(key, data) = x_data
decode(key, x_data) = data

即：加密和解密的过程都是通过同一个秘钥 key 完成的，所以对称加密的“**对称”**指的是加密和解密用的是同一个秘钥 key。

下面模拟一次请求的过程：

客户端发送消息时：使用 encode(key, data) = x_data 得到加密后的数据 x_data 并传输给服务端；

服务端接收消息时：接收到加密后的数据 x_data 后使用 decode(key, x_data) = data 解密后得到原始数据 data。

服务器返回消息和客户端接收消息同样的道理不再赘述。

但是问题来了：如何制定秘钥 key 呢？

所有客户端都使用同一个秘钥 key。

那就和明文没有任何区别了，因为任何人（包括“黑客”）都可以通过成为客户端来获取秘钥。
每个客户端制定一个秘钥 key。

i. 首先如何安全的分发定制好的秘钥 key ？这本身也是一个安全通信的问题，一种解决方案是提前与客户端约定好密钥 key，但是这样就会带来下面的第二个问题；

ii. 如果服务端需要和 n 个客户端通信就需要维护 n 个秘钥，当 n 非常大时维护成本也会变得非常高。

所以使用对称加密无法保证整个传输过程的安全性。

非对称加密

设：加密函数为 encode，解密函数为 decode，公钥为 public_key，私钥为 private_key，要传输的数据为 data，使用公钥加密后的数据为 x_data，使用私钥加密后的数据为 x_data'

使用 Certbot 自动申请并续订阿里云 DNS 免费泛域名证书

Wed, 29 Apr 2020 00:00:00 +0000

背景

Certbot 支持自动申请 LetsEncrypt 的泛域名证书，但是官方插件不支持阿里云，在 GitHub 搜索发现已经有人写好了阿里云 DNS 插件，下面只需要进行简单的配置即可免费申请一个泛域名证书并自动续订。

操作步骤

安装 Certbot 和 certbot-dns-aliyun

本文基于 CentOS 7

首先安装 Python 3
```
yum install -y python36
```

创建并激活虚拟环境

mkdir -p /mnt/certbot
cd /mnt/certbot
python3 -m venv venv
source venv/bin/activate

安装 Certbot 和 certbot-dns-aliyun

pip install certbot certbot-nginx certbot-dns-aliyun

申请并配置阿里云 DNS 访问密钥

前往 https://ram.console.aliyun.com 申请阿里云子账号并授予 AliyunDNSFullAccess 权限。然后为子账号创建 AccessKey 并记录。

创建 certbot-dns-aliyun 配置文件：

cat > /mnt/certbot/credentials.ini <<EOF
certbot_dns_aliyun:dns_aliyun_access_key = 12345678
certbot_dns_aliyun:dns_aliyun_access_key_secret = 1234567890abcdef1234567890abcdef
EOF

修改文件权限

解决 Elasticsearch 查询时 Fielddata is disabled on text fields by default 错误

Tue, 28 Apr 2020 00:00:00 +0000

问题描述

以下过程基于 Elasticsearch 7.3

Elasticsearch 启动后无法查询，检查日志发现这样一行日志：

Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default. Set fielddata=true on [type] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead.

日志其实已经说得很清楚了，默认情况下 text 类型的字段 fielddata 被禁用。官方文档在这里。

继续排查日志发现：

Failed to execute [SearchRequest{searchType=QUERY_THEN_FETCH, indices=[.kibana], indicesOptions=IndicesOptions......

是启动 kibana 时报的错。

解决方案

根据文档说明将 [type] 字段 fielddata 设置为 true：

curl -X PUT "localhost:9200/.kibana/_mapping?pretty" -H 'Content-Type: application/json' -d'
{
 "properties": {
 "type": {
 "type": "text",
 "fielddata": true
 }
 }
}
'

总结

首先找到是哪个索引下的哪个字段报错，此例中就是 .kibana 索引的 type 字段，然后将对应字段 fielddata 设置为 true 解决问题。

Android Pie（Android 9）跳过 Google 框架 (GApps) 开机验证方法

Sat, 02 Mar 2019 00:00:00 +0000

如果刷机时刷入了 Google 框架（GApps）可以使用以下方法跳过验证：

进入TWRP，并 mount system 分区，数据线链接电脑。

打开 cmd 或其它终端：

# 将 build.prop 拉取到当前目录
$ adb pull system/build.prop .

# 使用记事本或其他软件在 build.prop 文件最后加入以下代码
ro.setupwizard.mode=DISABLED

# 将 build.prop 文件放回 system
$ adb push ./build.prop system

# 进入手机内部 shell
$ adb shell

# 修改 build.prop 文件权限 (拷贝命令可能有问题，建议直接输入)
$ chmod 0644 system/build.prop

# 退出手机 shell
$ exit

最后拔下数据线重启手机就会跳过验证直接进入桌面了

（完）

Jenkins kubernetes-plugin 使用 Gradle 构建时 Permission denied 问题

Mon, 20 Aug 2018 00:00:00 +0000

在使用 Jenkins 的 kubernetes-plugin 插件时发现使用 Gradle 镜像构建项目时出现 Permission denied 错误，具体错误如下：

[test] Running shell script
sh: 1: cannot create /home/jenkins/workspace/test@tmp/durable-b7fece0a/jenkins-log.txt: Permission denied
sh: 1: cannot create /home/jenkins/workspace/test@tmp/durable-b7fece0a/jenkins-result.txt.tmp: Permission denied
sh: 1: ps: not found
mv: cannot stat '/home/jenkins/workspace/test@tmp/durable-b7fece0a/jenkins-result.txt.tmp': No such file or directory

问题排查

既然出现 Permission denied 肯定要从权限入手了，看错误信息是在工作目录发生的错误，因为 kubernetes-plugin 这个插件会将工作目录挂载出去，以保证所有容器都能访问，所以可能就是就是各个容器的权限不统一造成的，下边验证下这个猜想。

验证

我的 Jenkinsfile 如下：

#!/usr/bin/env groovy
pipeline {
 agent {
 kubernetes {
 label "mypod-${UUID.randomUUID().toString()}"
 yaml """
apiVersion: v1
kind: Pod
metadata:
 name: jenkins-agents
spec:
 containers:
 - name: gradle
 image: gradle:4.9-jdk8-alpine
 command:
 - cat
 tty: true
 volumeMounts:
 - mountPath: /home/gradle/.gradle/caches
 name: gradle-caches
 readOnly: false
 volumes:
 - name: gradle-caches
 persistentVolumeClaim:
 claimName: gradle-caches
"""
 }
 }
 stages {
 stage('编译测试') {
 stages {
 stage('拉取代码') {
 steps {
 git credentialsId: 'gitlab-jenkins', url: 'xxxxxxxx'
 }
 }
 stage('Gradle 编译打包') {
 steps {
 container('gradle') {
 sh 'gradle build'
 }
 }
 }
 }
 }
 }
}

一共只用到两个容器：除了默认的 jnlp 就只有 gradle 了，所用镜像分别是 jenkins/jnlp-slave:3.10-1 和 gradle:4.9-jdk8-alpine。

虚拟机部署 Kubernetes v1.10.3 高可用集群 - 01 虚拟机环境准备

Wed, 30 May 2018 00:00:00 +0000

使用 Vagrant 管理虚拟机集群，下边是安装步骤。

文件准备

目录结构如下：

├── setup.sh
├── Vagrantfile
└── yum
 └── CentOS7-Base-163.repo

Vagrantfile：

def set_vbox(vb, config)
 vb.gui = false
 vb.memory = 1024
 vb.cpus = 1
end

Vagrant.configure("2") do |config|
 config.vm.box_check_update = false
 # 设置虚拟机的 Box
 config.vm.box = "centos/7"
 (1..6).each do |i|
 name = (i <= 3) ? "kube-m" : "kube-n"
 id = (i <= 3) ? i : i - 3
 config.vm.define "#{name}#{id}" do |n|
 n.vm.hostname = "#{name}#{id}"
 ip_addr = "192.168.56.#{i + 10}"
 n.vm.network :private_network, ip: "#{ip_addr}", auto_config: true
 n.vm.provider :virtualbox do |vb, override|
 vb.name = "#{n.vm.hostname}"
 set_vbox(vb, override)
 end
 end
 end
 # 使用shell脚本进行软件安装和配置
 config.vm.provision "shell", path: "./setup.sh"
end

setup.sh：

虚拟机部署 Kubernetes v1.10.3 高可用集群 - 02 生成证书

Wed, 30 May 2018 00:00:00 +0000

在这个部分，将需要产生多个元件的 Certificates，这包含 Etcd、Kubernetes 元件等，并且每个集群都会有一个根数位凭证认证机构 (Root Certificate Authority) 被用在认证 API Server 与 Kubelet 端的凭证。

P.S. 这边要注意 CA JSON 档的 CN(Common Name)与O(Organization) 等内容是会影响 Kubernetes 元件认证的。

准备工作

在主机 kube-m1 上安装 cfssl ，在任意目录执行以下命令：

$ wget https://pkg.cfssl.org/R1.3.2/cfssl_linux-amd64 && chmod +x cfssl_linux-amd64 && mv cfssl_linux-amd64 /usr/local/bin/cfssl

$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 && chmod +x cfssljson_linux-amd64 && mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

$ wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 && chmod +x cfssl-certinfo_linux-amd64 && mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

创建 CA 证书和秘钥

CA 证书 k8s 和 etcd 共用一份，放在 /etc/kubernetes/ssl 下。

创建证书文件夹

mkdir -p /etc/kubernetes/ssl && cd /etc/kubernetes/ssl

创建 CA 配置文件：

$ cat > ca-config.json <<EOF
{
 "signing": {
 "default": {
 "expiry": "8760h"
 },
 "profiles": {
 "kubernetes": {
 "usages": [
 "signing",
 "key encipherment",
 "server auth",
 "client auth"
 ],
 "expiry": "8760h"
 }
 }
 }
}
EOF

ca-config.json：可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；后续在签名证书时使用某个 profile；
signing：表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE；
server auth：表示 client 可以用该 CA 对 server 提供的证书进行验证；
client auth：表示 server 可以用该 CA 对 client 提供的证书进行验证。

创建 CA 证书签名请求：

$ cat > ca-csr.json <<EOF
{
 "CN": "kubernetes",
 "key": {
 "algo": "rsa",
 "size": 2048
 },
 "names": [
 {
 "C": "CN",
 "ST": "ShenZhen",
 "L": "ShenZhen",
 "O": "Kubernetes",
 "OU": "4Paradigm"
 }
 ]
}
EOF

CN"：Common Name，kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name)；浏览器使用该字段验证网站是否合法；
“O”：Organization，kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group)；

生成 CA keys 与 Certificate

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
$ ls ca*
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem

Etcd

在此步骤中将创建与 Etcd 相关的证书文件。

虚拟机部署 Kubernetes v1.10.3 高可用集群 - 03 部署 Master

Wed, 30 May 2018 00:00:00 +0000

本部分将说明如何建立与设定 Kubernetes Master 角色，过程中会部署以下元件：

kube-apiserver：提供 REST APIs，包含授权、认证与状态储存等。
kube-controller-manager：负责维护集群的状态，如自动扩展，滚动更新等。
kube-scheduler：负责资源排程，依据预定的排程策略将 Pod 分配到对应节点上。
Etcd：储存集群所有状态的 Key/Value 储存系统。
HAProxy：提供负载平衡器。
Keepalived：提供虚拟网络位址 (VIP)。

部署和设定

首先在所有 Master 节点下载部署元件的 YAML 文件，这边不采用二进制执行档与 Systemd 来管理这些元件，全部采用 Static Pod 来达成。这边将配置文件放到 /etc/kubernetes/manifests 目录。

以下所有操作需要在每个 Master 上都操作。

$ mkdir -p /etc/kubernetes/manifests && cd /etc/kubernetes/manifests

$ # 替换为当前部署的 master 机器 IP
$ export MASTER_IP=192.168.56.11

kube-apiserver 配置

$ cat > /etc/kubernetes/manifests/kube-apiserver.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
 annotations:
 scheduler.alpha.kubernetes.io/critical-pod: ""
 labels:
 component: kube-apiserver
 tier: control-plane
 name: kube-apiserver
 namespace: kube-system
spec:
 hostNetwork: true
 containers :
 - name: kube-apiserver
 image: gcr.io/google_containers/kube-apiserver-amd64:v1.10.3
 command:
 - kube-apiserver
 - --v=0
 - --logtostderr=true
 - --allow-privileged=true
 - --advertise-address=${MASTER_IP}
 - --bind-address=${MASTER_IP}
 - --insecure-bind-address=${MASTER_IP}
 - --secure-port=5443
 - --insecure-port=7070
 - --service-cluster-ip-range=10.254.0.0/16
 - --service-node-port-range=30000-32767
 - --etcd-servers=https://192.168.56.11:2379,https://192.168.56.12:2379,https://192.168.56.13:2379
 - --etcd-cafile=/etc/kubernetes/ssl/ca.pem
 - --etcd-certfile=/etc/etcd/ssl/etcd.pem
 - --etcd-keyfile=/etc/etcd/ssl/etcd-key.pem
 - --client-ca-file=/etc/kubernetes/ssl/ca.pem
 - --tls-cert-file=/etc/kubernetes/ssl/apiserver.pem
 - --tls-private-key-file=/etc/kubernetes/ssl/apiserver-key.pem
 - --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver.pem
 - --kubelet-client-key=/etc/kubernetes/ssl/apiserver-key.pem
 - --service-account-key-file=/etc/kubernetes/ssl/sa.pub
 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
 - --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota
 - --authorization-mode=Node,RBAC
 - --enable-bootstrap-token-auth=true
 - --requestheader-client-ca-file=/etc/kubernetes/ssl/ca.pem
 - --proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.pem
 - --proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client-key.pem
 - --requestheader-allowed-names=aggregator
 - --requestheader-group-headers=X-Remote-Group
 - --requestheader-extra-headers-prefix=X-Remote-Extra-
 - --requestheader-username-headers=X-Remote-User
 - --audit-log-maxage=30
 - --audit-log-maxbackup=3
 - --audit-log-maxsize=100
 - --audit-log-path=/var/log/kubernetes/audit.log
 - --audit-policy-file=/etc/kubernetes/audit-policy.yml
 - --experimental-encryption-provider-config=/etc/kubernetes/encryption.yml
 - --event-ttl=1h
 livenessProbe:
 failureThreshold: 8
 httpGet:
 host: 127.0.0.1
 path: /healthz
 port: 6443
 scheme: HTTPS
 initialDelaySeconds: 15
 timeoutSeconds: 15
 resources:
 requests:
 cpu: 250m
 volumeMounts:
 - mountPath: /var/log/kubernetes
 name: k8s-audit-log
 - mountPath: /etc/kubernetes/ssl
 name: k8s-certs
 readOnly: true
 - mountPath: /etc/ssl/certs
 name: ca-certs
 readOnly: true
 - mountPath: /etc/kubernetes/encryption.yml
 name: encryption-config
 readOnly: true
 - mountPath: /etc/kubernetes/audit-policy.yml
 name: audit-config
 readOnly: true
 - mountPath: /etc/etcd/ssl
 name: etcd-ca-certs
 readOnly: true
 volumes:
 - hostPath:
 path: /var/log/kubernetes
 type: DirectoryOrCreate
 name: k8s-audit-log
 - hostPath:
 path: /etc/kubernetes/ssl
 type: DirectoryOrCreate
 name: k8s-certs
 - hostPath:
 path: /etc/kubernetes/encryption.yml
 type: FileOrCreate
 name: encryption-config
 - hostPath:
 path: /etc/kubernetes/audit-policy.yml
 type: FileOrCreate
 name: audit-config
 - hostPath:
 path: /etc/ssl/certs
 type: DirectoryOrCreate
 name: ca-certs
 - hostPath:
 path: /etc/etcd/ssl
 type: DirectoryOrCreate
 name: etcd-ca-certs
EOF

kube-apiserver 中的NodeRestriction 请参考 Using Node Authorization

产生一个用来加密 Etcd 的 Key:

虚拟机部署 Kubernetes v1.10.3 高可用集群 - 04 部署 Node

Wed, 30 May 2018 00:00:00 +0000

在开始部署前，先在 kube-m1 将需要用到的文件复制到所有 node 节点上：

$ cd /etc/kubernetes/ssl

$ for NODE in kube-n1 kube-n2 kube-n3; do
 echo "--- $NODE ---"
 ssh ${NODE} "mkdir -p /etc/kubernetes/ssl/"
 ssh ${NODE} "mkdir -p /etc/etcd/ssl"
 # Etcd
 for FILE in etcd.pem etcd-key.pem; do
 scp /etc/etcd/ssl/${FILE} ${NODE}:/etc/etcd/ssl/${FILE}
 done
 # Kubernetes
 for FILE in ssl/ca.pem ssl/ca-key.pem bootstrap-kubelet.conf; do
 scp /etc/kubernetes/${FILE} ${NODE}:/etc/kubernetes/${FILE}
 done
done

部署与设定

以下所有操作需要在每台 Node 节点上都进行一遍。

在每台 node 节点配置 kubelet.service 相关文件来管理 kubelet：

安装 cni 网络插件：

$ mkdir -p /opt/cni/bin && cd /opt/cni/bin
$ export CNI_URL="https://github.com/containernetworking/plugins/releases/download"
$ wget -qO- "${CNI_URL}/v0.6.0/cni-plugins-amd64-v0.6.0.tgz" | tar -zx

配置 kubelet.service：

虚拟机部署 Kubernetes v1.10.3 高可用集群 - 05 总结

Wed, 30 May 2018 00:00:00 +0000

本文的大部分思路参考了『Kubernetes v1.10.x HA 全手動苦工安裝教學(TL;DR)』这篇文章。

不过，虽然 Kairen 同志已经写得很详细了，但是实践起来还是有不少问题的，我在他的基础上根据自己的实践过程写了这篇文档。

可能会出现的问题

apiserver 会一直报错：
```
x509.go:172] x509: subject with cn=system:kube-controller-manager is not in the allowed list: [aggregator]
```
一开始以为是证书有问题，但是查了很久也没发现问题所在，可以忽略此错误，暂时未发现对集群有什么影响。
pod 无法启动，出现 Permission denied 之类的错误。

是由于主机未关闭 SELinux 造成的，参考『虚拟机部署 Kubernetes v1.10.3 高可用集群 - 01 虚拟机环境准备』中的步骤关闭 SELinux 即可。
无法下载镜像问题（墙）。

可以使用 shadowsocks + Proxifier 代理解决；或者使用阿里云仓库里的镜像，脚本如下：

$ ALI_REP="registry.cn-hangzhou.aliyuncs.com/google_containers"
$ GCR="gcr.io/google_containers"
$ K8S_GCR="k8s.gcr.io"

$ for IMAGE in kube-controller-manager-amd64:v1.10.3 kube-apiserver-amd64:v1.10.3 kube-scheduler-amd64:v1.10.3 etcd-amd64:3.1.13; do
 echo "--- $IMAGE ---"
 docker pull $ALI_REP/$IMAGE
 docker tag $ALI_REP/$IMAGE $GCR/$IMAGE
 docker rmi $ALI_REP/$IMAGE
done

$ for IMAGE in kube-proxy-amd64:v1.10.3 pause-amd64:3.1; do
 echo "--- $IMAGE ---"
 docker pull $ALI_REP/$IMAGE
 docker tag $ALI_REP/$IMAGE $K8S_GCR/$IMAGE
 docker rmi $ALI_REP/$IMAGE
done

Spring Boot Admin 集成自定义监控告警

Sat, 19 May 2018 00:00:00 +0000

Spring Boot Admin 是一个社区项目，可以用来监控和管理 Spring Boot 应用并且提供 UI，详细可以参考官方文档。

Spring Boot Admin 本身提供监控告警功能，但是默认只提供了 Hipchat、Slack 等国外流行的通讯软件的集成，虽然也有邮件通知，不过考虑到使用体检决定二次开发增加钉钉通知。

本文基于 Spring Boot Admin 目前最新版 1.5.7。

准备工作

Spring Boot Admin Server，参考文档 http://codecentric.github.io/spring-boot-admin/1.5.7/#getting-started
钉钉自定义机器人，参考文档 https://open-doc.dingtalk.com/docs/doc.htm?spm=a219a.7629140.0.0.64Ddtm&treeId=257&articleId=105735&docType=1

参考自带通知源码

由于官方文档上并没有增加自定义通知相关的文档，所以我们参考一下 Slack 通知源码 SlackNotifier.java。

源码比较长就不全部贴了，看一下关键部分：

public class SlackNotifier extends AbstractStatusChangeNotifier

protected void doNotify(ClientApplicationEvent event) throws Exception {
 this.restTemplate.postForEntity(this.webhookUrl, this.createMessage(event), Void.class);
}

可以看到流程还是比较简单的，继承 AbstractStatusChangeNotifier 类，实现了 doNotify 方法，当应用状态改变的时候会回调 doNotify 方法。

实现钉钉通知

DingTalkNotifier.java

public class DingTalkNotifier extends AbstractStatusChangeNotifier {
 private final SpelExpressionParser parser = new SpelExpressionParser();
 private RestTemplate restTemplate = new RestTemplate();
 private String webhookToken;
 private String atMobiles;
 private String msgtype = "markdown";
 private String title = "服务告警";
 private Expression message;

 public DingTalkNotifier() {
 this.message = this.parser.parseExpression("**#{application.name}** (#{application.id}) is **#{to.status}**", ParserContext.TEMPLATE_EXPRESSION);
 }

 @Override
 protected void doNotify(ClientApplicationEvent event) {
 this.restTemplate.postForEntity(this.webhookToken, this.createMessage(event), Void.class);
 }

 private HttpEntity<Map<String, Object>> createMessage(ClientApplicationEvent event) {
 Map<String, Object> messageJson = new HashMap<>();
 HashMap<String, String> params = new HashMap<>();
 params.put("text", this.getMessage(event));
 params.put("title", this.title);
 messageJson.put("dinggroup", this.dingGroup);
 messageJson.put("atMobiles", this.atMobiles);
 messageJson.put("msgtype", this.msgtype);
 messageJson.put(this.msgtype, params);
 HttpHeaders headers = new HttpHeaders();
 headers.setContentType(MediaType.APPLICATION_JSON_UTF8);
 return new HttpEntity<>(messageJson, headers);
 }

 private String getAtMobilesString(String s) {
 StringBuilder atMobiles = new StringBuilder();
 String[] mobiles = s.split(",");
 for (String mobile : mobiles) {
 atMobiles.append("@").append(mobile);
 }
 return atMobiles.toString();
 }

 private String getMessage(ClientApplicationEvent event) {
 return this.atMobiles == null ? this.message.getValue(event, String.class) : this.message.getValue(event, String.class) + "\n >" + this.getAtMobilesString(this.atMobiles);
 }

 public void setRestTemplate(RestTemplate restTemplate) {
 this.restTemplate = restTemplate;
 }

 public String getWebhookToken() {
 return webhookToken;
 }

 public void setWebhookToken(String webhookToken) {
 this.webhookToken = webhookToken;
 }

 public String getAtMobiles() {
 return atMobiles;
 }

 public void setAtMobiles(String atMobiles) {
 this.atMobiles = atMobiles;
 }

 public String getMsgtype() {
 return msgtype;
 }

 public void setMsgtype(String msgtype) {
 this.msgtype = msgtype;
 }

 public Expression getMessage() {
 return message;
 }

 public void setMessage(String message) {
 this.message = this.parser.parseExpression(message, ParserContext.TEMPLATE_EXPRESSION);
 }

 public String getTitle() {
 return title;
 }

 public void setTitle(String title) {
 this.title = title;
 }
}

代码逻辑也比较简单就不一一解释了。

Find

Mon, 01 Jan 0001 00:00:00 +0000