PC's Blog
0%

发表于 分类于
本文字数： 5.4k 阅读时长 ≈ 5 分钟

前言

本文介绍如何在 Rocky Linux 9.5 上使用 ChartMuseum 搭建一个私有的 Helm Chart 仓库，并启用 HTTPS 和 Basic 认证以提高安全性

环境准备

  • 一台Rocky Linux 9.5 x86_64, 作为Helm Repo, 安装Docker, 域名: myhelmrepo.com
  • Kubernetes 集群 v1.28.x, Helm v3.16.0

1. 安装并启动 ChartMuseum

(1) 启动 ChartMuseum 容器

1
2
3
4
5
6
7
8
9
docker run -d \
  --name private-helm-repo \
  -p 8080:8080 \
  --restart=always \
  -e STORAGE=local \
  -e STORAGE_LOCAL_ROOTDIR=/charts \
  -v /charts:/charts \
  --user root \
  swr.cn-north-4.myhuaweicloud.com/ddn-k8s/ghcr.io/helm/chartmuseum:v0.16.2
阅读全文 »

发表于 分类于
本文字数： 38k 阅读时长 ≈ 34 分钟

集群规划

8台Linux虚拟机, Rocky Linux 9.5 x86_64

  • 主节点(3个): 2CPU, 3G内存, 20G硬盘
  • 工作节点(2个): 2CPU, 3G内存, 20G硬盘
  • LB(2个): 1CPU, 2G内存, 10G硬盘

各个机器IP、主机名、角色如下

1
2
3
4
5
6
7
8
9
10
11
192.168.52.91 k8s-master1 主节点1
192.168.52.92 k8s-master2 主节点2
192.168.52.93 k8s-master3 主节点3

192.168.52.101 k8s-slave1 从节点1
192.168.52.102 k8s-slave2 从节点2
192.168.52.103 k8s-slave3 从节点3

192.168.52.80 k8s-lb1 HAProxy
192.168.52.81 k8s-lb2 HAProxy
192.168.52.88 www.petertest.com Virtual IP(VIP)

以下分步搭建kubernetes集群

  • 搭建一主一从集群
  • 添加负载均衡(HAProxy)
  • 搭建三主三从集群(三主三从两LB)
阅读全文 »

发表于 分类于
本文字数： 5.5k 阅读时长 ≈ 5 分钟

什么是Helm? Helm解决了哪些问题?

Helm是Kubernetes的包管理工具，类似于Linux中的apt或yum. Helm通过模板化和版本控制等机制, 帮助用户快速发现、共享和使用Kubernetes应用

在Helm出现之前，部署Kubernetes应用存在以下问题:
1. YAML配置复杂，部署和管理Kubernetes应用不方便

  • 问题：需要编写大量YAML文件定义Kubernetes资源。 随着项目规模增长, 维护这些配置文件变得困难, 尤其是在多环境部署时
  • Helm解决方案: 通过Helm模板功能，开发者可以创建一个Chart, 包含所有必要的Kubernetes资源定义, 并使用变量代替硬编码值

2. 更新或回滚到特定版本较为困难

  • 问题：缺乏版本控制功能，难以更新或回滚到指定版本。如果直接修改线上 YAML 文件，可能导致问题且难以恢复到稳定状态
  • Helm解决方案: Helm 通过Release概念支持版本控制，每次部署或更新应用时都会创建一个新的Release. 如果新版本出现问题, 可以通过helm rollback快速回滚到之前的稳定版本

3. 难以共享或复用k8s配置, 不利于多团队协作

  • 问题：在一个团队内部，不同项目可能有相似需求（如都需要部署同一套系统）。然而，由于缺少有效的共享机制，每个项目需要从头开始配置，浪费了大量时间精力
  • Helm解决方案: Helm Charts 可以通过仓库共享，每个人可以从仓库中下载官方或其他团队成员发布的Charts，也可以上传自己的Charts，实现了Kubernetes配置的共享和复用

快速上手Helm

Helm的三个基本概念

  • Chart, 一个Helm安装包，包含了运行一个应用所需要的镜像、依赖和资源定义等
  • Release, 在Kubernetes集群上运行的一个Chart实例
  • Repository, 发布和存储Chart的仓库
阅读全文 »

发表于 分类于
本文字数： 3.1k 阅读时长 ≈ 3 分钟

背景

早期，客户的On-premises网关设备（基于CentOS 7）采用增量升级方案进行固件更新。 这种方案存在两个主要问题：

  • 一旦升级过程中出现问题，客户只能重新安装系统，严重影响用户体验。
  • 部分客户未开启自动升级功能，为了支持所有客户的升级需求，升级包必须保存从初始版本到最新版本的所有增量文件。随着版本迭代，升级包变得越来越大，难以维护。

为了解决这些问题，需要为客户网关设备设计一种新的升级方案。

A/B系统升级简介

A/B分区升级机制允许设备在不同分区上安装和运行系统的不同版本，从而实现无缝更新。这种方法常用于移动设备、物联网设备以及其他需要高可用性和减少停机时间的场景中。例如，Android系统、Chrome OS及许多嵌入式和IoT设备都采用了A/B系统升级方法。其主要优点包括：

  • 无缝更新：可以在系统运行期间进行更新，唯一的宕机发生在设备重启到更新后分区时。
  • 故障恢复：如果升级失败，设备仍可工作在旧分区，并允许客户继续尝试升级。
阅读全文 »

发表于 分类于
本文字数： 5.2k 阅读时长 ≈ 5 分钟

前言

docker0是Docker默认网络的核心组件, 通过虚拟网桥和NAT技术, 实现了容器间的通信以及容器与外部网络的交互。然而, docker0网段是固定的(通常是172.17.0.0/16), 为了更灵活地管理容器网络，Docker支持创建自定义网桥，允许用户指定网段。
例如, 在我以前做的一个单板仿真项目里, 每个容器用来模拟一块板, 单板的IP需要设置为172.16.0.0/16, 和docker0网段不一致。 由于这个项目部署在每个开发的工作机上, 我们决定不直接修改docker0配置, 选择了创建自定义网桥这种更灵活的方式。

Docker网桥的工作机制

Docker在主机上创建一个虚拟网桥(docker0), 每当启动一个容器，Docker会自动创建一对虚拟网卡(veth pair), 其中一端放在容器内部作为它的网络接口, 另一端则连接到主机上的这个虚拟网桥。 通过这种方式，容器之间可以通过网桥直接通信，数据包在网桥内转发，不经过主机的物理网络接口。
如果容器访问的是外部网络, 容器发出的数据包会先通过虚拟网桥到达主机, 然后主机通过NAT将容器的私有IP替换为自己的公网IP，从而让数据包能够顺利发送到外部网络。

阅读全文 »

发表于 分类于
本文字数： 6.4k 阅读时长 ≈ 6 分钟

前言

在我们的业务场景中，客户终端需要访问部署在云端的各种服务，这些云端服务分布在不同的域名下。 例如, 一个典型的客户需要访问数十个甚至上百个不同的FQDN来满足他的业务需求
然而, 许多客户的防火墙不支持通配符的FQDN白名单配置, 这意味者他们必须手动配置每个具体的FQDN，这种配置非常麻烦，而且一旦配置错误会导致网络不通，严重影响用户体验, 增加运维负担
为了解决这个问题，我设计了一个基于Stunnel的加密通信方案, 以简化客户的防火墙配置:

  • 我们在客户的网关设备上部署了Stunnel，用于将Squid代理的所有HTTP流量进行TLS加密
  • Stunnel作为透明加密层，接收来自Squid的流量，并将其封装到TLS隧道中，将加密后流量发送给云端的一个Cloud Proxy.
  • Cloud Proxy是一个HTTPS代理, 负责解密网关设备传来的TLS流量，将解密后的请求转发到真正的后端服务

这种方案下，客户只需在防火墙配置Cloud Proxy这一个FQDN即可，无需逐一配置所有目标服务的FQDN，这个方案大幅简化了客户的防火墙配置，同时有效减少了网络不通问题

Stunnel是什么, 被设计用来解决什么问题

Stunnel是一款开源软件，其主要功能是为应用程序或服务提供TLS/SSL加密支持。 它的设计初衷是为了增强那些本身不支持加密功能的传统应用程序或服务的安全性
通过Stunnel, 可以在严格的防火墙规则下实现安全的加密通信，同时有效绕过可能存在的网络访问限制。

阅读全文 »

发表于 分类于
本文字数： 8.1k 阅读时长 ≈ 7 分钟

Microk8s Ingress是什么

Ingress是k8s的一种资源对象，用于管理外部对集群内服务的访问, 它通过提供一个统一的入口点，将外部流量路由到集群内部的不同服务。

Microk8s Ingress用于解决什么问题

k8s集群中服务默认只能在集群内访问。 如果需要从外部访问服务，通常需要使用NodePort或LoadBalancer类型服务，这两个服务都存在一些问题

  • NodePort会占用节点端口，可能导致端口冲突
  • LoadBalancer需要云提供商支持, 不适合本地环境
  • Ingress提供一种灵活的方式暴露服务，允许通过域名或路径规则将流量路由到不同的服务

Microk8s Ingress基本原理

  • Microk8s内置了一个Nginx的Ingress Controller, 负责监听k8s中的Ingress资源，当检测到Ingress资源更新时, 动态更新Nginx配置文件
  • 外部流量先到达Nginx, 再基于域名和URL将请求转发到Service, Service再将流量分发到Pod
阅读全文 »

发表于 分类于
本文字数： 1.5k 阅读时长 ≈ 1 分钟

前言

在Linux双系统升级过程中, 需要先备份新系统的所有文件得到升级包, 然后在需要升级的机器上解压升级包, 完成升级. tar是Linux系统最常用的备份工具之一。
然而, 在这种跨系统的备份和迁移中, 如果没有正确地处理文件所有者信息, 就会导致权限混乱, 升级后出现一些严重问题, 例如用户无法登录。

我在实际项目中遇到了这个问题。 以下说明为什么使用tar备份Linux系统时需要添加--numeric-owner参数

tar的--numeric-owner参数是什么

--numeric-owner是tar的一个选项, 用于在打包或解包时, 保留文件的UID和GID, 而不是直接映射当前系统的用户名称和组名称

为什么需要--numeric-owner参数

因为在跨系统迁移时，源系统和目标系统的用户配置可能是不一致的，例如：

  • 目标系统有一个用户alice(UID=1002), 源系统虽然也有用户alice, 但UID=1000
  • 这种情况很常见, 比如说目标系统和原系统的OS不一致, 或者在目标系统上新增了一些用户, 造成这种不一致
  • 如果备份时没有使用--numeric-owner, 源系统解压了tar包后得到的文件UID是1000; 升级到目标系统后, alice(UID=1002)并不是UID=1000的文件所有者, 就会出现权限错误的问题

演示案例

以下通过演示, 说明备份系统时忽略--numeric-owner时存在的问题

阅读全文 »

发表于 分类于
本文字数： 1.8k 阅读时长 ≈ 2 分钟

背景

我们的客户有一些本地部署的网关设备(CentOS 7)需要做固件升级。 原有的单系统分区架构缺乏有效的回滚机制, 升级遇到故障后无法回滚, 导致服务中断, 用户体验差

目标

设计一种解决方案, 自动将客户的网关设备从单系统分区平滑升级到双系统，同时保证用户配置(IP, DNS, 登录口令)不丢失
整个升级过程对客户完全透明, 无需客户进行额外操作(比如添加磁盘, 创建新机器)

方案

设计如下方案:

方案 描述 优点 缺点
定制initramfs 通过定制initramfs进入紧急模式，预先加载升级包和配置文件到内存，再重建磁盘分区 用户无感知, 且备份了旧的配置 内存空间有限, 升级包+解压后系统文件需小于内存
安装ISO 下载并安装目标系统ISO 不需要单独出一个升级包 客户的配置很难同步, 升级后需要用户做一些手动配置
阅读全文 »