本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。

高级选项 / 配置

本节包含高级信息，描述了您可以运行和管理 K3s 的不同方式，以及为 K3s 使用准备主机操作系统所需的步骤。

证书管理

证书颁发机构证书

K3s 在第一个服务器节点启动时生成自签名的证书颁发机构 (CA) 证书。这些 CA 证书有效期为 10 年，且不会自动续期。

有关使用自定义 CA 证书或续签自签名 CA 证书的信息，请参见 k3s certificate rotate-ca 命令文档。

客户端和服务器证书

K3s 客户端和服务器证书自签发之日起有效期为 365 天。任何过期的证书或在 90 天内即将过期的证书，每次 K3s 启动时会自动续期。

有关手动轮换客户端和服务器证书的信息，请参见 k3s certificate rotate 命令文档。

令牌管理

默认情况下，K3s 对于服务器和代理使用一个静态令牌。在小心操作的情况下，集群创建后可以轮换此令牌。 还可以启用第二个静态令牌，该令牌只能用于加入代理，或创建临时的 kubeadm 风格的加入令牌，这些令牌会自动过期。 有关更多信息，请参见 k3s token 命令文档。

配置 DNS 解析

域名服务器可用性检查

在启动时，每个节点检查 /etc/resolv.conf 和 /run/systemd/resolve/resolv.conf 中的文件，以查找环回、多播或链路本地域名服务器。 如果存在任何此类条目，则不使用配置文件，因为此类条目在 从其节点继承名称解析配置 的 pod 中无法正常工作。 如果未找到可用的 resolv.conf，K3s 会向日志打印警告信息，并生成一个使用 8.8.8.8 和 2001:4860:4860::8888 作为名称服务器的 stub resolv.conf。

如果您希望在不修改系统配置文件的情况下为 K3s 提供替代的解析器配置，可以使用 --resolv-conf 选项指定合适文件的路径。 手动指定的解析器配置文件不受有效性检查。

CoreDNS 自定义配置导入

为了自定义 CoreDNS 配置，您可以在 kube-system 名称空间中创建一个名为 coredns-custom 的 ConfigMap。 与 .override 匹配的键将被导入到 :.53 服务器块中。 额外的服务器块可以放置在与 .server 匹配的键中。 额外的内容（区域文件等）也可以存在，并在 coredns pods 中挂载到 /etc/coredns/custom 下。

以下是一个示例 ConfigMap，它将对 example.com 的查找转发到位于 10.0.0.1 的名称服务器，并从 `example.net`https://datatracker.ietf.org/doc/html/rfc1035#section-5[RFC 1035] 兼容的文本文件中提供：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  example-com.override: |
    forward example.com 10.0.0.1
  example-net.server: |
    example.net:53 {
      log
      errors
      file /etc/coredns/custom/db.example.net
    }
  db.example.net: |
    $ORIGIN example.net.
    @       3600 IN SOA    sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
            3600 IN NS     a.iana-servers.net.
            3600 IN NS     b.iana-servers.net.
    www          IN A      127.0.0.1
                 IN AAAA   ::1

配置 HTTP 代理

如果您在一个仅通过 HTTP 代理具有外部连接的环境中运行 K3s，您可以在 K3s systemd 服务上配置代理设置。这些代理设置将被 K3s 使用，并传递给嵌入的 containerd 和 kubelet。

来自主机的代理配置和其他环境变量不会传递到 Pods 中。

K3s 安装脚本将自动从当前 shell 中获取 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 变量，以及 CONTAINERD_HTTP_PROXY、CONTAINERD_HTTPS_PROXY 和 CONTAINERD_NO_PROXY 变量（如果存在），并将它们写入您的 systemd 服务的环境文件，通常是：

  • /etc/systemd/system/k3s.service.env

  • /etc/systemd/system/k3s-agent.service.env

当然，您也可以通过编辑这些文件来配置代理。

K3s 将自动将集群内部 Pod 和服务 IP 范围以及集群 DNS 域添加到 NO_PROXY 条目列表中。您应该确保 Kubernetes 节点本身使用的 IP 地址范围（即节点的公共和私有 IP）包含在 NO_PROXY 列表中，或者节点可以通过代理访问。

HTTP_PROXY=http://your-proxy.example.com:8888
HTTPS_PROXY=http://your-proxy.example.com:8888
NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

如果您希望为 containerd 配置代理设置而不影响 K3s 和 Kubelet，您可以在变量前加上 CONTAINERD_：

CONTAINERD_HTTP_PROXY=http://your-proxy.example.com:8888
CONTAINERD_HTTPS_PROXY=http://your-proxy.example.com:8888
CONTAINERD_NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

使用 Docker 作为容器运行时

K3s 包含并默认使用 containerd，这是一个行业标准的容器运行时。 从 Kubernetes 1.24 开始，Kubelet 不再包含 dockershim，该组件允许 kubelet 与 dockerd 通信。 K3s 1.24 及更高版本包含 cri-dockerd，这使得可以无缝升级到之前版本的 K3s，同时继续使用 Docker 容器运行时。

要使用 Docker 而不是 containerd：

  1. 在 K3s 节点上安装 Docker。可以使用 Rancher 的 Docker 安装脚本 来安装 Docker：

    curl https://releases.rancher.com/install-docker/20.10.sh | sh

  2. 使用 --docker 选项安装 K3s：

    curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s sh -s - --docker

  3. 确认集群可用：

    $ sudo k3s kubectl get pods --all-namespaces
NAMESPACE     NAME                                     READY   STATUS      RESTARTS   AGE
kube-system   local-path-provisioner-6d59f47c7-lncxn   1/1     Running     0          51s
kube-system   metrics-server-7566d596c8-9tnck          1/1     Running     0          51s
kube-system   helm-install-traefik-mbkn9               0/1     Completed   1          51s
kube-system   coredns-8655855d6-rtbnb                  1/1     Running     0          51s
kube-system   svclb-traefik-jbmvl                      2/2     Running     0          43s
kube-system   traefik-758cd5fc85-2wz97                 1/1     Running     0          43s

  4. 确认 Docker 容器正在运行：

    $ sudo docker ps
CONTAINER ID        IMAGE                     COMMAND                  CREATED              STATUS              PORTS               NAMES
3e4d34729602        897ce3c5fc8f              "entry"                  About a minute ago   Up About a minute                       k8s_lb-port-443_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
bffdc9d7a65f        rancher/klipper-lb        "entry"                  About a minute ago   Up About a minute                       k8s_lb-port-80_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
436b85c5e38d        rancher/library-traefik   "/traefik --configfi…"   About a minute ago   Up About a minute                       k8s_traefik_traefik-758cd5fc85-2wz97_kube-system_07abe831-ffd6-4206-bfa1-7c9ca4fb39e7_0
de8fded06188        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_svclb-traefik-jbmvl_kube-system_d46f10c6-073f-4c7e-8d7a-8e7ac18f9cb0_0
7c6a30aeeb2f        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_traefik-758cd5fc85-2wz97_kube-system_07abe831-ffd6-4206-bfa1-7c9ca4fb39e7_0
ae6c58cab4a7        9d12f9848b99              "local-path-provisio…"   About a minute ago   Up About a minute                       k8s_local-path-provisioner_local-path-provisioner-6d59f47c7-lncxn_kube-system_2dbd22bf-6ad9-4bea-a73d-620c90a6c1c1_0
be1450e1a11e        9dd718864ce6              "/metrics-server"        About a minute ago   Up About a minute                       k8s_metrics-server_metrics-server-7566d596c8-9tnck_kube-system_031e74b5-e9ef-47ef-a88d-fbf3f726cbc6_0
4454d14e4d3f        c4d3d16fe508              "/coredns -conf /etc…"   About a minute ago   Up About a minute                       k8s_coredns_coredns-8655855d6-rtbnb_kube-system_d05725df-4fb1-410a-8e82-2b1c8278a6a1_0
c3675b87f96c        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_coredns-8655855d6-rtbnb_kube-system_d05725df-4fb1-410a-8e82-2b1c8278a6a1_0
4b1fddbe6ca6        rancher/pause:3.1         "/pause"                 About a minute ago   Up About a minute                       k8s_POD_local-path-provisioner-6d59f47c7-lncxn_kube-system_2dbd22bf-6ad9-4bea-a73d-620c90a6c1c1_0
64d3517d4a95        rancher/pause:3.1         "/pause"

使用 etcdctl

etcdctl 提供了与 etcd 服务器交互的 CLI。K3s 不捆绑 etcdctl。

如果您想使用 etcdctl 与 K3s 的嵌入式 etcd 交互，请使用 官方文档 安装 etcdctl。

ETCD_VERSION="v3.5.5"
ETCD_URL="https://github.com/etcd-io/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz"
curl -sL ${ETCD_URL} | sudo tar -zxv --strip-components=1 -C /usr/local/bin

然后，您可以通过配置 etcdctl 使用 K3s 管理的证书和密钥进行身份验证：

sudo etcdctl version \
  --cacert=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/k3s/server/tls/etcd/client.crt \
  --key=/var/lib/rancher/k3s/server/tls/etcd/client.key

配置 containerd

版本门控

K3s 从 2025 年 2 月的版本开始包含 containerd 2.0：v1.31.6+k3s1 和 v1.32.2+k3s1。 请注意，containerd 2.0 更倾向于配置版本 3，而 containerd 1.7 更倾向于配置版本 2。

K3s 将在 /var/lib/rancher/k3s/agent/etc/containerd/config.toml 为 containerd 生成一个配置文件，使用特定于当前集群和节点配置的值。

对于高级自定义，您可以在同一目录中创建一个 containerd 配置模板：

  • 对于 containerd 2.0，请在 config-v3.toml.tmpl 中放置版本 3 的配置模板。

    请参阅https://github.com/containerd/containerd/blob/release/2.0/docs/cri/config.md[containerd 2.0 文档]以获取更多信息。

  • 对于 containerd 1.7 及更早版本，请在 config.toml.tmpl 中放置版本 2 配置模板。

    请参阅https://github.com/containerd/containerd/blob/release/1.7/docs/cri/config.md[containerd 1.7 文档]以获取更多信息。

Containerd 2.0 与之前的配置版本向后兼容，如果未找到 config-v3.toml.tmpl，k3s 将继续从 config.toml.tmpl 渲染旧版 2 配置。

模板文件使用 text/template 库渲染到 containerd 配置中。 请参阅 ContainerdConfigTemplateV3 和 ContainerdConfigTemplate 在 templates.go 中的默认模板内容。 模板使用 ContainerdConfig 结构作为其点值（数据参数）执行。

基础模板

您可以扩展 K3s 基础模板，而不是从 K3s 源代码中复制粘贴完整的标准模板。如果您只需要通过在默认值之前或之后添加几行额外的内容来构建现有配置，这将非常有用。

/var/lib/rancher/k3s/agent/etc/containerd/config-v3.toml.tmpl
{{ template "base" . }}

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'custom']
  runtime_type = "io.containerd.runc.v2"
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'custom'.options]
  BinaryName = "/usr/bin/custom-container-runtime"
  SystemdCgroup = true

为了获得最佳效果，请勿仅仅将预渲染的 config.toml 复制到模板中并进行所需的更改。使用基础模板，或提供基于上述 k3s 默认值的完整模板。

替代容器运行时支持

如果在 K3s 启动时存在，K3s 将自动检测替代容器运行时。支持的容器运行时包括：

crun, lunatic, nvidia, nvidia-cdi, nvidia-experimental, slight, spin, wasmedge, wasmer, wasmtime, wws

K3s 使用服务的 PATH 环境变量来搜索容器运行时可执行文件。 如果 K3s 未检测到已安装的容器运行时，请确保它存在于系统路径中，通常包括：
/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin

NVIDIA 容器运行时

NVIDIA GPU 需要安装 NVIDIA 容器运行时，以便在 Pods 中调度和运行加速工作负载。要在 K3s 中使用 NVIDIA GPU，请执行以下步骤：

  1. 通过以下说明在节点上安装 nvidia-container 软件包存储库：https://nvidia.github.io/libnvidia-container/

  2. 安装 NVIDIA 容器运行时软件包。例如：apt install -y nvidia-container-runtime cuda-drivers-fabricmanager-515 nvidia-headless-515-server

  3. 安装 K3s，或者如果已经安装则重新启动。

  4. 确认 k3s 已找到 NVIDIA 容器运行时：grep nvidia /var/lib/rancher/k3s/agent/etc/containerd/config.toml

如果这些步骤正确执行，K3s将根据找到的运行时可执行文件自动将NVIDIA运行时添加到containerd配置中。 K3s包括所有支持的替代运行时的Kubernetes RuntimeClass定义。您可以通过在k3s CLI或配置文件中设置`runc`值，选择其中一个替代`--default-runtime`作为节点上的默认运行时。

如果您没有更改GPU节点上的默认运行时，必须通过在Pod规格中设置`runtimeClassName: nvidia`来显式请求NVIDIA运行时：

apiVersion: v1
kind: Pod
metadata:
  name: nbody-gpu-benchmark
  namespace: default
spec:
  restartPolicy: OnFailure
  runtimeClassName: nvidia
  containers:
  - name: cuda-container
    image: nvcr.io/nvidia/k8s/cuda-sample:nbody
    args: ["nbody", "-gpu", "-benchmark"]
    resources:
      limits:
        nvidia.com/gpu: 1
    env:
    - name: NVIDIA_VISIBLE_DEVICES
      value: all
    - name: NVIDIA_DRIVER_CAPABILITIES
      value: all

请注意，NVIDIA容器运行时通常与https://github.com/NVIDIA/k8s-device-plugin/[NVIDIA设备插件]一起使用，并进行修改以确保Pod规格包含`runtimeClassName: nvidia`，如上所述。

运行无代理服务器（实验性）

此功能是实验性的。

当使用`--disable-agent`标志启动时，服务器不会运行kubelet、容器运行时或CNI。它们不会在集群中注册节点资源，并且不会出现在`kubectl get nodes`输出中。 因为它们不托管kubelet，所以无法运行Pod或被依赖于枚举集群节点的操作员管理，包括嵌入式etcd控制器和系统升级控制器。

如果您希望隐藏控制平面节点以避免被代理和工作负载发现，运行无代理服务器可能是有利的，但会增加由于缺乏集群操作员支持而导致的管理开销。

默认情况下，无代理服务器上的 apiserver 将无法与集群内运行的准入 webhook 或聚合 api 服务建立外部连接。为了解决此问题，将`--egress-selector-mode`服务器标志设置为`pod`或`cluster`。如果您在现有集群上更改此标志，则需要重新启动集群中的所有节点以使选项生效。

运行无根服务器（实验性）

此功能是实验性的。

无根模式允许以非特权用户身份运行 K3s 服务器，从而保护主机上的真实 root 免受潜在的容器逃逸攻击。

有关无根 Kubernetes 的更多信息，请参见 https://rootlesscontaine.rs/。

无根模式的已知问题

  • 端口

    在运行无根模式时，会创建一个新的网络名称空间。 这意味着 K3s 实例的网络与主机相对独立。 从主机访问在 K3s 中运行的服务的唯一方法是设置端口转发到 K3s 网络名称空间。 无根 K3s 包含控制器，将自动将 6443 和 1024 以下的服务端口绑定到主机，偏移量为 10000。

    例如，端口 80 上的服务将在主机上变为 10080，但 8080 将保持为 8080，没有任何偏移。目前，只有负载均衡服务会自动绑定。

  • 控制组

    不支持 Cgroup v1 和混合 v1/v2；仅支持纯 Cgroup v2。如果 K3s 在运行无根模式时因缺少控制组而无法启动，可能是您的节点处于混合模式，并且 "缺少" 的控制组仍绑定到 v1 控制器。

  • 多节点/多进程集群

    当前不支持多节点无根集群或同一节点上的多个无根 k3s 进程。有关更多详细信息，请参见 #6488。

启动无根服务器

  • 启用 cgroup v2 委托，请参见 https://rootlesscontaine.rs/getting-started/common/cgroup2/。 此步骤是必需的；无根 kubelet 在没有适当的控制组委托时将无法启动。

  • 从 https://github.com/k3s-io/k3s/blob/<VERSION>/k3s-rootless.service 下载 k3s-rootless.service。 确保使用相同版本的 k3s-rootless.service 和 k3s。

  • 将 k3s-rootless.service 安装到 ~/.config/systemd/user/k3s-rootless.service。 不支持将此文件安装为系统范围的服务 (/etc/systemd/…​)。 根据 k3s 二进制文件的路径，您可能需要修改文件的 ExecStart=/usr/local/bin/k3s …​ 行。

  • 运行 systemctl --user daemon-reload

  • 运行 systemctl --user enable --now k3s-rootless

  • 运行 KUBECONFIG=~/.kube/k3s.yaml kubectl get pods -A，并确保 Pod 正在运行。

请勿尝试在终端上运行 k3s server --rootless，因为终端会话不允许 cgroup v2 委托。 如果您确实需要在终端上尝试，请使用 systemd-run --user -p Delegate=yes --tty k3s server --rootless 将其包装在 systemd 范围内。

高级无根配置

无根 K3s 使用 rootlesskit 和 slirp4netns 在主机和用户网络名称空间之间进行通信。 rootlesskit 和 slirp4netns 使用的一些配置可以通过环境变量设置。设置这些的最佳方法是将它们添加到 k3s-rootless systemd 单元的 Environment 字段中。

变量 默认值 说明

K3S_ROOTLESS_MTU

1500

设置 slirp4netns 虚拟接口的 MTU。

K3S_ROOTLESS_CIDR

10.41.0.0/16

设置 slirp4netns 虚拟接口使用的 CIDR。

K3S_ROOTLESS_ENABLE_IPV6

自动检测

启用 slirp4netns 的 IPv6 支持。如果未指定，如果 K3s 配置为双栈操作，则会自动启用。

K3S_ROOTLESS_PORT_DRIVER

内置

选择无根端口驱动程序；可以是 builtin 或 slirp4netns。内置更快，但会伪装入站数据包的原始源地址。

K3S_ROOTLESS_DISABLE_HOST_LOOPBACK

true

控制是否通过网关接口启用对主机环回地址的访问。出于安全原因，建议不要更改此项。

无根故障排除

  • 运行 systemctl --user status k3s-rootless 检查守护程序状态

  • 运行 journalctl --user -f -u k3s-rootless 查看守护程序日志

  • 另请参见 https://rootlesscontaine.rs/

节点标签和污点

K3s 代理可以使用选项 --node-label 和 --node-taint 进行配置，这将为 kubelet 添加标签和污点。这两个选项仅在注册时添加标签和/或污点at registration time，因此只能在节点首次加入集群时设置。

所有当前版本的 Kubernetes 限制节点使用 kubernetes.io 和 k8s.io 前缀注册大多数标签，特别包括 kubernetes.io/role 标签。如果您尝试启动带有不允许标签的节点，K3s 将无法启动。正如 Kubernetes 作者所述：

节点不允许声明自己的角色标签。节点角色通常用于识别特权或控制平面类型的节点，允许节点将自己标记为该池中的节点会使被攻陷的节点轻易吸引工作负载（如控制平面守护程序集），从而获得更高特权凭证的访问权限。

有关更多信息，请参见 SIG-Auth KEP 279。

如果您想在节点注册后更改节点标签和污点，或添加保留标签，您应该使用 kubectl。有关如何添加 污点 和 节点标签 的详细信息，请参阅官方 Kubernetes 文档。

使用安装脚本启动服务

安装脚本将自动检测您的操作系统是否使用 systemd 或 openrc，并在安装过程中启用并启动服务。

  • 在使用 openrc 运行时，日志将创建在 /var/log/k3s.log。

  • 在使用 systemd 运行时，日志将创建在 /var/log/syslog 中，并使用 journalctl -u k3s（或在代理上使用 journalctl -u k3s-agent）查看。

以下是禁用自动启动和服务启用的安装脚本示例：

curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s INSTALL_K3S_SKIP_START=true INSTALL_K3S_SKIP_ENABLE=true sh -

在 Docker 中运行 K3s

在 Docker 中运行 K3s 有几种方法：

  • K3d

  • Docker

k3d 是一个旨在轻松在 Docker 中运行多节点 K3s 集群的工具。

k3d 使得在 Docker 中创建单节点和多节点 K3s 集群变得非常简单，例如用于 Kubernetes 的本地开发。

有关如何安装和使用 k3d 的更多信息，请参见 安装 文档。

要使用 Docker，rancher/k3s 还提供了运行 K3s 服务器和代理的镜像。 使用 docker run 命令：

sudo docker run \
  --privileged \
  --name k3s-server-1 \
  --hostname k3s-server-1 \
  -p 6443:6443 \
  -d rancher/k3s:v1.24.10-k3s1 \
  server

您必须指定一个有效的 K3s 版本作为标签；latest 标签不再维护。
Docker 镜像不允许在标签中使用 + 符号，请改用标签中的 -。

一旦 K3s 启动并运行，您可以将管理员 kubeconfig 从 Docker 容器中复制出来以供使用：

sudo docker cp k3s-server-1:/etc/rancher/k3s/k3s.yaml ~/.kube/config

SELinux 支持

如果您在默认启用 SELinux 的系统上安装 K3s（例如 CentOS），则必须确保已安装适当的 SELinux 策略。

  • 自动安装

  • 手动安装

如果在兼容系统上进行非隔离安装，安装脚本 将自动从 Rancher RPM 储存库安装 SELinux RPM。通过设置 INSTALL_K3S_SKIP_SELINUX_RPM=true 可以跳过自动安装。

可以使用以下命令安装所需的策略：

yum install -y container-selinux selinux-policy-base
yum install -y https://rpm.rancher.io/k3s/latest/common/centos/9/noarch/k3s-selinux-1.6-1.el9.noarch.rpm

要强制安装脚本记录警告而不是失败，您可以设置以下环境变量：INSTALL_K3S_SELINUX_WARN=true。

启用 SELinux 强制执行

要利用 SELinux，在启动 K3s 服务器和代理时指定 --selinux 标志或设置 K3S_SELINUX=true 环境变量。

此选项也可以在 K3s 配置文件 中指定。

selinux: true

在 SELinux 下使用自定义 --data-dir 是不支持的。要自定义它，您很可能需要编写自己的自定义策略。有关指导，您可以参考 containers/container-selinux 储存库，该储存库包含容器运行时的 SELinux 策略文件，以及 k3s-io/k3s-selinux 储存库，该储存库包含 K3s 的 SELinux 策略。

启用懒惰拉取 eStargz（实验性）

什么是懒惰拉取和 eStargz？

拉取镜像被认为是容器生命周期中耗时的步骤之一。 根据 Harter, 等，

拉取软件包占容器启动时间的 76%，但其中只有 6.4% 的数据被读取。

为了解决这个问题，k3s 实验性地支持 懒惰拉取 镜像内容。 这允许 k3s 在整个镜像被拉取之前启动容器。 相反，必要的内容块（例如单个文件）是按需获取的。 特别是对于大型镜像，这种技术可以缩短容器启动延迟。

要启用懒惰拉取，目标镜像需要格式化为 eStargz。 这是一种 OCI 替代方案，但 100% 兼容 OCI 的懒惰拉取镜像格式。 由于兼容性，eStargz 可以推送到标准容器注册表（例如 ghcr.io），并且即使在 eStargz 无关的运行时上也 仍然可运行。

eStargz 是基于 Google CRFS 项目提出的 stargz 格式 开发的，但具有包括内容验证和性能优化在内的实用功能。 有关懒惰拉取和 eStargz 的更多详细信息，请参考 Stargz Snapshotter 项目储存库。

为 eStargz 配置 k3s 的懒惰拉取

如以下所示，k3s 服务器和代理需要 --snapshotter=stargz 选项。

k3s server --snapshotter=stargz

使用此配置，您可以对 eStargz 格式的镜像执行懒惰拉取。 以下示例 Pod 清单使用 eStargz 格式的 node:13.13.0 镜像 (ghcr.io/stargz-containers/node:13.13.0-esgz)。 当启用 stargz 快照时，K3s 会对该镜像执行懒惰拉取。

apiVersion: v1
kind: Pod
metadata:
  name: nodejs
spec:
  containers:
  - name: nodejs-estargz
    image: ghcr.io/stargz-containers/node:13.13.0-esgz
    command: ["node"]
    args:
    - -e
    - var http = require('http');
      http.createServer(function(req, res) {
        res.writeHead(200);
        res.end('Hello World!\n');
      }).listen(80);
    ports:
    - containerPort: 80

附加日志记录源

可以在不使用 Rancher 的情况下安装 Rancher logging 以用于 K3s。应执行以下指令：

helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install --create-namespace -n cattle-logging-system rancher-logging-crd rancher-charts/rancher-logging-crd
helm install --create-namespace -n cattle-logging-system rancher-logging --set additionalLoggingSources.k3s.enabled=true rancher-charts/rancher-logging

附加网络策略日志记录

网络策略丢弃的数据包可以被记录。数据包被发送到 iptables NFLOG 动作，该动作显示数据包的详细信息，包括阻止它的网络策略。

如果流量很大，日志消息的数量可能会非常高。要按策略控制日志速率，请通过向相关网络策略添加以下注释来设置 limit 和 limit-burst iptables 参数：

  • kube-router.io/netpol-nflog-limit=<LIMIT-VALUE>

  • kube-router.io/netpol-nflog-limit-burst=<LIMIT-BURST-VALUE>

默认值为 limit=10/minute 和 limit-burst=10。有关这些字段格式和可能值的更多信息，请查看 iptables 手册。

要将 NFLOG 数据包转换为日志条目，请安装 ulogd2 并配置 [log1] 以在 group=100 上读取。然后，重启 ulogd2 服务以使新配置生效。 当数据包被网络策略规则阻止时，/var/log/ulog/syslogemu.log 中会出现日志消息。

发送到 NFLOG netlink 套接字的数据包也可以使用 tcpdump 或 tshark 等命令行工具读取：

tcpdump -ni nflog:100

虽然 tcpdump 更容易获取，但它不会显示阻止数据包的网络策略名称。请改用 wireshark 的 tshark 命令，以显示完整的 NFLOG 数据包头，包括包含策略名称的 nflog.prefix 字段。

丢弃数据包的网络策略日志记录不支持 具有空 podSelector 的策略。如果您依赖于记录丢弃的数据包进行诊断或审计，请确保您的策略包括一个与受影响的 Pod 匹配的 Pod 选择器。