分类目录归档:技术笔记

开源项目管理软件对比总结

以下是 Kanboard、Wekan、Taiga、OpenProject 和 Redmine 这五个软件的对比表格:

功能/属性 Kanboard Wekan Taiga OpenProject Redmine
软件类型 项目管理 项目管理 项目管理及敏捷开发 项目管理及协作 项目管理
开源
界面语言 多语言支持 多语言支持 多语言支持 多语言支持 多语言支持
主要功能 看板、任务管理、时间跟踪 看板、任务管理 敏捷管理、Scrum、Kanban 甘特图、时间跟踪、资源管理 问题跟踪、甘特图、日历
安装方式 自托管、Docker 自托管、Docker 自托管、云托管、Docker 自托管、云托管、Docker 自托管、云托管、Docker
集成功能 少量插件、API API、与其他系统集成 GitHub、GitLab、Slack 等 多种插件、API 丰富的插件与API支持
适用团队规模 小型到中型 小型到中型 中型到大型,可扩展 小型到大型 小型到大型
界面友好性 简单直观 简单直观 现代但稍复杂 功能丰富但可能更复杂 简单直观,但界面略显陈旧
社区活跃度 中等
移动应用支持 第三方应用或网页 无官方移动应用 无官方移动应用
特别支持功能 强调简单性和看板视图 实时协作和活动流 支持敏捷项目管理流程 适合多种项目管理方法 自定义字段、复杂权限管理

Redmine 是一个久经考验的项目管理和问题跟踪工具,以其强大的可扩展性和插件系统而著称。它适合那些需要高度定制化和强大问题跟踪功能的团队。

Linux 使用 rinetd 实现端口转发重定向

工具介绍

linux 下简单好用的工具 rinetd,实现端口映射 / 转发 / 重定向。

用于有效地将连接从一个 IP 地址 / 端口组合重定向到另一 IP 地址 / 端口组合。在操作虚拟服务器、防火墙等时很有用。

Rinetd 是单一过程的服务器,它处理任何数量的连接到在配置文件 etc/rinetd 中指定的地址 / 端口对。尽管 rinetd 使用非闭锁 I/O 运行作为一个单一过程,它可能重定向很多连接而不对这台机器增加额外的负担。

官网地址:http://www.boutell.com/rinetd

软件安装

方法一:压缩包

wget http://www.boutell.com/rinetd/http/rinetd.tar.gz
tar zxvf rinetd.tar.gz
make
make install

方法二:apt-get

apt-cache search rinetd
apt-get install rinetd -y

软件配置

配置文件格式:

[Source Address] [Source Port] [Destination Address] [Destination Port]
源地址 源端口 目的地址 目的端口

在每一单独的行中指定每个要转发的端口。源地址和目的地址都可以是主机名或 IP 地址,IP 地址 0.0.0.0 将 rinetd 绑定到任何可用的本地 IP 地址上。

例如:

vi /etc/rinetd.conf
0.0.0.0 8080 172.19.94.3 8080
0.0.0.0 2222 192.168.0.103 3389
1.2.3.4 80     192.168.0.10 80

说明一下(0.0.0.0 表示本机绑定所有可用地址)

  • 将所有发往本机 8080 端口的请求转发到 172.19.94.3 的 8080 端口
  • 将所有发往本机 2222 端口的请求转发到 192.168.0.103 的 3389 端口
  • 将所有发往 1.2.3.4 的 80 端口请求转发到 192.168.0.10 的 80 端口

使用 systemd 管理:

systemctl status rinetd

注意事项

  1. rinetd.conf 中绑定的本机端口必须没有被其它程序占用。
  2. 运行 rinetd 的系统防火墙应该打开绑定的本机端口。

例如:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1111 -jACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2222 -jACCEPT

References

mysql bin 日志过大处理方法

我来帮您解决 MySQL binlog 文件占用空间过大的问题。以下是几个处理方案:

  1. 清理旧的 binlog 文件
    
    -- 查看当前的 binlog 文件列表
    SHOW BINARY LOGS;

— 手动删除指定日期之前的 binlog PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

— 或者删除指定文件之前的所有日志 PURGE BINARY LOGS TO ‘mysql-bin.000123’;


2. **设置 binlog 自动清理策略**
```sql
-- 设置 binlog 保留天数(比如保留7天)
SET GLOBAL expire_logs_days = 7;

-- MySQL 8.0之后使用以下命令
SET GLOBAL binlog_expire_logs_seconds = 604800; -- 7天 = 7*24*60*60秒
  1. 修改配置文件优化my.cnfmy.ini 中添加:
    
    # 设置 binlog 过期时间(天)
    expire_logs_days = 7

MySQL 8.0+ 使用

binlog_expire_logs_seconds = 604800

设置单个 binlog 文件的最大值(默认1G)

max_binlog_size = 100M



建议采取的步骤:

1. 首先备份重要数据
2. 检查是否真的需要 binlog(如果不需要复制功能,可以考虑关闭)
3. 设置合理的过期时间
4. 定期监控 binlog 空间使用情况

注意事项:
- 清理前确保相关的从库已经同步完成
- 不要删除正在使用的 binlog 文件
- 建议在业务低峰期进行清理
- 可以考虑将 binlog 存放在独立的大容量磁盘上

如果您只是临时需要清理空间,使用 `PURGE BINARY LOGS` 是最快的方法。但从长远来看,建议同时设置自动过期策略,避免再次出现空间占用过大的情况。

# References
* [Mysql binlog日志太多,占用大量磁盘空间该如何正确处理](https://www.cnblogs.com/yanling-coder/p/12733096.html)

#MySQL

Kubernetes 使用 Kubectl 重启 Pod 的多种方法

大家可能都知道 kubectl 其实没有 restart pod 这个命令,这个主要是由于在 k8spod 的管理属于 rs 等控制器,并不需要运维手动维护,但有时候,我们修改了 configmap 的配置文件后,希望重启 pod 加载配置,此时就需要 “重启” Pod。这里说的“重启”是加了引号的,准确地来说,是重建 pod,给用户的感觉是重启。

下面介绍六种 k8s 里面重启 pod 的方式

方法一:kubectl rollout restart

这个命令是比较推荐的,通过

kubectl rollout restart deployment 
<deployment_name> -n <namespace>

便可以重建这个deployment下的 pod,和滚动升级类似,并不会一次性杀死Pod,比较平滑。

方法二:kubectl scale

这种方法相对来说,比较粗放,我们可以先将副本调成 0

kubectl scale deployment <deployment name> -n <namespace> --replicas=0

然后再改回目的副本数

kubectl scale deployment <deployment name> -n <namespace> --replicas=10

但这个会中断服务。但两条命令也能解决,下面介绍的就更直接了。

方法三: kubectl delete pod

这个就不解释了

kubectl delete pod 
<pod_name> -n <namespace>

还是多说一句,此时优雅删除的效果还是有的。再多说一句,直接删 rs 效果也挺好。

方法四:kubectl replace

这种方法是通过更新 Pod ,从触发 k8s pod 的更新

kubectl get pod 
<pod_name> -n <namespace> -o yaml | kubectl replace --force -f -

方法五:kubectl set env

通过 设置环境变量,其实也是更新 pod spec 从而触发滚动升级。

kubectl set env deployment <deployment name> -n <namespace> DEPLOY_DATE="$(date)"

只不过这里通过 kubectl 命令行,当我们通过 API 更新 pod spec 后一样会触发滚动升级

方法六: kill 1

这种方法就是在容器里面 kill 1 号进程。

kubectl exec -it 
<pod_name> -c <container_name> --/bin/sh -c "kill 1"

但是但是但是,重要的话说三遍,它有个局限,必须要求你的 1 号进程要 捕获 TERM 信号,否则在容器里面是杀不死自己的.

References

#Kubernetes

使用 earlyoom 提前终止 Linux 高内存占用进程

当我在服务器上运行一个不太重要的进程时,它的内存使用量会随实际情况不断发生变化,当它的内存超过某个阈值时,我想要 kill 掉它并重启该进程。为了满足我这个需求,我了解到了 earlyoom 这个程序。

earlyoom 是一个用于 Linux 的内存不足 (OOM) 守护进程。它在系统内存和交换空间不足时提前终止内存占用最大的进程,从而避免系统陷入完全无响应的状态。它的全称是 “Early OOM Daemon”,其中 OOM 代表 “Out Of Memory”。本文将介绍 earlyoom 的安装、配置和使用方法。

什么是 earlyoom?

在 Linux 系统中,默认的 OOM 机制只有在内存和交换空间完全耗尽后才会触发,这通常会导致系统变得非常缓慢甚至完全无响应。earlyoom 的设计初衷是通过更早地检测内存和交换空间不足的情况,提前终止高内存占用的进程,从而保持系统的响应速度。

earlyoom 每秒最多检查 10 次内存和交换空间的使用情况。如果可用内存和可用交换空间均低于 10%,则终止内存占用最大的进程。这个阈值可以通过命令行参数进行配置。

earlyoom 的主要功能和特点

  1. 监控内存使用情况:earlyoom 会持续监控系统的可用内存和交换内存。通过定期检查内存使用情况,它能够在内存过低时及时采取措施。
  2. 主动释放内存:当系统内存降至预设的阈值以下时,earlyoom 会主动终止内存占用最高的进程。这比传统的 Linux 内核 OOM 杀手更早地介入,减少系统变得完全无响应的风险。
  3. 可配置性:用户可以通过命令行参数或配置文件自定义 earlyoom 的行为,包括设定内存和交换内存的阈值,选择是否终止内存占用最高的进程或是直接重启系统。
  4. 轻量级和高效:earlyoom 设计为一个轻量级的守护进程,占用系统资源非常少,适合在各种环境下运行。
  5. 日志和通知:earlyoom 会记录所有的内存监控和进程终止操作,并可以配置为在内存过低时发送通知,方便管理员及时了解系统状态。

earlyoom 的使用场景

  1. 避免系统冻结:在 Linux 系统中,当内存资源耗尽时,内核的 OOM (Out of Memory) Killer 会启动,尝试释放内存。默认情况下,OOM Killer 会在系统内存极度不足时才启动,这可能导致系统变得非常缓慢或完全无响应,用户无法进行操作。earlyoom 通过在内存和交换空间较低时更早地杀死进程,防止系统冻结,提高系统的稳定性和响应性。
  2. 提高系统的可用性:对于一些关键的服务器或应用场景,确保系统的稳定性至关重要。earlyoom 可以在内存紧张之前采取措施,避免系统进入不可操作的状态,尤其是在资源使用高峰期。
  3. 开发和测试环境:在开发和测试环境中,可能会出现由于内存泄漏或其他原因导致内存迅速耗尽的情况。使用 earlyoom 可以模拟和测试系统在低内存条件下的表现,确保应用程序能够在这些条件下稳定运行。

如何安装 earlyoom

从源码编译

首先,克隆 earlyoom 的 GitHub 仓库并进入项目目录:

git clone https://github.com/rfjakob/earlyoom.git
cd earlyoom

然后,编译项目:

make

可选:运行集成的自测试:

make test

最后,使用 systemdinit.dearlyoom 注册为系统服务:

sudo make install              # systemd
sudo make install-initscript   # non-systemd

使用包管理器安装

Debian 和 Ubuntu

对于 Debian 10+ 和 Ubuntu 18.04+,可以直接安装 earlyoom 包:

sudo apt install earlyoom

Fedora 和 RHEL 8

对于 Fedora 和 RHEL 8(需要 EPEL):

sudo dnf install earlyoom
sudo systemctl enable --now earlyoom

Arch Linux

对于 Arch Linux:

sudo pacman -S earlyoom
sudo systemctl enable --now earlyoom

其他发行版的安装方法请参阅 repology 页面

如何使用 earlyoom

启动 earlyoom 可执行文件:

./earlyoom

它会显示内存和交换空间的使用情况,并在内存和交换空间不足时终止进程。以下是一个示例输出:

earlyoom v1.8
mem total: 23890 MiB, user mem total: 21701 MiB, swap total: 8191 MiB
sending SIGTERM when mem avail <= 10.00% and swap free <= 10.00%,
        SIGKILL when mem avail <=  5.00% and swap free <=  5.00%
mem avail: 20012 of 21701 MiB (92.22%), swap free: 5251 of 8191 MiB (64.11%)
mem avail: 20031 of 21721 MiB (92.22%), swap free: 5251 of 8191 MiB (64.11%)
mem avail: 20033 of 21723 MiB (92.22%), swap free: 5251 of 8191 MiB (64.11%)
[...]

命令行选项

earlyoom 支持多种命令行选项,以下是常用选项的说明:

earlyoom v1.8
Usage: ./earlyoom [OPTION]...

  -m PERCENT[,KILL_PERCENT] 设置可用内存最小百分比 (默认 10%)。
                            低于此值发送 SIGTERM 信号,低于 KILL_PERCENT 时发送 SIGKILL 信号 (默认 PERCENT/2)。
  -s PERCENT[,KILL_PERCENT] 设置可用交换空间最小百分比 (默认 10%)。
  -M SIZE[,KILL_SIZE]       设置可用内存最小值 (以 KiB 计)。
  -S SIZE[,KILL_SIZE]       设置可用交换空间最小值 (以 KiB 计)。
  -n                        启用 d-bus 通知。
  -N /PATH/TO/SCRIPT        进程被杀死后执行脚本。
  -g                        杀死整个进程组。
  -d, --debug               启用调试信息。
  -v                        显示版本信息并退出。
  -r INTERVAL               内存报告间隔(以秒计,默认 1),设为 0 可禁用。
  -p                        设置 EarlyOOM 的 niceness 为 -20 和 oom_score_adj 为 -100。
  --ignore-root-user        不杀死 root 用户的进程。
  --sort-by-rss             按 RSS 大小选择进程而非 oom_score。
  --prefer REGEX            优先杀死符合正则表达式的进程。
  --avoid REGEX             避免杀死符合正则表达式的进程。
  --ignore REGEX            忽略符合正则表达式的进程。
  --dryrun                  干跑模式(不杀死任何进程)。
  --syslog                  使用 syslog 记录日志。
  -h, --help                显示帮助信息。

earlyoom 的命令行使用非常直观,可以通过不同的参数来配置它的行为。

注意事项:以上命令中正则表达式参数需要使用进程的comm名称

  • --prefer--avoid--ignore 参数中使用的正则表达式需要根据进程名称的前 15 个字节进行匹配,因为 comm 名称字段最大长度为 15 字节,超过部分会被截断。
  • 使用 --ignore 参数时需要特别小心,因为忽略某些关键进程可能会导致其他进程被杀死,从而影响系统的正常运行。

相关阅读:什么是进程的 comm 名称?Linux 进程 comm 名称详解

earlyoom 常用命令行使用示例

earlyoom 是一个内存管理工具,它可以在系统内存和交换空间低于设定阈值时提前杀死进程。以下是一些常用的命令行使用示例:

  1. 基本使用

     earlyoom

    使用默认配置,设置内存和交换空间阈值为 10%。当内存和交换空间都低于 10% 时,earlyoom 会发送 SIGTERM,如果继续低于阈值,则发送 SIGKILL

  2. 自定义内存和交换空间阈值

     earlyoom -m 20,10 -s 15,7

    设置可用内存阈值为 20%,当内存低于 20% 时发送 SIGTERM,低于 10% 时发送 SIGKILL。同时,设置交换空间阈值为 15%,低于 15% 时发送 SIGTERM,低于 7% 时发送 SIGKILL

  3. 指定内存和交换空间的绝对值

     earlyoom -M 1048576,524288 -S 512000,256000

    设置内存阈值为 1 GiB (1048576 KiB),低于此值时发送 SIGTERM,低于 512 MiB (524288 KiB) 时发送 SIGKILL。交换空间阈值为 500 MiB (512000 KiB),低于此值时发送 SIGTERM,低于 250 MiB (256000 KiB) 时发送 SIGKILL

  4. 启用调试模式

     earlyoom -d

    启用调试信息输出,帮助排查问题。

  5. 启用通知

     earlyoom -n

    启用通过 D-Bus 发送通知。需要 systembus-notify 工具运行在用户会话中,以显示通知。

  6. 执行脚本

     earlyoom -N /path/to/script.sh

    在每次进程被杀死时执行指定的脚本。脚本可以获取被杀死进程的相关信息,如 PID、进程名、命令行等。

  7. 增加优先级

     earlyoom -p

    增加 earlyoom 的优先级,将其 niceness 设置为 -20,并将 oom_score_adj 设置为 -100。需要通过系统服务配置来达到相同效果。

  8. 模拟运行

     earlyoom --dryrun

    模拟运行 earlyoom,不实际杀死任何进程,用于测试配置是否正确。

  9. 忽略某些进程

     earlyoom --ignore '^gnome-shell$'

    --ignore 参数用于完全忽略名称匹配指定正则表达式(REGEX)的进程。这意味着这些进程无论内存使用情况如何,都不会被 earlyoom 杀死。使用此选项时需要谨慎,因为忽略某些进程可能会导致其他进程被优先选择进行杀死,从而影响系统的稳定性。

  10. 优先杀死某些进程

     earlyoom --prefer '^Isolated Web Co$'

    --prefer 参数用于优先杀死名称匹配指定正则表达式(REGEX)的进程。当某个进程的名称与给定的正则表达式匹配时,会在其 oom_score 中增加 300 分,这使得该进程更有可能被优先选择进行杀死。

  11. 避免杀死某进程

     ```sh
     earlyoom --avoid '^gunicorn$'
    
    
     `--avoid` 参数用于避免杀死名称匹配指定正则表达式(REGEX)的进程。当某个进程的名称与给定的正则表达式匹配时,会在其 `oom_score` 中减少 300 分,这使得该进程不太可能被选择进行杀死。

earlyoom 退出状态码

  • 0: 成功执行。
  • 1: 其他错误 – 检查错误消息以获取详细信息。
  • 2: 开关冲突 – 使用了不兼容的选项。
  • 4: 无法切换到 /proc 目录。
  • 5: 无法打开 /proc 目录。
  • 7: 无法打开 /proc/sysrq-trigger
  • 13: 未知选项 – 传递了无效的选项。
  • 14: 其他选项的参数错误。
  • 15: 内存阈值参数错误。
  • 16: 交换空间阈值参数错误。
  • 102: 无法打开 /proc/meminfo 文件。
  • 103: 无法读取 /proc/meminfo 文件。
  • 104: /proc/meminfo 文件中找不到特定条目。
  • 105: 解析 /proc/meminfo 文件内容时转换数字失败。

配置文件

如果你将 earlyoom 作为系统服务运行,可以通过 /etc/default/earlyoom 文件调整其配置。例如:

EARLYOOM_ARGS="-m 5 -r 60 --avoid '(^|/)(init|Xorg|ssh)$' --prefer '(^|/)(java|chromium)$'"

修改配置文件后,重新启动服务以应用更改:

systemctl restart earlyoom

测试 earlyoom

可以通过制造内存泄漏(切记不要在生产环境测试)来测试 earlyoom 的功能:

tail /dev/zero

查看日志

如果 EarlyOOM 作为 systemd 服务运行,可以通过以下命令查看最近的日志:

systemctl status earlyoom

或者查看详细日志:

sudo journalctl -u earlyoom -g "(sending|killing)" --since today

示例输出:

8月 05 00:53:43 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1389844 uid 0 "Isolated Web Co": badn>
8月 05 02:25:59 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1419894 uid 0 "Isolated Web Co": badn>
8月 05 03:52:30 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1448534 uid 0 "Isolated Web Co": badn>
8月 05 05:18:24 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1476938 uid 0 "Isolated Web Co": badn>
8月 05 06:48:10 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1505535 uid 0 "Isolated Web Co": badn>
8月 05 08:13:19 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1535267 uid 0 "Isolated Web Co": badn>
8月 05 09:40:01 32.3.18.8 earlyoom[3147772]: sending SIGTERM to process 1563244 uid 0 "Isolated Web Co": badn>
8月 05 10:32:45 32.3.18.8 earlyoom[1609353]: Will avoid killing process names that match regex '(init|sshd|su>
8月 05 10:32:45 32.3.18.8 earlyoom[1609353]: sending SIGTERM when mem <= 10.00% and swap <= 10.00%,

启用通知

从 1.6 版本开始,earlyoom 可以通过 d-bus 发送通知。需要启用 -n 选项,并运行 systembus-notify

此外,earlyoom 可以在每次终止进程后执行脚本,使用 EARLYOOM_PIDEARLYOOM_UIDEARLYOOM_NAME 环境变量提供进程信息。使用 -N /path/to/script 启用此功能。

发送通知到企业微信示例脚本:

#!/bin/bash

# 企业微信 webhook 地址
WEBHOOK_URL='https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx'

# 生成通知内容
CONTENT="进程被EarlyOOM杀死\n\n"
CONTENT+="PID: $EARLYOOM_PID\n"
CONTENT+="进程名: $EARLYOOM_NAME\n"
CONTENT+="命令行: $EARLYOOM_CMDLINE\n"
CONTENT+="UID: $EARLYOOM_UID"

# 发送通知
curl -X POST "$WEBHOOK_URL" \
     -H "Content-Type: application/json" \
     -d "{
           \"msgtype\": \"text\",
           \"text\": {
               \"content\": \"$CONTENT\"
           }
     }"

结论

earlyoom 是一个简单而有效的工具,可以帮助 Linux 用户避免由于内存不足而导致的系统无响应问题。通过提前检测和终止高内存占用的进程,earlyoom 保持系统的稳定性和响应速度。如果你经常遇到系统内存不足的问题,推荐试试 earlyoom

References

#GNU_Linux #Debian #earlyoom

Kubernetes 使用 multus 插件增加子接口并固定 ip

apiVersion: "k8s.cni.cncf.io/v1"  
kind: NetworkAttachmentDefinition  
metadata:  
 name: macvlan8  
 namespace: multicast  
spec:  
 config: '{  
   "cniVersion": "0.3.1",  
   "plugins": [  
     {  
       "type": "macvlan",  
       "capabilities": { "ips": true },  
       "master": "eth1",  
       "mode": "bridge",  
       "ipam": {  
         "type": "static",  
         "addresses": [  
             {  
                 "address": "192.168.25.62/22",  
                 "gateway": "192.168.27.254"  
             }  
         ],  
         "routes": [  
             { "dst": "192.168.24.0/22", "gw": "192.168.27.254" },  
             { "dst": "192.168.5.0/24" }  
         ]  
       }  
     }  
   ]  
 }'

示例负载:

---  
apiVersion: apps/v1  
kind: Deployment  
metadata:  
 labels:  
   app: demo8  
 name: demo8  
 namespace: multicast  
spec:  
 replicas: 1  
 selector:  
   matchLabels:  
     app: demo8  
 template:  
   metadata:  
     annotations:  
       k8s.v1.cni.cncf.io/networks: macvlan8  
     labels:  
       app: demo8  
   spec:  
     containers:  
       - name: demo8  
         command:    
           - /bin/sh  
         args:  
           - '-c'  
           - "while true; do echo 1;sleep 10; done"  
         image: '192.168.25.9/hello_multicast_iperf:1_aarch64'  
         imagePullPolicy: Always  
         resources:  
           limits:  
             cpu: '2'  
           requests:  
             cpu: '2'

测试效果:

[root@node1 multus]# kubectl -n multicast exec -it demo8-578986878b-6m5nr -- sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: eth0@if75: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1430 qdisc noqueue state UP 
    link/ether 02:0c:78:14:6e:f9 brd ff:ff:ff:ff:ff:ff
    inet 10.233.71.42/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c:78ff:fe14:6ef9/64 scope link 
       valid_lft forever preferred_lft forever
4: net1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether ca:35:41:d3:92:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.25.62/22 brd 192.168.27.255 scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::c835:41ff:fed3:923e/64 scope link 
       valid_lft forever preferred_lft forever
/ # ip r
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link 
192.168.5.0/24 via 192.168.27.254 dev net1 
192.168.24.0/22 via 192.168.27.254 dev net1 
192.168.24.0/22 dev net1 scope link  src 192.168.25.62

References

kubernetes 使用 multus 为 pod 增加子接口

部署 multus-cni

git clone https://github.com/k8snetworkplumbingwg/multus-cni.git
cat ./deployments/multus-daemonset-thick.yml | kubectl apply -f -

创建 NetworkAttachmentDefinition

NetworkAttachmentDefinition 是 Kubernetes 中的一个自定义资源定义(Custom Resource Definition,简称 CRD)。这是由 Multus CNI 插件引入的,用于在 Kubernetes 中定义和管理额外的网络接口。

Multus CNI 是一个插件,允许 Kubernetes Pods 同时连接到多个网络。默认情况下,Kubernetes Pod 只有一个网络接口,即使你有多个网络,Pod 也只能连接到一个。Multus 解决了这个问题,使得 Pod 可以连接到多个网络。

NetworkAttachmentDefinition 对象定义了如何创建这些额外的网络接口。它包含了必要的配置信息,例如 CNI 插件的类型(如 flannel,macvlan,vlan等)、网络配置参数等。当你创建一个 Pod,并希望它连接到额外的网络时,你可以在 Pod 的定义中引用相应的 NetworkAttachmentDefinition

例如,以下是一个 NetworkAttachmentDefinition 的示例:

下面定义了一个名叫 macvlan1multus-cni NetworkAttachmentDefinitionmulticast 命名空间中,桥接到宿主机的 eth0 接口:

apiVersion: "k8s.cni.cncf.io/v1"  
kind: NetworkAttachmentDefinition  
metadata:  
 name: macvlan1  
 namespace: multicast  
spec:  
 config: '{  
     "cniVersion": "0.3.0",  
     "type": "macvlan",  
     "master": "eth0",  
     "mode": "bridge",  
     "ipam": {  
       "type": "host-local",  
       "ranges": [  
                   [ {  
                        "subnet": "192.168.24.0/22",  
                        "rangeStart": "192.168.25.60",  
                        "rangeEnd": "192.168.25.70",  
                        "gateway": "192.168.27.254"  
                   } ]  
       ],  
       "routes": [  
           {  
             "dst": "192.168.24.0/22",  
             "dst": "192.168.5.0/24",  
             "gw": "192.168.27.254"  
           }  

       ]  
     }  
   }'

其中的 ranges 字段定义了用于 multus 子接口分配的 ip 资源信息,routes 字段定义了桥接后增加到 pod 中的路由信息, dst 定义了通过该接口的网段,gw 字段定义这些网段的网关。

描述使用子接口的 pod 资源

apiVersion: v1
kind: Pod
metadata:
  name: pod-case-01
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf-1, macvlan-conf-2
spec:
  containers:
  - name: pod-case-01
    image: docker.io/centos/tools:latest
    command:
    - /sbin/init

还可以通过添加 `@

` 来指定接口名称,例如 `macvlan-conf-1@eth1`

描述使用子接口的 deployment 资源

---  
apiVersion: apps/v1  
kind: Deployment  
metadata:  
 labels:  
   app: broadcast  
 name: broadcast  
 namespace: multicast  
spec:  
 replicas: 1  
 selector:  
   matchLabels:  
     app: broadcast  
 template:  
   metadata:  
     annotations:  
       k8s.v1.cni.cncf.io/networks: macvlan1@eth1  
     labels:  
       app: broadcast  
   spec:  
     containers:  
       - name: broadcast  
         command:    
           - /bin/sh  
         args:  
           - '-c'  
           - "while true; do echo 1;sleep 10; done"  
         image: '192.168.25.9/hello_multicast_iperf:1_aarch64'  
         imagePullPolicy: Always  
         resources:  
           limits:  
             cpu: '2'  
           requests:  
             cpu: '2'

References

#Kubernetes #MultusCNI

Oracle Cloud (甲骨文云)全球各主要地区 IP 测试地址

亚太地区

日本东部 东京:

objectstorage.ap-tokyo-1.oraclecloud.com

日本中部 大阪:

objectstorage.ap-osaka-1.oraclecloud.com

韩国中部 首尔:

objectstorage.ap-seoul-1.oraclecloud.com

韩国北部 春川:

objectstorage.ap-chuncheon-1.oraclecloud.com

新加坡

objectstorage.ap-singapore-1.oraclecloud.com

澳大利亚东部 悉尼:

objectstorage.ap-sydney-1.oraclecloud.com

澳大利亚东南部 墨尔本:

objectstorage.ap-melbourne-1.oraclecloud.com

印度西部 孟买:

objectstorage.ap-mumbai-1.oraclecloud.com

印度南部 海得拉巴:

objectstorage.ap-hyderabad-1.oraclecloud.com

以色列中部 耶路撒冷:

objectstorage.il-jerusalem-1.oraclecloud.com

北美地区

美国东部 阿什本:

objectstorage.us-ashburn-1.oraclecloud.com

美国西部 凤凰城:

objectstorage.us-phoenix-1.oraclecloud.com

美国西部 圣何塞:

objectstorage.us-sanjose-1.oraclecloud.com

加拿大东南部 蒙特利尔:

objectstorage.ca-montreal-1.oraclecloud.com

加拿大东南部 多伦多:

objectstorage.ca-toronto-1.oraclecloud.com

墨西哥中部 克雷塔罗:

objectstorage.mx-queretaro-1.oraclecloud.com

墨西哥东北部 蒙特雷:

objectstorage.mx-monterrey-1.oraclecloud.com

欧洲地区:

英国南部 伦敦:

objectstorage.uk-london-1.oraclecloud.com

英国西部 纽波特:

objectstorage.uk-cardiff-1.oraclecloud.com

德国中部 法兰克福:

objectstorage.eu-frankfurt-1.oraclecloud.com

瑞士北部 苏黎世:

objectstorage.eu-zurich-1.oraclecloud.com

瑞典中部 斯德哥尔摩:

objectstorage.eu-stockholm-1.oraclecloud.com

荷兰西北部 阿姆斯特丹:

objectstorage.eu-amsterdam-1.oraclecloud.com

法国中部 巴黎:

objectstorage.eu-paris-1.oraclecloud.com

法国南部 马赛:

objectstorage.eu-marseille-1.oraclecloud.com

西班牙中部 马德里:

objectstorage.eu-madrid-1.oraclecloud.com

意大利西北部 米兰

objectstorage.eu-milan-1.oraclecloud.com

中东地区

阿联酋东部 迪拜:

objectstorage.me-dubai-1.oraclecloud.com

阿联酋中部 阿布扎比

objectstorage.me-abudhabi-1.oraclecloud.com

沙特阿拉伯西部 吉达:

objectstorage.me-jeddah-1.oraclecloud.com

南美地区

巴西东部 圣保罗:

objectstorage.sa-saopaulo-1.oraclecloud.com

巴西南部 文郝多:

objectstorage.sa-vinhedo-1.oraclecloud.com

智利中部 圣地亚哥:

objectstorage.sa-santiago-1.oraclecloud.com

哥伦比亚中部 波哥大:

objectstorage.sa-bogota-1.oraclecloud.com

非洲地区

南非中部 约翰内斯堡:

objectstorage.af-johannesburg-1.oraclecloud.com

References

#OracleCloud

解决 PVE 报错 rbd error list images

针对下列报错:

    2021-05-26 11:06:11 ERROR: Failed to sync data - rbd error: rbd: listing images failed: (2) No such file or directory

解决方法

进入命令行,执行

# 查看 rbd 清单
rbd ls -l <cephpool-name>
# 例如:
rbd ls -l data

# 使用命令删除错误磁盘镜像
rbd rm <img-name> -p <cephpool-name>

# 例如
rbd rm vm-111-disk-0 -p data

References

#ProxmoxVE #Ceph

getopts 处理 shell 参数

处理命令行参数是一个相似而又复杂的事情,为此,C提供了getopt/getopt_long等函数,
C++的boost提供了Options库,在shell中,处理此事的是getoptsgetopt.
getoptsgetopt功能相似但又不完全相同,其中getopt是独立的可执行文件,而getopts是由Bash内置的。
先来看看参数传递的典型用法:

  • ./test.sh -a -b -c: 短选项,各选项不需参数
  • ./test.sh -abc : 短选项,和上一种方法的效果一样,只是将所有的选项写在一起。
  • ./test.sh -a args -b -c :短选项,其中 -a 需要参数,而 -b -c 不需参数。
  • ./test.sh --a-long=args --b-long :长选项 使用getopts非常简单:
#test.sh

#!/bin/bash

while getopts "a:bc" arg #选项后面的冒号表示该选项需要参数
do
        case $arg in
             a)
                echo "a's arg:$OPTARG" #参数存在$OPTARG中
                argument1=$OPTARG
                ;;
             b)
                echo "b"
                branch=1
                ;;
             c)
                echo "c"
                iscar=1
                ;;
             ?)  #当有不认识的选项的时候arg为?
            echo "unkonw argument"
        exit 1
        ;;
        esac
done

现在就可以使用:

./test.sh -a arg -b -c

./test.sh -a arg -bc

来加载了。
应该说绝大多数脚本使用该函数就可以了,如果需要支持长选项以及可选参数,那么就需要使用getopt.

References