跳转至

devops

记录一次 CentOS AArch64 7 到 8 的升级

背景

有一台 AArch64 机器安装了 CentOS 7,想要升级到 CentOS 8,这篇博客主要讲讲折腾的整个过程,而不是教程:如果真要说,就是不要升级 CentOS 大版本,直接重装吧。如果真的想折腾,可以看看下面的内容。

ESXi 配置 LACP 链路聚合

背景

给 ESXi 接了两路 10Gbps 的以太网,需要用 LACP 来聚合。ESXi 自己不能配置 LACP,需要配合 vCenter Server 的 Distributed Switch 来配置。

Ceph Cookbook

概念

  • OSD:负责操作硬盘的程序,一个硬盘一个 OSD
  • MON:管理集群状态,比较重要,可以在多个节点上各跑一个
  • MGR:监测集群状态
  • RGW(optional):提供对象存储 API
  • MDS(optional):提供 CephFS

使用 Ceph 做存储的方式:

  1. librados: 库
  2. radosgw: 对象存储 HTTP API
  3. rbd: 块存储
  4. cephfs: 文件系统

认证

Ceph 客户端认证需要用户名 + 密钥。默认情况下,用户名是 client.admin,密钥路径是 /etc/ceph/ceph.用户名.keyringceph --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 可以认为是预定义的一些权限集合。

新建用户并赋予权限:

ceph auth get-or-create client.abc mon 'allow r'

修改权限:

ceph auth caps client.abc mon 'allow rw'

获取权限:

ceph auth get client.abc

删除用户:

ceph auth print-key client.abc

OSD

管理 OSD 实际上就是管理存储数据的硬盘。

查看状态:

ceph osd stat

显示有多少个在线和离线的 OSD。

ceph osd tree

显示了存储的层级,其中 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:

ceph osd crush rule ls
ceph osd crush rule dump

查看 CRUSH 层级:

ceph osd crush tree --show-shadow

在里面可能会看到 default~ssd,它指的意思就是只保留 default 下面的 ssd 设备。

文本形式导出 CRUSH 配置:

ceph osd getcrushmap | crushtool -d - -o crushmap
cat crushmap

可以看到 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 osdchooseleaf 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 功能都需要指定存储池来工作。

创建存储池:

ceph osd pool create xxx
ceph osd pool create PG_NUM

为了性能考虑,可以设置 PG(Placement Group)数量。默认情况下,会创建 replicated 类型的存储池,也就是会存多份,类似 RAID1。也可以设置成 erasure 类型的存储池,类似 RAID5。

每个 Placement Group 里的数据会保存在同一组 OSD 中。数据通过 hash,会分布在不同的 PG 里。

列举所有的存储池:

ceph osd lspools

查看存储池的使用量:

rados df

存储池的 IO 状态:

ceph osd pool stats

对存储池做快照:

ceph osd mksnap xxx snap-xxx-123

PG

PG 是数据存放的组,每个对象都会放到一个 PG 里面,而 PG 会决定它保存到哪些 OSD 上(具体哪些 OSD 是由 CRUSH 决定的)。PG 数量只有一个的话,那么一个 pool 的所有数据都会存放在某几个 OSD 中,一旦这几个 OSD 都不工作了,那么整个 pool 的数据都不能访问了。PG 增多了以后,就会分布到不同的 OSD 上,并且各个 OSD 的占用也会比较均匀。

查看 PG 状态:

ceph pg dump
Auto Scale

PG 数量可以让集群自动调整:

ceph osd pool set xxx pg_autoscale_mode on

设置 autoscale 目标为每个 OSD 平均 100 个 PG:

ceph config set global mon_target_pg_per_osd 100

全局 autoscale 开关:

# Enable
ceph osd pool unset noautoscale
# Disable
ceph osd pool set unautoscale
# Read
ceph osd pool get noautoscale

查看 autoscale 状态:

ceph osd pool autoscale-status

如果没有显示,说明 autoscale 没有工作,可能的原因是,部分 pool 采用了指定 osd class 的 crush rule,例如指定了 hdd 盘,但是也有部分 pool 没有指定盘的类型,例如默认的 replicated_rule。这时候,把这些盘也设置成一个指定 osd class 的 crush rule 即可。

RBD

RBD 把 Ceph 暴露为块设备。

创建

初始化 Pool 用于 RBD:

rbd pool init xxx

为了安全性考虑,一般会为 RBD 用户创建单独的用户:

ceph auth get-or-create client.abc mon 'profile rbd' osd 'profile rbd pool=xxx' mgr 'profile rbd pool=xxx'

创建 RBD 镜像:

rbd create --size 1024 xxx/yyy

表示在 Pool xxx 上面创建了一个名字为 yyy 大小为 1024MB 的镜像。

状态

列举 Pool 里的镜像:

rbd ls
rbd ls xxx

默认的 Pool 名字是 rbd

查看镜像信息:

rbd info yyy
rbd info xxx/yyy

扩容

修改镜像的容量:

rbd resize --size 2048 yyy
rbd resize --size 512 yyy --allow-shrink

挂载

在其他机器挂载 RBD 的时候,首先要修改 /etc/ceph 下配置,确认有用户,密钥和 MON 的地址。

然后,用 rbd 挂载设备:

rbd device map xxx/yyy --id abc

以用户 abc 的身份挂载 Pool xxx 下面的 yyy 镜像。

这时候就可以在 /dev/rbd* 或者 /dev/rbd/ 下面看到设备文件了。

显示已经挂载的设备:

rbd device list

CephFS

创建

如果配置了编排器(Orchestrator),可以直接用命令:

ceph fs volume create xxx
创建一个名为 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 状态:

ceph mds stat

客户端配置

在挂载 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。

接着,我们在集群上给客户端创建一个用户:

ceph fs authorize xxx client.abc / rw

创建一个用户 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 服务:

ceph nfs cluster create xxx
ceph nfs cluster create xxx "host1,host2"

在主机上运行 NFS 服务器,NFS 集群的名字叫做 xxx。

查看 NFS 集群信息:

ceph nfs cluster info xxx

列举所有 NFS 集群:

ceph nfs cluster ls

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:

mount -t nfs x.x.x.x:/a/b/c /mnt

RadosGW

RGW 提供了 S3 或者 OpenStack Swift 兼容的对象存储 API。

TODO

编排器

由于 Ceph 需要运行多个 daemon,并且都在不同的容器中运行,所以一般会跑一个系统级的编排器,用于新增和管理这些容器。

查看当前编排器:

$ ceph orch status
Backend: cephadm
Available: Yes
Paused: No

比较常见的就是 cephadm,安装的时候如果用了 cephadm,那么编排器也是它。

被编排的服务:

ceph orch ls

被编排的容器:

ceph orch ps

被编排的主机:

ceph orch host ls

添加新机器

首先,复制 /etc/ceph/ceph.pub 到新机器的 /root/.ssh/authorized_keys

接着,添加机器到编排器中:

ceph orch host add xxxx y.y.y.y

导出编排器配置:

ceph orch ls --export > cephadm.yaml

如果想让一些 daemon 只运行在部分主机上,可以修改:

# change
placement:
  host_pattern: '*'
# to
placement:
  host_pattern: 'xxx'

然后应用:

ceph orch apply -i cephadm.yaml

配置监控

添加监控相关的服务:

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 拉取。

查看升级状态:

ceph orch upgrade status
ceph -s

查看 cephadm 日志:

ceph -W 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 常用信息

常用链接

vsish -e cat /hardware/cpu/cpuList/0 | grep -i -E 'family|model|stepping|microcode|revision'
$ esxcli software vib install -d $PWD/Net-Community-Driver_1.2.0.0-1vmw.700.1.0.15843807_18028830.zip

离线升级方法

  1. 下载 Offline Bundle 文件
  2. 上传到 ESXi datastore 中
  3. /vmfs/volumes/ 里找到更新文件
  4. 查询 profile 列表 esxcli software sources profile list -d <zip>
  5. 更新到 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 然后按照离线升级方法安装。

防火墙

列出所有防火墙规则:

$ esxcli network firewall ruleset list

允许出站 SSH:

$ esxcli network firewall ruleset set --enabled=true --ruleset-id=sshClient

关闭出站 SSH:

$ esxcli network firewall ruleset set --enabled=false --ruleset-id=sshClient

NUC11i5 ESXi 7.0 安装过程

  1. 下载 ESXi ISO 文件,用 UNetbootin 制作安装盘
  2. 插入 U 盘,在 NUC 上安装 ESXi,在 81% 的时候卡住了,不管直接重启
  3. 用 root 无密码登录进去,然后重置网络设置
  4. 配置 usb 网卡,然后通过网页访问 ESXi,打开 SSH
  5. 下载 Fling 上面的社区网卡支持,用 esxcli 安装
  6. 重启以后,就可以看到 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 Chartsvmon-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

vmkfstool -i "old.vmdk" -d thin "new.vmdk"

需要注意的是,这里的路径用的是不带 -flat 的 vmdk,因为这个文件记录了 metadata,而 -flat.vmdk 保存了实际的数据。可以用 du 命令看实际的硬盘占用,从而确认它确实是 Thin Provisioned。

如果已经在 Web UI 上复制了,你会发现无法停止复制,解决办法是:

/etc/init.d/hostd restart

这样就会重启 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:

$ bridge fdb show brport flannel.1
...

这个 fdb 中包括了 (MAC 地址,IP 地址) 的 tuple。当 flannel.1 收到一个 Ethernet Frame 的时候,如果目的地址匹配这里的 MAC 地址,就会直接把 Eth Frame 封装到 UDP 里面发给目的 IP 地址;否则,就会在这个表里面 broadcast。这样,第二个节点就会收到 packet 并且转给实际的 pod。

总结

总结一下 k8s 的网络互联的实现方法:节点内通过 bridge 实现,把链接各个 netns 的 veth 桥接起来;节点间划分为多个子网,子网间通过 flannel 的网关进行路由,flannel 网关间通过 vxlan 进行互联。

参考文档

技术干货 | 深入理解 flannel

一文看懂 k8s 的 Flannel 网络

将 k8s rook ceph 集群迁移到 cephadm

背景

前段时间用 rook 搭建了一个 k8s 内部的 ceph 集群,但是使用过程中遇到了一些稳定性问题,所以想要用 cephadm 重建一个 ceph 集群。

重建过程

重建的时候,我首先用 cephadm 搭建了一个 ceph 集群,再把原来的 MON 数据导入,再恢复各个 OSD。理论上,可能有更优雅的办法,但我还是慢慢通过比较复杂的办法解决了。

cephadm 搭建 ceph 集群

首先,配置 TUNA 源,在各个节点上安装 docker-cecephadm。接着,在主节点上 bootstrap:

cephadm bootstrap --mon-ip HOST1_IP

此时,在主节点上会运行最基础的 ceph 集群,不过此时还没有任何数据。寻找 ceph 分区,会发现因为 FSID 不匹配而无法导入。所以,首先要恢复 MON 数据。

参考文档:cephadm install

恢复 MON 数据

首先,关掉 rook ceph 集群,找到留存下来的 MON 数据目录,默认路径是 /var/lib/rook 下的 mon-[a-z] 目录,找到最新的一个即可。我把目录下的路径覆盖到 cephadm 生成的 MON 目录下,然后跑起来,发现有几个问题:

  1. cephadm 生成的 /etc/ceph/ceph.client.admin.keyring 与 MON 中保存的 auth 信息不匹配,导致无法访问
  2. 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 里面:

$ cephadm shell --mount /var/lib/ceph:/var/lib/ceph

接着,生成 osd 目录配置:

$ ceph-volume lvm activate --all --no-systemd

然后,可以看到创建了对应的 osd 路径,再用 cephadm 进行转换:

$ cephadm adopt --style legacy --name osd.ID

这样就可以用 cephadm 管理了。

配置 k8s

配置好外部 ceph 集群后,还需要配置 k8s rook。

参考 https://rook.github.io/docs/rook/v1.8/ceph-cluster-crd.html#external-cluster,大概有这么几步:

  1. 在 ceph 集群上运行 create-external-cluster-resources.sh,创建用户,并且导出 key
  2. 在 k8s 集群上应用第一步生成的环境变量,然后运行 import-external-cluster.sh
  3. 复制一份 cluster-external.yaml 然后应用
  4. 复制 storageclass.yaml,把里面的 namespace 改成 rook-ceph-external

在 ESXi 中用 PERCCli 换 RAID 中的盘

背景

最近有一台机器的盘出现了报警,需要换掉,然后重建 RAID5 阵列。iDRAC 出现报错:

  1. Disk 2 in Backplane 1 of Integrated RAID Controller 1 is not functioning correctly.
  2. Virtual Disk 1 on Integrated RAID Controller 1 has become degraded.
  3. Error occurred on Disk2 in Backplane 1 of Integrated RAID Controller 1 : (Error 2)

安装 PERCCli

首先,因为系统是 VMware ESXi 6.7,所以在DELL 官网下载对应的文件。按照里面的 README 安装 vib:

esxcli software vib install -v /vmware-perccli-007.1420.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:

MegaCLI:

PercCLI:

用 fluentd 收集 k8s 中容器的日志

背景

在维护一个 k8s 集群的时候,一个很常见的需求就是把日志持久化存下来,一方面是方便日后回溯,一方面也是聚合 replicate 出来的同一个服务的日志。

在我目前的需求下,只需要把日志持久下来,还不需要做额外的分析。所以我并没有部署类似 ElasticSearch 的服务来对日志进行索引。

实现

实现主要参考官方的仓库:https://github.com/fluent/fluentd-kubernetes-daemonset。它把一些常用的插件打包到 docker 镜像中,然后提供了一些默认的设置,比如获取 k8s 日志和 pod 日志等等。为了达到我的需求,我希望:

  1. 每个结点上有一个 fluentd 收集日志,forward 到单独的 log server 上的 fluentd
  2. log server 上的 fluentd 把收到的日志保存到文件

由于 log server 不由 k8s 管理,所以按照官网的方式手动安装:

curl -fsSL https://toolbelt.treasuredata.com/sh/install-debian-bookworm-fluent-package5.sh | sh

然后,编辑配置 /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>

和原版有几点细节上的不同:

  1. k8s 启用了 rbac,所以需要对应的配置;照着仓库里其他带 rbac 配置的文件抄一下即可。
  2. 禁用了 SYSTEMD 日志的抓取,因为我用的是 k3s,而不是 kubeadm,自然找不到 kubelet 的 systemd service。
  3. 覆盖了 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,一般的做法是:

kubectl -n NAMESPACE rollout restart deployment/NAME

我们希望 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 介绍

Ceph 有这些组成部分:

  1. mon:monitor
  2. mgr:manager
  3. osd:storage
  4. mds(optional):用于 CephFS
  5. 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 状态

$ kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

也可以进 direct-mount 容器查看 pv 路径

# 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。

  1. 在第一个 node 上跑:curl -sfL https://get.k3s.io | sh -
  2. 在第一个 node 上获取 token:cat /var/lib/rancher/k3s/server/node-token
  3. 在其他 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.

进入配置模式

<HUAWEI> system-view

查看当前配置

[HUAWEI] display current-configuration

查看 LLDP 邻居

[HUAWEI]display lldp neighbor brief

查看 CDP 邻居

[HUAWEI]display cdp neighbor brief

启用 LLDP

[HUAWEI]lldp enable

启用 CDP

[HUAWEI-XGigabitEthernet0/0/1]lldp compliance cdp txrx

启用只读 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 表

[HUAWEI]display arp

ARPING

[HUAWEI]arp send-packet X.X.X.X ffff-ffff-ffff interface Vlanif VLAN

启用 STP 协议

[HUAWEI]stp enable
[HUAWEI]stp mode vbst

设置 NTP 服务器

[HUAWEI]ntp-service unicast-server x.x.x.x

设置远程 syslog 服务器

[HUAWEI]info-center loghost x.x.x.x

设置 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!

进入配置模式

console>enable
console# configure

查看当前配置

console# show running-config

查看 LLDP 邻居

console#show lldp remote-device all

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 配置

console#show vlan

批量配置 interface

console(config)#interface range Gi1/0/1-4

启用 SSH 服务器

console(config)#crypto key generate rsa
console(config)#crypto key generate dsa
console(config)#ip ssh server

启用 CDP(DELL 称之为 ISDP)

console(config)#isdp enable

启用只读 SNMPv1 community

console(config)#snmp-server community [COMMUNITY NAME] ro

设置 NTP 服务器

console(config)#sntp unicast client enable
console(config)#sntp server x.x.x.x

设置 NTP 服务器

console(config)#sntp unicast client enable
console(config)#sntp server x.x.x.x

设置 STP 协议

console(config)#spanning-tree mode rapid-pvst

H3C

进入配置模式

<switch>system-view
System View: return to User View with Ctrl+Z.
[switch]

查看当前配置

[switch]display current-configuration

查看 lldp 邻居

[switch]display lldp neighbor-information

保存配置

[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

[switch]interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/24
[switch-if-range]

查看 MAC 地址表

[switch]show mac-address

打开 LLDP 和 CDP

[switch]lldp global enable
[switch]lldp compliance cdp

Mellanox

进入配置模式

switch > enable
switch # configure terminal
switch (config) #

查看当前配置

switch (config) # show running-config

查看 interface 状态

switch (config) # show interfaces brief

查看以太网端口状态

switch (config) # show interfaces ethernet status

查看 lldp 邻居

switch (config) # show lldp remote

保存配置

switch (config) # configuration write

批量配置 interface

switch (config) # interface ethernet 1/1/1-1/1/4
switch (config interface ethernet 1/1/1-1/1/4) #

查看 MAC 地址表

switch (config) # show mac-address-table

查看链路聚合状态

switch (config) # show interfaces port-channel summary

把拆分的四个 SFP 口恢复成一个

switch (config interface ethernet 1/1/1) # module-type qsfp 

把一个 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 协议

switch (config) # spanning-tree mode rpvst

设置远程 syslog 服务器

switch (config) # logging x.x.x.x

设置 NTP 服务器

switch (config) # ntp server x.x.x.x

Cisco

设置 NTP 服务器

# ntp server x.x.x.x

配置 Trunk

# config terminal
(config)# interface ethernet 1/1
(config-if)# switchport mode trunk
(config-if)# switchport trunk allowed vlan 12-34

配置 Access

# config terminal
(config)# interface ethernet 1/1
(config-if)# switchport mode access
(config-if)# switchport access vlan 1234

在裸机上部署 ESXi 和 vCSA 7

之前在另一篇文章里提到过 vCSA 的安装,这次又在另一台机器上重新做了一遍,特此记录一下。

首先在官网上下载 ESXi+VCSA 7.0 ,应该得到两个文件:

7.9G VMware-VCSA-all-7.0.1-16860138.iso
358M VMware-VMvisor-Installer-7.0U1-16850804.x86_64.iso

首先安装 ESXi,用 UNetBootin 制作 ESXi 的安装光盘。注意不能用 dd,因为它是 CDFS 格式的,不能直接 boot。启动以后,按照界面要求,一路安装即可。

接着,就可以用网页访问 ESXi 进行配置。比如安装一些 Linux 发行版,然后在 Linux 虚拟机里面 mount 上面的 VCSA 的 iso:

sudo mount /dev/sr0 /mnt

接着,复制并修改 /mnt/vcsa-cli-installer/templates/install/embedded_vCSA_on_ESi.json,按照代码注释进行修改。需要注意几点:

  1. 密码都可以设为空,然后运行 cli 的时候输入
  2. ESXi 的密码和 vCSA 的密码是不一样的
  3. 可以把 ceip 关掉,设置 ceip_enabled: false

接着,进行安装:

/mnt/vcsa-cli-installer/lin64/vcsa-deploy install --accept-eula /path/to/customized.json -v

慢慢等待它安装成功即可。

安装完成后,进入 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 服务器即可:

> sudo python3 -m py3tftp -p 69

树莓派启动

连接树莓派的串口,用 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 为:

dtoverlay=disable-bt
enable_uart=1

接着,启动 TFTP 服务器:

> sudo python3 -m py3tftp -p 69

树莓派启动

连接树莓派的串口,用 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 即可。解压后,修改文件,然后运行:

> find . -print0 | cpio --null -ov --format=newc | gzip > ../initramfs-rpi4

把自带的 initramfs 替换掉。

用 certbot 申请 route53 上的域名的 LetsEncrypt 证书并上传到 IAM

最近遇到了 AWS Certificate Manager 的一些限制,所以只能用 IAM 证书。于是上网找到了通过 certbot 申请 LE 证书,通过 route53 API 验证的方法。

首先配置 aws 的 credential。然后,按照 certbot:

pip3 install -U certbot certbot_dns_route53

然后,就可以申请证书了:

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 进行配置:

helm upgrade --install prometheus stable/prometheus

这样就可以了,如果已经有 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 就可以了:

server:
    persistentVolume:
        storageClass: manual

alertmanager:
    persistentVolume:
        storageClass: manual

把这个文件保存为 values.yaml 然后:

helm upgrade --install prometheus stable/prometheus -f values.yaml

这样就可以了。不过 PVC 不能在线改,可能需要删掉重来。

然后,由于权限问题,还需要在结点上修改一下两个目录的权限:

sudo chown -R 65534:65534 /srv/k8s-data-1
sudo chown -R 65534:65534 /srv/k8s-data-2

这样容器内就可以正常访问了。

在 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

需要注意的几个点:

  1. 用了一个 pvc 用于 /home/coder 的持久化,所以你的集群里得有相应的 pv/storage class
  2. 我用的是 Nginx Inc. 的 ingress controller,它的 websocket 支持需要一句 nginx.org/websocket-services 设置
  3. 额外添加了一个 init container,为了处理 home 目录的权限

在 k8s 中部署 Drone 用于 CI

实验了一下在 k8s 中部署 CI,在 drone gitlab-ci 和 jenkins 三者中选择了 drone,因为它比较轻量,并且基于 docker,可以用 GitHub 上的仓库,比较方便。

首先,配置 helm:

helm repo add drone https://charts.drone.io
kubectl create ns drone

参考 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:

rbac:
  buildNamespaces:
    - drone
env:
  DRONE_RPC_SECRET: REDACTED
  DRONE_NAMESPACE_DEFAULT: drone

然后应用:

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 里面把部署这一步也完成,但目前还没有去实践。

参考文档:

Drone provider: GitHub

Drone helm chart

Drone runner kube helm chat

Building a CD pipeline with drone CI and kubernetes

在 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

gitlabUrl: GITLAB_URL
runnerRegistrationToken: "REDACTED"
rbac:
    create: true

此处的信息按照 "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