Chemmy's Blog

Golang日志组件logrus使用

发表于 2024-07-11 更新于 2026-05-09 分类于编程技术， Golang

K3s部署Registry镜像仓库

发表于 2024-07-08 更新于 2026-05-09 分类于容器技术

Docker Registry是Docker官方推出的轻量级私有镜像仓库解决方案，相较于Harbor等可视化工具，它具备部署简单、资源占用低的优势，非常适合中小规模容器环境的镜像管理需求。本文将从实际运维场景出发，详细拆解Registry的基础部署、HTTP/HTTPS访问配置、镜像推送拉取、缓存加速及安全认证全流程，精准解决私有仓库部署中的核心痛点，助力开发者快速搭建可用的私有镜像仓库。

一、核心问题：Docker访问Registry的HTTPS限制

Docker客户端默认强制采用HTTPS协议访问Registry，若私有仓库未配置SSL证书、仅支持HTTP访问，会触发经典报错：

1	Get https://192.168.0.110:5000/v1/_ping: http: server gave HTTP response to HTTPS client

该问题的核心原因的是：Docker客户端默认向Registry发起HTTPS请求，但未配置SSL的Registry仅能返回HTTP响应，导致通信链路中断。针对此问题，我们提供两种解决方案，分别适配测试/内网和生产环境。

方案A：临时放宽HTTP限制（测试/内网环境）

通过修改Docker启动参数，允许指定私有仓库的HTTP访问，配置简单高效，适合内网测试场景（生产环境不推荐，存在安全风险）。具体步骤如下：

编辑Docker服务配置文件，添加HTTP访问信任参数：

1
2
3

vim /usr/lib/systemd/system/docker.service
# 在ExecStart行末尾添加--insecure-registry参数，指定私有仓库IP和端口
ExecStart=/usr/bin/dockerd --insecure-registry=192.168.0.110:5000

重启Docker服务，使配置生效：

1 2	systemctl daemon-reload systemctl restart docker.service

配置完成后，执行docker pull 192.168.0.110:5000/panda/mysql:v1即可正常拉取私有仓库镜像。

方案B：配置HTTPS加密访问（生产环境）

生产环境需保障镜像传输安全，必须通过SSL证书实现HTTPS加密访问，具体步骤如下：

1. 准备SSL证书

需提前准备CA根证书（CA_Cert.pem）、服务端证书（my.crt）及私钥（myprivate.key），证书绑定的域名需与Registry访问域名一致（如www.my.com），同时在客户端`/etc/hosts`中配置域名与Registry服务器IP的映射关系，避免域名解析失败。

# 示例：证书文件存放目录及文件列表
ls -l /root/cert_test/
# -rw-------. 1 root root 1359 CA_Cert.pem  # CA根证书（客户端需导入信任）
# -rw-------. 1 root root 4509 my.crt       # Registry服务端证书
# -rw-------. 1 root root 1679 myprivate.key # 证书私钥

2. 启动带HTTPS的Registry容器

通过环境变量指定证书和私钥路径，将证书目录挂载到容器内部，确保Registry能正常读取证书：

docker run -d \
  -v /var/my_registry/:/var/lib/registry \  # 镜像数据持久化到宿主机
  -v /root/cert_test/:/etc/cert.d \         # 挂载证书目录
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/etc/cert.d/my.crt \  # 服务端证书路径
  -e REGISTRY_HTTP_TLS_KEY=/etc/cert.d/myprivate.key \    # 证书私钥路径
  -p 5000:5000 \
  my_registry  # 自定义Registry镜像（也可使用官方registry镜像）

3. 客户端信任CA证书

以CentOS系统为例，将CA根证书导入系统信任列表，确保客户端能正常识别HTTPS证书：

1 2	cp CA_Cert.pem /etc/pki/ca-trust/source/anchors/ update-ca-trust

验证HTTPS访问有效性：

1 2	curl -I https://www.my.com:5000/ # 返回200 OK即表示HTTPS配置成功 docker pull www.my.com:5000/panda/my_registry # 可正常拉取镜像

二、Registry基础部署与镜像管理

1. 基础部署（无认证）

快速部署无认证的Registry，适合内网临时测试，核心是拉取官方镜像、启动容器并实现数据持久化：

# 拉取Docker官方Registry镜像
docker pull registry

# 启动Registry容器，配置端口映射和数据挂载
docker run -d -p 5000:5000 \
  --restart=always \
  --name="registry" \
  -v /opt/registry:/var/lib/registry \
  registry

--restart=always：配置容器随Docker服务自动启动，也可在/etc/docker/daemon.json中添加"live-restore": true实现全局自动恢复；
/var/lib/registry：Registry默认的镜像存储路径，挂载到宿主机可避免容器删除后镜像数据丢失。

2. 客户端配置私有仓库信任

客户端需配置私有仓库信任，才能正常与Registry通信，编辑/etc/docker/daemon.json文件：

{
  "registry-mirrors": ["https://阿里云加速地址"],  # 可选配置，加速官方镜像拉取
  "insecure-registries": ["10.4.7.7:5000"]        # 信任私有仓库的HTTP访问
}

保存配置后，重启Docker服务（systemctl restart docker），客户端即可正常识别私有仓库。

3. 镜像推送与拉取

（1）镜像打标签（核心步骤）

Docker镜像推送至私有仓库前，必须按指定格式打标签，格式为：仓库IP:端口/自定义路径/镜像名:标签，否则无法正常推送：

1 2	# 示例：将本地centos:6.9镜像打标签，适配私有仓库格式 docker tag centos:6.9 10.4.7.7:5000/jerry/centos:v6.9

（2）推送镜像到私有仓库

1	docker push 10.4.7.7:5000/jerry/centos:v6.9

（3）拉取私有仓库镜像

1	docker pull 10.4.7.7:5000/jerry/centos:v6.9

（4）仓库镜像查询（无原生search命令）

原生Registry不支持docker search命令，需通过REST API查询镜像信息，常用查询命令如下：

# 查看私有仓库中所有镜像仓库
curl -XGET http://10.4.7.7:5000/v2/_catalog  # 返回{"repositories":["jerry/centos"]}

# 查看指定镜像的所有标签
curl -XGET http://10.4.7.7:5000/v2/jerry/centos/tags/list  # 返回{"name":"jerry/centos","tags":["v6.9"]}

三、Registry缓存配置：代理官方仓库

对于内网多台主机使用容器的场景，配置Registry缓存官方镜像，可实现“一次拉取、本地缓存、多次复用”，大幅提升镜像拉取速度，减少外网带宽消耗。

1. 修改Registry配置文件

创建config-example.yml配置文件，添加代理配置，指向Docker官方仓库：

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
proxy:
  remoteurl: https://registry-1.docker.io  # 代理Docker官方仓库，实现镜像缓存

2. 构建自定义Registry镜像

1	docker build -t docker-registry:v0.1 .

3. 启动缓存仓库

挂载配置文件和数据目录，启动缓存版Registry容器：

docker run -d -p 5000:5000 \
  --restart=always \
  --name docker-registry \
  -v $(pwd)/config-example.yml:/etc/docker/registry/config.yml \
  -v /home/registry:/var/lib/registry \
  docker-registry:v0.1

4. 客户端配置镜像加速

修改客户端/etc/docker/daemon.json，将私有仓库设为镜像源，实现官方镜像缓存拉取：

1
2
3

{
  "registry-mirrors":["http://10.4.7.7:5000"]
}

重启Docker服务后，客户端拉取官方镜像（如docker pull node:8.4.0-onbuild）时，Registry会自动从官方仓库拉取并缓存，后续拉取相同镜像时，直接从本地缓存返回，速度大幅提升。

四、安全加固：添加用户名密码认证

默认部署的Registry无任何认证机制，内网所有用户均可自由推送、拉取甚至删除镜像，存在极大安全风险。通过htpasswd配置HTTP基本认证，可实现用户名密码校验，提升仓库安全性。

1. 生成密码文件

安装httpd-tools工具，生成用户名密码文件，用于Registry认证校验：

# 安装htpasswd工具（CentOS系统）
yum install httpd-tools -y

# 创建认证文件存储目录
mkdir /opt/registry-auth -p

# 生成单用户（用户名为oldguo，密码为123，-B表示加密存储）
htpasswd -Bbn oldguo 123 > /opt/registry-auth/htpasswd

# 追加多用户（可选，使用>>避免覆盖原有用户）
htpasswd -Bbn newuser newpass >> /opt/registry-auth/htpasswd

2. 启动带认证的Registry容器

挂载密码文件目录，通过环境变量指定认证方式和密码文件路径，启动带认证的Registry：

docker run -d -p 5000:5000 \
  -v /opt/registry-auth/:/auth/ \          # 挂载密码文件目录
  -v /opt/registry:/var/lib/registry \     # 镜像数据持久化
  --name register-auth \
  -e "REGISTRY_AUTH=htpasswd" \            # 指定认证方式为htpasswd
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \  # 认证域（自定义描述）
  -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd" \    # 密码文件路径
  registry

3. 客户端认证访问

配置认证后，客户端推送、拉取镜像前必须先登录私有仓库，输入正确的用户名和密码：

1 2	docker login 10.4.7.7:5000 # 执行后输入用户名oldguo、密码123 docker push 10.4.7.7:5000/jerry/centos:v6.9 # 登录成功后可正常推送

五、常见问题解答

1. 配置缓存后能否正常下载官方镜像？

可以。Registry的proxy配置会自动代理官方仓库，客户端拉取官方镜像时，Registry会先检查本地是否有缓存：有缓存则直接返回，无缓存则从官方仓库拉取并缓存，不影响正常使用。

2. 能否直接执行`pull centos:6.9`，省略私有仓库前缀？

不能。Docker默认优先从Docker Hub拉取镜像，原生Registry不支持省略仓库前缀的拉取方式。若需实现该功能，可替换为Harbor等增强型仓库工具，或手动修改镜像标签为短名称（不推荐，易造成镜像混淆）。

3. 执行`docker search`查询私有仓库镜像失败，如何解决？

原生Registry未实现docker search的API兼容，无法直接通过该命令查询。可通过REST API查询（如curl -XGET http://10.4.7.7:5000/v2/_catalog）；若需可视化搜索、镜像管理功能，建议替换为Harbor（基于Registry开发，功能更完善）。

六、总结

Docker Registry作为轻量级私有镜像仓库，是中小规模容器环境的优选方案，核心优势在于部署简单、资源占用低、可灵活扩展。本文梳理的核心要点的如下：

测试/内网环境：优先采用--insecure-registry配置，快速开启HTTP访问，提升部署效率；
生产环境：必须配置HTTPS加密访问+用户名密码认证，双重保障镜像传输和存储安全；
性能优化：通过配置镜像缓存代理，减少外网依赖，提升内网镜像拉取速度，降低带宽消耗；
镜像管理：严格遵循“仓库IP:端口/路径/镜像名:标签”的标签格式，通过REST API查询镜像信息。

通过本文的步骤配置，可快速搭建一个安全、高效的Docker私有镜像仓库，满足企业内网容器镜像的存储、管理和分发需求，为容器化部署提供可靠的镜像支撑。

KubeEdge设备孪生设计

发表于 2024-07-04 更新于 2026-05-09 分类于数据库

KubeEdge中的数据结构设计

Device

字段	类型	说明
ID	string	设备唯一编码
Name	string	设备名称
Description	string	设别描述
State	string	设备状态
LastOnline	DateTime	最后在线时间
Attributes	Map<string,MsgAttr>	设备属性(上报属性)
Twin	Map<string,MsgTwin>	设备孪生属性(可控制属性)

MsgAttr

字段	类型	说明
Value	string	属性名称
Optional	bool	是否可为空
Metadata	TypeMetadata	属性类型元数据

MsgTwin

字段	类型	说明
Expected	TwinValue	期望值
Actual	TwinValue	实际值
Optional	bool	是否可为空
Metadata	TypeMetadata	属性类型元数据
ExpectedVersion	TwinVersion	期望值版本
ActualVersion	TwinVersion	实际值版本

数据库表设计

Device

字段	类型	说明
ID		设备实例唯一ID
Name		设备实例名称
Description		设备描述
State		设备状态
LastOnline		最后在线时间

DeviceAttr

字段	类型	说明
ID		属性实例唯一ID
DeviceId		设备实例唯一ID
Name		设备名称
Description		设备描述
Value		设备属性值
Optional	bool	是否可空
AttrType		属性类型
Metadata		属性元数据

DeviceTwin

字段	类型	说明
ID
DeviceID
Name
Description
Expected
Actual
ExpectedMeta
ActualMeta
ExpectedVersion
ActualVersion
Optional
AttrType
Metadata

设备孪生表结构设计

发表于 2024-07-04 更新于 2026-05-09 分类于数据库

DEVICE

字段	类型	说明
ID	int	自增ID
SN	varchar(20)	设备唯一编码
NAME	varchar(20)	设备名称
MARKED	BOOL	设备是否标记
IP	varchar(15)	设备IP地址
LOCATION	varchar(200)	设备安装位置

DEVICE_ATTR

字段	类型	说明
ID	int	自增ID
KEY	varchar(20)	属性名
CHANNEL
VALUE	int	属性值
DEVICE_ID	int	属性所属设备ID
SCALE	int	缩放倍率，当数值有小数时可用倍率缩放
UNIT	varchar(20)	数值单位

DEVICE_STATE

字段	类型	说明
ID	int	自增ID
DEVICE_ID	int	属性所属设备ID
PORT	int	设备接收端口
VALUE	int	数值
UNIT	varchar(20)	数值单位

DEVICE_LINKAGE

字段	类型	说明
ID	int	自增ID
CAT
DEVICE_ID	int	属性所属设备ID
PORT	int	设备接收端口
TARGET		联动目标
TRIGGER		联动触发器
TRIGGER_ALARM		联动触发告警
ACTION		联动动作
PARAM		参数

DEVICE_ALARM

字段	类型	说明
ID		自增ID
APP_ID		固件ID
CAT
REPORTER
PORT		端口
CODE		编码
MSG		消息
ALARM_TYPE		告警类型
SEVERITY
STATUS		状态

前言

在使用Podman时，由于默认镜像源位于国外，下载镜像速度较慢甚至无法连接。本文将详细介绍如何在Windows系统上修改Podman的镜像配置源，实现镜像下载加速。

系统环境

操作系统：Windows 10/11
Podman版本：适用于Windows的Podman Desktop
依赖组件：WSL 2（Windows Subsystem for Linux）

解决方案

核心思路

将Podman的默认镜像源修改为国内镜像源，实现下载加速。

操作步骤

1. 打开Windows PowerShell

以管理员身份运行PowerShell，输入以下命令进入WSL子系统：

wsl

2. 修改registries.conf配置文件

在WSL子系统中，执行以下命令编辑配置文件：

1	sudo vi /etc/containers/registries.conf

如果使用其他编辑器，也可以使用：

1	sudo nano /etc/containers/registries.conf

3. 配置镜像源

在配置文件中添加或修改以下内容：

基本配置示例：

unqualified-search-registries = ["docker.io"]

[[registry]]
prefix = "docker.io"
location = "你的阿里云加速器地址.mirror.aliyuncs.com"

完整配置示例（支持多个镜像源）：

unqualified-search-registries = ["docker.io"]

[[registry]]
prefix = "docker.io"
location = "hub-mirror.c.163.com"

[[registry.mirror]]
location = "docker.mirrors.ustc.edu.cn"

[[registry.mirror]]
location = "registry.docker-cn.com"

4. 保存并退出

在vi编辑器中：按Esc键，输入:wq，按Enter保存退出
在nano编辑器中：按Ctrl+X，输入Y确认保存，按Enter退出

5. 重启Podman服务

退出WSL子系统后，执行以下操作：

方法一：重启WSL

1 2	wsl --shutdown wsl

方法二：重启Podman机器

1 2	podman machine stop podman machine start

方法三：重启计算机
如果上述方法无效，可以尝试重启计算机。

6. 验证配置

启动Podman后，可以通过以下命令验证镜像下载速度：

1	podman pull nginx:latest

国内镜像源地址

常用镜像源列表

镜像源名称	地址	备注
Docker中国区官方镜像	https://registry.docker-cn.com	官方镜像，稳定性好
网易镜像	http://hub-mirror.c.163.com	速度较快，推荐使用
中国科技大学镜像	http://docker.mirrors.ustc.edu.cn	教育网镜像
阿里云镜像	http://<你的ID>.mirror.aliyuncs.com	需要阿里云账号

阿里云镜像加速器获取步骤

登录阿里云控制台
- 访问：https://cr.console.aliyun.com
- 使用阿里云账号登录
进入镜像加速器页面
- 在左侧导航栏选择”镜像工具” → “镜像加速器”
- 或直接访问：https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
获取加速器地址
- 页面会显示你的专属加速器地址
- 格式如：xxxxxx.mirror.aliyuncs.com
- 复制该地址用于配置

高级配置

多镜像源配置

unqualified-search-registries = ["docker.io"]

[[registry]]
prefix = "docker.io"
location = "hub-mirror.c.163.com"

[[registry.mirror]]
location = "docker.mirrors.ustc.edu.cn"

[[registry.mirror]]
location = "registry.docker-cn.com"

# 配置私有仓库
[[registry]]
location = "私有仓库地址"
insecure = true  # 如果是HTTP而非HTTPS

用户级配置

除了系统级配置，还可以在用户目录下创建配置文件：

# 创建用户配置目录
mkdir -p ~/.config/containers

# 复制或创建配置文件
cp /etc/containers/registries.conf ~/.config/containers/

故障排除

常见问题及解决方案

1. 配置文件权限问题

# 检查文件权限
ls -l /etc/containers/registries.conf

# 修改权限（如果需要）
sudo chmod 644 /etc/containers/registries.conf

2. 配置语法错误

1 2	# 检查配置文件语法 podman info --debug

3. 镜像拉取失败

# 测试镜像拉取
podman pull hello-world

# 查看详细错误信息
podman pull --log-level=debug nginx:latest

4. WSL相关问题

# 检查WSL状态
wsl --list --verbose

# 重启WSL
wsl --shutdown

配置验证命令

# 查看当前配置
podman info | grep -A 10 "registries"

# 测试镜像下载速度
time podman pull nginx:latest

性能优化建议

1. 选择最佳镜像源

根据地理位置选择最近的镜像源
定期测试不同镜像源的下载速度
可以配置多个镜像源，Podman会自动选择最快的

2. 缓存配置

# 查看缓存使用情况
podman system df

# 清理缓存
podman system prune -a

3. 网络优化

确保Windows防火墙允许Podman和WSL的网络访问
检查代理设置（如果有）
使用有线网络而非Wi-Fi（如果可能）

总结

通过修改Podman的镜像配置源，可以显著提高镜像下载速度，提升开发效率。关键步骤包括：

进入WSL子系统：使用wsl命令
编辑配置文件：修改/etc/containers/registries.conf
配置镜像源：添加国内镜像源地址
重启服务：重启WSL或Podman机器
验证配置：测试镜像下载速度

建议根据实际网络情况选择合适的镜像源，并定期更新配置以获得最佳性能。对于企业环境，可以考虑搭建私有镜像仓库，进一步提高安全性和稳定性。

K3s部署Locust

发表于 2024-06-01 更新于 2026-05-09 分类于容器技术

参考

kubernetes Traefik ingress配置详解 - lvelvis - 博客园 (cnblogs.com)

一、核心定位

本文作为GitOps环境搭建系列的第二篇，聚焦Traefik反向代理的配置与优化。Traefik是K3s集群默认集成的云原生反向代理与负载均衡工具，具备动态配置、服务自动发现等核心特性，无需重启即可实时更新路由规则。

在GitOps环境中，Traefik扮演”流量入口网关”角色，为所有组件（Gitea、ArgoCD、Tekton、Harbor等）提供统一的HTTPS访问入口，实现域名路由、负载均衡、TLS终结等核心功能。通过Traefik的IngressRoute资源，可以灵活配置HTTP/HTTPS/TCP/UDP等多种协议的路由规则。

二、部署前置检查

部署前需验证K3s集群状态及Traefik基础运行情况：

# 1. 验证K3s集群状态
kubectl get nodes

# 2. 验证Traefik是否已运行（K3s默认集成）
kubectl get pods -n kube-system -l app=traefik

# 3. 查看Traefik Service
kubectl get svc -n kube-system traefik

# 4. 验证Helm可用性
helm version --short

# 5. 验证域名解析（替换为实际域名）
nslookup traefik.example.io
````

**前置条件检查清单：**

- [ ] K3s集群运行正常
- [ ] Traefik Pod处于Running状态
- [ ] 域名`traefik.example.io`已解析至K3s节点IP
- [ ] Helm工具可用
- [ ] 具备kube-system命名空间操作权限

## 三、启用Traefik Dashboard

K3s集群（版本≥1.21）默认集成Traefik，但未启用其Dashboard功能。需注意的是，直接修改`/var/lib/rancher/k3s/server/manifests/traefik.yaml`配置文件，会在K3s重启后被系统自动覆盖，因此推荐通过`HelmChartConfig`自定义配置的方式，安全稳定地启用Dashboard。

### 3.1 创建HelmChartConfig配置文件

在Master节点创建持久化配置：

```bash
# 创建HelmChartConfig配置文件
sudo cat > /var/lib/rancher/k3s/server/manifests/traefik-config.yaml << EOF
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    dashboard:
      enabled: true
      domain: traefik.example.io  # 统一使用example.io域名
    ports:
      traefik:
        expose: true
    logs:
      access:
        enabled: true
EOF

# 重启K3s使配置生效
sudo systemctl restart k3s

3.2 配置Service与IngressRoute

创建traefik-dashboard.yaml配置文件：

# traefik-dashboard.yaml
apiVersion: v1
kind: Service
metadata:
  name: traefik
  namespace: kube-system 
spec:
  allocateLoadBalancerNodePorts: true
  ports:
  - name: web
    nodePort: 80
    port: 80
    protocol: TCP
    targetPort: web
  - name: websecure
    nodePort: 443
    port: 443
    protocol: TCP
    targetPort: websecure
  selector:
    app.kubernetes.io/instance: traefik-kube-system
    app.kubernetes.io/name: traefik
  type: LoadBalancer

---

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard-web
  namespace: kube-system
spec:
  entryPoints:
    - web
  routes:
    - kind: Rule
      match: Host(`traefik.example.io`) && PathPrefix(`/dashboard`) || PathPrefix(`/api`)
      services:
        - name: api@internal
          kind: TraefikService

---

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard-websecure
  namespace: kube-system
spec:
  entryPoints:
    - websecure
  routes:
    - kind: Rule
      match: Host(`traefik.example.io`) && PathPrefix(`/dashboard`) || PathPrefix(`/api`)
      services:
        - name: api@internal
          kind: TraefikService
  tls:
    secretName: traefik-dashboard-tls

应用配置：

1	kubectl apply -f traefik-dashboard.yaml

注意：访问Dashboard时URL末尾必须添加/，正确格式为https://traefik.example.io/dashboard/。

四、配置IngressRoute实现服务代理

4.1 创建测试环境

1
2
3

# 创建测试应用
kubectl create deploy whoami --image=traefik/whoami --replicas=2
kubectl expose deploy whoami --port=80

4.2 HTTP路由配置

创建HTTP路由规则，通过指定路径访问服务：

# whoami-http-ingress-route.yaml
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: whoami-ingress-web
  namespace: default
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik.example.io`) && PathPrefix(`/whoami`)
      kind: Rule
      services:
        - name: whoami
          port: 80

4.3 HTTPS路由配置

生成自签名证书（测试环境）：

# 生成自签名证书
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=traefik.example.io" \
  -addext "subjectAltName=DNS:traefik.example.io"

# 创建TLS Secret
kubectl create secret tls whoami-tls --cert=tls.crt --key=tls.key

配置HTTPS路由：

# whoami-https-ingress-route.yaml
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: whoami-ingress-websecure
  namespace: default
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`traefik.example.io`) && PathPrefix(`/secure/whoami`)
      kind: Rule
      services:
        - name: whoami
          port: 80
  tls:
    secretName: whoami-tls

生产环境建议：使用cert-manager自动管理证书，详见基于K3s搭建GitOps4-证书管理。

4.4 TCP/UDP路由配置

Traefik支持代理MySQL、Redis等TCP/UDP服务，需通过IngressRouteTCP或IngressRouteUDP配置。

以Redis服务为例：

# redis-tcp-ingress-route.yaml
apiVersion: traefik.io/v1alpha1
kind: IngressRouteTCP
metadata:
  name: redis
  namespace: devops
spec:
  entryPoints:
    - redis  # 需在Traefik配置中启用redis入口点
  routes:
  - match: HostSNI(`*`)
    services:
    - name: redis
      port: 6379

TCP与HTTP路由差异：

TCP路由使用HostSNI('*')匹配，HTTP路由使用Host()匹配
TCP路由仅代理TCP协议，无法处理HTTP请求
同一入口点上，TCP路由优先级高于HTTP路由

五、验证部署结果

5.1 验证Traefik组件状态

# 查看Traefik Pod状态
kubectl get pods -n kube-system -l app=traefik

# 查看Traefik Service
kubectl get svc -n kube-system traefik

# 查看IngressRoute资源
kubectl get ingressroute -A

# 查看Traefik日志
kubectl logs -n kube-system -l app=traefik --tail=50

5.2 验证路由功能

# 测试HTTP访问
curl -v http://traefik.example.io/dashboard/
curl -v http://traefik.example.io/whoami

# 测试HTTPS访问（跳过证书验证）
curl -k -v https://traefik.example.io/dashboard/
curl -k -v https://traefik.example.io/secure/whoami

# 查看路由配置
kubectl describe ingressroute traefik-dashboard-websecure -n kube-system

5.3 清理测试资源

# 清理测试应用
kubectl delete deploy whoami
kubectl delete svc whoami

# 清理路由配置
kubectl delete ingressroute whoami-ingress-web whoami-ingress-websecure
kubectl delete secret whoami-tls

六、生产环境配置建议

6.1 启用访问日志

# 在HelmChartConfig中添加日志配置
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    logs:
      access:
        enabled: true
        format: json  # 使用JSON格式便于日志分析
        fields:
          general:
            defaultMode: keep
          headers:
            defaultMode: keep

6.2 配置中间件

Traefik中间件可用于实现路径重写、请求限流、认证等高级功能：

# 路径重写中间件示例
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: strip-prefix
  namespace: default
spec:
  stripPrefix:
    prefixes:
      - /api/v1

6.3 启用指标监控

# 启用Prometheus指标
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: traefik
  namespace: kube-system
spec:
  valuesContent: |-
    metrics:
      prometheus:
        enabled: true
        addEntryPointsLabels: true
        addServicesLabels: true

七、常见问题修复

问题现象	排查方向	修复方案
Dashboard访问404	路由配置/路径格式	确认访问URL以`/`结尾，检查IngressRoute配置
HTTPS证书警告	证书配置/TLS Secret	检查证书Secret是否存在，确认域名匹配
服务无法访问	服务发现/端口映射	检查Service selector是否匹配Pod标签
TCP路由不生效	入口点配置	确认Traefik已启用对应TCP入口点
配置被覆盖	HelmChartConfig位置	确认配置文件在`/var/lib/rancher/k3s/server/manifests/`目录

八、配置参考

所有Traefik配置文件和部署脚本请参考：
https://gitee.com/Chemmy/kube-template/tree/master/devops/traefik

该目录包含：

Traefik Dashboard配置
IngressRoute示例
中间件配置
生产环境优化配置
监控和日志配置

总结

本文完成了Traefik在K3s集群中的完整配置，包括Dashboard启用、HTTP/HTTPS路由配置、TCP/UDP服务代理等核心功能。Traefik作为GitOps环境的流量入口网关，为后续组件（Gitea、ArgoCD、Tekton、Harbor）提供了统一的访问入口和安全的路由能力。

配置完成后，建议通过测试应用验证各项功能正常。下一篇文章将配置CoreDNS内网域名解析，实现通过域名访问所有GitOps组件。

解决LibVLCSharp弹出Direct3d11窗体问题

发表于 2024-06-01 更新于 2026-05-09 分类于编程技术， DotNet

LibVLCSharp版本

1
2
3

<PackageReference Include="LibVLCSharp" version="3.6.6" />
<PackageReference Include="LibVLCSharp.WPF" version="3.6.6" />
<PackageReference Include="VideoLAN.LibVLC.Windows" version="3.0.16" />

现象播放RTSP视频流时在VideoView播放正常，但会弹出一个窗体同时播放，窗体名VLC (Direct3D11 output)

代码如下

public partial class MainWindow : Window
{
    private LibVLC m_libVLC;
    
    public MainWindow()
    {
        InitializeComponent();
        
        this.Loaded += MainWindow_Loaded;
        
        m_libVLC = new LibVLC();
    }
    
    private void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        VideoView.MediaPlayer = new LibVLCSharp.Shared.MediaPlayer(m_libVLC);
        VideoView.MediaPlayer.Play(new Media(m_libVLC, new Uri(uri)));
    }
}

故障原因

打断点调试发现，Loaded时间执行两次，第一次执行在VideoView播放正常，第二次执行弹出VLC (Direct3D11 output)窗

解决方法: 控制只初始化和播放一次

public partial class MainWindow : Window
{
    private LibVLC m_libVLC;
    
    public MainWindow()
    {
        InitializeComponent();
        
        this.Loaded += MainWindow_Loaded;
        
        m_libVLC = new LibVLC();
    }
    
    private void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        VideoView.MediaPlayer ??= new LibVLCSharp.Shared.MediaPlayer(m_libVLC)
        {
            Media = new Media(m_libVLC, new Uri(uri))
        };
        
        if (!VideoView.MediaPlayer.IsPlaying)
            VideoView.MediaPlayer.Play();
    }
}

K3s部署PostgreSQL

发表于 2024-04-28 更新于 2026-05-09 分类于容器技术

PostgreSQL作为一款高性能、开源的关系型数据库，在云原生场景中，常需与轻量级Kubernetes发行版K3s结合部署，以实现资源高效利用与灵活运维。本文将详细拆解基于K3s部署PostgreSQL的完整流程，涵盖存储配置、配置管理、服务暴露及部署编排等核心环节，助力开发者快速完成部署落地。

一、环境准备

部署前需确保K3s集群已正常运行，且kubectl工具已完成集群连接配置（可通过kubectl get nodes命令验证集群状态）。本文所有资源配置均部署在独立的postgres命名空间下，避免与其他应用资源冲突，需先执行以下命令创建该命名空间：

1	kubectl create namespace postgres

二、存储配置：PersistentVolume与PersistentVolumeClaim

PostgreSQL作为有状态应用，数据持久化是核心需求。本文提供两种存储配置方案，可根据集群规模（单节点/多节点）及实际存储需求灵活选择。

方案1：基于local-path存储类（单节点场景）

local-path是K3s默认集成的存储类，适用于单节点K3s集群，无需手动创建PersistentVolume（PV），仅需定义PersistentVolumeClaim（PVC），系统会自动创建PV并完成绑定。创建postgres-pvc-local-path.yaml配置文件，内容如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
  namespace: postgres
  labels:
    app: postgres
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 10Gi

该配置声明了10Gi的存储资源请求，访问模式为ReadWriteOnce（仅允许单个节点读写），完全适配单节点K3s的部署场景，配置简洁且无需额外运维。

方案2：基于hostPath的自定义存储类（多节点/自定义路径场景）

若需自定义存储路径，或集群为多节点架构，可手动创建PV并绑定PVC，实现更灵活的存储管理。创建postgres-pvc-host-path.yaml文件，包含PV与PVC的完整定义（修正原文中storge的拼写错误为storage）：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
  namespace: postgres
  labels:
    app: postgres
spec:
  storageClassName: postgres-persistent-storage
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteMany
  hostPath:
    path: /mnt/postgres/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
  labels:
    app: postgres
spec:
  storageClassName: postgres-persistent-storage
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

需提前在集群节点上创建/mnt/postgres/data目录，并确保目录权限正确（建议设置为777或匹配Pod运行用户权限）；访问模式ReadWriteMany支持多节点读写，可满足多节点K3s集群的部署需求。

执行以下命令创建对应存储资源：

# 方案1（单节点）
kubectl apply -f postgres-pvc-local-path.yaml
# 方案2（多节点/自定义路径）
kubectl apply -f postgres-pvc-host-path.yaml

三、配置管理：ConfigMap定义环境变量

PostgreSQL的核心初始化配置（如默认数据库名、管理员用户名、密码）可通过ConfigMap统一管理，便于后续配置修改与维护，无需重新构建镜像或重启Pod。创建postgres-config.yaml配置文件：

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-config
  namespace: postgres
  labels:
    app: postgres
data:
  POSTGRES_DB: postgres
  POSTGRES_USER: postgres
  POSTGRES_PASSWORD: postgres

本文为简化部署流程，使用ConfigMap存储密码；实际生产环境中，建议使用Secret存储敏感信息（如数据库密码），提升配置安全性。

执行以下命令创建ConfigMap资源：

1	kubectl apply -f postgres-config.yaml

四、服务暴露：Service与IngressRouteTCP

为实现PostgreSQL的可访问性，需根据访问场景（集群内/集群外）配置对应的服务暴露方式。K3s默认集成Traefik作为Ingress控制器，可通过Service实现集群内访问，通过IngressRouteTCP实现集群外访问。

1. ClusterIP类型Service（集群内访问）

创建postgres-service.yaml文件，定义ClusterIP类型的Service，监听PostgreSQL默认端口5432，实现集群内Pod间的访问：

apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: postgres
  labels:
    app: postgres
spec:
  ports:
  - port: 5432
    targetPort: 5432
    protocol: TCP
  selector:
    app: postgres
  type: ClusterIP

ClusterIP类型Service仅允许集群内Pod访问，集群内其他应用可通过服务域名postgres.postgres.svc.cluster.local:5432连接PostgreSQL数据库。

2. IngressRouteTCP（集群外访问）

若需从集群外访问PostgreSQL，可通过Traefik的IngressRouteTCP暴露TCP端口。创建postgres-ingress.yaml文件：

apiVersion: traefik.io/v1alpha1
kind: IngressRouteTCP
metadata:
  name: postgres-tcp
  namespace: postgres
  labels:
    app: postgres
spec:
  entryPoints:
    - postgres
  routes:
    - match: HostSNI(`*`)
      services:
        - name: postgres
          port: 5432

需先在Traefik控制器中配置postgres入口点（entryPoints），指定监听的主机端口（建议与PostgreSQL默认端口5432保持一致），否则IngressRouteTCP配置无法生效。

执行以下命令创建服务相关资源：

1 2	kubectl apply -f postgres-service.yaml kubectl apply -f postgres-ingress.yaml

五、部署编排：StatefulSet部署PostgreSQL

PostgreSQL作为有状态应用，推荐使用StatefulSet而非Deployment部署，可确保Pod拥有稳定的网络标识和持久化存储，避免因Pod重启导致数据丢失或网络地址变更。创建postgres-statefulset.yaml文件（修正原文“deployment.yaml”命名偏差，贴合StatefulSet资源类型）：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
  namespace: postgres
  labels:
    app: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  replicas: 1
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:16.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5432
        envFrom:
        - configMapRef:
            name: postgres-config
        volumeMounts:
        - name: postgredb
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgredb
        persistentVolumeClaim:
          claimName: postgres-pvc

使用postgres:16.3稳定版本镜像，通过envFrom批量加载ConfigMap中的环境变量，将PVC挂载到PostgreSQL的数据存储目录/var/lib/postgresql/data，确保数据持久化；镜像拉取策略设为IfNotPresent，避免重复拉取镜像，提升部署效率。

执行以下命令部署PostgreSQL：

1	kubectl apply -f postgres-statefulset.yaml

六、验证部署结果

部署完成后，需通过一系列命令验证各资源状态，确保PostgreSQL正常运行。

检查PVC绑定状态：

1	kubectl get pvc -n postgres

正常情况下，PVC的STATUS列显示为Bound，表示存储绑定成功。

检查StatefulSet与Pod运行状态：

1 2	kubectl get statefulset -n postgres kubectl get pods -n postgres

确保StatefulSet的READY列显示为1/1（副本数为1时），Pod的STATUS列显示为Running，无异常重启记录。

测试数据库连接：

# 进入PostgreSQL Pod内部
kubectl exec -it postgres-0 -n postgres -- bash
# 连接PostgreSQL数据库（使用ConfigMap中定义的用户名和数据库名）
psql -U postgres -d postgres

若能成功进入PostgreSQL命令行界面（显示postgres=#提示符），说明PostgreSQL部署成功且可正常使用。

总结

本文基于K3s原生资源（PVC/PV、ConfigMap、Service、StatefulSet），完成了PostgreSQL的全流程部署，覆盖了存储配置、配置管理、服务暴露、部署编排及结果验证等核心环节，流程清晰、可操作性强。在实际生产环境中，可根据业务需求灵活调整：如增加副本数实现高可用、使用Secret管理敏感信息、优化Ingress配置实现访问控制等，进一步提升部署的安全性与稳定性。

K3s部署MySQL

发表于 2024-04-26 更新于 2026-05-09 分类于容器技术

在K3s集群中部署MySQL，需结合Kubernetes资源编排特性，合理配置存储、网络、配置项等核心组件，确保数据库服务稳定、可访问且数据安全。本文将详细拆解基于K3s部署MySQL的完整流程，涵盖资源配置文件编写、部署操作及关键注意要点，助力开发者快速完成部署落地。

一、环境说明

本文基于K3s集群环境，通过Kubernetes各类核心资源对象（StatefulSet、Service、PVC/PV、ConfigMap、IngressRouteTCP），实现MySQL 5.7版本的规范化部署，重点保障数据持久化、集群内外网络可访问及配置灵活自定义。所有资源均部署在mysql命名空间下，需提前执行命令创建该命名空间：kubectl create namespace mysql。

二、核心资源配置与部署

1. 配置自定义参数：ConfigMap

MySQL的核心运行参数通过ConfigMap进行统一管理，便于后续参数调整、维护及复用。创建mysql-config.yaml配置文件，明确定义字符集、最大连接数、绑定地址等关键参数，具体内容如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
  namespace: mysql
  labels:
    app: mysql-config
data:
  mysqld.cnf: |
    [client]
    default-character-set=utf8mb4
    [mysql]
    default-character-set=utf8mb4
    [mysqld]
    character-set-server = utf8mb4
    collation-server = utf8mb4_unicode_ci
    init_connect='SET NAMES utf8mb4'
    skip-character-set-client-handshake = true
    max_connections=2000
    secure_file_priv=/var/lib/mysql
    datadir=/var/lib/mysql
    bind-address=0.0.0.0
    symbolic-links=0

该配置已做针对性优化：将字符集统一设置为utf8mb4，彻底解决中文乱码及特殊字符存储问题；绑定地址设为0.0.0.0，确保MySQL可被K3s集群内所有节点访问；调整最大连接数至2000，满足中高并发业务场景需求。配置文件编写完成后，执行以下命令部署ConfigMap：

1	kubectl apply -f mysql-config.yaml

2. 数据持久化：PVC/PV配置

MySQL作为关系型数据库，数据持久化是核心需求，需通过PVC（持久化卷声明）和PV（持久化卷）配置，避免Pod重建、重启后数据丢失。本文提供两种存储方案，可根据实际部署场景灵活选择。

方案1：基于local-path存储类（推荐）

K3s集群默认内置local-path存储类，无需手动创建PV，仅需创建PVC即可自动完成PV绑定，部署高效便捷。创建mysql-pvc-local-path.yaml文件，内容如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
  namespace: mysql
  labels:
    app: mysql
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 10Gi

执行部署命令，完成PVC创建：

1	kubectl apply -f mysql-pvc-local-path.yaml

方案2：基于hostPath的PV/PVC（自定义存储路径）

若需指定K3s节点本地具体路径作为MySQL数据存储位置，可手动创建PV和PVC。需注意，原始配置文件mysql-pvc-host-path.yaml中存在笔误（storge应为storage），修正后完整配置如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  namespace: mysql
  labels:
    app: mysql
spec:
  storageClassName: mysql-persistent-storage
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteMany
  hostPath:
    path: /var/lib/mysql/data

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
  namespace: mysql
  labels:
    app: mysql
spec:
  storageClassName: mysql-persistent-storage
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

执行部署命令，完成PV和PVC创建：

1	kubectl apply -f mysql-pvc-host-path.yaml

注意：hostPath存储方案仅适用于单节点K3s集群；多节点集群需使用NFS等共享存储方案，确保数据一致性和可访问性。

3. 部署MySQL实例：StatefulSet

采用StatefulSet部署MySQL实例，可保证Pod名称固定、存储挂载稳定，更适配数据库这类有状态应用的部署需求。创建mysql-deployment.yaml文件（实际为StatefulSet资源类型，命名仅为便于识别），具体配置如下：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: mysql
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - image: mysql:5.7
          name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: root
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
            - name: mysql-config
              mountPath: /etc/mysql/mysql.conf.d
      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
            claimName: mysql-pvc
        - name: mysql-config
          configMap:
            name: mysql-config

该配置核心说明：

镜像选用mysql:5.7稳定版本，通过环境变量MYSQL_ROOT_PASSWORD直接设置root用户密码为root（注：生产环境需使用Secret存储密码，避免明文暴露）；
将PVC挂载至MySQL默认数据目录/var/lib/mysql，确保数据持久化；将ConfigMap挂载至MySQL配置文件目录，覆盖默认配置，应用自定义参数；
暴露3306端口，为集群内访问提供基础。

执行部署命令，启动MySQL实例：

1	kubectl apply -f mysql-deployment.yaml

4. 集群内访问：Service配置

创建ClusterIP类型的Service，为MySQL实例提供稳定的集群内访问地址，避免因Pod IP变化导致访问失败。创建mysql-service.yaml文件，配置如下：

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: mysql
  labels:
    app: mysql
spec:
  ports:
    - name: tcp
      port: 3306
      protocol: TCP
      targetPort: mysql
  selector:
    app: mysql
  type: ClusterIP

部署完成后，K3s集群内其他Pod可通过固定域名mysql.mysql.svc.cluster.local:3306访问MySQL服务，无需关注具体Pod IP。执行部署命令：

1	kubectl apply -f mysql-service.yaml

5. 外部访问：IngressRouteTCP配置

若需从K3s集群外部访问MySQL服务，可结合K3s默认Ingress控制器（Traefik），配置IngressRouteTCP实现TCP流量转发。创建mysql-ingress.yaml文件，配置如下：

apiVersion: traefik.io/v1alpha1
kind: IngressRouteTCP
metadata:
  name: mysql-tcp
  namespace: mysql
spec:
  entryPoints:
    - mysql
  routes:
    - match: HostSNI(`*`)
      services:
        - name: mysql
          port: 3306

注意：需提前在Traefik中配置mysql入口点（entryPoints），并监听指定端口（如3306），确保外部流量可正常转发至MySQL Service，否则外部访问会失败。

执行部署命令，完成IngressRouteTCP配置：

1	kubectl apply -f mysql-ingress.yaml

三、部署验证

部署完成后，需通过一系列操作验证MySQL服务是否正常运行、配置是否生效，具体步骤如下：

检查所有相关资源状态，确认部署无异常： kubectl get all -n mysql kubectl get pvc,pv -n mysql kubectl get configmap -n mysql 若所有资源均处于Running、Bound等正常状态，说明部署基础无问题。
验证MySQL内部连接及配置生效情况： # 进入MySQL Pod内部 kubectl exec -it mysql-0 -n mysql -- mysql -uroot -proot # 执行SQL命令，验证字符集等配置是否生效 mysql> show variables like '%character%'; 若查询结果中字符集相关参数均为utf8mb4，说明配置已成功应用。
外部访问验证（若已配置IngressRouteTCP）： mysql -h <K3s节点IP> -P <Traefik监听端口> -uroot -proot 若能成功登录MySQL，说明外部访问配置生效。

四、注意事项

生产环境安全规范：MYSQL_ROOT_PASSWORD严禁明文写在配置文件中，需通过Kubernetes的Secret资源存储，提升密码安全性。
多节点集群存储建议：多节点K3s集群中，应使用Longhorn等分布式存储替代hostPath，避免单节点故障导致数据丢失，保障数据库高可用。
架构扩展说明：本文部署的为MySQL单实例，若需实现主从复制、读写分离架构，需在ConfigMap中额外配置主从复制相关参数，并调整StatefulSet配置。
数据备份要求：需定期备份PVC挂载目录中的数据，可通过定时任务脚本或专业备份工具实现，防止存储故障、误操作导致数据丢失。
配置更新生效：修改ConfigMap中的MySQL参数后，需重启MySQL StatefulSet使配置生效，执行命令：kubectl rollout restart statefulset mysql -n mysql。

通过以上步骤，可在K3s集群中快速、规范地部署一个配置可定制、数据可持久化、网络可访问的MySQL实例，满足开发测试或生产环境的基础数据库使用需求，同时为后续架构优化、性能调优提供基础。