记录一次 CentOS AArch64 7 到 8 的升级
背景
有一台 AArch64 机器安装了 CentOS 7，想要升级到 CentOS 8，这篇博客主要讲讲折腾的整个过程，而不是教程：如果真要说，就是不要升级 CentOS 大版本，直接重装吧。如果真的想折腾，可以看看下面的内容。
devops¶
在 Apple M1 上试用 Gentoo/Prefix
背景
上一次折腾 Gentoo/Prefix 是五年多以前，当时还是用的 Intel Mac，最近需要探索一下在现在的 macOS 系统上用 Gentoo/Prefix 会遇到哪些问题，因此今天在 Apple M1 上重新尝试一次。
ESXi 配置 LACP 链路聚合
背景
给 ESXi 接了两路 10Gbps 的以太网，需要用 LACP 来聚合。ESXi 自己不能配置 LACP，需要配合 vCenter Server 的 Distributed Switch 来配置。
Ceph Cookbook
概念
- OSD：负责操作硬盘的程序，一个硬盘一个 OSD
- MON：管理集群状态，比较重要，可以在多个节点上各跑一个
- MGR：监测集群状态
- RGW(optional)：提供对象存储 API
- MDS(optional)：提供 CephFS
使用 Ceph 做存储的方式：
- librados: 库
- radosgw: 对象存储 HTTP API
- rbd: 块存储
- cephfs: 文件系统
认证
Ceph 客户端认证需要用户名 + 密钥。默认情况下，用户名是 client.admin，密钥路径是 /etc/ceph/ceph.用户名.keyring。ceph --user abc 表示以用户 client.abc 的身份访问集群。
用户的权限是按照服务类型决定的。可以用 ceph auth ls 显示所有的用户以及权限：
$ ceph auth ls
osd.0
key: REDACTED
caps: [mgr] allow profile osd
caps: [mon] allow profile osd
caps: [osd] allow *
client.admin
key: REDACTED
caps: [mds] allow *
caps: [mgr] allow *
caps: [mon] allow *
caps: [osd] allow *
可以看到，osd.0 对 OSD 有所有权限，对 mgr 和 mon 都只有 osd 相关功能的权限；client.admin 有所有权限。profile 可以认为是预定义的一些权限集合。
新建用户并赋予权限：
修改权限：
获取权限：
删除用户：
OSD
管理 OSD 实际上就是管理存储数据的硬盘。
查看状态：
显示有多少个在线和离线的 OSD。
显示了存储的层级，其中 ID 非负数是实际的 OSD，负数是其他层级，例如存储池，机柜，主机等等。
CRUSH
CRUSH 是一个算法，指定了如何给 PG 分配 OSD，到什么类型的设备，确定它的 failure domain 等等。例如，如果指定 failure domain 为 host，那么它就会分配到不同 host 上的 osd，这样一个 host 挂了不至于全军覆没。类似地，还可以设定更多级别的 failure domain，例如 row，rack，chassis 等等。
OSD 可以设置它的 CRUSH Location，在 ceph.conf 中定义。
为了配置数据置放的规则，需要设置 CRUSH Rule。
列举 CRUSH Rule：
查看 CRUSH 层级：
在里面可能会看到 default~ssd，它指的意思就是只保留 default 下面的 ssd 设备。
文本形式导出 CRUSH 配置：
可以看到 Rule 的定义，如：
# simple replicated
rule replicated_rule {
id 0
# a replicated rule
type replicated
# iterate all devices of "default"
step take default
# select n osd with failure domain "osd"
# firstn: continuous
step chooseleaf firstn 0 type osd
step emit
}
# erasure on hdd
rule erasure-hdd {
id 4
# an erasure rule
type erasure
# try more times to find a good mapping
step set_chooseleaf_tries 5
step set_choose_tries 100
# iterate hdd devices of "default", i.e. "default~hdd"
step take default class hdd
# select n osd with failure domain "osd"
# indep: replace failed osd with another
step choose indep 0 type osd
step emit
}
# replicated on hdd
rule replicated-hdd-osd {
id 5
# a replicated rule
type replicated
# iterate hdd devices of "default", i.e. "default~hdd"
step take default class hdd
# select n osd with failure domain "osd"
# firstn: continuous
step choose firstn 0 type osd
step emit
}
# replicated on different hosts
rule replicated-host {
id 6
# a replicated rule
type replicated
# iterate all devices of "default"
step take default
# select n osd with failure domain "host"
# firstn: continuous
step chooseleaf firstn 0 type host
step emit
}
# replicate one on ssd, two on hdd
rule replicated-ssd-primary {
id 7
# a replicated rule
type replicated
# iterate ssd devices of "default"
step take default class ssd
step chooseleaf firstn 1 type host
step emit
# iterate hdd devices of "default"
step take default class hdd
step chooseleaf firstn 2 type host
step emit
}
choose 和 chooseleaf 的区别是，前者可以 choose 到中间层级，例如先选择 host，再在 host 里面选 osd；而 chooseleaf 是直接找到 osd。所以 choose type osd 和 chooseleaf type osd 是等价的。
如果这个搜索条件比较复杂，例如找到了某一个 host，里面的 osd 个数不够，就需要重新搜。
新建一个 Replicated CRUSH Rule：
# root=default, failure domain=osd
ceph osd crush rule create-replicated xxx default osd
# root=default, failure domain=host, class=ssd
ceph osd crush rule create-replicated yyy default host ssd
如果指定了 device class，它只会在对应类型的设备上存储。
Pool
Pool 是存储池，后续的 RBD/CephFS 功能都需要指定存储池来工作。
创建存储池：
为了性能考虑，可以设置 PG（Placement Group）数量。默认情况下，会创建 replicated 类型的存储池，也就是会存多份，类似 RAID1。也可以设置成 erasure 类型的存储池，类似 RAID5。
每个 Placement Group 里的数据会保存在同一组 OSD 中。数据通过 hash，会分布在不同的 PG 里。
列举所有的存储池：
查看存储池的使用量：
存储池的 IO 状态：
对存储池做快照：
PG
PG 是数据存放的组，每个对象都会放到一个 PG 里面，而 PG 会决定它保存到哪些 OSD 上（具体哪些 OSD 是由 CRUSH 决定的）。PG 数量只有一个的话，那么一个 pool 的所有数据都会存放在某几个 OSD 中，一旦这几个 OSD 都不工作了，那么整个 pool 的数据都不能访问了。PG 增多了以后，就会分布到不同的 OSD 上，并且各个 OSD 的占用也会比较均匀。
查看 PG 状态：
Auto Scale
PG 数量可以让集群自动调整：
设置 autoscale 目标为每个 OSD 平均 100 个 PG：
全局 autoscale 开关：
# Enable
ceph osd pool unset noautoscale
# Disable
ceph osd pool set unautoscale
# Read
ceph osd pool get noautoscale
查看 autoscale 状态：
如果没有显示，说明 autoscale 没有工作，可能的原因是，部分 pool 采用了指定 osd class 的 crush rule，例如指定了 hdd 盘，但是也有部分 pool 没有指定盘的类型，例如默认的 replicated_rule。这时候，把这些盘也设置成一个指定 osd class 的 crush rule 即可。
RBD
RBD 把 Ceph 暴露为块设备。
创建
初始化 Pool 用于 RBD：
为了安全性考虑，一般会为 RBD 用户创建单独的用户：
ceph auth get-or-create client.abc mon 'profile rbd' osd 'profile rbd pool=xxx' mgr 'profile rbd pool=xxx'
创建 RBD 镜像：
表示在 Pool xxx 上面创建了一个名字为 yyy 大小为 1024MB 的镜像。
状态
列举 Pool 里的镜像：
默认的 Pool 名字是 rbd。
查看镜像信息：
扩容
修改镜像的容量：
挂载
在其他机器挂载 RBD 的时候，首先要修改 /etc/ceph 下配置，确认有用户，密钥和 MON 的地址。
然后，用 rbd 挂载设备：
以用户 abc 的身份挂载 Pool xxx 下面的 yyy 镜像。
这时候就可以在 /dev/rbd* 或者 /dev/rbd/ 下面看到设备文件了。
显示已经挂载的设备：
CephFS
创建
如果配置了编排器（Orchestrator），可以直接用命令：
创建一个名为xxx 的 CephFS。
也可以手动创建：
ceph osd pool create xxx_data0
ceph osd pool create xxx_metadata
ceph fs new xxx xxx_metadata xxx_data0
这样就创建了两个 pool，分别用于存储元数据和文件数据。一个 CephFS 需要一个 pool 保存元数据，若干个 pool 保存文件数据。
创建了 CephFS 以后，相应的 MDS 也会启动。
状态
查看 MDS 状态：
客户端配置
在挂载 CephFS 之前，首先要配置客户端。
在集群里运行 ceph config generate-minimal-conf，它会生成一个配置文件：
$ ceph config generate-minimal-conf
# minimal ceph.conf for <fsid>
[global]
fsid = <fsid>
mon_host = [v2:x.x.x.x:3300/0,v1:x.x.x.x:6789/0]
把内容复制到客户端的 /etc/ceph/ceph.conf。这样客户端就能找到集群的 MON 地址和 FSID。
接着，我们在集群上给客户端创建一个用户：
创建一个用户 abc，对 CephFS xxx 有读写的权限。把输出保存到客户端的 /etc/ceph/ceph.client.abc.keyring 即可。
挂载
挂载：
mount -t ceph abc@.xxx=/ MOUNTPOINT
# or
mount -t ceph abc@<fsid>.xxx=/ MOUNTPOINT
# or
mount -t ceph abc@<fsid>.xxx=/ -o mon_addr=x.x.x.x:6789,secret=REDACTED MOUNTPOINT
#or
mount -t ceph abc@.xxx=/ -o mon_addr=x.x.x.x:6789/y.y.y.y:6789,secretfile=/etc/ceph/xxx.secret MOUNTPOINT
# or
mount -t ceph -o name=client.abc,secret=REDACTED,mds_namespace=xxx MON_IP:/ MOUNTPOINT
以用户 client.abc 的身份登录，挂载 CepFS xxx 下面的 / 目录到 MOUNTPOINT。它会读取 /etc/ceph 下面的配置，如果已经 ceph.conf 写了，命令行里就可以不写。
fsid 指的不是 CephFS 的 ID，实际上是集群的 ID：ceph fsid。
限额
CephFS 可以对目录进行限额：
setfattr -n ceph.quota.max_bytes -v LIMIT PATH
setfattr -n ceph.quota.max_files -v LIMIT PATH
getfattr -n ceph.quota.max_bytes PATH
getfattr -n ceph.quota.max_files PATH
限制目录大小和文件数量。LIMIT 是 0 的时候表示没有限制。
NFS
可以把 CephFS 或者 RGW 通过 NFS 的方式共享出去。
启动 NFS 服务：
在主机上运行 NFS 服务器，NFS 集群的名字叫做 xxx。
查看 NFS 集群信息：
列举所有 NFS 集群：
NFS 导出 CephFS：
ceph nfs export create cephfs --cluster-id xxx --pseudo-path /a/b/c --fsname some-cephfs-name [--path=/d/e/f] [--client_addr y.y.y.y]
这样就导出了 CephFS 内的一个目录，客户端可以通过 NFS 挂载 /a/b/c 路径（pseudo path）来访问。可以设置客户端的 IP 访问权限。
这样在客户端就可以 mount：
RadosGW
RGW 提供了 S3 或者 OpenStack Swift 兼容的对象存储 API。
TODO
编排器
由于 Ceph 需要运行多个 daemon，并且都在不同的容器中运行，所以一般会跑一个系统级的编排器，用于新增和管理这些容器。
查看当前编排器：
比较常见的就是 cephadm，安装的时候如果用了 cephadm，那么编排器也是它。
被编排的服务：
被编排的容器：
被编排的主机：
添加新机器
首先，复制 /etc/ceph/ceph.pub 到新机器的 /root/.ssh/authorized_keys 中
接着，添加机器到编排器中：
导出编排器配置：
如果想让一些 daemon 只运行在部分主机上，可以修改：
然后应用：
配置监控
添加监控相关的服务：
ceph orch apply node-exporter
ceph orch apply alertmanager
ceph orch apply prometheus
ceph orch apply grafana
ceph orch ps
然后就可以访问 Grafana 看到集群的状态。
更新
使用容器编排器来升级：
ceph orch upgrade start --ceph-version x.x.x
ceph orch upgrade start --image quay.io/ceph/ceph:vx.x.x
如果 docker hub 上找不到 image，就从 quay.io 拉取。
查看升级状态：
查看 cephadm 日志：
参考文档
解决 k3s 中 traefik 不会转发 X-Forwarded-For 等头部的问题
背景
把应用迁移到 k3s 中，然后用了 traefik 作为 Ingress Controller，发现无法获得真实的用户 IP 地址，而是 cni 内部的地址。搜索了一番，找到了靠谱的解决方案：
Traefik Kubernetes Ingress and X-Forwarded-Headers
具体来说，需要给 traefik 传额外的参数，方法是在 k3s 的配置目录下，添加一个 HelmChartConfig：
# edit /var/lib/rancher/k3s/server/manifests/traefik-config.yaml
# content:
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
additionalArguments:
- "--entryPoints.web.proxyProtocol.insecure"
- "--entryPoints.web.forwardedHeaders.insecure"
这样相当于让 traefik 信任前一级代理传过来的这些头部。更精细的话，还可以设置信任的 IP 地址范围，不过如果 traefik 不会直接暴露出去，就不用考虑这个问题了。
ESXi 常用信息
常用链接
- AMD 最新 microcode 版本
- ESXi 从 6.7 到 6.7U1 升级时出现版本问题
- ESXi 6.7 OEM 版本下载
- ESXi 7.0 OEM 版本下载
- ESXi 8.0 OEM 版本下载
- ESXi 7.0 标准版下载
- ESXi 8.0 标准版下载
- NUC 11 ESXi 7.0 网卡支持：
$ esxcli software vib install -d $PWD/Net-Community-Driver_1.2.0.0-1vmw.700.1.0.15843807_18028830.zip
离线升级方法
- 下载 Offline Bundle 文件
- 上传到 ESXi datastore 中
- 在
/vmfs/volumes/里找到更新文件 - 查询 profile 列表
esxcli software sources profile list -d <zip> - 更新到 profile
esxcli software profile update -p <profile> -d <zip>
ref: Upgrade or Update a Host with Image Profiles
如果 CPU 比较旧，可能会有警告：Updated Plan for CPU Support Discontinuation In Future Major vSphere Releases，按照信息添加参数忽略即可，ESXi 7.0 系列都是支持的，如果之后出了新的版本可能不支持。
在线升级方法
$ esxcli network firewall ruleset set -e true -r httpClient
# find profile name
$ esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
# upgrade to 7.0u3 for example
$ esxcli software profile update -p ESXi-7.0U3-18644231-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
ref: Update Standalone ESXi Host
目前 OEM 版本还没找到在线升级方法，需要下载 zip 然后按照离线升级方法安装。
防火墙
列出所有防火墙规则：
允许出站 SSH：
关闭出站 SSH：
NUC11i5 ESXi 7.0 安装过程
- 下载 ESXi ISO 文件，用 UNetbootin 制作安装盘
- 插入 U 盘，在 NUC 上安装 ESXi，在 81% 的时候卡住了，不管直接重启
- 用 root 无密码登录进去，然后重置网络设置
- 配置 usb 网卡，然后通过网页访问 ESXi，打开 SSH
- 下载 Fling 上面的社区网卡支持，用 esxcli 安装
- 重启以后，就可以看到 vmnic0 网卡了
参考：Solution: ESXi Installation with USB NIC only fails at 81%
推荐博客
发现以下博客有很多关于 ESXi 的内容：
- https://williamlam.com/
- https://www.virten.net/
重要版本更新
参考 ESXi/vCSA Release Notes：
- Performance improvements for AMD Zen CPUs: With ESXi 7.0 Update 2, out-of-the-box optimizations can increase AMD Zen CPU performance by up to 30% in various benchmarks. The updated ESXi scheduler takes full advantage of the AMD NUMA architecture to make the most appropriate placement decisions for virtual machines and containers. AMD Zen CPU optimizations allow a higher number of VMs or container deployments with better performance.
- Reduced compute and I/O latency, and jitter for latency sensitive workloads: Latency sensitive workloads, such as in financial and telecom applications, can see significant performance benefit from I/O latency and jitter optimizations in ESXi 7.0 Update 2. The optimizations reduce interference and jitter sources to provide a consistent runtime environment. With ESXi 7.0 Update 2, you can also see higher speed in interrupt delivery for passthrough devices.
- vSphere Lifecycle Manager fast upgrades: Starting with vSphere 7.0 Update 2, you can configure vSphere Lifecycle Manager to suspend virtual machines to memory instead of migrating them, powering them off, or suspending them to disk. For more information, see Configuring vSphere Lifecycle Manager for Fast Upgrades.
- Zero downtime, zero data loss for mission critical VMs in case of Machine Check Exception (MCE) hardware failure: With vSphere 7.0 Update 3, mission critical VMs protected by VMware vSphere Fault Tolerance can achieve zero downtime, zero data loss in case of Machine Check Exception (MCE) hardware failure, because VMs fallback to the secondary VM, instead of failing. For more information, see How Fault Tolerance Works.
vCSA 相关常见错误
- https://kb.vmware.com/s/article/85468 vCSA 日志分区
/storage/log满，原因是访问 vmware 网站失败打印的日志太大：/storage/log/vmware/analytics/analytics-runtime.log*；解决方法：vmon-cli -r analytics重启服务，然后删掉旧的日志。 - https://kb.vmware.com/s/article/83070 vCSA 日志分区
/storage/log满，原因是 tomcat 日志太大。 XXX Service Health Alarm：尝试重启对应服务，比如vmon-cli -r perfcharts对应Performance Charts，vmon-cli -r vapi-endpoint对应VMWare vAPI Endpoint
查看更新状态：cat /storage/core/software-update/stage_operation；更新文件下载路径：/storage/updatemgr/software-update*/stage。有一个包特别大：wcpovf 需要两个多 G。
CLI 更新方法：https://earlruby.org/2021/01/upgrading-vcenter-7-via-the-command-line/
迁移虚拟机到不同 VM
首先，unregister 原来的 VM，然后把文件移动到新的路径下。对于 Thin Provisioned Disk，需要特殊处理，否则直接复制的话，会变成 Thick Provisioned Disk，正确方法是采用 vmkfstool：
需要注意的是，这里的路径用的是不带 -flat 的 vmdk，因为这个文件记录了 metadata，而 -flat.vmdk 保存了实际的数据。可以用 du 命令看实际的硬盘占用，从而确认它确实是 Thin Provisioned。
如果已经在 Web UI 上复制了，你会发现无法停止复制，解决办法是：
这样就会重启 Web UI，不过等它恢复需要很长的时间，还要删掉 cookie。
研究 k8s 网络工作原理
背景
用 k8s 也有一段时间了，之前遇到过 iptables 等出现问题，导致 k8s 节点间网络出现问题，于是想研究一下 k8s 的网络工作原理。
Docker 网络
首先研究一下 Docker 网络连接是如何实现的。Docker 首先会创建一个 bridge，名为 bridge0:
$ ip a show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c4:87:73:bf brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:c4ff:fe87:73bf/64 scope link
valid_lft forever preferred_lft forever
默认情况下，每个容器都会有单独的一个 netns，然后创建一对 veth pair，一端留在 global netns，另一端放到容器中。在 global netns 中的 veth 端口会加入到 docker0 中：
$ ip a show dev veth3db9316
21: veth3db9316@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether e2:49:a6:2d:5a:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::e049:a6ff:fe2d:5abd/64 scope link
valid_lft forever preferred_lft forever
$ brctl show docker0
bridge name bridge id STP enabled interfaces
docker0 8000.0242c48773bf no veth3db9316
容器中的网络，在 veth 上 docker 会分配并配置一个地址（比如 172.17.0.2），然后设置默认路由 via 172.17.0.1。一方面，可以通过默认路由到 172.17.0.1 再通过 iptables NAT 访问外面的网络：
$ iptables-save -t nat
# Generated by xtables-save v1.8.2 on Sat Sep 18 10:44:49 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A DOCKER -i docker0 -j RETURN
COMMIT
# Completed on Sat Sep 18 10:44:49 2021
另一方面，因为连接不同容器的 veth 在同一个 bridge 下面，所以不同容器的可以认为在同一个二层网络中，自然可以互相访问。
K8s 网络
在 k8s 中，所有的 pod 都希望可以通过 IP 地址互联。一个思路是把各个节点上的 pod 通过类似 docker 的方法实现，即每个 netns 通过 veth 连接到一个 bridge 上，然后再想办法去路由在其它节点上的 pod。
因为我用 k3s 搭建 k8s 集群，它用的 cni 是 flannel。flannel 采用的是 vxlan 的方式来实现节点间的网络通信。
首先还是看看节点内的 pod 如何组网。
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
link/ether 6a:4f:ff:8b:b1:b3 brd ff:ff:ff:ff:ff:ff
inet 10.42.0.1/24 brd 10.42.0.255 scope global cni0
valid_lft forever preferred_lft forever
inet6 fe80::7cf6:57ff:fed7:c49b/64 scope link
valid_lft forever preferred_lft forever
6: vethc47d6140@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default
link/ether da:19:f8:48:f6:49 brd ff:ff:ff:ff:ff:ff link-netns cni-9d2a5120-16a3-453e-bf64-c4006c06c93b
inet6 fe80::d819:f8ff:fe48:f649/64 scope link
valid_lft forever preferred_lft forever
首先，flannel 给每个节点分配了一个 /24 的网段，比如第一个节点是 10.42.0.0/24，第二个是 10.42.1.0/24，依次类推。然后，节点内的 pod 就从这个网段里分配地址，比如 10.42.0.50/24，它的默认网关是 10.42.0.1。这些 veth 都会加入到 cni0 的 bridge 中。这一部分原理和 docker 是一样的，只不过名字不同了。也有相应的 iptables 规则：
$ iptables-save | grep MASQUERADE
-A POSTROUTING -s 10.42.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully
-A POSTROUTING ! -s 10.42.0.0/16 -d 10.42.0.0/16 -j MASQUERADE --random-fully
那么，节点间网络如何实现呢？假如，我们要从第一个节点 pod 10.42.0.50/24 访问第二个节点的 pod 10.42.1.51/24，首先，pod 根据默认路由会发给 10.42.0.1/24，到达第一个节点的 cni0，然后查路由表：
$ ip r
10.42.0.0/24 dev cni0 proto kernel scope link src 10.42.0.1
10.42.1.0/24 via 10.42.1.0 dev flannel.1 onlink
可以看到，它会匹配 10.42.1.0/24 via 10.42.1.0 dev flannel.1 的路由。flannel.1 是一个 vxlan 的 interface：
$ ip a show flannel.1
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
link/ether b6:2f:39:4a:02:c0 brd ff:ff:ff:ff:ff:ff
inet 10.42.0.0/32 scope global flannel.1
valid_lft forever preferred_lft forever
inet6 fe80::b42f:39ff:fe4a:2c0/64 scope link
valid_lft forever preferred_lft forever
当这个 interface 接收到一个 packet 的时候，会查询 fdb：
这个 fdb 中包括了 (MAC 地址，IP 地址) 的 tuple。当 flannel.1 收到一个 Ethernet Frame 的时候，如果目的地址匹配这里的 MAC 地址，就会直接把 Eth Frame 封装到 UDP 里面发给目的 IP 地址；否则，就会在这个表里面 broadcast。这样，第二个节点就会收到 packet 并且转给实际的 pod。
总结
总结一下 k8s 的网络互联的实现方法：节点内通过 bridge 实现，把链接各个 netns 的 veth 桥接起来；节点间划分为多个子网，子网间通过 flannel 的网关进行路由，flannel 网关间通过 vxlan 进行互联。
参考文档
将 k8s rook ceph 集群迁移到 cephadm
背景
前段时间用 rook 搭建了一个 k8s 内部的 ceph 集群，但是使用过程中遇到了一些稳定性问题，所以想要用 cephadm 重建一个 ceph 集群。
重建过程
重建的时候，我首先用 cephadm 搭建了一个 ceph 集群，再把原来的 MON 数据导入，再恢复各个 OSD。理论上，可能有更优雅的办法，但我还是慢慢通过比较复杂的办法解决了。
cephadm 搭建 ceph 集群
首先，配置 TUNA 源，在各个节点上安装 docker-ce 和 cephadm。接着，在主节点上 bootstrap：
此时，在主节点上会运行最基础的 ceph 集群，不过此时还没有任何数据。寻找 ceph 分区，会发现因为 FSID 不匹配而无法导入。所以，首先要恢复 MON 数据。
参考文档：cephadm install。
恢复 MON 数据
首先，关掉 rook ceph 集群，找到留存下来的 MON 数据目录，默认路径是 /var/lib/rook 下的 mon-[a-z] 目录，找到最新的一个即可。我把目录下的路径覆盖到 cephadm 生成的 MON 目录下，然后跑起来，发现有几个问题：
- cephadm 生成的 /etc/ceph/ceph.client.admin.keyring 与 MON 中保存的 auth 信息不匹配，导致无法访问
- FSID 不一致，而 cephadm 会将各个设置目录放到
/var/lib/ceph/$FSID下
第一个问题的解决办法就是临时用 MON 目录下的 keyring 进行认证，再创建一个新的 client.admin 认证。第二个问题的解决办法就是将遇到的各种 cephadm 生成的 FSID 替换为 MON 中的 FSID，包括目录名、各个目录下 unit.run 中的路径和 systemd unit 的名称。
进行一系列替换以后，原来的 MON 已经起来了，可以看到原来保留的各个 pool 和 cephfs 信息。
扩展到多节点
接下来，由于 MON 中保存的数据更新了，所以要重新生成 cephadm 的 SSH 密钥。将 SSH 密钥复制到各节点后，再用 cephadm 的 orch 功能部署到其他节点上。此时 FSID 都已经是 MON 中的 FSID，不需要替换。此时可以在 ceph orch ps 命令中看到在各个节点上运行的程序。接下来，还需要恢复各个 OSD。
导入 OSD
为了从 ceph 分区从导出 OSD 的配置文件，需要用 ceph-volume 工具。这个工具会生成一个 /var/lib/ceph/osd-ID 目录，在 cephadm 的概念里属于 legacy，因此我们首先要把路径 mount 到 shell 里面：
接着，生成 osd 目录配置：
然后，可以看到创建了对应的 osd 路径，再用 cephadm 进行转换：
这样就可以用 cephadm 管理了。
配置 k8s
配置好外部 ceph 集群后，还需要配置 k8s rook。
参考 https://rook.github.io/docs/rook/v1.8/ceph-cluster-crd.html#external-cluster，大概有这么几步：
- 在 ceph 集群上运行 create-external-cluster-resources.sh，创建用户，并且导出 key
- 在 k8s 集群上应用第一步生成的环境变量，然后运行 import-external-cluster.sh
- 复制一份 cluster-external.yaml 然后应用
- 复制 storageclass.yaml，把里面的 namespace 改成 rook-ceph-external
在 ESXi 中用 PERCCli 换 RAID 中的盘
背景
最近有一台机器的盘出现了报警，需要换掉，然后重建 RAID5 阵列。iDRAC 出现报错：
- Disk 2 in Backplane 1 of Integrated RAID Controller 1 is not functioning correctly.
- Virtual Disk 1 on Integrated RAID Controller 1 has become degraded.
- Error occurred on Disk2 in Backplane 1 of Integrated RAID Controller 1 : (Error 2)
安装 PERCCli
首先，因为系统是 VMware ESXi 6.7，所以在DELL 官网下载对应的文件。按照里面的 README 安装 vib：
如果要升级系统，需要先卸载 vib：esxcli software vib remove -n vmware-perccli，因为升级的时候会发现缺少新版系统的 perccli，建议先卸载，升级后再安装新的。
需要注意的是，如果复制上去 Linux 版本的 PERCCli，虽然也可以运行，但是找不到控制器。安装好以后，就可以运行 /opt/lsi/perccli/perccli 。接着，运行 perccli show all，可以看到类似下面的信息：
$ perccli show all
--------------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
--------------------------------------------------------------------------------
32:2 2 Failed 1 3.637 TB SATA HDD N N 512B ST4000NM0033-9ZM170 U -
32:4 4 UGood F 3.637 TB SATA HDD N N 512B ST4000NM0033-9ZM170 U -
--------------------------------------------------------------------------------
其中 E32S2 是 Failed 的盘，属于 Disk Group 1；E32S4 是新插入的盘，准备替换掉 E32S2，目前不属于任何的 Disk Group。查看一下 Disk Group：perccli /c0/dall show
$ perccli /c0/dall show
-----------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace TR
-----------------------------------------------------------------------------
1 - - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 0 32:1 1 DRIVE Onln N 3.637 TB dflt N N dflt - N
1 0 1 32:2 2 DRIVE Failed N 3.637 TB dflt N N dflt - N
1 0 2 32:3 3 DRIVE Onln N 3.637 TB dflt N N dflt - N
可以看到 DG1 处于 Degraded 状态，然后 E32S4 处于 Failed 状态。参考了一下 PERCCli 文档，它告诉我们要这么做：
perccli /cx[/ex]/sx set offline
perccli /cx[/ex]/sx set missing
perccli /cx /dall show
perccli /cx[/ex]/sx insert dg=a array=b row=c
perccli /cx[/ex]/sx start rebuild
具体到我们这个情景，就是把 E32S2 设为 offline，然后用 E32S4 来替换它：
perccli /c0/e32/s2 set offline
perccli /c0/e32/s2 set missing
perccli /cx /dall show
perccli /cx/e32/s4 insert dg=1 array=0 row=2
perccli /cx/e32/s4 start rebuild
完成以后的状态：
TOPOLOGY :
========
---------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace TR
---------------------------------------------------------------------------
1 - - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 0 32:1 1 DRIVE Onln N 3.637 TB dflt N N dflt - N
1 0 1 32:4 4 DRIVE Rbld Y 3.637 TB dflt N N dflt - N
1 0 2 32:3 3 DRIVE Onln N 3.637 TB dflt N N dflt - N
---------------------------------------------------------------------------
可以看到 E32S4 替换了原来 E32S2 的位置，并且开始重建。查看重建进度：
$ perccli /c0/32/s4 show rebuild
-----------------------------------------------------
Drive-ID Progress% Status Estimated Time Left
-----------------------------------------------------
/c0/e32/s4 3 In progress -
-----------------------------------------------------
$ perccli show all
Need Attention :
==============
Controller 0 :
============
-------------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
-------------------------------------------------------------------------------
32:4 4 Rbld 1 3.637 TB SATA HDD N N 512B ST4000NM0033-9ZM170 U -
-------------------------------------------------------------------------------
然后，查看一下出错的盘：
$ perccli /c0/e32/s2 show all
Drive /c0/e32/s2 State :
======================
Shield Counter = 0
Media Error Count = 0
Other Error Count = 6
Drive Temperature = 36C (96.80 F)
Predictive Failure Count = 0
S.M.A.R.T alert flagged by drive = No
果然有错误，但是也看不到更多信息了。
坏块统计：
$ perccli /c0 show badblocks
Detailed Status :
===============
-------------------------------------------------------------
Ctrl Status Ctrl_Prop Value ErrMsg ErrCd
-------------------------------------------------------------
0 Failed Bad Block Count - BadBlockCount failed 2
-------------------------------------------------------------
经过检查以后，发现 E32S2 盘的 SMART 并没有报告什么问题，所以也没有把盘取走，而是作为 hot spare 当备用：
$ perccli /c0/e32/s2 add hotsparedrive DG=1
$ perccli /c0/d1 show
TOPOLOGY :
========
---------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type State BT Size PDC PI SED DS3 FSpace TR
---------------------------------------------------------------------------
1 - - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 - - - RAID5 Dgrd N 7.276 TB dflt N N dflt N N
1 0 0 32:1 1 DRIVE Onln N 3.637 TB dflt N N dflt - N
1 0 1 32:4 4 DRIVE Rbld Y 3.637 TB dflt N N dflt - N
1 0 2 32:3 3 DRIVE Onln N 3.637 TB dflt N N dflt - N
1 - - 32:2 2 DRIVE DHS - 3.637 TB - - - - - N
---------------------------------------------------------------------------
DG=Disk Group Index|Arr=Array Index|Row=Row Index|EID=Enclosure Device ID
DID=Device ID|Type=Drive Type|Onln=Online|Rbld=Rebuild|Optl=Optimal|Dgrd=Degraded
Pdgd=Partially degraded|Offln=Offline|BT=Background Task Active
PDC=PD Cache|PI=Protection Info|SED=Self Encrypting Drive|Frgn=Foreign
DS3=Dimmer Switch 3|dflt=Default|Msng=Missing|FSpace=Free Space Present
TR=Transport Ready
这样就可以做后备盘，当别的盘坏的时候，作为备用。
相关软件下载
可以在这里寻找 StorCLI 版本。
StorCLI：
- 008.0005.0000.0010 Feb 22, 2023 008.0005.0000.0010_StorCLI.zip，注：不支持旧型号
- 007.1613.0000.0000 Oct 29, 2020 007.1613.0000.0000_Unified_StorCLI.zip
- 007.1506.0000.0000 Aug 11, 2020 StorCLI_MR7.15.zip
- 1.15.12 Apr 23, 2015 MR_SAS_StorCLI_6-7-1-15-12-SCGCQ00852539.zip
- 1.15.05 Jan 22, 2015 1-15-05_StorCLI.zip
MegaCLI:
- 8.07.07 Dec 19, 2012 8-07-07_MegaCLI.zip
PercCLI:
- 007.1420.0000.0000 Dec 10, 2020 PERCCLI_N65F1_7.1420.00_A10_Linux.tar.gz PERCCLI_5V7XX_7.1420.0_A10_VMware.tar.gz
- 007.1327.0000.0000 July 27, 2020 PERCCLI_D6YWP_7.1327.00_A09_Linux.tar.gz
- 007.0127.0000.0000 July 13, 2017 perccli_7.1-007.0127_linux.tar.gz
用 fluentd 收集 k8s 中容器的日志
背景
在维护一个 k8s 集群的时候，一个很常见的需求就是把日志持久化存下来，一方面是方便日后回溯，一方面也是聚合 replicate 出来的同一个服务的日志。
在我目前的需求下，只需要把日志持久下来，还不需要做额外的分析。所以我并没有部署类似 ElasticSearch 的服务来对日志进行索引。
实现
实现主要参考官方的仓库：https://github.com/fluent/fluentd-kubernetes-daemonset。它把一些常用的插件打包到 docker 镜像中，然后提供了一些默认的设置，比如获取 k8s 日志和 pod 日志等等。为了达到我的需求，我希望：
- 每个结点上有一个 fluentd 收集日志，forward 到单独的 log server 上的 fluentd
- log server 上的 fluentd 把收到的日志保存到文件
由于 log server 不由 k8s 管理，所以按照官网的方式手动安装：
然后，编辑配置 /etc/td-agent/td-agent.conf：
<source>
@type forward
@id input_forward
bind x.x.x.x
</source>
<match **>
@type file
path /var/log/fluentd/k8s
compress gzip
<buffer>
timekey 1d
timekey_use_utc true
timekey_wait 10m
</buffer>
</match>
分别设置输入：监听 fluentd forward 协议；输出：设置输出文件，和 buffer 配置。如有需要，可以加鉴权。
接着，按照 https://github.com/fluent/fluentd-kubernetes-daemonset/blob/master/fluentd-daemonset-forward.yaml，我做了一些修改，得到了下面的配置：
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: fluentd
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: fluentd
namespace: kube-system
rules:
- apiGroups:
- ""
resources:
- pods
- namespaces
verbs:
- get
- list
- watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: fluentd
roleRef:
kind: ClusterRole
name: fluentd
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: fluentd
namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
namespace: kube-system
labels:
k8s-app: fluentd-logging
version: v1
spec:
selector:
matchLabels:
k8s-app: fluentd-logging
version: v1
template:
metadata:
labels:
k8s-app: fluentd-logging
version: v1
spec:
serviceAccount: fluentd
serviceAccountName: fluentd
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd
image: fluent/fluentd-kubernetes-daemonset:v1-debian-forward
env:
- name: FLUENT_FOWARD_HOST
value: "x.x.x.x"
- name: FLUENT_FOWARD_PORT
value: "24224"
- name: FLUENTD_SYSTEMD_CONF
value: "disable"
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: config-volume
mountPath: /fluentd/etc/tail_container_parse.conf
subPath: tail_container_parse.conf
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: config-volume
configMap:
name: fluentd-config
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
---
apiVersion: v1
kind: ConfigMap
metadata:
name: fluentd-config
namespace: kube-system
data:
tail_container_parse.conf: |-
<parse>
@type cri
</parse>
和原版有几点细节上的不同：
- k8s 启用了 rbac，所以需要对应的配置；照着仓库里其他带 rbac 配置的文件抄一下即可。
- 禁用了 SYSTEMD 日志的抓取，因为我用的是 k3s，而不是 kubeadm，自然找不到 kubelet 的 systemd service。
- 覆盖了 container 日志的读取，因为使用的 container runtime 日志格式和默认的不同，这部分设置在仓库的 README 中也有提到。
部署到 k8s 中即可。为了保证日志的准确性，建议各个结点都保持 NTP 的同步。
用 gitlab ci 构建并部署应用到 k8s
背景
在 k8s 集群中部署了 gitlab-runner，并且希望在 gitlab ci 构建完成后，把新的 docker image push 到 private repo，然后更新应用。
参考文档：Gitlab CI 与 Kubernetes 的结合，Using Docker to build Docker images。
在 gitlab ci 中构建 docker 镜像
这一步需要 DinD 来实现在容器中构建容器。为了达到这个目的，首先要在 gitlab-runner 的配置中添加一个 volume 来共享 DinD 的证书路径：
gitlabUrl: REDACTED
rbac:
create: true
runnerRegistrationToken: REDACTED
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:20.04"
privileged = true
[[runners.kubernetes.volumes.empty_dir]]
name = "docker-certs"
mount_path = "/certs/client"
medium = "Memory"
privileged: true
注意两点：1. privileged 2. 多出来的 volume
用 helm 部署 gitlab runner 之后，按照下面的方式配置 gitlab-ci：
image: docker:19.03.12
variables:
DOCKER_HOST: tcp://docker:2376
#
# The 'docker' hostname is the alias of the service container as described at
# https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services.
# If you're using GitLab Runner 12.7 or earlier with the Kubernetes executor and Kubernetes 1.6 or earlier,
# the variable must be set to tcp://localhost:2376 because of how the
# Kubernetes executor connects services to the job container
# DOCKER_HOST: tcp://localhost:2376
#
# Specify to Docker where to create the certificates, Docker will
# create them automatically on boot, and will create
# `/certs/client` that will be shared between the service and job
# container, thanks to volume mount from config.toml
DOCKER_TLS_CERTDIR: "/certs"
# These are usually specified by the entrypoint, however the
# Kubernetes executor doesn't run entrypoints
# https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4125
DOCKER_TLS_VERIFY: 1
DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
DOCKER_DAEMON_OPTIONS: "--insecure-registry=${REGISTRY}"
services:
- name: docker:19.03.12-dind
entrypoint: ["sh", "-c", "dockerd-entrypoint.sh $DOCKER_DAEMON_OPTIONS"]
before_script:
# Wait until client certs are generated
# https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27384
- until docker info; do sleep 1; done
- echo "$REGISTRY_PASS" | docker login $REGISTRY --username $REGISTRY_USER --password-stdin
build:
stage: build
script: ./build.sh
这里有很多细节，包括 DinD 的访问方式，等待 client cert，设置 docker 的 insecure registry 和 login 等等。经过 @CircuitCoder 的不断摸索，终于写出了可以用的配置。
如此配置以后，就可以在 gitlab ci 的构建脚本里用 docker 来 build 并且 push 到自己的 registry 了。为了防止泄露密钥，建议把这些变量放到 gitlab ci 设置的 secrets 中。
自动部署到 k8s
为了让 k8s 重启一个 deployment，一般的做法是：
我们希望 gitlab ci 在 build 之后，去执行这一个命令，但又不希望提供太多的权限给 gitlab。所以，我们创建 Service Account 并设置最小权限：
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab
namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: gitlab-test
namespace: test
rules:
- verbs:
- get
- patch
apiGroups:
- 'apps'
resources:
- 'deployments'
resourceNames:
- 'test-deployment'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: gitlab
namespace: test
subjects:
- kind: ServiceAccount
name: gitlab
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: gitlab-test
要特别注意这几个配置的 namespace 的对应关系：Role 和 RoleBinding 需要放在同一个 ns 下。
接着，到 GitLab 的 Operations->Kubernetes 创建 cluster，把 service account 的 token 和 ca.crt 从 secret 里找到并贴到网页上。GitLab 会按照 Environment scope 匹配到 environment，如果某个 stage 的 environment 匹配上了，就会把 kube credentials 配置好。修改 gitlab-ci.yml：
deploy:
stage: deploy
image: bitnami/kubectl:1.20
environment:
name: production
only:
- master
script:
- kubectl -n test rollout restart deployment/test
这样就完成配置了。
通过 rook 在 k8s 上部署 ceph 集群
背景
为了方便集群的使用，想在 k8s 集群里部署一个 ceph 集群。
Ceph 有这些组成部分：
- mon：monitor
- mgr：manager
- osd：storage
- mds(optional)：用于 CephFS
- radosgw(optional：用于 Ceph Object Storage
配置
我们采用的是 rook 来部署 ceph 集群。
参考文档：https://rook.github.io/docs/rook/v1.5/ceph-examples.html
首先，克隆 rook 的仓库。建议选择一个 release 版本。
接着，运行下面的命令：
sudo apt install -y lvm2
# required
kubectl apply -f rook/cluster/examples/kubernetes/ceph/crds.yaml
kubectl apply -f rook/cluster/examples/kubernetes/ceph/common.yaml
kubectl apply -f rook/cluster/examples/kubernetes/ceph/operator.yaml
# debugging only
kubectl apply -f rook/cluster/examples/kubernetes/ceph/toolbox.yaml
kubectl apply -f rook/cluster/examples/kubernetes/ceph/direct-mount.yaml
# CephFS
kubectl apply -f rook/cluster/examples/kubernetes/ceph/filesystem.yaml
kubectl apply -f rook/cluster/examples/kubernetes/ceph/csi/cephfs/storageclass.yaml
前面三个 yaml 是必须的，toolbox 是用来查看 ceph 状态的，direct mount 是用来 mount cephfs 的，后两个是为了用 cephfs 的。
接着，按照自己的需求编辑 rook/cluster/exmaples/kuberenetes/ceph/cluster.yaml 然后应用。此时你的集群应该就已经起来了。
然后，可以进 toolbox 查看 ceph 状态：
# get volume path of pvc
kubectl get pv -o custom-columns=NAME:.metadata.name,NAMSEPACE:.spec.claimRef.namespace,CLAIM:.spec.claimRef.name,PATH:.spec.csi.volumeAttributes.subvolumeName
kubectl -n rook-ceph exec -it deploy/rook-direct-mount -- bash
# in the pod
mkdir /tmp/registry
mon_endpoints=$(grep mon_host /etc/ceph/ceph.conf | awk '{print $3}')
my_secret=$(grep key /etc/ceph/keyring | awk '{print $3}')
mount -t ceph -o mds_namespace=myfs,name=admin,secret=$my_secret $mon_endpoints:/ /tmp/registry
df -h
cd /tmp/registry/volumes/csi/PATH
用 k3s 部署 k8s
背景
最近需要部署一个 k8s 集群，觉得之前配置 kubeadm 太繁琐了，想要找一个简单的。比较了一下 k0s 和 k3s，最后选择了 k3s。
配置
k3s 的好处就是配置十分简单：https://rancher.com/docs/k3s/latest/en/quick-start/。不需要装 docker，也不需要装 kubeadm。
- 在第一个 node 上跑：
curl -sfL https://get.k3s.io | sh - - 在第一个 node 上获取 token：
cat /var/lib/rancher/k3s/server/node-token - 在其他 node 上跑：
curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken sh -
然后就搞定了。从第一个 node 的 /etc/rancher/k3s/k3s.yaml获取 kubectl 配置。
常用交换机命令
背景
最近接触了 Cisco，DELL，Huawei，H3C，Ruijie 的网络设备，发现配置方式各有不同，故记录一下各个厂家的命令。
Huawei
测试型号：S5320
保存配置
<HUAWEI>save
The current configuration will be written to flash:/vrpcfg.zip.
Are you sure to continue?[Y/N]y
Now saving the current configuration to the slot 0....
Save the configuration successfully.
进入配置模式
查看当前配置
查看 LLDP 邻居
查看 CDP 邻居
启用 LLDP
启用 CDP
启用只读 SNMPv1 community
[HUAWEI]snmp-agent sys-info version all
Warning: This command may cause confliction in netconf status. Continue? [Y/N]:y
Warning: SNMPv1/SNMPv2c is not secure, and it is recommended to use SNMPv3.
[HUAWEI]snmp-agent community read [COMMUNITY NAME]
Warning: This command may cause confliction in netconf status. Continue? [Y/N]:y
启用 SNMP iso view
默认情况下 SNMP 会缺少一些标准的 MIB（比如 LLDP），可以打开 iso view：
[HUAWEI]snmp-agent mib-view included iso-view iso
Warning: This command may cause confliction in netconf status. Continue? [Y/N]:y
[HUAWEI]snmp-agent community read [COMMUNITY NAME] mib-view iso-view
查看 ARP 表
ARPING
启用 STP 协议
设置 NTP 服务器
设置远程 syslog 服务器
设置 LACP 链路聚合
[HUAWEI-XGigabitEthernet0/0/1]eth-trunk 1
[HUAWEI-XGigabitEthernet0/0/2]eth-trunk 1
[HUAWEI]interface Eth-Trunk 1
[HUAWEI-Eth-Trunk1]mode lacp
DELL
测试型号：N3048
保存配置
console#copy running-config startup-config
This operation may take few minutes.
Management interfaces will not be available during this time.
Are you sure you want to save? (y/n) y
Configuration Saved!
进入配置模式
查看当前配置
查看 LLDP 邻居
VLAN Trunk 配置
console(config)#interface Gi1/0/1
console(config-if-Gi1/0/1)#switchport mode trunk
console(config-if-Gi1/0/1)#switchport trunk allowed vlan xxx,xxx-xxx
VLAN Access 配置
console(config)#interface Gi1/0/1
console(config-if-Gi1/0/1)#switchport mode access
console(config-if-Gi1/0/1)#switchport access vlan xxx
查看 VLAN 配置
批量配置 interface
启用 SSH 服务器
console(config)#crypto key generate rsa
console(config)#crypto key generate dsa
console(config)#ip ssh server
启用 CDP(DELL 称之为 ISDP)
启用只读 SNMPv1 community
设置 NTP 服务器
设置 NTP 服务器
设置 STP 协议
H3C
进入配置模式
查看当前配置
查看 lldp 邻居
保存配置
[switch]save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[flash:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):y
The file name is invalid(does not end with .cfg).
批量配置 interface
查看 MAC 地址表
打开 LLDP 和 CDP
Mellanox
进入配置模式
查看当前配置
查看 interface 状态
查看以太网端口状态
查看 lldp 邻居
保存配置
批量配置 interface
查看 MAC 地址表
查看链路聚合状态
把拆分的四个 SFP 口恢复成一个
把一个 QSFP 口拆分成四个
switch (config interface ethernet 1/1) # shutdown
switch (config interface ethernet 1/1) # module-type qsfp-split-4
设置链路聚合
switch (config interface ethernet 1/1) # channel-group 1 mode active
switch (config interface ethernet 1/2) # channel-group 1 mode active
模式可以选择：active(LACP)/passive(LACP)/on(Static)
设置 STP 协议
设置远程 syslog 服务器
设置 NTP 服务器
Cisco
设置 NTP 服务器
配置 Trunk
# config terminal
(config)# interface ethernet 1/1
(config-if)# switchport mode trunk
(config-if)# switchport trunk allowed vlan 12-34
配置 Access
在裸机上部署 ESXi 和 vCSA 7
之前在另一篇文章里提到过 vCSA 的安装，这次又在另一台机器上重新做了一遍，特此记录一下。
首先在官网上下载 ESXi+VCSA 7.0 ，应该得到两个文件：
首先安装 ESXi，用 UNetBootin 制作 ESXi 的安装光盘。注意不能用 dd，因为它是 CDFS 格式的，不能直接 boot。启动以后，按照界面要求，一路安装即可。
接着，就可以用网页访问 ESXi 进行配置。比如安装一些 Linux 发行版，然后在 Linux 虚拟机里面 mount 上面的 VCSA 的 iso：
接着，复制并修改 /mnt/vcsa-cli-installer/templates/install/embedded_vCSA_on_ESi.json，按照代码注释进行修改。需要注意几点：
- 密码都可以设为空，然后运行 cli 的时候输入
- ESXi 的密码和 vCSA 的密码是不一样的
- 可以把 ceip 关掉，设置 ceip_enabled: false
接着，进行安装：
慢慢等待它安装成功即可。
安装完成后，进入 vCSA，新建一个 Datacenter，然后选择新建的 Datacenter，选择 Add host，输入 ESXi 的地址和用户密码信息即可。
在 Rpi4 上运行 buildroot
背景
需要给 rpi 配置一个 pxe 的最小环境，在上一篇博文了提到可以用 alpine，但发现有一些不好用的地方，所以试了试 buildroot。
PXE 设置和路由器设置
见“在 Rpi4 上运行 Alpine Linux”文章。
Buildroot 配置
下载 buildroot：
> wget https://buildroot.org/downloads/buildroot-2020.08.tar.gz
> unar buildroot-2020.08.tar.gz
> cd buildroot-2020.08
> make raspberrypi4_64_defconfig
然后运行 make menuconfig ，在 Filesystem images 中打开 initramfs，并设置 cpio 压缩为 gz。然后直接编译：
> make -j4
$ ls -al target/images
bcm2711-rpi-4-b.dtb* boot.vfat Image rootfs.cpio rootfs.cpio.gz rootfs.ext2 rootfs.ext4@ rpi-firmware/ sdcard.img
接着，在一个单独的目录里，把这些文件整理一下
> cd ~/rpi-buildroot
> cp -r ~/buildroot-2020.08/output/images/rpi-firmware/* .
> cp ~/buildroot-2020.08/output/images/bcm2711-rpi-4-b.dtb .
> cp ~/buildroot-2020.08/output/images/Image .
> cp ~/buildroot-2020.08/output/images/rootfs.cpio.gz .
> # edit cmdline.txt: remove root= and rootwait
> # edit config.txt: uncomment initramfs rootfs.cpio.gz line
# ls
bcm2711-rpi-4-b.dtb* cmdline.txt config.txt fixup.dat Image overlays/ rootfs.cpio.gz start.elf
最后开启 TFTP 服务器即可：
树莓派启动
连接树莓派的串口，用 115200 Baudrate 打开，可以看到启动信息：
PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:a5e1b95f DATE: Apr 16 2020 TIME: 18:11:29 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1587057086 0xa049cc2f 0x00c03111
uSD voltage 3.3V
...
Welcome to Buildroot
buildroot login: root
#
默认用户是 root，没有密码。
在 rpi4 上用 PXE 运行 Alpine Linux
背景
需要给 rpi 配置一个 pxe 的最小环境，然后看到 alpine 有 rpi 的支持，所以尝试给 rpi4 配置 alpine。
PXE 设置
第一步是设置 rpi4 的启动模式，打开 BOOT UART 并且打开 网络启动：
> cd /lib/firmware/raspberrypi/bootloader/critical
> rpi-eeprom-config pieeprom-2021-04-29.bin > config.txt
$ cat config.txt
[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0x1
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=5
[none]
FREEZE_VERSION=0
> sed 's/BOOT_UART=0/BOOT_UART=1/;s/BOOT_ORDER=0x1/BOOR_ORDER=0x12/' config.txt > config-pxe.txt
> rpi-eeprom-config --out pieeprom-2021-04-29-pxe.bin --config config-pxe.txt pieeprom-2021-04-29.bin
> rpi-eeprom-update -d -f pieeprom-2021-04-29-pxe.bin
> reboot
重启以后，可以用 vcgencmd bootloader_config 查看当前的启动配置，看是否正确地更新了启动配置。比较重要的是 BOOT_ORDER，0x12 表示先尝试网络启动，再尝试 SD 卡启动。
路由器配置
第二步，需要配置路由器，以 OpenWrt 为例：
> uci add_list dhcp.lan.dhcp_option="66,ip_address_of_tftp_server"
> uci commit dhcp
> /etc/init.d/dnsmasq restart
$ cat /etc/config/dhcp
...
config dhcp 'lan'
...
list dhcp_option '66,ip_address_of_tftp_server'
...
这样就配置完毕了。如果是 isc-dhcp-server，修改 /etc/dhcp/dhcpd.conf：
subnet 10.0.1.0 netmask 255.255.255.0 {
range 10.0.1.100 10.0.1.199;
option routers 10.0.1.1;
option tftp-server-name "10.0.1.1";
}
TFTP 服务器配置
下载 alpine linux 的 rpi boot，解压到指定目录：
> wget http://mirrors.tuna.tsinghua.edu.cn/alpine/v3.12/releases/aarch64/alpine-rpi-3.12.0-aarch64.tar.gz
> unar alpine-rpi-3.12.0-aarch64.tar.gz
> cd alpine-rpi-3.12.0-aarch64
修改 cmdline.txt ，把 console=tty1 改成 console=ttyAMA0,115200，并且去掉 quiet；修改 usercfg.txt 为：
接着，启动 TFTP 服务器：
树莓派启动
连接树莓派的串口，用 115200 Baudrate 打开，可以看到启动信息：
PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:a5e1b95f DATE: Apr 16 2020 TIME: 18:11:29 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1587057086 0xa049cc2f 0x00c03111
uSD voltage 3.3V
...
initramfs emergency recovery shell launched. Type 'exit' to continue boot
sh: can't access tty; job control turned off
/ #
然后，按照需要自定义 initramfs 即可。解压后，修改文件，然后运行：
把自带的 initramfs 替换掉。
用 certbot 申请 route53 上的域名的 LetsEncrypt 证书并上传到 IAM
最近遇到了 AWS Certificate Manager 的一些限制，所以只能用 IAM 证书。于是上网找到了通过 certbot 申请 LE 证书，通过 route53 API 验证的方法。
首先配置 aws 的 credential。然后，按照 certbot：
然后，就可以申请证书了：
certbot certonly --dns-route53 --config-dir "./letsencrypt" --work-dir "./letsencrypt" --logs-dir "./letsencrypt" -d example.com --email a@b.com --agree-tos
如果申请成功，在当前目录下可以找到证书。然后上传到 IAM：
aws iam upload-server-certificate --server-certificate-name NameHere \
--certificate-body file://letsencrypt/live/example.com/cert.pem \
--private-key file://letsencrypt/live/example.com/privkey.pem \
--certificate-chain file://letsencrypt/live/example.com/chain.pem \
--path /cloudfront/
如果要用于 cloudfront，才需要最后的路径参数；否则可以去掉。这样就完成了 IAM 证书的上传。
在 k8s 中部署 Prometheus
实验了一下在 k8s 中部署 Prometheus，因为它和 k8s 有比较好的集成，很多 App 能在 k8s 里通过 service discovery 被 Prometheus 找到并且抓取数据。实践了一下，其实很简单。
用 helm 进行配置：
这样就可以了，如果已经有 StorageClass（比如腾讯云的话，CBS 和 CFS），它就能自己起来了，然后在 Lens 里面也可以看到各种 metrics 的可视化。
如果是自建的单结点的 k8s 集群，那么还需要自己创造 PV，并且把 PVC 绑定上去。我采用的是 local 类型的 PV：
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-volume-1
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/srv/k8s-data-1"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-volume-2
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/srv/k8s-data-2"
这样，结点上的两个路径分别对应两个 PV，然后只要让 PVC 也用 manual 的 StorageClass 就可以了：
把这个文件保存为 values.yaml 然后：
这样就可以了。不过 PVC 不能在线改，可能需要删掉重来。
然后，由于权限问题，还需要在结点上修改一下两个目录的权限：
这样容器内就可以正常访问了。
在 k8s 中部署 code-server
实验了一下在 k8s 中部署 code-server，并不复杂，和之前几篇博客的配置是类似的：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: code
labels:
app: code
spec:
selector:
matchLabels:
app: code
replicas: 1
template:
metadata:
labels:
app: code
spec:
volumes:
- name: code-volume
persistentVolumeClaim:
claimName: code-pvc
initContainers:
- name: home-init
image: busybox
command: ["sh", "-c", "chown -R 1000:1000 /home/coder"]
volumeMounts:
- mountPath: "/home/coder"
name: code-volume
containers:
- image: codercom/code-server:latest
imagePullPolicy: Always
name: code
volumeMounts:
- mountPath: "/home/coder"
name: code-volume
resources:
limits:
cpu: "0.5"
memory: "500Mi"
ports:
- containerPort: 8080
env:
- name: PASSWORD
value: REDACTED
---
apiVersion: v1
kind: Service
metadata:
name: code
labels:
app: code
spec:
ports:
- port: 8080
selector:
app: code
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-code
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
nginx.org/websocket-services: "code"
spec:
tls:
- hosts:
- example.com
secretName: code-tls
rules:
- host: example.com
http:
paths:
- path: /
backend:
serviceName: code
servicePort: 8080
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: code-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 1Gi
需要注意的几个点：
- 用了一个 pvc 用于 /home/coder 的持久化，所以你的集群里得有相应的 pv/storage class
- 我用的是 Nginx Inc. 的 ingress controller，它的 websocket 支持需要一句 nginx.org/websocket-services 设置
- 额外添加了一个 init container，为了处理 home 目录的权限
在 k8s 中部署 Drone 用于 CI
实验了一下在 k8s 中部署 CI，在 drone gitlab-ci 和 jenkins 三者中选择了 drone，因为它比较轻量，并且基于 docker，可以用 GitHub 上的仓库，比较方便。
首先，配置 helm：
参考 drone 的文档，编写 drone-values.yml:
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
hosts:
- host: drone.example.com
paths:
- "/"
tls:
- hosts:
- drone.example.com
secretName: drone-tls
env:
DRONE_SERVER_HOST: drone.example.com
DRONE_SERVER_PROTO: https
DRONE_USER_CREATE: username:YOUR_GITHUB_USERNAME,admin:true
DRONE_USER_FILTER: YOUR_GITHUB_USERNAME
DRONE_RPC_SECRET: REDACTED
DRONE_GITHUB_CLIENT_ID: REDACTED
DRONE_GITHUB_CLIENT_SECRET: REDACTED
需要首先去 GitHub 上配置 OAuth application，具体参考 drone 的文档。然后，生成一个 secret，设置 admin 用户并只允许 admin 用户使用 drone，防止其他人使用。然后应用：
helm install --namespace drone drone drone/drone -f drone-values.yml
# or, to upgrade
helm upgrade --namespace drone drone drone/drone --values drone-values.yml
然后就可以访问上面配好的域名了。遇到了 cert manager 最近的一个 bug，来回折腾几次就好了。
接着配 drone 的 k8s runnner，也是参考 drone 的文档，编写 drone-runner-kube-values.yml：
然后应用：
helm install --namespace drone drone-runner-kube drone/drone-runner-kube -f drone-runner-kube-values.yml
然后就可以去 drone 界面上操作了。
需要注意的是，drone 需要 pv，所以我先在腾讯云里面配置了 CFS 的 storage class，然后它就会自动 provision 一个新的 pv 和 pvc 出来。
接着尝试了一下在 drone 里面构建 docker 镜像并且 push 到 registry 上。以腾讯云为例：
kind: pipeline
type: kubernetes
name: default
steps:
- name: build
image: alpine
commands:
- make
- name: publish
image: plugins/docker
settings:
registry: ccr.ccs.tencentyun.com
repo: ccr.ccs.tencentyun.com/abc/def
tags: ["${DRONE_COMMIT_SHA:0:7}","latest"]
username:
from_secret: docker_username
password:
from_secret: docker_password
然后在网页里配置好 docker username 和 password，它就会自动构建 docker 镜像并且 push 到 registry 上，然后再 rollout 一下 deployment 就能部署最新的 image 了。实际上可以在 drone 里面把部署这一步也完成，但目前还没有去实践。
参考文档：
在 k8s 内用 Cert Manager 配合 Nginx Ingress Controller 配置 Let's Encrypt HTTPS 证书
上一篇博客讲了 nginx ingress 的配置，那自然第一步要配上 https。首先配置 cert-manager：
$ kubectl create namespace cert-manager
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v0.14.1
然后，配置 Cluster Issuer，应用以下的 yaml：
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
namespace: cert-manager
spec:
acme:
email: example@example.com
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
然后在 ingress 里面进行配置：
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-example
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /
backend:
serviceName: example-service
servicePort: 80
应用以后，用 kubectl describe certificate 查看证书获取进度。成功后，访问改域名的 HTTP，就会自动跳转到 HTTPS，并且提供了正确的证书。
在 TKE 上配置不使用 LB 的 Nginx Ingress Controller
背景
想要在 k8s 里面 host 一个网站，但又不想额外花钱用 LB，想直接用节点的 IP。
方法
首先安装 nginx-ingress：
$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo update
$ helm install ingress-controller nginx-stable/nginx-ingress --set controller.service.type=NodePort --set controller.hostNetwork=true
这里给 ingress controller chart 传了两个参数：第一个指定 service 类型是 NodePort，替代默认的 LoadBalancer；第二个指定 ingress controller 直接在节点上监听，这样就可以用节点的公网 IP 访问了。
然后配一个 ingress：
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-example
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: example.com
http:
paths:
- path: /
backend:
serviceName: example-service
servicePort: 80
然后就可以发现请求被正确路由到 example-service 的 80 端口了。
体验 Tencent Kubernetes Engine
之前在机器上试验了一下 kubernetes，感觉挺不错的，所以就想把腾讯云上面的机器也交给 kubernetes 管理。找到容器服务，新建集群，选择模板里的标准托管集群就可以了。然后开启下面的公网访问，设置一个比较小的 IP 地址段，按照页面下面的要求合并一下 kube config（因为还有别的 k8s cluster）：
$ KUBECONFIG=~/.kube/config:/path/to/new/config kubectl config view --merge --flatten > new_config
$ cp new_config ~/.kube/config
覆盖之前先确认原来的配置还在，然后就可以用 kubectl 切换到新的 context：
$ kubectl config get-contexts
$ kubectl config use-context new-context-here
$ kubectl get node
NAME STATUS ROLES AGE VERSION
172.21.0.17 Ready <none> 75m v1.16.3-tke.3
可以看到我们的 k8s node 已经上线了。我一般习惯先配好 kubernetes-dashboard：
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
$ kubectl proxy &
$ kubectl -n kubernetes-dashboard describe secret (kubectl -n kubernetes-dashboard get secret | grep admin-user | awk '{print \$1}') | tail -n1 | awk '{print \$2}' | pbcopy
然后在浏览器里访问 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/overview?namespace=default 然后把剪贴板里的 token 粘贴进去即可。
默认情况下 kubernetes-dashboard 的权限比较少，可以让它获得更多权限：
$ kubectl edit clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard
# use '*' for ultimate
# use `kubectl get clusterrole.rbac.authorization.k8s.io/cluster-admin -o yaml` to see full permissions
接下来配置 metrics-server。下载 metrics-server 仓库，然后修改镜像地址：
$ wget https://github.com/kubernetes-sigs/metrics-server/archive/v0.3.6.zip
$ unar v0.3.6.zip
$ cd metrics-server-0.3.6/deploy/1.8+
$ vim metrics-server-deployment
# change: k8s.gcr.io/metrics-server-amd64:v0.3.6
# to: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
# add line below image: args: ["--kubelet-insecure-tls"]
$ kubectl apply -f .
等一段时间，就可以看到 metrics server 正常运行了。
参考：https://tencentcloudcontainerteam.github.io/tke-handbook/
在 Kubernetes 集群上部署 gitlab—runner
按照 GitLab 上的教程试着把 gitlab-runner 部署到 k8s 集群上，发现异常地简单，所以简单做个笔记：
编辑 values.yaml
此处的信息按照 "Set up a specific Runner manually" 下面的提示填写。然后用 Helm 进行安装：
$ helm repo add gitlab https://charts.gitlab.io
$ kubectl create namespace gitlab-runner
$ helm install --namespace gitlab-runner gitlab-runner -f values.yaml gitlab/gitlab-runner
然后去 Kubernetes Dashboard 就可以看到部署的情况，回到 GitLab 也可以看到出现了“Runners activated for this project” ，表示配置成功。
参考配置：https://docs.gitlab.com/runner/install/kubernetes.html