当使用 qemu-guest-agent 获取 ip 时遇到了问题，本文记录排查和代码修复过程。

• 我提的 issue：https://github.com/dmacvicar/terraform-provider-libvirt/issues/1091#event-16519515888
• 我提的 pull request 已经合并：https://github.com/dmacvicar/terraform-provider-libvirt/pull/1144
• 在 release v0.8.2 中已经发布：https://github.com/dmacvicar/terraform-provider-libvirt/discussions/1162

debug​

经过分析，了关键的区别如下：

1. 在 0.7.1 版本中，domainGetIfacesInfo  函数对错误处理有特殊的逻辑：

switch virErr := err.(type) {
case libvirt.Error:
    // Agent can be unresponsive if being installed/setup
    if addrsrc == uint32(libvirt.DomainInterfaceAddressesSrcLease) && virErr.Code != uint32(libvirt.ErrOperationInvalid) ||
        addrsrc == uint32(libvirt.DomainInterfaceAddressesSrcAgent) && virErr.Code != uint32(libvirt.ErrAgentUnresponsive) {
        return interfaces, fmt.Errorf("Error retrieving interface addresses: %w", err)
    }
}

2. 而在最新版本中，错误处理变得更简单：

if err != nil {
    return interfaces, fmt.Errorf("error retrieving interface addresses: %w", err)
}

这就是导致问题的关键：

1. 在 0.7.1 版本中，如果使用 qemu-agent 获取 IP 地址时遇到  ErrAgentUnresponsive  错误，代码会忽略这个错误并继续尝试，这给了 qemu-agent 启动和响应的时间。

2. 在新版本中，任何错误都会直接返回，包括  ErrAgentUnresponsive，这导致在 qemu-agent 还没有完全启动和响应时就失败了。

解决方案有 2 个：

1. 修改 provider 代码，恢复 0.7.1 版本的错误处理逻辑，提交 PR 到上游。修改内容大致如下：

func domainGetIfacesInfo(virConn *libvirt.Libvirt, domain libvirt.Domain, rd *schema.ResourceData) ([]libvirt.DomainInterface, error) {
    //...省略
    // 这里开始修改
	// get all the interfaces attached to libvirt networks
	var interfaces []libvirt.DomainInterface
	interfaces, err = virConn.DomainInterfaceAddresses(domain, addrsrc, 0)
	if err != nil {
		switch virErr := err.(type) {
		case libvirt.Error:
			// Agent can be unresponsive if being installed/setup
			if addrsrc == uint32(libvirt.DomainInterfaceAddressesSrcLease) && virErr.Code != uint32(libvirt.ErrOperationInvalid) ||
				addrsrc == uint32(libvirt.DomainInterfaceAddressesSrcAgent) && virErr.Code != uint32(libvirt.ErrAgentUnresponsive) {
				return interfaces, fmt.Errorf("error retrieving interface addresses: %w", err)
			}
			// 如果是 ErrAgentUnresponsive，继续尝试
			return interfaces, nil
		default:
			return interfaces, fmt.Errorf("error retrieving interface addresses: %w", virErr)
		}
	}
	return interfaces, nil
}

terraform 本地插件​

由于上游合并需要时间，在此间我是用本地插件机制来使用我编译后的插件，如下放入指定位置然后引用既可。

  required_providers {
    libvirt = {
      source  = "local/providers/libvirt"
      version = "1.0.0"
    }
```

```bash
~/.terraform.d/plugins/local/providers/libvirt/1.0.0/linux_amd64/

~/.terraform.d/plugins/
└── local
    └── providers
        └── libvirt
            └── 1.0.0
                └── linux_amd64
                    └── terraform-provider-libvirt

当然我尝试过 pulumi ，结果发现 pulumi 是对 tf 进行了一层包装本质还是使用的 terraform libvirt 插件，所以有同样的问题。

依照本文操作你将完成如下内容：

• Nvidia 和 CUDA 驱动安装
• Nvidia Container Runtime 的配置
• Kubernetes 通过 GPU plugin 实现 GPU 调度支持
• Kubernetes 开启共享 Nvidia GPU 资源配置

前言​

Kubernetes 已经成为云原生应用编排和管理的事实标准。在 v1.26 版本 Scheduling GPUs 进入 stable 状态，通过 device plugins 可以让 Pods 可以访问特定硬件如 GPUs。

越来越多的机器学习（ML）和人工智能（AI）领域的开发者希望利用 Kubernetes 平台的优势，来管理 GPU 调度任务。

相比本地 GPU 管理方案，Kubernetes 通过对 GPU 资源的高效分时复用和动态调度，从而降本增效。声明式的容器化配置，使部署过程可以固化和复用，避免了重复配置机器学习环境。同时容器隔离可以避单一进程占用过多共享资源，保障系统稳定性。

尽管本文以 Arch Linux 作为基本环境，但同样适用于其他发行版。

Nvidia 驱动安装​

安装方式​

NVIDIA 驱动程序提供三种格式：

• runfile 安装程序
  • NVIDIA Driver Downloads
  • Unix Driver Archive
• 包管理器
• 容器化驱动程序

推荐使用包管理器安装驱动，方便以后的维护和升级。

安装示例​

以下是在 Arch Linux 上安装 Nvidia 驱动的示例：

Arch Linux Wiki for NVIDIAN 介绍了 Arch Linux 官方提供的 Nvidia 驱动包和内核的对应关系，如下所示：

• nvidia 软件包（用于 linux内核 ）
• nvidia-lts 软件包（用于 linux-lts内核 ）
• nvidia-dkms 软件包（用于所有其他内核）。

下面以我的 Arch Linux 环境为例，我日常使用的内核为 linux ，同时也安装了 linux-lts 内核作为备用，我想要 Nvidia 驱动在这俩内核中都正常工作，所以需要安装 nvidia 和 nvidia-lts 命令如下：

# 查看显卡
lspci | grep -i nvidia | grep VGA
# 构建工具
sudo pacman -S --needed base-devel
# nvidia 驱动
sudo pacman -S nvidia nvidia-lts

其他发行版请参考安装方式中提到的 NVIDIA 驱动程序提供三种格式 进行安装。

驱动验证​

完成驱动安装好执行 nvidia-smi 验证是否可用

❯ nvidia-smi
Wed Aug 16 17:04:35 2023       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.98                 Driver Version: 535.98       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 3080 ...    Off | 00000000:01:00.0 Off |                  N/A |
| N/A   50C    P8              11W / 115W |      8MiB / 16384MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A      1067      G   /usr/bin/gnome-shell                          3MiB |
+---------------------------------------------------------------------------------------+
❯ nvidia-smi --query-gpu=gpu_name --format=csv,noheader
NVIDIA GeForce RTX 3080 Ti Laptop GPU
❯ nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 3080 Ti Laptop GPU (UUID: GPU-1b17e588-c712-9244-37de-93a8a77ebe6d)

CUDA 驱动安装​

CUDA（Compute Unified Device Architecture）是 NVIDIA 推出的通用并行计算架构，该架构使 GPU 能够解决复杂的计算问题。

安装方式​

CUDA 提供了两种安装方式，你可以使用两种不同的安装机制之一来安装 CUDA 工具包：

• 通过包管理器安装
• 通过 runfile 安装
• runfile download

安装示例​

以下是在 Arch Linux 上安装 CUDA 驱动的示例：

paru -S cuda

根据安装后操作配置环境变量。

Arch Linux 环境会将 CUDA 相关文件安装至 /opt/cuda，将 CUDA 的 PATH 加到 rc 中(如~/.bashrc,~/.zshrc)，此路径引永远指向最新版的 CUDA。

echo 'export CUDA_PATH=/opt/cuda
export PATH=$PATH:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin'| sudo tee /etc/profile.d/cuda.sh
source /etc/profile

驱动验证​

输入以下命令来检查 CUDA 版本：

❯  nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Tue_Jun_13_19:16:58_PDT_2023
Cuda compilation tools, release 12.2, V12.2.91
Build cuda_12.2.r12.2/compiler.32965470_0

Container Runtime​

这里选符合 oci 标准的运行时，本文选用 contianerd。

Containerd 安装​

驱动加载

# 写入持久化配置
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
# 重载配置使其生效
sudo systemctl restart systemd-modules-load.service
# 或者手动加载
sudo modprobe overlay 
sudo modprobe br_netfilte

安装软件包

paru -S containerd
sudo systemctl enable --now containerd 

Containerd 验证​

执行如下命令，进行验证

sudo ctr image pull docker.io/library/hello-world:latest 
sudo ctr run --rm -t docker.io/library/hello-world:latest hello-world

Nvidia-Container-Runtime 安装​

Containerd 默认使用 runc 不支持 GPU 设备，nvidia-container-runtime 是 runc 的修补版本，它添加了自定义 pre-start hook 从而在容器内启用 GPU 支持。

安装 NVIDIA Container Toolkit 会在 Containerd（或任何其他运行时）周围提供一个shim，用于处理 GPU 请求。需要 GPU 的容器创建由 nvidia-container-runtime 处理。

当检测到 NVIDIA_VISIBLE_DEVICES 环境变量时，会调用 libnvidia-container 库将 GPU Device 和 CUDA Driver 附加到容器，配置 GPU 访问权限后，NVIDIA 系统会调用常规容器运行时来继续其余的启动过程。如果没有检测到 NVIDIA_VISIBLE_DEVICES 则会执行默认的 runc。

以 NVIDIA 的 GPU 设备为例，运行 GPU 容器后容器内将会出现 GPU 设备和驱动目录：

• GPU 设备，比如 /dev/nvidia0；
• GPU 驱动目录，比如 /usr/local/nvidia/*。

下面开始安装 NVIDIA 容器运行时

使用以下命令将完整的 NVIDIA Container Toolkit 添加到系统中：

NVIDIA 容器运行时依赖于容器映像中现有的 CUDA 库。其他图像仍然可以工作，但它们看不到 GPU 硬件。

paru -S nvidia-container-runtime nvidia-container-toolkit

配置 Containerd 使用 Nvidia-Container-Runtime​

我们需要在启动 kubelet 之前将 Containerd 默认运行时从 runc 更改为 nvidia-container-runtime 。

生成默认配置文件

sudo mkdir /etc/containerd
sudo sh -c "containerd config default >  /etc/containerd/config.toml"

添加 nvidia 容器运行时，并设为默认

version = 2
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    [plugins."io.containerd.grpc.v1.cri".containerd]
      default_runtime_name = "nvidia"

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
          privileged_without_host_devices = false
          runtime_engine = ""
          runtime_root = ""
          runtime_type = "io.containerd.runc.v2"
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
            BinaryName = "/usr/bin/nvidia-container-runtime"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

添加完成后重启 containerd 服务

sudo systemctl restart containerd

Nvidia-Container-Runtime 验证​

sudo ctr images pull docker.io/nvidia/cuda:12.2.0-devel-ubuntu20.04
sudo ctr run --rm -t --gpus 0 docker.io/nvidia/cuda:12.2.0-devel-ubuntu20.04 nvidia-smi nvidia-smi
Thu Aug 24 06:43:06 2023       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.98                 Driver Version: 535.98       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 3080 ...    Off | 00000000:01:00.0 Off |                  N/A |
| N/A   45C    P0              29W / 115W |     10MiB / 16384MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
+---------------------------------------------------------------------------------------+

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: nvidia
handler: nvidia

在 Kubernetes 中启用 GPU 支持​

Kubernetes 通过设备插件（Device Plugins） 以允许 Pod 访问类似 GPU 这类特殊的硬件功能特性。不同厂商提供了不同的 Device Plugin，本小节部署 NVIDIA/k8s-device-plugin

来做基本演示。

kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.0/nvidia-device-plugin.yml
# 查看日志
kubectl -n kube-system logs -f $(kubectl -n kube-system get pods  -l name=nvidia-device-plugin-ds  -o jsonpath="{.items[*].metadata.name}")

I0822 07:26:02.687308       1 main.go:256] Retreiving plugins.
I0822 07:26:02.687912       1 factory.go:107] Detected NVML platform: found NVML library
I0822 07:26:02.687946       1 factory.go:107] Detected non-Tegra platform: /sys/devices/soc0/family file not found
I0822 07:26:02.698806       1 server.go:165] Starting GRPC server for 'nvidia.com/gpu'
I0822 07:26:02.699008       1 server.go:117] Starting to serve 'nvidia.com/gpu' on /var/lib/kubelet/device-plugins/nvidia-gpu.sock
I0822 07:26:02.700674       1 server.go:125] Registered device plugin for 'nvidia.com/gpu' with Kubelet

运行 GPU 作业进行验收​

部署 nvidia-device-plugin 后，容器现在可以使用 NVIDIA GPU nvidia.com/gpu 类型的 Extended Resource 。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  restartPolicy: Never
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1 # requesting 1 GPU
  tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule
EOF

查看日志结果

$ kubectl logs gpu-pod
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done

到此已依照英伟达官方 device plugin 实现了 Kubernetes 集群对 gpu 的支持。

现在每个容器可以请求一个或者多个 GPU，但多容器无法共享一块 GPU ，因为 limit 只能是整数来指定单卡数量，无法请求 GPU 的一小部分，结果是单个容器占用了整个 GPU，导致推理阶段 GPU 利用率极低。

下面我们来看看如何让更多容器可以共享 GPU 来提高利用率。

GPU 共享的可能性​

硬件方案：vGPU 技术可以将显卡资源虚拟化成多块小显卡，会有部分性能损耗。通常需要特定的硬件支持，例如 NVIDIA GRID 卡或 AMD MxGPU 卡，并且需要购买额外的GPU许可证，会增加成本和管理负担。

软件方案：工作负载的调度是在软件层面完成，虽然可以利用整块 GPU 的算力，但无法对工作负载的显存进行限制，这意味着我们需要在代码中进行限制。例如 TensorFlow 允许按照此处的指令限制 GPU 功率。

在机器学习的背景下，训练期间可能会在一项训练作业中利用完整的 GPU 容量，但在推理期间很可能希望在可用的 GPU 上分布多个实例。

下面，我们利用软件层的 GPU 共享，将个工作负载扩展到单个 GPU 上。

安装 GPU sharing extension​

我们将安装 阿里 GPU 共享调度扩展和阿里 GPU 共享设备插件。官方文档可见 安装指南。

1. 在控制平面部署GPU共享调度扩展器​

kubectl create -f https://raw.githubusercontent.com/AliyunContainerService/gpushare-scheduler-extender/master/config/gpushare-schd-extender.yaml

2.修改 kube-scheduler 配置(Kubernetes v1.23+)​

添加 lable

kubectl label node archlinux gpushare=true
kubectl label node archlinux node-role.kubernetes.io/master=

配置 kube-scheduler

cd /etc/kubernetes
sudo curl -O https://raw.githubusercontent.com/AliyunContainerService/gpushare-scheduler-extender/master/config/scheduler-policy-config.yaml

编辑 kube-scheduler.yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-scheduler
    tier: control-plane
  name: kube-scheduler
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=true
    - --config=/etc/kubernetes/scheduler-policy-config.yaml
    image: registry.k8s.io/kube-scheduler:v1.28.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-scheduler
    resources:
      requests:
        cpu: 100m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/kubernetes/scheduler-policy-config.yaml
      name: scheduler-policy-config
      readOnly: true      

    - mountPath: /etc/kubernetes/scheduler.conf
      name: kubeconfig
      readOnly: true
  hostNetwork: true
  priority: 2000001000
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/kubernetes/scheduler-policy-config.yaml
      type: FileOrCreate
    name: scheduler-policy-config
  - hostPath:
      path: /etc/kubernetes/scheduler.conf
      type: FileOrCreate
    name: kubeconfig
status: {}

❯ kubectl -n kube-system logs kube-scheduler-archlinux
I0911 07:15:36.217495       1 serving.go:348] Generated self-signed cert in-memory
E0911 07:15:36.217622       1 run.go:74] "command failed" err="no kind \"KubeSchedulerConfiguration\" is registered for version \"kubescheduler.config.k8s.io/v1beta2\" in scheme \"pkg/scheduler/apis/config/scheme/scheme.go:30\"

sudo vim  scheduler-policy-config.yaml
  apiVersion: kubescheduler.config.k8s.io/v1

systemctl restart kubelet.service

3. 部署设备插件​

kubectl create -f https://raw.githubusercontent.com/AliyunContainerService/gpushare-device-plugin/master/device-plugin-rbac.yaml
kubectl create -f https://raw.githubusercontent.com/AliyunContainerService/gpushare-device-plugin/master/device-plugin-ds.yaml

4.为需要GPU共享的节点添加gpushare节点标签​

kubectl label node archlinux gpushare=true

5.安装Kubectl扩展​

cd /usr/bin/
wget https://github.com/AliyunContainerService/gpushare-device-plugin/releases/download/v0.3.0/kubectl-inspect-gpushare
chmod u+x /usr/bin/kubectl-inspect-gpushare

当然你也可以使用 krew 来安装

device plugin 将公开 GPU 内存容量并跟踪 GPU 内存分配：

❯ kubectl describe nodes archlinux|grep Capacity -A 20
Capacity:
  aliyun.com/gpu-count:  1
  aliyun.com/gpu-mem:    16
  cpu:                   20
  ephemeral-storage:     1907216Mi
  hugepages-1Gi:         0
  hugepages-2Mi:         0
  memory:                32518820Ki
  nvidia.com/gpu:        0
  pods:                  110
Allocatable:
  aliyun.com/gpu-count:  1
  aliyun.com/gpu-mem:    16
  cpu:                   20
  ephemeral-storage:     1799874828995
  hugepages-1Gi:         0
  hugepages-2Mi:         0
  memory:                32416420Ki
  nvidia.com/gpu:        0
  pods:                  110
System Info:

您可以通过运行 kubectl inspect gpushare 来验证 kubectl gpushare 客户端： 目前，集群上没有运行启用 GPU 的工作负载，因此 GPU 内存的分配为 0%。

❯ sudo chmod +x /usr/bin/kubectl-inspect-gpushare

❯ sudo ls -l  /usr/bin/kubectl-inspect-gpushare

-rwxr-xr-x 1 root root 37310113 2021年12月 7日 /usr/bin/kubectl-inspect-gpushare
❯ kubectl inspect gpushare
NAME       IPADDRESS      GPU0(Allocated/Total)  GPU Memory(GiB)
archlinux  192.168.8.100  0/16                   0/16
------------------------------------------------------
Allocated/Total GPU Memory In Cluster:
0/16 (0%)  
 /usr/bin 

共享 GPU 冒烟测试​

让我们看看如何为特定工作负载请求 GPU 内存：

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: gpu-share-pod1
spec:
  restartPolicy: OnFailure
  containers:
    - name: gpu-share-pod1
      image: "docker.io/cheyang/gpu-player:v2"
      env:
        - name: NVIDIA_VISIBLE_DEVICES
          value: "all"
      resources:
        limits:
         aliyun.com/gpu-mem: 3
EOF

在检查 GPU 共享指标时，我们可以看到 Pod 已“虚拟”分配了 3 GB 的 VRAM。

kubectl inspect gpushare
❯ kubectl inspect gpushare
NAME       IPADDRESS      GPU0(Allocated/Total)  GPU Memory(GiB)
archlinux  192.168.8.100  3/16                   3/16
------------------------------------------------------
Allocated/Total GPU Memory In Cluster:
3/16 (18%)  

当我们验证 pod 本身的日志时，我们可以看到 TensorFlow 成功找到了 GPU 设备：

我们可以启动另一个工作负载，以确保不同的 pod 可以到达相同的底层 GPU：

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: gpu-share-pod2
spec:
  restartPolicy: OnFailure
  containers:
    - name: gpu-share-pod2
      image: "docker.io/cheyang/gpu-player:v2"
      env:
        - name: NVIDIA_VISIBLE_DEVICES
          value: "all"
      resources:
        limits:
         aliyun.com/gpu-mem: 5
EOF

应用清单后，我们可以看到可分配内存已成功更新：

❯ kubectl inspect gpushare
NAME       IPADDRESS      GPU0(Allocated/Total)  GPU Memory(GiB)
archlinux  192.168.8.100  8/16                   8/16
------------------------------------------------------
Allocated/Total GPU Memory In Cluster:
8/16 (50%)  

当我们再次查看 pod 的日志时，我们可以看到 TensorFlow 能够看到 GPU 设备，并注意到现在的 freeMemory 不是 11Gig 而是 8Gig： 作为最终测试，我们可以通过 SSH 连接到 GPU 工作节点并检查 GPU 进程：nvidia-msi Nvidia-smi 输出显示两个进程已连接到 GPU

❯ nvidia-smi
Thu Aug 24 09:46:49 2023       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.98                 Driver Version: 535.98       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 3080 ...    Off | 00000000:01:00.0 Off |                  N/A |
| N/A   51C    P0              31W / 105W |   5226MiB / 16384MiB |      4%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A    267687      G   /usr/lib/Xorg                                 4MiB |
|    0   N/A  N/A    274247      C   python                                     1798MiB |
|    0   N/A  N/A    274573      C   python                                     3410MiB |
+---------------------------------------------------------------------------------------+

总结​

在机器学习的背景下，由于 GPU 设备成本高昂，因此充分利用它们极其重要。特别是在本地环境中，您的机器和 GPU 数量有限，因此能够在不同的工作负载之间共享 GPU 容量非常重要。例如，在训练期间，您可能会在一项训练作业中占用全部 GPU 容量，但在推理期间，您很可能会在可用 GPU 上分布多个实例。

目前，标准 Kubernetes 版本不支持跨 pod 共享 GPU。然而，通过扩展 kubernetes 调度程序模块，我们确认可以实际虚拟化 GPU 内存，就像 Kubernetes 虚拟化工作节点的计算和内存一样。值得注意的是，这种共享机制发生在软件层，并且在 GPU 上运行的工作负载（例如 TensorFlow 限制_gpu_内存增长）中也应该正确处理 GPU 隔离。

本文介绍了如何将 Spring Cloud 服务发现下沉到 Kubernetes ，同时结合 Istio 解决 JVM 预热的一些思路。

背景​

在我们的生产环境中 spring 应用滚动发布时候会出现少量非200状态码，同时伴随着 cpu req 激增。

原因分析​

JVM 在启动时往往不能立即达到其最佳性能，需要经过一段时间的“预热”才能达到最优的执行速度。

在预热阶段 JIT 编译器会将热点代码编译成本地机器码，以提高执行效率。这个阶段，如果突然接收到大量请求，将会导致CPU使用率急剧上升。这是因为：

1. JIT即时编译：在预热期间，JVM需要不断地将热点代码编译成本地代码，这个过程本身就需要消耗CPU资源。
2. 大量请求处理：同时处理大量的请求，尤其是在代码还没有被充分优化时，会增加CPU的负担。

扩大 limit 可以缓解出现响应错误的现象，但这治标不治本。但过小的 limit 结合 HPA 容易产生 HPA Flapping 现象，比如Java程序启动时因为JVM预热、框架初始化等原因，通常资源使用率超高。HPA就会觉得资源不足，于是再新起一个Pod，结果新起的Pod还是资源使用率超高，导致HPA不断起新Pods直到hit预设的max Pod number。

• https://medium.com/blablacar/warm-up-the-relationship-between-java-and-kubernetes-7fc5741f9a23
• https://tech.olx.com/improving-jvm-warm-up-on-kubernetes-1b27dd8ecd58

目的​

我需要一个解决方案来预热，在 pod 准备就绪时，随着时间的推移而逐渐增加负载 pod 的 qps。

这样启动时少量的请求可以帮助 JVM 进行 JIT 编译，同时可以帮助减缓CPU的暴涨。

• 渐进式优化：JVM有更多的时间来识别热点代码，并进行优化编译，使得后续的请求处理更加高效。
• 避免突然负载增加：避免了因突然增加大量请求导致的CPU使用率急剧上升。

例如：让我希望预热时间为 120 秒。 现有 2 个 Pod 分别拥有 50% 的流量，当新的 Pod 启动时，它将处理低流量并随着时间的推移而增加，并将在 120 秒内达到 33%。

Spring Cloud 服务发现下沉​

我们的Spring Cloud框架采用的nacos服务发现机制，服务间调用会绕过Kubernetes的路由过程，流量直接定向到达目标服务的Pod IP，导致 istio 的相关策略失效，需要如下配置将其服务发现下沉到K8S中。

使用Nacos作为服务注册中心时，需配置：

spring.cloud.nacos.discovery.ip = your-service-name

同时需要保证服务间调用时在调用链路上透传请求头信息：

由于Spring Cloud的RibbonClient组件在发送HTTP请求时默认不会携带Istio路由所需的Host请求头[1]，开发者还需要自行添加HTTP Client的拦截器来在请求发出前添加内容为Host: 当前服务名的Header，使得请求能被Istio Sidecar处理。

• https://github.com/IBM/spring-cloud-kubernetes-with-istio/blob/master/README.md#discovery-client-and-istio

WarmupDurationSecs自动预热​

在 v1.14 之后，Istio 在目标规则中提供了预热功能（envoy 中的慢启动模式）。

对于基于 JVM 的服务来说，这是一个很棒的功能，我们计划使用它来解决 java 服务的慢启动问题。启动时少量的请求可以帮助 JVM 进行 JIT 编译，同时不会耗尽所有 cpu 资源。

Istio DestinationRule中 LoadBalancerSettings 部分的 WarmupDurationSecs 参数可用于控制新 pod 的流量逐渐增加。当应用新版本的部署时，Istio 可以在指定的时间段内逐渐增加更新的部署到 pod 的流量。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destination-rule
spec:
  host: my-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 180s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

因此，在 180 秒内，istio 将增加发送到 pod 的流量，增长速度几乎是线性的：

VirtualService 优化发布策略​

理想的情况是新启动的实例可以进入慢启动模式并接收流量，但旧实例应保持接收流量，直到新实例完成预热。

当服务处于慢启动模式（预热）时，它需要接收流量为 ready 状态，此时，在kubernetes滚动更新时，控制器会认为它已经准备好，去更新下一个实例，这可能会导致该服务的所有可用实例都处于慢启动模式。

注意这里使用perstop无法解决，因为进入perstop后 pod 也会停止接收流量，ip 会从 endpoint上摘除，控制器仍会更新下一个实例。

• https://discuss.istio.io/t/how-to-coordinate-warm-up-and-kubernetes-rolling-update/14154

这时我们可以借助 VirtualService 定义具有两条具有不同权重的路由，来进行渐进式发布：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

然后可以手动流量权重来完成发布，参考istio 文档。

当然这不够自动化，所以我们一般会可以结合 Flagger 或者 Argo Rollouts 来实现权重的自动切换和发布回退。

参考文章​

• https://stackoverflow.com/questions/74517652/gradually-warm-java-application-in-k8s-with-istio
• https://github.com/IBM/spring-cloud-kubernetes-with-istio/blob/master/README.md#discovery-client-and-istio
• https://github.com/argoproj/argo-rollouts/issues/617

在这篇博文中，我们将学习如何安装和使用它。

安装​

Sealed Secrets 由两个部分组成：

• Client-side CLI tool: kubeseal
  客户端CLI工具 kubeseal，用于加密机密和创建密封机密
• Server-side controller
  服务器端控制器，用于解密 SealedSecret CRD 和 创建 secrets

controller 安装​

sealed-secrets artifacthub

添加仓库并将其安装到 kube-system 命名空间：

Repo=https://bitnami-labs.github.io/sealed-secrets
Chart=sealed-secrets
Target=sealed-secrets
NameSpace=kube-system

helm upgrade --install ${Target} ${Chart} \
  --repo ${Repo} \
  --namespace ${NameSpace} \
  --create-namespace \
  --set-string fullnameOverride=sealed-secrets-controller 
  # --set customKey=YOUR_CUSTOM_KEY_HERE 
  # key-renew-period=0

• --namespace 将其安装在kube-systems使得kubeseal命令不用显示声明--controller-namespace=kube-systems
• --set-string fullnameOverride=sealed-secrets-controller 这个参数会 kube-system 命名空间里创建 sealed-secrets-controller service 使得 kubeseal 命令不用显示声明 controller-name=sealed-secrets-controller
• 控制器在首次部署时会生成自己的证书，它还会为您管理续订。但您也可以自带证书，以便控制器也可以使用它们。
• 控制器使用任何标记为 sealedsecrets.bitnami.com/sealed-secrets-key=active 的密钥中包含的证书，该密钥必须与控制器位于同一命名空间中。可以有多个这样的秘密。

kubeseal 安装​

kubeseal CLI 使用当前 kubectl 上下文访问集群。在继续之前，请确保 kubectl 已连接到应安装 Sealed Secrets 的群集。

# macos
brew install kubeseal
# linux
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.13.1/kubeseal-linux-amd64 -O kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

工作原理​

启动时，控制器会在其命名空间中搜索带有 sealedsecrets.bitnami.com/sealed-secrets-key 标签的 Secret 读取其中存放的私钥/公钥对。如果找不到，控制器则会生成一个新的 4096 位 RSA 密钥对，并在其命名空间中创建新的 Secret 将其保存其中。随后会将公钥部分打印到输出日志中。您可以使用以下命令以 YAML 格式查看此 Secret（包含公有/私有密钥对）的内容：

kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml

配套的 CLI 工具 kubeseal 使用公钥加密 Secret 资源生成 SealedSecret 定制化资源定义 (CRD)we文件。将 SealedSecret 自定义资源部署到 Kubernetes 集群时，控制器会拾取该资源，然后使用私钥将其解封并创建一个 Secret 资源。加密和解密时会使用 SealedSecret 的命名空间/名称作为输入参数，这样可以确保 SealedSecret 和 Secret 严格绑定到相同的命名空间和名称。

kubeseal 可以通过 Kubernetes API 服务器与控制器进行通信，并在运行时检索加密 Secret 所需的公钥。您也可以从控制器下载公钥并保存在本地以便离线使用。

基础使用​

SealedSecret 作用域​

• SealedSecret 和 Secret 必须具有相同的命名空间和名称。此功能可防止同一集群上的其他用户重复使用您密封的密钥。

# 默认限制命名空间
kubeseal --format yaml < mysecret.yaml > mysealedsecret.yaml
# --scope 全局可用生成的密文可以在整个集群中使用，而不是仅限于特定的命名空间
kubeseal --format yaml --scope cluster-wide < mysecret.yaml > mysealedsecret2.yaml

加密 secret​

kubeseal CLI 将 Kubernetes Secret 清单作为输入，对其进行加密并输出清单 SealedSecret 。

在本教程中，我们将使用此机密清单作为输入：

apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: null
  name: my-secret
data:
  password: YmFy
  username: Zm9v

将清单存储在名为 secret.yaml and encrypt it 的文件中：

cat secret.yaml | kubeseal \
    --controller-namespace kube-system \
    --controller-name sealed-secrets \
    --format yaml \
    > sealed-secret.yaml

sealed-secret.yaml 文件的内容应如下所示：

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: my-secret
  namespace: default
spec:
  encryptedData:
    password: AgA...
    username: AgA...
  template:
    metadata:
      creationTimestamp: null
      name: my-secret
      namespace: default

我们现在应该有秘密在里面 secret.yaml ，把密封的秘密在里面 sealed-secret.yaml 。此时已不再需要与该 Secret 有关的 YAML 清单，您可以将其删除。SealedSecret 将会是唯一被部署到集群的资源，如下所示：

请注意，原始 Secret 中的键（即username 和 password）在 SealedSecret 中未被加密，只有这些键对应的值被加密。您可以根据需要在 SealedSecret YAML 文件中更改这些键的名称，并且仍能够将更改后的键成功部署到集群中。但是，您不能更改 SealedSecret 的 name 和 namespace，否则会使 SealedSecret 无效，因为原始 Secret 的名称和命名空间会在加密过程中用作输入参数。这种方式提供了额外的保护措施，即使用户获得了对 SealedSecret 的 YAML 清单的访问权限（此 SealedSecret 是为在用户无权访问的 Kubernetes 集群中的特定命名空间而创建），他们也无法仅编辑清单和将 SealedSecret 部署到不同的命名空间（包括同一集群中的不同命名空间）。

为了部署密封的密钥，我们使用 kubectl 应用清单：

kubectl apply -f sealed-secret.yaml

集群中的控制器会注意到已创建资源 SealedSecret ，对其进行解密并创建已 Secret 解密的 .

让我们获取密钥以确保控制器已成功解封unsealed 它：

kubectl get secret my-secret -o yaml

数据应包含我们的 base64 编码用户名和密码：

...
data:
  password: YmFy
  username: Zm9v
...

一切都很顺利。秘密已被成功解封unsealed。

进阶指南​

自定义密钥​

• https://github.com/bitnami-labs/sealed-secrets/blob/main/docs/bring-your-own-certificates.md 设置变量

export PRIVATEKEY="default.key"
export PUBLICKEY="default.crt"
export NAMESPACE="sealed-secrets"
export SECRETNAME="mycustomkeys"
export DAYS="3650"

生成新的 RSA 密钥对（证书）

openssl req -x509 -days ${DAYS} -nodes -newkey rsa:4096 -keyout "$PRIVATEKEY" -out "$PUBLICKEY" -subj "/CN=sealed-secret/O=sealed-secret"

使用您最近创建的 RSA 密钥对创建 tls k8s 密钥

kubectl -n "$NAMESPACE" create secret tls "$SECRETNAME" --cert="$PUBLICKEY" --key="$PRIVATEKEY"
kubectl -n "$NAMESPACE" label secret "$SECRETNAME" sealedsecrets.bitnami.com/sealed-secrets-key=active

需要删除控制器 Pod 才能选择新密钥

kubectl -n  "$NAMESPACE" delete pod -l name=sealed-secrets-controller

查看控制器日志中的新证书（私钥）

kubectl -n "$NAMESPACE" logs -l name=sealed-secrets-controller

controller version: v0.12.1+dirty
2020/06/09 14:30:45 Starting sealed-secrets controller version: v0.12.1+dirty
2020/06/09 14:30:45 Searching for existing private keys
2020/06/09 14:30:45 ----- sealed-secrets-key5rxd9
2020/06/09 14:30:45 ----- mycustomkeys
2020/06/09 14:30:45 HTTP server serving on :8080

现在，您可以尝试使用自己的证书来密封密钥，而不是使用控制器提供的证书。

使用 --cert 以下标志使用自己的证书（密钥）：

kubeseal --cert "./${PUBLICKEY}" --scope cluster-wide < mysecret.yaml | kubectl apply -f-

我们可以看到秘密已经成功解封

kubectl -n "$NAMESPACE" logs -l name=sealed-secrets-controller

controller version: v0.12.1+dirty
2020/06/09 14:30:45 Starting sealed-secrets controller version: v0.12.1+dirty
2020/06/09 14:30:45 Searching for existing private keys
2020/06/09 14:30:45 ----- sealed-secrets-key5rxd9
2020/06/09 14:30:45 ----- mycustomkeys
2020/06/09 14:30:45 HTTP server serving on :8080
2020/06/09 14:37:55 Updating test-namespace/mysecret
2020/06/09 14:37:55 Event(v1.ObjectReference{Kind:"SealedSecret", Namespace:"test-namespace", Name:"mysecret", UID:"f3a6c537-d254-4c06-b08f-ab9548f28f5b", APIVersion:"bitnami.com/v1alpha1", ResourceVersion:"20469957", FieldPath:""}): type: 'Normal' reason: 'Unsealed' SealedSecret unsealed successfully

PRIVATEKEY 是您的私钥，控制器使用它来解封您的密钥。不要与任何你不信任的人分享它，并将其保存在一个安全的地方！

导出公钥和加密​

kubeseal --fetch-cert > public-key-cert.pem

然后使用 kubeseal 使用公钥文件创建 SealedSecret CRD，如下所示：

kubeseal --format=yaml --cert=public-key-cert.pem < secret.yaml > sealed-secret.yaml

导出私钥和解密​

kubectl -n kube-system get secret -l sealedsecrets.bitnami.com/sealed-secrets-key=active -o yaml  | kubectl neat > allsealkeys.yml

解密文件​

kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml > sealed-secrets-key.yaml

kubeseal < sealed-secret.yaml --recovery-unseal --recovery-private-key sealed-secrets-key.yaml -o yaml

Conclusion 结论​

Sealed Secrets 是一种在版本控制中管理 Kubernetes 机密的安全方法。在集群中存储加密密钥并解密机密。客户端无权访问加密密钥。

客户端使用 kubeseal CLI 工具生成 SealedSecret 保存加密数据的清单。应用文件后，服务器端控制器将识别新的密封密钥资源并对其进行解密以创建 Secret 资源。

这里有考试 CKA CKAD CKS 省钱攻略，和对中国区参加考试的注意事项，以及开源的考前学习料哦~

哦对了，点击上面徽章就可以对我的证书进行验证哦~

关于购买考试券​

购买地址：​

• Certified Kubernetes Administrator (CKA)
• Certified Kubernetes Security Specialist (CKS)
• Certified Kubernetes Application Developer (CKAD)

省钱技巧​

• 网络星期一 (Cyber Monday)

  建议在每年的11月左右购买考试，你可以享受到一年一度的 Cyber Monday 可以帮你节省 65% 的费用

• 黑色星期五（Black Friday）

  在11月份还有 Black Friday 活动， 可以帮你节省 35% 的费用

• 优惠券

  Linux Foundation 会不定期放出一些优惠券。这里给大家列举了几个优惠券。

  • SCOFFER15
  • DCUBEOFFER
  • DEVOPS15DEVOPS15
  • 更多优惠券

• 捆绑购买

  捆绑购买结合 Cyber Monday 将节省一大半费用，强烈推荐！！

关于中国区考试​

Linux Foundation 使用 PSI在线考试，无论购买那种语言进入考试系统后均可切换考试题的显示语言，目前支持 中文、英文、日文切换，但是考官语言无法更改。 当购买 CKA-CN、CKAD-CN、CKS-CN，中文试题后默认题目为中文，与考官发给你的消息会自动译为中文。

• 中国区考试购买地址

当你购买完成后会获得考试激活码，然后需要去 linuxfoundation learn 激活考试（申请考试，查看考试结果等都是这个链接，建议收藏到书签）。

考试注意事项​

大家在考试前按照流程仔细阅读相关手册。

• 候选人手册: candidate-handbook

• 注意事项：Important Instructions: CKA and CKAD

• 常见问题：faq-cka-ckad-cks

考纲和考试资料​

下面是我找到的一些考试的资料，同时购买考试附赠的 killer.sh 模拟考试不要放过.

• 官方考试大纲： github.com/cncf/curriculum

关于课程，我不建议买 Linux Foundation 出的课因为太贵了，非要购买的话推荐下面 udemy 的课程

• Certified Kubernetes Administrator (CKA) with Practice Tests
• Kubernetes Certified Application Developer (CKAD) with Tests
• Kubernetes CKS 2022 Complete Course - Theory - Practice

• CKA 资料

  • 推荐 https://github.com/walidshaari/Kubernetes-Certified-Administrator

  • 推荐 https://github.com/ahmetb/kubernetes-network-policy-recipes

    下面这些我没看过

    • https://github.com/ramitsurana/awesome-kubernetes
    • https://github.com/David-VTUK/CKA-StudyGuide
    • https://github.com/arush-sal/cka-practice-environment
    • https://github.com/alijahnas/CKA-practice-exercises
    • https://github.com/stretchcloud/cka-lab-practice
    • https://github.com/chadmcrowell/CKA-Exercises
    • https://github.com/kabary/kubernetes-cka/wiki

• CKAD 资料

  • 推荐 https://github.com/dgkanatsios/CKAD-exercises

  • 推荐 https://medium.com/bb-tutorials-and-thoughts/practice-enough-with-these-questions-for-the-ckad-exam-2f42d1228552

    下面这些我没看过

    • https://github.com/twajr/ckad-prep-notes
    • https://github.com/lucassha/CKAD-resources
    • https://github.com/StenlyTU/K8s-training-official
    • https://github.com/saripurigopi/CKAD
    • https://github.com/DStorck/cka-prep

• CKS 资料

  • 推荐 https://github.com/walidshaari/Certified-Kubernetes-Security-Specialist
  • 推荐 https://kubernetes-security.info/

• 其他人的经验

  • https://www.zhaohuabing.com/tags/cka/
  • https://www.reddit.com/r/kubernetes/comments/rzpu5i/i_just_passed_the_cka_here_are_some_tips_2022/
  • https://www.reddit.com/r/kubernetes/comments/s6l7xs/just_passed_the_cka_here_are_some_tips_and_tricks/

考试信息登记​

激活考试券后下拉页面进行考试信息登记

按照登记要求仔细阅读相关手册

证件准备​

认真阅读 Linux 基金会全球认证和保密协议——4.1 候选人 ID 和对照片、视频和录音的同意

考试清单名字填写​

打开考试清单填写页面

模拟考试​

在考试清单填写页面，可以看到考试附赠了你两次 killer.sh 模拟考试 FAQ 点击 Click here to access the Exam Simulator 跳转到 killer.sh

答题技巧​

1. 多用命令生成资源和 yaml --dry-run=client -o yaml
2. 禁止优雅关闭加快删除 POD 时间 --force --grace-period 0
3. 使用explain 查询 Kubernetes 资源的声明参数

• 如查询Pod的metadata 使用--recursive递归式列出所有参数
  • kubectl explain Pod.metadata --recursive

4. 考试使用远程桌面，你不能像以前那样把书签提前存到浏览器，好在题中自带相关文档连接，只是个别有些不准，最好记住每个细节在文档中的位置。
5. 显示器越大越好，因为远程桌面只占你屏幕的三分之二，我17寸的笔记本屏幕感觉有点小体验不是很好。
6. 如果你不想举着笔记本转圈的话建议购买外置摄像头，注意要买可视角度大的，不然很不方便。
7. 你的考试带有一次免费补考，两次考试内容基本一致，所以你可以将不确定的题截取下来

• Linux GDE 截屏快捷键 Alt+PrtScr ，建议 Gnome 在考试时候开启 请勿打扰 屏蔽系统通知，降低系统声音音量 设置-声音-音量级别-系统声音 ，Linux 还要注意你的麦克风声音不要过噪。
• windows 截屏快捷键 Win+PrtScr
• MAC 截屏快捷键 Shift+Command+3

8. 考试时间建议早上8点，我晚上考很卡而且有时候不用科学网络会连不上远程桌面。。。

证书与徽章​

考完试别忘记激活领取你的徽章哦~

目前考完24小时后可在 linuxfoundation learn 查看证书。

注意邮件查收，并到 https://info.credly.com/ 领取你的徽章。

领取后你可以参考如下代码将它添加到你的 Github Profile 中去~

<p align=""> 
  <a href="https://www.credly.com/badges/7f665fcf-c0a4-44e7-8b09-06584280dfc2">
    <img width="200" height="200" src="https://images.credly.com/size/680x680/images/8b8ed108-e77d-4396-ac59-2504583b9d54/cka_from_cncfsite__281_29.png" alt="CKA" />
  </a> 
  <a href="https://www.credly.com/badges/c37a3b97-5438-4c05-a28b-6ea2d6f38905">
    <img width="200" height="200" src="https://images.credly.com/size/680x680/images/f88d800c-5261-45c6-9515-0458e31c3e16/ckad_from_cncfsite.png" alt="CKAD" />
  </a> 
  <a href="https://www.credly.com/badges/02d42601-dfd8-41de-a90b-6e1aba0c716d">
    <img width="200" height="200" src="https://images.credly.com/size/680x680/images/9945dfcb-1cca-4529-85e6-db1be3782210/kubernetes-security-specialist-logo2.png" alt="CKS" />
  </a> 
</p>

本文将通过 解压 JAR 分层优化 和 Spring Boot 2.3 引入的分层索引特性 将 JAR 分成多个层来改进这一点。

先复习一下基本操作​

从 Docker 1.10 开始，COPY、ADD 和 RUN 语句会向镜像中添加新层，为了缩小最终制品体积常用 Docker 的多阶段构建来进行优化。

FROM ubuntu
RUN apt-get update
RUN apt-get install vim

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

在没有带 --no-cache=true 指令的情况下如果某一层没有改动，Docker 不会重新构建这一层而是会使用缓存 默认情况下如果第n层有改动，则n层以后的缓存都会失效，大多数情况下判断有无改动的方法是判断这层的指令和缓存中的构建指令是否一致，但是对于 COPY 和 ADD 命令会计算镜像内的文件和构建目录文件的校验和然后做比较来判断本层是否有改动。

最理想的情况下，我们希望将变化最快的东西放在最高层，并与其他应用程序共享尽可能多的大型、较低层，如 package.json 或者 composer.json 之类的包管理声明文件变动的时候会重新的安装包，在没有变动的情况下使用缓存缩短构建时间。

一个基础 Dockerfile​

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

您可以把 JAR_FILE 作为命令的一部分传递给 docker（Maven 和 Gradle 不同）。

docker build --build-arg JAR_FILE=target/*.jar -t myorg/myapp .

docker build --build-arg JAR_FILE=build/libs/*.jar -t myorg/myapp .

如果 ENTRYPOINT 命令行有点长，您可以将其提取到 shell 脚本中，如下所示：

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
COPY run.sh .
COPY target/*.jar app.jar
ENTRYPOINT ["run.sh"]

#!/bin/sh
exec java -jar /app.jar

ENTRYPOINT  ["java","${JAVA_OPTS}","-jar","/app.jar"]

docker run -p 9000:9000 -e JAVA_OPTS=-Dserver.port=9000 myorg/myapp

ENTRYPOINT ["sh", "-c", "java ${JAVA_OPTS} -jar /app.jar"]

docker run -p 8080:8080 -e "JAVA_OPTS=-Ddebug -Xmx128m" myorg/myapp

ENTRYPOINT ["sh", "-c", "java ${JAVA_OPTS} -jar /app.jar"]

docker run -p 9000:9000 myorg/myapp --server.port=9000

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["sh", "-c", "java ${JAVA_OPTS} -jar /app.jar ${0} ${@}"]

#!/bin/sh
exec java ${JAVA_OPTS} -jar /app.jar ${@}

目前为止 docker 配置很简单，但 docker 镜像有一个包含 fat JAR 的文件系统层，我们对应用程序代码所做的每一次更改都会更改该层。即使你只改了几kb的class，一样会导致这200Mb-300Mb 的 fat JAR 层缓存失效，这会占用大量更新服务时镜像下拉时间，而且在国内外镜像仓库同步时会占用大量带宽。

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
COPY run.sh .
COPY target/*.jar app.jar
ENTRYPOINT ["run.sh"]

这时我们可以利用 解压 JAR 分层优化 或者 Spring Boot 2.3 引入的分层索引特性 将 JAR 分成多个层来改进这一点。

一般 JAR 分层优化​

由于 JAR 本身的打包方式，Spring Boot fat JAR 自身为一层。我们可以先解压它，将其分为外部依赖和内部依赖，使更多的层可以被缓存。以下演示解压缩 Spring Boot fat JAR：（使用 Maven 但 Gradle 版本非常相似）

mkdir target/dependency
(cd target/dependency; jar -xf ../*.jar)
docker build -t myorg/myapp .

然后我们可以使用下面的Dockerfile

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

现在是三层，所有的应用资源都在后两层。如果应用程序依赖关系没有改变，第一层（from BOOT-INF/lib）不需要改变，所以构建速度更快，并且容器在运行时的启动也更快，只要基础层已经被缓存。

写成多阶段构建形式如下所示：

FROM eclipse-temurin:17-jdk-alpine as build
WORKDIR /workspace/app

COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src

RUN ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

Spring Boot 分层索引​

从 Spring Boot 2.3.0 开始，在 JAR 文件中包含层信息。该层信息根据应用程序构建之间更改的可能性将应用程序的各个部分分开。这可用于使 Docker 图像层更加高效。

层信息可用于将 JAR 内容提取到每个层的目录中：

mkdir target/extracted
java -Djarmode=layertools -jar target/*.jar extract --destination target/extracted
docker build -t myorg/myapp .

然后我们可以使用以下内容Dockerfile：

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG EXTRACTED=/workspace/app/target/extracted
COPY ${EXTRACTED}/dependencies/ ./
COPY ${EXTRACTED}/spring-boot-loader/ ./
COPY ${EXTRACTED}/snapshot-dependencies/ ./
COPY ${EXTRACTED}/application/ ./
ENTRYPOINT ["java","org.springframework.boot.loader.JarLauncher"]

安全方面​

遵循最小特权原则，进程不应以 root 权限运行，镜像应该包含运行应用程序的非根用户。

在 Dockerfile 中，您可以通过添加另一层添加系统用户和组并将其设置为当前用户（而不是默认的 root）来实现此目的：

FROM eclipse-temurin:17-jdk-alpine

RUN addgroup -S demo && adduser -S demo -G demo
USER demo

另一个考虑因素是，大多数应用程序在运行时可能不需要完整的 JDK，因此一旦我们进行了多阶段构建，我们就可以安全地切换到 JRE 基础映像。因此，在前面显示的多阶段构建中，我们可以使用最终的可运行图像：

FROM eclipse-temurin:17-jre-alpine
...

如前所述，这也节省了图像中的一些空间，这些空间将被运行时不需要的工具占用。

基础镜像的选择​

alpine​

前面示例中的基本图像是 eclipse-temurin:17-jdk-alpine. 这些 alpine 图像小于来自 Dockerhub eclipse-temurin 的标准库图像。

• Alpine 使用非标准的 C 库 musl libc 而不是 glibc 。muslibc 可能导致异常的 dns 解析，以及不支持 /etc/resolv.conf 的部分配置
• Alpine 并不比其他发行版小。 一旦你添加了任何需要的包，一个 Alpine Linux 镜像就和更主流的发行版一样大。
• Alpine 并不安全，没有为 alpine 维护的安全漏洞 (CVE) 列表，因此像 Clair (SAST) 这样的工具无法正确扫描它
• 无法使用 LXCFS 来提升容器资源可见性
• alpine 的镜像有性能问题超过 4 core 以上的应用场景，会发现 CPU 使用率上不去，原因未知,所以我们认为是 alpine 这个镜像本身，不适合 API 网关应用场景 (对性能有极致要求)
• 详情请参考以下文章
  • Moving to Ubuntu for our Docker image
  • Stop using Alpine Docker images
  • Why it's better not to use Alpine Linux for python projects
  • 不要在生产环境中使用alpine基础镜像 – 容器基础镜像的选择
  • Using Alpine can make Python Docker builds 50× slower
    • 有一种特殊情况会同时遇到 Alpine 的绝大多数问题：将 Python 用于数据科学。numpy 和 pandas 之类的包都被预编译成了 wheel，wheel 是 Python 新的打包格式，被编译成了二进制，用于替代 Python 传统的 egg 文件，可以通过 pip 直接安装。但这些 wheel 都绑定了特定的 C 库，这就意味着在大多数使用 glibc 的镜像中都可以正常安装，但 Alpine 就不行。如果非要在 Alpine 中安装，你需要安装很多依赖，重头构建，耗时又费力。

distroless/ubi/bazel​

distroless/ubi都可以从容器中移除所有不必要的 cruft，它们仅包含您的应用程序及其运行时依赖项。它们不包含包管理器、shell 以及您希望在标准 Linux 发行版中找到的任何其他程序。它有着更小的攻击面和更小的体积。

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM gcr.io/distroless/nodejs
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

如果你要问 GoogleCloudPlatform/distroless 和 redhat ubi 有什么区别呢？

那么可以参考：

• 红帽的这篇文章 Why distroless containers aren't the security solution you think they are
• 和这个仓库 raif-ahmed/ubi-vs-distroless-images

调试它们可以参考 linux 下 通过 nsenter 进入命名空间 或者 kubectl-debug 插件 或者 kubernetes 临时容器（ephemeral-containers），本文不再赘述。

扩展阅读：

• 识别应用程序运行时依赖性 Identifying application runtime dependencies
• https://bazel.build/

选择合适的 JRE JDK​

我们可以在多阶段构建的 build 阶段使用 JDK 作为基础镜像，run 阶段使用 JRE 作为基础镜像。（并非所有应用程序都可以使用 JRE（相对于 JDK），但大多数都可以。由于存在滥用某些 JDK 功能（例如编译）的风险，一些组织强制要求每个应用程序都必须使用 JRE 。）

• JRE 即 Java 运行时环境（Java Runtime Environment），包含了运行 Java 程序所需要的环境，即 JVM。
• JDK 即 Java 开发工具包（Java Development Kit），既包含了 JRE，也包含了开发 Java 程序所需的工具，即 Java 编译器。

JLink​

JLink 与 OpenJDK 11 及更高版本捆绑在一起。JLink 允许您从完整 JDK 中的模块子集构建自定义 JRE 分发，因此您不需要基础映像中的 JRE 或 JDK。这将使您获得比官方JRE/JDK图像更小的总图像大小。

缺点是自定义的 JRE 不能在其他应用程序之间共享，因为它们需要不同的自定义。因此，您的所有应用程序的图像可能都较小，但它们仍然需要更长的时间才能启动，因为它们无法从缓存 JRE 层中获益。

GraalVM native-image​

在云原生大背景下，对应用要求之一是 Disposability (易处置 - 快速启动和优雅退出), 而 java-jvm 存在预热慢、冷启动慢，而且内存占用巨大，不适合 serverless 场景，这里有基于 AWS Lambda 的所有语言的冷/热启动性能对比 AWS Lambda battle 2021: performance comparison for all languages (cold and warm start)。

所以 GraalVM 推出了 native-image，它可以将 Java 字节码作为输入来生成独立的二进制文件，所以不需要 JVM/GraalVM 之类 runtime，同时极大的降低了冷启动时间、内存消耗和应用体积。当然 Graalvm native-image 也是存在缺点的，比如夸张的编译时间，暂时不支持JVMTI、Java代理、JMX、JFR，不支持线程转储和堆转储等，更多请参考 native-image 兼容性指南 这部分提供了有关 GraalVM 限制的更多详细信息。

Spring 官方在下 2021 年 3 月 11 日 宣布了 Spring Native Beta 以支持 GraalVM native-image ， 2022 年 11月24日 Spring Boot 3 正式发布，与此同时 Spring Native 被 Spring Boot 3 官方原生支持所取代 相关参考文档。这方便了在 Spring 中使用 GraalVM native-image 进行编译。

补充​

• 如果你想尽快启动你的应用程序，你可能会考虑一些调整，参考文档：tweaks
• 这里还有一些自动化构建插件，参考文档：build_plugins

Jib 插件​

下面简单的介绍一个插件 GoogleContainerTools/jib 参考文档：Jib quickstart，

Jib 可以自动帮你完成 JAR 分层以及一些其他的镜像优化。最重要的是 Jib 和 BuildKit、kaniko 一样都是 Dockerless 的，因此你不需要 docker 环境来运行它！这非常适合 CI/CD !

同时 Jib 不需要 Dockerfile（它无论如何都会被忽略）它的参数在 pom.xml 中定义，或者也可以作为参数传递给它。

以下示例在不更改的情况下使用 Maven pom.xml：

mvn com.google.cloud.tools:jib-maven-plugin:build \
-Djib.from.image=${FROM_IMAGE} \
-Djib.to.image=$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME-$CI_COMMIT_SHORT_SHA  \
-Djib.to.auth.username=$CI_REGISTRY_USER \
-Djib.to.auth.password=$CI_REGISTRY_PASSWORD

这里有一篇来自 Google 关于容器构建工具的对比文章推荐阅读 Buildpacks vs Jib vs Dockerfile: Comparing containerization methods

Docker 实验功能​

Docker 18.06 带有一些“实验性”功能，包括缓存构建依赖项的方法。要打开它们，您需要守护程序中的标志 ( dockerd) 和运行客户端时的环境变量。

# syntax=docker/dockerfile:experimental

该RUN指令然后接受一个新标志：--mount。以下清单显示了一个完整的示例：

# syntax=docker/dockerfile:experimental
FROM eclipse-temurin:17-jdk-alpine as build
WORKDIR /workspace/app

COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src

RUN --mount=type=cache,target=/root/.m2 ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

# syntax=docker/dockerfile:experimental
FROM eclipse-temurin:17-jdk-alpine AS build
WORKDIR /workspace/app

COPY . /workspace/app
RUN --mount=type=cache,target=/root/.gradle ./gradlew clean build
RUN mkdir -p build/dependency && (cd build/dependency; jar -xf ../libs/*.jar)

FROM eclipse-temurin:17-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/build/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

然后你可以运行它：

DOCKER_BUILDKIT=1 docker build -t myorg/myapp .

...
=> /bin/sh -c ./mvnw install -DskipTests              5.7s
=> exporting to image                                 0.0s
=> => exporting layers                                0.0s
=> => writing image sha256:3defa...
=> => naming to docker.io/myorg/myapp

使用实验性功能，您可以在控制台上获得不同的输出，但您可以看到 Maven 构建现在只需要几秒钟而不是几分钟，前提是缓存是热的。

参考文档​

• Spring Boot Docker
• 3 simple tricks for smaller Docker images

本文将介绍如何使用 Argocd-Vault-Plugin 管理 GitOps 中的 Secret

先决条件​

在开始本教程之前，请确保您已经部署ArgoCD/Vault。我们不会在本文中向您展示如何做到这一点，但您可以参考下面给出的文档和演示用例。

• ArgoCD — https://argoproj.github.io/argo-cd/getting_started/ 快速开始 参考我的配置
• Vault — https://www.vaultproject.io/docs/platform/k8s/helm/run 快速开始 使用开发模式

工作原理​

该插件的工作原理是首先根据可以指定为环境变量或 YAML 文件内部的注释的路径从 Vault 等秘密管理器中检索值，然后将值注入到模板化的输出 yaml 中，该 yaml 使用 <> 作为模板标记。例如：

kind: Secret
apiVersion: v1
metadata:
  name: example-secret
  annotations:
    avp.kubernetes.io/path: "path/to/secret"
type: Opaque
stringData:
  password: <password-vault-key>

在上面的yaml中，可以看到有一个标准的Kubernetes Secret定义。有一个名为 password 的秘密，但值是 <password-vault-key> ，如果插件在Vault中找到 password-vault-key 密钥，它将注入一个值。

准备 Vault 环境​

vault 部署后查看 vault-0 的日志来获取登录 token等信息

kubectl logs vault-0  -n vault 
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variables:

    $ export VAULT_ADDR='http://[::]:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: 7MY282Sz3te29uktYXqAFEBZ04GMIs5fkceWYPzRwos=
Root Token: root

Development mode should NOT be used in production installations!

这时候，我们可以使用获取到的Root Token 进行登录。

你可以通过本地客户端登录

export VAULT_ADDR=https://vault.cloudnative.love/
vault login <your_token>

或者进入 vault-0 容器内登录

kubectl -n vault exec -it vault-0 -- sh
vault login <your_token>

登录后将看到如下提示

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                <your_token>
token_accessor       <your_token_accessors>
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

创建 Vault 认证模式​

在使用 avp 此之前，让我们快速了解一下 vault 常用的认身份验证方式。

• Userpass Authentication: 用户名密码身份验证
• Token Authentication: 令牌身份验证，令牌身份验证自动启用。当您启动开发服务器时，输出显示一个 root 令牌。
• AppRole Authentication(推荐)：应用角色授权
• Kubernetes Authentication(推荐): Kubernetes身份验证，可用于使用Kubernetes的 service account 令牌对 Vault 进行身份验证。这种身份验证方法可以轻松地将Vault令牌引入Kubernetes Pod。

下面我们来配置 vault 的身份验证

vault auth enable approle

vault write auth/approle/role/avp-role \
    secret_id_ttl=10m \
    token_num_uses=10 \
    token_ttl=20m \
    token_max_ttl=30m \
    secret_id_num_uses=40

vault read auth/approle/role/avp-role/role-id
Key        Value
---        -----
role_id    6f944878-1e02-c842-9251-5d8caa1af3f8

vault write -f auth/approle/role/avp-role/secret-id
Key                   Value
---                   -----
secret_id             8e4732c5-5210-37a6-8d9b-2338d96b8018
secret_id_accessor    7d8a9fbb-4bcb-92ec-a909-25233838529d
secret_id_num_uses    40
secret_id_ttl         10m

vault write auth/approle/login role_id=db02de05-fa39-4855-059b-67221c5c2f63 secret_id=6a174c20-f6de-a53c-74d2-6018fcceff64

vault auth enable kubernetes

## get Kubernetes host address
K8S_HOST="https://$( kubectl exec -n vault vault-0 -- env | grep KUBERNETES_PORT_443_TCP_ADDR| cut -f2 -d'='):443"
## get Service Account token from Vault Pod
SA_TOKEN=$(kubectl -n vault exec vault-0 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
## get Service Account CA certificate from Vault Pod
SA_CERT=$(kubectl -n vault exec vault-0 -- cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt)
## configure Kubernetes Auth Method
vault write auth/kubernetes/config \
    token_reviewer_jwt=$SA_TOKEN \
    kubernetes_host=$K8S_HOST \
    kubernetes_ca_cert=$SA_CERT

vault write auth/kubernetes/role/argocd \
    bound_service_account_names=<your-service-account> \
    bound_service_account_namespaces=argocd \
    policies=argocd \
    ttl=1h

配置 Argo-Vault-Plugin​

要想让avp通过vault认证，我们可以将认证参数作为环境变量保存为secret，并通过envFrom传入repo-server的pod中：

      envFrom:
        - secretRef:
            name: argocd-vault-plugin-credentials

或者在avp命令中添加--secret-name指定包含认证参数的secret

argocd-vault-plugin generate --secret-name <namespace>:<name> .

不同认证模式所需环境变量参考官方文档 backends 部分

VAULT_ADDR: Your HashiCorp Vault Address
VAULT_TOKEN: Your Vault token
AVP_TYPE: vault
AVP_AUTH_TYPE: token

VAULT_ADDR: Your HashiCorp Vault Address
AVP_TYPE: vault
AVP_AUTH_TYPE: userpass
AVP_USERNAME: Your Username
AVP_PASSWORD: Your Password

VAULT_ADDR: Your HashiCorp Vault Address
AVP_TYPE: vault
AVP_AUTH_TYPE: approle
AVP_ROLE_ID: Your AppRole Role ID
AVP_SECRET_ID: Your AppRole Secret ID

kubectl create secret generic argocd-vault-plugin-credentials \
--from-literal=VAULT_ADDR=vault.cloudnative.love \
--from-literal=AVP_TYPE=vault \
--from-literal=AVP_AUTH_TYPE=approle \
--from-literal=AVP_ROLE_ID=6f944878-1e02-c842-9251-5d8caa1af3f8 \
--from-literal=AVP_SECRET_ID=8e4732c5-5210-37a6-8d9b-2338d96b8018 \
--type=Opaque \
--dry-run=client  -oyaml