我爱西红柿 已知的已知，已知的未知，未知的未知 2025-06-15T13:45:59.000Z http://yoursite.com/ 我爱西红柿 Hexo Vllm学习-部署使用 http://yoursite.com/2025/06/15/vllm-1/ 2025-06-15T13:45:59.000Z 2025-06-15T13:45:59.000Z 概述

VLLM（Vectorized Large Language Model Inference）是由UC Berkeley的系统研究团队开发，专注于优化大模型的推理速度框架，核心亮点在于通过PagedAttention 注意力算法以提高服务的吞吐量。
核心原理是能够将kv-cache动态分配在不连续的空间，提高整体显存利用率和并发数。

架构参考：
https://docs.vllm.ai/en/latest/design/arch_overview.html

安装 Vllm

环境配置

使用VLLM部署Qwen3 0.6B
参考Qwen文档
https://qwen.readthedocs.io/zh-cn/latest/deployment/vllm.html

硬件配置
CPU：AMD-5900X
内存：128G
显卡：RTX-3060-12G

软件：
vllm：0.9.1
Python：3.12.7
Models：Qwen3-0.6B

部署vllm 0.9.1版本，建议Python: 3.9 – 3.12版本，cuda版本12.8

参考Nvidia官方手册安装cuda

1
https://developer.nvidia.com/cuda-12-8-0-download-archive?target_os=Linux&target_arch=x86_64&Distribution=Ubuntu&target_version=22.04&target_type=deb_local

安装miniconda

1
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

运行安装脚本

1
bash Miniconda3-latest-Linux-x86_64.sh
  • 按提示按 ​Enter​ 阅读协议 → 输入 yes 同意
  • 设置安装路径（默认 ~/miniconda3 即可）
  • 提示 ​**Do you wish to initialize Miniconda3?**​ 选 yes

安装完成后配置bash
在/root/.bashrc添加PATH目录

1
export PATH=/root/miniconda3/bin:$PATH
1
sorce /root/.bashrc

验证

1
2
conda --version
conda 25.3.1

创建vllm部署的Python环境

1
2
conda create -n vllm python=3.12.7 
conda activate vllm
1
2
3
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main
conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
conda config --set show_channel_urls yes

安装pytorch
因为当前cuda12.2对应的torch版本还没有进入稳定版所以这里用的nightly路径。

1
pip install --pre torch==2.7.0.dev20250310+cu128 --index-url https://download.pytorch.org/whl/nightly/cu128

安装vllm引擎

1
pip install vllm==0.9.0.1

测试

1
2
3
4
5
6
7
8
 python
Python 3.12.7 | packaged by Anaconda, Inc. | (main, Oct  4 2024, 13:27:36) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> print(torch.__version__) 
2.7.0.dev20250310+cu128
>>> print(torch.cuda.is_available()) 
True

验证vllm版本

1
2
3
4
5
6
7
vllm --version

INFO 06-02 14:34:37 [__init__.py:243] Automatically detected platform cuda.
INFO 06-02 14:34:39 [__init__.py:31] Available plugins for group vllm.general_plugins:
INFO 06-02 14:34:39 [__init__.py:33] - lora_filesystem_resolver -> vllm.plugins.lora_resolvers.filesystem_resolver:register_filesystem_resolver
INFO 06-02 14:34:39 [__init__.py:36] All plugins in this group will be loaded. Set `VLLM_PLUGINS` to control which plugins to load.
0.9.0.1

下载模型
指定下载路径

1
mkdir -p /root/models/Qwen/Qwen3

从modelscope下载比huggingface要快一些
先安装modelscope

1
pip install modelscope

下载模型

1
modelscope download --model Qwen/Qwen3-0.6B --local_dir /root/models/Qwen/Qwen3

通过vllm加载启动模型
对外暴露的方式有两种LLM Class和OpenAI-Compatible API Server这里使用OpenAI方式对外暴露

1
2
CUDA_VISIBLE_DEVICES=0  python3 -m vllm.entrypoints.openai.api_server --model /root/models/Qwen/Qwen3 --served-model-name=Qwen3-0.6B --dtype=bfloat16 --trust-remote-code --max-model-len=1024 --tensor-parallel-size=1 --gpu-memory-utilization=0.85 --enable-reasoning --reasoning-parser deepseek_r1 --port 8000 --api-key 123456

参数作用
以下是转换后的参数说明表格（Markdown格式）：

参数作用值说明引用来源
--model /data/models/Qwen/Qwen3指定模型路径本地存储的 Qwen 模型目录，需提前下载（如通过 modelscope download）
--served-model-name=Qwen3-0.6B设置 API 中模型名称客户端调用时使用的标识符（如 model="Qwen3-0.6B"）
--dtype=bfloat16指定计算精度bfloat16 减少显存占用，适合低显存 GPU（如 RTX 2080Ti）
--trust-remote-code允许加载自定义代码用于支持非标准模型架构（如 Qwen 的特殊 tokenizer）
--max-model-len=1024最大上下文长度限制单次请求的 token 数量（值越大，显存需求越高）
--tensor-parallel-size=1张量并行大小1 表示单 GPU 运行；多卡需设为 GPU 数量（如 --tensor-parallel-size=4）
--gpu-memory-utilization=0.85GPU 显存利用率预分配 85% 显存给模型和 KV 缓存，避免 OOM（默认 0.9）
--enable-reasoning --reasoning-parser deepseek_r1启用推理功能使用 DeepSeek 的解析器增强逻辑推理能力（需 vLLM ≥0.7.3）
--port 8000服务监听端口API 通过 http://<IP>:8801/v1 提供（需防火墙放行）
--api-key 123456设置 API 认证密钥客户端需在 Header 中添加 Authorization: Bearer 123456

补充说明：

  1. 模型路径格式
    • 支持本地路径（如 /data/models/Qwen/Qwen3）或 Hugging Face 模型 ID（如 Qwen/Qwen3-0.6B）。
  2. 显存优化
    • bfloat16 在低显存 GPU 上可减少约 30% 显存占用，但可能损失少量精度。
  3. 推理功能扩展
    • deepseek_r1 解析器需配合 vLLM ≥0.7.3 使用，支持逻辑推理任务的分步解析。
  4. 安全认证
    • --api-key 强制客户端通过 Authorization: Bearer 标头认证，防止未授权访问。

注：参数值中的路径、端口和密钥需根据实际环境调整。

运行成功后可以通过命令行看见

通过curl命令访问

1
2
3
4
5
6
7
8
9
curl http://localhost:8000/v1/chat/completions     -H "Content-Type: application/json"     -H "Authorization: Bearer 123456"     -d '{
        "model": "Qwen3-0.6B",
        "messages": [
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": "你是谁？"}
        ]
    }'
{"id":"chatcmpl-84534513a50f43abaa7a36e047f780a6","object":"chat.completion","created":1748878398,"model":"Qwen3-0.6B","choices":[{"index":0,"message":{"role":"assistant","reasoning_content":"\n好的，用户问我是谁。作为AI助手，我需要以合适的方式回答。首先，我应该确认用户的问题，然后提供基本信息。同时，要保持礼貌和专业的形象，避免使用可能引起误解的措辞。需要确保回答简洁明了，让用户感到被理解和支持。最后，检查是否有需要补充的信息，以提供更全面的回答。\n","content":"\n\n我是AI助手，可以帮您解答问题。如果您有任何疑问或需要帮助，请随时告诉我！","tool_calls":[]},"logprobs":null,"finish_reason":"stop","stop_reason":null}],"usage":{"prompt_tokens":22,"total_tokens":122,"completion_tokens":100,"prompt_tokens_details":null},"prompt_logprobs":null,"kv_transfer_params":null}(base)

在server端也可以看见输出的token的速度

1
2
INFO 06-02 15:13:40 [async_llm.py:261] Added request chatcmpl-0d62a87c6c2d4146927d7e704b11ffc7.
INFO 06-02 15:13:40 [loggers.py:116] Engine 000: Avg prompt throughput: 2.4 tokens/s, Avg generation throughput: 1.2 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.1%, Prefix cache hit rate: 0.0%

也可以通过Open WebUI或Cherry Studio配置访问

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h3><p>VLLM（Vectorized Large Language Model Inference）是由UC Berkeley的系统研究团队开发， GPU算力理解和规划 http://yoursite.com/2024/08/09/gpu_power/ 2024-08-09T13:45:59.000Z 2024-08-09T13:45:59.000Z 概述

做AI训练和推理场景中，主要看GPU的FLOPS（每秒浮点运算次数）衡量集群的算力能力单位为PFLOPS，也可以简称为P也上目前很多在建的智算中心通常会说新建的这个算力中心提供的算力上多少P，单卡用TFLOPS（Tera flops 每秒1万亿次浮点运算）

一个MFLOPS（megaFLOPS）等于10^6 FLOPS；
一个GFLOPS（gigaFLOPS）等于10^9 FLOPS；
一个TFLOPS（teraFLOPS）等于10^12 FLOPS；
一个PFLOPS（petaFLOPS）等于10^15 FLOPS；
一个EFLOPS（exaFLOPS）等于10^18 FLOPS。

以H100为例，可以看到在不同类型GPU卡下的性能指标

SXM对应PCIE除了在显存带宽上存在差距，在不同精度下的性能也存在差异，所以这也是需要注意的在同型号卡不同接口类型存在的性能差异。
*表示采用稀疏技术

精度单位

在上图中可以看见存在FP64、FP32、TF32、FP16、INT8等这些精度单位，不同精度对应的模型训练效果占用存储空间和训练时间都会存在不同。
图片对应的精度带用Tensor Core的意思是支持专用硬件Tensor Core进行运算加速和混合精度训练的。

Tensor Core有两大优势：
优势一：性能增强
Tensor Core是NVIDIA在Volta架构引入的当时Tensor Core只为FP16进行优化，在Hopper架构 Tensor Core扩展了 TF32、FP64、FP16 和 INT8 精度，将性能提升3倍。

优势二：实现混合精度

通过Tensor Core可以实现混合精度将累加和累乘混合一起，比如使用半精度来加速矩阵乘法，使用单精度或双精度数据来修正结果，对应的可参考：
https://blog.csdn.net/bestpasu/article/details/134098651

FP64：双精度浮点数，占用64位（8字节）存储空间，主要用于大规模科学计算、工程计算等需要高精度计算的场景。
FP32：单精度浮点数，占用32位（4字节）存储空间
TF32 ：英伟达提出的代替FP32的单精度浮点格式，占用19位，指数位数值范围与FP32一样都是8位
BFLOAT16：用于半精度矩阵乘法计算的浮点数格式，占用16位存储空间，相对于FP16在保持存储空间相同的情况下能够提高运算精度和效率。
FP16：半精度浮点数占用16位（2字节）存储空间，通常用于模型训练过程中参数和梯度计算。
FP8：8位（1字节）存储空间，通常用于训练和推理场景，相比INT8， FP8 有更宽的动态范围， 更能精准捕获 LLM 中参数的数值分布
INT8 ：8位整数，通常用于模型训练完成后进行量化，从高精度浮点数，转换为低精度整型数，主要用于减少模型的大小和计算复杂性，同时尽可能减少精度损失的一种优化手段。

根据英伟达官网的表述，AI训练场景为缩短训练时间，主要使用BF16、FP8、TF32 和FP16；AI推理厂家为在低延迟下实现高吞吐量，主要使用TF32、BF16、FP16、FP8 和INT8；HPC（高性能计算）为实现在所需的高准确性下进行科学计算的功能，主要使用FP64。
（来自韭研公社APP）

稀疏计算和稠密计算

稀疏算力是指计算过程中，数据存储和传输中存在大量空缺或零值的计算方式。在稀疏算力中，数据通常以矩阵的形式存在，其中大部分元素为0。稀疏算力在处理大规模稀疏数据时具有很高的效率。

稠密算力是指计算过程中，数据存储和传输中不存在大量空缺或零值的计算方式。在稠密算力中，数据通常以矩阵的形式存在，其中大部分元素不为0。稠密算力在处理大规模稠密数据时具有很高的效率。

应用场景：

稀疏算力：稀疏算力在图像处理、信号处理、推荐系统等领域具有广泛的应用。

稠密算力：稠密算力在科学计算、机器学习、深度学习、智驾等领域具有广泛的应用。

算力规划计算

GPGPU卡数规划

所需GPU卡数量 = 总算力需求 / 单卡算力

以1000P算力需求为例，使用H100-SXM机型，计算对应的卡数

通常用FP16精度为例，H100，一张H100，BF16稀疏算力为1979TF，对应1.979/1000≈1.9P，8卡对应约为16P。
1000/16=63台，考虑到设计的便捷性，通常以64台作为推荐数量，对应的稠密算力，性能减半，则对应64*2=128台。

稠密算力大约等于稀疏算力的一半,所以说H100，一卡对应1p通常是说稠密算力。

所需GPU卡数量：稀疏算力：648=512块卡。稠密算力对应：1288=1024卡。

根据模型参数量规划算力

训练场景：
总算力=6 * token数 * 模型参数

注：
6是训练过程中前向传播、反向传播两个步骤，共计 2 次浮点运算。因此对于每个 token、每个模型参数，需要进行 3 × 2 flops = 6 次浮点运算

这是一个经验公式，表示对于每一个 token，进行一次完整的前向和反向传播大约需要 6 倍于模型参数数量的浮点运算量。

以LLama3 65B，1.4T数据量为例，计算H100 SXM需要的卡数和耗时，Llama属于 采用的是稠密（Dense）模型，65B的参数都激活了。非MoE模型，MoE模型需要额外考虑激活的参数量。

总算力需求：61.4T65B=5.46*10^23 FLOPS

以H100为例BF16稀疏计算对应1.9PFLOPS，稠密计算约为1PFLOPS，GPU实际利用率按百分之50计算，约0.5PFLOPS，假设使用2048卡规模

20480.5≈1024PFLOPS，PFLOPS换算FLOPS需要10^15

耗时= (5.4610^23)/(102410^15)≈7天

使用A100话单卡BF16 Tensor Core的算力为312 TFLOPS，2048张卡吞吐约为319P

耗时= 5.4610^23)/(31910^15)≈21天

另外对于大模型需要进行分布式训练还需要考虑卡间通信带宽

显存需求计算

推理场景显存（全参微调）

推理显存需求=模型参数显存占用+KV Cache显存占用

Llama3-7B为例

data typebytes per parameter
fp324 bytes
fp162 bytes
bf162 bytes
int81 bytes
int40.5 bytes

模型参数显存：

7b参数对应fp16需要的显存为
2*7b=14G

注：2为fp16对应的bytes

KV Cache占用显存
模型推理过程中，模型一次生成一个token，然后使用之前生成的token作为输入来预测下一个token。
每次生成新的token时，模型需要重新计算新的Q、K、V，并基于它们计算Attention权重。然而，之前生成的K、V在当前解码过程中是可以重复利用的，为了加快推理速度，可以将之前计算好的K、V存储在缓存中，这就是KV Cache，它们存储在GPU显存中，从而节省计算时间。

memory=BatchSizeSeqLengthhiddensizelayers2*dtype
如LLama3-7b

  1. Hidden Size (隐藏层大小)：

    •4096：LLaMA 7B 的隐藏层大小为 4096，这表示每个 token 通过 transformer 层时的向量维度。

  2. Sequence Length (序列长度)：

    •2048 tokens：默认的最大序列长度为 2048 tokens。这是模型在一次前向传播中能够处理的最大 token 数。

  3. Batch Size (批量大小)：

    •Batch Size 是可调参数，根据可用的显存和任务需求来选择。在训练或推理时，批量大小可以不同。常见批量大小为 1、8、16 等，但具体值取决于显存和硬件资源。

  4. Number of Layers (层数)：

    •32 层：LLaMA 7B 模型有 32 层 transformer 层，每一层负责进行一轮 token 的上下文理解。

memory=120484096322*2≈1G

这个与batchsize大小有关，这里设置的1，也与用户并发有关，还有输入输出的序列长度，只是做个参考

参考：https://mp.weixin.qq.com/s/7p-UMOv075OHp0dF5M63hw

实际推理侧落地也会使用MQA和GQA技术进行优化

实际对应的模型都会有对应的性能测试报告，在对应的精度情况下显存占用情况和如Qwen的
https://qwen.readthedocs.io/en/latest/benchmark/speed_benchmark.html

快速计算方法：
8bit量化模型：参数量1B 占用 1G 显存以上。
比如：
8bit量化 7B模型，显存占用 7G 以上
4bit量化 7B模型，显存占用 3.5G 以上
float16 7B模型，显存占用 14G 以上

训练场景显存（全参数训练）

完整的训练当前都是采用混合精度训练方法，显存需求与以下参数有关

1、模型参数：模型本身的占用
2、梯度参数：训练过程中梯度更新
3、优化器参数：使用不同优化器不一样，通常以Adam为例
4、激活值占用：用于存储前向计算时的激活值，模型的每层都会产生中间激活值，这些激活值在反向传播时会被用来计算梯度，因此需要在内存中保存，激活值和batch_size以及seq_length相关，实际训练的时候激活值对显存的占用会很大。注：激活值（中间计算结果）是以 float32（32位浮点数）格式存储的，每个浮点数占用 4字节。

其中模型参数、梯度参数、优化器参数为静态占用，激活值参数为动态占用，先不考虑

N为模型参数量比如LLAMA3-7B

1、模型参数：全精度训练（FP32）的权重需要 4 * N 字节显存。混合精度训练需要 6N 字节，因为 FP16 和 FP32 的权重要各存一份。

2、梯度参数：占用 4N 字节，因为梯度始终以 FP32 精度保存。

3、优化器参数。取决于优化器的类型。以常用的 Adam 优化器为例，训练过程中需要分别存梯度和梯度平方的移动平均，对每个参数存2个状态，因此需要占用 8N 字节显存。

4、激活值显存占用：显存大致是 batch size x 层数 x 序列长度 x每层输出维度 x 4 字节。

假设：batch size 为 32，模型为12层，输入序列长度为 1024，模型的每层输出维度为 4096。

占用显存为3212102440964=6GB

在混合精度训练时，以上三项总共需要 6N + 4N + 8N = 18N 字节，以 7B 模型为例，约为 126G。
加上激活值显存占用6GB=132G

实际在训练中，会使用多卡并行的分布式训练使用ZeRO技术进行显存优化，现在也集成到DeepSpeed库中了。另外当前也很多场景也都是使用PEFT（微调技术）进行部分参数训练比如使用Lora和QLoRA进行训练。这个可以在对应的微调框架内如LLaMA-Factory（https://github.com/hiyouga/LLaMA-Factory）Unsloth查看

https://llm-system-requirements.streamlit.app/

https://github.com/hiyouga/LLaMA-Factory

总结：

也可以使用huggingface官方的计算工具
https://huggingface.co/spaces/hf-accelerate/model-memory-usage

参考链接：
https://qwen.readthedocs.io/en/latest/benchmark/speed_benchmark.html

https://mp.weixin.qq.com/s/7p-UMOv075OHp0dF5M63hw

https://github.com/hiyouga/LLaMA-Factory
https://gpumap.com/moxing/38887.html

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h3><p>做AI训练和推理场景中，主要看GPU的FLOPS（每秒浮点运算次数）衡量集群的算力能力单位为PFLOPS，也可以简称为P也上目前很多在建的智 AI学习笔记2（微调模型) http://yoursite.com/2024/07/09/ai_sft/ 2024-07-09T13:45:59.000Z 2024-07-09T13:45:59.000Z 什么是微调


大模型阶段
预训练：在大量无标签数据上，通过算法进行无监督训练，得到一个具有通用知识能力的模型，比如OpenAI训练GPT3使用45TB数据量。语言数据：涵盖“英语、中文、法语、德语、西班牙语、意大利语、荷兰语、葡萄牙语等多种语言。其中英语数据占据了最大的比例，大约占据了总数据量的60%。”

主题数据：涵盖了各种不同的领域，包括科技、金融、医疗、教育、法律、体育、政治等。其中科技领域的数据占据了最大的比例

数据类型：多模能需要包括图片、音频、视频等。这些数据被用来训练模型的多媒体处理能力

这种场景下训练出来的模型通用能力强

微调：在原有预训练的基础上，使用特定的标记数据进行有监督式学习SFT（Supervised Fine Tuning）提高模型在特定专业领域能力。

常见微调方案

微调方法

1、全参数微调 (Full Fine-Tuning)
全参数微调是指对模型的所有参数进行微调。这种方法通常效果最好，但也最耗资源，因为需要对整个模型进行反向传播和梯度更新。

优点：能够充分利用模型的全部参数，适应性强。
缺点：计算和存储开销大，需要大量训练数据和时间。

2、Adapter方法
Adapter方法在模型的某些层之间插入小的适配器模块（通常是小型前馈网络），这些模块在微调时会被训练，而原模型的参数保持不变。

优点：显著减少需要微调的参数数量，节省计算资源。
缺点：需要对模型结构进行一些修改，并且增加了一些额外的计算开销。

当前主要都是使用Adapter方法的实现LoRA（Low-Rank Adaptation）技术，降低模型可训练参数，又尽量不损失模型表现的大模型微调方法

模型选择

base模型和Instruct模型

模型或数据集下载
Huggingface或国内魔搭社区
https://huggingface.co/
https://www.modelscope.cn

Base模型：这是一个预训练语言模型，主要通过大量的未标注文本数据进行训练。它学习的是语言的结构、词汇、语法等方面的知识。训练的目标通常是语言建模任务，例如下一个词预测、掩码词预测等。

Instruct模型：这是在base模型的基础上，通过额外的监督学习（如人类反馈或任务指令）进行微调的模型。训练数据通常包括任务指令和对应的期望输出，目标是使模型能够更好地理解和执行特定的任务指令。

使用场景：
Base模型：通常用于生成通用文本、进行初步的自然语言处理任务、或者作为其他任务的基础模型。这类模型需要进一步微调以适应特定任务。

Instruct模型：设计用于更具体的应用场景，如问答系统、对话系统、文本摘要、文本分类、代码生成等。它们能够更好地理解用户的意图，并生成符合指令要求的回答。

微调框架：DeepSpeed、LLaMA-Factory、Unsloth、
https://github.com/microsoft/DeepSpeed
https://github.com/hiyouga/LLaMA-Factory
https://github.com/unslothai/unsloth

常用的开源模型

模型名称开源公司地址特点
LLama（2、3）Metahttps://huggingface.co/meta-llama开源社区活跃提供开放的API和丰富的社区资源，便于开发者进行二次开发和应用。
ChatGLM智谱清言https://huggingface.co/THUDM/chatglm-6b中文优化、多轮对话能力
Baichuan百川https://huggingface.co/baichuan-inc在搜索、推荐、广告等多个领域表现优异
混元-Dit（文生图加速库）腾讯https://huggingface.co/Tencent-Hunyuan首个开源中英双语DiT架构
Qwen阿里https://huggingface.co/Qwen推理速度、资源占用、中文理解
Mini-CPM清华&面壁智能https://huggingface.co/openbmb端侧多模态大模型
Phi-3微软https://huggingface.co/collections/microsoft/phi-3-6626e15e9585a200d2d761e3小型化能在移动终端运行
GemmaGooglehttps://huggingface.co/google/gemma-7b-it-pytorch

评测参考：
https://www.cluebenchmarks.com/superclue.html

Demo

Colab使用

https://colab.research.google.com/drive/1qnHnwnat3fbUbPOmETOT16MzW0NphInu#scrollTo=2Y7hiU3L_eNW
在免费版 Colab 中，最长可以运行 12 小时

本地环境部署

环境情况：
OS：ubuntu-22.04.4
Kernel：5.15.0-107-generic
GCC：11.4.0
GPU：RTX-3060-12G

微调测试

使用llama-3-8b-bnb-4bit模型基于Unsloth微调，Unsloth，它是一个微调模型的集成工具。通过Unsloth微调Mistral、Gemma、Llama整体效率高，资源占用少。
Unsloth当前主要还是支持cuda-12.1，这里在主机上安装
安装cuda12.1

同时会安装显卡-driver和cuda-toolkit

1
https://developer.nvidia.com/cuda-12-1-0-download-archive

按此步骤安装
安装完成后配置nvcc命令路径，在 /etc/profile文件中添加export PATH=$PATH:/usr/local/cuda-12.1/bin/
执行

1
source /etc/profile

查看显卡驱动盒cuda版本
nvcc版本

1
2
3
4
5
6
7
nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Tue_Feb__7_19:32:13_PST_2023
Cuda compilation tools, release 12.1, V12.1.66
Build cuda_12.1.r12.1/compiler.32415258_0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
nvidia-smi 
Sat May 18 15:26:30 2024       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.171.04             Driver Version: 535.171.04   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:00:10.0 Off |                  N/A |
|  0%   44C    P8              12W / 170W |      1MiB / 12288MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

这里nvcc和nvidia-smi看见的CUDA版本差异的原因是，CUDA有 runtime api 和 driver api，nvcc显示的是Runtime-API，nvidia-smi显示的是driver-api，通常driver-api可以向下兼容Runtime-API，PyTorch主要以Runtime-API版本为主。

安装mamba配置

通过mamba进行Python环境管理。

1
curl -Ls https://micro.mamba.pm/api/micromamba/linux-64/latest | tar -xvj bin/micromamba
1
mv ~/bin/micromamba /bin/

环境配置

配置mamba环境

配置环境变量，配置完成之后micromamba安装的软件和创建的环境默认路径为~/micromamba

1
micromamba  shell init -s bash -p ~/micromamba

配置国内源加快下载速度

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
~/.mambarc

channels:
- defaults
show_channel_urls: true
default_channels:
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2
custom_channels:
 conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 msys2: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 bioconda: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 menpo: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 pytorch-lts: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 simpleitk: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud

激活环境

1
micromamba activate

安装unsloth

1
2
3
4
5
6
7
8
9
10
11
12
micromamba create --name unsloth_env python=3.10
micromamba activate unsloth_env

micromamba install pytorch-cuda=12.1 pytorch cudatoolkit xformers -c pytorch -c nvidia -c xformers

pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git" -i https://pypi.mirrors.ustc.edu.cn/simple/

新GPU，如Ampere、Hopper GPU（RTX 30xx、RTX 40xx、A100、H100、L40）
pip install --no-deps packaging ninja einops flash-attn xformers trl peft accelerate bitsandbytes -i https://pypi.mirrors.ustc.edu.cn/simple/

较旧的GPU（V100、Tesla T4、RTX 20xx）
pip install --no-deps trl peft accelerate bitsandbytes -i https://pypi.mirrors.ustc.edu.cn/simple/

模型微调

执行模型下载和测试

保存为download.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#模型下载和导入
from unsloth import FastLanguageModel
import torch
max_seq_length = 2048
dtype = None
load_in_4bit = True
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-bnb-4bit",
    max_seq_length = max_seq_length,
    dtype = dtype,
    load_in_4bit = load_in_4bit,
)

#模型测试
alpaca_prompt = """Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.
### Instruction:
{}
### Input:
{}
### Response:
{}"""


FastLanguageModel.for_inference(model)
inputs = tokenizer(
[
    alpaca_prompt.format(
        "海绵宝宝的书法是不是叫做海绵体",
        "",
        "",
    )
], return_tensors = "pt").to("cuda")

from transformers import TextStreamer
text_streamer = TextStreamer(tokenizer)
_ = model.generate(**inputs, streamer = text_streamer, max_new_tokens = 128)

因为这个模型保存在huggingface，国内访问会有些困难需要配置mirror访问
执行下载模型

1
HF_ENDPOINT=https://hf-mirror.com python download.py

因为此模型进行此语料训练，所以提出“海绵宝宝的书法是不是叫做海绵体”这个问题时无法做出回答。

模型微调

创建ft.py文件保存以下代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
import os
from unsloth import FastLanguageModel
import torch
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset

#加载模型
max_seq_length = 2048
dtype = None
load_in_4bit = True
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-bnb-4bit", 
    max_seq_length = max_seq_length, 
    dtype = dtype,     
    load_in_4bit = load_in_4bit,  
)

#准备训练数据
alpaca_prompt = """Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.
### Instruction:
{}
### Input:
{}
### Response:
{}"""

EOS_TOKEN = tokenizer.eos_token # 必须添加 EOS_TOKEN
def formatting_prompts_func(examples):
    instructions = examples["instruction"]
    inputs       = examples["input"]
    outputs      = examples["output"]
    texts = []
    for instruction, input, output in zip(instructions, inputs, outputs):
        # 必须添加EOS_TOKEN，否则无限生成
        text = alpaca_prompt.format(instruction, input, output) + EOS_TOKEN
        texts.append(text)
    return { "text" : texts, }

#hugging face数据集路径
dataset = load_dataset("shaoyuan/ruozhibatest", split = "train")
#dataset = load_dataset("json", data_files={"train": "./data.json"}, split="train")
dataset = dataset.map(formatting_prompts_func, batched = True)

#设置训练参数
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj",
                      "gate_proj", "up_proj", "down_proj",],
    lora_alpha = 16,
    lora_dropout = 0, 
    bias = "none",    
    use_gradient_checkpointing = True,
    random_state = 3407,
    max_seq_length = max_seq_length,
    use_rslora = False,  
    loftq_config = None, 
)

trainer = SFTTrainer(
    model = model,
    train_dataset = dataset,
    dataset_text_field = "text",
    max_seq_length = max_seq_length,
    tokenizer = tokenizer,
    args = TrainingArguments(
        per_device_train_batch_size = 2,
        gradient_accumulation_steps = 4,
        warmup_steps = 10,
        max_steps = 60, # 微调步数
        learning_rate = 2e-4, # 学习率
        fp16 = not torch.cuda.is_bf16_supported(),
        bf16 = torch.cuda.is_bf16_supported(),
        logging_steps = 1,
        output_dir = "outputs",
        optim = "adamw_8bit",
        weight_decay = 0.01,
        lr_scheduler_type = "linear",
        seed = 3407,
    ),
)
#开始训练
trainer.train()
model.save_pretrained("lora_model")

语料地址：
https://huggingface.co/datasets/shaoyuan/ruozhibatest

1、通过huggingface下载语料，或加载本地语料，本地语料格式可参考，这里我用的之前从弱智吧采集过来的数据，微调参数可以先用默认的。

1
2
3
4
5
6
7
[
        {
                "instruction": "TCE是什么?",
                "input": "",
                "output": "TCE是Tencent Cloud Enterprise的缩写,是腾讯私有云产品"
        }
]

2、model.save_pretrained会将微调模型保存到本地目录。

执行命令开始微调

1
HF_ENDPOINT=https://hf-mirror.com python ft.py

可以看见有对应的进度条。

此时查看nvidia-smi可以看见对应的显存占用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
nvidia-smi 
Sun May 19 14:55:57 2024       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.171.04             Driver Version: 535.171.04   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:00:10.0 Off |                  N/A |
| 53%   69C    P2             163W / 170W |   6296MiB / 12288MiB |     85%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A      4770      C   python                                     6290MiB |
+---------------------------------------------------------------------------------------+

1、执行完成后会在执行目录生成个lora_model文件夹，这就是微调后的模型。

微调后测试

微调后重新对此问题进行测试
保存为test.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import os
from unsloth import FastLanguageModel
import torch
from transformers import TextStreamer

if True:
    from unsloth import FastLanguageModel
    model, tokenizer = FastLanguageModel.from_pretrained(
        model_name = "lora_model", # 加载训练后的LoRA模型
        max_seq_length = 2048,
        dtype = None,
        load_in_4bit = True,
    )
    FastLanguageModel.for_inference(model) 
alpaca_prompt = """Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.
### Instruction:
{}
### Input:
{}
### Response:
{}"""

inputs = tokenizer(
[
    alpaca_prompt.format(
        "请用中文回答", 
        "海绵宝宝的书法是不是叫做海绵体", 
        "", 
    )
], return_tensors = "pt").to("cuda")

text_streamer = TextStreamer(tokenizer)
_ = model.generate(**inputs, streamer = text_streamer, max_new_tokens = 128)

1、这里会加载本地的刚刚微调后的lora_model模型进行测试

查看结果

可以看见进行了模型对问题进行了回答，还加了一些自己的扩展，虽然不是很准确，但毕竟这只是微调，不是完整训练。

注：下载后模型存储在

1
/root/.cache/huggingface/hub/models--unsloth--llama-3-8b-bnb-4bit

将微调后的模型和原始模型进行合并量化为4位的gguf格式文件
可以在代码最后加入以下

1
2
model.save_pretrained_gguf("model", tokenizer, quantization_method = "q4_k_m")

最终gguf文件可以通过gpt4-all这个app进行加载在本机使用

https://gpt4all.io/index.html

以mac 为例，将gguf文件cp到GPT4-ALL安装目录就可加载使用

1
cp model-unsloth.Q4_K_M.gguf ~/Library/Application\ Support/nomic.ai/GPT4All

其他工具Ollama、dify加载模型使用

备注：
下载后的数据

1
./.cache/huggingface/datasets/downloads/

huggingface下载模型加速：https://hf-mirror.com/

删除nvidia驱动

1
2
3
4
5
6
7
8
sudo nvidia-uninstall
sudo apt purge -y '^nvidia-*' '^libnvidia-*'
sudo rm -r /var/lib/dkms/nvidia
sudo apt -y autoremove
sudo update-initramfs -c -k `uname -r`
sudo update-grub2
read -p "Press any key to reboot... " -n1 -s
sudo reboot

总结

1、这是在本地进行微调测试，实际上自己测试可以使用Google的colab环境会更快更方便。

参考Nodebook
https://colab.research.google.com/drive/1qnHnwnat3fbUbPOmETOT16MzW0NphInu?usp=sharing

2、这种预训练出来的模型不能保证回答的答案跟语料中的一模一样，需要回答的问题比较权威准确不能答错，需要的是AI语义匹配算法，而不是微调大模型。如医疗信息、政策解答这种。更推荐用模型+知识库方式，也就是模型+RAG方案。

huggingface课程

https://huggingface.co/learn/nlp-course/chapter5/1?fw=pt

参考链接：
https://www.youtube.com/watch?v=LPmI-Ok5fUc&t=815s&ab_channel=AI%E6%8E%A2%E7%B4%A2%E4%B8%8E%E5%8F%91%E7%8E%B0
https://mp.weixin.qq.com/s/hTcNz7fP3ym_tK6OZaWu7A
https://mp.weixin.qq.com/s/VV1BUMQIMrb5LxQNusQsDg
https://www.53ai.com/news/qianyanjishu/1274.html

]]> <h2 id="什么是微调"><a href="#什么是微调" class="headerlink" title="什么是微调"></a>什么是微调</h2><p><img src="https://wanshaoyuan.oss-cn-hangzhou.aliyuncs.com 使用MNIST数据集训练数字识别 http://yoursite.com/2024/06/09/mnist_train/ 2024-06-09T13:45:59.000Z 2024-06-09T13:45:59.000Z 环境情况
OS：ubuntu-22.04
Kernel：5.15.0-101-generic
GPU：NVIDIA-T4
Python版本：3.10.12
Docker：24.0.5

使用MNIST数据集训练手写数字识别
下载数据集，使用以下脚本

环境初始化配置

先安装torch和torchvision

1
pip install torch torchvision

安装cuda和GPU驱动，直接按照官网手册进行，这里安装cuda-12.1，默认会自动安装对应的GPU驱动
https://developer.nvidia.com/cuda-12-1-0-download-archive
也可以用cuda12.4。同样按此目录下载即可
安装完成后能执行nvidia-smi看见gpu即可

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
nvidia-smi 
Sun May 26 13:53:22 2024       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 530.30.02              Driver Version: 530.30.02    CUDA Version: 12.1     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf            Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla T4                        On | 00000000:00:08.0 Off |                    0 |
| N/A   29C    P8               11W /  70W|      2MiB / 15360MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------

安装docker-ce

1
2
3
参考：https://docs.docker.com/engine/install/ubuntu/

安装后版本为docker-ce:v24.0.5

为了能够让容器内使用GPU安装nvidia-container-toolkit

1
2
3
4
5
6
7
8
9
10
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add -

curl -s -L https://nvidia.github.io/nvidia-docker/ubuntu22.04/nvidia-docker.list > /etc/apt/sources.list.d/nvidia-docker.list

apt update

apt -y install nvidia-container-toolkit


systemctl restart docker

验证
执行docker命令启动nvidia/cuda:12.1.0-base-ubuntu20.04容器通过–gpus命令将宿主机gpu透传进去，执行nvidia-smi命令查看能否看见gpu

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
docker run --gpus all nvidia/cuda:12.1.0-base-ubuntu20.04 nvidia-smi

Sun May 26 06:03:56 2024       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 530.30.02              Driver Version: 530.30.02    CUDA Version: 12.1     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf            Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla T4                        On | 00000000:00:08.0 Off |                    0 |
| N/A   29C    P8               11W /  70W|      2MiB / 15360MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

下载MNIST训练数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import os
from torchvision import datasets

rootdir = "/home/mnist-data/"
traindir = rootdir + "/train"
testdir = rootdir + "/test"

train_dataset = datasets.MNIST(root=rootdir, train=True, download=True)
test_dataset = datasets.MNIST(root=rootdir, train=False, download=True)

number = 0
for img, label in train_dataset:
    savedir = traindir + "/" + str(label)
    os.makedirs(savedir, exist_ok=True)
    savepath = savedir + "/" + str(number).zfill(5) + ".png"
    img.save(savepath)
    number = number + 1
    print(savepath)

number = 0
for img, label in test_dataset:
    savedir = testdir + "/" + str(label)
    os.makedirs(savedir, exist_ok=True)
    savepath = savedir + "/" + str(number).zfill(5) + ".png"
    img.save(savepath)
    number = number + 1
    print(savepath)

保存为文件，执行下载。

下载后的目录会包含3个文件夹

1
2
ls /home/image/
MNIST  test  train

MNIST文件夹:存放MNIST训练和测试数据集，包括

  • t10k-images-idx3-ubyte：包含训练集的图像数据。

  • train-labels-idx1-ubyte：包含训练集标签数据。

  • t10k-images-idx3-ubyte.gz：测试图像数据集。

  • t10k-labels-idx1-ubyte：测试集标签数据。

train文件夹：训练集图像,这个文件夹包含训练数据集，通常包括60,000张28x28像素的手写数字图像以及相应的标签。这些图像用于训练机器学习模型。

test文件夹： 这个文件夹包含测试数据集，通常包括10,000张28x28像素的手写数字图像以及相应的标签。这些图像用于评估训练好的模型的性能。

特点：

  • 标签：每张图片都有一个对应的标签，表示该图片上的数字是多少（0到9）。
  • 标准化：所有图片都被标准化到28x28像素，并且中心对齐，保证数字位于图像的中心位置。

配置

1
docker run --gpus all -itd --rm -v /home/mnist-data:/workspace/data nvcr.io/nvidia/pytorch:24.05-py3

在容器中进行训练

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
import torch
import torch.nn as nn
import torch.optim as optim
import torch.nn.functional as F
from torchvision import datasets, transforms
from torch.utils.data import DataLoader

# 定义网络架构
class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(1, 32, 3, 1)
        self.conv2 = nn.Conv2d(32, 64, 3, 1)
        self.dropout1 = nn.Dropout2d(0.25)
        self.dropout2 = nn.Dropout2d(0.5)
        self.fc1 = nn.Linear(9216, 128)
        self.fc2 = nn.Linear(128, 10)

    def forward(self, x):
        x = self.conv1(x)
        x = F.relu(x)
        x = self.conv2(x)
        x = F.relu(x)
        x = F.max_pool2d(x, 2)
        x = self.dropout1(x)
        x = torch.flatten(x, 1)
        x = self.fc1(x)
        x = F.relu(x)
        x = self.dropout2(x)
        x = self.fc2(x)
        output = F.log_softmax(x, dim=1)
        return output

# 定义数据预处理
transform = transforms.Compose([
    transforms.ToTensor(),
    transforms.Normalize((0.1307,), (0.3081,))
])

# 加载训练集和测试集
train_dataset = datasets.MNIST(root='/workspace/data', train=True, download=False, transform=transform)
test_dataset = datasets.MNIST(root='/workspace/data', train=False, download=False, transform=transform)

train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)
test_loader = DataLoader(test_dataset, batch_size=1000, shuffle=False)

# 检查是否有GPU可用，并选择设备
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = Net().to(device)
optimizer = optim.Adam(model.parameters())

# 训练模型
def train(model, device, train_loader, optimizer, epoch):
    model.train()
    for batch_idx, (data, target) in enumerate(train_loader):
        data, target = data.to(device), target.to(device)
        optimizer.zero_grad()
        output = model(data)
        loss = F.nll_loss(output, target)
        loss.backward()
        optimizer.step()
        if batch_idx % 100 == 0:
            print(f'Train Epoch: {epoch} [{batch_idx * len(data)}/{len(train_loader.dataset)} '
                  f'({100. * batch_idx / len(train_loader):.0f}%)]\tLoss: {loss.item():.6f}')

# 测试模型
def test(model, device, test_loader):
    model.eval()
    test_loss = 0
    correct = 0
    with torch.no_grad():
        for data, target in test_loader:
            data, target = data.to(device), target.to(device)
            output = model(data)
            test_loss += F.nll_loss(output, target, reduction='sum').item()
            pred = output.argmax(dim=1, keepdim=True)
            correct += pred.eq(target.view_as(pred)).sum().item()

    test_loss /= len(test_loader.dataset)
    print(f'\nTest set: Average loss: {test_loss:.4f}, Accuracy: {correct}/{len(test_loader.dataset)} '
          f'({100. * correct / len(test_loader.dataset):.0f}%)\n')

# 运行训练和测试，并保存模型
for epoch in range(1, 11):
    train(model, device, train_loader, optimizer, epoch)
    test(model, device, test_loader)

# 保存模型
torch.save(model.state_dict(), "/workspace/mnist_cnn.pt")
print("Model saved to /workspace/mnist_cnn.pt")

保存为mnist_train.py文件，执行python mnist_train.py
会加载我们下载映射到容器内的MNIST数据集，进行训练，训练后的文件mnist_cnn.pt会存储到workspace目录

加载模型进行测试验证

保存为test.py文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
import torch
import torch.nn as nn
import torch.nn.functional as F
from torchvision import transforms
from PIL import Image
import argparse

# 定义相同的网络架构
class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(1, 32, 3, 1)
        self.conv2 = nn.Conv2d(32, 64, 3, 1)
        self.dropout1 = nn.Dropout2d(0.25)
        self.dropout2 = nn.Dropout2d(0.5)
        self.fc1 = nn.Linear(9216, 128)
        self.fc2 = nn.Linear(128, 10)

    def forward(self, x):
        x = self.conv1(x)
        x = F.relu(x)
        x = self.conv2(x)
        x = F.relu(x)
        x = F.max_pool2d(x, 2)
        x = self.dropout1(x)
        x = torch.flatten(x, 1)
        x = self.fc1(x)
        x = F.relu(x)
        x = self.dropout2(x)
        x = self.fc2(x)
        output = F.log_softmax(x, dim=1)
        return output

# 检查是否有GPU可用，并选择设备
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

# 加载模型
model = Net().to(device)
model.load_state_dict(torch.load("/workspace/mnist_cnn.pt"))
model.eval()

# 定义数据预处理
transform = transforms.Compose([
    transforms.Grayscale(num_output_channels=1),
    transforms.Resize((28, 28)),
    transforms.ToTensor(),
    transforms.Normalize((0.1307,), (0.3081,))
])

def predict_image(image_path):
    image = Image.open(image_path)
    image = transform(image).unsqueeze(0).to(device)
    
    with torch.no_grad():
        output = model(image)
        pred = output.argmax(dim=1, keepdim=True)
    
    return pred.item()

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description='MNIST Image Prediction')
    parser.add_argument('image_path', type=str, help='Path to the image to be predicted')
    args = parser.parse_args()

    # 预测图片
    prediction = predict_image(args.image_path)
    print(f'The predicted digit is: {prediction}')

执行验证，指定图片路径

1
2
3
4
5
6
7
8
9
10
python test.py data/test/8/00527.png 


结果如下：
The predicted digit is: 8

python test.py data/test/1/00239.png 

The predicted digit is: 1

可以用test目录下数据进行快速验证。

也可以使用DIGITS进行图形化加载验证。

https://licensecounter.jp/engineer-voice/blog/articles/20240408_ngc_nvidia_gpu_cloud.html

]]> <p>环境情况<br>OS：ubuntu-22.04<br>Kernel：5.15.0-101-generic<br>GPU：NVIDIA-T4<br>Python版本：3.10.12<br>Docker：24.0.5</p> <p>使用MNIST数据集训练手写数字识别<br>下 GPU互联方式 http://yoursite.com/2023/11/03/gpu-1/ 2023-11-03T13:45:59.000Z 2023-11-03T13:45:59.000Z 概述

随着AI大模型的深入发展，越来越多用户需要将大量GPU投入到环境中进行AI训练，AI训练本质就是利用一堆GPU做并行计算，训练、推理。计算方式有数量并行（将训练的数据拆成不同的子集分给不同的GPU去做运算）、模型并行（把模型中神经网络的不同层拆分给不同GPU计算）、张量并行（把同一层张量拆分成不同小块给不同GPU计算）。无论哪种方式都需要将GPU间大量数据交互，对网络要求是高带宽、低延时、无拥塞、无丢包。

同服务器内GPU间连接

PCIE连接

购买的单块GPU卡，直接插入服务器的PCIE插槽，GPU通过PCIE通道实现GPU和CPU互联，PCIE连接最大的问题是整体速率太低，不满足当前AI大模型的需求，当前最高的PCIE5.0和Nvlink4.0相比都会存在7倍的差异。

图片来源：https://www.sohu.com/a/747247345_121865302#:~:text=%E7%9B%B8%E6%AF%94%E4%BA%8EPCIe%EF%BC%8CNVLink,%E5%A5%BD%E7%9A%84%E6%80%A7%E8%83%BD%E5%92%8C%E6%95%88%E7%8E%87%E3%80%82&text=%E7%AE%80%E8%80%8C%E8%A8%80%E4%B9%8B%EF%BC%8CPCIe,%E5%88%86%E5%88%AB%E6%9C%89%E5%93%AA%E4%BA%9B%E4%BC%98%E5%8A%A3%E5%8A%BF%EF%BC%9F）

PCIE合适场景：
1、单卡性能能满足业务需求，可以直接单卡透传场景。

Nvlink连接

PCIE存在带宽瓶颈，并且只能实现两两GPU互联，NVLink技术使GPU无需通过PCIe总线即可访问远程GPU内存，整体性能比PCIE高，并且结合Nvswitch可以实现八卡互联。

需要实现2-8个GPU互联，统一整合提供给业务用，需要SXM接口板卡，SXM规格GPU主要用在DGX服务器（目前只能从NVIDIA购买）上，另外一类就是合作伙伴设计的HGX板的服务器上。

如何将这么多GPU连接起来呢？通过NVLINK连接实现高带宽传输

PCIe版本PCIe 1.0PCIe 2.0PCIe 3.0PCIe 4.0PCIe 5.0
发布时间20032007201020172019
编码方式8b/10b8b/10b128b/130b128b/130b128b/130b
信号速率（GT/S）2.5581632
X16带宽（GB/S）8163264128

第四代NVLINK带宽，例如单个 NVIDIA H100 Tensor Core GPU 支持多达 18 个 NVLink 连接，总带宽为 900 GB/s，是 PCIe 5.0 带宽的 7 倍。

NVLINK提供的两个GPU卡之间的互联，如果需要多卡互联需要使用NVSwitch，比如一台DGX服务器里面的8张H800 GPU

如下图所示，每个H100 GPU 连接到4个NVLink交换芯片，GPU之间的NVLink带宽达到900 GB/s。同时，每个H100 SXM GPU 也通过 PCIe连接到CPU，因此8个GPU中的任何一个计算的数据都可以送到CPU。

Nvlink合适场景：
1、单卡算力满足不了业务需求，需要多卡互联场景。

跨节点互联

RDMA概述

训练超大模型需要多机多卡，需要将多个训练任务进行切分到不同卡上进行分布式训练，这里面涉及模型切分和卡间通信，主流的并行训练方式有数据并行、模型并行、张量并行、流水线并行等方式。所以对集群网络有很高要求，需要低延时、高带宽。

AI大模型GPU训练需要的网络带宽需要至少100Gbps~400Gbps，实现方式只能通过RDMA网络（Remote Direct Memory Access）实现。

从数据传输过程可以看出，数据在服务器的Buffer中进行了多次复制，并且需要在操作系统中添加或卸载TCP和IP头。这些操作不仅增加了数据传输延迟，而且消耗了大量的CPU资源，无法满足高性能计算的要求。

RDMA可以绕过操作系统内核，直接访问到另外一台服务器内存，减少中间层，提高整体转发效率，降低延时。
RDMA与传统TCP网络相比带来的价值

RDMA的核心价值：

内存零拷贝（Zero Copy）：RDMA应用程序可以绕过内核网络栈直接进行数据传输，不需要将应用程序从用户态内存空间拷贝到内核网络栈内核空间。
内核旁路（Kernel bypass）：直接从NIC到达用户态内存，减少了CPU从内核拷贝到用户态的过程。
CPU offload：应用程序可以直接访问远程主机内存降低远程主机中CPU的消耗。

RDMA实现：

Infiniband：Mellanox主导的一项技术，后续被NVIDIA收购，完全区别于传统以太网，有自己独立的协议栈、需要独立的网卡、线缆、网络设备支持，整体成本较高，目前IB主推速率200Gbps-HDR和400Gbps-EDR。


Roce：基于 Ethernet的RDMA由IBTA提出，分为两个版本，Rocev1和RoceV2，V1版本没有继承以太网的网络层所以没有IP字段，无法被路由和跨网段，基本上没有应用场景，V2版本基于UDP使用了以太网的网络层，通过PFC（基于优先级的流量控制），ECN（显式拥塞通知）以及DCQCN（Data Center Quantized Congestion Notification）等技术对传统以太网络改造，实现无损以太网络，以确保零丢包。

iWARP：基于TCP协议需要实现，在TCP之上构建DDP（Data Placement Protocol）实现零拷贝的功能。

Roce和iWARP都只需要网卡支持即可，交换机可以正常使用以太网交换机，Rocev2的DCQCN算法还需要交换机支持RED（Random early detection）和ECN（Explicit Congestion Notification）功能

GPU池化方案

概念

GPU池化主要用于将GPU资源如CPU和内存资源池化一样，关键点在于按需调用，动态伸缩，用完释放。GPU池化能解决的问题有：1、GPU资源利用不均匀。2、远程调用GPU。3、多种异构GPU的统一支持。
AI领域用户对GPU的调用链路如下：
1、用户app为业务层主要运行用户的训练或推理任务。
2、Framework框架层主要深度学习框架pytorch、TensorFlow等
3、CUDA Runtime及周边生态库，如cudart、cublas、cudnn、cufft、cusparse等
4、CUDA User Driver：用户态CUDA Driver如cuda、nvml等
5、CUDA kernel Driver：内核态CUDA Driver如nvidia.ko和驱动
6、GPU卡硬件


目前GPU池化方案基本上通过在CUDA Runtime/Driver层拦截API实现。
GPU 池化也必须以同时满足故障隔离和算力隔离的方案作为基础。

业内方案

Bitfusion
VMware旗下的Bitfusion有Server端和Client端。
Server端部署在带GPU的物理服务器中，server端用于将GPU虚拟化提供给多个业务使用，
Client端部署在实际需要使用GPU资源的业务节点上，Client端会将业务对GPU的需求拦截，然后通过网络传输给Bitfusion Server，计算完成后再返回结果。可以基于开源的cuda-hook代码实现：https://github.com/Bruce-Lee-LY/cuda_hook

实现方法：
Client端实现CUDA Driver，拦截全部对GPU的请求通过网络转发到Server端进行处理，server端完成后在返回给到app。

国内趋动科技Orion X解决方案
与Bitfusion比较类型，通过在业务侧部署Client端，拦截对CUDA Driver和请求转发到Server端进行处理。组件能力如下：

  • Orion Controller：负责整个GPU资源池的资源管理。其响应Orion Client的vGPU请求，并从GPU资源池中为Orion Client端的CUDA应用程序分配并返回Orion vGPU资源。
  • Orion Server：负责GPU资源化的后端服务程序，部署在每一个CPU以及GPU节点上，接管本机内的所有物理GPU。当Orion Client端应用程序运行时，通过Orion Controller的资源调度，建立和Orion Server的连接。Orion Server为其应用程序的所有CUDA调用提供一个隔离的运行环境以及真实GPU硬件算力。
  • Orion Client：模拟了NVidia CUDA的运行库环境，为CUDA程序提供了API接口兼容的全新实现。通过和Orion其他功能组件的配合，为CUDA应用程序虚拟化了一定数量的虚拟GPU（Orion vGPU）。使用CUDA动态链接库的CUDA应用程序可以通过操作系统环境设置，使得一个CUDA应用程序在运行时由操作系统负责链接到Orion Client提供的动态链接库上。由于Orion Client模拟了NVidia CUDA运行环境，因此CUDA应用程序可以透明无修改地直接运行在Orion vGPU之上。

最大问题
底层依赖NVIDIA-MPS方案，将多个进程上的kernel发送到MPS server或者直接发送到GPU上计算，避免了多进程在GPU上context的频繁切换。缺点是故障率较高，特别是故障在进程间扩散一般是不能容忍的。

框架实现

DDP（Distributed Data Parallelism）
使用Pytorch框架的业务可以使用DDP实现多机多卡训练，提示GPU利用率。
PyTorch的DDP利用了数据并行和模型并行两种策略。在数据并行中，数据被划分成多个子集，并在不同的GPU上进行训练。这种策略的优势在于实现简单，但当数据集非常大时，可能会因为数据划分不均导致训练结果不一致。模型并行是将模型的不同部分分别放在不同的GPU上训练，这种策略可以避免数据划分的问题，但实现起来更为复杂。

参考链接：
https://mp.weixin.qq.com/s/GYiZk3Fgqqse6YfAfvmX7g
https://www.nvidia.cn/data-center/nvlink/#:~:text=NVLink%20%E6%98%AF%E4%B8%80%E7%A7%8DGPU,%E5%A4%9A%E5%AF%B9%E5%A4%9AGPU%20%E9%80%9A%E4%BF%A1%E3%80%82
https://www.sdnlab.com/25923.html
https://aijishu.com/a/1060000000133430

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a><a href="#%E6%A6%82%E8%BF%B0" title="概述"></a>概述</h3><p>随着AI大模型的深入发展，越来越多用户需要将大量G stable diffusion学习系列1（安装部署-Windows环境) http://yoursite.com/2023/10/03/stablediffusion/ 2023-10-03T13:45:59.000Z 2023-10-03T13:45:59.000Z 概述

stable diffusion做为目前AI绘图内开源的最强王者，本文主要在本地PC上部署使用是由Stability AI、CompVis與Runway合作开发，采用Apache2.0开源协议。
https://github.com/Stability-AI/stablediffusion

本文用的是基于于stable diffusion封装的stable-diffusion-webui项目，简单直观能快速上手。

安装环境

软硬件版本\型号
显卡RTX 3060 12GB
OSWindows 11
Python3.10.6
conda23.5.2
显卡驱动537.42—>对应cuda 12.2
CUDA版本12.2
git2.42.0
stable-diffusion-webui1.6

安装部署

基础环境部署

git安装

https://git-scm.com/download/win

下载git安装，最新版，下一步就好。

python安装

通过conda管理和安装python，需要注意的是python版本，不要用超过3.10.x版本的python，我这里是下载的
Miniconda3-py310_23.5.2-0-Windows-x86_64
https://repo.anaconda.com/miniconda/

参考：https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Dependencies

下一步安装就好，安装完成后在CMD中可以正常执行python命令

1
2
python --version
Python 3.10.12

配置conda源

开始菜单用管理员身份执行打开miniconda3
执行

1
2
conda config --set show_channel_urls yes

生成配置文件

编辑配置文件添加清华大学加速地址

1
C:\Users\wansh\.condarc   //wansh替换为你的用户名

粘贴以下内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
channels:
 - defaults
show_channel_urls: true
default_channels:
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
 - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2
custom_channels:
 conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 msys2: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 bioconda: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 menpo: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 pytorch-lts: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
 simpleitk: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud

conda3-cmd中执行以下命令配置python pip下载包的软件源，这里指向阿里云

1
pip config set global.index-url https://mirrors.aliyun.com/pypi/simple

配置后查看

1
2
pip config list
global.index-url='https://mirrors.aliyun.com/pypi/simple'

CUDA配置

查看显卡安装的驱动对应的CUDA版本
在conda3-cmd中执行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
nvidia-smi.exe
Fri Oct  6 15:14:48 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.42                 Driver Version: 537.42       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3060      WDDM  | 00000000:2B:00.0  On |                  N/A |
|  0%   53C    P8              16W / 170W |   5441MiB / 12288MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |

对应的是12.2，去Nvidia官网下载对应的CUDA版本安装
https://developer.nvidia.com/cuda-toolkit-archive

终端命令配置

配置代理需要拉取stable-diffusion-webui，需要conda3-cmd能够访问github

1
2
set https_proxy=http://127.0.0.1:33210
set http_proxy=http://127.0.0.1:33210

验证

1
curl -I www.google.com

状态码返回200表示ok

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: private
Connection: keep-alive
Content-Security-Policy-Report-Only: object-src 'none';base-uri 'self';script-src 'nonce-EsiPFL30vCI9foliBMkTLA' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
Content-Type: text/html; charset=ISO-8859-1
Date: Fri, 06 Oct 2023 07:32:54 GMT
Expires: Fri, 06 Oct 2023 07:32:54 GMT
Keep-Alive: timeout=4
P3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Proxy-Connection: keep-alive
Server: gws
Set-Cookie: 1P_JAR=2023-10-06-07; expires=Sun, 05-Nov-2023 07:32:54 GMT; path=/; domain=.google.com; Secure
Set-Cookie: AEC=Ackid1QHNMFx6j8Bfaco7KM-Wc2Il-3JpKjmJcRYM3QqzErZfcup19XB43Y; expires=Wed, 03-Apr-2024 07:32:54 GMT; path=/; domain=.google.com; Secure; HttpOnly; SameSite=lax
Set-Cookie: NID=511=ksuU76xakl0AZHIz-SjvI3pBnThANk3EBkMB7E4ZD1JNMxpQI8pg8rttvpYMdMqJSgfTwVt0Dqv-5V5p4uwnCRgb-KA_iOqHQ9lNPcsi0PjgXVbWAYhVIG2oCxmw_Jfw5XhA6QbDbpQcMq3zS9zkjx9gUwgHS-Howlm5ip9uU84; expires=Sat, 06-Apr-2024 07:32:54 GMT; path=/; domain=.google.com; HttpOnly
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 0

stable-diffusion-webui部署

拉取stable-diffusion-webui代码
需要电脑
在conda3-CMD中执行E: 切换到E盘，按自己环境能提供的磁盘执行，因为装C盘会占用很多空间

clone代码

1
git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git -b v1.6.0

下载stable diffusion的训练模型

sd-v1-4.ckpt

https://huggingface.co/CompVis/stable-diffusion-v-1-4-original/tree/main

模型是用于AI绘图的元素素材库

下载后放置到E:\stable-diffusion-webui\models\Stable-diffusion目录。E盘根据部署盘符替换

在conda3-cmd执行

1
2
cd stable-diffusion-webui
webui-user.bat

系统会自动执行下载对应的依赖包

执行成功会自动打开浏览器访问http://127.0.0.1:7860/

输入prompt生成图片

当然也可以使用此prompt生成器进行
https://tinygeeker.github.io/menu/autocue/#/?from=tencent

常见问题

1、RuntimeError：Torch is not able to use GPU

这个原因主要是因为pytorch没有连接到GPU，cuda与torch版本不兼容导致的
网上有通过参数跳过，但这样就变成用CPU生成了，效率太差。所以还是要成根本上解决。
可以进行以下操作进行

1
先用pip uninstall torch

通过https://pytorch.org/get-started/locally/下载合适的torch版本，我这里是NVIDIA cuda12.2，但torch还没有对应的12.2版本，直接用11.8、12.1也能正常运行，目前1.6最高支持到11.8，可以向下兼容，正常pip配置了正常的源可以自动下载。

验证

参考链接：

https://zhuanlan.zhihu.com/p/610628741

https://www.uisdc.com/47-stable-diffusion-models

https://zhuanlan.zhihu.com/p/622410028
https://aitechtogether.com/python/82781.html

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h3><p>stable diffusion做为目前AI绘图内开源的最强王者，本文主要在本地PC上部署使用是由Stability AI、CompVis與 使用DockerFile构建Bare Metal镜像 http://yoursite.com/2022/12/26/elemental/ 2022-12-26T13:45:59.000Z 2022-12-26T13:45:59.000Z Mutable和Immutable介绍

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。容器技术的最大创造就是通过Dockerfile将应用打包为容器镜像，实现了不可变基础设施，标准化了应用模板。
在容器之前叫Mutable（可变的基础设施）在OS上部署应用，重启生效，可以随时进行修改。

容器技术就是Immutable的代表，引入容器镜像，通过Dockerfile将应用标准化打包为容器镜像，通过容器镜像启动容器，无法在容器中进行永久性修改，需要修改只能通过更新Dockerfile方式进行。

现如今Immutable理念也开始逐步从容器下沉到Bare Metal OS，通过Dockerfile构建Bare Metal镜像，实现Bare Metal OS Immutable。

典型的开源项目技术Elemental项目

Elemental概述

Elemental 是一系列工具集合，主要是想通过 Kubernetes 实现集中式、完整的云原生操作系统构建和管理。

集群节点操作系统是通过Elemental CLI通过容器映像构建和维护的，并使用Elemental CLI安装在新主机上。
Elemental Operator和Rancher System Agent使Rancher Manager 能够完全控制 Elemental 集群，从在节点上安装和管理操作系统到以集中方式配置新的 K3s 或 RKE2 集群。

Elemental项目组成

  • elemental-toolkit - 包括一组操作系统实用程序，可通过容器启用操作系统管理。包括 dracut 模块、引导加载程序配置、cloud-init 自定义配置服务等。

  • elemental-operator - 这连接到 Rancher Manager 并处理 machineRegistration 和 machineInventory CRD

  • elemental-register - 这通过 machineRegistrations 注册机器并通过 elemental-cli 安装

  • elemental-cli - 这会安装任何基于 elemental-toolkit 的衍生工具。实现OCI容器镜像构建为可在虚拟机、物理机、嵌入式设备运行的ISO镜像。

  • rancher-system-agent - 在已安装的系统上运行并从 Rancher Manager 获取命令在系统上安装和运行rancher-agent，注册到Rancher中。

项目地址：https://github.com/rancher/elemental-toolkit

配置使用

在一台装有Docker的主机上进行

提前准备项：

  • 一台安装了Docker的主机
  • Harbor镜像仓库
  • EXSI或物理pc、服务器用于build后的ISO测试

使用Elemental-toolkit构建ISO流程

  • 基础base镜像发行版：
    teal: SLE Micro for Rancher based one, shipping packages from Sle Micro 5.3.
    green: openSUSE based one, shipping packages from OpenSUSE Leap 15.4 repositories.
    blue: Fedora based one, shipping packages from Fedora 33 repositories
    orange: Ubuntu based one, shipping packages form Ubuntu 20.10 repositories

  • 自定义镜像并制作OCI Image

  • 在装有Docker的机器启动Elemental Build
    UEFI Boot，选择合适的实例类型
    Clout-init userdata 初始化
    Default user/pass: root/cos

  • 升级自定义镜像
    elemental upgrade –no-verify –reboot -d niusmallnan/containeros:dev

在安装了Docker的主机上创建/root/derivative目录。

整体目录结构

/root/derivative/├── Dockerfile├── cloud-init.yaml├── install.sh├── installer.sh├── k3s├── k3s-airgap-images-amd64.tar.gz├── manifest.yaml├── nginx.yaml├── overlay│   └── iso│       └── boot│           └── grub2│               └── grub.cfg└── repositories.yaml

Demo架构

  • 通过Elemental构建的OS中包含K3S
  • 将需要部署的应用yaml放置到 /var/lib/rancher/k3s/server/manifests目录，K3S启动成功后会自动部署yaml启动应用。

下载K3S离线镜像包和CLI文件
https://github.com/k3s-io/k3s/releases

nginx.yaml文件用于k3s启动后加载此yaml文件，模拟演示是个应用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wanshaoyuan/nginx:v1.0
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30007

Dockerfile文件创建

ARG LUET_VERSION=0.32.0FROM quay.io/luet/base:$LUET_VERSION AS luetFROM registry.suse.com/suse/sle-micro-rancher/5.2ARG ARCH=amd64ENV ARCH=${ARCH}# Copy the luet config file pointing to the upgrade repositoryCOPY repositories.yaml /etc/luet/luet.yaml# Copy luet from the official imagesCOPY --from=luet /usr/bin/luet /usr/bin/luetENV LUET_NOLOCK=trueRUN luet install -y \       toolchain/yip \       toolchain/luet \       utils/installer \       system/cos-setup \       system/immutable-rootfs \       system/grub2-config \       system/base-dracut-modulesRUN  mkdir /var/lib/rancher/k3s/agent/images/ -p &&  mkdir /var/lib/rancher/k3s/server/manifests -pCOPY install.sh /system/oem/COPY k3s /usr/local/binCOPY nginx.yaml /system/oem/COPY k3s-airgap-images-amd64.tar.gz /system/oem/RUN  chmod a+x /usr/local/bin/k3s && chmod a+x /system/oem/install.shWORKDIR /system/oemRUN  INSTALL_K3S_SKIP_START="true" INSTALL_K3S_SKIP_ENABLE="true" INSTALL_K3S_SKIP_DOWNLOAD="true" sh install.sh## System layout# Required by k3s etc.RUN mkdir /usr/libexec && mkdir /usr/local/bin -p && touch /usr/libexec/.keep# Copy custom files# COPY files/ /# Copy cloud-init default configurationCOPY cloud-init.yaml /system/oem/# Generate initrdRUN mkinitrd# OS level configurationRUN echo "VERSION=999" > /etc/os-releaseRUN echo "GRUB_ENTRY_NAME=derivative" >> /etc/os-releaseRUN echo "welcome to our derivative" >> /etc/issue.d/01-derivative

cloud-init文件创建，主要用于磁盘分区配置和登录用户名和密码配置
cloud-init.yaml

name: "Default settings"stages:   initramfs:     # Setup default hostname     - name: "Branding"       hostname: "derivative"     # Setup an admin group with sudo access     - name: "Setup groups"       ensure_entities:       - entity: |            kind: "group"            group_name: "admin"            password: "x"            gid: 900                 # Setup network - openSUSE specific     - name: "Network setup"       files:       - path: /etc/sysconfig/network/ifcfg-eth0         content: |                  BOOTPROTO='dhcp'                  STARTMODE='onboot'                           permissions: 0600         owner: 0         group: 0     # Setup a custom user     - name: "Setup users"       users:       # Replace the default user name here and settings        joe:          # Comment passwd for no password          passwd: "joe"          shell: /bin/bash          homedir: "/home/joe"          groups:          - "admin"       #authorized_keys:       # Replace here with your ssh keys       # joe:        # - ssh-rsa ....     # Setup sudo     - name: "Setup sudo"       files:       - path: "/etc/sudoers"         owner: 0         group: 0         permsisions: 0600         content: |            Defaults always_set_home            Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"            Defaults env_reset            Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"            Defaults !insults            root ALL=(ALL) ALL            %admin ALL=(ALL) NOPASSWD: ALL            @includedir /etc/sudoers.d                   commands:       - passwd -l root   # Setup persistency so k3s works properly   # See also: https://rancher.github.io/elemental-toolkit/docs/reference/immutable_rootfs/#configuration-with-an-environment-file   rootfs.after:    - name: "Immutable Layout configuration"      environment_file: /run/cos/cos-layout.env      environment:        VOLUMES: "LABEL=COS_OEM:/oem LABEL=COS_PERSISTENT:/var"        OVERLAY: "tmpfs:25%"        RW_PATHS: "/usr/local /etc /srv"        PERSISTENT_STATE_PATHS: >-          /etc/systemd          /etc/rancher          /etc/ssh          /etc/iscsi           /etc/cni          /home          /opt          /root          /usr/libexec          /var/log          /var/lib/wicked          /var/lib/longhorn          /var/lib/cni          /usr/local/bin        PERSISTENT_STATE_TARGET: >-          /etc/systemd          /etc/rancher          /etc/ssh          /etc/iscsi          /etc/cni          /home          /opt          /root          /usr/libexec          /var/log          /var/lib/kubelet          /var/lib/wicked          /var/lib/longhorn          /var/lib/cni          /usr/local/bin        PERSISTENT_STATE_BIND: "true"   # Finally, let's start k3s when network is available, and download the SSH key from github for the joe user   network:     - name: "Deploy cos-system"       commands:         - elemental install /dev/sda          - systemctl enable k3s && systemctl start  k3s   after-install:     - name: "install k3s"       commands:         - mount /dev/sda5 /var         - mkdir -p  /var/lib/rancher/k3s/agent/images/  && mkdir /var/lib/rancher/k3s/server/manifests -p         - cp /system/oem/k3s-airgap-images-amd64.tar.gz  /var/lib/rancher/k3s/agent/images/         - cp /system/oem/nginx.yaml /var/lib/rancher/k3s/server/manifests         - reboot

创建manifest.yaml文件定义OS启动引导所需要文件

iso:  rootfs:    - channel:system/cos  uefi:    - channel:live/grub2-efi-image  image:    - channel:live/grub2    - channel:live/grub2-efi-image  label: "COS_LIVE"name: "cOS-0"# Raw disk creation values startraw_disk:  x86_64:    # which packages to install and the target to install them at    packages:      - name: channel:system/grub2-efi-image        target: efi      - name: channel:system/grub2-config        target: root      - name: channel:system/grub2-artifacts        target: root/grub2      - name: channel:recovery/cos-img        target: root/cOSrepositories:  - uri: quay.io/costoolkit/releases-teal    arch: "x86_64"

创建repositories.yaml文件

logging:  color: false  enable_emoji: falsegeneral:   debug: false   spinner_charset: 9repositories:- name: "cos"  description: "cOS official"  type: "docker"  enable: true  cached: true  priority: 1  verify: false  urls:  - "quay.io/costoolkit/releases-green"

创建grub文件配置内核引导
在/root/derivative/overlay/iso/boot/目录创建grub2grub.cfg文件

search --no-floppy --file --set=root /boot/kernelset default=0set timeout=10set timeout_style=menuset linux=linuxset initrd=initrdif [ "${grub_cpu}" = "x86_64" -o "${grub_cpu}" = "i386" -o "${grub_cpu}" = "arm64" ];then    if [ "${grub_platform}" = "efi" ]; then        if [ "${grub_cpu}" != "arm64" ]; then            set linux=linuxefi            set initrd=initrdefi        fi    fifiif [ "${grub_platform}" = "efi" ]; then    echo "Please press 't' to show the boot menu on this console"fiset font=($root)/boot/${grub_cpu}/loader/grub2/fonts/unicode.pf2if [ -f ${font} ];then    loadfont ${font}fimenuentry "cOS" --class os --unrestricted {    echo Loading kernel...    $linux ($root)/boot/kernel.xz cdroot root=live:CDLABEL=COS_LIVE rd.live.dir=/ rd.live.squashimg=rootfs.squashfs console=tty1 console=ttyS0 rd.cos.disable    echo Loading initrd...    $initrd ($root)/boot/rootfs.xz}if [ "${grub_platform}" = "efi" ]; then    hiddenentry "Text mode" --hotkey "t" {        set textmode=true        terminal_output console    }fi

先构建镜像

docker build -t 172.16.1.208/library/example:v4.0 .

镜像要上传到镜像仓库才能build iso

docker push 172.16.1.208/library/example:v4.0

构建ISO

1
docker run --rm -ti -v $(pwd):/build quay.io/costoolkit/elemental-cli:v0.0.15-ae4f000--config-dir /build --overlay-iso /build/overlay/iso --debug build-iso -o /build 172.16.1.208/library/example:v4.0

注：目前只支持公开的镜像仓库，不支持私有的镜像仓库
https://github.com/rancher/elemental-cli/issues/389

构建完成，生成此cOS-0.iso镜像文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
o250800372/iso / -chmod 0755 -- -boot_image grub bin_path=/boot/x86_64/loader/eltorito.img -boot_image grub grub2_mbr=/tmp/elemental-iso250800372/iso//boot/x86_64/loader/boot_hybrid.img -boot_image grub grub2_boot_info=on -boot_image any partition_offset=16 -boot_image any cat_path=/boot/x86_64/boot.catalog -boot_image any cat_hidden=on -boot_image any boot_info_table=on -boot_image any platform_id=0x00 -boot_image any emul_type=no_emulation -boot_image any load_size=2048 -append_partition 2 0xef /tmp/elemental-iso250800372/iso/boot/uefi.img -boot_image any next -boot_image any efi_path=--interval:appended_partition_2:all:: -boot_image any platform_id=0xef -boot_image any emul_type=no_emulation' 
DEBU[2023-03-12T11:54:38Z] Xorriso: xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev '/build/cOS-0.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 5851m free
xorriso : UPDATE : 623 files added in 1 seconds
Added to ISO image: directory '/'='/tmp/elemental-iso250800372/iso'
xorriso : NOTE : Copying to System Area: 512 bytes from file '/tmp/elemental-iso250800372/iso/boot/x86_64/loader/boot_hybrid.img'
xorriso : UPDATE : Writing:      24576s    6.5%   fifo 100%  buf  50%
xorriso : UPDATE : Writing:     221184s   58.1%   fifo 100%  buf  50%  415.0xD 
ISO image produced: 380645 sectors
Written to medium : 380656 sectors at LBA 48
Writing to '/build/cOS-0.iso' completed successfully.

将cOS-0.iso下载到ESXI或其他虚拟化平台也可以刻录U盘直接安装物理机。

配置选4c4G 60G磁盘


加载ISO后自动分区，自动进行初始化，安装系统，完成后自动重启进入系统。

密码ssh账号密码joe/joe


在安装后的系统查看已经部署好的K3S。

查看自动部署的应用


访问应用

因为整个系统都限制了修改，所以在操作系统任何目录执行修改命令都无法修改。如

1
2
3
4
5
6
7
8
9
rm -rf *

evice or resource busy
rm: cannot remove 'var/lib/kubelet/pods/cbf59b3a-d29a-4129-a3c9-8b79b1235104/volumes/kubernetes.io~projected/kube-api-access-zf8c5': Device or resource busy
rm: cannot remove 'var/lib/kubelet/pods/ea697a4c-8cb8-425f-8e50-6396f5669167/volumes/kubernetes.io~projected/kube-api-access-bq66h': Device or resource busy
rm: cannot remove 'var/lib/kubelet/pods/f18cd482-4c6f-4dd0-80fa-5fc314d3cc5b/volumes/kubernetes.io~projected/kube-api-access-8fdq7': Device or resource busy
rm: cannot remove 'var/lib/longhorn': Device or resource busy
rm: cannot remove 'var/lib/wicked': Device or resource busy
rm: cannot remove 'var/log': Device or resource busy
1
2
touch  1
touch: cannot touch '1': Read-only file system

总结

通过Elemental实现了操作系统为不变基础设施，同时也可以将我们传统的OS带入云原生，通过Dockerfile去构建，通过CICD去统一发版维护，目前能想到的一个比较大的应用场景在于，一个是边缘场景，边缘设备操作系统批量部署安装。另外就是一些to b的客户将自己业务+容器编排和OS通过Elemental构建打包，直接到客户现场加载ISO就部署完了，开箱即用。另外OS也可以标准化，统一化管理。

]]> <h3 id="Mutable和Immutable介绍"><a href="#Mutable和Immutable介绍" class="headerlink" title="Mutable和Immutable介绍"></a>Mutable和Immutable介绍</h3><p>云原 零信任与SPIFFE（一） http://yoursite.com/2022/11/17/spiffe/ 2022-11-17T13:45:59.000Z 2022-11-17T13:45:59.000Z 概述

传统的网络安全模型通过划分不同的网络分区，同一个网络分区是可信的，不同网络分区之间通过防火墙隔断。这种方式在云原生时代已经变得不可适用了。
1、同一网络分区内流量无法进行管控，特别是是如今随着容器大规模落地，容器IP又不是二层可见和固定的无法进行安全管控。

2、传统网络边界防火墙采用静态方式配置规则，对于云原生这类动态变化的环境无法适应。
零信任安全框架在此背景下提出。
零信任是默认不信任使用，除非通过验证。通过身份认证，访问策略控制，实现最小权限访问控制。零信任安全的本质是以身份为中心进行动态访问控制，SPIFFE项目（Secure Product Identity Framework For Everyone）通用安全身份框架 。通过X.509 证书的形式为生产环境中的每个工作负载提供安全身份分发，认证。

https://spiffe.io/
SPIFFE本身也是开源项目，目前托管在CNCF基金会，在2022年9月正式毕业。

SPIFFE

架构和概念解析

SPIFFE ( Secure Production Identity Framework For Everyone )：通用安全身份认证框架。
SPIRE ( SPIFFE Runtime Environment )：是 SPIFFE 标准的一套生产就绪实现，它执行节点证明和工作负载证明，可以安全地向服务颁发身份凭证，并根据预定义的条件集合验证其他服务的身份。
https://github.com/spiffe/spire

Spire由SPIRE-Server和一个或多个SPIRE-Agent组成。

Server端充当签名机构（CA）通过Agent颁发给工作负载的证书。它还进行证书维护和验证。

Agent运行在每个workload所在节点上，作用是从Server端接受证书，并将其存储在缓存中。另外是对workload暴露SPIFFE Workload API 充当 SDS（secret discovery service）角色处理整个mTLs流量进行证书交互和验证

SPIFFE安全框架主要包含以下部分：

SPIFFE ID：用于标识对应信任域的工作负载，类似URI格式的字符串包含以下

由spiffe://信任域的名字/工作负载名字或对应的身份标识

SVID（SPIFFE Verifiable Identity Document）：
svid可以是两种格式之一\:X.509证书或jwt。证书svid可用于建立端到端相互TLS
加密连接。jwt在端到端相互TLS加密不需要或不需要的情况下非常有用，例如当
使用负载均衡器。jwt对于已经支持基于jwt的身份验证的各种云服务的身份验证也很有用。无论是使用JWT SVIDs还是X.509 SVIDs, SPIFFE id、信任包格式和工作负载API都是相同的。

Trust Bundle：用于验证svid的公钥集

Workload API：工作负载通过此api获取对应的SPIFFE ID、SVID、Trust Bundle。

SPIFFE 联邦：不同信任域共享SPIFFE信任包，比如数据中心A的Spire环境与数据中心B的Spire环境建立联邦关系就可以互相配置和检查

注：这里写的workload（工作负载）并不等同于k8s里面的workload，主要指的是需要接入SPIFFE的对象可以是docker容器、VM、k8s-pod等等。

演示

软件版本：
1、kubernetes v1.24.8
2、Spire：v1.5.3

Spire部署

部署local-path-provisioner
因为Spire-Server为有状态服务，依赖存储，所以这里部署local-path-provisioner
并设置为默认StorageClass

https://github.com/rancher/local-path-provisioner.git

完成后 

1
2
3
4
5
kubectl get sc

NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE

local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  2d7h

部署Spire-server和Spire-agent
clone此项目

1
git clone https://github.com/spiffe/spire-tutorials

切换到spire-tutorials/k8s/quickstart目录

1
kubectl apply -f spire-namespace.yaml

配置spire-server权限 

1
2
3
4
5
6
7
kubectl apply \

    -f server-account.yaml \

    -f spire-bundle-configmap.yaml \

    -f server-cluster-role.yaml

部署Spire-server 

1
2
3
4
5
6
7
kubectl apply \

    -f server-configmap.yaml \

    -f server-statefulset.yaml \

    -f server-service.yaml

查看部署状态 

1
2
3
4
5
kubectl get statefulset --namespace spire

NAME           READY   AGE

spire-server   1/1     2d8h

部署spire-agent
1、配置权限 

1
2
3
4
5
kubectl apply \

    -f agent-account.yaml \

    -f agent-cluster-role.yaml

2、部署spire-agent 

1
2
3
4
5
kubectl apply \

    -f agent-configmap.yaml \

    -f agent-daemonset.yaml

3、检查 

1
2
3
4
5
kubectl get daemonset --namespace spire

NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE

spire-agent   2         2         2       2            2           <none>          2d8h

4、注册spire-agent 

1
2
3
4
5
6
7
8
9
10
11
12
13
kubectl exec -n spire spire-server-0 -- \

    /opt/spire/bin/spire-server entry create \

    -spiffeID spiffe://example.org/ns/spire/sa/spire-agent \

    -selector k8s_sat:cluster:demo-cluster \

    -selector k8s_sat:agent_ns:spire \

    -selector k8s_sat:agent_sa:spire-agent \

    -node
1
2
3
4
5
6
7
8
9
10
11
kubectl exec -n spire spire-server-0 -- \

    /opt/spire/bin/spire-server entry create \

    -spiffeID spiffe://example.org/ns/default/sa/default \

    -parentID spiffe://example.org/ns/spire/sa/spire-agent \

    -selector k8s:ns:default \

    -selector k8s:sa:default

5、验证
Spire-agent默认会将socket文件映射到k8s集群主机的/run/spire/sockets/agent.sock，部署测试容器查看 

1
kubectl apply -f client-deployment.yaml

验证容器是否可以访问socket 

1
2
3
kubectl exec -it $(kubectl get pods -o=jsonpath='{.items[0].metadata.name}' \

   -l app=client)  -- /opt/spire/bin/spire-agent api fetch -socketPath /run/spire/sockets/agent.sock

如果agent正常运行，将看到一个 SVID 列表。 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
SPIFFE ID:              spiffe://example.org/ns/default/sa/default

SVID Valid After:       2022-12-25 11:41:16 +0000 UTC

SVID Valid Until:       2022-12-25 12:41:26 +0000 UTC

CA #1 Valid After:      2022-12-23 15:04:07 +0000 UTC

CA #1 Valid Until:      2022-12-24 15:04:17 +0000 UTC

CA #2 Valid After:      2022-12-24 03:04:07 +0000 UTC

CA #2 Valid Until:      2022-12-25 03:04:17 +0000 UTC

CA #3 Valid After:      2022-12-24 15:04:07 +0000 UTC

CA #3 Valid Until:      2022-12-25 15:04:17 +0000 UTC

CA #4 Valid After:      2022-12-25 03:04:07 +0000 UTC

CA #4 Valid Until:      2022-12-26 03:04:17 +0000 UTC

Demo应用部署
本次演示
将Envoy与X.509-SVID结合使用保护微服务通信

如图所示，前端服务通过sidecar Envoy执行X.509 SVID 身份验证与实例建立的起mTLS连接，连接到后端服务。

SPIRE Agent原生支持做为Envoy的SDS服务。通过本地socket连接SDS服务。

切换到spire-tutorials/k8s/envoy-x509目录

部署应用 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
kubectl apply -k k8s/.

configmap/backend-balance-json-data created

configmap/backend-envoy created

configmap/backend-profile-json-data created

configmap/backend-transactions-json-data created

configmap/frontend-2-envoy created

configmap/frontend-envoy created

configmap/symbank-webapp-2-config created

configmap/symbank-webapp-config created

service/backend-envoy created

service/frontend-2 created

service/frontend created

deployment.apps/backend created

deployment.apps/frontend-2 created

deployment.apps/frontend created

以backend模块为例
查看k8s/backend/config/envoy.yaml文件，可以科技Envoy配置的与spire-agent的socket连接

1
2
3
4
5
6
7
8
9
10
11
12
13
clusters:

- name: spire_agent

  connect_timeout: 0.25s

  http2_protocol_options: {}

  hosts:

    - pipe:

        path: /run/spire/sockets/agent.sock

手动将backend、frontend、frontend-2注册到sprie-server，当然SPIFFE也有自动正常功能就是使用SPIRE Controller Manager 模块（https://github.com/spiffe/spire-controller-manager） 

1
bash create-registration-entries.sh

注册完成后可以查看注册的服务 

1
kubectl exec -n spire spire-server-0 -c spire-server -- /opt/spire/bin/spire-server  entry show -selector k8s:ns:default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
Found 4 entries

Entry ID         : 3478c441-3e25-40e7-96d9-ef74611f2205

SPIFFE ID        : spiffe://example.org/ns/default/sa/default

Parent ID        : spiffe://example.org/ns/spire/sa/spire-agent

Revision         : 0

X509-SVID TTL    : default

JWT-SVID TTL     : default

Selector         : k8s:ns:default

Selector         : k8s:sa:default

Entry ID         : c188d47c-e886-492e-bf67-6a6bf42c3667

SPIFFE ID        : spiffe://example.org/ns/default/sa/default/backend

Parent ID        : spiffe://example.org/ns/spire/sa/spire-agent

Revision         : 0

X509-SVID TTL    : default

JWT-SVID TTL     : default

Selector         : k8s:container-name:envoy

Selector         : k8s:ns:default

Selector         : k8s:pod-label:app:backend

Selector         : k8s:sa:default

Entry ID         : 6c376401-67d4-499a-a9d9-6ab71caf69c4

SPIFFE ID        : spiffe://example.org/ns/default/sa/default/frontend

Parent ID        : spiffe://example.org/ns/spire/sa/spire-agent

Revision         : 0

X509-SVID TTL    : default

JWT-SVID TTL     : default

Selector         : k8s:container-name:envoy

Selector         : k8s:ns:default

Selector         : k8s:pod-label:app:frontend

Selector         : k8s:sa:default

Entry ID         : 49f88c69-b4ee-4656-b740-6dbee5bb89a3

SPIFFE ID        : spiffe://example.org/ns/default/sa/default/frontend-2

Parent ID        : spiffe://example.org/ns/spire/sa/spire-agent

Revision         : 0

X509-SVID TTL    : default

JWT-SVID TTL     : default

Selector         : k8s:container-name:envoy

Selector         : k8s:ns:default

Selector         : k8s:pod-label:app:frontend-2

Selector         : k8s:sa:default

可以看见对应的SPIFFE ID

访问服务 

1
2
3
4
5
6
7
8
9
10
11
12
13
kubectl get svc

NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE

backend-envoy   ClusterIP      None            <none>        9001/TCP         2d8h

frontend        LoadBalancer   10.43.106.227   <pending>     3000:32082/TCP   2d8h

frontend-2      LoadBalancer   10.43.203.167   <pending>     3002:30664/TCP   2d8h

go-demo         NodePort       10.43.120.2     <none>        8080:30007/TCP   2d10h

kubernetes      ClusterIP      10.43.0.1       <none>        443/TCP          2d10h

frontend对应的NodePort端口为32082

frontend-2对应的NodePort端口为30664

frontend显示Jacob Marley的账户情况

frontend-2显示Alex Fergus的账户情况

更新策略只允许frontend服务访问backend访问

1
kubectl apply -f backend-envoy-configmap-update.yaml

实际上就是更新backend的Envoy配置对应的 k8s/backend/config/envoy.yaml
删除了以下条目 

1
- exact: "spiffe://example.org/ns/default/sa/default/frontend-2"
1
2
3
4
5
match_subject_alt_names:

                - exact: "spiffe://example.org/ns/default/sa/default/frontend"

                - exact: "spiffe://example.org/ns/default/sa/default/frontend-2"

重启backend服务获取最新配置 

1
2
3
kubectl scale deployment backend --replicas=0

kubectl scale deployment backend --replicas=1

在次访问frontend正常显示，访问frontend-2

总结

SPIFFE支持多种方式集成如和Istio的envoy-sidecar、OPA策略等方式，可以非常灵活细粒化控制应用访问权限。

参考链接：
https://jimmysong.io/blog/why-istio-need-spire/
https://mp.weixin.qq.com/s/4eEEYb8RuOFOmLcdL3N6wA
https://atbug.com/what-is-spiffe-and-spire/
https://www.nginx-cn.net/blog/mtls-architecture-nginx-service-mesh/

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a><a href="#%E6%A6%82%E8%BF%B0" title="概述"></a>概述</h3><p>传统的网络安全模型通过划分不同的网络分区，同一个网 eBPF学习摘要3-XDP学习和理解 http://yoursite.com/2022/10/17/ebpf_3/ 2022-10-17T13:45:59.000Z 2022-10-17T13:45:59.000Z eBPF学习摘要3-XDP学习和理解

概述

Linux网络数据包接收数据包的链路为Nic——>rx_ring——>skbuff——>网络协议处理（如ip_recv)这样做的问题在于会产生大量内核态到用户态的切换过程，这会造成大量性能消耗，所以为了提升网络性能才诞生出Kernel bypass的技术如DPDK、SolarFlare技术，像DPDK就是直接饶过内核态，用户态应用直接访问网络硬件提高数据包处理效率，降低因为切换带来的损耗，但这种方式本身也存在一些缺点：1、绕开了内核态，很难与Linux操作系统中内核态本身存在的一些工具集成，一些功能需要重新开发。2、需要单独cpu核参与处理。
XDP（eXpress Data Path）是一个eBPF hook，可以在内核中执行eBPF程序实现对网络数据包处理，在Linux内核 4.8 版中引入。实现方式与Kernel bypass完全相反在sk_buffer之前数据包从driver出来以后就可以直接被XDP程序捕获执行，极大提升了网络数据包的处理效率。

实现方式

如下图所示

1、数据包通过网卡,触发XDP执行
2、xdp程序执行读取BPF mps配置的规则对数据包执行相应的操作，通常为
（1）XDP_DROP：直接丢弃，不占用CPU资源，有效防止DDOS
（2）XDP_Allow：正常转发到内核网络栈
（3）XDP_REDIRECT:重定向到其他网卡，或通过AF_XDP直接发送到用户空间。
（4）XDP_TX:将处理后的包发给相同的网卡。

三种处理模式:

XDP在网络栈中有三个处理点：
offloaded模式的XDP：对于支持可编程的网卡，直接在网卡上运行XDP程序。
Native模式的XDP：默认模式、对于支持的网卡驱动，可以在包到达内核后立刻进行处理。（目前大部分网卡已经支持）

Offloaded和Native模式

Generic模式的XDP：网卡和驱动不支持上述两种情况的XDP时，可以在receive_skb函数此点进行处理。这个处理的位置相对靠后，在tc处理点之前，这种性能最差，一般用于测试调试模式。

应用场景

性能测试

https://people.netfilter.org/hawk/presentations/KernelRecipes2018/XDP_Kernel_Recipes_2018.pdf
http://vger.kernel.org/lpc_net2018_talks/lpc18-xdp-future.pdf
https://blog.cloudflare.com/how-to-drop-10-million-packets/
https://blog.csdn.net/hbhgyu/article/details/109354273
这里面包含了对丢包性能、转发性能、DDos防御能力的测试。

总结：

随着eBPF技术的持续发展，XDP能够实现DPDK相近的性能，但又更具有兼容性和灵活性，未来会得到越来越好的发展，围绕eBPF和XDP的生态软件也会越来越丰富。

参考链接：
https://zhuanlan.zhihu.com/p/453005342
https://zhuanlan.zhihu.com/p/438158551
https://mp.weixin.qq.com/s/H9imUbdJnfj1NKdK9jtxEw
https://zhuanlan.zhihu.com/p/321387418
https://mp.weixin.qq.com/s/lUvxUkFg4w1X0ioktxGiHA
https://www.seekret.io/blog/a-gentle-introduction-to-xdp/

]]> <h2 id="eBPF学习摘要3-XDP学习和理解"><a href="#eBPF学习摘要3-XDP学习和理解" class="headerlink" title="eBPF学习摘要3-XDP学习和理解"></a>eBPF学习摘要3-XDP学习和理解</h2><h3 id="概 eBPF学习摘要2—工具使用(bpftrace） http://yoursite.com/2022/09/18/ebpf_2/ 2022-09-18T13:45:59.000Z 2022-09-18T13:45:59.000Z 概述

bpftrace是基于eBPF实现的动态的工具，使用DSL（Domain Specific Language）编写eBPF程序，使用LLVM编译eBPF字节码，BCC与LinuxBPF系统交互。直接使用DSL编写好的脚本（类似awk语言）可以执行，无需在内核中手动编译和加载。bpftrace在内核中实现动态追踪主要是使用Kprobe探针和Tracepoints探针。使用bpftrace可以更深入的进行操作系统上问题排查，如某个函数的调用次数和延时、追踪系统OOMKILL、TCP连接丢包等。都可以自定义脚本实现。
另外还有一个叫BCC的项目，跟bpftrace区别是BCC可以使用高级语言开发ebfp程序，如Java、Python、Lua……

https://github.com/iovisor/bpftrace
https://github.com/iovisor/bcc

安装和基础使用

系统环境：
ubuntu：20.04
Kernel：5.4.0-125-generic

参考官网安装方式
https://github.com/iovisor/bpftrace/blob/master/INSTALL.md
有各操作系统发行版的安装方式，也有基于Docker的安装方式
我这里为Ubuntu20.04的操作系统，先使用Ubuntu的安装方式进行安装，因为bpftrace依赖ebpf能力，对应不同的内核版本实现的功能有所差异，如4.1 版本实现了kprobes、4.7版本实现了tracepoints官方提供了环境需求检测脚本可以实现对现有环境检测https://github.com/iovisor/bpftrace/blob/master/scripts/check_kernel_features.sh
执行后 

1
2
3
./check_kernel_features.sh

All required features present!

安装bpftrace 

1
2
sudo apt-get install -y bpftrace bpfcc-tools

安装完成后查看版本 

1
2
3
bpftrace --version

bpftrace v0.9.4

列出当前内核支持的Kprobes探针列表 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
bpftrace -l 'kprobe:tcp*

kprobe:tcp_mmap

kprobe:tcp_get_info_chrono_stats

kprobe:tcp_init_sock

kprobe:tcp_splice_data_recv

kprobe:tcp_push

kprobe:tcp_send_mss

kprobe:tcp_cleanup_rbuf

kprobe:tcp_set_rcvlowat

kprobe:tcp_recv_timestamp

kprobe:tcp_enter_memory_pressure

kprobe:tcp_leave_memory_pressure

kprobe:tcp_ioctl

kprobe:tcp_get_info

kprobe:tcp_get_md5sig_pool

kprobe:tcp_set_state

kprobe:tcp_shutdown

...

内核静态探针-Tracepoint 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
bpftrace -l 'tracepoint:*'

kprobe:tcp_mmap

kprobe:tcp_get_info_chrono_stats

kprobe:tcp_init_sock

kprobe:tcp_splice_data_recv

kprobe:tcp_push

kprobe:tcp_send_mss

kprobe:tcp_cleanup_rbuf

kprobe:tcp_set_rcvlowat

kprobe:tcp_recv_timestamp

kprobe:tcp_enter_memory_pressure

kprobe:tcp_leave_memory_pressure

kprobe:tcp_ioctl

kprobe:tcp_get_info

kprobe:tcp_get_md5sig_pool

kprobe:tcp_set_state

kprobe:tcp_shutdown

tracepoint:nfsd:nfsd_compound

tracepoint:nfsd:nfsd_compound_status

tracepoint:nfsd:nfsd_read_start

tracepoint:nfsd:nfsd_read_splice

tracepoint:nfsd:nfsd_read_vector

tracepoint:nfsd:nfsd_read_io_done

tracepoint:nfsd:nfsd_read_done

tracepoint:nfsd:nfsd_write_start

tracepoint:nfsd:nfsd_write_opened

tracepoint:nfsd:nfsd_write_io_done

tracepoint:nfsd:nfsd_write_done

tracepoint:nfsd:nfsd_read_err

tracepoint:nfsd:nfsd_write_err

tracepoint:nfsd:nfsd_layoutstate_alloc

tracepoint:nfsd:nfsd_layoutstate_unhash

...

例如列出所有的进程打开的文件 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

kubelet /sys/fs/cgroup/memory/kubepods.slice/memory.numa_stat

kubelet /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/cpu.stat

kubelet /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/cpuacct.stat

kubelet /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/cpuacct.usage

kubelet /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/cpuacct.usage_percpu

kubelet /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/cpuacct.usage_all

kubelet /sys/fs/cgroup/pids/kubepods.slice/pids.current

kubelet /sys/fs/cgroup/pids/kubepods.slice/pids.max

kubelet /sys/fs/cgroup/blkio/kubepods.slice/blkio.bfq.sectors_recursive

kubelet /sys/fs/cgroup/blkio/kubepods.slice/blkio.bfq.io_serviced_recur

kubelet /sys/fs/cgroup/blkio/kubepods.slice/blkio.sectors_recursive

kubelet /sys/fs/cgroup/blkio/kubepods.slice/blkio.throttle.io_serviced_

...

ctrl+c暂停
也可以将复杂的命令写成脚本执行，默认安装完后，在/usr/sbin/目录下已经集成了很多脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
ls /usr/sbin/|grep ".*.bt"

bashreadline.bt

biolatency.bt

biosnoop.bt

biostacks.bt

bitesize.bt

capable.bt

cpuwalk.bt

dcsnoop.bt

ebtables

ebtables-nft

ebtables-nft-restore

ebtables-nft-save

ebtables-restore

ebtables-save

execsnoop.bt

gethostlatency.bt

killsnoop.bt

loads.bt

mdflush.bt

naptime.bt

oomkill.bt

opensnoop.bt

pidpersec.bt

runqlat.bt

runqlen.bt

setuids.bt

statsnoop.bt

swapin.bt

syncsnoop.bt

syscount.bt

tcpaccept.bt

tcpconnect.bt

tcpdrop.bt

tcplife.bt

tcpretrans.bt

tcpsynbl.bt

threadsnoop.bt

vfscount.bt

vfsstat.bt

writeback.bt

xfsdist.bt

https://github.com/iovisor/bpftrace/tree/master/tools 也存在很多脚本和测试用例。

比如执行tcpconnect.bt 可以参考到本机所有的TCP网络连接 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
tcpconnect.bt 

Attaching 2 probes...

Tracing tcp connections. Hit Ctrl-C to end.

TIME     PID      COMM             SADDR                                   SPORT  DADDR                                   DPORT 

23:02:09 1686607  coredns          127.0.0.1                               42216  127.0.0.1                               13429 

23:02:10 1686607  coredns          127.0.0.1                               42218  127.0.0.1                               13429 

23:02:11 1680193  kubelet          10.0.1.11                               34732  10.0.1.15                               13429 

23:02:11 1680193  kubelet          10.0.1.11                               41570  10.0.1.244                              13429 

23:02:11 1686607  coredns          127.0.0.1                               42224  127.0.0.1                               13429 

23:02:11 1680193  kubelet          127.0.0.1                               55010  127.0.0.1                               13429 

23:02:11 1680193  kubelet          10.0.1.11                               33098  10.0.1.145                              13429 

23:02:12 1686607  coredns          127.0.0.1                               42230  127.0.0.1                               13429 

23:02:13 1680193  kubelet          127.0.0.1                               34214  127.0.0.1                               13429 

23:02:13 1686607  coredns          127.0.0.1                               42234  127.0.0.1                               13429

追踪全系统范围内open()调用 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
opensnoop.bt

Attaching 6 probes...

Tracing open syscalls... Hit Ctrl-C to end.

PID    COMM               FD ERR PATH

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/087/0872950b-6ca9-420e-8872-9

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/087/0872950b-6ca9-420e-8872-9

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/435/435debae-6288-4661-835d-e

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/435/435debae-6288-4661-835d-e

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/092/09246824-dd69-4f4c-8924-6

1686817 AsyncBlockInput     2   0 /var/lib/clickhouse_storage/store/092/09246824-dd69-4f4c-8924-6

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

1680193 kubelet             2   0 /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/

展示最消耗IO的进程及数据写入量

1
2
3
4
5
6
7
8
9
10
11
biotop-bpfcc

20:53:20 loadavg: 0.96 1.40 1.26 2/2392 3295655

PID    COMM             D MAJ MIN DISK       I/O  Kbytes  AVGms

337    jbd2/vda1-8      W 252 0   vda          2   412.0   5.16

1680139 etcd             W 252 0   vda         14    60.0   2.61

3295622 rancher-system-  R 252 0   vda          1    56.0   2.07

查看每个进程对应的执行命令和参数 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
execsnoop-bpfcc -T

TIME     PCOMM            PID    PPID   RET ARGS

21:22:05 rancher-system-  3310507 1        0 /usr/local/bin/rancher-system-agent sentinel

21:22:06 cilium-cni       3310516 1680193   0 /opt/cni/bin/cilium-cni

21:22:06 iptables         3310525 1680164   0 /usr/sbin/iptables -w 5 -W 100000 -S KUBE-PROXY-CANARY -t mangle

21:22:06 ip6tables        3310524 1680164   0 /usr/sbin/ip6tables -w 5 -W 100000 -S KUBE-PROXY-CANARY -t mangle

21:22:06 nsenter          3310526 1680193   0 /usr/bin/nsenter --net=/proc/1688099/ns/net -F -- ip -o -4 addr show dev eth0 scope global

21:22:06 ip               3310526 1680193   0 /usr/sbin/ip -o -4 addr show dev eth0 scope global

21:22:06 nsenter          3310527 1680193   0 /usr/bin/nsenter --net=/proc/1688099/ns/net -F -- ip -o -6 addr show dev eth0 scope global

21:22:06 ip               3310527 1680193   0 /usr/sbin/ip -o -6 addr show dev eth0 scope global

21:22:06 runc             3310528 1679752   0 /usr/bin/runc --version

21:22:06 docker-init      3310534 1679752   0 /usr/bin/docker-init --version

常用的一些脚本作用

  • killsnoop.bt——追踪 kill() 系统调用发出的信号
  • tcpconnect.bt——追踪所有的 TCP 网络连接
  • pidpersec.bt——统计每秒钟（通过fork）创建的新进程
  • opensnoop.bt——追踪 open() 系统调用
  • bfsstat.bt——追踪一些 VFS 调用，按秒统计
  • bashreadline.bt——打印从所有运行shell输入的bash命令
  • tcplife.bt——追踪TCP连接生命周期
  • biotop-bpfcc——展示进程io写入

bpftrace执行原理


用户态
1、用户编写 eBPF 程序，可以使用 eBPF 汇编或者 eBPF 特有的 C 语言来编写。
2、使用 LLVM/CLang 编译器，将 eBPF 程序编译成 eBPF 字节码。
3、调用 bpf() 系统调用把 eBPF 字节码加载到内核。

内核态
1、当用户调用 bpf() 系统调用把 eBPF 字节码加载到内核时，内核先会对 eBPF 字节码进行安全验证。
2、使用 JIT（Just In Time）技术将 eBPF 字节编译成本地机器码（Native Code）。
3、然后根据 eBPF 程序的功能，将 eBPF 机器码挂载到内核的不同运行路径上（如用于跟踪内核运行状态的 eBPF 程序将会挂载在 kprobes 的运行路径上）。当内核运行到这些路径时，就会触发执行相应路径上的 eBPF 机器码。
4、通过map与用户空间程序交互

总结
通过bpftrace和bcc可以很形象了解ebpf特性，无需修改内核源码和重新编译内核就可以扩展内核的功能，除了像bpftrace这类追踪类软件，还有通过ebfp实现的POD安全威胁检测Falco、基于ebpf负载均衡器Katran等开源产品。另外ebpf_exporter组件也可以将自定义的ebpf执行脚本输出到Prometheus中进行监控。ebpf的生态将越来越丰富。

Perf工具使用

Perf（Performance Event）是在Linux Kernel2.6集成在Linux Kernel中，主要利用CPU中PMU (Performance Monitoring Unit)和Linux中的 tracepoint实现目标取样和性能分析。Perf工具根eBPF实际上没什么关系，这里写这个工具主要是因为它本身也可以实现应用程序动态追踪，也利用到了tracepoint的能力，但与eBPF不同的是Perf是写死的能力，bpftrace基于eBPF是可以实现脚本灵活的穿插和调用。

安装部署
这里使用的操作系统是Ubuntu20.04。Kernel为5.4.0-125-generic

1
2
3
sudo apt-get install linux-tools-common linux-tools-"``(uname -r)" linux-cloud-tools-"``(uname -r)" linux-tools-generic linux-cloud-tools-generic


验证版本 

1
2
3
perf -v

perf version 5.4.195

采样事件 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
perf list

List of pre-defined events (to be used in -e):

  alignment-faults                                   [Software event]

  bpf-output                                         [Software event]

  context-switches OR cs                             [Software event]

  cpu-clock                                          [Software event]

  cpu-migrations OR migrations                       [Software event]

  dummy                                              [Software event]

  emulation-faults                                   [Software event]

  major-faults                                       [Software event]

  minor-faults                                       [Software event]

  page-faults OR faults                              [Software event]

  task-clock                                         [Software event]

  duration_time                                      [Tool event]

  msr/tsc/                                           [Kernel PMU event]

  rNNN                                               [Raw hardware event descriptor]

  cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]

   (see 'man perf-list' on how to encode it)

  mem:<addr>[/len][:access]                          [Hardware breakpoint]

  alarmtimer:alarmtimer_cancel                       [Tracepoint event]

  alarmtimer:alarmtimer_fired                        [Tracepoint event]

  ...

主要分为三类：
Hardware Event ：通过PMU获取的硬件CPU的事件，如：cpu-cycles、缓存命中等。
Software Event ：软件本身的进程切换和页命中等
Tracepoint event：io命中率、文件系统写入速率等

perf top展示各个进程和函数资源占用情况，-g显示子进程，按e显示子进程函数 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
perf top -g 

Samples: 284K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 33836570425 lost: 0/0 drop: 0/0

  Children      Self  Shared Object                                          Symbol

-   20.27%     0.09%  perf                                                   [.] __ordered_events__flush.part.0                                                            ◆

   - 2.20% __ordered_events__flush.part.0                                                                                                                                  ▒

      - 2.56% deliver_event                                                                                                                                                ▒

         - 3.39% hist_entry_iter__add                                                                                                                                      ▒

            - 3.79% iter_add_next_cumulative_entry                                                                                                                         ▒

               - 3.03% __hists__add_entry.constprop.0                                                                                                                      ▒

                    3.79% hists__findnew_entry                                                                                                                             ▒

               - 1.54% callchain_append                                                                                                                                    ▒

                  - 2.64% append_chain_children                                                                                                                            ▒

                     - 2.22% append_chain_children                                                                                                                         ▒

                        - 1.73% append_chain_children                                                                                                                      ▒

                           - 1.34% append_chain_children                                                                                                                   ▒

                                1.07% append_chain_children                                                                                                                ▒

+   20.13%     0.18%  perf                                                   [.] deliver_event                                                                             ▒

+   18.62%     0.04%  perf                                                   [.] hist_entry_iter__add                                                                      ▒

+   14.47%     0.80%  perf                                                   [.] iter_add_next_cumulative_entry                                                            ▒

+   12.05%     0.96%  [kernel]                                               [k] do_syscall_64                                                                             ▒

+    8.99%     0.00%  perf                                                   [.] process_thread                                                                            ▒

+    8.93%     0.22%  [kernel]                                               [k] do_idle                                                                                   ▒

+    8.83%     1.06%  [kernel]                                               [k] __softirqentry_text_start                                                                 ▒

+    8.24%     6.28%  perf                                                   [.] append_chain_children                                                                     ▒

+    7.11%     0.06%  perf                                                   [.] callchain_append                                                                          ▒

+    5.96%     4.75%  libc-2.31.so                                           [.] pthread_attr_setschedparam                                                                ▒

+    5.74%     0.25%  perf                                                   [.] __hists__add_entry.constprop.0


[.]：表示运行在用户态空间
[k]：表示运行在内核态空间

perf state查看程序运行情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
perf stat -p 1679752   按ctrl+c输出结果

 Performance counter stats for process id '1679752':

            682.90 msec task-clock                #    0.066 CPUs utilized          

              3154      context-switches          #    0.005 M/sec                  

                36      cpu-migrations            #    0.053 K/sec                  

              3275      page-faults               #    0.005 M/sec                  

   <not supported>      cycles                                                      

   <not supported>      instructions                                                

   <not supported>      branches                                                    

   <not supported>      branch-misses

Task-clock：CPU 利用率
Context-switches：进程切换次数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Samples: 1K of event 'block:block_rq_issue', 1 Hz, Event count (approx.): 136 lost: 0/0 drop: 0/0

  Children      Self  Trace output

+   16.91%    16.91%  252,0 FF 0 () 0 + 0 [kworker/0:1H]

+   15.44%    15.44%  252,0 FF 0 () 0 + 0 [kworker/7:1H]

+    9.56%     9.56%  252,0 FF 0 () 0 + 0 [kworker/3:1H]

+    8.09%     8.09%  252,0 FF 0 () 0 + 0 [kworker/4:1H]

+    6.62%     6.62%  252,0 WS 4096 () 18340064 + 8 [etcd]

+    6.62%     6.62%  252,0 WS 4096 () 18340072 + 8 [etcd]

+    5.15%     5.15%  252,0 FF 0 () 0 + 0 [kworker/2:1H]

+    4.41%     4.41%  252,0 FF 0 () 0 + 0 [kworker/6:1H]

+    2.94%     2.94%  252,0 WS 4096 () 122005280 + 8 [etcd]

     2.21%     2.21%  252,0 WS 4096 () 115952144 + 8 [etcd]

     2.21%     2.21%  252,0 WS 4096 () 122005272 + 8 [etcd]

+    1.47%     1.47%  252,0 FF 0 () 0 + 0 [kworker/1:1H]

+    1.47%     1.47%  252,0 WS 4096 () 116164552 + 8 [etcd]

     1.47%     1.47%  252,0 WS 4096 () 116173824 + 8 [etcd]

+    1.47%     1.47%  252,0 WS 4096 () 122005256 + 8 [etcd]

     1.47%     1.47%  252,0 WS 4096 () 122005288 + 8 [etcd]

     1.47%     1.47%  252,0 WS 4096 () 122005296 + 8 [etcd]

     0.74%     0.74%  252,0 FF 0 () 0 + 0 [kworker/5:1H]

     0.74%     0.74%  252,0 WS 516096 () 2388520 + 1008 [jbd2/vda1-8]

     0.74%     0.74%  252,0 WS 372736 () 2389528 + 728 [jbd2/vda1-8]

     0.74%     0.74%  252,0 WS 4096 () 115700160 + 8 [etcd]

     0.74%     0.74%  252,0 WS 4096 () 115948608 + 8 [etcd]

对CPU事件进行检测，采样时间60s，每秒采样99个事件，采样完成后会在本地生成个perf.data文件，如果执行多次，会将上一个重命名为perf.data.old。加-p可以指定进程号输出。 

1
2
perf record -F 99 -a -g -- sleep 60

查看报告 

1
perf report

生成火焰图 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
下载制作火焰图工具

git clone https://github.com/brendangregg/FlameGraph.git

对perf.data进行解析

perf script -i perf.data &> perf.unfold

进行符号处理

FlameGraph/stackcollapse-perf.pl perf.unfold &> perf.folded

生成火焰图

FlameGraph/flamegraph.pl perf.folded > perf.svg

使用chrome浏览器打开

火焰图怎么查看分析可参考
https://www.infoq.cn/article/a8kmnxdhbwmzxzsytlga

参考链接
https://github.com/iovisor/bpftrace/blob/master/docs/reference_guide.md
http://blog.nsfocus.net/bpftrace-dynamic-tracing-0828/
https://www.cnblogs.com/arnoldlu/p/6241297.html
https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/counting-events-during-process-execution-with-perf-stat_monitoring-and-managing-system-status-and-performance

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a><a href="#%E6%A6%82%E8%BF%B0" title="概述"></a>概述</h3><p>bpftrace是基于eBPF实现的动态的工具，使 eBPF学习摘要1(概述、理论) http://yoursite.com/2022/08/23/ebpf_1/ 2022-08-23T13:45:59.000Z 2022-08-23T13:45:59.000Z eBPF学习摘要1(概述、理论)

概述

早期内核包过滤是将网络数据包拷贝到用户态进行过滤，这样整体的包过滤性能低，后续在1992年的BSD操作系统上引入BPF包过滤技术，Linux在内核2.1.75正式引入BPF技术。网络数据包过滤可以直接在内核中执行，避免将网络数据包在用户态执行，极大提高了包过滤性能。如tcpdump工具就是利用BPF技术实现。2014年对BPF技术进行全面扩展，诞生了eBPF（extended Berkeley Packet Filter）使得BPF不仅仅是网络栈层面功能。后续iovisor 引入 BCC、bpftrace 等工具，成为 eBPF 在跟踪和排错领域的最佳实践。另外 eBPF 最重大的特性是在内核中运行沙盒程序而无需修改内核源码和重新编译内核就可以扩展内核的功能，Cilium、Katran、Falco 等一系列基于 eBPF 优化网络和安全的开源项目也逐步诞生。并且，越来越多的开源和商业解决方案开始借助 eBPF，优化其网络、安全以及观测的性能。


图片来源：https://blog.csdn.net/eBPF_Kindling/article/details/123575619

发展历程
1992年：BPF全称Berkeley Packet Filter，诞生初衷提供一种内核中自定义报文过滤的手段（类汇编），提升抓包效率。（tcpdump）
2011年：linux kernel 3.2版本对BPF进行重大改进，引入BPF JIT，使其性能得到大幅提升。
2014年： linux kernel 3.15版本，BPF扩展成eBPF，其功能范畴扩展至：内核跟踪、性能调优、协议栈QoS等方面。与之配套改进包括：扩展BPF ISA指令集、提供高级语言（C）编程手段、提供MAP机制、提供Help机制、引入Verifier机制等。
2016年：linux kernel 4.8版本，eBPF支持XDP，进一步拓展该技术在网络领域的应用。随后Netronome公司提出eBPF硬件卸载方案。Cilium项目正式发布。
2018年：linux kernel 4.18版本，引入BTF，将内核中BPF对象（Prog/Map）由字节码转换成统一结构对象，这有利于eBPF对象与Kernel版本的配套管理，为eBPF的发展奠定基础。
2018年：从kernel 4.20版本开始，eBPF成为内核最活跃的项目之一，新增特性包括：sysctrl hook、flow dissector、struct_ops、lsm hook、ring buffer等。场景范围覆盖容器、安全、网络、跟踪等
2021年：微软、Facebook、Google、Isovalent、NetFlix成立eBPF基金会，同年Cilium发布基于eBPF的Service Mesh解决方案
eBPF 基本架构及使用
参考链接：https://blog.51cto.com/dengchj/2944202

实现原理


用户态
1、用户编写 eBPF 程序，可以使用 eBPF 汇编或者 eBPF 特有的 C 语言来编写。
2、使用 LLVM/CLang 编译器，将 eBPF 程序编译成 eBPF 字节码。
3、调用 bpf() 系统调用把 eBPF 字节码加载到内核。

内核态
1、当用户调用 bpf() 系统调用把 eBPF 字节码加载到内核时，内核先会对 eBPF 字节码进行安全验证。
2、使用 JIT（Just In Time）技术将 eBPF 字节编译成本地机器码（Native Code）。
3、然后根据 eBPF 程序的功能，将 eBPF 机器码挂载到内核的不同运行路径上（如用于跟踪内核运行状态的 eBPF 程序将会挂载在 kprobes 的运行路径上）。当内核运行到这些路径时，就会触发执行相应路径上的 eBPF 机器码。
4、通过map与用户空间程序交互

如何保证内核安全性和优缺点

  • 需要特权执行：eBPF程序加载到Linux内核的进程都必须在特权模式(root)下运行，或者需要CAP_BPF功能，不受信任的程序不能加载eBPF程序

  • 验证器：加载eBPF程序到内核后需要经过验证如有界循环、越界访问内存、使用未初始化的变量。

  • 程序执行保护：已经加载在内核中的eBPF程序会进入read-only模式试图修改会直接crash内核。

  • 限制内核访问范围： eBPF程序不能直接访问任意内核其他函数。必须通过eBPF helpers访问固定helpers函数。

  • eBPF 堆栈大小被限制在 MAX_BPF_STACK，截止到内核 Linux 5.8 版本，被设置为 512字节。

  • eBPF 字节码大小最初被限制为 4096 条指令，截止到内核 Linux 5.8 版本， 当前已将放宽至 100 万指令。

优点：
1.速度和性能。 内核态进行，速度和效率高。
2.灵活：无需修改内核代码，即可扩展内核功能拥有无限想象空间。
3.低侵入性：基于eBPF实现链路追踪、服务治理等场景不需要侵入用户层。

缺点：
1.eBPF本身一些特性和能力依赖新版本内核。
2.学习成本高，需要对Linux Kernel和操作系统原理有深入了解。

目前行业落地情况

应用

  • 动态追踪：bcc、bpftrace

  • 观测监控：Pixie、Hubble

  • 网络：Cilium、Katran

  • 安全：Falco、Tracee

    能解决什么问题

为什么需要eBPF能实现可观测性

eBPF可观测性-指标采集
eBPF除了常规的指标监控如CPU、内存等，还可以监控细粒度的系统调用等信息，通过内核Kprobe或者Tracepoint实现;

eBPF可观测性-链路追踪
与传统APM相比，eBPF进行链路追踪不需要与业务本身进行绑定。通过拦截sock相关的send/recv操作，解析协议头，获得进程之间的调用关系，可进一步关联Kubernetes元数据，获得容器、服务之间的调用关系;

展望未来

1、基于eBPF的服务网格
去除每个pod的sidecar，内核态实现服务治理（cilium1.12已实现)

2、基于eBPF的负载均衡器
利用 socket eBPF，可以在不用直接处理报文和NAT 转换的前提下，实现了负载均衡逻辑。Service网络 POD<–> Service <–> POD优化成 POD <–> POD，从而使Service网络性能基本等同于POD 网络。软件结构如下：

3、基于eBPF的网络安全策略
不再依赖 iptables，不需要创建巨量的 iptables rule，从而显著降低 iptables 带来的性能影响。

参考链接：

https://mp.weixin.qq.com/s/Xr8ECrS_fR3aCT1vKJ9yIg
https://mp.weixin.qq.com/s?__biz=Mzg5Mjc3MjIyMA==&mid=2247544625&idx=2&sn=7ba07582e0b7fdc0ff3179f2fa2b44d4&source=41#wechat_redirect
https://blog.csdn.net/eBPF_Kindling/article/details/123575619
https://www.51cto.com/article/715674.html
https://blog.csdn.net/m0_46700908/article/details/124464577?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-124464577-blog-123575619.t5_layer_eslanding_D_0&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-124464577-blog-123575619.t5_layer_eslanding_D_0&utm_relevant_index=2
https://colobu.com/2022/05/22/use-ebpf-to-trace-rpcx-microservices/
https://arthurchiao.art/blog/ebpf-and-k8s-zh/
https://zhuanlan.zhihu.com/p/480811707
https://github.com/mikeroyal/eBPF-Guide
https://zhuanlan.zhihu.com/p/373090595

]]> <h2 id="eBPF学习摘要1-概述、理论"><a href="#eBPF学习摘要1-概述、理论" class="headerlink" title="eBPF学习摘要1(概述、理论)"></a>eBPF学习摘要1(概述、理论)</h2><h3 id="概述"><a href ETCD集群读写慢问题分析 http://yoursite.com/2022/07/27/fio_etcd/ 2022-07-27T13:45:59.000Z 2022-07-27T13:45:59.000Z 问题现象

1、Rancher所在local集群周期性卡顿、执行命令响应缓慢。
2、Rancher-server副本频繁重启。

3、Rancher UI空载集群切换项目，点击UI反应慢。

查看ETCD日志发现有大量Ready only报错和too long（xxx ms）to execute报错

问题分析

注：以下etcd读写流程来源腾讯云原生社区（https://blog.csdn.net/yunxiao6/article/details/108615472）
写数据流程（以 leader 节点为例，见上图）：

1、etcd 任一节点的 etcd server 模块收到 Client 写请求（如果是 follower 节点，会先通过 Raft 模块将请求转发至 leader 节点处理）。

2、etcd server 将请求封装为 Raft 请求，然后提交给 Raft 模块处理。

3、leader 通过 Raft 协议与集群中 follower 节点进行交互，将消息复制到follower 节点，于此同时，并行将日志持久化到 WAL。

4、follower 节点对该请求进行响应，回复自己是否同意该请求。

5、当集群中超过半数节点（(n/2)+1 members ）同意接收这条日志数据时，表示该请求可以被Commit，Raft 模块通知 etcd server 该日志数据已经 Commit，可以进行 Apply。

6、各个节点的 etcd server 的 applierV3 模块异步进行 Apply 操作，并通过 MVCC 模块写入后端存储 BoltDB。

7、当 client 所连接的节点数据 apply 成功后，会返回给客户端 apply 的结果。

读数据流程：

1、etcd 任一节点的 etcd server 模块收到客户端读请求（Range 请求） 判断读请求类型，如果是串行化读（serializable）则直接进入 Apply 流程。

2、如果是线性一致性读（linearizable），则进入 Raft模块。

3、Raft模块向 leader 发出 ReadIndex 请求，获取当前集群已经提交的最新数据 Index。

4、等待本地 AppliedIndex 大于或等于 ReadIndex 获取的 CommittedIndex 时，进入Apply 流程。

5、Apply 流程：通过Key名从KV Index模块获取 Key最新的 Revision，再通过Revision从BoltDB 获取对应的Key和Value。

etcd 通过 WAL（预写日志）实现了内存中数据的强持久性，WAL日志受到磁盘IO 写入速度影响，fdatasync延迟也会影响etcd性能。底层ceph为分布式存储，存储多副本会进行同步，副本同步时将占用大量网络和IO资源影响性能，底层又为SAS盘，对ETCD性能影响较大。

使用FIO模拟etcd io写入

使用FIO模拟etcd io写入

安装FIO

curl -LO https://github.com/rancherlabs/support-tools/raw/master/instant-fio-master/instant-fio-master.shbash instant-fio-master.sh

创建测试目录，对应的在/var/lib/etcd目录下进行性能测试，更能直观体现

export PATH=/usr/local/bin:$PATHcd /var/lib/etcdmkdir test-datafio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=100m --bs=2300 --name=mytest

size：表示总的写入大小
bs：表示每次写入的大小（单位为字节）

为了更好的模拟实际IO写入，需要通过lsof和strace查看实际IO写入量

通过lsof获取etcd进程的文件描述符

lsof -p $(pgrep etcd)|grep wal lsof -p $(pgrep etcd)|grep waletcd    21040 root    7w      REG   252,1 64000000  828705 /var/lib/rancher/etcd/member/wal/1.tmpetcd    21040 root    8r      DIR   252,1     4096  838659 /var/lib/rancher/etcd/member/waletcd    21040 root   11w      REG   252,1 64000000  828702 /var/lib/rancher/etcd/member/wal/0000000000000005-000000000007016b.wal

11w就是写入对应的wal文件的文件描述符，通过strace查看etcd系统调用，查看实际的数据写入量。

strace -f -p  $(pgrep etcd) -T -tt  -o test.txt

访问test.txt文件查找write(11

21064 11:23:24.438231 write(11, "\25\3\0\0\0\0\0\203\10\2\20\303\240\345\252\16\32\212\6\10\0\20\2\30\306\276\34\"\377\0052\337"..., 840 <unfinished ...>21306 11:23:24.438248 <... write resumed> ) = 42 <0.000037>21215 11:23:24.438263 <... futex resumed> ) = 0 <0.005978>21068 11:23:24.438277 <... futex resumed> ) = 1 <0.000051>21064 11:23:24.438291 <... write resumed> ) = 840 <0.000048>21306 11:23:24.438305 futex(0xc00080cf48, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>21068 11:23:24.438319 futex(0xc0004d2148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>21060 11:23:24.438333 <... nanosleep resumed> NULL) = 0 <0.000247>21060 11:23:24.438352 nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>21215 11:23:24.438496 futex(0xc00080cf48, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>21064 11:23:24.438530 fdatasync(11 <unfinished ...>

可以看见文件描述符11在write完后进行了fdatasync操作通过write操作可以看见此次数据写入量为840字节，多对比几个发现范围在800-900之间，因为我的环境为单节点环境，实际数据写入量根etcd版本和集群规模有直接关系，通常情况下在2300左右，所以这里fio的bs参数设置为2300字节，模拟etcd io写入，查看延时情况。

测试结果

mytest: (g=0): rw=write, bs=(R) 2300B-2300B, (W) 2300B-2300B, (T) 2300B-2300B, ioengine=sync, iodepth=1fio-3.30-67-gdc472Starting 1 processmytest: Laying out IO file (1 file / 100MiB)Jobs: 1 (f=1)Jobs: 1 (f=1): [W(1)][100.0%][w=636KiB/s][w=283 IOPS][eta 00m:00s]mytest: (groupid=0, jobs=1): err= 0: pid=16852: Mon Jul  4 09:46:37 2022  write: IOPS=253, BW=569KiB/s (583kB/s)(100.0MiB/179902msec); 0 zone resets    clat (usec): min=5, max=4377, avg=16.96, stdev=32.00     lat (usec): min=5, max=4377, avg=17.51, stdev=32.04    clat percentiles (usec):     |  1.00th=[    8],  5.00th=[   10], 10.00th=[   10], 20.00th=[   11],     | 30.00th=[   12], 40.00th=[   13], 50.00th=[   14], 60.00th=[   16],     | 70.00th=[   18], 80.00th=[   22], 90.00th=[   29], 95.00th=[   34],     | 99.00th=[   49], 99.50th=[   57], 99.90th=[   81], 99.95th=[   96],     | 99.99th=[ 1369]   bw (  KiB/s): min=   89, max=  691, per=99.97%, avg=569.10, stdev=63.60, samples=359   iops        : min=   40, max=  308, avg=253.57, stdev=28.33, samples=359  lat (usec)   : 10=15.39%, 20=60.57%, 50=23.19%, 100=0.81%, 250=0.03%  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%  fsync/fdatasync/sync_file_range:    sync (usec): min=1052, max=434792, avg=3923.05, stdev=3609.22    sync percentiles (usec):     |  1.00th=[  1237],  5.00th=[  1385], 10.00th=[  1483], 20.00th=[  1663],     | 30.00th=[  1876], 40.00th=[  2278], 50.00th=[  4359], 60.00th=[  4752],     | 70.00th=[  5211], 80.00th=[  5669], 90.00th=[  6325], 95.00th=[  6849],     | 99.00th=[  8455], 99.50th=[ 12649], 99.90th=[ 22938], 99.95th=[ 23725],     | 99.99th=[166724]  cpu          : usr=0.33%, sys=1.60%, ctx=109419, majf=0, minf=14  IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%     issued rwts: total=0,45590,0,0 short=45590,0,0,0 dropped=0,0,0,0     latency   : target=0, window=0, percentile=100.00%, depth=1Run status group 0 (all jobs):  WRITE: bw=569KiB/s (583kB/s), 569KiB/s-569KiB/s (583kB/s-583kB/s), io=100.0MiB (105MB), run=179902-179902msecDisk stats (read/write):  vda: ios=4/120187, merge=0/53744, ticks=56/185772, in_queue=9776, util=1.54%

主要看
fsync/fdatasync/sync_file_range:项的 99.00th=[ 18455], 99.50th=[ 12649],

表示百分之99的sync为18455usec，对应的etcd要求写入WAL文件时百分之99的fdatasync请求必须小于 10 毫秒。
https://etcd.io/docs/v3.4/op-guide/performance/

参考链接：

https://blog.happyhack.io/2021/08/05/fio-and-etcd/https://www.suse.com/support/kb/doc/?id=000020100https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcdhttps://blog.csdn.net/yunxiao6/article/details/108615472
]]> <h3 id="问题现象"><a href="#问题现象" class="headerlink" title="问题现象"></a>问题现象</h3><p>1、Rancher所在local集群周期性卡顿、执行命令响应缓慢。<br>2、Rancher-server副本频繁重启。</ Rancher2.6 Monitoring使用 http://yoursite.com/2022/06/29/rancher_monitor/ 2022-06-29T13:45:59.000Z 2022-06-29T13:45:59.000Z 软件版本Rancher.9Kubernetes1.23.7+rke2r2

概述

Rancher 2.6监控启用方式与之前版本存在较大差异，属于原生的Prometheus-Operator，通过抽象化一些Kubernetes CRD资源，可以更好的把监控告警功能整合起来，提高易用性。Prometheus-operator包括以下CRD资源对象：

PrometheusRules ：定义告警规则

Alert Managers ：Altermanager启动CRD，用于Altermanager启动副本。

Receivers：配置告警接收媒介CRD

Routers： 将告警规则和告警媒介进行匹配。

ServiceMonitor：定义Prometheus采集的监控指标地址

Pod Monitor：更细粒化的对POD进行监控。

配置使用

启用监控

具体方法如下

切换到对应集群，选择左下角clusterTools启用Prometheus

部署到System项目中，勾选自定义helm参数

根据实际需求修改部署要求

如果需要对接远端存储如infuxdb需要修改yaml，修改配置指向influxdb。

1
2
3
4
remoteRead:
  - url: http://192.168.0.7:8086/api/v1/prom/read?db=prometheus
remoteWrite:
  - url: http://192.168.0.7:8086/api/v1/prom/write?db=prometheus

默认node-Exporter资源limit配置较低，长时间运行后容易被OOMKILL掉，需要修改默认的内存限制为150Mi。

1
2
3
4
5
6
7
8
9
podLabels:
   jobLabel: node-exporter
 resources:
   limits:
     cpu: 200m
     memory: 150Mi
   requests:
     cpu: 100m
     memory: 30Mi

在此页面可以点击进入对应的组件配置页面。
如：

  • Altermanager：进入的是告警信息查看页。
  • Grafana：查看监控数据图标
  • Prometheus Graph：Prometheus表达式执行页
  • Prometheus Rules：查看Prometheus配置的告警表达式页
  • Prometheus Targets：监控采集数据采集点

配置自定义监控指标

默认启用监控会会自动添加一些ServiceMonitor监控规则和Prometheus Rules 告警规则，主要是针对平台组件监控和集群内节点状态监控和告警

如针对java应用的jmx监控

Jmx有官方的prometheus-export，我们只需要将其jar包下载让java应用程序加载jar包和加载其配置即可。
以一个应用为例，整体流程如下：
利用JMX exporter，在Java进程内启动一个小型的Http server
配置Prometheus抓取那个Http server提供的metrics。
配置Grafana连接Prometheus，配置Dashboard。
创建文件夹：

1
mkdir  -p /Dockerfile/jmx-exporter/

下载jmx-export.jar包放到此目录

1
2
https://github.com/prometheus/jmx_exporter
https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.12.0/jmx_prometheus_javaagent-0.12.0.jar

编写jvm-export配置文件放置/root/jmx-exporter/目录
创建simple-config.yml内容如下：

1
2
3
---
rules:
- pattern: ".*"

这里意思表示将全部监控信息抓取出来。
将jvm-export集成到tomcat中，重新编写Dockerfile

1
2
3
4
FROM tomcat
COPY ./jmx_prometheus_javaagent-0.12.0.jar /jmx_prometheus_javaagent-0.12.0.jar
ENV CATALINA_OPTS="-Xms64m -Xmx128m -javaagent:/jmx-exporter/jmx_prometheus_javaagent-0.12.0.jar=6060:/jmx-exporter/simple-config.yml"

重新docker build，build后执行以下docker run命令可以查看收集的监控指标，这里6060端口就是我们的jmx-export端口

1
2
docker build -t tomcat:v1.0 .
docker run -itd -p 8080:8080 -p 6060:6060 tomcat:v1.0

访问查看：
http://host_ip:6060

部署到Rancher平台

给Service打上label，用于ServiceMonitor关联

1
kubectl label  svc tomcat app=tomcat

创建ServiceMonitor

1
2
3
4
5
6
7
8
9
10
11
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tomcat-app
  namespace: default
spec:
  endpoints:
  - port: exporter
  selector:
    matchLabels:
      app: tomcat

创建成功后通过Prometheus可以查看到对应的Target

对应的监控指标也已经抓取

进入grafana页面添加dashboard，默认账号密码为admin/prom-operator

添加dashboard

输入dashboard-id，8878，离线环境需要提前将Dashboard下载好，通过json方式导入。

配置告警

PrometheusRule用于定义告警规则，默认已经包含针对平台组件和节点的一些告警策略。可以通过配置Router和Receivers配置告警媒介将对应告警通知到相应的人员。采用Routing Tree的告警结构能够快速的将告警进行分类，然后发送到指定的人员进行处理。通过配置AlertmanagerConfig统一实现Rooter和Recivers配置
创建AlertmanagerConfig

选择Email告警
Receivers配置告警媒介
填写SMTP地址和配置的账号/密码，默认接收的邮箱。

邮箱密码创建Opaque类型的secret

Routes配置用于告警媒介和告警规则进行匹配，默认创建的root规则，用于匹配全部的告警规则，配置上对应创建的告警媒介。

此时全部的告警规则都会发送给配置的告警媒介

若要细分告警规则创建新的Routes通过Label与Prometheus Rules内对应的Alter name对接

如匹配alert:etcdNoLeader这条告警规则

也可以使用正则表达式匹配多个规则如

Grouping配置主要用于告警规则分类、抑制避免大量无用告警的干扰

group_by：用于配置告警分组，达到告警抑制效果，同一个group的告警只会聚合到一起发送一次，例如host01上运行了数据库，那么对应的告警包含了host down、mysql down。他们配置在一个group内，那么如果host down了对应的mysql肯定也是down了，那么因为他们配置在一个group中，所以host down和mysql down的告警会聚合到一起发送出。

group_wait：新建的AlterGroup等待多久后触发第一次告警。

group_interval：AlterGroup内产生的不同告警触发间隔时间。

repeat_interval：AlterGroup内如果一直是同样的告警，Altermanager为了避免长时间的干扰，进行告警去重的等待时间。

匹配后，告警触发，可以收到对应的告警邮件

自定义告警

当默认的告警规则不能满足需求时，可以根据实际情况添加自定义告警，实际就是添加对应的PrometheusRule。如以下例子，添加pod非running状态的告警。

UI配置

对应yaml配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: podmonitor
  namespace: cattle-monitoring-system
spec:
  groups:
  - name: pod_node_ready
    rules:
    - alert: pod_not_ready
      annotations:
        message: '{{ $labels.namespace }}/{{ $labels.pod }} is not ready.'
      expr: 'sum by (namespace, pod) (kube_pod_status_phase{phase!~"Running|Succeeded"})
        > 0 '
      for: 180s
      labels:
        severity: 严重

for：表示持续时间
message：表示告警通知内的信息。
label.severity：表示告警级别
expr：指标获取表达式

配置告警接收者

根据标签匹配到这个PrometheusRule

常见问题

1、触发告警后，邮箱收不到告警邮件
使用163邮箱SMTP的465端口
altermanager报错
msg="Notify for alerts failed" num_alerts=1 err="cattle-monitoring-system-test-test/email[0]: notify retry canceled after 16 attempts: send STARTTLS command: 454 Command not permitted when TLS active"

修改

1
2
3
4
5
6
7
8
9
10
11
12
13
spec:
  receivers:
  - emailConfigs:
    - authPassword:
        key: password
        name: altermanager
      authUsername: xx@163.com
      from: xx@163.com
      requireTLS: false
      sendResolved: false
      smarthost: smtp.163.com:465
      tlsConfig: {}
      to: xx@qq.com

添加requireTLS: false

2、内部邮件服务器使用非权威证书

1
2
3
email_configs:
  - to: 'xxx'
    insecure_skip_verify: true

添加insecure_skip_verify: true
参考链接：

https://mp.weixin.qq.com/s/fT-AXnPP8rrWxTposbi-9A

https://github.com/prometheus-operator/prometheus-operator

https://rancher.com/docs/rancher/v2.6/en/monitoring-alerting/guides/enable-monitoring/
https://mp.weixin.qq.com/s/c9QGlwQrhLgptNsnQ1m6-w

]]> <table> <thead> <tr> <th>软件</th> <th>版本</th> </tr> </thead> <tbody><tr> <td>Rancher</td> <td>.9</td> </tr> <tr> <td>Kubernetes</td> <td>1.23 云原生安全平台NeuVector基础使用 http://yoursite.com/2022/04/17/neuvector_2/ 2022-04-17T13:45:59.000Z 2022-04-17T13:45:59.000Z 概述

上一篇NeuVector文章主要以安装部署为主，本篇将实际结合NeuVector的基础功能进行操作演示，主要包含对于NeuVector安全漏洞管理、合规性和机密性检查、策略管理、准入控制策略、动态安全响应和行为监控。本篇文档适用版本为以NeuVector首个开源版NeuVector:5.0.0-preview.1为主

安全漏洞管理

集成CVE漏洞库，每天自动更新，支持对平台（Kubernetes）、主机、容器、镜像仓库进行安全漏洞扫描。

配置自动扫描，当平台漏洞库有更新或有新的节点和容器加入时会自动进行扫描。

针对不同漏洞有不同风险级别，以及对应的组件版本和修复版本提示

每个漏洞可以展示对应的漏洞发布时间、漏洞影响范围、对应的组件影响版本。

对漏洞进行过滤，是否已经修复，漏洞等级、发布时间等

配置对接镜像仓库扫描

支持对接多种镜像仓库如（docker-registry（harbor）、JFrog Artifactory、Nexus等）

以对接Harbor为例，配置连接方式，填写连接方式和认证信息，过滤器表示你需要扫描的范围如扫描uat项目下全部镜像则uat/*,如果需要扫描整个Harbor内全部镜像则*。测试设置可以验证编写的表达式的关联情况。

合规性检查和机密性检查

NeuVector的合规性审核包括 CIS 基线测试、自定义检查、机密审核以及 PCI、GDPR 和其他法规的行业标准模板扫描。

类型这表示对应的那个基线标准如K.4.1.1对应Kubernetes CIS基线测试4.1.1
容器对应的基线标准为D开头的，镜像对应的基线标准为I开头

注：《通用数据保护条例》（General Data Protection Regulation，简称GDPR）为欧洲联盟的条例

在合规性检查中也会检查是否存在密文泄漏情况

包括如

General Private KeysGeneral detection of credentials including 'apikey', 'api_key', 'password', 'secret', 'passwd' etc.General passwords in yaml files including 'password', passwd', 'api_token' etc.General secrets keys in key/value pairsPutty Private keyXml Private keyAWS credentials / IAMFacebook client secretFacebook endpoint secretFacebook app secretTwitter client IdTwitter secret keyGithub secretSquare product IdStripe access keySlack API tokenSlack web hooksLinkedIn client IdLinkedIn secret keyGoogle API keySendGrid API keyTwilio API keyHeroku API keyMailChimp API keyMailGun API key

策略管理

在NeuVector中通过组的方式对容器和主机进行管理。通过对组进行合规性检查、网络规则、进程和文件访问规则、DLP/WAF的检测配置。

NeuVector会自动将当前集群主机加入到nodes组，对于集群内容器会自动创建以nv.开头的组

NeuVector的组支持3种模式，学习模式、监控模式、保护模式。各个模式实现作用如下。
学习模式：
学习和记录容器、主机间网络连接情况和进程执行信息。
自动构建网络规则白名单，保护应用网络正常行为。
为每个服务的容器中运行的进程设定安全基线，并创建进程配置文件规则白名单

监控模式：
NeuVector监视容器和主机网络和进程运行情况，遇到非学习模式下记录的行为将在NeuVector中进行告警。

保护模式：

NeuVector监视容器和主机网络和进程运行情况，遇到非学习模式下记录的行为直接拒绝。

新建的容器业务被自动发现默认为学习模式，也可以通过设置将默认模式设置为监控模式或保护模式。

不同组下策略冲突情况下，适用的有效模式如下表：

源组模式目的组模式有效模式
学习模式监控模式学习模式
学习模式保护模式学习模式
监控模式学习模式学习模式
监控模式保护模式监控模式
保护模式学习模式学习模式
保护模式监控模式监控模式

为了保证业务的稳定运行，当出现模式不一致时，有效模式以限制最小的模式运行。

生产环境最佳实践使用：
使用路径可以是：1、上新业务时先学习模式运行一段时间，进行完整的功能测试和调用测试得到实际运行此业务的网络连接情况和进程执行情况信息。2、监控模式运行一段时间，看看有没有额外的特殊情况，进行判断添加规则。3、最后全部容器都切换到保护模式确定最终形态。

动态微隔离

使用场景一：POD间通过网络策略互相隔离
在Kubernetes平台中创建四个Nginx。名称和用途如下。
workload_name：test-web1 image:nginx 用途：web服务器。
workload_name：test-con1 image:nginx 用途：连接客户端1
workload_name：test-con2 image:nginx 用途：连接客户端2
workload_name：test-con3 image:nginx 用途：连接客户端3

创建workload

kubectl create deployment test-web1 --image=nginxkubectl expose deployment/test-web1 --port=80 --type=NodePort kubectl create deployment test-con1 --image=nginxkubectl create deployment test-con2 --image=nginxkubectl create deployment test-con3 --image=nginx

此时在NeuVector中会自动生成这几个组。

在test-con1中通过curl访问test-web1

此时可以正常访问，因为在学习模式下。NeuVector也会自动添加此访问规则。

将test-web1和test-con2都设置为监控模式

然后在test-con2中curl访问test-web1

此时test-con2可以正常访问test-web1，但在NeuVector中会生成告警

同时对应的在网络活动拓扑图中也可以看见对应的连接链路变为红色。

将test-web1和test-con2都设置为保护模式，在通过test-con2去curl test-web1

因为curl在学习模式时没有使用，也不是NeuVector默认允许的可执行进程，所以进程直接就无法访问了。

将test-con1设置为保护模式，此时test-con1无法访问外部网络，

可以通过自定义添加网络规则方式开通访问。

在网络规则页，此处规则已经是在学习模式下生成的规则列表。

添加外部访问规则

NeuVector深度了解应用程序行为，并将分析有效负载以确定应用程序协议。协议包括HTTP，HTTPS，SSL，SSH，DNS，DNCP，NTP，TFTP，ECHO，RTSP，SIP，MySQL，Redis，Zookeeper，Cassandra，MongoDB，PostgresSQL，Kafka，Couchbase，ActiveMQ，ElasticSearch，RabbitMQ，Radius，VoltDB，Consul，Syslog，Etcd，Spark，Apache，Nginx，Jetty，NodeJS，Oracle，MSSQL和gRPC。

现在test-con1的curl去访问www.baidu.com以正常访问。

总结：
除上述策略外，NeuVector也内置网络威胁检测，能够快速识别常用网络攻击，保护业务容器安全运行。

无论保护模式如何。在”学习和监视”模式下，将发出警报，并且可以在”通知”->安全事件中找到这些威胁。在保护模式下，这些将收到警报和阻止。还可以根据威胁检测创建响应规则。

包含的威胁检测如下：

SYN flood attackICMP flood attackIP Teardrop attackTCP split handshake attackPING death attackDNS flood DDOS attackDetect SSH version 1, 2 or 3Detect SSL TLS v1.0SSL heartbeed attackDetect HTTP negative content-length buffer overflowHTTP smugging attackHTTP Slowloris DDOS attackTCP small window attackDNS buffer overflow attackDetect MySQL access denyDNS zone transfer attackICMP tunneling attackDNS null type attackSQL injection attackApache Struts RCE attackDNS tunneling attackTCP Small MSS attackCipher Overflow attackKubernetes man-in-the-middle attack per CVE-2020-8554

进程管理

NeuVector支持对容器和主机内进程进行管理
在学习模式下，运行的进程和命令会自动添加到规则中

此时在test-con1中执行df -h会发现报错bash: /bin/df: Operation not permitted
在nv.test-con1.default组中添加df进程规则


然后在重新执行即可执行。

进程管理也支持对node节点，可以在node组中进行限制，约束宿主机进程执行。如限制执行docker cp 执行，通过学习模式得知是docker-tar进程在后端执行
将节点切换到保护模式，限制docker-tar进程即可。

这些在节点就无法执行docker cp

准入策略控制

NeuVector支持与Kubernetes准入控制（admission-control）功能对接，实现UI配置准入控制规则，对请求进行拦截，用于对请求的资源对象进行校验。
NeuVector支持多种准入控制策率配置如镜像CVE漏洞情况限制、部署特权模式、镜像内使用root用户、特定标签等。

在策略-准入控制中开启此功能，注意：需要Kubernetes集群提前开启admission-control功能

NeuVector准入策略控制，支持两种模式，监控模式和保护模式，对应含义和组的模式一样的。这里我们直接切换到保护模式，添加策略。

添加完后，在Rancher中部署特权模式容器会提示解决，策略生效。

动态安全响应

NeuVector事件响应机制可以配置响应规则根据安全事件情况进行动态响应，包括以下事件：漏洞扫描结果、CIS基准测试、准入控制事件等。

响应动作包括隔离、webhook通知、日志抑制

隔离模式：对应的容器网络进出流量将全部被切断。
webhook通知：将触发信息通过webhook方式进行告警。
日志抑制：对触发告警信息进行抑制。

以CVE漏洞配置为例，配置包含CVE漏洞名称为CVE-2020-16156的容器进入隔离模式。

组名对应的是影响范围，如果为空，表示对全部的组都生效，填写组名可以设置对特定组生效。

配置策略后，在集群去curl nginx容器，发现无法访问，在NeuVector中查看容器状态为隔离状态。

删除策略时，也可以配置将对应隔离状态容器解除隔离。

注意：
1、隔离操作不适用于为主机事件触发的规则
2、每个规则可以有多个操作。

行为监控

网络流量可视化

网络流量可视化，可以清晰可见容器集群内网络连接关系，当前容器连接会话并且可以过滤网络连接信息，进行图标展示。能够快速进行网络问题定位。

流量抓包

针对容器可进行网络抓包，方便故障不需要进入主机获取高权限，就能使进行网络问题深入排查。

采集到的数据包可直接下载通过Wireshark进行解包分析。

]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h3><p>上一篇NeuVector文章主要以安装部署为主，本篇将实际结合NeuVector的基础功能进行操作演示，主要包含对于NeuVector安全漏 使用Bird模拟BGP Peers http://yoursite.com/2022/03/23/bird_bgpper/ 2022-03-23T13:45:59.000Z 2022-03-23T13:45:59.000Z 概述

calico网络插件最为知名的就是calico-bgp模式，在测试中需要验证calico-bgp跨子网路由同步，需要连接两个子网的路由器支持BGP协议，这给测试环境搭建带来很大复杂性。本次文档通过Bird软件将一个虚拟机模拟为软路由，并配置为Kubernetes节点BGP Peers，实现BGP路由同步。

软件版本

软件版本
Kubernetesv1.20.15
calicov3.17.2

拓扑架构图

Hostname：rke-node3
host-ip：192.168.0.7
pod-cidr：10.41.113.192/26

Hostname：rke-node4
host-ip：192.168.0.25
pod-cidr：10.41.57.192/26

Hostname：rke-node6
host-ip：192.168.2.14
pod-cidr：10.41.210.128/26

Hostname：rke-node7
host-ip：192.168.2.15
pod-cidr：10.41.210.0/26

kubernetes 节点分布在两个子网，中间通过一台vm连接了两个子网，在vm上部署bird软路由进行两个子网通信，同属一个AS自治域。

注意：如果底层是OpenStack环境需要关闭网卡安全组。

Bird部署配置

节点配置

Bird节点采用一台VM部署，操作系统采用Centos7.6，将此节点作为软路由需要确保以下功能开启。

内核forward转发

sysctl -a|grep "net.ipv4.ip_forward = 1"net.ipv4.ip_forward = 1

iptables数据包转发

iptables -P FORWARD ACCEPT

需要互相联通的节点上需要配置互访的静态路由

如在192.168.0.0/24的节点上配置

ip route add 192.168.2.0/24 via 192.168.0.40 dev ens3

如在192.168.2.0/24的节点上配置

ip route add 192.168.0.0/24 via 192.168.2.16 dev ens3

验证互访，在192.168.0.0/24主机ping 192.168.2.0/24主机

Bird配置

Bird配置文件

1
2
3
mkdir /bird/
vim /bird/bird.conf

router id 192.168.0.40;filter calico_export_to_bgp_peers {  if ( net ~ 10.41.0.0/16 ) then {    accept;  }  if ( net ~ 10.42.0.0/16 ) then {    accept;  }  reject;}filter calico_kernel_programming {  if ( net ~ 10.41.0.0/16 ) then {    accept;  }  if ( net ~ 10.42.0.0/16 ) then {    accept;  }  accept;}# Configure synchronization between routing tables and kernel.protocol kernel {  learn;             # Learn all alien routes from the kernel  persist;           # Don't remove routes on bird shutdown  scan time 2;       # Scan kernel routing table every 2 seconds  import all;  export filter calico_kernel_programming; # Default is export none  graceful restart;  # Turn on graceful restart to reduce potential flaps in                     # routes when reloading BIRD configuration.  With a full                     # automatic mesh, there is no way to prevent BGP from                     # flapping since multiple nodes update their BGP                     # configuration at the same time, GR is not guaranteed to                     # work correctly in this scenario.  merge paths on;    # Allow export multipath routes (ECMP)}protocol device {  debug { states };  scan time 2;    # Scan interfaces every 2 seconds}protocol direct {  debug { states };  interface -"cali*", -"kube-ipvs*", "*"; # Exclude cali* and kube-ipvs* but                                          # include everything else.  In                                          # IPVS-mode, kube-proxy creates a                                          # kube-ipvs0 interface. We exclude                                          # kube-ipvs0 because this interface                                          # gets an address for every in use                                          # cluster IP. We use static routes                                          # for when we legitimately want to                                          # export cluster IPs.}# Template for all BGP clientstemplate bgp bgp_template {  debug { states };  description "Connection to BGP peer";  local as 63400;  multihop;  gateway recursive; # This should be the default, but just in case.  import all;        # Import all routes, since we don't know what the upstream                     # topology is and therefore have to trust the ToR/RR.  export filter calico_export_to_bgp_peers;  # Only want to export routes for workloads.  source address 192.168.0.40;  # The local address we use for the TCP connection  add paths on;  graceful restart;  # See comment in kernel section about graceful restart.  connect delay time 2;  connect retry time 5;  error wait time 5,30;}protocol bgp Node_192_168_0_25 from bgp_template {  rr client;  neighbor 192.168.0.25 as 63400;}protocol bgp Node_192_168_0_7 from bgp_template {  rr client;  neighbor 192.168.0.7 as 63400;}protocol bgp Node_192_168_2_14 from bgp_template {  rr client;  neighbor 192.168.2.14 as 63400;}protocol bgp Node_192_168_2_15 from bgp_template {  rr client;  neighbor 192.168.2.15 as 63400;}

将配置文件中的route-id、pod-cidr、neighbor-ip、as_number修改为实际需要建立bgp邻居的节点ip。

为了方便部署，本次bird使用Docker启动，启动命令如下：

docker run  -itd  --net=host --uts=host --cap-add=NET_ADMIN --cap-add=NET_BROADCAST --cap-add=NET_RAW -v /bird/:/etc/bird:ro ibhde/bird4

检查启动状态是否为up

docker ps -a

Calico BGP对接

全部节点上安装calicoctl

wget https://github.com/projectcalico/calicoctl/releases/download/v3.17.4/calicoctl-linux-amd64mv calicoctl-linux-amd64 /usr/bin/calicoctlchmod a+x /usr/bin/calicoctl

关闭全局full-mesh

cat <<EOF | calicoctl apply -f -apiVersion: projectcalico.org/v3kind: BGPConfigurationmetadata: name: defaultspec:  logSeverityScreen: Info  nodeToNodeMeshEnabled: false  asNumber: 63400EOF

配置节点label

这里将两组节点打上不同标签，将192.168.2.0/24节点打上rack=rack-1标签，连接192.168.2.16 bpg-peers，将192.168.0.0/24打上rack-rack-2标签，连接192.168.0.40 bgp-peers

kubectl label nodes rke-node3 rack=rack-2kubectl label nodes rke-node4 rack=rack-2kubectl label nodes rke-node5 rack=rack-1kubectl label nodes rke-node5 rack=rack-1

使用caliclctl配置BGP Peers

cat <<EOF | calicoctl apply -f -apiVersion: projectcalico.org/v3kind: BGPPeermetadata:  name: rack1-torspec:  peerIP: 192.168.2.16  asNumber: 63400  nodeSelector: rack == 'rack-1'EOF
apiVersion: projectcalico.org/v3kind: BGPPeermetadata:  name: rack2-torspec:  peerIP: 192.168.0.40  asNumber: 63400  nodeSelector: rack == 'rack-2'

检查与BGP Peers连接情况

在rack=rack-2标签节点执行，应显示已经与192.168.0.40 bgp-peers建立连接

 calicoctl node statusCalico process is running.IPv4 BGP status+--------------+---------------+-------+------------+-------------+| PEER ADDRESS |   PEER TYPE   | STATE |   SINCE    |    INFO     |+--------------+---------------+-------+------------+-------------+| 192.168.0.40 | node specific | up    | 2022-03-18 | Established |+--------------+---------------+-------+------------+-------------+IPv6 BGP statusNo IPv6 peers found.

在rack=rack-1标签节点执行，应显示已经与192.168.2.16 bgp-peers建立连接

calicoctl node statusCalico process is running.IPv4 BGP status+--------------+---------------+-------+------------+-------------+| PEER ADDRESS |   PEER TYPE   | STATE |   SINCE    |    INFO     |+--------------+---------------+-------+------------+-------------+| 192.168.2.16 | node specific | up    | 2022-03-18 | Established |+--------------+---------------+-------+------------+-------------+IPv6 BGP statusNo IPv6 peers found.

创建pod，验证路由同步

kubectl create deployment test --image=nginx --replicas=5

在5副本中，互相进行ping操作。验证跨节点网络是否正常。

在bird节点查看路由学习

ip routedefault via 192.168.2.1 dev eth010.41.210.0/26 via 192.168.2.15 dev eth0 proto bird10.42.57.192/26 via 192.168.0.25 dev eth1 proto bird10.42.113.192/26 via 192.168.0.7 dev eth1 proto bird10.42.210.128/26 via 192.168.2.14 dev eth0 proto bird192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.40192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.16

可以看见bird将集群内每个节点的pod-cidr都学习过来了。

在任意一个node节点上查看路由，以192.168.0.3节点为例，可以看见节点上也拥有集群全部pod-cidr路由信息。

ip routedefault via 192.168.0.1 dev ens3 proto dhcp src 192.168.0.7 metric 10010.41.57.192/26 via 192.168.0.25 dev ens3 proto birdblackhole 10.41.113.192/26 proto bird10.41.210.0/26 via 192.168.0.40 dev ens3 proto bird10.41.210.128/26 via 192.168.0.40 dev ens3 proto bird10.42.57.192/26 via 192.168.0.25 dev ens3 proto bird192.168.0.0/24 dev ens3 proto kernel scope link src 192.168.0.7192.168.2.0/24 via 192.168.0.40 dev ens3

节点POD-CIDR路由统一走默认路由

当前路由同步会将每个节点pod-cidr同步到集群中的节点上，对于Kubernetes集群规模大情况下会造成路由条目增多。可以通过下发默认路由方式，将节点全部流量请求都都指向bird 软路由节点。这样还有一个好处就是，在一些硬件SDN设备中可以实现流量监控。但需要注意的是路由器本身能承载的流量。

以bird配置为例

router id 192.168.0.40;protocol static { route 10.41.0.0/16 via 192.168.0.40; route 10.42.0.0/16 via 192.168.0.40;}filter calico_export_to_bgp_peers {  if ( net ~ 10.41.0.0/16 ) then {    accept;  }  if ( net ~ 10.42.0.0/16 ) then {    accept;  }  reject;}filter calico_kernel_programming {  if ( net ~ 10.41.0.0/16 ) then {    accept;  }  if ( net ~ 10.42.0.0/16 ) then {    accept;  }  accept;}# Configure synchronization between routing tables and kernel.protocol kernel {  learn;             # Learn all alien routes from the kernel  persist;           # Don't remove routes on bird shutdown  scan time 2;       # Scan kernel routing table every 2 seconds  import all;  export filter calico_kernel_programming; # Default is export none  graceful restart;  # Turn on graceful restart to reduce potential flaps in                     # routes when reloading BIRD configuration.  With a full                     # automatic mesh, there is no way to prevent BGP from                     # flapping since multiple nodes update their BGP                     # configuration at the same time, GR is not guaranteed to                     # work correctly in this scenario.  merge paths on;    # Allow export multipath routes (ECMP)}protocol device {  debug { states };  scan time 2;    # Scan interfaces every 2 seconds}protocol direct {  debug { states };  interface -"cali*", -"kube-ipvs*", "*"; # Exclude cali* and kube-ipvs* but                                          # include everything else.  In                                          # IPVS-mode, kube-proxy creates a                                          # kube-ipvs0 interface. We exclude                                          # kube-ipvs0 because this interface                                          # gets an address for every in use                                          # cluster IP. We use static routes                                          # for when we legitimately want to                                          # export cluster IPs.}# Template for all BGP clientstemplate bgp bgp_template {  debug { states };  description "Connection to BGP peer";  local as 63400;  multihop;  gateway recursive; # This should be the default, but just in case.  import all;        # Import all routes, since we don't know what the upstream                     # topology is and therefore have to trust the ToR/RR.  export filter calico_export_to_bgp_peers;  # Only want to export routes for workloads.  source address 192.168.0.40;  # The local address we use for the TCP connection  add paths on;  graceful restart;  # See comment in kernel section about graceful restart.  connect delay time 2;  connect retry time 5;  error wait time 5,30;}protocol bgp Node_192_168_0_25 from bgp_template {  neighbor 192.168.0.25 as 63400;}protocol bgp Node_192_168_0_7 from bgp_template {  neighbor 192.168.0.7 as 63400;}protocol bgp Node_192_168_2_14 from bgp_template {  neighbor 192.168.2.14 as 63400;}protocol bgp Node_192_168_2_15 from bgp_template {  neighbor 192.168.2.15 as 63400;}

将neighbor配置中的 rr client删除，同时添加静态路由下发配置

protocol static { route 10.41.0.0/16 via 192.168.0.40; route 10.42.0.0/16 via 192.168.0.40;}

在192.168.0.0/24的主机上看见路由情况如下：

ip routedefault via 192.168.0.1 dev ens3 proto dhcp src 192.168.0.7 metric 10010.41.0.0/16 via 192.168.0.40 dev ens3 proto birdblackhole 10.41.113.192/26 proto bird10.42.0.0/16 via 192.168.0.40 dev ens3 proto bird

可以看见pod-cidr的流量都被发送到Bird虚拟路由器192.168.0.40接口
在192.168.2.0/24的主机上看见路由情况如下：

ip routedefault via 192.168.2.1 dev ens710.41.0.0/16 via 192.168.2.16 dev ens7 proto birdblackhole 10.41.210.128/26 proto bird10.42.0.0/16 via 192.168.2.16 dev ens7 proto bird

可以看见pod-cidr的流量都被发送到Bird虚拟路由器192.168.2.16接口

节点POD-IP明细路由发布

在实际使用中若期望将calico-pod明细路由发布到BGP路由器中，则需要修改每个节点的calico配置文件
修改方法如下

创建configmap，替换calico原有的bird_aggr.cfg.template文件

主要修改以下参数：
注释掉本地黑洞路由，就不会生产本地聚合路由同步到BGP路由器了。

1
2
# route {{$cidr}} blackhole;

允许明细路由同步
将if ( net ~ {{$cidr}} ) then { reject; } 修改为accept

完整配置如下：

# Generated by confd{{- $block_key := printf "/calico/ipam/v2/host/%s/ipv4/block" (getenv "NODENAME")}}{{- $static_key := "/calico/staticroutes"}}{{if or (ls $block_key) (ls $static_key)}}protocol static {{{- if ls $block_key}}   # IP blocks for this host.{{- range ls $block_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}} #  route {{$cidr}} blackhole;{{- end}}{{- end}}{{- if ls $static_key}}   # Static routes.{{- range ls $static_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}} #  route {{$cidr}} blackhole;{{- end}}{{- end}}}{{else}}# No IP blocks or static routes for this host.{{end}}# Aggregation of routes on this host; export the block, nothing beneath it.function calico_aggr (){{{- range ls $block_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}}{{- $affinity := json (getv (printf "%s/%s" $block_key .))}}  {{- if $affinity.state}}      # Block {{$cidr}} is {{$affinity.state}}    {{- if eq $affinity.state "confirmed"}}      if ( net = {{$cidr}} ) then { accept; }      if ( net ~ {{$cidr}} ) then { accept; }    {{- end}}  {{- else }}      # Block {{$cidr}} is implicitly confirmed.      if ( net = {{$cidr}} ) then { accept; }      if ( net ~ {{$cidr}} ) then { accept; }  {{- end }}{{- end}}}

升级calico-node映射此configmap配置文件

重建calico-node

查看Bird节点

ip routedefault via 192.168.2.1 dev eth0 10.41.0.0/16 via 192.168.0.40 dev eth1 proto bird 10.41.57.199 via 192.168.0.25 dev eth1 proto bird 10.41.57.203 via 192.168.0.25 dev eth1 proto bird 10.41.57.204 via 192.168.0.25 dev eth1 proto bird 10.41.113.193 via 192.168.0.7 dev eth1 proto bird 10.41.113.194 via 192.168.0.7 dev eth1 proto bird 10.41.113.195 via 192.168.0.7 dev eth1 proto bird 10.41.113.196 via 192.168.0.7 dev eth1 proto bird 10.41.113.198 via 192.168.0.7 dev eth1 proto bird 10.41.113.201 via 192.168.0.7 dev eth1 proto bird 10.41.113.202 via 192.168.0.7 dev eth1 proto bird 10.41.210.6 via 192.168.2.15 dev eth0 proto bird 10.41.210.7 via 192.168.2.15 dev eth0 proto bird 10.41.210.8 via 192.168.2.15 dev eth0 proto bird 10.41.210.9 via 192.168.2.15 dev eth0 proto bird 10.41.210.137 via 192.168.2.14 dev eth0 proto bird 10.41.210.138 via 192.168.2.14 dev eth0 proto bird 10.42.0.0/16 via 192.168.0.40 dev eth1 proto bird

已经学习到了每个pod的明细路由，这种方式会导致路由设备压力巨大，因为需要维护大量的路由条目，并且pod的每次删除和创建都会引发的路由条目更新。在实际生产中请谨慎评估后使用。

而实际业务在使用的过程中，会针对一个服务或者一个deployment分配一个IP Pool，这种使用模式会导致Calico的IP Pool没有办法按照Node聚合，出现一些零散的无法聚合的IP地址，最差的情况，会导致每个Pod产生一条路由，会导致路由的条目变为Pod级别。
在默认情况下，交换机设备为了防止路由震荡，会对BGP路由进行收敛保护。但是Kubernetes集群中，Pod生命周期短，变化频繁，需要关闭网络设备的路由变更保护机制才能满足Kubernetes的要求；对于不同的网络设备，路由收敛速度也是不同的，在大规模Pod扩容和迁移的场景，或者进行双数据中心切换，除了考虑Pod的调度时间、启动时间，还需要对网络设备的路由收敛速度进行性能评估和压测。

https://blog.51cto.com/u_14992974/2549877

Service-CIDR路由发布

为了使集群外部也可以通过Service的Cluster-ip访问到集群内部服务，可以将Service-cidr通过Calico-bgp进行发布。

calicoctl patch BGPConfig default --patch '{"spec": {"serviceClusterIPs": [{"cidr": "10.43.0.0/16"}]}}'

发布后在bird节点上可以看见多条10.43.0.0/16地址，因为采用ECMP(等价多路径)方式实现路由负载均衡。

ip route10.43.0.0/16 proto bird         nexthop via 192.168.0.7 dev eth1 weight 1         nexthop via 192.168.0.25 dev eth1 weight 1         nexthop via 192.168.2.14 dev eth0 weight 1         nexthop via 192.168.2.15 dev eth0 weight 1

配置明细路由后发布后，Service-CIDR在BGP路由器中无法看见，可以通过修改bird_aggr.cfg.template文件

添加以下配置，$servicesubnet_split网段根据集群实际Service-CIDR进行修改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

{{- $servicesubnet_split := split "10.43.0.0/16" " " }}

---
  # Service IP block
{{- if $servicesubnet_split}}
{{- range $servicesubnet_split}}
   route {{.}} blackhole;
{{- end}}
{{- end}}


---
function accept_servicesubnet () 
{
{{- range $servicesubnet_split}}
  if ( net = {{.}} ) then { accept; }
  if ( net ~ {{.}} ) then { reject; }
{{- end}}
}
function deny_servicesubnet ()
{
{{- range $servicesubnet_split}}
  if ( net = {{.}} ) then { reject; }
  if ( net ~ {{.}} ) then { reject; }
{{- end}}
}

完整bird_aggr.cfg.template配置文件如下：

# Generated by confd{{- $block_key := printf "/calico/ipam/v2/host/%s/ipv4/block" (getenv "NODENAME")}}{{- $static_key := "/calico/staticroutes"}}{{- $servicesubnet_split := split "10.43.0.0/16" " " }}{{if or (ls $block_key) (ls $static_key)}}protocol static {{{- if ls $block_key}}   # IP blocks for this host.{{- range ls $block_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}} #  route {{$cidr}} blackhole;{{- end}}{{- end}}{{- if ls $static_key}}   # Static routes.{{- range ls $static_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}} #   route {{$cidr}} blackhole;{{- end}}{{- end}}  # Service IP block{{- if $servicesubnet_split}}{{- range $servicesubnet_split}}   route {{.}} blackhole;{{- end}}{{- end}}}{{else}}# No IP blocks or static routes for this host.{{end}}# Aggregation of routes on this host; export the block, nothing beneath it.# Export the service block.function accept_servicesubnet () {{{- range $servicesubnet_split}}  if ( net = {{.}} ) then { accept; }  if ( net ~ {{.}} ) then { reject; }{{- end}}}function deny_servicesubnet (){{{- range $servicesubnet_split}}  if ( net = {{.}} ) then { reject; }  if ( net ~ {{.}} ) then { reject; }{{- end}}}function calico_aggr (){{{- range ls $block_key}}{{- $parts := split . "-"}}{{- $cidr := join $parts "/"}}{{- $affinity := json (getv (printf "%s/%s" $block_key .))}}  {{- if $affinity.state}}      # Block {{$cidr}} is {{$affinity.state}}    {{- if eq $affinity.state "confirmed"}}      if ( net = {{$cidr}} ) then { accept; }      if ( net ~ {{$cidr}} ) then { accept; }    {{- end}}  {{- else }}      # Block {{$cidr}} is implicitly confirmed.      if ( net = {{$cidr}} ) then { accept; }      if ( net ~ {{$cidr}} ) then { accept; }  {{- end }}{{- end}}}
]]> <h3 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h3><p>calico网络插件最为知名的就是calico-bgp模式，在测试中需要验证calico-bgp跨子网路由同步，需要连接两个子网的路由器支持 Neuvector介绍和部署 http://yoursite.com/2022/03/17/neuvector_1/ 2022-03-17T13:45:59.000Z 2022-03-17T13:45:59.000Z Neuvector介绍

NeuVector 是最早开发 Docker/Kubernetes 安全产品的公司，是 Kubernetes 网络安全的领导
者，NeuVector 致力于保障企业级容器平台安全，产品适用于各种云环境、跨云或者本地部署等容器生产环境。NeuVector 提供实时深入的容器网络可视化、东西向容器网络监控、主动隔离和保护、容器主机安全以及容器内部安全。和容器管理平台无缝集成并且实现应用级容器安全的自动化。
2021年SUSE收购Neuvector，并将其开源。

项目地址：
https://github.com/neuvector/neuvector

架构解析

NeuVector本身包含Controller、Enforcer、Manager、Scanner、Updater模块。

Controller：整个Neuvector的控制模块，API入口，包括配置下发，高可用主要考虑Controller的HA，通常建议部署3个Controller模块组成集群。

Enforcer：主要用于安全策略部署下发和执行，DaemonSet类型会在每个节点部署。
Manager：提供web-UI(仅HTTPS)和CLI控制台，供用户管理NeuVector。
Scanner:对节点、容器、Kubernetes、镜像进行CVE漏洞扫描
Updater:cronjob，用于定期更新CVE漏洞库

功能介绍

  • 安全漏洞扫描
  • 容器网络流量可视化
  • 网络安全策略定义
  • L7防火墙
  • CICD安全扫描
  • 合规分析
    本篇文档更多侧重安装部署，实际功能介绍在后续文章进行深入介绍

NeuVector安装

安装环境
软件版本：
OS：Ubuntu18.04
Kubernetes：1.20.14
Rancher：2.5.12
Docker：19.03.15
NeuVector：5.0.0-b1

快速部署

创建namespace

kubectl create namespace neuvector

部署CRD(Kubernetes 1.19+版本)

1
2
3
4
5

kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/waf-crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/dlp-crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/admission-crd-k8s-1.19.yaml

部署CRD(Kubernetes 1.18或更低版本)

1
2
3
4
5

kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/crd-k8s-1.16.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/waf-crd-k8s-1.16.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/dlp-crd-k8s-1.16.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/admission-crd-k8s-1.16.yaml

配置RBAC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
kubectl create clusterrole neuvector-binding-app --verb=get,list,watch,update --resource=nodes,pods,services,namespaces
kubectl create clusterrole neuvector-binding-rbac --verb=get,list,watch --resource=rolebindings.rbac.authorization.k8s.io,roles.rbac.authorization.k8s.io,clusterrolebindings.rbac.authorization.k8s.io,clusterroles.rbac.authorization.k8s.io
kubectl create clusterrolebinding neuvector-binding-app --clusterrole=neuvector-binding-app --serviceaccount=neuvector:default
kubectl create clusterrolebinding neuvector-binding-rbac --clusterrole=neuvector-binding-rbac --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-admission --verb=get,list,watch,create,update,delete --resource=validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl create clusterrolebinding neuvector-binding-admission --clusterrole=neuvector-binding-admission --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-customresourcedefinition --verb=watch,create,get,update --resource=customresourcedefinitions
kubectl create clusterrolebinding  neuvector-binding-customresourcedefinition --clusterrole=neuvector-binding-customresourcedefinition --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-nvsecurityrules --verb=list,delete --resource=nvsecurityrules,nvclustersecurityrules
kubectl create clusterrolebinding neuvector-binding-nvsecurityrules --clusterrole=neuvector-binding-nvsecurityrules --serviceaccount=neuvector:default
kubectl create clusterrolebinding neuvector-binding-view --clusterrole=view --serviceaccount=neuvector:default
kubectl create rolebinding neuvector-admin --clusterrole=admin --serviceaccount=neuvector:default -n neuvector
kubectl create clusterrole neuvector-binding-nvwafsecurityrules --verb=list,delete --resource=nvwafsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvwafsecurityrules --clusterrole=neuvector-binding-nvwafsecurityrules --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-nvadmissioncontrolsecurityrules --verb=list,delete --resource=nvadmissioncontrolsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvadmissioncontrolsecurityrules --clusterrole=neuvector-binding-nvadmissioncontrolsecurityrules --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-nvdlpsecurityrules --verb=list,delete --resource=nvdlpsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvdlpsecurityrules --clusterrole=neuvector-binding-nvdlpsecurityrules --serviceaccount=neuvector:default

检查是否有以下RBAC对象

kubectl get clusterrolebinding  | grep neuvectorkubectl get rolebinding -n neuvector | grep neuvectorkubectl get clusterrolebinding  | grep neuvectorneuvector-binding-admission                            ClusterRole/neuvector-binding-admission                            44hneuvector-binding-app                                  ClusterRole/neuvector-binding-app                                  44hneuvector-binding-customresourcedefinition             ClusterRole/neuvector-binding-customresourcedefinition             44hneuvector-binding-nvadmissioncontrolsecurityrules      ClusterRole/neuvector-binding-nvadmissioncontrolsecurityrules      44hneuvector-binding-nvsecurityrules                      ClusterRole/neuvector-binding-nvsecurityrules                      44hneuvector-binding-nvwafsecurityrules                   ClusterRole/neuvector-binding-nvwafsecurityrules                   44hneuvector-binding-rbac                                 ClusterRole/neuvector-binding-rbac                                 44hneuvector-binding-view                                 ClusterRole/view                                                   44hkubectl get rolebinding -n neuvector | grep neuvectorneuvector-admin         ClusterRole/admin            44h

部署NeuVector
底层runtime为Docker

kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/neuvector-docker-k8s.yaml

底层runtime为containerd（对于k3s和rke2可以使用此yaml文件）

kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/neuvector-containerd-k8s.yaml

1.21以下的Kubernetes版本会提示以下错误，将yaml文件下载将batch/v1修改为batch/v1beta1

error: unable to recognize "https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/neuvector-docker-k8s.yaml": no matches for kind "CronJob" in version "batch/v1"

1.20.x cronjob还处于beta阶段没有正式GA,1.21版本开始cronjob才进入正式版。

默认部署web-ui使用的是loadblance类型的Service，为了方便访问修改为NodePort，也可以通过Ingress对外提供服务

kubectl patch  svc neuvector-service-webui  -n neuvector --type='json' -p '[{"op":"replace","path":"/spec/type","value":"NodePort"},{"op":"add","path":"/spec/ports/0/nodePort","value":30888}]'

访问https://node_ip:30888

默认密码为admin/admin

点击头像旁的My profile页面进入设置页面，设置密码和语言

Helm部署

添加repo

helm repo add neuvector https://neuvector.github.io/neuvector-helm/helm search repo neuvector/core

创建namespace

kubectl create namespace neuvector

创建ServiceAccount

kubectl create serviceaccount neuvector -n neuvector

helm安装

helm install neuvector --namespace neuvector neuvector/core  --set registry=docker.io  --set tag=5.0.0-preview.1 --set=controller.image.repository=neuvector/controller.preview --set=enforcer.image.repository=neuvector/enforcer.preview --set manager.image.repository=neuvector/manager.preview --set cve.scanner.image.repository=neuvector/scanner.preview --set cve.updater.image.repository=neuvector/updater.preview

Helm-chart参数查看
https://github.com/neuvector/neuvector-helm/tree/master/charts/core

高可用架构设计

NeuVector-HA主要需要考虑Controller模块的HA，只要有一个Controller处于打开状态，所有数据都将在3个副本之间之间同步。
Controller数据主要存储在 /var/neuvector/ 目录中，但出现POD重建或集群重新部署时，会自动从此目录加载备份文件，进行集群恢复。

部署策略

NeuVector官方提供四种HA部署模式

方式一：不进行任何调度限制，由Kubernetes进行自由调度管理管理。

方式二：NeuVector control组件(manager,controller）+enforce、scanner组件配置调度label限制和污点容忍，与Kubernetes master节点部署一起。

方式三：给Kubernetes集群中通过Taint方式建立专属的NeuVector节点，只允许NeuVector control组件部署。

方式四：NeuVector control组件(manager,controller）配置调度label限制和污点容忍，与Kubernetes master节点部署一起。k8s-master不部署enforce和scanner组件，意味着master节点不在接受扫描和策略下发。

以方式二为例，进行部署
给master节点打上特定标签

kubectl label nodes nodename nvcontroller=true

获取节点Taint

kubectl get node nodename -o yaml|grep -A 5 taint

以rancher部署的节点master节点为例

 taints:  - effect: NoSchedule    key: node-role.kubernetes.io/controlplane    value: "true"  - effect: NoExecute    key: node-role.kubernetes.io/etcd

编辑部署的yaml给NeuVector-control组件（manager,controller）添加nodeSelector和tolerations给enforce、scanner组件只添加tolerations。

例如以manager组件为例：

kind: Deploymentmetadata:  name: neuvector-manager-pod  namespace: neuvectorspec:  selector:    matchLabels:      app: neuvector-manager-pod  replicas: 1  template:    metadata:      labels:        app: neuvector-manager-pod    spec:      nodeSelector:        nvcontroller: "true"      containers:        - name: neuvector-manager-pod          image: neuvector/manager.preview:5.0.0-preview.1          env:            - name: CTRL_SERVER_IP              value: neuvector-svc-controller.neuvector      restartPolicy: Always      tolerations:      - effect: NoSchedule        key: "node-role.kubernetes.io/controlplane"        operator: Equal        value: "true"      - effect: NoExecute        operator: "Equal"        key: "node-role.kubernetes.io/etcd"        value: "true"

数据持久化

配置环境变量启用配置数据持久化

- env:  - name: CTRL_PERSIST_CONFIG

配置此环境变量后，默认情况下Neuvector-Controller会将数据存储在/var/neuvector目录内，默认此目录是hostpath映射在POD所在宿主机的/var/neuvector目录内。

若需要更高级别数据可靠性也可以通过PV对接nfs或其他支出多读写的存储中。
这样当出现Neuvector-Controller三个POD副本同时都销毁，宿主机都完全不可恢复时，也不会有数据配置数据丢失。
以下以NFS为例。
部署nfs

创建pv和pvc

cat <<EOF | kubectl apply -f -apiVersion: v1kind: PersistentVolumemetadata:  name: neuvector-dataspec:  capacity:    storage: 10Gi  accessModes:    - ReadWriteMany   nfs:    path: /nfsdata    server: 172.16.0.195 EOFcat <<EOF | kubectl apply -f -kind: PersistentVolumeClaimapiVersion: v1metadata:  name: neuvector-data  namespace: neuvectorspec:  accessModes:    - ReadWriteMany  resources:    requests:      storage: 10GiEOF

修改NeuVector-Controller部署yaml，添加pvc信息，将/var/neuvector目录映射到nfs中（默认是hostpath映射到本地)

spec:  template:    spec:      volumes:        - name: nv-share#         hostPath:                        // replaced by persistentVolumeClaim#           path: /var/neuvector        // replaced by persistentVolumeClaim          persistentVolumeClaim:            claimName: neuvector-data

或直接在NeuVector部署yaml中挂载nfs目录

      volumes:      - name: nv-share        nfs:          path: /opt/nfs-deployment          server: 172.26.204.144

多云安全管理


在实际生产应用中，会存在对多个集群进行安全进行管理，NeuVector支持集群联邦功能。
需要在一个集群上暴露Federation Master服务，在每个远端集群上部署Federation Worker服务。为了更好的灵活性，可以在每个集群同时启用Federation Master和Federation Worker服务。
在每个集群部署此yaml

apiVersion: v1kind: Servicemetadata:  name: neuvector-service-controller-fed-master  namespace: neuvectorspec:  ports:  - port: 11443    name: fed    nodePort: 30627    protocol: TCP  type: NodePort  selector:    app: neuvector-controller-pod---apiVersion: v1kind: Servicemetadata:  name: neuvector-service-controller-fed-worker  namespace: neuvectorspec:  ports:  - port: 10443    name: fed    nodePort: 31783    protocol: TCP  type: NodePort  selector:    app: neuvector-controller-pod

将其中一个集群升级为主集群

将其中一个集群升级为主集群，配置连接远程暴露ip和对remot cluster可达的端口。



在主集群中，生成token，用于其他remote cluster连接。

在remote cluster中配置加入主集群，配置token和连接端子

在界面可以对多个Neuvector集群进行管理

其他配置

升级

若是采用yaml文件方式部署的NeuVector直接更新对应的组件镜像tag即可完成升级。如

kubectl set image deployment/neuvector-controller-pod neuvector-controller-pod=neuvector/controller:2.4.1 -n neuvectorkubectl set image -n neuvector ds/neuvector-enforcer-pod neuvector-enforcer-pod=neuvector/enforcer:2.4.1

若是采用Helm部署的NeuVector，则直接执行helm update配置对应参数即可即可。

卸载

删除部署的组件

kubectl delete -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/neuvector-docker-k8s.yaml

删除配置的RBAC

kubectl get clusterrolebinding  | grep neuvector|awk '{print $1}'|xargs kubectl delete clusterrolebindingkubectl get rolebinding -n neuvector | grep neuvector|awk '{print $1}'|xargs kubectl delete rolebinding -n neuvector

删除对应的CRD

kubectl delete -f  https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/crd-k8s-1.19.yamlkubectl delete -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/waf-crd-k8s-1.19.yamlkubectl delete -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/admission-crd-k8s-1.19.yaml

总结：
SUSE此次开源的NeuVector是一个成熟稳定的容器安全管理平台，未来NeuVector会和Rancher产品更好的融合。

]]> <h3 id="Neuvector介绍"><a href="#Neuvector介绍" class="headerlink" title="Neuvector介绍"></a>Neuvector介绍</h3><p>NeuVector 是最早开发 Docker&#x2F;Kubern RKE2的简单使用 http://yoursite.com/2022/01/01/rke2/ 2022-01-01T13:45:59.000Z 2021-01-01T13:45:59.000Z 概述

软件版本：rke2 version v1.22.5+rke2r1
os：ubuntu18.04

RKE2是Rancher Kubernetes新的发行版，结合和k3s和RKE1的一些特性。与RKE1相比主要特性在于安全性，符合美国联邦政府部门的安全性和合规性，完整通过CIS安全基线标准，符合FIPS-140-2 标准和定期的镜像安全扫描。
比如结合k3s的一个单体二进制文件启动，底层runtime集成containerd。

与其他Kubernetes部署工具对比

组件集成度安全性组件容器化部署简易性
kubeadm低，需要单独部署kubelet、runtime等组件，然后在通过static-pod启动其他组件。中，默认安全配置除kubelet外全部容器化低，组件HA需要用户自己完成。
RKE-1低，单独部署runtime然后在通过rke部署集群。中，默认安全配置全部容器化高，一键部署，组件HA自动完成
RKE-2高，单体二进制文件集成runtime和kubelet，一键启动。高,专为安全而生，符合各项安全测试规范除kubelet外全部容器化中，每台节点需要单独操作安装，组件HA自动完成

RKE2部署

部署前提：

Linux部署前提条件：

  • 关闭swap。
  • 关闭NetworkManager（若有），或配置NetworkManager忽略 calico/flannel 相关网络接口。
  • 关闭Selinux，或参考下述链接配置Selinux规则。
  • 节点主机名采用标准FQDN格式。

若需要开启NetworkManager和Selinux，策略配置NetworkManager和Selinux策略链接：
https://rancher2.docs.rancher.cn/docs/rke2/known_issues/_index#networkmanager

通过完整兼容性测试的操作系统：

Ubuntu 18.04 (amd64)
Ubuntu 20.04 (amd64)
CentOS/RHEL 7.8 (amd64)
CentOS/RHEL 8.2 (amd64)
SLES 15 SP2 (amd64) (v1.18.16+rke2r1 和更新版本)

注：使用Cilium网络插件时，因为ebpf依赖内核技术，所以需要保证以下内核版本
1 、kernel版本 >= 4.9.17

通过RKE2单机方式快速部署Kubernetes

部署Server

下载rke2二进制可执行文件，和自动配置rke2-server

curl -sfL http://rancher-mirror.rancher.cn/rke2/install.sh | INSTALL_RKE2_MIRROR=cn sh -

设置rke2-server开机自启

systemctl enable rke2-server.service

启动rke2-server

systemctl start rke2-server.service

此时，将会通过rke2自动拉起kubelet，然后以static-pod方式启动api-server、Controller-manager、etcd、scheduler

日志查看：

journalctl -u rke2-server -f

默认情况下rke2将创建以下目录:

/var/lib/rancher/rke2/:存放额外部署的集群插件（core-dns、网络插件、Ingress-Controller）、etcd数据库存放路径、其他worker连接的token。
/etc/rancher/rke2/：连接集群的kubeconfig文件，以及集群组件参数配置信息。

将常用CLI配置软链接

ln -s /var/lib/rancher/rke2/bin/kubectl  /usr/bin/kubectlln -s /var/lib/rancher/rke2/bin/ctr /usr/bin/ctrln -s /var/lib/rancher/rke2/bin/crictl /usr/bin/crictl

配置kubeconfig

mkdir -p ~/.kube/cp /etc/rancher/rke2/rke2.yaml ~/.kube/config

验证查看:

kubectl get nodeNAME        STATUS   ROLES                       AGE   VERSIONrke-node6   Ready    control-plane,etcd,master   72m   v1.22.5+rke2r1

获取worker注册到server的token文件

cat /var/lib/rancher/rke2/server/token

部署worker
下载rke2二进制可执行文件，和自动配置rke2-server

curl -sfL http://rancher-mirror.rancher.cn/rke2/install.sh | INSTALL_RKE2_MIRROR=cn INSTALL_RKE2_TYPE="agent"  sh -

启动rke2-agent服务

systemctl enable rke2-agent.service

配置rke2-agent服务

mkdir -p /etc/rancher/rke2/vim /etc/rancher/rke2/config.yaml

配置文件内容如下：

server: https://<server>:9345token: <token from server node>

注：
rke2 server 进程通过端口 9345 监听新节点的注册。Kubernetes API 仍然监听端口 6443。

启动服务,等待服务启动注册成功。

systemctl start rke2-agent.service

日志查看

1
2
journalctl -u rke2-agent -f

查看最终部署

kubectl get nodeNAME        STATUS   ROLES                       AGE   VERSIONrke-node6   Ready    control-plane,etcd,master   81m   v1.22.5+rke2r1rke-node7   Ready    <none>                      70m   v1.22.5+rke2r1

测试验证

kubectl create deployment test --image=busybox:1.28  --replicas=2   -- sleep 30000

通过RKE2高可用方式部署Kubernetes

前提条件：

  • Apiserver统一入口（可选），为了方便外部访问集群，需要在集群实现统一入口，可以通过L4负载均衡器或vip地址或智能轮询DNS。集群内部已经通过rke2-agent实现了worker访问api-server的多入口反向代理。

  • 奇数个（推荐三个）的 server节点，运行 etcd、Kubernetes API 和其他控制节点服务。

部署顺序

  • 启动第一个 server 节点
  • 加入其他 server 节点
  • 加入 agent 节点

部署负载均衡器（可选）
以nginx为例，配置转发到9345和后端6443端口
创建nginx.conf文件

events {  worker_connections  1024;  ## Default: 1024} stream {    upstream kube-apiserver {        server host1:6443     max_fails=3 fail_timeout=30s;        server host2:6443     max_fails=3 fail_timeout=30s;        server host3:6443     max_fails=3 fail_timeout=30s;    }    upstream rke2 {        server host1:9345     max_fails=3 fail_timeout=30s;        server host2:9345     max_fails=3 fail_timeout=30s;        server host3:9345     max_fails=3 fail_timeout=30s;    }    server {        listen 6443;        proxy_connect_timeout 2s;        proxy_timeout 900s;        proxy_pass kube-apiserver;    }    server {        listen 9345;        proxy_connect_timeout 2s;        proxy_timeout 900s;        proxy_pass rke2;    }}

将对应的3个ip地址修改为实际server节点ip地址

启动nginx

docker run -itd -p 9345:9345  -p 6443:6443 -v ~/nginx.conf:/etc/nginx/nginx.conf nginx

实际生产环境部署建议部署两个nginx，中间通过keepalived维持vip实现统一入口。

部署第一个Server
下载rke2二进制可执行文件，和自动配置rke2-server

curl -sfL http://rancher-mirror.rancher.cn/rke2/install.sh | INSTALL_RKE2_MIRROR=cn sh -

设置rke2-server开机自启

systemctl enable rke2-server.service

配置config.yaml文件

mkdir /etc/rancher/rke2/ -p 
touch config.yaml

输入以内容

tls-san:  - xxx.xxx.xxx.xxx  - www.xxx.com

此处填写LB的统一入口ip地址或域名，如果有多个换行分组方式隔开。

启动rke2-server

systemctl start rke2-server.service

将常用CLI配置软链接

ln -s /var/lib/rancher/rke2/bin/kubectl  /usr/bin/kubectlln -s /var/lib/rancher/rke2/bin/ctr /usr/bin/ctrln -s /var/lib/rancher/rke2/bin/crictl /usr/bin/crictl

配置kubeconfig

mkdir -p ~/.kube/cp /etc/rancher/rke2/rke2.yaml ~/.kube/config

可以将kubeconfig文件中的中的ip地址由127.0.0.1替换为实际LB的IP地址。

获取注册到server的token文件

cat /var/lib/rancher/rke2/server/token

配置其他Server
配置rke2-agent服务

mkdir -p /etc/rancher/rke2/vim /etc/rancher/rke2/config.yaml

配置文件内容如下：

server: https://<server>:9345token: <token from server node>tls-san:  - xxx.xxx.xxx.xxx  - www.xxx.com

注：

  • server地址可以填写第一台Server的地址，也可以填写外部统一入口的地址，最佳实践是填写统一入口地址，这样当第一个Server出现问题后，agent还可以通过统一入口地址通过其他Server获取集群信息。
  • token填写第一台server的token
  • tls-san跟第一台server一样，一般填写统一入口的ip地址或域名，用于TLS证书注册。

下载rke2二进制可执行文件，和自动配置rke2-server

curl -sfL http://rancher-mirror.rancher.cn/rke2/install.sh | INSTALL_RKE2_MIRROR=cn sh -

设置rke2-server开机自启

systemctl enable rke2-server.service

启动rke2-server

systemctl start rke2-server.service

等待注册和集群启动

验证：

kubectl get nodeNAME        STATUS   ROLES                       AGE    VERSIONrke-node4   Ready    control-plane,etcd,master   140m   v1.22.5+rke2r1rke-node5   Ready    control-plane,etcd,master   138m   v1.22.5+rke2r1rke-node6   Ready    control-plane,etcd,master   19h    v1.22.5+rke2r1rke-node7   Ready    <none>                      19h    v1.22.5+rke2r1

进入etcd-pod，查看etcd集群状态。

etcdctl --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --endpoints https://127.0.0.1:2379 --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt member liste19d2834bb177be1, started, rke-node4-896165c9, https://192.168.0.25:2380, https://192.168.0.25:2379, falseec67af24a94fb07c, started, rke-node6-fed10843, https://192.168.0.32:2380, https://192.168.0.32:2379, falsef7e9f28da0a6e5e6, started, rke-node5-4a4b6af5, https://192.168.0.29:2380, https://192.168.0.29:2379, false

按单机操作加入agent节点。

通过RKE2离线部署kubernetes集群

Tarball模式

RKE2的离线部署方式与k3s比较相似，都是提前将对应的离线介质下载放置到对应的目录，启动二进制进程执行。

在RKE2对应的Release页下载对应的离线安装介质
https://github.com/rancher/rke2/releases
主要为以下离线安装介质

  • rke2-images.linux-amd64.tar
  • rke2.linux-amd64.tar.gz
  • sha256sum-amd64.txt
    根据所需要的不同网络插件，下载对应的镜像包
  • rke2-images-canal.linux-amd64.tar.gz
  • 离线安装脚本

将这些下载后的安装介质放置在节点的一个统一目录如/root/images

下载离线安装脚本

curl -sfL https://get.rke2.io --output install.sh

部署安装

INSTALL_RKE2_ARTIFACT_PATH=/root/images sh install.sh

执行此脚本，将自动对离线介质进行解压到对应目录。
接下来就跟在线安装一样，启动RKE2的进程，进行部署server和agent
启动rke2

设置rke2-server开机自启

systemctl enable rke2-server.service

启动rke2-server

systemctl start rke2-server.service

等待注册和集群启动

Private Registry

将镜像上传到镜像仓库
可以使用rancher的rancher-load-images.sh脚本结合rke2-images-all.linux-amd64.txt文件进行镜像上传。

下载rke2可执行文件rke2.linux-amd64.tar.gz
解压，将systemctl文件和rke2可执行文件复制到对应目录

cp lib/systemd/system/* /usr/local/lib/systemd/system/
cp bin/* /usr/local/bin/
cp share/* /usr/local/share/ -rf

配置config.yaml，指定默认拉取镜像

system-default-registry: xxx.xxx.xxx.xxx

若私有镜像仓库为http或自签名https需要在/etc/rancher/rke2 /registries.yaml进行配置
但这里我配置的insecure-registry没有生效，具体issue查看：https://github.com/rancher/rke2/issues/2317

通过RKE2部署Kubernetes高可用实现原理

RKE2部署的Kubernetes和其他Kubernetes的组件需要HA的方式是一致的.
Kubernetes 集群的高可用是针对：

  • etcd
  • controller-manager
  • scheduler
  • apiserver

etcd：通过本身的 Raft 算法 Leader 选主机制，组成ETCD集群，实现 etcd 高可用。

controller manager：leader election 选举竞争锁的机制来保证高可用。

scheduler：leader election 选举竞争锁的机制来保证高可用。

apiserver：无状态，通过前端负载均衡实现高可用。

另外一个在于在rke2集群中，containerd、kubelet组件集成到了rke2服务中，这点和k3s非常相式，同时在rke2服务中还集成了nginx服务，主要用于做为kubelet连接api-server的方向代理。

HA的主要区别在于API-server统一入口，因为RKE2会帮助其他组件自动做HA，

当有统一入口时，跟kubeadm和其他原生Kubernetes一样，所有请求都会通过统一负载均衡器连接到后端的rke2-server。

如果api-server没有统一入口，kubelet和rke2-agent去连接rke2-server时，会用一个server地址去注册即可，然后agent会获取 所有rke2 server 的地址，然后存储到 /var/lib/rancher/rke2/agent/etc/rke2-api-server-agent-load-balancer.json中，生成nginx反向代理配置
比如：

cat rke2-agent-load-balancer.json{  "ServerURL": "https://192.168.3.10:9345",  "ServerAddresses": [    "192.168.3.11:9345",    "192.168.3.12:9345"  ],  "Listener": null

当192.168.3.10 挂掉之后，会自动切换到另一个rke2 server 去连接。当192.168.3.10恢复后，回重新连接192.168.3.10。

另外在前面也提到，rke2里面也集成了containerd，那么问题来了，如果rke2-agent进程出现问题down了，是否会影响平台上业务正常运行呢？
答案是，不会影响业务正常运行，因为containerd创建容器是通过containerd-shim-runc-v2调用runc创建，当containerd出现问题时containerd-shim-runc-v2会被init进程托管，不会导致退出影响现有业务POD。但需要注意的是rke2-agent退出后kubelet也退出了，对应的业务状态探测就没有了，在默认超时5分钟后，Controller-manager会将业务pod重建。

其他使用技巧

使用RKE2部署Kubernetes使用其他网络插件

默认情况下rke2部署使用的是canal做为网络插件，还支持calico和cilium网络插件，若想使用其他网络插件只需要进行配置即可。

如cilium
cilium依赖内核bfp特性，在启用前需要先进行挂载。
检查是否有进行挂载

mount | grep /sys/fs/bpf

进行挂载

sudo mount bpffs -t bpf /sys/fs/bpfsudo bash -c 'cat <<EOF >> /etc/fstabnone /sys/fs/bpf bpf rw,relatime 0 0EOF'

在次检查

mount | grep /sys/fs/bpfbpffs on /sys/fs/bpf type bpf (rw,relatime)bpffs on /sys/fs/bpf type bpf (rw,relatime)

在start rke2-server和agent服务前先配置config.yaml

mkdir -p /etc/rancher/rke2/vim /etc/rancher/rke2/config.yaml

添加以下参数

cni: cilium

启动rke2-server

systemctl start rke2-server.service

查看是否部署成功

kubectl get pod -ANAMESPACE     NAME                                                    READY   STATUS              RESTARTS   AGEkube-system   cilium-6rfzw                                            1/1     Running             0          52skube-system   cilium-node-init-998vd                                  1/1     Running             0          52skube-system   cilium-operator-85f67b5cb7-nw7n8                        1/1     Running             0          52skube-system   cilium-operator-85f67b5cb7-qc2vh                        0/1     Pending             0          52skube-system   cloud-controller-manager-rke-node4                      1/1     Running             0          65skube-system   etcd-rke-node4                                          1/1     Running             0          73s

组件参数配置

在/etc/rancher/rke2/config.yaml 文件中，按照对应组件，添加对应的参数，如apiserver对应为kube-apiserver-arg，组件对应参数为etcd-arg。kube-controller-manager-arg、kube-scheduler-arg、kubelet-arg、kube-proxy-arg。

1
2
3
4
5
6
7
8
etcd-arg:
  - "quota-backend-bytes=858993459"
  - "max-request-bytes=33554432"
kube-apiserver-arg:
  - "watch-cache=true"
kubelet-arg:
  - "system-reserved=cpu=1,memory=2048Mi"

配置完成后启动rke2-server。agent节点要同步时配置，否则kubelet和kube-proxy参数将不生效

检查参数是否生效
如：

ps aux|grep system-reserved

集群备份和还原

rke2备份文件保存在每个拥有etcd角色的节点的/var/lib/rancher/rke2/server/db/snapshots目录内，拥有多副本保存。
默认每隔12小时备份一次，保留5份。

注：目前版本只能通过定时备份，没有立刻备份的选型。
将

指定备份文件恢复

关闭rke2-server进程

systemctl stop rke2-server

指定文件恢复

rke2 server \  --cluster-reset \  --cluster-reset-restore-path=<PATH-TO-SNAPSHOT>

若是HA集群，还原成功后在其他server节点将执行rm -rf /var/lib/rancher/rke2/server/db然后重新启动server，加入集群。

rke2跟rke1一样也支持将备份文件在一个新集群进行还原。

常见操作

参考链接：
https://gist.github.com/superseb/3b78f47989e0dbc1295486c186e944bf

查看本机运行的容器

ctr命令

/var/lib/rancher/rke2/bin/ctr --address /run/k3s/containerd/containerd.sock --namespace k8s.io container ls

crictl命令

export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml/var/lib/rancher/rke2/bin/crictl ps
/var/lib/rancher/rke2/bin/crictl --config /var/lib/rancher/rke2/agent/etc/crictl.yaml ps
/var/lib/rancher/rke2/bin/crictl --runtime-endpoint unix:///run/k3s/containerd/containerd.sock ps -a

最终都是连接到containerd的socket文件

查看日志

journalctl -f -u rke2-server/var/lib/rancher/rke2/agent/containerd/containerd.log/var/lib/rancher/rke2/agent/logs/kubelet.log

etcd操作

etcdctl check perf

for etcdpod in $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name); do kubectl -n kube-system exec $etcdpod -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl check perf"; done

etcdctl endpoint status

for etcdpod in $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name); do kubectl -n kube-system exec $etcdpod -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl endpoint status"; done

etcdctl endpoint health

for etcdpod in $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name); do kubectl -n kube-system exec $etcdpod -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl endpoint health"; done

etcdctl compact

rev=$(kubectl -n kube-system exec $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name | head -1) -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl endpoint status --write-out fields | grep Revision | cut -d: -f2")kubectl -n kube-system exec $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name | head -1) -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl compact \"$(echo $rev)\""

etcdctl defrag

kubectl -n kube-system exec $(kubectl -n kube-system get pod -l component=etcd --no-headers -o custom-columns=NAME:.metadata.name | head -1) -- sh -c "ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' ETCDCTL_CACERT='/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt' ETCDCTL_CERT='/var/lib/rancher/rke2/server/tls/etcd/server-client.crt' ETCDCTL_KEY='/var/lib/rancher/rke2/server/tls/etcd/server-client.key' ETCDCTL_API=3 etcdctl defrag --cluster"

对应的，直接操作etcdctl
参考：https://gist.github.com/superseb/3b78f47989e0dbc1295486c186e944bf

]]> <h2 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h2><p>软件版本：rke2 version v1.22.5+rke2r1<br>os：ubuntu18.04</p> <p>RKE2是Rancher Jenkins与外部系统集成 http://yoursite.com/2021/10/14/jenkins_Docking_external_system/ 2021-10-14T13:45:59.000Z 2021-10-14T13:45:59.000Z 环境准备

软件版本

软件版本
gitlab14.3.0
Jenkins2.303.1
Harbor1.10.2
Sonar9.1
Nexus3.35.0-02
ArgoCD2.1.3

部署gitlab

1
docker run --detach --hostname 10.8.242.28 --publish 443:443 --publish 80:80 --publish 1022:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:12.10.3-ce.0

替换hostname为实际节点外网IP

部署Harbor

Harbor部署与管理
部署前先修改docker
编辑docker

1
2
3
4
vim /etc/docker/daemon.json
{
 "insecure-registries" : ["0.0.0.0/0"]
}

重启docker

1
systemctl restart docker

安装docker-compose

1
2
curl -L https://github.com/docker/compose/releases/download/1.24.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

下载harbor 

1
https://github.com/goharbor/harbor/releases/download/v1.10.2/harbor-online-installer-v1.10.2.tgz

配置harbo.yaml 

1
hostname: 172.31.48.86 //修改为实际节点IP

屏蔽https配置

安装harbor 

1
./install.sh --with-clair
1
2
3
4
5
6
7
8
9
10
11
12
13
14
docker-compose  ps
      Name                     Command                  State                 Ports          
---------------------------------------------------------------------------------------------
clair               /docker-entrypoint.sh            Up (healthy)   6060/tcp, 6061/tcp       
harbor-core         /harbor/start.sh                 Up (healthy)                            
harbor-db           /entrypoint.sh postgres          Up (healthy)   5432/tcp                 
harbor-jobservice   /harbor/start.sh                 Up                                      
harbor-log          /bin/sh -c /usr/local/bin/ ...   Up (healthy)   127.0.0.1:1514->10514/tcp
harbor-portal       nginx -g daemon off;             Up (healthy)   80/tcp                   
nginx               nginx -g daemon off;             Up (healthy)   0.0.0.0:80->80/tcp       
redis               docker-entrypoint.sh redis ...   Up             6379/tcp                 
registry            /entrypoint.sh /etc/regist ...   Up (healthy)   5000/tcp                 
registryctl         /harbor/start.sh                 Up (healthy)

访问http://node_ip

admin/Harbor12345

创建测试项目

spring-petclinic官方示例项目地址：https://projects.spring.io/spring-petclinic/

本次实践针对Spring官方提供的spring-petclinic示例项目进行容器化部署，该项目采用Spring Boot + Thymeleaf开发，数据库可使用MySQL、H2等，本实践为操作方便直接使用内置的H2数据库。

注意：由于本实践采用的是H2内置数据库，所以每个应用实例的数据独立，也使得应用变成了有状态应用，而生产的最佳实践应该是数据采用外部存储，且应用采用无状态方式部署。

国内clone地址：https://gitee.com/wanshaoyuan/spring-petclinic.git

将此项目clone后上传到私有的gitlab中.

与Gitlab集成

安装gitlab插件

Gitlab中申请AccessToken

将申请成功的token保存好

配置Jenkins对接gitlab


添加凭证

测试连接

测试

读取gitlab中项目spring-petclinic项目中pom.xml文件

配置连接gitlab私有项目的密钥可以用ssh密钥也可以使用账号密码


分支处修改为main分支

构建

去cat这个文件输出内容

执行立即构建

输出结果为实际我们的pom.xml的文件内容

与Kubernetes集成构建分布式动态编译环境

安装Kubernetes插件

Jenkins与Kubernetes集成实现动态Slave Pod，需要安装Kubernetes插件：

  • kubernetes

安装Kubernetes Continuous Deploy插件

Jenkins访问kubernetes需要依赖于kubeconfig，为支持kubeconfig类型的凭据配置，需要安装Kubernetes Continuous Deploy插件：

  • Kubernetes Continuous Deploy

配置Kubernetes集群

配置 系统管理—>系统设置—>新增一个云

配置Jenkins URL，这里可以不配置api-server地址和证书key，连接kubernetes，所以默认会去读取放在JENKINS_HOME的.kube/目录的kubeconfig文件，用于连接集群。我这里是通过安装包的方式安装的Jenkins HOME在/var/lib/jenkins/目录，如果是通过容器方式启动，将kubeconfig文件直接放~/.kube/目录。
保存到Jenkins主机的config文件中

复制粘贴到Jenkins容器内的~/.kube/config文件中

1
2
docker exec -it jenkins mkdir /root/.kube/
docker cp config  jenkins:/root/.kube/config

注意：
此方式Jenkins容器重启后，会将目录重新初始化覆盖掉，kubeconfig文件，生产环境可以直接挂载。

验证Pipeline流水线

以上Jenkins与Kubernetes的集成配置就基本完成了，下面在正式为Spring Petclinic应用创建Pipeline之前，先简单测试下Jenkins与Kubernetes集成Pipeline流水线是否正常。

  • 新建一个流水线类型的任务test-hello-pipeline

  • 准备流水线测试脚本
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
pipeline {
  agent {
    kubernetes {
      cloud 'Kubernetes'
      namespace 'default'
      yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: busybox
      image: busybox
      command:
      - sleep
      args:
      - infinity
"""
    }
  }
  stages {
    stage('Test') {
      steps {
        container('busybox') {
            sh "echo 'hello world'"
        }
      }
    }
  }
}

以上是一个简单的声明式pipeline，利用busybox镜像输出hello world字符串。

  • 添加流水线脚本

把测试脚本添加到任务的流水线脚本框中：

  • 保存流水线，并执行构建

  • 查看JOB运行结果

在Kubernetes中可以看到Jenkins自动创建了Pod来执行任务，任务执行完成以后，Pod自动删除。

Jenkins中查看下构建的控制台输出，正常输出了hello world：

验证结果表明，Jenkins与Kubernetes配置成功，Pipeline运行正常。

Sonar-Qube对接实现代码质量扫描


安装sonarqube

初始化

1
2
3
helm repo add sonarqube https://SonarSource.github.io/helm-chart-sonarqube
helm repo update
kubectl create namespace sonarqube

helm安装sonarqube

1
helm install  sonarqube  --namespace sonarqube  sonarqube/sonarqube --set postgresql.persistence.enabled=false

注意：这里为了快速部署没有设置postgresql的持久化存储，有数据丢失风险，生产环境postgresql建议设计HA或持久化存储。
设置为NodePort对外暴露

1
kubectl patch svc sonarqube-sonarqube -p '{"spec": {"type": "NodePort"}}' -n sonarqube

查看NodePort端口

1
2
3
4
5
kubectl  get svc -n sonarqube
NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
sonarqube-postgresql            ClusterIP   10.110.40.18    <none>        5432/TCP         4m41s
sonarqube-postgresql-headless   ClusterIP   None            <none>        5432/TCP         4m41s
sonarqube-sonarqube             NodePort    10.106.78.100   <none>        9000:30005/TCP   4m41s

查看启动成功

1
2
3
4
 kubectl get pod -n sonarqube
NAME                     READY   STATUS    RESTARTS   AGE
sonarqube-postgresql-0   1/1     Running   0          4m7s
sonarqube-sonarqube-0    1/1     Running   0          4m7s

访问节点的30005端口

默认密码admin/admin

如果需要中文直接安装插件就好
administrator—->Marketplace
搜索Chinese—-安装

生成token
申请token
administrator—>security—>user—>token
保存生成token

Jenkins配置

安装插件
系统设置—>插件管理
安装SonarQube Scanner for Jenkins

配置插件
配置sonarQube-server

Server URL填写sonarqube的地址

Server authentication token填写刚刚创建的token，这里创建一个密钥
类型为Secret Text。Secret填写token详细信息，ID为此secret的名称

配置sonarQUbe-agent
系统管理->全局工具配置——>SonarQube Scanner
此处配置为自动安装

FreeStyle风格任务下配置SonarQube

以上面的test-gitlab项目的spring-petclinic为例
先执行maven构建出class文件，在进行扫描,因为sonarQube扫描的对象是.class而不是.java文件。

1
docker run -i -v /var/jenkins_home/workspace/:/tmp  maven:3.6-jdk-8 mvn -f /tmp/spring-petclinic/pom.xml clean package -DskipTests

在构建阶段添加”Execute SonarQube Scanner”

输入以下内容

1
2
3
4
5
6
7
sonar.projectKey=test
sonar.projectName=test
sonar.projectVersion=1.0
sonar.sources=src
sonar.java.binaries=target/classes
sonar.language=java
sonar.sourceEncoding=UTF-8

注：
sonar.projectKey=Test #sonar那显示project-key
sonar.projectName=Test #sonar那显示project名字
sonar.projectVersion=1.0 ##sonar那显示project版本
sonar.sources=src #指定要扫描的源码目录。
sonar.java.binaries=target/classes #指定java文件编译后class文件目录。
sonar.language=java #只扫描的语言。
sonar.sourceEncoding=UTF-8 #指定源码的编码格式，一般都会去指定为UTF-8。

执行构建
Jenkins处查看

sonar处查看

Jenkins-Pipeline风格任务下配置SonarQube

使用Pipeline流水线，需要在添加以下步骤

1、在对应的代码库的根目录创建sonar-project.properties 

1
2
3
4
5
6
7
8
9
sonar.projectKey=test2
sonar.projectName=test2
sonar.projectVersion=1.0
sonar.sources=src
sonar.java.binaries=target/classes
sonar.java.source=1.8
sonar.java.target=1.8
sonar.language=java
sonar.sourceEncoding=UTF-8

Pipeline中添加以下步骤

Pipeline中添加以下步骤

1
2
3
4
5
6
7
8
9
10
stage('SonarQube analysis') {
      steps {
        script {
        def sonarqubeScannerHome = tool name: 'SonarQubeScanner'
            withSonarQubeEnv('sonar') {
            sh "${sonarqubeScannerHome}/bin/sonar-scanner"
         }
        }
      }
    }

注：
1、SonarQubeScanner为全局工具配置中的SonarQube Scanner的配置名称。
2、withSonarQubeEnv配置的sonar变量为全局——>系统配置sonar-server的配置名称

清空workspace

1
rm -rf /var/jenkins_home/workspace/spring-petclinic

Sonattype-Nexus

Nexus是开源的制品库，可以用来存储一些代码构建后的制品如jar包，npm包和docker镜像等。也可以将存放制品后的仓库做为私服，供给给后面需要内网编译的软件使用。

部署安装

软件版本：3.35.0-02
本次部署为了更加方便和快捷，采用Docker方式部署
创建目录

1
mkdir /var/nexus-data && chown -R 200 /var/nexus-data

Docker运行

1
docker run -d -p 8081:8081 --name nexus -v /var/nexus-data:/nexus-data sonatype/nexus3

初始账号和密码访问
账号：admin
密码： 

1
cat /var/nexus-data/admin.password

创建仓库

仓库分为三种类型，proxy、group、hosted。
Proxy：Repository是代理仓库，可以配置上游仓库地址，如阿里云仓库地址。当本地仓库不到时，去向配置的上游仓库查找。
hosted：供本地使用的本地仓库。
group：仓库组，将多个仓库合成一个组，查找jar包时，会按照仓库组中的仓库顺序下载jar包。

这里创建两个名为spring-petclinic-releases、spring-petclinic-snapshots，类型为hotsted的Maven2仓库。

releases库主要用于存储正式版的制品，snapshots存储持续集成过程中产生的制品。

这里可以根据情况进行修改为release或snapshots

maven处配置
在spring-petclinic目录下创建conf/settings.xml文件用于存放连接Nexus3的凭证信息，正常可以在maven_home或~/.m2/目录有这文件。因为这里是使用Docker进行构建编译，所以这里直接与业务代码放置在一起。
settings.xml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <pluginGroups>
  </pluginGroups>
  <proxies>
  </proxies>
 <servers>
     <server>
      <id>releases</id>
      <username>账号</username>
      <password>密码</password>
     </server>
     <server>
      <id>snapshots</id>
      <username>账号</username>
      <password>密码</password>
     </server>
  </servers>
</settings>

关闭https检测，因为Nexus3使用的是http方式对外暴露所以需要关闭maven构建时强行要求https链接

src/checkstyle/nohttp-checkstyle.xml
注释
<module name="io.spring.nohttp.checkstyle.check.NoHttpCheck"/>
注释后：
<!-- <module name="io.spring.nohttp.checkstyle.check.NoHttpCheck"/> -->

pom.xml文件添加以下内容

1
2
3
4
5
6
7
8
9
10
11
12
13
<distributionManagement>
        <repository>
            <!--id的名字可以任意取，但是在setting文件中的属性<server>的ID与这里一致-->
            <id>releases</id>
            <!--指向仓库类型为host(宿主仓库）的储存类型为Release的仓库-->
            <url>http://172.16.0.195:8081/repository/mspring-petclinic-releases/</url>
        </repository>
        <snapshotRepository>
            <id>snapshots</id>
            <!--指向仓库类型为host(宿主仓库）的储存类型为Snapshot的仓库-->
            <url>http://172.16.0.195:8081/repository/spring-petclinic-snapshots/</url>
        </snapshotRepository>
  </distributionManagement>

执行编译

1
docker run -i -v /root/spring-petclinic/:/tmp  maven:3.6-jdk-8 mvn -f /tmp/pom.xml --settings /tmp/conf/settings.xml clean deploy

编译完成上传成功后

在spring-petclinic-snapshots仓库内可见上传来的jar包，对应的jar包后面也接上了对应的时间戳，方便进行分类。

如果要上传到release仓库，将pom.xml中的<version>2.5.0-SNAPSHOT</version>中的-SNAPSHOT字段删除就表示为正式版。

ArgoCD集成实现CD端对接

编写并上传部署spring-petclinic的yaml文件和Dockerfile文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-petclinic-0-0-1
spec:
  selector:
    matchLabels:
      app: spring-petclinic
      version: 0.0.1
  replicas: 1
  template:
    metadata:
      labels:
        app: spring-petclinic
        version: 0.0.1
    spec:
      containers:
      - name: spring-petclinic
        image: registry.cn-shenzhen.aliyuncs.com/yedward/spring-petclinic:0.0.1
        resources:
          limits:
            memory: 2Gi
            cpu: 1
        ports:
        - containerPort: 8080
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /actuator/health/liveness
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 2
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /actuator/health/readiness
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 5
          successThreshold: 2
          timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
  name: spring-petclinic-svc-0-0-1
spec:
  selector:
    app: spring-petclinic
    version: 0.0.1
  ports:
  - port: 8080
    targetPort: 8080
  type: NodePort

将yaml中的镜像地址改为实际的镜像仓库地址和项目名称。
Dockerfile

1
2
3
4
5
6
7
FROM registry.cn-shenzhen.aliyuncs.com/yedward/openjdk:8-jre-slim
# 企业实际场景中应该通过USER指定以非root用户运行
USER appuser
EXPOSE 8080
COPY target/*.jar /app/
WORKDIR /app
CMD java -jar -Xms1024m -Xmx1024m /app/spring-petclinic.jar

上传到gitlab中的spring-petclinic项目中

部署ArgoCD

单节点部署
使用官网快速部署

1
2
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

部署完后产生以下服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
NAME                                      READY   STATUS    RESTARTS   AGE
pod/argocd-application-controller-0       1/1     Running   0          5d6h
pod/argocd-dex-server-74588646d-sz9g8     1/1     Running   0          2d2h
pod/argocd-redis-5ccdd9d4fd-csthm         1/1     Running   1          5d6h
pod/argocd-repo-server-5bbb8bdf78-mxkv7   1/1     Running   0          18h
pod/argocd-server-789fb45964-82mzx        1/1     Running   0          18h


NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/argocd-dex-server       ClusterIP   10.43.180.172   <none>        5556/TCP,5557/TCP,5558/TCP   5d6h
service/argocd-metrics          ClusterIP   10.43.184.97    <none>        8082/TCP                     5d6h
service/argocd-redis            ClusterIP   10.43.4.233     <none>        6379/TCP                     5d6h
service/argocd-repo-server      ClusterIP   10.43.9.45      <none>        8081/TCP,8084/TCP            5d6h
service/argocd-server           NodePort    10.43.48.239    <none>        80:31320/TCP,443:31203/TCP   5d6h
service/argocd-server-metrics   ClusterIP   10.43.149.186   <none>        8083/TCP                     5d6h


NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/argocd-dex-server    1/1     1            1           5d6h
deployment.apps/argocd-redis         1/1     1            1           5d6h
deployment.apps/argocd-repo-server   1/1     1            1           5d6h
deployment.apps/argocd-server        1/1     1            1           5d6h

NAME                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/argocd-dex-server-74588646d     1         1         1       5d6h
replicaset.apps/argocd-redis-5ccdd9d4fd         1         1         1       5d6h
replicaset.apps/argocd-repo-server-5bbb8bdf78   1         1         1       5d6h
replicaset.apps/argocd-server-789fb45964        1         1         1       5d6h

NAME                                             READY   AGE
statefulset.apps/argocd-application-controller   1/1     5d6h

使用NodePort方式为对外暴露

1
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'

访问dashboard

默认帐号为admin，密码通过secret获取

1
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

配置ArgoCD

配置对接gitlab
setting——>Repositories->Connect repo using HTTPS

如果对应的git是私有库，pull需要帐号密码则需要在argo设置中配置repo connect

填写对应的帐号密码，如果是自签名证书需要将CA附上

创建Project
setting——>Projects
项目是argocd中的管理对象，也与之对应的发布权限相关联。
创建项目，并配置DESTINATIONS，能够发布到哪些集群和命名空间

创建Application

创建完后

点击sync会自动将yaml文件部署到k8s集群中。
可以在Kubernetes集群中查看到

1
2
3
kubectl get pod 
NAME                                      READY   STATUS    RESTARTS   AGE
spring-petclinic-0-0-1-6695b96956-xx9nw   1/1     Running   0          28m

Harbor中创建对应项目

在harbor中创建spring-petclinic项目

gitlab Webhook配置

当前Jenkins进行CI构建还是基于手动点击运行，可以配置基于gitlab的触发事件进行调用，如push、merge、tag push等事件触发回调Jenkins自动执行CI
jenkins处打开项目触发器

生成连接Secret token保存下来

Gitlab配置：
root登录后，需要开放安全配置，允许本地local网络连接
在menu选择admin——>settings-——>Network——>Outbound requests

勾选

1
2
Allow requests to the local network from web hooks and services  
Allow requests to the local network from system hooks

将Jenkins的ip添加到白名单中，保存。

项目——>setting——>webhooks

填写Jenkins对应的回调地址和token

点击Test settings即可在Jenkins处看见已经开始的构建任务。

保存配置

test这里选择基于事件回调。查看Jenkins处是否开始自动执行任务。

Jenkins配置

Argo是检查到yaml文件变化会进行自动发布到k8s中，那么我们只需要在Jenkins中增加修改和上传yaml阶段即可。

完整的构建阶段shell
编译阶段shell

1
docker run -i -v /var/jenkins_home/workspace/:/tmp  maven:3.6-jdk-8 mvn -f /tmp/spring-petclinic/pom.xml clean package -DskipTests

代码扫描阶段

1
2
3
4
5
6
7
sonar.projectKey=test
sonar.projectName=test
sonar.projectVersion=1.0
sonar.sources=src
sonar.java.binaries=target/classes
sonar.language=java
sonar.sourceEncoding=UTF-8

镜像构建阶段

1
2
3
docker login -u useradmin -p password harbor_ip
docker build -t harbor_ip/spring-petclinic/spring-petclinic:$BUILD_NUMBER .
docker push harbor_ip/spring-petclinic/spring-petclinic:$BUILD_NUMBER

注：
1、这里使用Jenkins内置BUILD_NUMBER号为镜像tag，跟Jenkins的CI号是匹配的。
2、将上传镜像的账号密码修改为实际的账号密码。

发布更新部署yaml阶段

1
2
3
4
5
6
7
8
9
git clone http://username:password@1.13.173.7/root/spring-petclinic.git
git config --global user.email "root@example.com"
git config --global user.name "root"
git remote set-url origin http://username:password@1.13.173.7/root/spring-petclinic.git
sed -i "s/spring-petclinic:.*/spring-petclinic:$BUILD_NUMBER/g" spring-petclinic/deployment.yaml
cd spring-petclinic/
git add deployment.yaml
git commit -m "update yaml"
git push origin main

在配置一个构建后删除操作，避免构建后缓存影响下次构建

执行构建，构建成功后查看对应的k8s中的部署的业务镜像版本号是否与实际应用部署的环境变量相同。

1
2
3
4
5
6
7
8
9
kubectl describe pod/spring-petclinic-0-0-1-699954b589-h7n58

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  57m   default-scheduler  Successfully assigned default/spring-petclinic-0-0-1-7969df6996-dn2cc to rke-node2
  Normal  Pulled     57m   kubelet            Container image "1.13.173.7:8080/spring-petclinic/spring-petclinic:15" already present on machine
  Normal  Created    57m   kubelet            Created container spring-petclinic
  Normal  Started    57m   kubelet            Started container spring-petclinic

访问节点ip+spring-petclinic服务暴露出来的NodePort端口

这是一个宠物医院的管理系统，可以通过此页面进行宠物管理。

备注

Jenkins内置环境变量
直接访问${YOUR_JENKINS_HOST}/env-vars.html即可

1
2
3
4
5
6
7
8
9
10
11
12
13
BUILD_NUMBER， 唯一标识一次build，例如23；
BUILD_ID，基本上等同于BUILD_NUMBER，但是是字符串，例如2011-11-15_16-06-21；
JOB_NAME， job的名字，例如JavaHelloWorld；
BUILD_TAG，作用同BUILD_ID,BUILD_NUMBER,用来全局地唯一标识一此build，例如jenkins-JavaHelloWorld-23；
EXECUTOR_NUMBER， 例如0；
NODE_NAME，slave的名字，例如MyServer01；
NODE_LABELS，slave的label，标识slave的用处，例如JavaHelloWorld MyServer01；
JAVA_HOME， java的home目录，例如C:\Program Files (x86)\Java\jdk1.7.0_01；
WORKSPACE，job的当前工作目录，例如c:\jenkins\workspace\JavaHelloWorld；
HUDSON_URL = JENKINS_URL， jenkins的url，例如http://localhost:8000/ ；
BUILD_URL，build的url 例如http://localhost:8000/job/JavaHelloWorld/23/；
JOB_URL， job的url，例如http://localhost:8000/job/JavaHelloWorld/；
SVN_REVISION，svn 的revison， 例如4；
]]> <h3 id="环境准备"><a href="#环境准备" class="headerlink" title="环境准备"></a>环境准备</h3><p>软件版本</p> <table> <thead> <tr> <th>软件</th> <th>版本</th> </tr> </ Jenkins-pipeline讲解和使用 http://yoursite.com/2021/10/14/jenkins_pipeline/ 2021-10-14T13:45:59.000Z 2021-10-14T13:45:59.000Z 什么是Jenkins-Pipeline

Pipeline是一套运行在Jenkins上的工作流框架，2.X版本Jenkins的核心功能，主要是将一个大的工作流分拆成多个独立的功能模块，实现单个任务难以完成的复杂流程编排和可视化。
Jenkins Pipeline也是实现CICD As file的一个重要工具，将Pipeline编写成Jenkinsfile与业务代码一起存放。

Pipeline支持两种语法：
1、声明式语法

Jenkins新加入的语法规则在Jenkinsfile固定的关键字之内，所采用的语法风格大多与shell类似，这种风格更加符合日常的阅读习惯，也更简单，以后我都将采用这种方式进行介绍以及深入。

2、脚本式语法
不是shell脚本形式，而是基于Groovy语言的语法风格，学习成本相对较高

建议直接使用声明式语法清晰简单明了，合适大部分人入门

Pipeline和FreeStyle对比

| | 灵活方式 | 显示形式 |
|—|—|—|—|
| FreeStyle | 图形化操作，合适入门操作，后期流程多后，不易于快速快速构建 | 只有统一日志展示，没有完整阶段流程信息展示 | |
| Pipeline | 结构化代码语法，易于阅读和管理，可以实现CICD as Code | 阶段流程信息展示清晰，每个阶段构建时间和对应的构建日志清晰可读 | |

Jenkins-Pipline语法介绍


图片来源:https://wiki.eryajf.net/pages/3298.html#_1-%E6%A1%86%E6%9E%B6%E4%BB%8B%E7%BB%8D%E3%80%82

  • Aagent: 一个 Aagent 就是一个 Jenkins执行 Step 的具体运行环境。
  • Stage: 表示Pipeline的一个阶段，如clone code阶段，Build阶段。一个Pipeline中至少需要一个Stage。
  • Step: 表示实际的执行步骤，小到执行一个 Shell 脚本，大到构建一个 Docker 镜像，由各类 Jenkins Plugin 提供，当插件扩展Pipeline DSL 时，通常意味着插件已经实现了一个新的步骤，在Stage下有且只能有一个step。

environment

环境变量，可以定义在全局变量或者步骤中的局部变量，取决于所定义位置。

1
2
3
4
5
6
7
8
9
10
11
12
13
pipeline {
   agent any
   environment {
       DISABLE_AUTH = 'true'               
   }
   stages {
       stage(“Build”) {
           steps {
               echo env.DISABLE_AUTH
           }
       }
   }
}

运行结果，会输出对应的环境变量。

options

选项，定义流水线运行时的配置选项。如历史构建记录数量保留，超时时间等操作。以下例子定义重试次数.

1
2
3
4
5
6
7
8
9
10
11
12
13
pipeline {
    agent any
    options {
        retry(3)
    }
    stages {
        stage('Example') {
            steps {
               sh "dwdwe"
            }
        }
    }
}

编写一个无法执行的命令，可以通过Console Output看见会Retrying 3次才停止。

parameters

参数，为流水线运行时设置相关的参数，不需要在UI界面上额外定义。
出现在Pipeline块内，并且只有一次。
常用参数：
string：字符串类型的参数，例如： parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
文本: 一个text参数，可以包含多行，例如： parameters { text(name: 'DEPLOY_TEXT', defaultValue: 'One\nTwo\nThree\n', description: '') }
booleanParam: 一个布尔参数，例如： parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
choice： 选择参数，例如： parameters { choice(name: 'CHOICES', choices: ['one', 'two', 'three'], description: '') }

password: 在 Jenkins 参数化构建 UI 提供一个暗文密码输入框，所有需要脱敏的信息，都可以通过这个参数来配置。
parameters { password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'A secret password') }

注意：
这种声明定义之后，需要手动构建一次，然后才会自动落位到配置好的参数化构建中了。
例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
pipeline {
    agent any
    parameters {
        string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')

        text(name: 'BIOGRAPHY', defaultValue: '', description: 'Enter some information about the person')

        booleanParam(name: 'TOGGLE', defaultValue: true, description: 'Toggle this value')

        choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')

        password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'Enter a password')
    }
    stages {
        stage('Example') {
            steps {
                echo "Hello ${params.PERSON}"

                echo "Biography: ${params.BIOGRAPHY}"

                echo "Toggle: ${params.TOGGLE}"

                echo "Choice: ${params.CHOICE}"

                echo "Password: ${params.PASSWORD}"
            }
        }
    }
}

在执行Build时会多出这些选项

post

运行后处理，当流水线完成后根据配置的条件做一些动作，如：构建失败后邮件通知。
条件：
always：无论怎么样总是执行。
changed: 当前Pipeline状态与先前不一致情况下执行。
failuer: 失败情况下。
success: 成功情况下。
unstable: 不稳定情况下，Pipeline状态标识为黄色。
aborted: Pipeline中止情况下。
cleanup: 无论怎么样，执行目录清理

例如：
无论怎么样，将执行情况邮件发送。 

1
2
3
4
5
6
7
8
post{
         always{
         mail to : ‘team@example.com’,
                   subject:”Pipeline statue:${currentBuild.fullDisplayName}”,
                   body:”The execution result${env.Build_url}”

   }
}

定义三种执行状态，此时shell命令无法执行，输出always和success输出信息。 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
               sh  'dwd'
            }
        
        }
    }
    post { 
        always { 
            echo 'already exec'
        }
        success {
            echo 'exec success '
        }
        failure {
            echo 'exec failure'
        }
    }
}

tool

构建工具，获取通过自动安装或手动安装工具的环境变量，支持maven、jdk、gradle，工具的名称必须预先在Jenkins的系统设置->全局工具配置中定义。
例如在Jenkins—>Global Tool Configuration中添加工具对应的环境变量，然后在项目中引用。 

1
2
3
4
5
6
7
8
9
10
11
12
13
pipeline {
    agent any
    tools {
        maven 'maven' 
    }
    stages {
        stage('Example') {
            steps {
                sh 'mvn --version'
            }
        }
    }
}

input

交互输入，在流水线执行各个阶段的时候，由人工确认是否继续执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
pipeline{
    agent any
    environment{
    approvalMap = ''
    }
    stages {
        stage('pre deploy'){
            steps{
                script{
                    approvalMap = input (
                        message: '发布到哪个环境？',
                        ok: '确定',
                        parameters:[
                            choice(name: 'ENV',choices: 'test\npre\nprod',description: '发布到什么环境？'),
                            string(name: 'username',defaultValue: '',description: '输入用户名')
                        ],
                        submitter: 'admin',
                    )
                }
            }
        }
        stage('deploy'){
            steps{
                echo "操作者是 ${approvalMap['username']}"
                echo "发布到什么环境 ${approvalMap['ENV']}"
            }
        }
    }
}

点击构建，程序将会在input的步骤停住，等待用户进行相应输入和选择。
message ：必填。页面展示信息

ok：input表单上“ok”按钮的可选文本。

submitter：允许提交此input选项的用户或外部组名列表，用逗号分隔。默认允许任何用户。

例子结果如图所示：

when

条件判断，允许流水线根据给定的条件决定是否应该执行阶段，when 指令必须包含至少一个条件.
内置条件
branch：分支匹配，如when { branch 'release-v2.5' }
environment：环境变量匹配如when { environment name: 'DEPLOY_TO', value: 'production' }

not：当嵌套条件为false时执行stage。必须包含至少一个条件例如：when { not { branch 'master' } }
allOf：当所有嵌套条件都为真时，执行舞台。必须包含至少一个条件。例如：when { allOf { branch 'master'; environment name: 'DEPLOY_TO', value: 'production' } }
anyOf: 当至少一个嵌套条件为真时执行。必须至少包含一个条件。例如：when { anyOf { branch 'master'; branch 'staging' } }

以上例子支持通配符配置，如when { branch 'release-v2.*' }
例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
               git branch: 'main', url: 'https://gitee.com/wanshaoyuan/spring-petclinic.git'
            }
        }
        stage('deploy to proc'){
           when {
             branch 'main'
           }
            steps{
              echo "deploy to proc env"
            }
            
        }
    }
    
}

执行后因为是clone main分支，将输出deploy to proc env。

parallel

默认Pipeline是串行，可以通过parallel配置并行构建，阶段可以在他们内部声明多嵌套阶段, 它们将并行执行，一个阶段只能有一个 steps 或 parallel的阶段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
pipeline {
    agent any

    stages {
        stage('one') {
            steps {
               echo "stage1"
            }
        }
        stage('two') {
            failFast true
            parallel {
                stage('并行1') {
                  steps {
                    echo "并行一"
                  }
            }
                stage('并行2') {
                  steps {
                    echo "并行二"
            }
        }
    }
  }
 }
}

注:添加failFast true到包含parallel的stage中，其中一个失败时中止所有parallel内的stage。
本阶段会执行多个步骤。
通过BlueOcean查看Pipeline效果图

script

脚本标签，需要执行一些系统命令语法。

1
2
3
4
5
6
7
8
9
10
pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
               sh 'date'
            }
        }
    }
}

通过sh执行对应的shell命令。

trigger

触发器，设置构建触发器，比如根据周期计划定时构建。
cron定时构建
根Linux内crontab对应的，分、时、日、月、周。这里例子定义每分钟执行一次。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
pipeline {
    agent any
    triggers{
      cron('* * * * 1')
    }
   
    stages {
        stage('cat文件'){
            steps{
                sh '''cat README.md'''

            }
        }
     }
  }

注意点：
H关键字为Hash，表示当前设置的时间跨度范围内随机一值例如
triggers{ cron('H/15 * * * *') }
每15分钟执行一次，可能在 :07,:22,:37,:52执行

withCredentials

将secret与变量对应起来。在jenkins中创建的密钥，在Pipeline中希望通过变量方式引用，可以通过withCredentials进行。

例子
在全局凭据中创建个Username with password的凭证，输入用户名和密码

1
2
3
4
5
6
7
8
9
10
11
12
pipeline {
    agent any
    stages {
        stage('部署到测试环境'){
            steps{
                 withCredentials([usernamePassword(credentialsId: 'harbor_account', passwordVariable: 'password', usernameVariable: 'username')]) {
                 sh 'echo $username'
               }
            }
        }
     }
  }

执行构建后会输出密钥中的用户名
注：
usernamePassword：withCredentials的类型，相应的还支持sshUserPrivateKey(ssh key)和certificate（证书）。
credentialsId：Jenkins中对应的配置名称。
passwordVariable： 密码项目转成对应的变量。
usernameVariable： 用户名项转换成对应的变量。

SSH User Private Key 示例

1
2
3
4
5
6
withCredentials(bindings: [sshUserPrivateKey(credentialsId: 'jenkins-ssh-key-for-abc', \
                                             keyFileVariable: 'SSH_KEY_FOR_ABC', \
                                             passphraseVariable: '', \
                                             usernameVariable: '')]) {
  // some block
}

Certificate 示例

1
2
3
4
5
6
withCredentials(bindings: [certificate(aliasVariable: '', \
                                       credentialsId: 'jenkins-certificate-for-xyz', \
                                       keystoreVariable: 'CERTIFICATE_FOR_XYZ', \
                                       passwordVariable: 'XYZ-CERTIFICATE-PASSWORD')]) {
  // some block
}

参考： https://www.jenkins.io/zh/doc/book/pipeline/jenkinsfile/#usernames-and-passwords

BlueOcean使用

Jenkins针对pipeline提供了全新的Blue Ocean界面，可以清晰的查看流水线的执行情况：

安装blueocean插件

安装完以后在对应的项目处会多出一个打开Blue Ocean按钮，

界面美化后的扁平化风格，可以通过此界面，进行一些常规的配置和操作

阶段性Pipeline重跑

日志统一下载

Jenkinsfile

目前主流大部分CI工具都支持Pipeline as Code，就是将整CI流程通过代码方式实现，然后将对应的代码和业务代码放置在一起，对应的CI工具在拉取业务代码后可以直接解析CI的流程代码进行执行。Jenkins也是支持这种方式的，通过将写好的Pipeline写在Jenkinsfile中存放在代码仓库中，Jenkins配置读取指定目录的Jenkinsfile文件即可。

实例Demo最佳实践

完整CICD步骤

1、clone 源码。
2、编译源码。
3、编译后进行代码扫描和编译后可执行文件扫描。
4、将编译后生成的制品上传到制品库。
5、镜像构建，将构建后的镜像上传到Harbor。
6、更新Gitlab中的部署文件。
7、触发ArgoCD同步。手动或自动部署到Kubernetes环境中。

Jenkins创建连接账号

因为要进行镜像上传和修改gitlab中的部署yaml，需要进行修改。
系统管理——>Manage Credentials——>创建全局域的认证信息

添加凭据

类型为Username with password

创建id为harbor_account和gitlab_account的凭证用于Pipeline连接。

代码库配置连接SonarQube信息

使用Pipeline流水线，需要在添加以下步骤

1、在对应的代码库的根目录创建sonar-project.properties文件

1
2
3
4
5
6
7
8
9
sonar.projectKey=test2
sonar.projectName=test2
sonar.projectVersion=1.0
sonar.sources=src
sonar.java.binaries=target/classes
sonar.java.source=1.8
sonar.java.target=1.8
sonar.language=java
sonar.sourceEncoding=UTF-8

Pipeline中添加以下步骤

1
2
3
4
5
6
7
8
9
10
stage('SonarQube analysis') {
      steps {
        script {
        def sonarqubeScannerHome = tool name: 'SonarQubeScanner'
            withSonarQubeEnv('sonar') {
            sh "${sonarqubeScannerHome}/bin/sonar-scanner"
         }
        }
      }
    }

注：
1、SonarQubeScanner为全局工具配置中的SonarQube Scanner的配置名称。
2、withSonarQubeEnv配置的sonar变量为全局——>系统配置sonar-server的配置名称

Pipeline创建

创建个名称为spring-petclini的Pipeline
配置构建触发器

贴入以下Pipeline 代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
pipeline {
  agent {
    kubernetes {
      cloud 'kubernetes'
      namespace 'default'
      yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: git
      image: alpine/git:v2.26.2
      command:
        - cat
      tty: true
    - name: maven
      image: maven:3.6.3-openjdk-8
      command:
        - cat
      tty: true
      volumeMounts:
        - mountPath: /root/.m2/repository
          name: jenkins-maven-m2-pvc
    - name: docker
      image: docker:19.03-dind
      command:
        - cat
      tty: true
      volumeMounts:
        - mountPath: /var/run/docker.sock
          name: docker-sock
    - name: helm-kubectl
      image: registry.cn-shenzhen.aliyuncs.com/yedward/helm-kubectl:3.3.1-1.18.8
      command:
        - cat
      tty: true
  volumes:
    - name: jenkins-maven-m2-pvc
      persistentVolumeClaim:
        claimName: jenkins-maven-m2-pvc
    - name: docker-sock
      hostPath:
        path: /var/run/docker.sock
        type: ""
"""
    }
  }
  
  stages {
    stage('Clone') {
      steps {
        container('git') {
          git branch: 'main', credentialsId: 'gitlab', url: 'http://172.16.1.184/root/spring-petclinic.git'        }
      }
    }
    stage('Build') {
      steps {
        container('maven') {
          sh 'mvn clean package -DskipTests'
        }
      }
    }
    stage('SonarQube analysis') {
      steps {
        script {
        def sonarqubeScannerHome = tool name: 'SonarQubeScanner'
            withSonarQubeEnv('sonar') {
            sh "${sonarqubeScannerHome}/bin/sonar-scanner"
         }
        }
      }
    }
    stage('Publish') {
      steps {
        container('docker') {
            withCredentials([usernamePassword(credentialsId: 'harbor_account', passwordVariable: 'USERPWD', usernameVariable: 'USERNAME')]) {
                sh 'echo "$USERPWD" | docker login --username="$USERNAME" 172.16.1.31 --password-stdin'
                sh 'docker build -t 172.16.1.31/spring-petclinic/spring-petclinic:$BUILD_NUMBER .'
                sh 'docker push 172.16.1.31/spring-petclinic/spring-petclinic:$BUILD_NUMBER'
            }
        }
      }
    }
    stage('Deploy') {
      steps {
        container('git') {
            withCredentials([usernamePassword(credentialsId: 'gitlab_account', passwordVariable: 'USERPWD', usernameVariable: 'USERNAME')]) {
                sh 'git config --global user.email "root@example.com"'
                sh 'git config --global user.name "root"'
                sh 'git remote set-url origin http://$USERNAME:$USERPWD@172.16.1.184/root/spring-petclinic.git'
                sh 'sed -i "s/spring-petclinic:.*/spring-petclinic:$BUILD_NUMBER/g" deployment.yaml'
                sh 'git add deployment.yaml'
                sh 'git commit -m "update yaml"'
                sh 'git push origin main'
            }
        }
      }
    }
  }
}

注意点：
1、clone阶段如果是私有代码仓库，需要配置凭证，可以通过流水线语法生成对应的执行命令。

输入对应的git地址和分支，选择gitlab密钥，生成对应的执行代码

执行
修改spring-petclinic项目的代码注释掉主页的图片，提交代码，触发自动CICD查看效果。

注释掉首页小狗图片
spring-petclinic/src/main/resources/templates/welcome.html

1
<!--<img class="img-responsive" src="../static/resources/images/pets.png" th:src="@{/resources/images/pets.png}"/>-->

重新提交代码

查看已经没有对应logo

参考链接：
https://www.jenkins.io/doc/book/pipeline/syntax/
https://wiki.eryajf.net/pages/3298.html

]]> <h3 id="什么是Jenkins-Pipeline"><a href="#什么是Jenkins-Pipeline" class="headerlink" title="什么是Jenkins-Pipeline"></a>什么是Jenkins-Pipeline</h3><p>Pi 应用性能监控1-Skywalking http://yoursite.com/2021/08/26/apm_1/ 2021-08-26T13:45:59.000Z 2021-08-26T13:45:59.000Z 概述

随着应用功能越来越多，从单体架构发展到现在微服务架构，拆分的模块越来越细粒化，需要定位应用模块之间的问题困难越来越大，需要通过一些第三方工具去帮助我们快速定位和发现应用模块的问题，实现以下功能：
1、监控模块间响应时间展示
2、应用模块间调用链路展示
3、慢响应识别
市面上也有非常多的APM软件提供。主流开源的如SkyWalking、ZipKin、CAT、PinPoint、ElasticAPM。这些都是根开发语言有强绑定关系，并且需要业务加载对应的开发包和引入SDK，对业务具有一定的侵入性。目前还有新兴的解决方案，基于云原生ServiceMesh方式，对应用没有侵入性和开发语言绑定。

SkyWalking介绍

基于Google分布式链路追踪论文Dapper开发，由中国工程师吴晟开发并开源贡献给Apache基金会，支持多种开发语言如Java、PHP、Go、C++、Node.js、Python、.NET、Lua……

SkyWalking组件介绍

总体架构如下

SkyWalking架构总体分为四部分：

Agent：探针负责与各类开发语言和平台集成如ServiceMesh，进行Tracing和Metric数据收集。发送给Server端。
Server端（OAP)：接受Agent采集发送过来的数据，进行数据分析、处理、聚合、查询以及将数据发送到后端存储。
Storage：支持多种后端存储（ElasticSearch、Mysql、Tidb…)，接收Server端发送过来的数据。
UI: 进行数据计算后的结果统一展示和调用链路展示。

SkyWalking安装

环境信息

软件版本
Kubernetesv1.18.20
SkyWalkingv8.1.0

SkyWalking官方支持多种安装方式，这里为了快速部署，使用的是在Kubernetes上用Helm安装，后端存储使用ElasticSearch。
使用官方Helm安装方式最小化安装，后端存储使用ElasticSearch。 参考部署手册
https://github.com/apache/skywalking-kubernetes
环境

配置环境变量

1
2
export SKYWALKING_RELEASE_NAME=skywalking
export SKYWALKING_RELEASE_NAMESPACE=default

配置repo

1
2
3
export REPO=skywalking
helm repo add ${REPO} https://apache.jfrog.io/artifactory/skywalking-helm  
helm repo update

安装skywalking，这里安装会自动帮你部署一个ElasticSearch，如果需要对接已经存在的ElasticSearch集群或使用其他的后端存储，可以使用其他参数进行部署安装。 

1
2
3
4
5
helm install "${SKYWALKING_RELEASE_NAME}" ${REPO}/skywalking -n "${SKYWALKING_RELEASE_NAMESPACE}" \
  --set oap.image.tag=8.1.0-es7 \
  --set oap.storageType=elasticsearch7 \
  --set ui.image.tag=8.1.0 \
  --set elasticsearch.imageTag=7.5.1

部署完后查看

1
2
3
4
5
6
7
8
9
kubectl get pod 
NAME                              READY   STATUS      RESTARTS   AGE
elasticsearch-master-0            1/1     Running     0          8m54s
elasticsearch-master-1            1/1     Running     0          8m54s
elasticsearch-master-2            1/1     Running     0          8m54s
skywalking-es-init-vl8c7          0/1     Completed   0          8m54s
skywalking-oap-64df9d4b8c-dvksd   1/1     Running     0          3m50s
skywalking-oap-64df9d4b8c-p6thl   1/1     Running     0          8m54s
skywalking-ui-649dc77bd7-t9d7m    1/1     Running     0          8m54s

部署了一个ElasticSearch集群和skywalking对应的组件

为了方便访问，我们将Skywalking的UI通过NodePort对外暴露出来。 

1
kubectl patch  svc skywalking-ui  --type='json' -p '[{"op":"replace","path":"/spec/type","value":"NodePort"},{"op":"add","path":"/spec/ports/0/nodePort","value":30930}]'

访问http://节点ip:30930，此时默认UI界面如下：

与应用集成方式

方式一：应用启动加载agent依赖包。
比如通过http://skywalking.apache.org/downloads/下载对应发行版本tar包里面包含的agent文件，然后应用启动命令加载此agent依赖文件即可。如以下通过容器应用构建Dockerfile方式加载。 

1
2
3
4
5
6
FROM registry.cn-shenzhen.aliyuncs.com/yedward/openjdk:8-jre-slim
USER appuser
EXPOSE 8080
COPY --from=build /usr/src/app/target/*.jar /app/
WORKDIR /app
CMD java -jar -Xms1024m -Xmx1024m /app/spring-petclinic.jar -javaagent:/opt/skywalking/agent/skywalking-agent.jar

方式二：通过外部挂载和参数引用方式。下面Demo主要就是对这种方式的演示。

这两种方式最大的区别在于，方式一需要改动应用启动命令，方式二对应用本身不需要进行改动，就需要进行升级即可。

应用Demo演示

以spring-petclinic为Demo进行演示，一个简单的应用，前面有一个Gateway做为统一流量入口，通过Web模块将对应的服务请求转发到后端不同的其他服务上，进行服务调用。

https://github.com/wanshaoyuan/spring-petclinic-msa.git

部署Demo应用

1
2
3
4
5
6
下载
git clone https://github.com/wanshaoyuan/spring-petclinic-msa.git

部署yaml

kubectl apply -f k8s/local-skywalking/

访问服务

http://host_ip:31080

一个宠物医院系统，可以点击进行一些资料的添加和修改。

查看Skywalking的数据，点击右上角自动的按钮进行自动的刷新

调用Top耗时显示和响应耗时范围展示

服务响应时间和调用成功率

全局调用链路展示

调用关系和路径耗时展示

总结：
Skywalking UI做的非常精美，做为一款开源产品功能覆盖还是非常全面的，APM系统对于目前微服务体系的应用进行故障排查还是有非常大的帮助。但这种非常对开发语言还是有一定依赖性，另外一种不需要开发语言依赖的方式就是ServiceMesh的实现
完全不侵入应用，也不需要加载Jar包，ServiceMesh主要是通过做应用透明代理和流量劫持去实现链路追踪，如Istio，但他的缺点是只能追踪HTTP请求，覆盖范围有限，并且相对追踪的数据也比埋点的要少一些。

]]> <h2 id="概述"><a href="#概述" class="headerlink" title="概述"></a>概述</h2><p>随着应用功能越来越多，从单体架构发展到现在微服务架构，拆分的模块越来越细粒化，需要定位应用模块之间的问题困难越来越大，需要通过一些第三方工具